From nicolas.dejean.ietf@googlemail.com Thu Jul 1 05:23:17 2010 Return-Path: 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 E1C523A6A35 for ; Thu, 1 Jul 2010 05:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.035 X-Spam-Level: X-Spam-Status: No, score=0.035 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, 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 oXgT-nWa5v6A for ; Thu, 1 Jul 2010 05:23:16 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2079528C126 for ; Thu, 1 Jul 2010 05:21:27 -0700 (PDT) Received: by wwi17 with SMTP id 17so18828wwi.13 for ; Thu, 01 Jul 2010 05:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=H9lUSzC2yIIPgVk8TUDJHrx04xjQcXrOX0SwduvE+3s=; b=DSLAe7ZBPdtm/piRdeVyQlu5ZkOb/M9NdeDMbJL0tJ+YZ/ewe5qs5WWwfxGUVcIdo/ wdZW7pviBnYEdzIxs/BwP1bGrOKhPTNXN+XebKY2HDRghTnoqF03Ap1VNOAf88zOo2tg bQcOaNhwZtcuu/wJdLFMc4HwUdl3ccBXjzl+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cez1Mq08je0Iwxhx7MKQo0UjcNRShi7oUY4F0TYlMrnZtrI03wYB6V4DGzlZDKQK1v ii4nhtlk/h8UQO2kvpdR9QdJKa52ZLe/JXiShNDzqJge1e5sdR9nDsUwWhL/6CQcQpnO uRCEwlBuWi1zpJNjN/AeUx4BhfvTMXeZMb2Hg= MIME-Version: 1.0 Received: by 10.213.28.5 with SMTP id k5mr4151441ebc.35.1277986865534; Thu, 01 Jul 2010 05:21:05 -0700 (PDT) Received: by 10.213.113.198 with HTTP; Thu, 1 Jul 2010 05:21:03 -0700 (PDT) In-Reply-To: References: <8E09C72DBC577D489F13A71228C0B7BF015DC2F0@ftrdmel0.rd.francetelecom.fr> <457DFDDC-10FD-430C-BFD5-49EAAF8ADC15@cs.stanford.edu> Date: Thu, 1 Jul 2010 14:21:03 +0200 Message-ID: From: Nicolas DEJEAN To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] Metrics ID, need for a new 'fill ratio' metric 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: , X-List-Received-Date: Thu, 01 Jul 2010 12:23:17 -0000 Phil, 2010/6/30 Philip Levis : > > On Jun 30, 2010, at 12:08 PM, Nicolas DEJEAN wrote: > > Recommendation > > ----------------- > > We concluded that statements of MUST/SHOULD/MAY relating to the 'O' bit have > to only related to *when* the bit is set, and can't relate to how a node > *responds* to hearing the 'O' bit. > > For example, CTP started with saying that a node, upon hearing the 'O' bit > set, MUST NOT route through a node until it hears the 'O' bit cleared. This > was a disaster. The text now reads that a node MUST set the 'O' bit when it > drops a packet due to a queue overflow. Of course, if you don't specify > either when to set it or what to do when it is set, then the bit is > meaningless. > > What I understand here is that the conclusion of your experiments is > that the 'O' bit cannot be used as I described. Right? > > I wouldn't go that far. Instead, we tried for a good six months to make it > work as described and concluded it probably wasn't the right approach. > Understood. > > So what do we have? > > About the 'O' bit, the metrics-07 is aligned with your recommandations. > (My own interpretation was not and I thank you again for all the details.) > Moreover, the meaning of this flag is clearly expressed as "may not be > able to process traffic". Some text also describes how it could be > used in a similar way than IS-IS. > However, for the moment, how to set the bit and what to do when it is > set is described as outside the scope. > Does CTP propose a solution about what to do when hearing the 'O' bit? > > It does not propose a solution. We tried a few and none worked well. So we > have left it as an open question. > OK metrics-07 also leave it as an open question. > The 'fill ratio' metric I described has really a different meaning and > should be managed in a separate metric as an implementation could use > both mechanisms (but also for clarity and usage as a constraint). > > What do you think? > > I don't know. I tend to be pretty conservative in these things. Wireless > protocol design is littered with so many ideas that looked good on paper but > didn't work well in practice. So I generally shrug until I've seen > supporting data from real-world networks. I don't see any reasons off the > top of my head why the metric you proposed would be unlikely to work in > practice, but there very well could be some that none of us know. In fact, this 'metric' has not only studied on paper. This is something we use in almost all our deployments (coupled with other metrics for sure, like Hop Count and LQL) and that provided good pro-active load balancing into our networks. Clearly, this is something usable only when the traffic flow generated by the network is known a priori. But this is not something new. An industrial usage in the field has shown a real interest of such a method. In these conditions, would be OK for including this new type of metric? > Phil Cheers, Nicolas. From alexandru.petrescu@gmail.com Thu Jul 1 05:31:14 2010 Return-Path: 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 0C7843A6A64 for ; Thu, 1 Jul 2010 05:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.733, 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 7TYUwT6+W9pz for ; Thu, 1 Jul 2010 05:31:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 247E63A69AA for ; Thu, 1 Jul 2010 05:31:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o61CVLX7019654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jul 2010 14:31:21 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o61CVLDO028455; Thu, 1 Jul 2010 14:31:21 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o61CVJsl030001; Thu, 1 Jul 2010 14:31:21 +0200 Message-ID: <4C2C8A97.9020007@gmail.com> Date: Thu, 01 Jul 2010 14:31:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alexandru Petrescu References: <8E09C72DBC577D489F13A71228C0B7BF015DC2F0@ftrdmel0.rd.francetelecom.fr> <457DFDDC-10FD-430C-BFD5-49EAAF8ADC15@cs.stanford.edu> <4C2C3C48.3050909@gmail.com> In-Reply-To: <4C2C3C48.3050909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] LC RPL-10 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: , X-List-Received-Date: Thu, 01 Jul 2010 12:31:14 -0000 [sorry for the previous wrong subject line] Le 30/06/2010 19:23, Philip Levis a écrit : > > On Jun 30, 2010, at 8:54 AM, Alexandru Petrescu wrote: > >> Le 30/06/2010 17:03, Pascal Thubert (pthubert) a écrit : >>> cribed. >>> >>> Anything else we need to add / update / delete ? >> >> Yes add IPsec AH I can write text if you need. > > Alex, > > Are you suggesting that AH should replace the current security > mechanisms, or that it's an additional option? Replace. IPsec AH covers ICMP completely and potentially other headers proposed for RPL in 6MAN - it would be worthless to have two signatures one IPsec and one issued from Abit CCM*. Proposal to write IPsec AH first, and make the current (A) bit and CCM* optional enhancements. Alex > > Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Thu Jul 1 05:40:26 2010 Return-Path: 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 9AC0A3A6BB8 for ; Thu, 1 Jul 2010 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.865 X-Spam-Level: X-Spam-Status: No, score=-4.865 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_20=-0.74, 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 xxa+5jmZeTM8 for ; Thu, 1 Jul 2010 05:40:23 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id B45863A6BB3 for ; Thu, 1 Jul 2010 05:39:55 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OUJ3m-0000iW-UA; Thu, 01 Jul 2010 05:40:07 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-14--966904083 From: Philip Levis In-Reply-To: Date: Thu, 1 Jul 2010 05:40:06 -0700 Message-Id: <1534B661-3E08-4EB1-8197-15AF0A977F2B@cs.stanford.edu> References: <8E09C72DBC577D489F13A71228C0B7BF015DC2F0@ftrdmel0.rd.francetelecom.fr> <457DFDDC-10FD-430C-BFD5-49EAAF8ADC15@cs.stanford.edu> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) X-Scan-Signature: daeb03f1a6494d8fe08e106a714ef916 Cc: roll@ietf.org Subject: Re: [Roll] Metrics ID, need for a new 'fill ratio' metric 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: , X-List-Received-Date: Thu, 01 Jul 2010 12:40:26 -0000 --Apple-Mail-14--966904083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 1, 2010, at 5:21 AM, Nicolas DEJEAN wrote: >>=20 >>=20 >> I don't know. I tend to be pretty conservative in these things. = Wireless >> protocol design is littered with so many ideas that looked good on = paper but >> didn't work well in practice. So I generally shrug until I've seen >> supporting data from real-world networks. I don't see any reasons off = the >> top of my head why the metric you proposed would be unlikely to work = in >> practice, but there very well could be some that none of us know. >=20 > In fact, this 'metric' has not only studied on paper. > This is something we use in almost all our deployments (coupled with > other metrics for sure, like Hop Count and LQL) and that provided good > pro-active load balancing into our networks. Clearly, this is > something usable only when the traffic flow generated by the network > is known a priori. But this is not something new. An industrial usage > in the field has shown a real interest of such a method. >=20 > In these conditions, would be OK for including this new type of = metric? Seems like a good idea to me. Standardizing how RPL/LLN nodes exchange = this kind of information is important. This leaves it open to future = specifications to describe best practices for computing and using the = information. It might be that current practices will work fine, or that = there's something different enough about RPL that it requires some = changes or modifications to current practice. Phil= --Apple-Mail-14--966904083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


I don't know. I = tend to be pretty conservative in these things. = Wireless
protocol design is = littered with so many ideas that looked good on paper = but
didn't work well in = practice. So I generally shrug until I've = seen
supporting data from = real-world networks. I don't see any reasons off = the
top of my head why the = metric you proposed would be unlikely to work = in
practice, but there very = well could be some that none of us know.

In fact, = this 'metric' has not only studied on paper.
This is something we use = in almost all our deployments (coupled with
other metrics for sure, = like Hop Count and LQL) and that provided good
pro-active load = balancing into our networks. Clearly, this is
something usable only = when the traffic flow generated by the network
is known a priori. But = this is not something new. An industrial usage
in the field has shown = a real interest of such a method.

In these conditions, would be = OK for including this new type of = metric?

Seems like a good idea to = me. Standardizing how RPL/LLN nodes exchange this kind of information is = important. This leaves it open to future specifications to describe best = practices for computing and using the information. It might be that = current practices will work fine, or that there's something different = enough about RPL that it requires some changes or modifications to = current practice.

Phil
= --Apple-Mail-14--966904083-- From d.sturek@att.net Thu Jul 1 06:05:27 2010 Return-Path: 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 7B83E3A67B2 for ; Thu, 1 Jul 2010 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.796 X-Spam-Level: * X-Spam-Status: No, score=1.796 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, 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 wHrKf-0WHk3R for ; Thu, 1 Jul 2010 06:05:26 -0700 (PDT) Received: from smtp108-mob.biz.mail.gq1.yahoo.com (smtp108-mob.biz.mail.gq1.yahoo.com [98.136.185.199]) by core3.amsl.com (Postfix) with SMTP id 0B1D03A68C7 for ; Thu, 1 Jul 2010 06:05:12 -0700 (PDT) Received: (qmail 99596 invoked from network); 1 Jul 2010 13:05:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1277989520; bh=sg3AsGayrFFU+sT1A9e+q/lS6Y4Hn2eOFqZw7Rp/MQU=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:To:Cc:Subject:From:Date:Content-Type:MIME-Version; b=ad7PJgm1IOBwpw9y5PXogazaJKiy4MYfXWk1IWauFaxKl4wOQDDKTDCrGQkMmNH16cs2r+c+pUAdQWymP3ba1VrRcZ9MjEudJYGiIZwJDivDonQqIcuErLssxXf2j5VPy9KuTHfFmtquT6vcywUwsNPztQugDMOzZQh60jccqpI= Received: from bda056.bisx.prod.on.blackberry (d.sturek@67.223.77.145 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 01 Jul 2010 06:05:20 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: i2IW20cVM1l.m3i51wWkcIfPzQ2Hyhhf3TSLvefByJDiWH7 9UwiLLmhodX5iwbWsUgXdJMay0nlVhwERAbQFw2mmO7Rfi92L14nnFsQjueO jdc5knKT2M03_0NQeSRlvtpL7PdadjS.RNvw09KvbqLxaiume0EpIXLl7VWq Iwv50hxPrVIV4PaMWtpAuXQZWda12j6gbAqcbQzhSEMroV_JbUwk0exiupeG l7EELCJgTrmGYGskwWqtMNbW_CDOhitREidRYnLBfEVJkPym8PgqOX5m4hsm TnxttX8jIlQTd6m2NDgQ- X-Yahoo-Newman-Property: ymail-3 X-rim-org-msg-ref-id: 2104719313 Message-ID: <2104719313-1277989517-cardhu_decombobulator_blackberry.rim.net-1537154360-@bda053.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <8E09C72DBC577D489F13A71228C0B7BF015DC2F0@ftrdmel0.rd.francetelecom.fr> <457DFDDC-10FD-430C-BFD5-49EAAF8ADC15@cs.stanford.edu> <4C2C3C48.3050909@gmail.com><4C2C8A97.9020007@gmail.com> In-Reply-To: <4C2C8A97.9020007@gmail.com> Sensitivity: Normal Importance: Normal To: "Alexandru Petrescu" , roll-bounces@ietf.org From: d.sturek@att.net Date: Thu, 1 Jul 2010 13:09:36 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] LC RPL-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:05:27 -0000 SSBhbSBjb21wbGV0ZWx5IG9wcG9zZWQgdG8gdGhpcyBwcm9wb3NhbC4gIFdlIHNob3VsZCBub3Qg YWRkIGlwc2VjIHRvIHRoZSBycGwgZHJhZnQuDQoNCkRvbg0KU2VudCB2aWEgQmxhY2tCZXJyeSBm cm9tIFQtTW9iaWxlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4YW5k cnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20+DQpTZW5kZXI6IHJvbGwt Ym91bmNlc0BpZXRmLm9yZw0KRGF0ZTogVGh1LCAwMSBKdWwgMjAxMCAxNDozMToxOSANClRvOiBB bGV4YW5kcnUgUGV0cmVzY3U8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4NCkNjOiA8cm9s bEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0gTEMgUlBMLTEwDQoNCltzb3JyeSBmb3Ig dGhlIHByZXZpb3VzIHdyb25nIHN1YmplY3QgbGluZV0NCg0KTGUgMzAvMDYvMjAxMCAxOToyMywg UGhpbGlwIExldmlzIGEg6WNyaXQgOg0KPg0KPiBPbiBKdW4gMzAsIDIwMTAsIGF0IDg6NTQgQU0s IEFsZXhhbmRydSBQZXRyZXNjdSB3cm90ZToNCj4NCj4+IExlIDMwLzA2LzIwMTAgMTc6MDMsIFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCkgYSDpY3JpdCA6DQo+Pj4gY3JpYmVkLg0KPj4+DQo+Pj4g QW55dGhpbmcgZWxzZSB3ZSBuZWVkIHRvIGFkZCAvIHVwZGF0ZSAvIGRlbGV0ZSA/DQo+Pg0KPj4g WWVzIGFkZCBJUHNlYyBBSCBJIGNhbiB3cml0ZSB0ZXh0IGlmIHlvdSBuZWVkLg0KPg0KPiBBbGV4 LA0KPg0KPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBBSCBzaG91bGQgcmVwbGFjZSB0aGUgY3Vy cmVudCBzZWN1cml0eQ0KPiBtZWNoYW5pc21zLCBvciB0aGF0IGl0J3MgYW4gYWRkaXRpb25hbCBv cHRpb24/DQoNClJlcGxhY2UuDQoNCklQc2VjIEFIIGNvdmVycyBJQ01QIGNvbXBsZXRlbHkgYW5k IHBvdGVudGlhbGx5IG90aGVyIGhlYWRlcnMgcHJvcG9zZWQNCmZvciBSUEwgaW4gNk1BTiAtIGl0 IHdvdWxkIGJlIHdvcnRobGVzcyB0byBoYXZlIHR3byBzaWduYXR1cmVzIG9uZSBJUHNlYw0KYW5k IG9uZSBpc3N1ZWQgZnJvbSBBYml0IENDTSouDQoNClByb3Bvc2FsIHRvIHdyaXRlIElQc2VjIEFI IGZpcnN0LCBhbmQgbWFrZSB0aGUgY3VycmVudCAoQSkgYml0IGFuZCBDQ00qDQpvcHRpb25hbCBl bmhhbmNlbWVudHMuDQoNCkFsZXgNCg0KPg0KPiBQaGlsDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWls aW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0K From nicolas.dejean.ietf@googlemail.com Thu Jul 1 11:51:39 2010 Return-Path: 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 B347A3A6A02 for ; Thu, 1 Jul 2010 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.326 X-Spam-Level: X-Spam-Status: No, score=0.326 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6] 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 uGA2d0IwQ-Eu for ; Thu, 1 Jul 2010 11:51:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 22F923A6825 for ; Thu, 1 Jul 2010 11:51:37 -0700 (PDT) Received: by wyg36 with SMTP id 36so281952wyg.31 for ; Thu, 01 Jul 2010 11:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Yuv28oAkddnw75aWFnCNMsR1uh+Ym0ds1taXBc5oCYw=; b=FPiWd7Cpcp5KT9hOfNKVNGFnSL4apYaDDpoIUtW8M/rcDnWOhoA+jhn52ztNi1quy4 jLncwFaTPuZf1RlGIsfOlpBXtuxs7NWDyqrDOJ3IrnuEN+uHuarn8uO3EKOf+wVvA/VZ Zv1RyAsfrVNO7rBS1siqS2Queb2qijpZSBWC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vLKVQ3nSvFSe5Ej4XHCB27DYGsCxj5S5nCmgnjU7mrHXv4bbqUwjDaJVk2lZg0f5r6 FXLRHzAUO8wrhdvrnNwEGgCy32Ji7pwRHu88vlX5rMK4VBalqlTZ0O32s4P57ba7/w6V b5HlqipNUCO54cFO2AxfGk7C5LRYf5NUdFvys= MIME-Version: 1.0 Received: by 10.213.12.196 with SMTP id y4mr2859134eby.3.1278010306021; Thu, 01 Jul 2010 11:51:46 -0700 (PDT) Received: by 10.213.113.198 with HTTP; Thu, 1 Jul 2010 11:51:45 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> Date: Thu, 1 Jul 2010 20:51:45 +0200 Message-ID: From: Nicolas DEJEAN To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] LC RPL-10 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: , X-List-Received-Date: Thu, 01 Jul 2010 18:51:39 -0000 Hi Pascal, WG, 2010/6/30 Pascal Thubert (pthubert) : > Hi Michael: > > Chicken and an egg... The Last call is an opportunity to give us an > hopefully last round of comments before we expose the spec to a larger > audience. > > What it tells us is that the chairs trust that we are getting somewhere, > and probably very close to where we want to be. > What is also tells us is that now is a good time to reread the spec and > see what's missing. > > We already know we need to add text on path sequence based on the FSM > that was present till 08. > There's also discussion on DAO Ack for non-storing that might impact the > behavior described in 10, > and non-RPL hosts support that might be incompletely described. > > Anything else we need to add / update / delete ? > As you asked for other updates, I had a look at rpl-10. Despite the impressing amount of work performed on this version, I have not seen any change concerning the DIS reception and Trickle Timer Reset. This issue was raised while dealing with Ticket #29. http://www.ietf.org/mail-archive/web/roll/current/msg03810.html is the last message posted on the thread (by me) before closing with the conclusion that DIS could now carry TLVs. This is already fine but the other subject discussed (that was not part of the ticket #29) has been lost in the battle. It seems to me that we had almost reached a concensus on this subject by adding some flags in order to break the currently existing link between: - the transmission method used for sending the DIS (unicast/multicast) - the Reset of the Trickle Timer (inconsistencies) - the transmission method used for answering (again unicast/multicast) Some flags were proposed: - C/R flag for driving the reset of the Trickle Timer - U flag for driving how the answered DIOs must be sent:unicast or multicas= t In rpl-10, some options exist but there is no such flag defined. Moreover, the second and third bullets describing the different Trickle Timer reset cases in section 7.3 contain hard MUST that could be softened by the flags proposed and let the door openened to some evolutions. IMHO, adding these 2 flags gives some opportunity to implement solutions like the 'Quick connection process' I described without adding complexity. Moreover, methods, goals and consequences will not be linked (Clarity is also a protocol quality). What do you think? > Pascal > Thank you, Nicolas. > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Michael Richardson >> Sent: Wednesday, June 30, 2010 3:29 PM >> To: David Culler >> Cc: roll@ietf.org >> Subject: Re: [Roll] LC RPL-10 >> >> >> >>>>> "David" =3D=3D David Culler writes: >> =A0 =A0 David> Dear ROLL WG, I would like to propose that we Last Call r= pl >> =A0 =A0 David> with http://www.ietf.org/id/draft-ietf-roll-rpl-10.txt. = =A0We >> =A0 =A0 David> have completed a significant body of clean up and >> =A0 =A0 David> simplification items since IETF 77, and we have wrapped u= p >> >> I agree with WG LC on -10.txt, but not until after IETF78. >> I'm not sure you understand what a last call is. It's not an > opportunity >> for: >> >> =A0 =A0 David> settled down. =A0By going to LC now, we have three weeks = to >> =A0 =A0 David> focus all of our attention on last minute clarifications > and >> =A0 =A0 David> clean up of the document before Maastricht. =A0Those >> =A0 =A0 David> refinements will be captured in 11 once submissions reope= n > at >> =A0 =A0 David> IETF 78. >> >> A LC is what you do after those clarifications are done. >> >> -- >> ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 = =A0 =A0 | > firewalls =A0[ >> ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|n= et >> architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ >> |device driver[ >> =A0 =A0Kyoto Plus: watch the video >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0then sign the petition. >> _______________________________________________ >> 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 pal@cs.stanford.edu Thu Jul 1 19:45:49 2010 Return-Path: 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 AF4133A685E for ; Thu, 1 Jul 2010 19:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.555 X-Spam-Level: X-Spam-Status: No, score=-4.555 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_20=-0.74, J_CHICKENPOX_47=0.6, 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 fR1NOdu1XE1o for ; Thu, 1 Jul 2010 19:45:45 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7C5F83A6859 for ; Thu, 1 Jul 2010 19:45:43 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OUWGI-0002Dl-Rt; Thu, 01 Jul 2010 19:45:55 -0700 In-Reply-To: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 1 Jul 2010 19:45:44 -0700 To: Nicolas DEJEAN X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: d06c6ff99f20bf33acb5a8de3011b91a Cc: roll@ietf.org Subject: Re: [Roll] LC RPL-10 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: , X-List-Received-Date: Fri, 02 Jul 2010 02:45:50 -0000 On Jul 1, 2010, at 11:51 AM, Nicolas DEJEAN wrote: > Hi Pascal, WG, > > 2010/6/30 Pascal Thubert (pthubert) : >> Hi Michael: >> >> Chicken and an egg... The Last call is an opportunity to give us an >> hopefully last round of comments before we expose the spec to a >> larger >> audience. >> >> What it tells us is that the chairs trust that we are getting >> somewhere, >> and probably very close to where we want to be. >> What is also tells us is that now is a good time to reread the >> spec and >> see what's missing. >> >> We already know we need to add text on path sequence based on the FSM >> that was present till 08. >> There's also discussion on DAO Ack for non-storing that might >> impact the >> behavior described in 10, >> and non-RPL hosts support that might be incompletely described. >> >> Anything else we need to add / update / delete ? >> > > As you asked for other updates, I had a look at rpl-10. > > Despite the impressing amount of work performed on this version, I > have not seen any change concerning the DIS reception and Trickle > Timer Reset. > This issue was raised while dealing with Ticket #29. > http://www.ietf.org/mail-archive/web/roll/current/msg03810.html is the > last message posted on the thread (by me) before closing with the > conclusion that DIS could now carry TLVs. > > This is already fine but the other subject discussed (that was not > part of the ticket #29) has been lost in the battle. > > It seems to me that we had almost reached a concensus on this subject > by adding some flags in order to break the currently existing link > between: > - the transmission method used for sending the DIS (unicast/multicast) > - the Reset of the Trickle Timer (inconsistencies) > - the transmission method used for answering (again unicast/multicast) > > Some flags were proposed: > - C/R flag for driving the reset of the Trickle Timer > - U flag for driving how the answered DIOs must be sent:unicast or > multicast > > In rpl-10, some options exist but there is no such flag defined. > > Moreover, the second and third bullets describing the different > Trickle Timer reset cases in section 7.3 contain hard MUST that could > be softened by the flags proposed and let the door openened to some > evolutions. > > IMHO, adding these 2 flags gives some opportunity to implement > solutions like the 'Quick connection process' I described without > adding complexity. Moreover, methods, goals and consequences will not > be linked (Clarity is also a protocol quality). > > What do you think? A couple of thoughts/opinions: 1) I personally don't think these optimizations matter much. The possible cost of disrupting Trickle is much, much higher than the cost of a few extra timer resets. In highly, highly dynamic environments, we see CTP's trickle-based control traffic to be 6-8% of the total traffic. Since CTP uses datapath validation, this is tied to the data rate (it wouldn't go up much if we lowered the data rate). In stable environments, it can be under 1%. If we're worried about the efficiency of RPL, this is *not* the place to start. 2) There's extensive research and deployment experience with Trickle; we know how it works both in theory and practice. This doesn't mean it can't be improved (Joakim has made several good points), but I'd strongly, strongly caution against tweaking it without a lot of evidence and testing first. Even slight changes can disrupt its delicate balance (e.g., waiting until interval expiration to reset can prevent the network from reaching consistency). 3) It is absolutely critical that reset be tied the transmission mechanism. In particular, it can be disastrous when a node responds immediately to a multicast message. 4) The Trickle timer is not doing more than it was intended to do; it is a simple yet amazingly powerful mechanism. One major use is establishing eventual consistency, but there are others. Phil From alexandru.petrescu@gmail.com Fri Jul 2 00:05:36 2010 Return-Path: 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 A0EC13A67AB for ; Fri, 2 Jul 2010 00:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_20=-0.74, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 F-z+pJIA9Z0b for ; Fri, 2 Jul 2010 00:05:34 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E4D2D3A67CF for ; Fri, 2 Jul 2010 00:05:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6275igM011535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Jul 2010 09:05:44 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6275iCi003884 for ; Fri, 2 Jul 2010 09:05:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6275hBf000728 for ; Fri, 2 Jul 2010 09:05:44 +0200 Message-ID: <4C2D8FC7.2030402@gmail.com> Date: Fri, 02 Jul 2010 09:05:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 CC: roll@ietf.org References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> In-Reply-To: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Security (was: LC RPL-10) 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: , X-List-Received-Date: Fri, 02 Jul 2010 07:05:36 -0000 I think there are several security aspects of RPL that need to be figured out. o should IPsec AH be used instead of RPL Abit CCM* security. o should security-framework draft and security in RPL draft be coherent (they seem to diverge in the preference of authentication over confidentiality). o should the 6MAN RPL related documents be covered coherently by the same security as RPL. When these are clearer I can provide technical comments to the RPL draft security text, for example how to fix this: draft-ietf-roll-rpl-10: "The exact placement and format of message integrity/authentication codes has not yet been determined." For example, if I know IPsec AH is used instead of Abit CCM* then I can suggest where the placement and format of authentication. and this: "[reference to RoLL security-framework absent]" If I know the two docs should in sync then I suggest to refer each other. Alex Le 30/06/2010 06:16, David Culler a écrit : > Dear ROLL WG, I would like to propose that we Last Call rpl with > http://www.ietf.org/id/draft-ietf-roll-rpl-10.txt. We have completed > a significant body of clean up and simplification items since IETF > 77, and we have wrapped up the critical open items, including routing > security. We have few open tickets. We have areas of future work, > but we have been able to separate them from the core spec, so they > can be developed more fully while experience is gained with the core. > We have numerous implementations that are operational and many many > more that are waiting to be sure things have settled down. By going > to LC now, we have three weeks to focus all of our attention on last > minute clarifications and clean up of the document before Maastricht. > Those refinements will be captured in 11 once submissions reopen at > IETF 78. > > So, please all in favor of LC on RPL-10... > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Fri Jul 2 02:25:25 2010 Return-Path: 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 631333A685B for ; Fri, 2 Jul 2010 02:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 suHWorZBzqpn for ; Fri, 2 Jul 2010 02:25:24 -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 BB8103A68E8 for ; Fri, 2 Jul 2010 02:25:20 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANRMLUyrRN+J/2dsb2JhbACfa3GjNpo9hSUEilk X-IronPort-AV: E=Sophos;i="4.53,525,1272844800"; d="scan'208";a="553528373" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2010 09:25:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o629PUrY024354; Fri, 2 Jul 2010 09:25:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 11:25:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jul 2010 11:25:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02397925@XMB-AMS-107.cisco.com> In-Reply-To: <4C2D8FC7.2030402@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Security (was: LC RPL-10) thread-index: AcsZtQrdN7SlIDKPT1u7GBAhX7OGFAAEwsAQ References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <4C2D8FC7.2030402@gmail.com> From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 02 Jul 2010 09:25:23.0158 (UTC) FILETIME=[7F639F60:01CB19C8] Cc: roll@ietf.org Subject: Re: [Roll] Security (was: LC RPL-10) 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: , X-List-Received-Date: Fri, 02 Jul 2010 09:25:25 -0000 Hi Alex: CCM is the de facto standard in the WSN space. It is used at all layers = from 2 to 4.=20 One deployed example is ISA100.11a that uses it in the data link and to = build transport layer MICs. The spec certainly needs to accommodate the real world, and in this = case, the existing hardware assists present in the chipsets. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > Alexandru Petrescu > Sent: Friday, July 02, 2010 9:06 AM > Cc: roll@ietf.org > Subject: Re: [Roll] Security (was: LC RPL-10) >=20 > I think there are several security aspects of RPL that need to be > figured out. >=20 > o should IPsec AH be used instead of RPL Abit CCM* security. > o should security-framework draft and security in RPL draft be = coherent > (they seem to diverge in the preference of authentication over > confidentiality). > o should the 6MAN RPL related documents be covered coherently by the > same security as RPL. >=20 > When these are clearer I can provide technical comments to the RPL = draft > security text, for example how to fix this: >=20 > draft-ietf-roll-rpl-10: > "The exact placement and format of message integrity/authentication > codes has not yet been determined." >=20 > For example, if I know IPsec AH is used instead of Abit CCM* then I = can > suggest where the placement and format of authentication. >=20 > and this: > "[reference to RoLL security-framework absent]" >=20 > If I know the two docs should in sync then I suggest to refer each = other. >=20 > Alex >=20 > Le 30/06/2010 06:16, David Culler a =E9crit : > > Dear ROLL WG, I would like to propose that we Last Call rpl with > > http://www.ietf.org/id/draft-ietf-roll-rpl-10.txt. We have = completed > > a significant body of clean up and simplification items since IETF > > 77, and we have wrapped up the critical open items, including = routing > > security. We have few open tickets. We have areas of future work, > > but we have been able to separate them from the core spec, so they > > can be developed more fully while experience is gained with the = core. > > We have numerous implementations that are operational and many many > > more that are waiting to be sure things have settled down. By going > > to LC now, we have three weeks to focus all of our attention on last > > minute clarifications and clean up of the document before = Maastricht. > > Those refinements will be captured in 11 once submissions reopen at > > IETF 78. > > > > So, please all in favor of LC on RPL-10... > > _______________________________________________ Roll mailing > list > > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Jul 2 07:55:39 2010 Return-Path: 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 9926D3A68BF for ; Fri, 2 Jul 2010 07:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.752 X-Spam-Level: X-Spam-Status: No, score=-5.752 tagged_above=-999 required=5 tests=[AWL=0.847, 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 fN+LD9fD8N-q for ; Fri, 2 Jul 2010 07:55:38 -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 DCF703A68B9 for ; Fri, 2 Jul 2010 07:55:38 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OUheg-0000t5-Pe; Fri, 02 Jul 2010 07:55:50 -0700 In-Reply-To: <4C2D8FC7.2030402@gmail.com> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <4C2D8FC7.2030402@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 2 Jul 2010 07:55:40 -0700 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: roll@ietf.org Subject: Re: [Roll] Security (was: LC RPL-10) 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: , X-List-Received-Date: Fri, 02 Jul 2010 14:55:39 -0000 On Jul 2, 2010, at 12:05 AM, Alexandru Petrescu wrote: > > "The exact placement and format of message integrity/authentication > codes has not yet been determined." Ah -- nice catch. This is leftover text from -08 that should be removed. The document currently specifies where they should go. Phil From alexandru.petrescu@gmail.com Fri Jul 2 08:41:07 2010 Return-Path: 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 4E7833A67F0 for ; Fri, 2 Jul 2010 08:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] 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 x4E8+H4swzaM for ; Fri, 2 Jul 2010 08:41:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8BB903A68B2 for ; Fri, 2 Jul 2010 08:41:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o62FfFqq009665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Jul 2010 17:41:15 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o62FfFSx032196 for ; Fri, 2 Jul 2010 17:41:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o62FfEWc006307 for ; Fri, 2 Jul 2010 17:41:15 +0200 Message-ID: <4C2E089A.5040604@gmail.com> Date: Fri, 02 Jul 2010 17:41:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 CC: roll@ietf.org References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <4C2D8FC7.2030402@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D02397925@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02397925@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Security 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: , X-List-Received-Date: Fri, 02 Jul 2010 15:41:08 -0000 Le 02/07/2010 11:25, Pascal Thubert (pthubert) a écrit : > Hi Alex: > > CCM is the de facto standard in the WSN space. It is used at all > layers from 2 to 4. One deployed example is ISA100.11a that uses it > in the data link and to build transport layer MICs. The spec > certainly needs to accommodate the real world, and in this case, the > existing hardware assists present in the chipsets. Hmm, good to learn CCM is the de facto stadard in the WSN space, namely ISA100.11a. (is ISA100.11a equating WSN). IPsec AH hardware may already exist too, largely deployed in the real world, de facto. In addition to the availability of hardware (CCM vs e.g. MD4 of IPSec) we could also discuss export control (is CCM more controlled than MD4?), home space standards, smart grid standards - would they all use CCM de facto? We may discuss more about the CCM choice, I am all ears. Alex > > Pascal > > >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: Friday, July 02, 2010 9:06 AM Cc: roll@ietf.org Subject: Re: >> [Roll] Security (was: LC RPL-10) >> >> I think there are several security aspects of RPL that need to be >> figured out. >> >> o should IPsec AH be used instead of RPL Abit CCM* security. o >> should security-framework draft and security in RPL draft be >> coherent (they seem to diverge in the preference of authentication >> over confidentiality). o should the 6MAN RPL related documents be >> covered coherently by the same security as RPL. >> >> When these are clearer I can provide technical comments to the RPL >> draft security text, for example how to fix this: >> >> draft-ietf-roll-rpl-10: "The exact placement and format of message >> integrity/authentication codes has not yet been determined." >> >> For example, if I know IPsec AH is used instead of Abit CCM* then I >> can suggest where the placement and format of authentication. >> >> and this: "[reference to RoLL security-framework absent]" >> >> If I know the two docs should in sync then I suggest to refer each >> other. >> >> Alex >> >> Le 30/06/2010 06:16, David Culler a écrit : >>> Dear ROLL WG, I would like to propose that we Last Call rpl with >>> http://www.ietf.org/id/draft-ietf-roll-rpl-10.txt. We have >>> completed a significant body of clean up and simplification items >>> since IETF 77, and we have wrapped up the critical open items, >>> including routing security. We have few open tickets. We have >>> areas of future work, but we have been able to separate them from >>> the core spec, so they can be developed more fully while >>> experience is gained with the core. We have numerous >>> implementations that are operational and many many more that are >>> waiting to be sure things have settled down. By going to LC >>> now, we have three weeks to focus all of our attention on last >>> minute clarifications and clean up of the document before >>> Maastricht. Those refinements will be captured in 11 once >>> submissions reopen at IETF 78. >>> >>> So, please all in favor of LC on RPL-10... >>> _______________________________________________ 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 navagar@cisco.com Sun Jul 4 23:38:30 2010 Return-Path: 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 8C9273A6852 for ; Sun, 4 Jul 2010 23:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 JGDYpEdhDock for ; Sun, 4 Jul 2010 23:38:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B921C3A67D1 for ; Sun, 4 Jul 2010 23:38:29 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKcaMUxAaHte/2dsb2JhbACfaXGjJ5lShSUEg3aGcA X-IronPort-AV: E=Sophos;i="4.53,538,1272844800"; d="scan'208";a="229155023" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2010 06:38:30 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o656cTWZ023702; Mon, 5 Jul 2010 06:38:29 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 12:08:29 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Jul 2010 12:05:39 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB0189E5ED@XMB-BGL-41C.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D021DB5EC@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] downward routing question Thread-Index: AcsMZnxKz/QHQo0pSsKwQL8BDtClCQPpVY9g References: <6A2A459175DABE4BB11DE2026AA50A5D021DB5EC@XMB-AMS-107.cisco.com> From: "Navneet Agarwal (navagar)" To: "Pascal Thubert (pthubert)" , "Reddy, Joseph" , X-OriginalArrivalTime: 05 Jul 2010 06:38:29.0278 (UTC) FILETIME=[ADE40BE0:01CB1C0C] Subject: Re: [Roll] downward routing question 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: , X-List-Received-Date: Mon, 05 Jul 2010 06:38:30 -0000 Hi Pascal: Does this mean that there would be an equivalent 'R' bit in RPL spec also as mentioned in RFC 3775 section 7.2? I did not see it in rev-10 Thx Regards, Navneet > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Tuesday, June 15, 2010 2:11 PM > To: Reddy, Joseph; roll@ietf.org > Subject: Re: [Roll] downward routing question >=20 > Hi Joseph: >=20 > This is certainly missing from 09 to be fixed in 10.=20 >=20 > In RFC 3775 section 7.2, this is done by placing the full=20 > address of the "parent" in the PIO as opposed to truncating=20 > to the prefix. >=20 > I suggest we do the same thing in non-storing mode. In that=20 > mode, when a router advertises a PIO option in a DIO message,=20 > it places its address that matches the prefix in the PIO,=20 > thus overriding the suffix but preserving the prefix. Only=20 > addresses that match the prefix advertised by the root can be=20 > used for that purpose. >=20 > Makes sense? >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Reddy, Joseph > > Sent: Tuesday, June 15, 2010 3:17 AM > > To: roll@ietf.org > > Subject: [Roll] downward routing question > >=20 > >=20 > >=20 > > Hi, > >=20 > > I have a question on the downward routing feature in RPL > >=20 > > The DIO packets are transmitted with source address set to the link > local > > address of the routers. So a new device that joins the DAG has only > the LL > > address of the parent routers. So it can only include these=20 > in the DAO > that it > > transmits. > >=20 > > Can the root node include the list of link local addresses in the > source routing > > header ? I think not, it must include global addresses of all the > intermediate > > routers. So how can a new device discover global addresses=20 > of its DIO=20 > > parents ? > >=20 > >=20 > > -Regards, Joseph > >=20 > > _______________________________________________ > > 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 >=20 From jpv@cisco.com Mon Jul 5 04:16:17 2010 Return-Path: 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 38BD73A6946 for ; Mon, 5 Jul 2010 04:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, SARE_SPEC_LEO_LINE03e=0.635] 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 wth1BGdjTpC9 for ; Mon, 5 Jul 2010 04:16:15 -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 8B63B3A6954 for ; Mon, 5 Jul 2010 04:15:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHANpbMUxAZnwM/2dsb2JhbACBQpFpjERxo0KZdoUlBIg6giw X-IronPort-AV: E=Sophos;i="4.53,539,1272844800"; d="gif'147?scan'147,208,217,147";a="128724661" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2010 11:15:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o65BFveR002307 for ; Mon, 5 Jul 2010 11:15:57 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 13:15:57 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 13:15:55 +0200 Message-Id: <8FE78511-A84F-4162-89E5-37EAF42FD327@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-56--626355288 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Jul 2010 13:15:55 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Jul 2010 11:15:55.0997 (UTC) FILETIME=[701BC8D0:01CB1C33] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17486.006 X-TM-AS-Result: No--4.378300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Final Agenda uploaded 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: , X-List-Received-Date: Mon, 05 Jul 2010 11:16:17 -0000 --Apple-Mail-56--626355288 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit THURSDAY, July 29, 2010 0800-1700 IETF Registration - Trajectum Lobby 0800-0900 Beverages - Trajectum Lobby 0900-1130 Morning Session I 0.9 Athens APP precis Preparation and Comparison of Internationalized Strings WG 0.4 Brussels INT dhc Dynamic Host Configuration WG 0.2 Berlin INT mip4 Mobility for IPv4 WG 0.1 London IRTF samrg Scalable Adaptive Multicast Research Group 0.8 Rome OPS bmwg Benchmarking Methodology WG 2.1 Colorado RAI martini Multiple AoR reachabiliTy InformatioN Indication WG Auditorium 1 RTG karp Keying and Authentication for Routing Protocols WG Auditorium 2 TSV tsvwg Transport Area Working Group WG 1130-1300 Break - Trajectum Lobby 1300-1500 Afternoon Session I 0.1 London APP sieve Sieve Mail Filtering Language WG 2.1 Colorado INT mif Multiple Interfaces WG 0.9 Athens IRTF mobopts IP Mobility Optimizations Research Group 0.2 Berlin OPS ipfix IP Flow Information Export WG 0.4 Brussels RAI ecrit Emergency Context Resolution with Internet Technologies WG Auditorium 2 RTG roll Routing Over Low power and Lossy networks WG Auditorium 1 SEC saag Security Area Open Meeting 0.8 Rome TSV fecframe FEC Framework WG 1510-1610 Afternoon Session II 0.9 Athens APP yam Yet Another Mail WG 2.1 Colorado INT lisp Locator/ID Separation Protocol WG 0.4 Brussels OPS grow Global Routing Operations WG 0.2 Berlin RAI martini Multiple AoR reachabiliTy InformatioN Indication WG 2.1 Colorado RAI xmpp Extensible Messaging and Presence Protocol WG Auditorium 2 RTG roll Routing Over Low power and Lossy networks WG 0.1 London SEC hokey Handover Keying WG 0.8 Rome SEC krb-wg Kerberos WG Auditorium 1 TSV mptcp Multipath TCP WG --Apple-Mail-56--626355288 Content-Type: multipart/related; boundary=Apple-Mail-57--626355283; type="text/html" --Apple-Mail-57--626355283 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 0.8 Rome

THURSDAY, July 29, = 2010

Tra= jectum Lobby

0800-0900 Beverages - Tra= jectum Lobby
0900-1130 Morning Session I
0.9 Athensprecis3D"" Preparati= on and Comparison of Internationalized Strings WG
0.4 Brusselsdhc3D"" Dynamic = Host Configuration WG
0.2 Berlinmip43D"" Mobility = for IPv4 WG
0.1 Londonsamrg3D"" Scalable = Adaptive Multicast Research Group
bmwg3D"" Benchmark= ing Methodology WG
2.1 Coloradomartini3D"" Multiple = AoR reachabiliTy InformatioN Indication WG
Auditorium 1karp3D"" Keying = and Authentication for Routing Protocols WG
Auditorium 2tsvwg3D"" Transport= Area Working Group WG

1130-1300 Break - Tra= jectum Lobby
1300-1500 Afternoon Session I
0.1 Londonsieve3D"" Sieve = Mail Filtering Language WG
2.1 Coloradomif3D"" Multiple = Interfaces WG
0.9 Athensmobopts3D"" IP = Mobility Optimizations Research Group
0.2 Berlinipfix3D"" IP Flow Information Export WG
0.4 Brusselsecrit3D"" Emergency= Context Resolution with Internet Technologies WG
Auditorium 2roll3D"" Routing = Over Low power and Lossy networks WG
Auditorium 1saag3D"" Security = Area Open Meeting
0.8 Romefecframe3D"" FEC = Framework WG
0.9 Athensyam3D"" Yet = Another Mail WG
2.1 Coloradolisp3D"" Locator/I= D Separation Protocol WG
0.4 Brusselsgrow3D"" Global = Routing Operations WG
0.2 Berlinmartini3D"" Multiple = AoR reachabiliTy InformatioN Indication WG
2.1 Coloradoxmpp3D"" Extensibl= e Messaging and Presence Protocol WG
Auditorium 2roll3D"" Routing = Over Low power and Lossy networks WG
0.1 Londonhokey3D"" Handover = Keying WG
0.8 Romekrb-wg3D"" Kerberos = WG
Auditorium 1mptcp3D"" Multipath= TCP WG

= --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <102EC076-1FA8-4AB6-B868-4D8FC2908E61@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <6B99E259-009C-4FF9-9799-ED6F4140EE3A@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <4A07AC87-2E63-4EC5-9D27-996057B4C067@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <1CD9FF07-0CD6-4737-8525-94FE3B12A4B6@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <7BDBCB0F-719A-41B3-87EF-3874FF75CBF0@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <09F3F90B-3395-46BE-B129-09D93D1D47BB@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <8EE13E90-0F3E-42EA-9511-6B6255828C88@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <47AABB6B-BBAA-4DAC-8547-DACF56672A8C@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <77614B61-D7D0-4449-B16C-3D459AD1A163@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <9F416116-E883-456E-9A9E-A1A92BACB550@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <8A722538-FE0D-4D62-A699-688BA5BC0EC5@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <8BE3C02F-5D3B-4B89-A2FC-A8831048DDFA@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <9D2E494C-4514-48E2-B05E-B69B32B6FE97@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <5265B731-B209-4F27-AAC1-CFEAC612BBED@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <02E219EA-D165-4BF9-977C-74DF296F5FAE@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <5BBD2E2E-58D6-4E79-B69F-561B2D7D1EEB@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <4A6AFFD1-32F9-4F88-9950-339DCC0011C3@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283 Content-Disposition: inline; filename=color-palette-4x4.gif Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="color-palette-4x4.gif" Content-Id: <0A4F6922-38B1-4AD1-84D9-4A3651807499@cisco.com> R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --Apple-Mail-57--626355283-- --Apple-Mail-56--626355288-- From trac@tools.ietf.org Mon Jul 5 05:39:47 2010 Return-Path: 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 C3E463A684C for ; Mon, 5 Jul 2010 05:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.145 X-Spam-Level: X-Spam-Status: No, score=-101.145 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 fhc8ZB7VVzDn for ; Mon, 5 Jul 2010 05:39:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F249A3A683A for ; Mon, 5 Jul 2010 05:39:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVkxg-0003Fo-H2; Mon, 05 Jul 2010 05:39:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 05 Jul 2010 12:39:48 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/55 Message-ID: <055.3f9964d7e3d9be963ea63ee01a78e115@tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #55: Downward routes in RPL rev -09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 12:39:47 -0000 #55: Downward routes in RPL rev -09 -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from Ralph Droms - June 27 Some details of the transmission and use of DAOs in a non-storing mode LLN are unclear to me... 1) How are DAO messages delivered from source to destination? I read list item 2 in section 8.7: 2. On receiving a unicast DAO, a node MUST forward the DAO upwards. This forwarding MAY use any parent in the parent set. to mean that: a) the sending node sets the IP destination address of the DAO to the address of one of its DAO parents b) the receiving node, in turn, sends the DAO to one of its (the receiving node's) DAO parents However, later in section 8.7, this text: Nodes aggregate DAOs by sending a single DAO with multiple RPL Target Options. leads me to believe that the receiving node "consumes" the DAO messages it receives (during the delay time specified in section 8.4) and constructs a new DAO message that aggregates the information from those received DAO messages. 2) Is the interpretation of RPL Target and Transit Information options in a DAO of dependent on the order and context in which those options appear? That is, are a string of consecutive RPL Target options considered a set of targets, for which a following string of Transit Information options are considered to hold the set of parents? 3) In the first bullet list item of section 8.1, does "subset of its parent set" mean "subset of its DODAG parent set"? 4) In section 8.3: 1. Each time a node generates a new DAO, the DAOSequence field MUST increment by at least one since the last generated DAO. what does "generates a new DAO" mean? How does this rule apply to 1), above? 5) In section 8.3: 2. Each time a node link-local multicasts a DAO, the DAOSequence field MUST increment by one since the last link local multicast DAO. why does this rule only apply to multicast? _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -- Ticket URL: roll From trac@tools.ietf.org Mon Jul 5 05:40:17 2010 Return-Path: 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 EA3113A696B for ; Mon, 5 Jul 2010 05:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 pxhbmajroOG1 for ; Mon, 5 Jul 2010 05:40:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D8C5E3A693A for ; Mon, 5 Jul 2010 05:40:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OVkyA-0003Ni-Dy; Mon, 05 Jul 2010 05:40:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 05 Jul 2010 12:40:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/55#comment:1 Message-ID: <064.b696135afc7dc4260b60ce1b3d453170@tools.ietf.org> References: <055.3f9964d7e3d9be963ea63ee01a78e115@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <055.3f9964d7e3d9be963ea63ee01a78e115@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #55: Downward routes in RPL rev -09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 12:40:18 -0000 #55: Downward routes in RPL rev -09 -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Comment(by jpv@…): Email from Phil Levis On Sun, 2010-06-27 at 16:00 -0400, Ralph Droms wrote: Some details of the transmission and use of DAOs in a non-storing mode LLN are unclear to me... 1) How are DAO messages delivered from source to destination? I read list item 2 in section 8.7: 2. On receiving a unicast DAO, a node MUST forward the DAO upwards. This forwarding MAY use any parent in the parent set. to mean that: a) the sending node sets the IP destination address of the DAO to the address of one of its DAO parents b) the receiving node, in turn, sends the DAO to one of its (the receiving node's) DAO parents However, later in section 8.7, this text: Nodes aggregate DAOs by sending a single DAO with multiple RPL Target Options. leads me to believe that the receiving node "consumes" the DAO messages it receives (during the delay time specified in section 8.4) and constructs a new DAO message that aggregates the information from those received DAO messages. The second conclusion is correct. The 2. bullet should probably read 2. On receiving a unicast DAO, a node MUST forward the updated downward route information upwards. This forwarding MAY use any parent in the parent set. The downward route information in the DAO MAY be aggregated with other DAOs before being forwarded upwards. Is that better? 2) Is the interpretation of RPL Target and Transit Information options in a DAO of dependent on the order and context in which those options appear? That is, are a string of consecutive RPL Target options considered a set of targets, for which a following string of Transit Information options are considered to hold the set of parents? The pattern is (Target, Transit+)+ 3) In the first bullet list item of section 8.1, does "subset of its parent set" mean "subset of its DODAG parent set"? Yes -- I think -10 reflects this. 4) In section 8.3: 1. Each time a node generates a new DAO, the DAOSequence field MUST increment by at least one since the last generated DAO. what does "generates a new DAO" mean? How does this rule apply to 1), above? "Generates a new DAO" means "send a DAO with different information." E.g., different field values, options, option values, etc. Retransmitting a DAO with the same information (e.g., due to the lack of a DAO-Ack) does not require incrementing the sequence number. This is for the case where the DAO parent received the message but the ack was lost. 5) In section 8.3: 2. Each time a node link-local multicasts a DAO, the DAOSequence field MUST increment by one since the last link local multicast DAO. why does this rule only apply to multicast? Good question -- I don't know. It should not apply to unicast due to the ack mechanism. Pascal, Tim? Phil __________________ -- Ticket URL: roll From jpv@cisco.com Mon Jul 5 05:42:58 2010 Return-Path: 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 A23B43A68BB for ; Mon, 5 Jul 2010 05:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.421 X-Spam-Level: X-Spam-Status: No, score=-9.421 tagged_above=-999 required=5 tests=[AWL=1.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Z2jjhjb1lIlf for ; Mon, 5 Jul 2010 05:42:58 -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 CD7293A68A2 for ; Mon, 5 Jul 2010 05:42:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALpvMUxAZnwN/2dsb2JhbACfdHGjfJl+hSUEiDqCLA X-IronPort-AV: E=Sophos;i="4.53,539,1272844800"; d="scan'208";a="128742826" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2010 12:42:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o65CgwaS008046; Mon, 5 Jul 2010 12:42:58 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 14:42:58 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 14:42:58 +0200 Message-Id: <6F28AAF0-2C7A-4CFB-BB80-49AE448A4DED@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Jul 2010 14:42:57 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Jul 2010 12:42:58.0253 (UTC) FILETIME=[98D0CFD0:01CB1C3F] Subject: [Roll] Request for slot ROLL WG Meeting 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: , X-List-Received-Date: Mon, 05 Jul 2010 12:42:58 -0000 Dear all, Could you please let us as soon as possible if you would like to get a slot for the ROLL WG meeting IETF-78. Be aware that we may not be able to accommodate all requests since a good part of the meeting will be given to RPL. Some slots may thus be conditional (if time permits). Thanks. JP. From pierre.colle@fr.schneider-electric.com Mon Jul 5 08:15:28 2010 Return-Path: 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 2DA493A69C8 for ; Mon, 5 Jul 2010 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=2.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 c5Gmg38rjmbD for ; Mon, 5 Jul 2010 08:15:27 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id E35C43A691D for ; Mon, 5 Jul 2010 08:15:25 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2010070517064320-168415 ; Mon, 5 Jul 2010 17:06:43 +0200 From: pierre.colle@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Mon, 5 Jul 2010 17:15:21 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 05/07/2010 17:15:26, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 05/07/2010 17:06:43, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 05/07/2010 17:06:44, Serialize complete at 05/07/2010 17:06:44 Content-type: multipart/alternative; Boundary="0__=4EBBFDC4DFC04B0B8f9e8a93df938690918c4EBBFDC4DFC04B0B" Content-Disposition: inline Subject: [Roll] Pierre Colle/FR/Schneider est absent(e). 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: , X-List-Received-Date: Mon, 05 Jul 2010 15:15:28 -0000 --0__=4EBBFDC4DFC04B0B8f9e8a93df938690918c4EBBFDC4DFC04B0B Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 03/07/2010 de retour le 20/07/2010. I am currently out of office. Best regards, Pierre = --0__=4EBBFDC4DFC04B0B8f9e8a93df938690918c4EBBFDC4DFC04B0B Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 03/07/2010 de retour le 20/07/201= 0.

I am currently out of office.

Best regards,

Pierre

= --0__=4EBBFDC4DFC04B0B8f9e8a93df938690918c4EBBFDC4DFC04B0B-- From zach@sensinode.com Tue Jul 6 02:16:42 2010 Return-Path: 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 F347F3A67E2 for ; Tue, 6 Jul 2010 02:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599, 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 DiUh3-cr5tG0 for ; Tue, 6 Jul 2010 02:16:41 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id B4F6F3A67F5 for ; Tue, 6 Jul 2010 02:16:39 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o669GZpA025994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Jul 2010 12:16:35 +0300 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02397925@XMB-AMS-107.cisco.com> Date: Tue, 6 Jul 2010 12:16:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7BB5BAD6-ACCA-4477-99A6-80A4122781E7@sensinode.com> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <4C2D8FC7.2030402@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D02397925@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Security (was: LC RPL-10) 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: , X-List-Received-Date: Tue, 06 Jul 2010 09:16:42 -0000 On Jul 2, 2010, at 12:25 PM, Pascal Thubert (pthubert) wrote: > CCM is the de facto standard in the WSN space. It is used at all = layers from 2 to 4.=20 > One deployed example is ISA100.11a that uses it in the data link and = to build transport layer MICs. > The spec certainly needs to accommodate the real world, and in this = case, the existing hardware assists present in the chipsets. +1 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From mdurvy@cisco.com Tue Jul 6 04:17:17 2010 Return-Path: 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 251753A6895 for ; Tue, 6 Jul 2010 04:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.178 X-Spam-Level: X-Spam-Status: No, score=-9.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 YUB4JQ8UVYYD for ; Tue, 6 Jul 2010 04:17:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5BF013A6834 for ; Tue, 6 Jul 2010 04:17:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABKtMkyrR7Ht/2dsb2JhbACBQ55BcaRAmi8ChSMEimY X-IronPort-AV: E=Sophos;i="4.53,545,1272844800"; d="gif'147?p7s'147?png'147,150?scan'147,150,208,217,147,150"; a="222141085" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2010 11:17:14 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o66BH1Q3010592 for ; Tue, 6 Jul 2010 11:17:14 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 13:17:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jul 2010 13:17:09 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0525_01CB1D0D.89A344B0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE02725921@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Transit and Target address mismatch Thread-Index: Acsc/MYClI8z8SCxSaK2OeOOKXoBPQ== From: "Mathilde Durvy (mdurvy)" To: "ROLL WG" X-OriginalArrivalTime: 06 Jul 2010 11:17:11.0161 (UTC) FILETIME=[C752A690:01CB1CFC] Subject: [Roll] Transit and Target address mismatch 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: , X-List-Received-Date: Tue, 06 Jul 2010 11:17:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0525_01CB1D0D.89A344B0 Content-Type: multipart/related; boundary="----=_NextPart_001_0526_01CB1D0D.89A344B0" ------=_NextPart_001_0526_01CB1D0D.89A344B0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0527_01CB1D0D.89A344B0" ------=_NextPart_002_0527_01CB1D0D.89A344B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 Let=92s consider the storing mode in a simple topology A=E0B=E0R (=E0 = mark the parent relationship). Let=92s also assume that A has a prefix =91Ap=92 = and a global address =91Ag=92 to advertise. In this example we have: - A sends DAO with =93target Ag, Ap, transit B=94 - B sends DAO with =93target Bg, transit R=94 together with the = information from A, i.e. =93target Ag, Ap, transit B=94 =20 Then R recombines the information to get the route to for example Ap = (Target Ap, transit B, target Bg, transit R) For this to work, transit B and target Bg need to be matched. How can = this be done? Does it mean that the transit parent address has to be a global address? This would imply that we use global addresses in the routing header. However 6man-rpl-routing-header says: =93When processing the Type 4 Routing header, a router MUST drop the = packet if the next entry is not on-link=94 As global addresses have to be off-link in NBMA network like 802.15.4, I = see a problem=85 =20 Can you please clarify how addresses are supposed to be used in this source-routing scenario. =20 Thanks, Mathilde =20 =20 =20 http://www.cisco.com/swa/i/logo.gif Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 Think before you print.Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message. ------=_NextPart_002_0527_01CB1D0D.89A344B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Let’s consider the storing mode in a simple = topology A=E0B=E0R (=E0 mark the parent = relationship). Let’s also assume that A has a prefix ‘Ap’ and a = global address ‘Ag’ to advertise.

In this example we have:

- A sends DAO with “target Ag, Ap, transit = B”

- B sends DAO with “target Bg, transit = R” together with the information from A, i.e. “target Ag, Ap, transit B”

 

Then R recombines the information to get the route = to for example Ap (Target Ap, transit B, target Bg, transit R)

For this to work, transit B and target Bg need to = be matched. How can this be done? Does it mean that the transit parent address has = to be a global address? This would imply that we use global addresses in the = routing header. However 6man-rpl-routing-header says:

“When processing the Type 4 Routing header, a = router MUST drop the packet if the next entry is not = on-link”

As global addresses have to be off-link in NBMA = network like 802.15.4, I see a problem…

 

Can you please clarify how addresses are supposed = to be used in this source-routing scenario.

 

Thanks,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco = home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain confidential and privileged material for the sole use of = the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender = by reply e-mail and delete all copies of this = message.


------=_NextPart_002_0527_01CB1D0D.89A344B0-- ------=_NextPart_001_0526_01CB1D0D.89A344B0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_0526_01CB1D0D.89A344B0 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAU5SURBVFjD xVdbTFNZFL1FFE3UoBgFBBQqIi/xEQUN+mEiH/7ph4kJmpAQlRiN/mGCMSSDDqLOgEAfNIC0PFpb ecdIeavgoCMQOgzC8BYQ5SnIU1hzz7mXRwdayFBmbrOa3ra5e5191l57Hwb/88WY8mEN3xqQ8DEB sioZMloyMDA+8N8QGPsxhq+jX3G/8j5s5DbYFr0NPuk+0DRqKInJqcnVJVD2uQzX31yHs9wZzK8M mAcsYhgcUx+jpFqGWlaXgPaTFufyzsE+3h6MiA0ezcBCbAEXhQtult1E/UD96hLoHulGaVcpAosC YS41B/OIwS7FLoS9D0NlTyWGJ4ZXl8DQxBCKO4sRUBDAEXjMwEHugNCKUFT1Vq2eCH9M/6CrU/2l womsE9gq3QqBWEC3YZ1oHazjreFf6I+KLxUYmRzB9PS0aQk0DDYg7EMYfJ75UNExkSzELKScCIkg N0o24kzuGSR+TMTg+KBpCVT3ViOwJBCOTx1hLjbnBCjhQYiw95vEm+CW5oZ7H+6hd6zXtAT6x/tR 3l2O4PJgWCdZg3nCB5bwGWBxWH0Y0bpo6Pp0GJ8aNy2BafZFRBbyNgQ2STaLEjiiPgJJrQRN35pM J0IiJrIaYkDnteexQ7YDgljBoltgEWsBe7k9bv92G+3D7ZiYmlg5AWK7sjoZ/LL9wESxge4ztPbp qiW8CAmBJ7wr/szAMs4SAcUBeNH2AlPTUysjQMQU8i4EXmle8Ej2gIfKA57PPGkfEEjYTMQyWC9b D8cUR/q9u9IdngpPHM84jqT6JNNogFRAdnM2CtoKUNJVgsLOQlx5dWXWCXen7EZ4ZTj9raSzBHkt echty0XrUKs+gezWbGiaNFDUKyg7eb0c6iY1yPeGkNuai/xP+dR+Z0CckBKImyPwoOqB3n8okfY8 vWcxzmnOcFG6wFXlin3Kfdibthd7UvfAKcXJIISpQrgqXeHxzEMP25O2c3sfw22BU6oTDqgPzMJL 7QU3lRtIzBkwTAQDu2Q7BL0Kwq2yW7hYdBFbErdwwvqJE9Cy8ZB3QxEvwmjODY2CNA6/HD8UdBTg 88hn9I314c67OxCmCCF8KqSrNQQiMjuFHRWfrdyWfrZV2MJCZsFVxBOeRDRfIaJFQH4UJglxqfAS ijqKqDA6v3dC266FtlVLe70hkJJ63vwcqkbVLIjp+Gb6cpkgpRnFI2aeSc0HfeP/cPblWWS1ZFHB EIs1iC4WneW0Gf3zIuOX6A8RTuecxul0FrkcSMZIeeq55SyBWI7A5vjNVIyHNIfgne5tGGoWSm9c Lb26KIkvo1+g69VB16OjPYCAbCvVVhSj75izzjXj35HLwGNOcJYyS1wuvoyc1pwlJ+Ca3hqEVITg qPIozCRmc66ptx9iA0IxBHY1ghgBLhRcQONg45LmReaB4LfBnFfMzA4LRLFckKz9wiKcwcmsk6jr r1uWg0ZUR2CtbC1Xgv+KQCwvWnYFZjFmcE91x933d9Ex3GE0cNf3Llpl/vn+WCNdMydGo8HEi0DE K5kl4KZ0Q1xtHO315HBi7NI0a3Aq+xSsZdazc+NCDUgWaaeRvGM94u73q/cjqDgI14quIbImEj1j PctKPWnf1KAe8ouQGiPABidpImVp9dQKVokspFZwSHagJ52e0R4MjA1geHJ4ycBkACGjG2lMlgmW 3GIWlOF88CebnYqduPHmBqR/SiGtZVEjpZOtsVOOofIL/T0UvmpfbIjbwGlIbIxALJfyg5qDeN31 esWHlszmTNgns0e2CN5npPrx/gbw8N1A6QE+ygAAAABJRU5ErkJggg== ------=_NextPart_001_0526_01CB1D0D.89A344B0-- ------=_NextPart_000_0525_01CB1D0D.89A344B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwNjExMTcwOVowIwYJKoZIhvcNAQkEMRYEFMbLXoxB0bEqDXc1 Lcuglt+7QTGTMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAh8cf1bL+PRb2OoXH53+z+IK3n5rvvGXH jccmAO8I95wlsdfU5twfEndoniy31H1mAqmaKf3rxU9f9hI4rpKqSSAb2zMfk8DDsGnBVcFm+iTs Bs8tZpKyOdV5xhwz6U65FQ+MoVGYnyxQs+cq+ff7nbBn7+2fI4+CdfjE7seRCgIAAAAAAAA= ------=_NextPart_000_0525_01CB1D0D.89A344B0-- From jpv@cisco.com Tue Jul 6 04:40:16 2010 Return-Path: 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 C78123A6876 for ; Tue, 6 Jul 2010 04:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.396 X-Spam-Level: X-Spam-Status: No, score=-9.396 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 HIgbWpaRs3g2 for ; Tue, 6 Jul 2010 04:40:15 -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 DFB793A686C for ; Tue, 6 Jul 2010 04:40:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACqzMkxAZnwM/2dsb2JhbACBQ51kXXGkT5orAoUjBIg6giw X-IronPort-AV: E=Sophos;i="4.53,545,1272844800"; d="scan'208,217";a="129053061" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2010 11:40:16 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o66BeBur027549 for ; Tue, 6 Jul 2010 11:40:13 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 13:40:12 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 13:40:11 +0200 Message-Id: From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE02725921@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-124--538499636 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Jul 2010 13:40:10 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE02725921@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Jul 2010 11:40:11.0822 (UTC) FILETIME=[FE42CCE0:01CB1CFF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17488.006 X-TM-AS-Result: No--44.179300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Transit and Target address mismatch 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: , X-List-Received-Date: Tue, 06 Jul 2010 11:40:16 -0000 --Apple-Mail-124--538499636 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable since I saw this request several times, I have opened a ticket to =20 clarify. On Jul 6, 2010, at 1:17 PM, Mathilde Durvy (mdurvy) wrote: > Hi All, > > Let=92s consider the storing mode in a simple topology A=E0B=E0R (=E0 = mark =20 > the parent relationship). Let=92s also assume that A has a prefix =91Ap=92= =20 > and a global address =91Ag=92 to advertise. > In this example we have: > - A sends DAO with =93target Ag, Ap, transit B=94 > - B sends DAO with =93target Bg, transit R=94 together with the =20 > information from A, i.e. =93target Ag, Ap, transit B=94 > > Then R recombines the information to get the route to for example Ap =20= > (Target Ap, transit B, target Bg, transit R) > For this to work, transit B and target Bg need to be matched. How =20 > can this be done? Does it mean that the transit parent address has =20 > to be a global address? This would imply that we use global =20 > addresses in the routing header. However 6man-rpl-routing-header says: > =93When processing the Type 4 Routing header, a router MUST drop the =20= > packet if the next entry is not on-link=94 > As global addresses have to be off-link in NBMA network like =20 > 802.15.4, I see a problem=85 > > Can you please clarify how addresses are supposed to be used in this =20= > source-routing scenario. > > Thanks, > Mathilde > > > > > Durvy Mathilde > Software Engineer > Technology center > > mdurvy@cisco.com > Phone: +41 21 822 1725 > Mobile: +41 76 396 8116 > Cisco Systems International S=E0rl > Av. des Uttins, 5 > CH-1180 Rolle > > Cisco home page > > > Think before you print. > This e-mail may contain confidential and privileged material for the =20= > sole use of the intended recipient. Any review, use, distribution or =20= > disclosure by others is strictly prohibited. If you are not the =20 > intended recipient (or authorized to receive for the recipient), =20 > please contact the sender by reply e-mail and delete all copies of =20 > this message. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-124--538499636 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable since I saw this request = several times, I have opened a ticket to clarify.

On = Jul 6, 2010, at 1:17 PM, Mathilde Durvy (mdurvy) wrote:

Hi All,
Let=92s consider the storing mode in a = simple topology A=E0B=E0R (=E0 mark the parent = relationship). Let=92s also assume that A has a prefix =91Ap=92 and a = global address =91Ag=92 to advertise.
In = this example we have:
- A sends DAO with =93target Ag, = Ap, transit B=94
- B sends DAO with =93target Bg, = transit R=94 together with the information from A, i.e. =93target Ag, = Ap, transit B=94
 
For = this to work, transit B and target Bg need to be matched. How can this = be done? Does it mean that the transit parent address has to be a global = address? This would imply that we use global addresses in the routing = header. However 6man-rpl-routing-header says:
 on-link=94<= /div>
As global addresses have to be off-link in NBMA network = like 802.15.4, I see a problem=85
Can you please clarify how addresses = are supposed to be used in this source-routing = scenario.
 
Mathilde
 
<image001.gif>
Durvy Mathilde
Software EngineerTechnology center

 +41 21 822 = 1725
Mobile: +41 76 396 = 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home = page

Think before you = print.
This e-mail may contain confidential and privileged material for = the sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this = message.

______________________________= _________________
Roll mailing list
X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 06 Jul 2010 11:41:09 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/56 Message-ID: <055.1533bd03f4c151786a54d1047fc43e73@tools.ietf.org> X-Trac-Ticket-ID: 56 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #56: Transit and Target address mismatch X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 11:41:09 -0000 #56: [Roll] Transit and Target address mismatch -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Hi All, Let’s consider the storing mode in a simple topology AàBàR (à mark the parent relationship). Let’s also assume that A has a prefix ‘Ap’ and a global address ‘Ag’ to advertise. In this example we have: - A sends DAO with “target Ag, Ap, transit B†- B sends DAO with “target Bg, transit R†together with the information from A, i.e. “target Ag, Ap, transit B†Then R recombines the information to get the route to for example Ap (Target Ap, transit B, target Bg, transit R) For this to work, transit B and target Bg need to be matched. How can this be done? Does it mean that the transit parent address has to be a global address? This would imply that we use global addresses in the routing header. However 6man-rpl-routing-header says: “When processing the Type 4 Routing header, a router MUST drop the packet if the next entry is not on-link†As global addresses have to be off-link in NBMA network like 802.15.4, I see a problem… Can you please clarify how addresses are supposed to be used in this source-routing scenario. Thanks, Mathilde -- Ticket URL: roll From pthubert@cisco.com Tue Jul 6 05:55:47 2010 Return-Path: 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 D113A3A6863 for ; Tue, 6 Jul 2010 05:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 uQnTrszRkeyX for ; Tue, 6 Jul 2010 05:55:41 -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 478823A6900 for ; Tue, 6 Jul 2010 05:55:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.png : 837, 1465 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcKAMnEMkxAZnwM/2dsb2JhbABzUJ5DcaU3mioChSMEimY X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="129073499" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2010 12:55:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o66CtYUj001756 for ; Tue, 6 Jul 2010 12:55:42 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 14:55:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB1D0A.8A7D09F0" Date: Tue, 6 Jul 2010 14:55:39 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Transit and Target address mismatch thread-index: AcsdCoejDG6UKjQ3Ta2pAgc9CJPsdA== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 06 Jul 2010 12:55:42.0156 (UTC) FILETIME=[8A8CE8C0:01CB1D0A] Subject: Re: [Roll] Transit and Target address mismatch 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: , X-List-Received-Date: Tue, 06 Jul 2010 12:55:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1D0A.8A7D09F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB1D0A.8A7D09F0" ------_=_NextPart_002_01CB1D0A.8A7D09F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde: =20 Yes we can improve the text : ) =20 Yes, all the RH are based on global addresses. I tend to think that the = non-storing mode should even use global addresses as source / = destination for DAO/DAO_ACK so nodes talk directly to the root as = opposed to sending DAOs hop by hop. =20 And no, global addresses are not off link. They are not expected to be = all onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a = strict source routing. So a node should be able to NS those addresses to = assert continuous connectivity. =20 One even more tricky thing is the use of IP in IP that seems to be = generalized now as soon as we insert a RH or a HbH option. I think that = the resolution of your issue should also clearly state what are the = tunnel endpoints, in particular when the destination on the RPL side is = a dumb host. RPL should be able to differentiate the last router from = the target. =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 1:17 PM To: ROLL WG Subject: [Roll] Transit and Target address mismatch =20 Hi All, =20 Let's consider the storing mode in a simple topology A=E0B=E0R (=E0 mark = the parent relationship). Let's also assume that A has a prefix 'Ap' and = a global address 'Ag' to advertise. In this example we have: - A sends DAO with "target Ag, Ap, transit B" - B sends DAO with "target Bg, transit R" together with the information = from A, i.e. "target Ag, Ap, transit B" =20 Then R recombines the information to get the route to for example Ap = (Target Ap, transit B, target Bg, transit R) For this to work, transit B and target Bg need to be matched. How can = this be done? Does it mean that the transit parent address has to be a = global address? This would imply that we use global addresses in the = routing header. However 6man-rpl-routing-header says: "When processing the Type 4 Routing header, a router MUST drop the = packet if the next entry is not on-link" As global addresses have to be off-link in NBMA network like 802.15.4, I = see a problem... =20 Can you please clarify how addresses are supposed to be used in this = source-routing scenario. =20 Thanks, Mathilde =20 =20 =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. ------_=_NextPart_002_01CB1D0A.8A7D09F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Mathilde:

 

Yes we can = improve the text : )

 

Yes, all the = RH are based on global addresses. I tend to think that the non-storing = mode should even use global addresses as source / destination for = DAO/DAO_ACK so nodes talk directly to the root as opposed to sending = DAOs hop by hop.

 

And no, = global addresses are not off link. =A0They are not expected to be all = onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a = strict source routing. So a node should be able to NS those addresses to = assert continuous connectivity.

 

One even more = tricky thing is the use of IP in IP that seems to be generalized now as = soon as we insert a RH or a HbH option. I think that the resolution of = your issue should also clearly state what are the tunnel endpoints, in = particular when the destination on the RPL side is a dumb host. RPL = should be able to differentiate the last router from the = target.

 

Cheers,

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 1:17 = PM
To: ROLL WG
Subject: [Roll] Transit and Target = address mismatch

 

Hi = All,

 

Let’s consider the storing mode in a simple = topology A=E0B=E0R (=E0 mark the parent = relationship). Let’s also assume that A has a prefix = ‘Ap’ and a global address ‘Ag’ to = advertise.

In this example we = have:

- A sends DAO with = “target Ag, Ap, transit B”

- B sends DAO with “target Bg, transit R” = together with the information from A, i.e. “target Ag, Ap, transit = B”

 

Then R recombines the information to get the route to = for example Ap (Target Ap, transit B, target Bg, transit = R)

For this to work, transit B and = target Bg need to be matched. How can this be done? Does it mean that = the transit parent address has to be a global address? This would imply = that we use global addresses in the routing header. However = 6man-rpl-routing-header says:

“When processing the Type 4 Routing header, a = router MUST drop the packet if the next entry is not = on-link”

As global = addresses have to be off-link in NBMA network like 802.15.4, I see a = problem…

 

Can you = please clarify how addresses are supposed to be used in this = source-routing scenario.

 

Thanks,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy Mathilde
Software = Engineer
Technology center

mdurvy@cisco.com
Phone: +41 21 = 822 1725
Mobile: +41 76 396 = 8116

Cisco Systems International = S=E0rl
Av. = des Uttins, 5
CH-1180 Rolle

Cisco home = page

 

 

3D"ThinkThink before you print.

This e-mail may contain = confidential and privileged material for the sole use of the intended = recipient. Any review, use, distribution or disclosure by others is = strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this = message.


------_=_NextPart_002_01CB1D0A.8A7D09F0-- ------_=_NextPart_001_01CB1D0A.8A7D09F0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CB1D0A.8A7D09F0 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAU5SURBVFjD xVdbTFNZFL1FFE3UoBgFBBQqIi/xEQUN+mEiH/7ph4kJmpAQlRiN/mGCMSSDDqLOgEAfNIC0PFpb ecdIeavgoCMQOgzC8BYQ5SnIU1hzz7mXRwdayFBmbrOa3ra5e5191l57Hwb/88WY8mEN3xqQ8DEB sioZMloyMDA+8N8QGPsxhq+jX3G/8j5s5DbYFr0NPuk+0DRqKInJqcnVJVD2uQzX31yHs9wZzK8M mAcsYhgcUx+jpFqGWlaXgPaTFufyzsE+3h6MiA0ezcBCbAEXhQtult1E/UD96hLoHulGaVcpAosC YS41B/OIwS7FLoS9D0NlTyWGJ4ZXl8DQxBCKO4sRUBDAEXjMwEHugNCKUFT1Vq2eCH9M/6CrU/2l womsE9gq3QqBWEC3YZ1oHazjreFf6I+KLxUYmRzB9PS0aQk0DDYg7EMYfJ75UNExkSzELKScCIkg N0o24kzuGSR+TMTg+KBpCVT3ViOwJBCOTx1hLjbnBCjhQYiw95vEm+CW5oZ7H+6hd6zXtAT6x/tR 3l2O4PJgWCdZg3nCB5bwGWBxWH0Y0bpo6Pp0GJ8aNy2BafZFRBbyNgQ2STaLEjiiPgJJrQRN35pM J0IiJrIaYkDnteexQ7YDgljBoltgEWsBe7k9bv92G+3D7ZiYmlg5AWK7sjoZ/LL9wESxge4ztPbp qiW8CAmBJ7wr/szAMs4SAcUBeNH2AlPTUysjQMQU8i4EXmle8Ej2gIfKA57PPGkfEEjYTMQyWC9b D8cUR/q9u9IdngpPHM84jqT6JNNogFRAdnM2CtoKUNJVgsLOQlx5dWXWCXen7EZ4ZTj9raSzBHkt echty0XrUKs+gezWbGiaNFDUKyg7eb0c6iY1yPeGkNuai/xP+dR+Z0CckBKImyPwoOqB3n8okfY8 vWcxzmnOcFG6wFXlin3Kfdibthd7UvfAKcXJIISpQrgqXeHxzEMP25O2c3sfw22BU6oTDqgPzMJL 7QU3lRtIzBkwTAQDu2Q7BL0Kwq2yW7hYdBFbErdwwvqJE9Cy8ZB3QxEvwmjODY2CNA6/HD8UdBTg 88hn9I314c67OxCmCCF8KqSrNQQiMjuFHRWfrdyWfrZV2MJCZsFVxBOeRDRfIaJFQH4UJglxqfAS ijqKqDA6v3dC266FtlVLe70hkJJ63vwcqkbVLIjp+Gb6cpkgpRnFI2aeSc0HfeP/cPblWWS1ZFHB EIs1iC4WneW0Gf3zIuOX6A8RTuecxul0FrkcSMZIeeq55SyBWI7A5vjNVIyHNIfgne5tGGoWSm9c Lb26KIkvo1+g69VB16OjPYCAbCvVVhSj75izzjXj35HLwGNOcJYyS1wuvoyc1pwlJ+Ca3hqEVITg qPIozCRmc66ptx9iA0IxBHY1ghgBLhRcQONg45LmReaB4LfBnFfMzA4LRLFckKz9wiKcwcmsk6jr r1uWg0ZUR2CtbC1Xgv+KQCwvWnYFZjFmcE91x933d9Ex3GE0cNf3Llpl/vn+WCNdMydGo8HEi0DE K5kl4KZ0Q1xtHO315HBi7NI0a3Aq+xSsZdazc+NCDUgWaaeRvGM94u73q/cjqDgI14quIbImEj1j PctKPWnf1KAe8ouQGiPABidpImVp9dQKVokspFZwSHagJ52e0R4MjA1geHJ4ycBkACGjG2lMlgmW 3GIWlOF88CebnYqduPHmBqR/SiGtZVEjpZOtsVOOofIL/T0UvmpfbIjbwGlIbIxALJfyg5qDeN31 esWHlszmTNgns0e2CN5npPrx/gbw8N1A6QE+ygAAAABJRU5ErkJggg== ------_=_NextPart_001_01CB1D0A.8A7D09F0-- From daniel.gavelle@jennic.com Tue Jul 6 06:05:21 2010 Return-Path: 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 37CB73A6863 for ; Tue, 6 Jul 2010 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 R4rKh5u4NaYd for ; Tue, 6 Jul 2010 06:05:20 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id C2BE93A6896 for ; Tue, 6 Jul 2010 06:05:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 1888B9BE511; Tue, 6 Jul 2010 14:05:21 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2GoBx7em1Xc; Tue, 6 Jul 2010 14:05:21 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id D44E69BE508; Tue, 6 Jul 2010 14:05:20 +0100 (BST) Message-ID: <4C332A10.1090202@jennic.com> Date: Tue, 06 Jul 2010 14:05:20 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Transit and Target address mismatch X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 13:05:21 -0000 I like the idea of sending a DAO directly from the node to the root in a non storing network. This avoids the DAO travelling up the tree a hop at a time with an ack for each hop. We wouldn't need a type 4 routing header in the packet as the direction of travel is up the DAG. The global IP address of the root would need to be distributed in the DIS if DAO's' could travel directly to the root in this way. Currently, the DODAG ID does not have to be the IP address of the root but can be any unique identifier. We could either define the DODAG ID to be the IP address of the root or add another field / option to the DIS with the global IP address of the root. Daniel. Pascal Thubert (pthubert) wrote: > Hi Mathilde: > > > Yes we can improve the text : ) > > > > Yes, all the RH are based on global addresses. I tend to think that the > non-storing mode should even use global addresses as source / > destination for DAO/DAO_ACK so nodes talk directly to the root as > opposed to sending DAOs hop by hop. > > > > And no, global addresses are not off link. They are not expected to be > all onlink for the purpose of ND lookup, but some may be. And this text > expects that those used for RH are effectively onlink to enforce a > strict source routing. So a node should be able to NS those addresses to > assert continuous connectivity. > > > > One even more tricky thing is the use of IP in IP that seems to be > generalized now as soon as we insert a RH or a HbH option. I think that > the resolution of your issue should also clearly state what are the > tunnel endpoints, in particular when the destination on the RPL side is > a dumb host. RPL should be able to differentiate the last router from > the target. > > > > Cheers, > > > > Pascal > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Mathilde Durvy (mdurvy) > *Sent:* Tuesday, July 06, 2010 1:17 PM > *To:* ROLL WG > *Subject:* [Roll] Transit and Target address mismatch > > > > Hi All, > > > > Let’s consider the storing mode in a simple topology AàBàR (à mark the > parent relationship). Let’s also assume that A has a prefix ‘Ap’ and a > global address ‘Ag’ to advertise. > > In this example we have: > > - A sends DAO with “target Ag, Ap, transit B” > > - B sends DAO with “target Bg, transit R” together with the information > from A, i.e. “target Ag, Ap, transit B” > > > > Then R recombines the information to get the route to for example Ap > (Target Ap, transit B, target Bg, transit R) > > For this to work, transit B and target Bg need to be matched. How can > this be done? Does it mean that the transit parent address has to be a > global address? This would imply that we use global addresses in the > routing header. However 6man-rpl-routing-header says: > > “When processing the Type 4 Routing header, a router MUST drop the > packet if the next entry is not *on-link*” > > As global addresses have to be off-link in NBMA network like 802.15.4, I > see a problem… > > > > Can you please clarify how addresses are supposed to be used in this > source-routing scenario. > > > > Thanks, > > Mathilde > > > > > > > > http://www.cisco.com/swa/i/logo.gif > > *Durvy Mathilde* > *Software Engineer* > *Technology center > * > mdurvy@cisco.com > Phone: *+41 21 822 1725* > Mobile: *+41 76 396 8116* > > > > *Cisco Systems International Sàrl* > Av. des Uttins, 5 > CH-1180 Rolle > > Cisco home page > > > > > > > > Think before you print.Think before you print. > > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply e-mail and delete all copies of this message. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From mdurvy@cisco.com Tue Jul 6 06:25:06 2010 Return-Path: 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 06C033A6937 for ; Tue, 6 Jul 2010 06:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.588 X-Spam-Level: X-Spam-Status: No, score=-8.588 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 KXW9J4QuGFAA for ; Tue, 6 Jul 2010 06:24:56 -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 EBC143A6838 for ; Tue, 6 Jul 2010 06:24:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMbLMkxAZnwN/2dsb2JhbACBQ55IcaVKmjKFJQSKZg X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="txt'?p7s'?scan'208,217";a="129086990" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Jul 2010 13:24:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66DOtZ9021865 for ; Tue, 6 Jul 2010 13:24:57 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 15:24:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jul 2010 15:24:53 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05CF_01CB1D1F.61A758E0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE027259F4@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Transit information option Thread-Index: AcsJhLJHxdDfg9wLSmuqz7gXSlthMgFPic1gA4iqzJA= From: "Mathilde Durvy (mdurvy)" To: "ROLL WG" X-OriginalArrivalTime: 06 Jul 2010 13:24:56.0023 (UTC) FILETIME=[9FEFC670:01CB1D0E] Subject: [Roll] FW: Transit information option 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: , X-List-Received-Date: Tue, 06 Jul 2010 13:25:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05CF_01CB1D1F.61A758E0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_05D0_01CB1D1F.61A758E0" ------=_NextPart_001_05D0_01CB1D1F.61A758E0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_05D1_01CB1D1F.61A758E0" ------=_NextPart_002_05D1_01CB1D1F.61A758E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I didn't see these comments addressed in the new draft. Any reason? For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option Hi All, I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. Best, Mathilde From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: Hi Phil, Thanks a lot for your answer. Here are my comments: A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? These are good questions. Currently the draft is a bit unclear on whether 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice. Similar to Phil I'm getting worried about the increased complexity. But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? ICMP error. Phil ------=_NextPart_002_05D1_01CB1D1F.61A758E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I didn’t see these comments addressed in the new draft. Any reason? =

For point 2, I would go even further and propose to put the path sequence, = control, and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add that the sentence “In a DIO, the RPL Target Option = identifies a resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi All,

 

I just looked at the updated draft and most of the comments = below have been addresses / clarified. Just a few rather minor = points:

- Section 5.7.7. RPL Target. Based on the discussion below I = would change “A set of one or more Transit Information options MAY = directly follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- If the Path-Sequence / Control fields are indeed used both = in storing (where I have doubts they are really needed) and non-storing = mode, why not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length option.

 

Best,

Mathilde

 

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy = (mdurvy) wrote:

 

Hi Phil,

 

Thanks a lot for your answer. Here are my = comments:

 =

A few items that might be worth clarifying in version = 09:

- “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path sequence / control = / lifetime are not specified (which seems to contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. = Storing mode seems like it is a MUST as well...

I think we all = agree.

- “A non-storing node that has more than one DAO parent MAY include = a Transit Information option for each DAO parent as part of the = non-storing Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn’t he send one DAO with transit information A (i.e. parent = address =3D A) to DAO parent A and another DAO with transit information B to DAO = parent B? Otherwise how this would work over multiple hop? Maybe an example of = DAO would help.

- In section 7.1.5 point 2, I assume the node should add a transit = information with its parent before passing the content of the received DAO. Also do = the operation specified on the path control field in the previous section = for storing node also apply in the non-storing case?

 

These are good questions. Currently the draft is a = bit unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, or 

2) the DODAG Root receives just the last downward = hops of each node, and stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that = if it's 2), then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are your = thoughts?

 

Indeed, I think the = current draft is a bit unclear. My interpretation when reading was 1 (probably due = mostly to the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for explaining.

What triggered this = change?

It seems to me that if = proper aggregation of the routes is performed (in particular if in the record = route case you can avoid transmitting routes which are sub-routes of others) = the two schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit on = the topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.

Also concerning your = last comment, I agree. The DAO produced will be slightly larger but we send only one = DAO instead of one DAO per DAO parent. I think if we do that we might not = really need the path control field, correct?

 

-09 has a rewrite of the Downward Routes section = that should make all of this much clearer. The answer is 2), for reasons Richard = brought up a few months ago. In particular, if you use 1), then when a node changes = its parent set it entire sub-DODAG must resend DAOs. This is a significant = cost. If you use 2), then only that node needs to send a new DAO.

 

 

 

- Has the advantage of having multiple DAO parents been assessed with = respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent = set. The concern is that the vagaries and unreliability of wireless links call = for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward = routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger = to the entire sub-DODAG.

I understand how this would work in the storing case but in = the non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------=_NextPart_002_05D1_01CB1D1F.61A758E0-- ------=_NextPart_001_05D0_01CB1D1F.61A758E0 Content-Type: text/plain; name="ATT515460.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT515460.txt" _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_001_05D0_01CB1D1F.61A758E0-- ------=_NextPart_000_05CF_01CB1D1F.61A758E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwNjEzMjQ1MlowIwYJKoZIhvcNAQkEMRYEFC9TQv160ERHeBPD In0s5QgPxOnTMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAakSfxHlm3Y0SWguNaUcXwPJ9pQCYmm5S 27tFZNlAzxhsS7RZW71ZICB3j9wh53pNLo0g14h9yCKcaO+IT4uIvblgW5BWYL21SSnDD9f7Qnrf IlZmZt8uY9gTYN9+sPrhm//83My72k22Ricj3GqkQDqxyeG0LbeV1GI0yfTMSJAAAAAAAAA= ------=_NextPart_000_05CF_01CB1D1F.61A758E0-- From pthubert@cisco.com Tue Jul 6 06:43:41 2010 Return-Path: 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 E25743A691B for ; Tue, 6 Jul 2010 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 9Jt5Pl8TLiFU for ; Tue, 6 Jul 2010 06:43:32 -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 D51993A6952 for ; Tue, 6 Jul 2010 06:43:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMPPMkxAZnwN/2dsb2JhbACBQ55JcaVpmjWFJQSKZg X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="scan'208,217";a="129235149" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2010 13:43:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66DhWrI000650 for ; Tue, 6 Jul 2010 13:43:33 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 15:43:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1D11.397F0390" Date: Tue, 6 Jul 2010 15:43:30 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243A8DD@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Transit information option thread-index: AcsdETbPrvyhawioRZaqXGJI+i24zg== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 06 Jul 2010 13:43:32.0756 (UTC) FILETIME=[398FB540:01CB1D11] Subject: Re: [Roll] FW: Transit information option 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: , X-List-Received-Date: Tue, 06 Jul 2010 13:43:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1D11.397F0390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mathilde: =20 Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. =20 We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+.=20 =20 I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router.=20 =20 What do you think? =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option =20 Hi All, =20 I didn't see these comments addressed in the new draft. Any reason?=20 For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. =20 Best, Mathilde =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 Hi All, =20 I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. =20 Best, Mathilde =20 =20 From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 =20 On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: =20 Hi Phil, =20 Thanks a lot for your answer. Here are my comments: =20 A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address =3D A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? =20 These are good questions. Currently the draft is a bit unclear on whether=20 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or=20 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information.=20 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? =20 Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? =20 -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. =20 =20 =20 - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice... Similar to Phil I'm getting worried about the increased complexity. =20 But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? =20 ICMP error. =20 Phil ------_=_NextPart_001_01CB1D11.397F0390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mathilde:

 

Pls note that the target identifies the final destination and the = transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. AS Phil = pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode to indicate = the tunnel end point for targets outside the RPL network, like the = proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 = PM
To: ROLL WG
Subject: [Roll] FW: Transit = information option

 

Hi = All,

 

I = didn’t see these comments addressed in the new draft. Any reason? =

For point 2, = I would go even further and propose to put the path sequence, control, = and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add = that the sentence “In a DIO, the RPL Target Option identifies a = resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 = 11:09
To: Philip Levis
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi= All,

 

I = just looked at the updated draft and most of the comments below have = been addresses / clarified. Just a few rather minor = points:

- = Section 5.7.7. RPL Target. Based on the discussion below I would change = “A set of one or more Transit Information options MAY directly = follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- = If the Path-Sequence / Control fields are indeed used both in storing = (where I have doubts they are really needed) and non-storing mode, why = not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode = and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length = option.

 

Be= st,

Ma= thilde

 

 

From:= = Philip Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. = juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On = Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) = wrote:

 

Hi= Phil,

&n= bsp;

Th= anks a lot for your answer. Here are my = comments:

 =

A few items = that might be worth clarifying in version = 09:

- = “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path = sequence / control / lifetime are not specified (which seems to = contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing = mode seems like it is a MUST as well...

I = think we all = agree.

- “A = non-storing node that has more than one DAO parent MAY include a Transit = Information option for each DAO parent as part of the non-storing = Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A = and B) shouldn’t he send one DAO with transit information A (i.e. = parent address =3D A) to DAO parent A and another DAO with transit = information B to DAO parent B? Otherwise how this would work over = multiple hop? Maybe an example of DAO would = help.

- In section = 7.1.5 point 2, I assume the node should add a transit information with = its parent before passing the content of the received DAO. Also do the = operation specified on the path control field in the previous section = for storing node also apply in the non-storing = case?

 

These are good questions. Currently the draft is a bit = unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, = or 

2) the = DODAG Root receives just the last downward hops of each node, and = stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that if = it's 2), then in non-storing mode node needs to send a DAO to just one = DAO parent, and this DAO can contain the full set of last-hops. What are = your thoughts?

 

Indeed, I think the current = draft is a bit unclear. My interpretation when reading was 1 (probably = due mostly to the history of the draft). Now from your comments I = understand what the draft is proposing, namely 2. Thanks for = explaining.

What triggered this = change?

It seems to me that if proper aggregation of the = routes is performed (in particular if in the record route case you can = avoid transmitting routes which are sub-routes of others) the two = schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit = on the topology. What is quite clear is that 2 requires more processing = power than 1 as it needs to reassemble routes from the received = information.

Also concerning your last comment, I agree. The DAO = produced will be slightly larger but we send only one DAO instead of one = DAO per DAO parent. I think if we do that we might not really need the = path control field, = correct?

 

-09 has a rewrite of the Downward Routes section that = should make all of this much clearer. The answer is 2), for reasons = Richard brought up a few months ago. In particular, if you use 1), then = when a node changes its parent set it entire sub-DODAG must resend DAOs. = This is a significant cost. If you use 2), then only that node needs to = send a new DAO.

 

 

<= p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'> 

=

- Has the = advantage of having multiple DAO parents been assessed with respect to = the added complexity? One could argue that since we take so much care in = selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent set. = The concern is that the vagaries and unreliability of wireless links = call for supporting some degree of path diversity. Most protocols today = maintain multiple candidate next hops for this exact reason. Because = downward routes start at the endpoints, there needs to be some way to = establish multiple routes. Otherwise, when one link breaks and you have = to issue a trigger to the entire sub-DODAG.

I = understand how this would work in the storing case but in the = non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------_=_NextPart_001_01CB1D11.397F0390-- From mdurvy@cisco.com Tue Jul 6 07:47:11 2010 Return-Path: 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 669EB3A6946 for ; Tue, 6 Jul 2010 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.691 X-Spam-Level: X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 pf4wgXrZMf-k for ; Tue, 6 Jul 2010 07:47:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 87E423A693A for ; Tue, 6 Jul 2010 07:47:00 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIfeMkyrR7H+/2dsb2JhbACBQ55NcaYXmjuFJQSKZg X-IronPort-AV: E=Sophos;i="4.53,546,1272844800"; d="p7s'?scan'208,217";a="341374316" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2010 14:47:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66EkxUM013152 for ; Tue, 6 Jul 2010 14:47:02 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 16:46:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 Jul 2010 16:46:57 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05F4_01CB1D2A.D8D1C850" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE02725A97@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A8DD@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Transit information option Thread-Index: AcsdETbPrvyhawioRZaqXGJI+i24zgAB9yqw References: <6A2A459175DABE4BB11DE2026AA50A5D0243A8DD@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 06 Jul 2010 14:46:59.0437 (UTC) FILETIME=[168521D0:01CB1D1A] Subject: Re: [Roll] FW: Transit information option 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: , X-List-Received-Date: Tue, 06 Jul 2010 14:47:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05F4_01CB1D2A.D8D1C850 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05F5_01CB1D2A.D8D1C850" ------=_NextPart_001_05F5_01CB1D2A.D8D1C850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. Does this make sense? Best, Mathilde From: Pascal Thubert (pthubert) Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option Hi Mathilde: Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+. I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router. What do you think? Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option Hi All, I didn't see these comments addressed in the new draft. Any reason? For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option Hi All, I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. Best, Mathilde From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: Hi Phil, Thanks a lot for your answer. Here are my comments: A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? These are good questions. Currently the draft is a bit unclear on whether 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice. Similar to Phil I'm getting worried about the increased complexity. But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? ICMP error. Phil ------=_NextPart_001_05F5_01CB1D2A.D8D1C850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

My point is a bit different.

In storing mode, the transit information “parent = address” is not used. The only fields that are relevant in the transit = information are the path control, sequence, and lifetime, which actually relate to the = target prefix. So why not put these fields in the target option and use only = the transit option when we are in non-storing mode and hence need to specify a = parent address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing.

 

Does this make sense?

Best,

Mathilde

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination = and the transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. = AS Phil pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode = to indicate the tunnel end point for targets outside the RPL network, like = the proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information = option

 

Hi All,

 

I didn’t see these comments addressed in the new draft. Any reason? =

For point 2, I would go even further and propose to put the path sequence, = control, and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add that the sentence “In a DIO, the RPL Target Option = identifies a resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi All,

 

I just looked at the updated draft and most of the comments = below have been addresses / clarified. Just a few rather minor = points:

- Section 5.7.7. RPL Target. Based on the discussion below I = would change “A set of one or more Transit Information options MAY = directly follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- If the Path-Sequence / Control fields are indeed used both = in storing (where I have doubts they are really needed) and non-storing = mode, why not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode and the = target+transit option in non-storing mode. This would have the additional benefit of = making the parent address mandatory in the transit information option and thus = avoid a variable length option.

 

Best,

Mathilde

 

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy = (mdurvy) wrote:

 

Hi Phil,

 

Thanks a lot for your answer. Here are my = comments:

 =

A few items that might be worth clarifying in version = 09:

- “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path sequence / control = / lifetime are not specified (which seems to contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. = Storing mode seems like it is a MUST as well...

I think we all = agree.

- “A non-storing node that has more than one DAO parent MAY include = a Transit Information option for each DAO parent as part of the = non-storing Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn’t he send one DAO with transit information A (i.e. parent = address =3D A) to DAO parent A and another DAO with transit information B to DAO = parent B? Otherwise how this would work over multiple hop? Maybe an example of = DAO would help.

- In section 7.1.5 point 2, I assume the node should add a transit = information with its parent before passing the content of the received DAO. Also do = the operation specified on the path control field in the previous section = for storing node also apply in the non-storing case?

 

These are good questions. Currently the draft is a = bit unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, or 

2) the DODAG Root receives just the last downward = hops of each node, and stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that = if it's 2), then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are your = thoughts?

 

Indeed, I think the = current draft is a bit unclear. My interpretation when reading was 1 (probably due = mostly to the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for explaining.

What triggered this = change?

It seems to me that if = proper aggregation of the routes is performed (in particular if in the record = route case you can avoid transmitting routes which are sub-routes of others) = the two schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit on = the topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.

Also concerning your = last comment, I agree. The DAO produced will be slightly larger but we send only one = DAO instead of one DAO per DAO parent. I think if we do that we might not = really need the path control field, correct?

 

-09 has a rewrite of the Downward Routes section = that should make all of this much clearer. The answer is 2), for reasons Richard = brought up a few months ago. In particular, if you use 1), then when a node changes = its parent set it entire sub-DODAG must resend DAOs. This is a significant = cost. If you use 2), then only that node needs to send a new DAO.

 

 

 

- Has the advantage of having multiple DAO parents been assessed with = respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent = set. The concern is that the vagaries and unreliability of wireless links call = for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward = routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger = to the entire sub-DODAG.

I understand how this would work in the storing case but in = the non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------=_NextPart_001_05F5_01CB1D2A.D8D1C850-- ------=_NextPart_000_05F4_01CB1D2A.D8D1C850 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwNjE0NDY1N1owIwYJKoZIhvcNAQkEMRYEFFGgUnBStxOcmDz1 8TJh70Im+XEOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAPA3XzwMk1XywbzmpMGbIXlE/J4SD5bgm vNWzcQ+Y4fM8sCIIQwt4JCMERcKeOwjXPCLV1FCFieqN47EAf1QKo339n+Kom5KFkb+mfZnnQO6G zbfVkbj49cwk4ulT1SSyRXP32/tqTZgNNaJ6HQ2PKMOq9K4KEG1sMefCf0hgKz8AAAAAAAA= ------=_NextPart_000_05F4_01CB1D2A.D8D1C850-- From jonsmirl@gmail.com Tue Jul 6 08:15:26 2010 Return-Path: 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 8A6D13A69DA for ; Tue, 6 Jul 2010 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 mmcnMeM94t1N for ; Tue, 6 Jul 2010 08:15:25 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 43FDC3A6973 for ; Tue, 6 Jul 2010 08:15:25 -0700 (PDT) Received: by pwj1 with SMTP id 1so1374590pwj.31 for ; Tue, 06 Jul 2010 08:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/gu0TpjpcBHJ8rUIuIZSHh3YrY4StyWdurzGkUWNQ+c=; b=CJNZuhplU4ZbRwtmeO4mYoOT9Dbqsmsnvpq05wqR62S+L76JVH6bQwNRcHJwv1AM1c SLlDJEnAeqiGGUhVof7EdqXEFRneHe2+sojdPP9pJIqluZySf5dZQYwiVXeWxnyPQW3f 9hzH93EZX/6C6BzoBop5Wo2WHXIlDWJBvssKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SvEtioYz+lf2+tlptSPOdAt/3xlX1oMAaDPs5BLvs17A+TKg5sfkzHh1ctng1LbtNT p054dW2AEL/hak67KlGM1R3UD2OWcsZueouDPxCTI0Mn3m6HuM+vZ/MU3tthXdpZjDNN 9+Ze9DrYNZVsZPDeghDMUi+5knY0MO/D5Xf0Q= MIME-Version: 1.0 Received: by 10.142.147.7 with SMTP id u7mr5714658wfd.219.1278429313942; Tue, 06 Jul 2010 08:15:13 -0700 (PDT) Received: by 10.142.224.9 with HTTP; Tue, 6 Jul 2010 08:15:13 -0700 (PDT) Date: Tue, 6 Jul 2010 11:15:13 -0400 Message-ID: From: Jon Smirl To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Implementing gateway routers 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: , X-List-Received-Date: Tue, 06 Jul 2010 15:15:26 -0000 I've been working with the Contiki RPL implementation. There are two ways to make gateway routers.... Linux hosted - RPL runs on Linux and 802.15.4 device is treated as a serially attached radio peripheral MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to MCU/radio over SPI/USB. There are multiple gateways attached to the RPL network. Which of these two architectures is better to implement? The same hardware can be used for both models. The MCU can run a small program that makes it look like a serially attached radio. Are there any advantages in integrating RPL/6lowpan into Linux's networking code? The project has already been started (linux-zigbee), I'm trying to figure out which model to work further on. It's not obvious to me how these two models interact with multiple gateways to the RPL network. -- Jon Smirl jonsmirl@gmail.com From pal@cs.stanford.edu Tue Jul 6 09:38:50 2010 Return-Path: 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 1D47D3A68D6 for ; Tue, 6 Jul 2010 09:38:50 -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 OlK6SiP17gdu for ; Tue, 6 Jul 2010 09:38:48 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 99E9A3A67C0 for ; Tue, 6 Jul 2010 09:38:48 -0700 (PDT) Received: from dnab4046bc.stanford.edu ([171.64.70.188]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OWBAY-0003A0-Tq; Tue, 06 Jul 2010 09:38:51 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6F28AAF0-2C7A-4CFB-BB80-49AE448A4DED@cisco.com> Date: Tue, 6 Jul 2010 09:08:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85F3C46B-AD06-4E67-BD84-9D7E174A6536@cs.stanford.edu> References: <6F28AAF0-2C7A-4CFB-BB80-49AE448A4DED@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Cc: ROLL WG Subject: Re: [Roll] Request for slot ROLL WG Meeting 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: , X-List-Received-Date: Tue, 06 Jul 2010 16:38:51 -0000 On Jul 5, 2010, at 5:42 AM, JP Vasseur wrote: > Dear all, >=20 > Could you please let us as soon as possible if you would like to get a = slot for the ROLL WG meeting IETF-78. > Be aware that we may not be able to accommodate all requests since a = good part of the meeting will be given > to RPL. Some slots may thus be conditional (if time permits). I would like a 5 minute slot to present the latest updates to the = Trickle draft; there will be a -02 for IETF-78. Phil= From culler@cs.berkeley.edu Tue Jul 6 09:41:07 2010 Return-Path: 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 4C3AF3A67C0 for ; Tue, 6 Jul 2010 09:41:07 -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 cexFK5BlHo5F for ; Tue, 6 Jul 2010 09:41:06 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 801E53A6878 for ; Tue, 6 Jul 2010 09:41:06 -0700 (PDT) Received: from [10.10.64.50] (mesh-wlan-171-218.AirBears.Berkeley.EDU [136.152.171.218]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o66Gf8XN008160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 6 Jul 2010 09:41:09 -0700 (PDT) From: David Culler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 09:41:07 -0700 Message-Id: To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [Roll] LC RPL-10 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: , X-List-Received-Date: Tue, 06 Jul 2010 16:41:07 -0000 This email starts a WG Last Call on RPL-10 that will end on July 27 at = noon ET. Please send your comments to the authors and copy the chairs = and the mailing list. Thanks all.= From alexandru.petrescu@gmail.com Tue Jul 6 12:29:17 2010 Return-Path: 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 677653A6953 for ; Tue, 6 Jul 2010 12:29:17 -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 pFXf-PFRb-9L for ; Tue, 6 Jul 2010 12:29:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 480873A698C for ; Tue, 6 Jul 2010 12:29:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 84BB0940195 for ; Tue, 6 Jul 2010 21:29:12 +0200 (CEST) Message-ID: <4C338400.9030602@gmail.com> Date: Tue, 06 Jul 2010 21:29:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100706-1, 06/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Implementing gateway routers 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: , X-List-Received-Date: Tue, 06 Jul 2010 19:29:17 -0000 Hmm... this is interesting, let me try to picture to see if I understand correctly. (I am also listening to RPL expert implementation opinion). Le 06/07/2010 17:15, Jon Smirl a écrit : > I've been working with the Contiki RPL implementation. There are two > ways to make gateway routers.... > > Linux hosted - RPL runs on Linux and 802.15.4 device is treated as a > serially attached radio peripheral o antenna | | ------ PC bus ------ eth0 +---|802154|----------|Linux |--- |device| |"host"| ------ ------ To my speculative reading this would be a very easy way to go, because RPL implementation could have access to Linux's host memory and CPU ressources. I would try this first. > MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to > MCU/radio over SPI/USB. o antenna | | ------ USB ------ eth0 +---|MCU |----------|Linux |--- |device|PPP/SLIP |"host"| ------ ------ I see a need to take IP-over-serial into account. I think in this case the MCU should be able to have two interfaces: one on which it runs RPL and another (USB serial) on which it doesn't. And IP route between the two ("route -n" shows two distinctive routes, the one towards serial being probably the default). > There are multiple gateways attached to the RPL network. Hmm... if one wants to have these gateways interact on their egress, using some non-RPL protocol (ND, OSPF), then one would prefer to have the RPL implemented in the first figure... because it would be hard to make non-RPL implementations on the MCU. > Which of these two architectures is better to implement? The same > hardware can be used for both models. The MCU can run a small program > that makes it look like a serially attached radio. Could the MCU also implement non-RPL stuff: ND and OSPF to talk to the Linux "host"? > Are there any advantages in integrating RPL/6lowpan into Linux's > networking code? WEll sure there are, IMHO. At least if IPv6-over-802154 (6lowpan's RFC4944) is implemented in the main linux kernel trunk. > The project has already been started (linux-zigbee), I'm trying to > figure out which model to work further on. It's not obvious to me > how these two models interact with multiple gateways to the RPL > network. Just two cents worth. Alex From jonsmirl@gmail.com Tue Jul 6 13:07:10 2010 Return-Path: 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 2FC113A693B for ; Tue, 6 Jul 2010 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 LNM2b2cqLdYk for ; Tue, 6 Jul 2010 13:07:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id BCB303A6899 for ; Tue, 6 Jul 2010 13:07:08 -0700 (PDT) Received: by gyh3 with SMTP id 3so3590010gyh.31 for ; Tue, 06 Jul 2010 13:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=38zW1uGtV1YeUcZV1WMDObt9lFLlaIGY27hazsJGFdY=; b=EnC6DTB4HYuuvUWOJJGaIrLF6Jfo1y9lZ6zIiUl9N09IfqdkR3RTinStCTxkApMvbf yO+4oSrn5c61tIv/xYHxOZdshgYFLRWRWfwTGlTKhCnhqGSflvN0K2IH13pREtPeHVFD 58eehy+m825Y8CWMsx04IUKi5CR/P7YNyhNu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s4pKVXJCdSUoI6rLmm9oCQNBzv6RIyWzGcBkjujrIQdicNpgTAOWaRyM5t/Hli/Ir1 2meOg2FZhJ0JPCdsj5jE3TnvLzsAV+LKAio3kujUcq5AtKuNzOca1bXWD4jIBu8TO5tR 5uuUgYFlIplRTuCIAabXxiJqCGqHN2y0fwnmo= MIME-Version: 1.0 Received: by 10.229.251.67 with SMTP id mr3mr3034422qcb.215.1278446828054; Tue, 06 Jul 2010 13:07:08 -0700 (PDT) Received: by 10.229.97.132 with HTTP; Tue, 6 Jul 2010 13:07:06 -0700 (PDT) In-Reply-To: <4C338400.9030602@gmail.com> References: <4C338400.9030602@gmail.com> Date: Tue, 6 Jul 2010 16:07:06 -0400 Message-ID: From: Jon Smirl To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Implementing gateway routers 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: , X-List-Received-Date: Tue, 06 Jul 2010 20:07:10 -0000 On Tue, Jul 6, 2010 at 3:29 PM, Alexandru Petrescu wrote: > Hmm... this is interesting, let me try to picture to see if I understand > correctly. > > (I am also listening to RPL expert implementation opinion). > > Le 06/07/2010 17:15, Jon Smirl a =E9crit : >> >> I've been working with the Contiki RPL implementation. =A0There are two >> ways to make gateway routers.... There are two types of hardware involved: embedded CPU with SPI attached radio - like a Atmel RF230. USB sticks with microcontroller and radio The SPI radio has no microcontroller so it is forced to run 6lowpan/RPL on the Linux host. 6lowpan/RPL support has been partially implemented on Linux but the implement is not complete. The USB stick has a choice, it can pretend to be a dumb radio or it can run a full TCP/IP stack and talk to the host using SLIP/PPP. I have this type of hardware. >> >> Linux hosted - RPL runs on Linux and 802.15.4 device is treated as a >> =A0serially attached radio peripheral > > =A0 =A0 =A0 =A0o antenna > =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0| =A0 =A0------ =A0 PC bus =A0 ------ =A0eth0 > =A0 =A0 =A0 =A0+---|802154|----------|Linux |--- > =A0 =A0 =A0 =A0 =A0 =A0|device| =A0 =A0 =A0 =A0 =A0|"host"| > =A0 =A0 =A0 =A0 =A0 =A0 ------ =A0 =A0 =A0 =A0 =A0 =A0------ > > To my speculative reading this would be a very easy way to go, because > RPL implementation could have access to Linux's host memory and CPU > ressources. =A0I would try this first. > >> MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to >> MCU/radio over SPI/USB. > > =A0 =A0 =A0 =A0o antenna > =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0| =A0 =A0------ =A0 USB =A0 =A0 =A0------ =A0eth0 > =A0 =A0 =A0 =A0+---|MCU =A0 |----------|Linux |--- > =A0 =A0 =A0 =A0 =A0 =A0|device|PPP/SLIP =A0|"host"| > =A0 =A0 =A0 =A0 =A0 =A0 ------ =A0 =A0 =A0 =A0 =A0 =A0------ > > I see a need to take IP-over-serial into account. > > I think in this case the MCU should be able to have two interfaces: one > on which it runs RPL and another (USB serial) on which it doesn't. =A0And > IP route between the two ("route -n" shows two distinctive routes, the > one towards serial being probably the default). Contiki has already implemented a dual interface gateway - SLIP and 6lowpan= /RPL. It works fine with one gateway. > >> There are multiple gateways attached to the RPL network. > > Hmm... if one wants to have these gateways interact on their egress, > using some non-RPL protocol (ND, OSPF), then one would prefer to have > the RPL implemented in the first figure... because it would be hard to > make non-RPL implementations on the MCU. That's the core part of my question, how do you set up routing with multiple gateways when the gateways are using SLIP/PPP to talk to their host? If that's too hard to set up then the better option is to run 6lowpan/RPL on the host and treat the microcontroller like a dumb radio. > >> Which of these two architectures is better to implement? The same >> hardware can be used for both models. The MCU can run a small program >> that makes it look like a serially attached radio. > > Could the MCU also implement non-RPL stuff: ND and OSPF to talk to the > Linux "host"? > >> Are there any advantages in integrating RPL/6lowpan into Linux's >> networking code? > > WEll sure there are, IMHO. =A0At least if IPv6-over-802154 (6lowpan's > RFC4944) is implemented in the main linux kernel trunk. > >> The project has already been started (linux-zigbee), I'm trying to >> figure out which model to work further on. It's not obvious to me >> how these two models interact with multiple gateways to the RPL >> network. > > Just two cents worth. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 Jon Smirl jonsmirl@gmail.com From pthubert@cisco.com Wed Jul 7 00:22:38 2010 Return-Path: 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 A75AD3A6817 for ; Wed, 7 Jul 2010 00:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Hv3q29ISQvdi for ; Wed, 7 Jul 2010 00:22:27 -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 4C8EF3A657C for ; Wed, 7 Jul 2010 00:22:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAH/HM0ytJV2Y/2dsb2JhbACBQ55DcaUpmlyFJASKag X-IronPort-AV: E=Sophos;i="4.53,551,1272844800"; d="scan'208,217";a="129474928" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2010 07:22:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o677MBre004397 for ; Wed, 7 Jul 2010 07:22:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 09:21:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1DA5.0DAB2F90" Date: Wed, 7 Jul 2010 09:21:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243AA8F@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE02725A97@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Transit information option thread-index: AcsdETbPrvyhawioRZaqXGJI+i24zgAB9yqwAALfWSA= References: <6A2A459175DABE4BB11DE2026AA50A5D0243A8DD@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE02725A97@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 07 Jul 2010 07:21:44.0963 (UTC) FILETIME=[0DDDA530:01CB1DA5] Subject: Re: [Roll] FW: Transit information option 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: , X-List-Received-Date: Wed, 07 Jul 2010 07:22:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1DA5.0DAB2F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mathilde, =20 1) In storing mode, the transit information "parent address" is not used =20 You're correct on that with the current spec.=20 I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. =20 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. =20 In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. =20 Pascal =20 From: Mathilde Durvy (mdurvy)=20 Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option =20 Hi Pascal, =20 My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 Does this make sense? Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option =20 Hi Mathilde: =20 Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. =20 We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+.=20 =20 I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router.=20 =20 What do you think? =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option =20 Hi All, =20 I didn't see these comments addressed in the new draft. Any reason?=20 For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. =20 Best, Mathilde =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 Hi All, =20 I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. =20 Best, Mathilde =20 =20 From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 =20 On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: =20 Hi Phil, =20 Thanks a lot for your answer. Here are my comments: =20 A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address =3D A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? =20 These are good questions. Currently the draft is a bit unclear on whether=20 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or=20 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information.=20 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? =20 Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? =20 -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. =20 =20 =20 - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice... Similar to Phil I'm getting worried about the increased complexity. =20 But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? =20 ICMP error. =20 Phil ------_=_NextPart_001_01CB1DA5.0DAB2F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mathilde,

 

1)= In storing mode, the transit information “parent address” = is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing the info for = the tunnel endpoint and that it might become handy to indicate a RPL = router to which a target host is attached.

 

2)    He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

We want to factorise: in non-storing mode, the target can have = multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can place multiple = targets for all its addresses and then only one transit info that is = common to them all.

 

Pascal

 

From:= Mathilde = Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 = PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: = RE: [Roll] FW: Transit information = option

 

Hi= Pascal,

 

My= point is a bit different.

In= storing mode, the transit information “parent address” is = not used. The only fields that are relevant in the transit information = are the path control, sequence, and lifetime, which actually relate to = the target prefix. So why not put these fields in the target option and = use only the transit option when we are in non-storing mode and hence = need to specify a parent address?

He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

Do= es this make sense?

Be= st,

Ma= thilde

 

From:= = Pascal Thubert (pthubert)
Sent: mardi, 6. juillet 2010 = 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: = RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination and the = transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. AS Phil = pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode to indicate = the tunnel end point for targets outside the RPL network, like the = proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 = PM
To: ROLL WG
Subject: [Roll] FW: Transit = information option

 

Hi = All,

 

I = didn’t see these comments addressed in the new draft. Any reason? =

For point 2, = I would go even further and propose to put the path sequence, control, = and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add = that the sentence “In a DIO, the RPL Target Option identifies a = resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 = 11:09
To: Philip Levis
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi= All,

 

I = just looked at the updated draft and most of the comments below have = been addresses / clarified. Just a few rather minor = points:

- = Section 5.7.7. RPL Target. Based on the discussion below I would change = “A set of one or more Transit Information options MAY directly = follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- = If the Path-Sequence / Control fields are indeed used both in storing = (where I have doubts they are really needed) and non-storing mode, why = not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode = and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length = option.

 

Be= st,

Ma= thilde

 

 

From:= = Philip Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. = juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On = Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) = wrote:

 

Hi= Phil,

&n= bsp;

Th= anks a lot for your answer. Here are my = comments:

 =

A few items = that might be worth clarifying in version = 09:

- = “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path = sequence / control / lifetime are not specified (which seems to = contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing = mode seems like it is a MUST as well...

I = think we all = agree.

- “A = non-storing node that has more than one DAO parent MAY include a Transit = Information option for each DAO parent as part of the non-storing = Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A = and B) shouldn’t he send one DAO with transit information A (i.e. = parent address =3D A) to DAO parent A and another DAO with transit = information B to DAO parent B? Otherwise how this would work over = multiple hop? Maybe an example of DAO would = help.

- In section = 7.1.5 point 2, I assume the node should add a transit information with = its parent before passing the content of the received DAO. Also do the = operation specified on the path control field in the previous section = for storing node also apply in the non-storing = case?

 

These are good questions. Currently the draft is a bit = unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, = or 

2) the = DODAG Root receives just the last downward hops of each node, and = stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that if = it's 2), then in non-storing mode node needs to send a DAO to just one = DAO parent, and this DAO can contain the full set of last-hops. What are = your thoughts?

 

Indeed, I think the current = draft is a bit unclear. My interpretation when reading was 1 (probably = due mostly to the history of the draft). Now from your comments I = understand what the draft is proposing, namely 2. Thanks for = explaining.

What triggered this = change?

It seems to me that if proper aggregation of the = routes is performed (in particular if in the record route case you can = avoid transmitting routes which are sub-routes of others) the two = schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit = on the topology. What is quite clear is that 2 requires more processing = power than 1 as it needs to reassemble routes from the received = information.

Also concerning your last comment, I agree. The DAO = produced will be slightly larger but we send only one DAO instead of one = DAO per DAO parent. I think if we do that we might not really need the = path control field, = correct?

 

-09 has a rewrite of the Downward Routes section that = should make all of this much clearer. The answer is 2), for reasons = Richard brought up a few months ago. In particular, if you use 1), then = when a node changes its parent set it entire sub-DODAG must resend DAOs. = This is a significant cost. If you use 2), then only that node needs to = send a new DAO.

 

 

<= p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'> 

=

- Has the = advantage of having multiple DAO parents been assessed with respect to = the added complexity? One could argue that since we take so much care in = selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent set. = The concern is that the vagaries and unreliability of wireless links = call for supporting some degree of path diversity. Most protocols today = maintain multiple candidate next hops for this exact reason. Because = downward routes start at the endpoints, there needs to be some way to = establish multiple routes. Otherwise, when one link breaks and you have = to issue a trigger to the entire sub-DODAG.

I = understand how this would work in the storing case but in the = non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------_=_NextPart_001_01CB1DA5.0DAB2F90-- From alexandru.petrescu@gmail.com Wed Jul 7 14:19:55 2010 Return-Path: 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 A510F3A681F for ; Wed, 7 Jul 2010 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_05=-1.11, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6] 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 QVP8Blq-0k68 for ; Wed, 7 Jul 2010 14:19:54 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id BAEF33A68D6 for ; Wed, 7 Jul 2010 14:19:52 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 59DC1940058; Wed, 7 Jul 2010 23:19:50 +0200 (CEST) Message-ID: <4C34EF75.6080007@gmail.com> Date: Wed, 07 Jul 2010 23:19:49 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jon Smirl References: <4C338400.9030602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100707-1, 07/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Implementing gateway routers 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: , X-List-Received-Date: Wed, 07 Jul 2010 21:19:55 -0000 Le 06/07/2010 22:07, Jon Smirl a écrit : > On Tue, Jul 6, 2010 at 3:29 PM, Alexandru Petrescu > wrote: >> Hmm... this is interesting, let me try to picture to see if I >> understand correctly. >> >> (I am also listening to RPL expert implementation opinion). >> >> Le 06/07/2010 17:15, Jon Smirl a écrit : >>> >>> I've been working with the Contiki RPL implementation. There >>> are two ways to make gateway routers.... > > There are two types of hardware involved: embedded CPU with SPI > attached radio - like a Atmel RF230. USB sticks with microcontroller > and radio > > The SPI radio has no microcontroller so it is forced to run > 6lowpan/RPL on the Linux host. 6lowpan/RPL support has been > partially implemented on Linux but the implement is not complete. > > The USB stick has a choice, it can pretend to be a dumb radio or it > can run a full TCP/IP stack and talk to the host using SLIP/PPP. I > have this type of hardware. That USB stick sounds interesting. Can you set up a SLIP interface on it? If yes then can you set IP forwarding on it (proc sys net ip_forwarding 1)? Can you run ND on that interface, on the USB stick? Does the stick run some form of linux at all? >>> Linux hosted - RPL runs on Linux and 802.15.4 device is treated >>> as a serially attached radio peripheral >> >> o antenna | | ------ PC bus ------ eth0 >> +---|802154|----------|Linux |--- |device| |"host"| >> ------ ------ >> >> To my speculative reading this would be a very easy way to go, >> because RPL implementation could have access to Linux's host >> memory and CPU ressources. I would try this first. >> >>> MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to >>> MCU/radio over SPI/USB. >> >> o antenna | | ------ USB ------ eth0 +---|MCU >> |----------|Linux |--- |device|PPP/SLIP |"host"| ------ ------ >> >> I see a need to take IP-over-serial into account. >> >> I think in this case the MCU should be able to have two >> interfaces: one on which it runs RPL and another (USB serial) on >> which it doesn't. And IP route between the two ("route -n" shows >> two distinctive routes, the one towards serial being probably the >> default). > > Contiki has already implemented a dual interface gateway - SLIP and > 6lowpan/RPL. It works fine with one gateway. Ah? I doubt Contiki could run on the USB stick too. >>> There are multiple gateways attached to the RPL network. >> >> Hmm... if one wants to have these gateways interact on their >> egress, using some non-RPL protocol (ND, OSPF), then one would >> prefer to have the RPL implemented in the first figure... because >> it would be hard to make non-RPL implementations on the MCU. > > That's the core part of my question, how do you set up routing with > multiple gateways when the gateways are using SLIP/PPP to talk to > their host? To my speculative thinking: if the USB stick can set up a SLIP interface, and see it with 'ifconfig' and add routes on the USB stick that are visible on it with 'route -n' running on stick then it's straightforward to set up routing between these sticks, their hosts and between them - it's a matter of properly planning the addressing architecture. > If that's too hard to set up then the better option is to run > 6lowpan/RPL on the host and treat the microcontroller like a dumb > radio. I tend to agree with this. It is much easier to implement and run RPL and 6lowpan on the linux host computer (not the stick) and treat the microcontroller as a dumb radio. ('dumb' in the IP sense, but could be as intelligent as running 802.15.5 mesh 'networking' which involves link-layer 'routing' and link-layer multicast). This is a very tempting case for implementation. From this implementation perspective it is very tempting. The approach can help answer many unknowns in the RPL 6lowpan space. (sometimes this discussion turns into "mesh-under" vs "route-over" a delimitation which is not as hard as it may sound - not all problems are solved if we just use "mesh-under" - e.g. how does IP routing and MLD over the "mesh-under" take advantage of the features it offers: does MLD REPORT map into XXXXX.join of 802.15.5? how does ND use the multicast of the "mesh-under"? and similar). I am eager to listen about the implementation approaches and how do they influence the RPL 6lowpan design. Alex > >> >>> Which of these two architectures is better to implement? The same >>> hardware can be used for both models. The MCU can run a small >>> program that makes it look like a serially attached radio. >> >> Could the MCU also implement non-RPL stuff: ND and OSPF to talk to >> the Linux "host"? >> >>> Are there any advantages in integrating RPL/6lowpan into Linux's >>> networking code? >> >> WEll sure there are, IMHO. At least if IPv6-over-802154 (6lowpan's >> RFC4944) is implemented in the main linux kernel trunk. >> >>> The project has already been started (linux-zigbee), I'm trying >>> to figure out which model to work further on. It's not obvious >>> to me how these two models interact with multiple gateways to >>> the RPL network. >> >> Just two cents worth. >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > From jpv@cisco.com Wed Jul 7 23:50:36 2010 Return-Path: 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 099E63A68F1 for ; Wed, 7 Jul 2010 23:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.176 X-Spam-Level: X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 nc+CovAC7ksR for ; Wed, 7 Jul 2010 23:50:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2A3A23A6846 for ; Wed, 7 Jul 2010 23:50:35 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPYRNUyrR7H+/2dsb2JhbACgG3GkFJpmhSUEiD+CLA X-IronPort-AV: E=Sophos;i="4.53,557,1272844800"; d="scan'208";a="223285059" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2010 06:50:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o686oGpp025708 for ; Thu, 8 Jul 2010 06:50:38 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 08:50:34 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 08:50:34 +0200 Message-Id: <1CE878A2-21B9-429E-8DEE-880052AC4D6E@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 08:48:57 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Jul 2010 06:50:34.0648 (UTC) FILETIME=[DD7BF980:01CB1E69] Subject: [Roll] Agenda ROLL WG Meeting IETF-78 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: , X-List-Received-Date: Thu, 08 Jul 2010 06:50:36 -0000 Dear all, Please find the agenda for the IETF-78 ROLL WG meeting: http://www.ietf.org/proceedings/78/agenda/roll.txt Let From jpv@cisco.com Wed Jul 7 23:53:55 2010 Return-Path: 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 29A493A6359 for ; Wed, 7 Jul 2010 23:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ETCqRLMk192Z for ; Wed, 7 Jul 2010 23:53:54 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 692223A6846 for ; Wed, 7 Jul 2010 23:53:54 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOcSNUyrR7H+/2dsb2JhbACgG3GkF5pmhSUEiD+CLA X-IronPort-AV: E=Sophos;i="4.53,557,1272844800"; d="scan'208,217";a="155460023" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 08 Jul 2010 06:53:58 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o686rkEQ028142 for ; Thu, 8 Jul 2010 06:53:57 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 08:53:15 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 08:53:15 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-268--382916298 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 08:53:14 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Jul 2010 06:53:15.0090 (UTC) FILETIME=[3D1D7B20:01CB1E6A] Subject: [Roll] Agenda ROLL WG Meeting IETF-78 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: , X-List-Received-Date: Thu, 08 Jul 2010 06:53:55 -0000 --Apple-Mail-268--382916298 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please find the agenda for the IETF-78 ROLL WG meeting: http://www.ietf.org/proceedings/78/agenda/roll.txt Let us know if you have comments. JP. --Apple-Mail-268--382916298 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all,

Please find the agenda for the IETF-78 ROLL WG meeting: http://www.ietf.org/proceedings/78/agenda/roll.txt

Let us know if you have comments.

JP.
--Apple-Mail-268--382916298-- From pthubert@cisco.com Thu Jul 8 04:11:14 2010 Return-Path: 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 1F54E3A6A4D; Thu, 8 Jul 2010 04:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 QS2e2Kk+nUyO; Thu, 8 Jul 2010 04:11:12 -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 B66A03A6A4A; Thu, 8 Jul 2010 04:11:10 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNPNUxAZnwN/2dsb2JhbACgJ3GkNZpzglyCSQSKaw X-IronPort-AV: E=Sophos;i="4.53,557,1272844800"; d="scan'208";a="129954122" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2010 11:11:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68BBCNR010028; Thu, 8 Jul 2010 11:11:13 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 13:11:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 13:11:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0243AFE4@XMB-AMS-107.cisco.com> In-Reply-To: <4C350CC1.5020904@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND-10 Status thread-index: AcseK8Uq7+thhv7YRn+/PS0DrDcqbwAU07vw References: <007201cb1485$c800e9a0$5802bce0$@sturek@att.net> <974D9389-B7FC-41B6-B5A5-85714879F4B3@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D022FDF43@XMB-AMS-107.cisco.com> <4C33D203.2050200@oracle.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AA90@XMB-AMS-107.cisco.com> <4C350CC1.5020904@oracle.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 08 Jul 2010 11:11:12.0708 (UTC) FILETIME=[467E9040:01CB1E8E] Cc: ROLL WG , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ND-10 Status 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: , X-List-Received-Date: Thu, 08 Jul 2010 11:11:15 -0000 Hi Erik > > http://tools.ietf.org/html/draft-ietf-roll-rpl-10#section-6 >=20 > Seems like the non-deployed OSPFv1 used lollipop, but since that was still > subject to the S1 < S2 < S3 < S1 issue, this was removed in OSPFv2. >=20 > That might be an issue for Roll; I haven't looked at it closely. >=20 > In any case, OSPFv1 includes the feature where using a number on the stick > of the lollipop will result in other routers telling you the last sequence > number they they have for your LSA. The message flow for 6lowpan-nd > doesn't have such a mechanism, and given that we don't require flooding all > the information to all the routers, it isn't clear that we can actually add such a > thing to 6lowpan-nd. (Without requiring that the AROs be flooded to all of > the 6LRs.) >=20 > Thus I think there is some work needed before we can consider applying > lollipop or any other sequence numbers to 6lowpan-nd. [Pascal] Let's do it then. You'll find that RPL: 1) uses simple increments (by 1 I mean) 2) emulates OSPFv2 in that it uses the odd space as a straight part. 3) avoids the S1=20 > > [Pascal] This is basically what the HA does in MIP. This has an added > > value for the HA to be able to ensure bidir reachability by using a > > new seq num as a challenge, though it is not officially used in the > > protocol. >=20 > I HA in MIP is a centralized solution. > A distributed protocol is q very different beast. >=20 [Pascal] Exactly. So getting the previously used seq nb from the wrong node in the distributed world is probably the wrong idea :) RPL did not=20 takes that path. Pascal From gnawali@cs.stanford.edu Thu Jul 8 16:46:06 2010 Return-Path: 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 DFC703A6990 for ; Thu, 8 Jul 2010 16:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3BcDCO80fYyj for ; Thu, 8 Jul 2010 16:46:06 -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 1E3B53A6968 for ; Thu, 8 Jul 2010 16:46:06 -0700 (PDT) Received: from mail-gx0-f174.google.com ([209.85.161.174]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OX0nC-0005ft-4Q for roll@ietf.org; Thu, 08 Jul 2010 16:46:10 -0700 Received: by gxk23 with SMTP id 23so842191gxk.19 for ; Thu, 08 Jul 2010 16:46:09 -0700 (PDT) Received: by 10.151.5.1 with SMTP id h1mr1133322ybi.348.1278632769234; Thu, 08 Jul 2010 16:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.192.13 with HTTP; Thu, 8 Jul 2010 16:45:49 -0700 (PDT) In-Reply-To: <4B70677D-FDC0-42B6-9D60-44491B354115@cisco.com> References: <4B70677D-FDC0-42B6-9D60-44491B354115@cisco.com> From: Omprakash Gnawali Date: Thu, 8 Jul 2010 16:45:49 -0700 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: ROLL WG Subject: Re: [Roll] Comments on draft-gnawali-roll-minrank-hysteresis-of-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: , X-List-Received-Date: Thu, 08 Jul 2010 23:46:07 -0000 On Wed, Jun 16, 2010 at 6:29 AM, JP Vasseur wrote: > Dear authors, > Please find some comments in line. Several comments are cosmetic and > editorial. > The main two comments are: > 1) why standardizing the hysteresis mechanism (other mechanisms may apply), > this is a local > decision, ... Many implementations will likely use some type of hysteresis so it was an attempt to establish some expectation on how quickly the paths change. > 2) at least parameters should not be tied to a specific routing metric. Agree. My goal was to make sure the parameters/variables make sense for at least etx and latency. If you noticed something that wouldn't work, I would be happy to address them. ... > 2. If there are multiple paths with the smallest path metric and > that smallest path metric is smaller than cur_min_path_metric by > at least PARENT_SWITCH_THRESHOLD, a node MAY use a different > objective function to select the preferred parent among the > candidates > > JP> Not sure of what you mean here ... Why using a different OF ? Did you > mean "MAY use a different preferred parent" ? Example: If there are multiple parents that offer the minimum ETX paths, a node MAY pick the parent that offers minimum latency. > 4. If the selected metric for a link is greater than > MAX_LINK_METRIC, the node SHOULD exclude that link from > consideration for parent selection. > > JP> I see two issues here; > > 1) This is tied to the ETX metric > > 2) Why should we standardize such a local decision? I think this also applies to latency. Thanks for the comments. - om_p From mcr@sandelman.ca Thu Jul 8 17:35:17 2010 Return-Path: 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 05C5C3A67C2 for ; Thu, 8 Jul 2010 17:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 IH1XXvRv4kPc for ; Thu, 8 Jul 2010 17:35:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2351C3A66B4 for ; Thu, 8 Jul 2010 17:35:14 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id B43413449B for ; Thu, 8 Jul 2010 20:35:15 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 760779896A for ; Thu, 8 Jul 2010 20:33:31 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 08 Jul 2010 20:33:31 -0400 Message-ID: <6427.1278635611@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] rpl-10 --- security questions 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: , X-List-Received-Date: Fri, 09 Jul 2010 00:35:17 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {I have a lot of comments here on rpl-10, mostly about the security=20 stuff present since rpl-09} Exec summary: *** I am not happy with the lack of algorithm agility implied by RPL-10. CCM*-AES-128 and the ECPVS signature scheme[X9.92] appear to be hard coded. While there are some bits to permit up to 3 additional algorithms to be used, I can see no bits to permit a different signature algorithm.=20=20 *** I am *not* of the opinion that AH would be a better choice here. AH can be made to work, but we will essentially be creating a new mode of AH, which is replay-enabled while still being multicast and multi-sender capable.=20=20 What I am saying is that there is no code savings: restricted code size system won't care AH vs RPL10, because they won't have any AH code to reuse. Systems with AH will have to implement new code anyway, and it will be harder to implement RPL on any system that already has IPsec because the code may be hard to modify. I am of the STRONG opinion that the text, and essential packet format of the AH specification should be extensively used.=20=20 =3D=3D=3D my detailed comments. In section 5.1, RPL Security Fields, the Key Identifier may be present depending upon the value of the KIM field. When KIM is 00, 01, and 10, the presence, absence of the Key Identifier is clear. (But, if Group key is used, then Key Source is not used, because, I guess, the Key Index is no longer a local key, but a global key, so that's why the Key Source is not present?) When KIM is 11, a signature is present. Where is the signature defined? What is the format of the signature?=20=20 When KIM is 11, a key source *MAY* be present and a key index *MAY* be present. How is this determined? I think it may come out of the security level, but I don't quite see how. It appears that the RPL security fields are not a multiple of 64-bits, and block-mode AES requires 16-byte blocks, while CCM mode is happy with any increment of bits. Assuming that someone will define a second cipher at some point, we need to know how to padd properly.=20 But, I don't see any statement about how padding is to be used. I am not happy with the text of 9.2.=20=20 I suggest it should say: Authenticated mode requires a would-be router to dynamically install new keys once they have joined a network as a host. Having joined as a host, the node would then use standard IP messaging to communicate with an authorization server, and new keys would be provided. A protocol to obtain such keys is the subject of a future standard. =3D=3D=3D I also see no way for a node to tell if it is joining an authenticated network or a pre-installed network. How does a node which is authenticated know which set of keys (pre-installed or authenticated) to use to authenticate a message from a new prospective node?=20 Is this an inate property of the keys themselves indicated by the Key Source and Key Index?=20=20 The 'A' bit of the Configuration Option tells a node what it may do. section 9.3: 2. When a node resets its Trickle timer in response to a secure DIS (Section 7.3), the next DIO it transmits MUST be a secure DIO with the same security configuration as the secure DIS. If a node receives multiple secure DIS messages before it transmits a DIO, the secure DIO MUST have the same security configuration as the last DIS it is responding to. The fact that the DIO transmitted is always the same as the last DIS it received means that any DIS received before may never get replied to using an acceptable (to that transmitter) level of security.=20=20 Isn't this an opening for a bid-down attack? The rules for the 'A' bit of the configuration option are written wrong. They give rules for what a node MAY NOT do, but nodes will do what they like. What we need are rules to determine what a message being processed with a non-Authenticated keyset may express.=20=20=20 Text like this: When processing DIO messages secured with Key Index 0x00 in a DODAG that is marked as authenticated, a processing node MUST consider the advertised rank to be INFINITE_RANK. Any other value results in the message being discarded.=20 When processing DAO messages secured with Key index 0x00 in a DODAG that is marked as authenticated, a processing node MUST ensure that any RPL Target Option containing the same address as the message's source address. =20=20=20 ...continuing with The above rules mean that in RPL Instances where the 'A' bit is set, using Key Index 0x00 a node can join the RPL Instance as a host but not a router. A node must communicate with a key authority to obtain a key that will enable it to act as a router.=20=20 {Why not just ignore any Target Option prefixes, and take the value from the source address? That way, you can avoid sending unnecessary bytes} 9.4: =2D the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL nodes + the 'C' bit is set, this Counter field can be 1 or 4 bytes. RPL nodes > 2. If a node receives a secure RPL message with the C bit set and is > uncertain of the 32-bit counter value, it MAY send a CC message > with the R bit cleared to obtain an uncompressed counter value. > The Nonce field of the CC message SHOULD be a random or > pseudorandom number. It says, "MAY". What other choices does the node have?=20 What does the node do with the message it received? Discard? Are there parts of the message that may still be trustworthy? Is there any point in asking for an update on the CC if the message does not change any state? > 3. If a node receives a unicast CC message with the R bit cleared, > and it is a member of or is in the process of joining the > associated DODAG, it SHOULD respond with a unicast CC message to > the sender. This response MUST have the C bit of the security > section cleared, MUST have the R bit set, and MUST have the same > Nonce, RPLInstanceID and DODAGID fields as the message it > received. It seems like this should have been discussed more in the section 3? Why is the nonce only 16-bits? Seems small to me. There needs to be advice that the nonce is not an incrementing integer! (cf. DNS queries with 16-bit ids). Why is the destination counter included? Of what use is that? Is it valid to send CC messages to peers which are not onlink (one hop)? I.e. can CC messages be meaningfully routed across the DAG? I'm asking, not because I think they should be forbidden, but because if they are not forbidden, then we might need to say so lest someone makes a different decision. > 2. The timestamp MUST be in 1kHz (millisecond) granularity. Is it 1/1000 that one wants, or 1/1024? > 3. The timestamp start time MUST be January 1, 2010, 12:00:00AM UTC. Making it Unix epoch (Jan. 1, 1970) would be simpler. As the specification says we are supposed to keep 6 bytes (48 bits) of resolution, this is 274877906944s, or 8700 years. If we go to Jan. 1970, then this changes the lifetime of RPL from 8716 years to 8675 years. As I understand it, we are only transmitting the lower 32-bits of the value, in units of 1/1000s. So the timestamp for my email would be: Unix time(1278331381) * 1000 mod (2^32) =3D 2726094088.=20 > 7. If a node does not have a local timestamp that satisfies the > above requirements, it MUST ignore the 'T' flag. I think this is confusing. I think it means that if a node does not=20 have a timestamp that meets the requirements, it must set the 'T' flag to zero. The question of what a node does with a message with the 'T' flag set, where the node has no concept of time is not dealt with, I think. Also, I guess that if keys have Start Times and End Times, then in principle, one can have multiple keys with index 0x00, which are non-overlapping in time. In principle, that is, if every node has a clock!=20=20=20 If a node hasn't a clock, while I can see ways to pick the key by either trying all of them, or using the Counter value as a clue, it seems that this introduces windows for replay attacks that the counters had just closed. > node's security policy database. The configuration of this security > policy database for outgoing packet processing is TBD (it may, for the term "security policy database", while generically used here, may well be confused with IPsec's SPD. > to the particular destination address. Where a Counter for the > intended destination address has not been established, the Counter > value MUST be initialized to zero and sent as a Full Counter for the > initial RPL message transmission. To aid in implementation, can we please start the Counter at 1, and even better, forbid 32-bit Counter values of 0 (matters when the counter rolls). The entire Compressed Counter mechanism seems like a waste of code space. I see no savings by doing this in the resulting packets due to required padding. The ensuing CC process that is needed to deal with this seems like a further waste. I'd rather define a standard compression algorithm that we can apply before encryption instead.=20 I was excited by section 9.5.1, because it was going to tell me which bits to apply the AES-CCM encryption bits to, and which bits to authenticate. It failed to do that.=20=20 Do I understand that the security bits themselves are *NOT* integrity protected?=20 page 74, re: zero-value Full Counter receipt. Is the message itself discarded then? Assume that it otherwise passes all processing.=20=20 > protection for a received RPL message. The replay check MUST be > performed following the authentication of the received packet. The well, no. The replay check SHOULD be preformed before authentication of the packet. If the replay counter says "old", then you discard without further processing (do not waste your time/energy verifying old packets!). If the replay says "new", then you can authenticate first, and update the counters if it checks out.=20=20=20 I can't tell from the specification if the contents of the "Security Section" are protected in any way by the integrity check. Section 9.6 was not helpful, as it says "entire IPv6 packet". I guess this means the layer-3, but someone will get it wrong, and include layer-2 too. When the integrity check is calculated, what is the value in the security section for the MAC code?=20 (I would assume zeroes..)=20=20 Should any fields in the layer-3 (IPv6 base header) be skipped, the way that AH skips them? What about any extension headers present?=20=20 As the recommended MUST is AES-CCM mode, which performs both integrity and encryption at the same time, I don't know how one can have the bytes under integrity check different from those that are encrypted.=20 Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for some text to steal. Note that this might=20 section 9.5.3.1: I have no idea where in the packet the nonce goes. Is it simply created as input into the CCM* star? Or does it have to be transmitted somewhere? (I don't think so)=20=20=20 *** I am not happy with the lack of algorithm agility implied by RPL-10 *** 9.5.3.2: I am not happy with specification of a possibly encumbered elliptic curve here. Has then been a proper IPR disclosure? There is no algorithm agility available here either. =20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATDZuW4CLcPvd0N1lAQJtjAf+PF89RD42S82qhnMLgfVxazt/F6eShg29 YLzav6sKP6r7ONEIiWqEBbEvVlj6LZiezspjCR7tRRY3+N/hX2V26d29K4XDdH+U BviTp4JZuOfSiqi/lN8KYJWxHQN3Uw276lIPohlIyrgKYhd2fP3wvmHIBIY/eCxd qOipDsaFIXeJipvHv7auBRnB8abFoUqS3bSXWt1yx+BCTdPH39+2CfsVrpKFoh1d RkPysGZdg6yJUJXHxlUeImT1AW+tjk06smeGi2z1WidmpAGJLMDn0+J7yGZ8PMZV ccfoLewAZspAd7s4FLqrzRndi/jg7yDYHDVm6URf5WPDmkP6BjH8Fw== =qG6Z -----END PGP SIGNATURE----- --=-=-=-- From pal@cs.stanford.edu Thu Jul 8 18:17:14 2010 Return-Path: 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 83B7A3A69B0 for ; Thu, 8 Jul 2010 18:17:14 -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 gTqF1lX5u2ah for ; Thu, 8 Jul 2010 18:17:13 -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 DCE663A699E for ; Thu, 8 Jul 2010 18:17:13 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OX2DO-0001VS-8o; Thu, 08 Jul 2010 18:17:18 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6427.1278635611@marajade.sandelman.ca> Date: Thu, 8 Jul 2010 18:17:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <340AE467-4830-44BC-AA50-17E282356522@cs.stanford.edu> References: <6427.1278635611@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: roll@ietf.org Subject: Re: [Roll] rpl-10 --- security questions 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: , X-List-Received-Date: Fri, 09 Jul 2010 01:17:14 -0000 On Jul 8, 2010, at 5:33 PM, Michael Richardson wrote: >=20 > {I have a lot of comments here on rpl-10, mostly about the security=20 > stuff present since rpl-09} >=20 > Exec summary: > *** I am not happy with the lack of algorithm agility implied by > RPL-10. CCM*-AES-128 and the ECPVS signature scheme[X9.92] > appear to be hard coded. While there are some bits to permit > up to 3 additional algorithms to be used, I can see no bits to > permit a different signature algorithm. =20 Michael, This is a good point. The table should specify that 00 specifies = CCM*-AES-128 and ECPVS. Future values need to be able to change both the = algorithm and signature scheme. Also, if you take a look at how the bits = are arranged, while the field is currently only 2 bits, the bits above = it are reserved, so that the field can grow if needed. I'll respond to the details in a follow-up mail (might take a while). Phil= From jpv@cisco.com Fri Jul 9 00:39:57 2010 Return-Path: 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 506EE3A6359 for ; Fri, 9 Jul 2010 00:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ICqWJdTliuiu for ; Fri, 9 Jul 2010 00:39:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BF7D33A6821 for ; Fri, 9 Jul 2010 00:39:54 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALFvNkyrR7H+/2dsb2JhbACBRJ50caN8mlOFJwSISYIu X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="scan'208,217";a="342383489" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2010 07:39:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o697dvF6023718 for ; Fri, 9 Jul 2010 07:39:59 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 09:39:57 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 09:39:56 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-299--293714736 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Jul 2010 09:39:55 +0200 References: <20100708192931.479143A689F@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Jul 2010 07:39:56.0903 (UTC) FILETIME=[ED89F770:01CB1F39] Subject: [Roll] Fwd: IETF 78 - Registration Cut-off Dates 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: , X-List-Received-Date: Fri, 09 Jul 2010 07:39:57 -0000 --Apple-Mail-299--293714736 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IETF Secretariat > Date: July 8, 2010 9:29:31 PM CEDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: IETF 78 - Registration Cut-off Dates > > 78th IETF Meeting > Maastricht, Netherlands > July 25-30, 2010 > > 1. Registration Cut-off Dates > 2. Social Event > ======================================================= > 1) Registration Cut-off Dates > You can register on line at: http://www.ietf.org/meeting/78/index.html > Please note the following registration cut-off dates: > * 2010-07-16 (Friday): Early Bird registration and payment cut-off at > 17:00 PDT (24:00 UTC). > * 2010-07-19 (Monday): Registration cancellation cut-off at 17:00 PDT > (24:00 UTC). > * 2010-07-23 (Friday): Final Pre-Registration and Pre-Payment cut-off > at 17:00 local Maastricht time (08:00 PDT, 15:00 UTC). > > 2) Social Event > General Information: http://www.ietf78.nl/social-event.html > Where: On the banks of the Meuse River > Date: Tuesday 27 July 2010 > Time: 19:30 - 22:30 (Note: this is a new time) > Host: Ministry of Economic Affairs, the Province of Limburg and the > Municipality of Maastricht > > Maastricht, one of the Netherlands oldest and most beautiful cities, > is > the backdrop to this spectacular social event, exclusively for > visitors to > the 78th IETF meeting. It is a lighthearted break in the IETF78 > Maastricht > program - an event you do not want to miss! > > You must register for the IETF meeting before you can purchase social > event tickets. > > Only 17 days until IETF 78! --Apple-Mail-299--293714736 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: July 8, 2010 9:29:31 PM = CEDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = IETF 78 - Registration Cut-off Dates 

78th IETF = Meeting
Maastricht, Netherlands
July 25-30, 2010

1. = Registration Cut-off Dates
2. Social = Event
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
1) Registration Cut-off Dates
You can = register on line at: http://www.ietf.org/mee= ting/78/index.html
Please note the following registration = cut-off dates:
 * 2010-07-16 (Friday): Early Bird registration = and payment cut-off at
17:00 PDT (24:00 UTC).
 * 2010-07-19 = (Monday): Registration cancellation cut-off at 17:00 PDT
(24:00 = UTC).
 * 2010-07-23 (Friday): Final Pre-Registration and = Pre-Payment cut-off
at 17:00 local Maastricht time (08:00 PDT, 15:00 = UTC).

2) Social Event
General Information: http://www.ietf78.nl/socia= l-event.html
Where: On the banks of the Meuse River
Date: = Tuesday 27 July 2010
Time: 19:30 - 22:30 (Note: this is a new = time)
Host: Ministry of Economic Affairs, the Province of Limburg and = the
Municipality of Maastricht

Maastricht, one of the = Netherlands oldest and most beautiful cities, is
the backdrop to this = spectacular social event, exclusively for visitors to
the 78th IETF = meeting. It is a lighthearted break in the IETF78 Maastricht
program = - an event you do not want to miss!

You must register for the = IETF meeting before you can purchase social
event = tickets.

Only 17 days until IETF = 78!

= --Apple-Mail-299--293714736-- From pthubert@cisco.com Fri Jul 9 03:00:18 2010 Return-Path: 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 3ADCD3A6951 for ; Fri, 9 Jul 2010 03:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.911 X-Spam-Level: X-Spam-Status: No, score=-7.911 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 G9bMawhVkrNH for ; Fri, 9 Jul 2010 03:00:16 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 74D1B3A69DE for ; Fri, 9 Jul 2010 03:00:16 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image003.gif, image002.png : 87, 6281 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KAMOPNkyrR7Ht/2dsb2JhbABzUIFanDxmcaMriSmRLwKEM3IEinc X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="156190354" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2010 10:00:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69A0AMS012612 for ; Fri, 9 Jul 2010 10:00:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 12:00:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB1F4D.840CFD50" Date: Fri, 9 Jul 2010 12:00:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of tunnels and end point determication thread-index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybw== From: "Pascal Thubert (pthubert)" To: "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 10:00:10.0566 (UTC) FILETIME=[84790E60:01CB1F4D] Subject: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 10:00:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1F4D.840CFD50 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB1F4D.840CFD50" ------_=_NextPart_002_01CB1F4D.840CFD50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KIA0KDQpJdCBtaWdodCBub3Qgc3RyaWtlIHRoZSBleWUgZ29pbmcgdGhyb3Vn aCB0aGUgYmFzZSBzcGVjIGJ1dCBtb3N0IHBhY2tldHMgdGhhdCBmbHkgdGhyb3VnaCBhIFJQTCBu ZXR3b3JrIGFyZSBlbmNhcHN1bGF0ZWQsIElQIGluIElQLiBUaGUgZ2VuZXJpYyByZWFzb24gaXMg dGhlIG5lZWQgdG8gaW5zZXJ0IC8gIHJlbW92ZSB0aGUgSG9wIGJ5IGhvcCBoZWFkZXIgZGVmaW5l ZCBkcmFmdC1odWktNm1hbi1ycGwtb3B0aW9uLiBUaGVyZeKAmXMgYWxzbyB0aGUgbmVlZCBmb3Ig dGhlIHJvb3QgdG8gaW5zZXJ0IGEgcm91dGluZyBoZWFkZXIgaW4gbm9uLXN0b3JpbmcgbW9kZS4g VGhpcyBpcyB3aGF0IHdlIGNhbiBjYWxsIHR1bm5lbCBtb2RlLg0KDQpUaGlzIHNlZW1zIHRydWUg Zm9yIHBhY2tldHMgb3JpZ2luYXRpbmcgb3V0c2lkZSBvciB0ZXJtaW5hdGluZyBvdXRzaWRlIHRo ZSBSUEwgbmV0d29yay4gQW4gZXhjZXB0aW9uIHRvIHRoaXMgcnVsZSBjb3VsZCBiZSBwYWNrZXRz IHRoYXQgd2lsbCBiZSBmcm9tIGFuZCB0byByb3V0ZXJzIG9yIGxlYXZlcyBvZiBhIHNhbWUgUlBM IG5ldHdvcmssIGJlY2F1c2UgaW4gdGhhdCBjYXNlLCB0aGUgb3JpZ2luYXRvciBjYW4gcGxhY2Ug dGhlIEhvcCBieSBob3AgYW5kIGV2ZW50dWFsbHkgdGhlIHJvdXRpbmcgaGVhZGVyIGFzIGl0IGZv cm1zIHRoZSBwYWNrZXQsIHdpdGhvdXQgSVAgaW4gSVAgZW5jYXBzdWxhdGlvbi4gU29tZXRoaW5n IHdlIGNvdWxkIGNhbGwgdHJhbnNwb3J0IG1vZGUsIG9yIG5hdGl2ZSBtb2RlLCBvciBpbnNpZGVy IG1vZGUgPw0KDQogDQoNCkFueXdheSBpdCBhcHBlYXJzIHRoYXQgdGhlIHNwZWMgY291bGQgYmUg Y2xlYXJlciBpbjoNCg0KMS4gICAgICAgRXhwbGFpbmluZyB3aHkgSVAgaW4gSVAgaXMgdXNlZCBp biBnZW5lcmFsDQoNCjIuICAgICAgIFNwZWNpZnlpbmcgdGhlIHJ1bGVzIHRvIGRldGVybWluZSBp ZiBhIGRlc3RpbmF0aW9uIGlzIGluc2lkZSB0aGUgUlBMIG5ldHdvcmsNCg0KMy4gICAgICAgU3Bl Y2lmeWluZyB0dW5uZWwgbW9kZSBvcGVyYXRpb24NCg0KNC4gICAgICAgU3BlY2lmeWluZyB0cmFu c3BvcnQgbW9kZSBvcGVyYXRpb24gYW5kIHdoZW4gaXQgY2FuIGJlIHVzZWQNCg0KNS4gICAgICAg U3BlY2lmeWluZyBob3cgdG8gZGV0ZXJtaW5lIHRoZSB0dW5uZWwgZW5kcG9pbnQgaW4gdHVubmVs IG1vZGUNCg0KIA0KDQpQcm9wb3NhbDoNCg0KIA0KDQoxKSAgICAgIFJQTCBuZWVkcyBhbiBpbnN0 YW5jZSBJRCBpbiB0aGUgZmxvdyBsYWJlbCwgYW5kIEhiSCBoZWFkZXIsIGFuZCBldmVudHVhbGx5 IGEgcm91dGluZyBoZWFkZXIgaW4gZXZlcnkgcGFja2V0IGZvciByb3V0aW5nIGFuZCBpbmNvbnNp c3RlbmN5IGRldGVybWluYXRpb24uIFRoZSBIYkggYW5kIFJIIGFyZSBub25zZW5zaWNhbCBvdXRz aWRlIHRoZSBSUEwgbmV0d29yayBhbmQgY2FuIG9ubHkgYmUgcHJlc2VudCBpbnNpZGUgdGhlIFJQ TCBuZXR3b3JrLiBUaGUgb25seSBjbGVhbiB3YXkgdG8gaW5zZXJ0IGFuZCByZW1vdmUgdGhvc2Ug aGVhZGVycyBpcyB0byB1c2UgYSB0dW5uZWwgbW9kZSAoSVAgaW4gSVAgZW5jYXBzdWxhdGlvbikg d2hlcmVieSB0aGUgcm91dGVyIHBsYWNlcyB0aGUgUlBMIGhlYWRlcnMgYmVmb3JlIHRoZSBpbm5l ciBoZWFkZXIsIGxlYXZpbmcgdGhlIG9yaWdpbmFsIHBhY2tldCB1bnRvdWNoZWQuDQoNCmEuICAg ICAgIEEgc291cmNlIGluc2lkZSB0aGUgUlBMIG5ldHdvcmsgKHJvdXRlciBvciBsZWFmKSBwbGFj ZXMgdGhlIFJQTCBoZWFkZXJzIGFuZCBmbG93IGxhYmVsIGluIHRoZSBwYWNrZXQsIGVpdGhlciBp biB0dW5uZWwgb3IgdHJhbnNwb3J0IG1vZGUuDQoNCmIuICAgICAgRm9yIHBhY2tldHMgb3JpZ2lu YXRlZCBvdXRzaWRlIHRoZSBSUEwgbmV0d29yaywgdGhlIGZpcnN0IFJQTCByb3V0ZXIgKGNhbGxl ZCBpbmdyZXNzIHJvdXRlcikgaGFzIHRvIHBsYWNlIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIHBh Y2tldCBpbiB0dW5uZWwgbW9kZQ0KDQpjLiAgICAgICBGdXJ0aGVyIFJQTCByb3V0ZXJzIGZpbmQg dGhlIGluZm9ybWF0aW9uIGFuZCB1c2UgaXQuIFRoZXkgZG8gbm90IHJlLWVuY2Fwc3VsYXRlLCB0 aGV5IGRvIG5vdCBjaGFuZ2UgdGhlIGZsb3cgbGFiZWwsIHRoZXkgaGFwcGVuIHRvIG1vZGlmeSB0 aGUgUlBMIGhlYWRlcnMuDQoNCmQuICAgICAgVGhlIHR1bm5lbCBlbmRwb2ludCBkZWNhcHN1bGF0 ZXMgYmVmb3JlIGZvcndhcmRpbmcgdGhlIGlubmVyIHBhY2tldC4gVGhpcyBzdHJpcHMgdGhlIFJQ TCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBwYWNrZXQuIElmIHRoZSBwYWNrZXQgaXMgcmVpbnNlcnRl ZCBpbnRvIHRoZSBSUEwgbmV0d29yayB0aGVuIHRoZXJlIGlzIGEgcmlzayBvZiBhIGxvb3AuIA0K DQogDQoNCjIpICAgICAgQSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgc2FtZSBSUEwgbmV0d29yayBp ZjoNCg0KYS4gICAgICAgVGhlIGRlc3RpbmF0aW9uIGlzIHRoZSByb290IG9mIHRoZSBET0RBRyAo YWxsIG1vZGVzKQ0KDQpiLiAgICAgIFRoZSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgc2FtZSBTdWJu ZXQgYXMgdGhlIHNvdXJjZSAoZGVyaXZlZCBmcm9tIGEgUElPKSAgKHN0b3JpbmcgbW9kZSBvbmx5 KSANCg0KYy4gICAgICAgVGhlIG5vZGUgaXMgYSByb3V0ZXIgdGhhdCBoYXMgYSBEQU8gc3RhdGUg aW5kaWNhdGluZyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBhIGNoaWxkIChzdG9yaW5nIG1vZGUg b25seSkNCg0KZC4gICAgICBUaGUgZGVzdGluYXRpb24gaGFzIGJlZW4gc2VlbiBhcyB0dW5uZWwg ZW5kcG9pbnQgYW5kIHRodXMgaXMgYSBEQU8gYW5jZXN0b3IgKHN0b3JpbmcgbW9kZSBvbmx5KS4N Cg0KIA0KDQogDQoNCjMpICAgICAgQSBSUEwgcm91dGVyIHRoYXQgaW5qZWN0cyBhIHBhY2tldCB3 aXRob3V0IHRoZSBIYkggb3B0aW9uIGludG8gdGhlIFJQTCBuZXR3b3JrIGlzIGFuIGluZ3Jlc3Mg cm91dGVyLiAgDQoNCmEuICAgICAgIEFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgcGxhY2UgdGhlIFJQ TCBpbmZvcm1hdGlvbiBpbiB0aGUgcGFja2V0IGluIHR1bm5lbCBtb2RlDQoNCmIuICAgICAgQW4g aW5ncmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0aGUgaW5zdGFuY2UgSUQgaW4gdGhlIGZsb3cgbGFi ZWwgb2YgdGhlIG91dGVyIGhlYWRlcg0KDQpjLiAgICAgICBBbiBpbmdyZXNzIHJvdXRlciBNVVNU IHVzZSBvbmUgb2YgaXRzIGdsb2JhbCBhZGRyZXNzZXMgZnJvbSB0aGUgUlBMIGRvbWFpbiBhcyBz b3VyY2UNCg0KZC4gICAgICBBbiBpbmdyZXNzIHJvdXRlciBNVVNUIHVzZSBhIHR1bm5lbCBlbmRw b2ludCB0aGF0IGlzIGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrIChydWxlcyBhYm92ZSkuDQoNCiAN Cg0KNCkgICAgICBBIFJQTCBub2RlIE1VU1QgcGxhY2UgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiBl dmVyeSBwYWNrZXQgdGhhdCBpcyBzb3VyY2VzLiBJdCBjYW4gc2FmZWx5IHVzZSB0dW5uZWwgbW9k ZSBmb3IgYWxsIHBhY2tldHMuIEl0IE1BWSB1c2UgdHJhbnNwb3J0IG1vZGUgd2hlbiBpdCBkZXRl cm1pbmVzIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGlzIGEgUlBMIGxlYWYgb3Igcm91dGVyIHdpdGhp biB0aGUgc2FtZSBSUEwgbmV0d29yay4gSW4gdHJhbnNwb3J0IG1vZGUsIHRoZSBvdXRlciBoZWFk ZXJzIGFyZSBidWlsdCBhcyBmb2xsb3dzOiANCg0KYS4gICAgICAgVGhlIHNvdXJjZSBNVVNUIHBs YWNlIHRoZSBpbnN0YW5jZSBJRCBpbiB0aGUgZmxvdyBsYWJlbCBvZiB0aGUgSVB2NiBoZWFkZXIN Cg0KYi4gICAgICBUaGUgc291cmNlIE1VU1QgdXNlIG9uZSBvZiBpdHMgZ2xvYmFsIGFkZHJlc3Nl cyBmcm9tIHRoZSBSUEwgZG9tYWluIGFzIHNvdXJjZQ0KDQpjLiAgICAgICBUaGUgZGVzdGluYXRp b24gTVVTVCBiZSBpcyBpbiB0aGUgc2FtZSBSUEwgbmV0d29yayAocnVsZXMgYWJvdmUpLg0KDQog DQoNCjUpICAgICAgVGhlIHR1bm5lbCBlbmRwb2ludCBpcyBkZXRlcm1pbmVkIGFzIGZvbGxvd3M6 DQoNCmEuICAgICAgIElmIHRoZSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgUlBMIG5ldHdvcmsgKHJ1 bGVzIGFib3ZlKSB0aGVuIHRoZSBlbmRwb2ludCBpcyB0aGUgZGVzdGluYXRpb24NCg0KYi4gICAg ICBJZiB0aGUgZGVzdGluYXRpb24gaXMgYSBob3N0IGF0dGFjaGVkIHRvIGEgUlBMIHJvdXRlciB0 aGVuIHRoZSBlbmRwb2ludCBpcyB0aGF0IFJQTCByb3V0ZXINCg0KYy4gICAgICAgRWxzZSB0aGUg ZW5kcG9pbnQgaXMgdGhlIHJvb3QNCg0KIA0KDQpJdCBhcHBlYXJzIHRoYXQgdGhlIGIpIGlzIG5v dCBzdXBwb3J0ZWQgY29ycmVjdGx5IHdpdGggdGhlIGN1cnJlbnQgc3BlYyBzaW5jZSB3ZSBkbyBu b3QgaGF2ZSBhIHdheSB0byBpbmplY3QgYSByb3V0ZSB0byBhbiBleHRlcm5hbCBob3N0IHdoaWxl IGluZGljYXRpbmcgdGhhdCB0aGUgaG9zdCBpcyBub3QgYSBsZWFmLg0KDQpQcm9iYWJseSB0aGUg cm91dGVyIHdvdWxkIHByZXNlbnQgaXRzZWxmIGFzIHBhcmVudCBpbiBhIHRyYW5zaXQgb3B0aW9u LCB3aXRoIGEgYml0IHNheWluZyB0aGF0IHRoZSB0YXJnZXRzIGFzIG5vbiBycGwgaG9zdHMuDQoN CiANCg0KT3BpbmlvbnM/DQoNCiANCg0KIA0KDQoJDQpQYXNjYWwgVGh1YmVydA0KSVB2NiBFbmdp bmVlcmluZw0KUHJvZHVjdCBEZXZlbG9wbWVudA0KcHRodWJlcnRAY2lzY28uY29tIDxtYWlsdG86 cHRodWJlcnRAY2lzY28uY29tPiANClBob25lOiArMzMgNCA5NzIzIDI2MzQNCk1vYmlsZTogKzMz IDYgMTk5OCAyOTg1DQoNCg0KDQpDaXNjbyBTeXN0ZW1zIEZyYW5jZQ0KVmlsbGFnZSBkJ0VudHJl cHJpc2VzIEdyZWVuIFNpZGUNCjQwMCBBdmVudWUgZGUgUm91bWFuaWxsZSANCkJhdGltZW50IFQg MyANCjA2NDEwIA0KQklPVCAtIFNPUEhJQSBBTlRJUE9MSVMNCkZyYW5jZQ0KQ2lzY28uY29tIDxo dHRwOi8vd3d3LmNpc2NvLmNvbS9nbG9iYWwvRlIvPiANCg0KICANCg0KIA0KDQogVGhpbmsgYmVm b3JlIHlvdSBwcmludC4NCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNw b25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFu dGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUg Y2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1 ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0 ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91 dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCA8aHR0cDovL3d3dy5jaXNjby5j b20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPiANCg0KIA0K DQogDQoNCg== ------_=_NextPart_002_01CB1F4D.840CFD50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uVGV4dGVkZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUg ZGUgYnVsbGVzIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJUZXh0ZSBkZSBidWxsZXMiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MjM5ODE0NzsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk4MzE0NjkyMCA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTA4 LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE0NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoxODAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMTYuMHB0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjUyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjI4OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMyNC4wcHQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDozNjAuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mzk2 LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTU5MjQ2MjEwOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUwMDIzODk0MCA2NzY5ODcwNSA2NzY5ODcxMyA2 NzY5ODcxNSAtMTI2NzQ1MTg3MiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlNFwpIjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjIwOTc0MzI2MTY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5NzIyNjcxMTQgNjc2OTg3MDMgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDMNCgl7bXNvLWxpc3QtaWQ6MjE0NTYxMjg5NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA5NjA2MjIxMCA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9 DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Ojkw LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEyNi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTYyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTk4 LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MjcwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzA2 LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjM0Mi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUg dmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD5E ZWFyIFdHOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SXQgbWlnaHQgbm90IHN0cmlrZSB0aGUgZXllIGdvaW5n IHRocm91Z2ggdGhlIGJhc2Ugc3BlYyBidXQgbW9zdCBwYWNrZXRzIHRoYXQgZmx5IHRocm91Z2gg YSBSUEwgbmV0d29yayBhcmUgZW5jYXBzdWxhdGVkLCBJUCBpbiBJUC4gVGhlIGdlbmVyaWMgcmVh c29uIGlzIHRoZSBuZWVkIHRvIGluc2VydCAvIMKgcmVtb3ZlIHRoZSBIb3AgYnkgaG9wIGhlYWRl ciBkZWZpbmVkIGRyYWZ0LWh1aS02bWFuLXJwbC1vcHRpb24uIFRoZXJl4oCZcyBhbHNvIHRoZSBu ZWVkIGZvciB0aGUgcm9vdCB0byBpbnNlcnQgYSByb3V0aW5nIGhlYWRlciBpbiBub24tc3Rvcmlu ZyBtb2RlLiBUaGlzIGlzIHdoYXQgd2UgY2FuIGNhbGwgdHVubmVsIG1vZGUuPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlRoaXMgc2VlbXMgdHJ1ZSBmb3IgcGFja2V0cyBvcmlnaW5h dGluZyBvdXRzaWRlIG9yIHRlcm1pbmF0aW5nIG91dHNpZGUgdGhlIFJQTCBuZXR3b3JrLiBBbiBl eGNlcHRpb24gdG8gdGhpcyBydWxlIGNvdWxkIGJlIHBhY2tldHMgdGhhdCB3aWxsIGJlIGZyb20g YW5kIHRvIHJvdXRlcnMgb3IgbGVhdmVzIG9mIGEgc2FtZSBSUEwgbmV0d29yaywgYmVjYXVzZSBp biB0aGF0IGNhc2UsIHRoZSBvcmlnaW5hdG9yIGNhbiBwbGFjZSB0aGUgSG9wIGJ5IGhvcCBhbmQg ZXZlbnR1YWxseSB0aGUgcm91dGluZyBoZWFkZXIgYXMgaXQgZm9ybXMgdGhlIHBhY2tldCwgd2l0 aG91dCBJUCBpbiBJUCBlbmNhcHN1bGF0aW9uLiBTb21ldGhpbmcgd2UgY291bGQgY2FsbCB0cmFu c3BvcnQgbW9kZSwgb3IgbmF0aXZlIG1vZGUsIG9yIGluc2lkZXIgbW9kZSA/PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5Bbnl3YXkgaXQgYXBwZWFycyB0aGF0IHRoZSBzcGVjIGNvdWxkIGJlIGNsZWFyZXIgaW46 PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPkV4cGxhaW5pbmcgd2h5IElQIGluIElQIGlzIHVzZWQgaW4g Z2VuZXJhbDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TcGVjaWZ5aW5nIHRoZSBydWxlcyB0byBkZXRl cm1pbmUgaWYgYSBkZXN0aW5hdGlvbiBpcyBpbnNpZGUgdGhlIFJQTCBuZXR3b3JrPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPlNwZWNpZnlpbmcgdHVubmVsIG1vZGUgb3BlcmF0aW9uPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMiBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+NC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPlNwZWNpZnlpbmcgdHJhbnNwb3J0IG1vZGUgb3BlcmF0aW9uIGFuZCB3aGVuIGl0 IGNhbiBiZSB1c2VkPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls ZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NS48c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlNwZWNpZnlpbmcgaG93IHRvIGRldGVy bWluZSB0aGUgdHVubmVsIGVuZHBvaW50IGluIHR1bm5lbCBtb2RlPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTGlzdFBhcmFncmFwaD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+UHJvcG9zYWw6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjEpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRp bWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5SUEwgbmVlZHMgYW4gaW5zdGFuY2UgSUQgaW4gdGhlIGZsb3cgbGFiZWws IGFuZCBIYkggaGVhZGVyLCBhbmQgZXZlbnR1YWxseSBhIHJvdXRpbmcgaGVhZGVyIGluIGV2ZXJ5 IHBhY2tldCBmb3Igcm91dGluZyBhbmQgaW5jb25zaXN0ZW5jeSBkZXRlcm1pbmF0aW9uLiBUaGUg SGJIIGFuZCBSSCBhcmUgbm9uc2Vuc2ljYWwgb3V0c2lkZSB0aGUgUlBMIG5ldHdvcmsgYW5kIGNh biBvbmx5IGJlIHByZXNlbnQgaW5zaWRlIHRoZSBSUEwgbmV0d29yay4gVGhlIG9ubHkgY2xlYW4g d2F5IHRvIGluc2VydCBhbmQgcmVtb3ZlIHRob3NlIGhlYWRlcnMgaXMgdG8gdXNlIGEgdHVubmVs IG1vZGUgKElQIGluIElQIGVuY2Fwc3VsYXRpb24pIHdoZXJlYnkgdGhlIHJvdXRlciBwbGFjZXMg dGhlIFJQTCBoZWFkZXJzIGJlZm9yZSB0aGUgaW5uZXIgaGVhZGVyLCBsZWF2aW5nIHRoZSBvcmln aW5hbCBwYWNrZXQgdW50b3VjaGVkLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+QSBzb3VyY2UgaW5zaWRlIHRoZSBSUEwgbmV0d29yayAocm91dGVyIG9yIGxlYWYpIHBs YWNlcyB0aGUgUlBMIGhlYWRlcnMgYW5kIGZsb3cgbGFiZWwgaW4gdGhlIHBhY2tldCwgZWl0aGVy IGluIHR1bm5lbCBvciB0cmFuc3BvcnQgbW9kZS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPkZvciBwYWNrZXRzIG9yaWdpbmF0ZWQgb3V0c2lkZSB0aGUgUlBMIG5ldHdvcmssIHRo ZSBmaXJzdCBSUEwgcm91dGVyIChjYWxsZWQgaW5ncmVzcyByb3V0ZXIpIGhhcyB0byBwbGFjZSB0 aGlzIGluZm9ybWF0aW9uIGluIHRoZSBwYWNrZXQgaW4gdHVubmVsIG1vZGU8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3 LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkZ1cnRoZXIgUlBMIHJvdXRlcnMgZmluZCB0aGUg aW5mb3JtYXRpb24gYW5kIHVzZSBpdC4gVGhleSBkbyBub3QgcmUtZW5jYXBzdWxhdGUsIHRoZXkg ZG8gbm90IGNoYW5nZSB0aGUgZmxvdyBsYWJlbCwgdGhleSBoYXBwZW4gdG8gbW9kaWZ5IHRoZSBS UEwgaGVhZGVycy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxl PSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+ZC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB0dW5uZWwg ZW5kcG9pbnQgZGVjYXBzdWxhdGVzIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBpbm5lciBwYWNrZXQu IFRoaXMgc3RyaXBzIHRoZSBSUEwgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGFja2V0LiBJZiB0aGUg cGFja2V0IGlzIHJlaW5zZXJ0ZWQgaW50byB0aGUgUlBMIG5ldHdvcmsgdGhlbiB0aGVyZSBpcyBh IHJpc2sgb2YgYSBsb29wLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo IHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJ Z25vcmUnPjIpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BIGRlc3Rp bmF0aW9uIGlzIGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrIGlmOjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGRlc3RpbmF0aW9uIGlzIHRoZSByb290IG9mIHRoZSBE T0RBRyAoYWxsIG1vZGVzKTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omwx IGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6 SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGRl c3RpbmF0aW9uIGlzIGluIHRoZSBzYW1lIFN1Ym5ldCBhcyB0aGUgc291cmNlIChkZXJpdmVkIGZy b20gYSBQSU8pIMKgKHN0b3JpbmcgbW9kZSBvbmx5KSA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPlRoZSBub2RlIGlzIGEgcm91dGVyIHRoYXQgaGFzIGEgREFPIHN0YXRl IGluZGljYXRpbmcgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMgYSBjaGlsZCAoc3RvcmluZyBtb2Rl IG9ubHkpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxm bzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmQu PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgZGVzdGluYXRpb24g aGFzIGJlZW4gc2VlbiBhcyB0dW5uZWwgZW5kcG9pbnQgYW5kIHRodXMgaXMgYSBEQU8gYW5jZXN0 b3IgKHN0b3JpbmcgbW9kZSBvbmx5KS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8y Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zKTxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QSBSUEwgcm91dGVyIHRoYXQg aW5qZWN0cyBhIHBhY2tldCB3aXRob3V0IHRoZSBIYkggb3B0aW9uIGludG8gdGhlIFJQTCBuZXR3 b3JrIGlzIGFuIGluZ3Jlc3Mgcm91dGVyLiDCoDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+QW4gaW5ncmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0aGUgUlBMIGluZm9ybWF0 aW9uIGluIHRoZSBwYWNrZXQgaW4gdHVubmVsIG1vZGU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgcGxhY2UgdGhlIGluc3RhbmNlIElEIGlu IHRoZSBmbG93IGxhYmVsIG9mIHRoZSBvdXRlciBoZWFkZXI8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPkFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgdXNlIG9uZSBvZiBpdHMg Z2xvYmFsIGFkZHJlc3NlcyBmcm9tIHRoZSBSUEwgZG9tYWluIGFzIHNvdXJjZTxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5kLjxzcGFuIHN0eWxlPSdmb250 OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QW4gaW5ncmVzcyByb3V0ZXIgTVVTVCB1c2UgYSB0dW5u ZWwgZW5kcG9pbnQgdGhhdCBpcyBpbiB0aGUgc2FtZSBSUEwgbmV0d29yayAocnVsZXMgYWJvdmUp LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1s ZWZ0OjcyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFw aCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NCk8c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkEgUlBMIG5vZGUgTVVTVCBwbGFjZSB0 aGUgUlBMIGluZm9ybWF0aW9uIGluIGV2ZXJ5IHBhY2tldCB0aGF0IGlzIHNvdXJjZXMuIEl0IGNh biBzYWZlbHkgdXNlIHR1bm5lbCBtb2RlIGZvciBhbGwgcGFja2V0cy4gSXQgTUFZIHVzZSB0cmFu c3BvcnQgbW9kZSB3aGVuIGl0IGRldGVybWluZXMgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMgYSBS UEwgbGVhZiBvciByb3V0ZXIgd2l0aGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrLiBJbiB0cmFuc3Bv cnQgbW9kZSwgdGhlIG91dGVyIGhlYWRlcnMgYXJlIGJ1aWx0IGFzIGZvbGxvd3M6IDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIHNvdXJjZSBNVVNUIHBsYWNlIHRo ZSBpbnN0YW5jZSBJRCBpbiB0aGUgZmxvdyBsYWJlbCBvZiB0aGUgSVB2NiBoZWFkZXI8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzb3VyY2UgTVVTVCB1c2Ugb25lIG9mIGl0 cyBnbG9iYWwgYWRkcmVzc2VzIGZyb20gdGhlIFJQTCBkb21haW4gYXMgc291cmNlPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzInPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmMuPHNwYW4gc3R5bGU9J2Zv bnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgZGVzdGluYXRpb24gTVVTVCBiZSBp cyBpbiB0aGUgc2FtZSBSUEwgbmV0d29yayAocnVsZXMgYWJvdmUpLjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+NSk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPlRoZSB0dW5uZWwgZW5kcG9pbnQgaXMgZGV0ZXJtaW5lZCBhcyBmb2xs b3dzOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8y Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgdGhlIGRlc3Rp bmF0aW9uIGlzIGluIHRoZSBSUEwgbmV0d29yayAocnVsZXMgYWJvdmUpIHRoZW4gdGhlIGVuZHBv aW50IGlzIHRoZSBkZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwxIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ SWYgdGhlIGRlc3RpbmF0aW9uIGlzIGEgaG9zdCBhdHRhY2hlZCB0byBhIFJQTCByb3V0ZXIgdGhl biB0aGUgZW5kcG9pbnQgaXMgdGhhdCBSUEwgcm91dGVyPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmMuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5FbHNlIHRoZSBlbmRwb2ludCBpcyB0aGUgcm9vdDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDozNi4wcHQnPkl0IGFwcGVhcnMgdGhhdCB0aGUgYikgaXMgbm90IHN1cHBvcnRlZCBjb3JyZWN0 bHkgd2l0aCB0aGUgY3VycmVudCBzcGVjIHNpbmNlIHdlIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGlu amVjdCBhIHJvdXRlIHRvIGFuIGV4dGVybmFsIGhvc3Qgd2hpbGUgaW5kaWNhdGluZyB0aGF0IHRo ZSBob3N0IGlzIG5vdCBhIGxlYWYuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPlByb2JhYmx5IHRoZSByb3V0ZXIgd291bGQgcHJlc2Vu dCBpdHNlbGYgYXMgcGFyZW50IGluIGEgdHJhbnNpdCBvcHRpb24sIHdpdGggYSBiaXQgc2F5aW5n IHRoYXQgdGhlIHRhcmdldHMgYXMgbm9uIHJwbCBob3N0cy48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPk9waW5p b25zPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHRhYmxlIGNsYXNzPU1z b05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01 NDMgc3R5bGU9J3dpZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSc+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5n PTAgY2VsbHBhZGRpbmc9MCB3aWR0aD02MDAgc3R5bGU9J3dpZHRoOjQ1MC4wNXB0Jz48dHI+PHRk IGNvbHNwYW49MyBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjwvdGQ+PC90cj48dHIg c3R5bGU9J2hlaWdodDo5NC4wNXB0Jz48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRp bmc6MGNtIDBjbSAxMS4yNXB0IDE4LjBwdDtoZWlnaHQ6OTQuMDVwdCc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5QYXNjYWwgVGh1YmVydDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojNjY2NjY2Jz48YnI+PGI+SVB2NiBFbmdpbmVlcmluZzwvYj48YnI+PGI+UHJvZHVjdCBEZXZl bG9wbWVudDwvYj48YnI+PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+PHNwYW4g c3R5bGU9J2NvbG9yOiM2NjY2NjYnPnB0aHViZXJ0QGNpc2NvLmNvbTwvc3Bhbj48L2E+PGJyPlBo b25lOiA8Yj4rMzMgNCA5NzIzIDI2MzQ8L2I+PGJyPk1vYmlsZTogPGI+KzMzIDYgMTk5OCAyOTg1 PC9iPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PHRkIG5vd3JhcCB2YWxpZ249 dG9wIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gNy41cHQgMTUuMHB0O2hlaWdodDo5NC4wNXB0Jz48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Jz48Yj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28gU3lzdGVt cyBGcmFuY2U8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+VmlsbGFn ZSBkJ0VudHJlcHJpc2VzIEdyZWVuIFNpZGU8YnI+NDAwIEF2ZW51ZSBkZSBSb3VtYW5pbGxlIDxi cj5CYXRpbWVudCBUIDMgPGJyPjA2NDEwIDxicj5CSU9UIC0gU09QSElBIEFOVElQT0xJUzxicj5G cmFuY2U8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGEgaHJlZj0iaHR0cDovL3d3dy5j aXNjby5jb20vZ2xvYmFsL0ZSLyI+PHNwYW4gbGFuZz1GUiBzdHlsZT0nY29sb3I6IzY2NjY2Nic+ Q2lzY28uY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCB3aWR0aD0xODYgc3R5bGU9J3dpZHRoOjEzOS43 NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo5NC4wNXB0Jz48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIic+PGltZyBi b3JkZXI9MCB3aWR0aD0xNjQgaGVpZ2h0PTEwOCBpZD0iSW1hZ2VfeDAwMjBfMSIgc3JjPSJjaWQ6 aW1hZ2UwMDIucG5nQDAxQ0IxRjVFLjQ1QURCNTMwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90 ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7ZGlzcGxheTpub25l Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxl IGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD03MTkgc3R5bGU9J3dp ZHRoOjUzOS4xNXB0Jz48dHIgc3R5bGU9J2hlaWdodDo5MC44cHQnPjx0ZCB3aWR0aD03MTkgc3R5 bGU9J3dpZHRoOjUzOS4xNXB0O3BhZGRpbmc6MGNtIDE4LjBwdCAwY20gMTguMHB0O2hlaWdodDo5 MC44cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDk5MDAnPjxpbWcgYm9yZGVy PTAgd2lkdGg9MTggaGVpZ2h0PTE5IGlkPSJJbWFnZV94MDAyMF8yIiBzcmM9ImNpZDppbWFnZTAw My5naWZAMDFDQjFGNEEuNjZFQ0IxNjAiIGFsdD0iVGhpbmsgYmVmb3JlIHlvdSBwcmludC4iPjwv c3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+VGhpbmsgYmVmb3JlIHlvdSBwcmludC48 YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+Q2lzY28gU3lzdGVtcyBG cmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUg RGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAg SXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2 MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWlj aGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2Vi L2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBsYW5nPUZS IHN0eWxlPSdjb2xvcjpibHVlJz5odHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdf YnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwOTkwMCc+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxl PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZSPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_002_01CB1F4D.840CFD50-- ------_=_NextPart_001_01CB1F4D.840CFD50 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CB1F4D.840CFD50 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahAST7V/3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L8OpvbV6Ly3WpD7HxVvyWoZOWD40gGTtkZFfTJGnok8g 3137O00SA6kuTJ/LAAKpaX9aaLCRpGWGEziLfjMSgVNvUklRM/uCfUXleQTkkv2mYjExjM98vRH7 TwwskFN+3COA5M/KZrsvINk/5i15BWUVEkixOmllsjPOUfMxn1AkZOT0GkSEJKTivXUHxE1/eoG6 MK8cVQ4UkFoOvnhhyWZhshmEr/cY9wpkdV09QsksWpCp58VSVVfXK5DLfjcT42AgWRMfsPUaMCC9 zicIrcj3hWv37Gf7RffsznCQlZSZh+Onw+AWFosiCg6HwK76PxZIjgJt/MJFILFglyF2UATa226c oQRkI5k6X/Jf2S+cv9NARLfeEQlQ9LABeKgByWmn3465YiHd938fOAqr06FCOdzQQF4iU8d+1eUJ 2oTXl+/AUa9glQCSc4jbLZzF659b/AueI8A2mdj3qCWHGpDc18QVuzCGxjF60UbhLydl5d3YQCZn FWDmFi08/Nlq4bONJGdfx+mMSgBZQ0CuJe342Bdq1Pc6PPq5GlZpHhOVGFUA0pgifPZjH5+7lu7/ T5ix4Qji0rJvbCBTcgoxb6e+CFIYgrHLtsDILUAlgKwlIH8hjciwMGC8Z5HNN+cbVQFITnGN//c2 oQT4Gp9v0xGbgm94IOfs0CPtuFZA8MLSzTB09e/x9cHxqe1R9oLBi7JH9SPKZiA3GNsJEBmwp6n/ NXonegXyyij790GJstXps6r3GWVzkn7ct1sxgoDkzzp7q7Y4EHdDA3kxuxBfbtfFE3PWipv+/JJN MHDpDcihk4dkINcbnRLjGCW0zDqo6dr0CORg5yE9WvOQT/YzD2nmESws0oiFl3fTzyLXiQOdGxpI zoHxacAxpC1YK/GBJusz4T2+PuJipjgXI6oR1GYMcKXmqGeIKBuKSs3Xv+BHrZ4rNZyeYqDGf7tN vH7c0i3YZeUqUkHdyeVKzQkKfjaJSgpXagxdAwYMyMDYi5i5WUuMhfv/bKuOSEn1JLyBhM8bjfpq PZ75aqOItFNyCm5sIHljhI7jGUxXPyRA4E0HIWSWexKuZe+ydBU3kuHdYGTXq99ztUD6xySLieGx sJNv6BKAsh5q2by7xjEoCnN36Ito9YttujgVEIGGHvKorDnNPILw8UYNTCRXg4/mno5MHDAgL2Tl Y4upA976ca/QjnzCMjWn51p2eFI6VlIQxn74++sOknXwQUHpH54g/2OBrG1oQBCZYU6XLD9kCTPP oF7PHnM1xD0sDmt0T1BEe1wAV1RROWBA8hFZPv/8/UELbDNzFMdOe0rUc7ktISMPh0564bsD5vjd xgNx6dk9Ph2DE9F8wIw3PfyH+tdz9sOlXjY/XMtuH8fgKKwmrf6TtjX51tFi+1xPwnsyLbxDxM6m jbSw/WMuoKbuD38QwdCo1PiSr8N7BC9k5fVaqeGaMQcHbgSlU3C0MPm97YfkU4cvdzh1+H4fpw45 t5iQnotT/ufhH933fkg2zwy4rd85hCWloaq250oNA8wPKQiITRZP0Yjr40kUfOrwQ3HqcK0InMb1 cepQ0fqkC+eQGLiSX80PSWhs6rnG3tDYSD58PuwDI+ETkSisVXPzDV6pUUopTRRvKOWb1Ke07oou 6MeOcceQKHL09wgNyVByJBmVktnre9jk8mSW9XPbWQ1BmVNUiqoefMfutHxOUVmfdXsOML78VZei d3WhISet2A1bArmvBV7QtmO8b7i4qsQLvPSPr9AMLSCVGqT/r+3f69kf5ceQcL6Nj8OqG5zs1x7B q63pDsbrM8hfZlPK4+bAadFuIwTEXOzXfby6ezmkDjv8uU8d8g5wbQdfEZl/s8cYNhTBD4F6bb+E 3QXWiEtoQbGmPEJBx6Xcoj/rVN0YQFbX1+Mc+Xi6TmdEhJtMPlPDAB1JGGxhc3qRomRzz2CRiQjt w0eVQKqAsDli3463taUQjIpG1YCxDUoKVFJzCoQ/yWmjIWZeJZDXPLEEYmOTajwX8kppoki5QcUW kgRSigRSihQJpBQJ5FCWpro6NNbUoImiafF9dTVaBtFX5Osor9d4nddrVijE+5tqa0Xj75sbrr50 J96rHBN9VVRVoUV1fU7VA5LjzCaauKqsLGT7+CDNwQEZLi5Id3Ki5oyiyEgxMS3d1ZT5T2zQxDWU l6OuuFg0/p5hbunlKGtzYxOq8/KQc+ZM+/WcnZHu6IiCc+fQUFmF5n6C2Uyw1JWUIC84RIw5w9VV tDT6Pi8wUIypP0Dx9apzc5HNY6JxiDGJ5oqiqCjxmSSQg60RFY0oTknFBTt7BG/7FW7z5sH+rbdw auJEnJowAQ7/mg6/1auRameHusLCTiAqNSpP4Fl1dbjNnAlXasFqashwd0dDRfc7Xero5xkBgQjd tx/uCxe1Xc+OmuP778Pn++WIMTFFceKFXrUlp2wqc/OQ5u2NcwcOwHPJUjh+OAP2770vGo/de+ky xBsYojQhkYBr7nFBcj85gUGI0dGF97ffwf6dd2hMk2BH/bh8MQdBGzYilRZO2aVLaFKRvzqhckDW k9ZLP+2LgLXrcJJuvNnIUdC/915o0vAPtzatm2+G2ajR8P1hJUoSEroAqaisRLyhIazHjcMBev3v 1KxGj0bUwYOoKei6F7CKJj7xuDXcF30N8xfGQv+v90OD3nOo9Xp8bd37H4DNm5ORdNwGjT3UpxvJ POfHxOLcoSNwmj0bFi+8CIMHHoT2rbeK/rhp0tiNHn0MzrM/Q4qDI7kEXWvjjGjRhWREamrBkxbH CYLQ+LHHoUXvP9I6Hv17/wrzMc/Cafp0BG/ajAzfM+JzSyAHSJilOrqhKR4ecFu0CEb33Qdtmjxd GrZ2a9Np/coTo3PHHXD84kvkR0R06YsnJtHMDKcmTRKTxyDYjB+PGC0t1BR1LsvVV1Uj2d4B9h9+ BP177hHX4MbX1Rs2DHoEk95tt0HjlltgRAsj6vARKBSKbrS6Ajlk1v02boLFuPHQoffpdBiz8nvN 1v9bEWQxZkehuOJBUax9C2PjELx9B4699jr07rhTjKXjZ9fq0Kce3SPjx/4Oj0VfIZ1cgoYKlYBy 6ANZT85+iocnXOfOJa3ygJg4rQ4wGhAspqQtTZ58SkwQ/85+1izknT/fVUOSw59kbg67yZPbJtH2 tdcQq6OD2iuAZE0U8MsmmDzyqABXqxVG85Ejcep/34MdmVtu5i+NFxovzsCoi5llPy+XfFrfn3+G 2egx0CKQO45d7847YfzEkzAbMQp6d90lfmfx6muINjahsbbX3Hn0ZWlpCFr3M0yffho6tBA69tO2 MIfd2gVQo4ceggdp00w/f+HySCCvU0oupuC02loYPviQgFGn9UazdrImTeH17+8Q/OsOAY87+5TT P4Cf+noUKU12h0fK9hdIDjxSvX3gNIcWAWkiASNdz3zMGASsX49Udw/yBX1wydMbscamiDiiibzQ cAqMOpf26ihgCj+iAbMXx3ZaSLq33Q6L51+A64KFCCCzyuP3WvYtHD/6GB70NZlNdofjtHU07sST drAhWA937Ie04NGnR8Bh2jR4z5sPD/r8J96YDCNauErNy4vJ5O+PI5Q0a0V6hgTyeoRTI6nOLjgx 5S1ok2lUmkxd0ia25LdF6ukjLzoGFdnZKCUHPvfceaS4uSHd5zSq8wuuGcjG+gYy146wJ0CUQLI2 s546FbGmZqgpKRWmWIyRIGwgbaaore0UqQsTS36j+1dfQ/d/7mo3+bffAStaSEE7dyEjKBhlBEl5 Zhby6XOk+fggxdUNRXHxaOrgjxbGxcFnxUoBltIkM9RWpJn91TfgEpnk0thY5J89i2gjYziSH2pE vq0OActjN7j9drh88gnS3dwlkNcjFTnZCNv9G0zJ2VdqR30C0/bttxFF0WgVBSLKIwMiHUQQMBgM SHM35qnfGpL6zPDyhvuXX8Ko1ZTq0nWNyfy5z1+IWHNLZIWEoDInp8cjC7VlZUi0PoGTU6Z08nUt xo4VMBYlJ3cKgrgfBaekaIyNDHfrIuJ/OWI+PnYcNG+97bJ/eNPNMH/+RQRt2UqWIFF8Zl50zY0K VBcWId7qGOw/+EC4M8rrmj/7HKK1dXpNb0kg+xCOTE+v+AFGd98jgORmQKYzkHypiryrPyHXG5BX BjWlBEyg2hro0/UOdQg+TB76G6wnTITzp5+KFFPCseMoy+y6C521dtiBg6TFXmgPuG6+CW7kBuRG RPZ7zA2krWP1DWD24IPCXGuLRTmMFsYCZIV2f8aGNW7Yvn2weOaZNvOuf/+Dwmy3DO1NJkMbyGwy wZ7kIxrdc6+4sewPGZLpjNPSvqb+rgbIBtI6yba2ODV5CvTJf9XpECi0TfLdd8PmrbcRums3iuMT hO+plLL0dATTz4+OHt32Hl0CMkhNTSTS+yu15RWI0tTC0UcvB1fKRRmyYSOqCrvfsKuoq0eykxNs 33ijPSC7626c3bxZAjkYQMbr6Q06kGwqawoLkeLoCO8fVpKJfF6Y7SsjW23yCS2eegrh5FqUZ2V3 BbJVSymj9OC1a7vNMfYKpIZm90AWFPYMJI3bdtKkdiD/8hcJ5PVKPjnzvitXdTbZ5KCHbduG2tKS q+7vaoBse09DA7kOMYg1MYEfjcV15iwcI8j0WoHUaP3q+PEnuESRd0trZaSC/MvwQ4dh9eKL7Sab mvfX34jMQX+lvrZOVGRMSUsrI2z9YcPg881iFEZFdfueitw8hB08CMsxz7YtBr377sNZum8SyOuQ 8qwshFIAYPrY39sSx5yUdvrkUzJJzqjv5q8McO6PI+A2573DLutrAbKjcBCVExyC0C1bYDFylKi0 6LSmX46TXxljZCI2XVzWbOXCv7TloIZ+r9SoNhMmiOxAZV7XR9/x4S8euzD9ynInfZ5k25M4xqkj up4y3WPzyiuIOnCgPZvQKuxqXHR2pUh7Ngzv+2vbdY1Ji587eEgCeT3SQMAlWtvgxJSposKh3Wr2 OP3hsWSpSJFw8FBXVi6AKk9LR35kFAqiY1BPUe7lWW7uV9qnE5AcsfJuHN6Jc8UOHAYmOyAQDp/O hF5rFMtjsnr5FUSSJmuovpzQ5hpyFsHLuUY98jWVKSsDgsRuxkeIPWqOkpRU1JaUoo5aBZn7wrgE 5J6PoKAks5M/yp+J863GjzzSXt2543acevNNJFhYojwjA/Vk2vl9XNHy+n45TB9/XIArFjHdO9t/ TkMSgT3Ej0EMbSA50VwYGwvfFStgQlGm0uzxjTYhrWk/7V0ErN+A89o6IqINIL/K8z/fI3jHTpQk JbVryKvMQ7J2rSDtnO57hibxFC66uiMrLAw5ERHIpwg5ljSc9auviTKlEhCrV15FlJ4BFNXtFZaq /HyE790Ly2efbYvSuRnefz9s334HvmvWIvywBs4d0RApHM418s9SXFwvp3JahRdckpUVbF9+uc1F EPlF8qdPvvEm/Fb9iLC9+0VxwHHmTJgNHy7ukbIkafzwI/Bf9zMKO9b3JZDXqCUrKpBC0a7jv6ZD lyZA84qgwvjRx0S5zXzsOBjTROiT828/azZyw8I6abyrAVKU/MLDEbR5K+xnfAx78hs9li4TzYt8 NzuKXg1I67T5Z1w/J42Z4uLWSaOKfoKC4LNsmSjhaXTwJTlpbchj59Lj+Jdh8vQIGJAGtJw4SeRY OR/Z4QOgPDkZAatWweChh7qUT9k0m416BibDn4IeBVlaHaDVv/c+OM3+DJfc3NFQM+T/kJJq7Pap zssn7aMvEuIGd7VXPbS621xB0Dp+/gXyzve8ueLkxIntmyteeklsrrgyMZ7l5wcv3szBEf4tw0Q+ Utn0Omg7vdtuxzHSjudIQ3P+78q/fMmbJHj3jsucuTB8/Anq65a28XbZXEG/s5wwCTGmZl02V7AJ T/cPEK6KCe8UojHpdFPP1u5QVuRyqyMtJnZ7aopLhvo0qw6QLBU02fHmFnCnKNX8pZdFOU6jddvV kQ5b0HTvuBNui5eQPxbfFUjStvFGRrAePx4H6bW8Bc2KIuaoQ4dEiqddobYgkzSb6/z5YnL3t245 69j42kYPPwy76R/i7O49KIyJExt5u5Pa0lKkkobyXbMOx96YDIMH/9Zp7Nx4PBoEmc277yGR3ITG bp77U09mPIv81wAy69Zk8g3IjdHs0IcyLcT50WOvvw6v777HhVP2qC0uVoUpVi0gxcRSoJIZFIwI HT2cJsfd8Z13YE/m12HqVNhTNMum2HPefAFuFWnVK4W3++f4+yOMomTPOXPgQe3s+vXI9PJCwxV7 BkvT04VWdp0xQwQPfA1l4+s4krYOUFPDBXsHFJM5bVL0/qweRW0d8mJiKZixQID6ejiTibejYM2B xs3tJPXpPOszEQkX0Ot6Kkky9EWJSYg/bg2/n36C07RpbfdA9EXj8l68GNFk9rNDw1BXPmT+Bs2f D0ihvWiimkh7VFF0nePri0xXV2QRUJkUXWa4uaE4KupyLbiHIwwieuazJwQgN/6ef3alqeX3sxnP CwgQRwz4GsrG1+HjE5UU3bIp7W/g2tKa1qkjjZkfGir6yfL0FI2vkR8SIn7X13EIUbenfqpzcsSx io73INPdvfd7IIEcPGEY+FgCBxLioFd9/YBfo6XjNZSNrtPch0bse/DNnfvlcz3XkCPscg84D6q6 T7iQx2ClSCClSJFASpFASpEigZQigZQiRQIpRQIpRYoEUooEUooUCaQUKRJIKRJIKVIkkFIkkFKk SCClSCClSJFASpFASpEigZQigZQi5Q+U3RJIKUMSyF2yyTYE2nsCSP5HNtmGSvs/hQgkdONYbE8A AAAASUVORK5CYII= ------_=_NextPart_001_01CB1F4D.840CFD50-- From richard.kelsey@ember.com Fri Jul 9 05:10:18 2010 Return-Path: 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 7BA3A3A6A1C for ; Fri, 9 Jul 2010 05:10:18 -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 JmHO1JgbXloJ for ; Fri, 9 Jul 2010 05:10:17 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id A6D703A6A17 for ; Fri, 9 Jul 2010 05:10:17 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 08:10:21 -0400 Date: Fri, 09 Jul 2010 08:10:45 -0400 Message-Id: <8739vshn3u.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Jul 2010 12:10:22.0271 (UTC) FILETIME=[B49CA4F0:01CB1F5F] Cc: roll@ietf.org Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 12:10:18 -0000 > Date: Fri, 9 Jul 2010 12:00:06 +0200 > From: "Pascal Thubert (pthubert)" > > 1) RPL needs an instance ID in the flow label, and HbH header, and > eventually a routing header in every packet for routing and > inconsistency determination. The HbH and RH are nonsensical outside > the RPL network and can only be present inside the RPL network. The > only clean way to insert and remove those headers is to use a tunnel > mode (IP in IP encapsulation) whereby the router places the RPL > headers before the inner header, leaving the original packet > untouched. Another clean way to do this would be to insert a non-IPv6 header in front of the IPv6 header, as MPLS does. This would be simple to do in a 6lowpan network and add less overhead than using an IP in IP tunnel with the hop-by-hop header. The core RPL draft should allow this type of solution. -Richard From mdurvy@cisco.com Fri Jul 9 05:36:34 2010 Return-Path: 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 9785B3A6892 for ; Fri, 9 Jul 2010 05:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.208 X-Spam-Level: X-Spam-Status: No, score=-9.208 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 jezR0fYC8mZo for ; Fri, 9 Jul 2010 05:36:26 -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 D5DB13A6A48 for ; Fri, 9 Jul 2010 05:36:25 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.png, smime.p7s : 837, 1465, 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABa0NkxAZnwM/2dsb2JhbACBRJ5+caNcmmcChSUEinc X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="gif'147?p7s'147?png'147,150?scan'147,150,208,217,147,150"; a="130430311" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 12:36:30 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69CaQ7w000131 for ; Fri, 9 Jul 2010 12:36:30 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 14:36:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jul 2010 14:36:25 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_097A_01CB1F74.1BA4E590" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0A6@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Transit and Target address mismatch Thread-Index: AcsdCoejDG6UKjQ3Ta2pAgc9CJPsdACU2uaQ References: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 12:36:28.0308 (UTC) FILETIME=[5A0AED40:01CB1F63] Subject: Re: [Roll] Transit and Target address mismatch 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: , X-List-Received-Date: Fri, 09 Jul 2010 12:36:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_097A_01CB1F74.1BA4E590 Content-Type: multipart/related; boundary="----=_NextPart_001_097B_01CB1F74.1BA4E590" ------=_NextPart_001_097B_01CB1F74.1BA4E590 Content-Type: multipart/alternative; boundary="----=_NextPart_002_097C_01CB1F74.1BA4E590" ------=_NextPart_002_097C_01CB1F74.1BA4E590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 Thanks for your answer. =20 So based on your comments here is my understanding of the current specs. Please correct me if I=92m wrong. =20 In the non-storing example below we would have: - A sends DAO with =93target Ag, Ap, transit Bg=94 - B sends DAO with =93target Bg, transit R=94 together with the = information from A, i.e. =93target Ag, Ap, transit Bg=94 =20 The address Bg is on-link, although it is formed on a prefix that is advertised as not on-link. This is possible thanks to a flag in the PIO sent by B that tells A the = PIO prefix is also an address (in this case Bg) that has to be considered on-link. Now, my last question would be, how does R knows that Bg is = on-link (when source routing to A)?=20 =20 I really think that this should be clarified in the specs. In = particular, it seems that for the DAO part to work: - Nodes must use the PIO sent by their parents -- to configure their own global IPv6 address -- Install a prefix that is not on-link -- Install the global IPv6 address of their parent as on-link. In particular, this means the PIO has to be included in the DIO for a node = to adopt a parent as DAO parent.=20 - Nodes must use their global on-link IPv6 address as target in DAO - Nodes must use the global IPv6 address of their parent as transit = parent address. =20 Is my understanding correct, does everybody agree on that? =20 Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 6. juillet 2010 14:56 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] Transit and Target address mismatch =20 Hi Mathilde: =20 Yes we can improve the text : ) =20 Yes, all the RH are based on global addresses. I tend to think that the non-storing mode should even use global addresses as source / = destination for DAO/DAO_ACK so nodes talk directly to the root as opposed to sending DAOs hop by hop. =20 And no, global addresses are not off link. They are not expected to be = all onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a strict source routing. So a node should be able to NS those addresses to assert = continuous connectivity. =20 One even more tricky thing is the use of IP in IP that seems to be generalized now as soon as we insert a RH or a HbH option. I think that = the resolution of your issue should also clearly state what are the tunnel endpoints, in particular when the destination on the RPL side is a dumb host. RPL should be able to differentiate the last router from the = target. =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 1:17 PM To: ROLL WG Subject: [Roll] Transit and Target address mismatch =20 Hi All, =20 Let=92s consider the storing mode in a simple topology A=E0B=E0R (=E0 = mark the parent relationship). Let=92s also assume that A has a prefix =91Ap=92 = and a global address =91Ag=92 to advertise. In this example we have: - A sends DAO with =93target Ag, Ap, transit B=94 - B sends DAO with =93target Bg, transit R=94 together with the = information from A, i.e. =93target Ag, Ap, transit B=94 =20 Then R recombines the information to get the route to for example Ap = (Target Ap, transit B, target Bg, transit R) For this to work, transit B and target Bg need to be matched. How can = this be done? Does it mean that the transit parent address has to be a global address? This would imply that we use global addresses in the routing header. However 6man-rpl-routing-header says: =93When processing the Type 4 Routing header, a router MUST drop the = packet if the next entry is not on-link=94 As global addresses have to be off-link in NBMA network like 802.15.4, I = see a problem=85 =20 Can you please clarify how addresses are supposed to be used in this source-routing scenario. =20 Thanks, Mathilde =20 =20 =20 http://www.cisco.com/swa/i/logo.gif Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 Think before you print.Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message. ------=_NextPart_002_097C_01CB1F74.1BA4E590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Pascal,

 

Thanks for your = answer.

 

So based on your = comments here is my understanding of the current specs. Please correct me if I’m = wrong.

 

In the non-storing = example below we would have:

- A sends DAO with = “target Ag, Ap, transit Bg”

- B sends DAO with = “target Bg, transit R” together with the information from A, i.e. = “target Ag, Ap, transit Bg”

 

The address Bg is = on-link, although it is formed on a prefix that is advertised as not = on-link.

This is possible thanks = to a flag in the PIO sent by B that tells A the PIO prefix is also an address (in = this case Bg) that has to be considered on-link. Now, my last question would = be, how does R knows that Bg is on-link (when source routing to A)? =

 

I really think that this = should be clarified in the specs. In particular, it seems that for the DAO part to = work:

- Nodes must use the PIO = sent by their parents

-- to configure their = own global IPv6 address

-- Install a prefix that = is not on-link

-- Install the global = IPv6 address of their parent as on-link. In particular, this means the PIO has to be = included in the DIO for a node to adopt a parent as DAO parent. =

- Nodes must use their = global on-link IPv6 address as target in DAO

- Nodes must use the = global IPv6 address of their parent as transit parent address.

 

Is my understanding = correct, does everybody agree on that?

 

Best,

Mathilde

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 6. juillet 2010 14:56
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] Transit and Target address = mismatch

 

Hi Mathilde:

 

Yes we can improve the text : )

 

Yes, all the RH are based on global addresses. I tend to think that the = non-storing mode should even use global addresses as source / destination for = DAO/DAO_ACK so nodes talk directly to the root as opposed to sending DAOs hop by = hop.

 

And no, global addresses are not off link.  They are not expected to be = all onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a strict source routing. So a node should be able to NS those addresses to assert = continuous connectivity.

 

One even more tricky thing is the use of IP in IP that seems to be = generalized now as soon as we insert a RH or a HbH option. I think that the resolution = of your issue should also clearly state what are the tunnel endpoints, in = particular when the destination on the RPL side is a dumb host. RPL should be able = to differentiate the last router from the target.

 

Cheers,

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 1:17 PM
To: ROLL WG
Subject: [Roll] Transit and Target address = mismatch

 

Hi All,

 

Let’s consider the storing mode in a simple = topology A=E0B=E0R (=E0 mark the parent = relationship). Let’s also assume that A has a prefix ‘Ap’ and a = global address ‘Ag’ to advertise.

In this example we have:

- A sends DAO with “target Ag, Ap, transit = B”

- B sends DAO with “target Bg, transit = R” together with the information from A, i.e. “target Ag, Ap, transit B”

 

Then R recombines the information to get the route = to for example Ap (Target Ap, transit B, target Bg, transit R)

For this to work, transit B and target Bg need to = be matched. How can this be done? Does it mean that the transit parent = address has to be a global address? This would imply that we use global addresses in = the routing header. However 6man-rpl-routing-header says:

“When processing the Type 4 Routing header, a = router MUST drop the packet if the next entry is not = on-link”

As global addresses have to be off-link in NBMA = network like 802.15.4, I see a problem…

 

Can you please clarify how addresses are supposed = to be used in this source-routing scenario.

 

Thanks,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy = Mathilde
Software Engineer
Technology center

mdurvy@cisco.com
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco = home page

 

 

3D"ThinkThink before you print.

This e-mail may contain confidential and privileged material for the sole use of = the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender = by reply e-mail and delete all copies of this = message.


------=_NextPart_002_097C_01CB1F74.1BA4E590-- ------=_NextPart_001_097B_01CB1F74.1BA4E590 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_097B_01CB1F74.1BA4E590 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAU5SURBVFjD xVdbTFNZFL1FFE3UoBgFBBQqIi/xEQUN+mEiH/7ph4kJmpAQlRiN/mGCMSSDDqLOgEAfNIC0PFpb ecdIeavgoCMQOgzC8BYQ5SnIU1hzz7mXRwdayFBmbrOa3ra5e5191l57Hwb/88WY8mEN3xqQ8DEB sioZMloyMDA+8N8QGPsxhq+jX3G/8j5s5DbYFr0NPuk+0DRqKInJqcnVJVD2uQzX31yHs9wZzK8M mAcsYhgcUx+jpFqGWlaXgPaTFufyzsE+3h6MiA0ezcBCbAEXhQtult1E/UD96hLoHulGaVcpAosC YS41B/OIwS7FLoS9D0NlTyWGJ4ZXl8DQxBCKO4sRUBDAEXjMwEHugNCKUFT1Vq2eCH9M/6CrU/2l womsE9gq3QqBWEC3YZ1oHazjreFf6I+KLxUYmRzB9PS0aQk0DDYg7EMYfJ75UNExkSzELKScCIkg N0o24kzuGSR+TMTg+KBpCVT3ViOwJBCOTx1hLjbnBCjhQYiw95vEm+CW5oZ7H+6hd6zXtAT6x/tR 3l2O4PJgWCdZg3nCB5bwGWBxWH0Y0bpo6Pp0GJ8aNy2BafZFRBbyNgQ2STaLEjiiPgJJrQRN35pM J0IiJrIaYkDnteexQ7YDgljBoltgEWsBe7k9bv92G+3D7ZiYmlg5AWK7sjoZ/LL9wESxge4ztPbp qiW8CAmBJ7wr/szAMs4SAcUBeNH2AlPTUysjQMQU8i4EXmle8Ej2gIfKA57PPGkfEEjYTMQyWC9b D8cUR/q9u9IdngpPHM84jqT6JNNogFRAdnM2CtoKUNJVgsLOQlx5dWXWCXen7EZ4ZTj9raSzBHkt echty0XrUKs+gezWbGiaNFDUKyg7eb0c6iY1yPeGkNuai/xP+dR+Z0CckBKImyPwoOqB3n8okfY8 vWcxzmnOcFG6wFXlin3Kfdibthd7UvfAKcXJIISpQrgqXeHxzEMP25O2c3sfw22BU6oTDqgPzMJL 7QU3lRtIzBkwTAQDu2Q7BL0Kwq2yW7hYdBFbErdwwvqJE9Cy8ZB3QxEvwmjODY2CNA6/HD8UdBTg 88hn9I314c67OxCmCCF8KqSrNQQiMjuFHRWfrdyWfrZV2MJCZsFVxBOeRDRfIaJFQH4UJglxqfAS ijqKqDA6v3dC266FtlVLe70hkJJ63vwcqkbVLIjp+Gb6cpkgpRnFI2aeSc0HfeP/cPblWWS1ZFHB EIs1iC4WneW0Gf3zIuOX6A8RTuecxul0FrkcSMZIeeq55SyBWI7A5vjNVIyHNIfgne5tGGoWSm9c Lb26KIkvo1+g69VB16OjPYCAbCvVVhSj75izzjXj35HLwGNOcJYyS1wuvoyc1pwlJ+Ca3hqEVITg qPIozCRmc66ptx9iA0IxBHY1ghgBLhRcQONg45LmReaB4LfBnFfMzA4LRLFckKz9wiKcwcmsk6jr r1uWg0ZUR2CtbC1Xgv+KQCwvWnYFZjFmcE91x933d9Ex3GE0cNf3Llpl/vn+WCNdMydGo8HEi0DE K5kl4KZ0Q1xtHO315HBi7NI0a3Aq+xSsZdazc+NCDUgWaaeRvGM94u73q/cjqDgI14quIbImEj1j PctKPWnf1KAe8ouQGiPABidpImVp9dQKVokspFZwSHagJ52e0R4MjA1geHJ4ycBkACGjG2lMlgmW 3GIWlOF88CebnYqduPHmBqR/SiGtZVEjpZOtsVOOofIL/T0UvmpfbIjbwGlIbIxALJfyg5qDeN31 esWHlszmTNgns0e2CN5npPrx/gbw8N1A6QE+ygAAAABJRU5ErkJggg== ------=_NextPart_001_097B_01CB1F74.1BA4E590-- ------=_NextPart_000_097A_01CB1F74.1BA4E590 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwOTEyMzYyNVowIwYJKoZIhvcNAQkEMRYEFHgzn449HgQ+LWqW dvbPdl0mo7g/MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAJc2UtueyS+O88X7Ht7cqJiOYveky3Lzh Dbjxpn6KKKBIGTPIOIrDjljXDWms/nJpDELu7nj4Vf6tHKss9gznbFRZVw+dPYuKKvWbqxIOGUdi pjBPhknYgZPLYDMgb6QTMyrR79Q5/mWeBWuHspB+OVt+O2jRYu9AtT0D52QPzGkAAAAAAAA= ------=_NextPart_000_097A_01CB1F74.1BA4E590-- From pthubert@cisco.com Fri Jul 9 05:50:28 2010 Return-Path: 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 4F7D33A69BF for ; Fri, 9 Jul 2010 05:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WxA9X77xfvuq for ; Fri, 9 Jul 2010 05:50:27 -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 C729F3A6A65 for ; Fri, 9 Jul 2010 05:50:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOa3NkxAZnwM/2dsb2JhbACgQnGjVpplhScEinc X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="scan'208";a="130434618" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 12:50:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69CoJhn006544; Fri, 9 Jul 2010 12:50:31 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 14:50:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 14:50:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD3BC@XMB-AMS-107.cisco.com> In-Reply-To: <8739vshn3u.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication thread-index: AcsfX9Pv8uI1PRNET8ehkFfJPfR+VgABMTCw References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8739vshn3u.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 09 Jul 2010 12:50:30.0568 (UTC) FILETIME=[50119A80:01CB1F65] Cc: roll@ietf.org Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 12:50:28 -0000 Hi Richard: RPL code only deals with native IP operations, so it does tunneling. OTOH I do not wish to preclude any operation like the one you are describing and I hope some specification will define it somewhere. Do you see text that would bar or be problematic with this operation and if so would you propose a modification to that text? Cheers, Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Friday, July 09, 2010 2:11 PM > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] Use of tunnels and end point determication >=20 > > Date: Fri, 9 Jul 2010 12:00:06 +0200 > > From: "Pascal Thubert (pthubert)" > > > > 1) RPL needs an instance ID in the flow label, and HbH header, and > > eventually a routing header in every packet for routing and > > inconsistency determination. The HbH and RH are nonsensical outside > > the RPL network and can only be present inside the RPL network. The > > only clean way to insert and remove those headers is to use a tunnel > > mode (IP in IP encapsulation) whereby the router places the RPL > > headers before the inner header, leaving the original packet > > untouched. >=20 > Another clean way to do this would be to insert a non-IPv6 > header in front of the IPv6 header, as MPLS does. This > would be simple to do in a 6lowpan network and add less > overhead than using an IP in IP tunnel with the hop-by-hop > header. >=20 > The core RPL draft should allow this type of solution. >=20 > -Richard From mdurvy@cisco.com Fri Jul 9 06:17:30 2010 Return-Path: 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 54E9E3A6A1D for ; Fri, 9 Jul 2010 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.912 X-Spam-Level: X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 1rN0cu233Gn6 for ; Fri, 9 Jul 2010 06:17: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 1BCD93A67E3 for ; Fri, 9 Jul 2010 06:17:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALK9NkxAZnwN/2dsb2JhbACBRJ5+caNcmmOFJwSKdw X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="p7s'?scan'208,217";a="130443725" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 13:17:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o69DHI1n006745 for ; Fri, 9 Jul 2010 13:17:19 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:17:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jul 2010 15:17:16 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0982_01CB1F79.D06A1C70" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0D4@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0243AA8F@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Transit information option Thread-Index: AcsdETbPrvyhawioRZaqXGJI+i24zgAB9yqwAALfWSAAj7qawA== References: <6A2A459175DABE4BB11DE2026AA50A5D0243A8DD@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE02725A97@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0243AA8F@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 13:17:18.0448 (UTC) FILETIME=[0E709F00:01CB1F69] Subject: Re: [Roll] FW: Transit information option 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: , X-List-Received-Date: Fri, 09 Jul 2010 13:17:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0982_01CB1F79.D06A1C70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0983_01CB1F79.D06C6660" ------=_NextPart_001_0983_01CB1F79.D06C6660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it's more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint). - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn't it redundant? - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? It's a lot of questions, but I hope it will help make the DAO part clearer to everybody! Best, Mathilde From: Pascal Thubert (pthubert) Sent: mercredi, 7. juillet 2010 09:22 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Mathilde, 1) In storing mode, the transit information "parent address" is not used You're correct on that with the current spec. I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. Pascal From: Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Pascal, My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. Does this make sense? Best, Mathilde From: Pascal Thubert (pthubert) Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option Hi Mathilde: Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+. I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router. What do you think? Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option Hi All, I didn't see these comments addressed in the new draft. Any reason? For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option Hi All, I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. Best, Mathilde From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: Hi Phil, Thanks a lot for your answer. Here are my comments: A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? These are good questions. Currently the draft is a bit unclear on whether 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice. Similar to Phil I'm getting worried about the increased complexity. But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? ICMP error. Phil ------=_NextPart_001_0983_01CB1F79.D06C6660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

Thanks again for your reply. What you say makes sense = although I still think that the separation of the fields between the target and = transit options is somewhat arbitrary J However this is not a major issue and maybe at this point = it’s more important to clarify the specs with respect to the meaning / usage = of the path sequence, control, and lifetime.

- In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred = (since path control bits sent to different parents have to be disjoint). =

- It seems to me that the path control usage is incompatible = with the sentence “If a node sends a DAO to one DAO parent, it MUST = send a DAO with the same DAOSequence to all other DAO parents”. = No?

- In the non storing mode, the path control is not used to = limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I = guess it can be used as a preference by the root when it computes the source = routes.

- How is the path sequence processed? Given that we have = already a DAO sequence is it possible to receive a stale path sequence? = Isn’t it redundant?

- What does the lifetime represent concretely? Is it a = measure of the lifetime of the link between the target and the = transit?

 

It’s a lot of questions, but I hope it will help make = the DAO part clearer to everybody!

 

Best,

Mathilde

 

 

From:= Pascal = Thubert (pthubert)
Sent: mercredi, 7. juillet 2010 09:22
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde,

 

1) In storing mode, the transit information “parent address” is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing = the info for the tunnel endpoint and that it might become handy to indicate = a RPL router to which a target host is attached.

 

2)    = He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ for = non-storing.

 

We want to factorise: in non-storing mode, the target can = have multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can = place multiple targets for all its addresses and then only one transit info = that is common to them all.

 

Pascal

 

From:= = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Pascal,

 

My point is a bit different.

In storing mode, the transit information “parent address” is not used. The only fields that are relevant in the = transit information are the path control, sequence, and lifetime, which actually = relate to the target prefix. So why not put these fields in the target option = and use only the transit option when we are in non-storing mode and hence need = to specify a parent address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing.

 

Does this make sense?

Best,

Mathilde

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination = and the transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. = AS Phil pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode = to indicate the tunnel end point for targets outside the RPL network, like = the proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information = option

 

Hi All,

 

I didn’t see these comments addressed in the new draft. Any reason? =

For point 2, I would go even further and propose to put the path sequence, = control, and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add that the sentence “In a DIO, the RPL Target Option = identifies a resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi All,

 

I just looked at the updated draft and most of the comments = below have been addresses / clarified. Just a few rather minor = points:

- Section 5.7.7. RPL Target. Based on the discussion below I = would change “A set of one or more Transit Information options MAY = directly follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- If the Path-Sequence / Control fields are indeed used both = in storing (where I have doubts they are really needed) and non-storing = mode, why not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length option.

 

Best,

Mathilde

 

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy = (mdurvy) wrote:

 

Hi Phil,

 

Thanks a lot for your answer. Here are my = comments:

 =

A few items that might be worth clarifying in version = 09:

- “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path sequence / control = / lifetime are not specified (which seems to contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. = Storing mode seems like it is a MUST as well...

I think we all = agree.

- “A non-storing node that has more than one DAO parent MAY include = a Transit Information option for each DAO parent as part of the = non-storing Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn’t he send one DAO with transit information A (i.e. parent = address =3D A) to DAO parent A and another DAO with transit information B to DAO = parent B? Otherwise how this would work over multiple hop? Maybe an example of = DAO would help.

- In section 7.1.5 point 2, I assume the node should add a transit = information with its parent before passing the content of the received DAO. Also do = the operation specified on the path control field in the previous section = for storing node also apply in the non-storing case?

 

These are good questions. Currently the draft is a = bit unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, or 

2) the DODAG Root receives just the last downward = hops of each node, and stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that = if it's 2), then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are your = thoughts?

 

Indeed, I think the = current draft is a bit unclear. My interpretation when reading was 1 (probably due = mostly to the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for explaining.

What triggered this = change?

It seems to me that if = proper aggregation of the routes is performed (in particular if in the record = route case you can avoid transmitting routes which are sub-routes of others) = the two schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit on = the topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.

Also concerning your = last comment, I agree. The DAO produced will be slightly larger but we send only one = DAO instead of one DAO per DAO parent. I think if we do that we might not = really need the path control field, correct?

 

-09 has a rewrite of the Downward Routes section = that should make all of this much clearer. The answer is 2), for reasons Richard = brought up a few months ago. In particular, if you use 1), then when a node changes = its parent set it entire sub-DODAG must resend DAOs. This is a significant = cost. If you use 2), then only that node needs to send a new DAO.

 

 

 

- Has the advantage of having multiple DAO parents been assessed with = respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent = set. The concern is that the vagaries and unreliability of wireless links call = for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward = routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger = to the entire sub-DODAG.

I understand how this would work in the storing case but in = the non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------=_NextPart_001_0983_01CB1F79.D06C6660-- ------=_NextPart_000_0982_01CB1F79.D06A1C70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwOTEzMTcxNVowIwYJKoZIhvcNAQkEMRYEFKdjnJirsVb6AHrn 4YgNzj7YQLxOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAGJcmq8WkLEyld83wu6gWPxxGemMpG0T2 aVqX4odaenbVfg+WPP4DzZyNVZ+wppESH38nFOPhV5GStXaO4/1HD2SD+/3sx78Mjadp0EX/9x7O KZ3iTVVCAx8FMiM5Bp4yLJuQaQmucKR8rkn22zjdwKh56LJTdeGz3E7/Mbcl6IwAAAAAAAA= ------=_NextPart_000_0982_01CB1F79.D06A1C70-- From richard.kelsey@ember.com Fri Jul 9 06:36:17 2010 Return-Path: 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 E06B33A6A2F for ; Fri, 9 Jul 2010 06:36:17 -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 Wak2jKIMGdhe for ; Fri, 9 Jul 2010 06:36:17 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id E83603A69BF for ; Fri, 9 Jul 2010 06:36:16 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 09:36:21 -0400 Date: Fri, 09 Jul 2010 09:36:45 -0400 Message-Id: <87zky0g4k2.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D024CD3BC@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8739vshn3u.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD3BC@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Jul 2010 13:36:21.0702 (UTC) FILETIME=[B7DF5660:01CB1F6B] Cc: roll@ietf.org Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 13:36:18 -0000 > Date: Fri, 9 Jul 2010 14:50:26 +0200 > From: "Pascal Thubert (pthubert)" > > RPL code only deals with native IP operations, so it does tunneling. > OTOH I do not wish to preclude any operation like the one you are > describing and I hope some specification will define it somewhere. > Do you see text that would bar or be problematic with this operation and > if so would you propose a modification to that text? Pascal, Here is one example: A router that injects a data packet into the RPL network MUST tag the packet by inserting a RPL Hop-by-hop option as specified in [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the RPL Hop-by-hop option. I am not sure what the best way to handle this would be. Your original email indicated that the draft would benefit from a fair amount of additional text describing the details of how the IP in IP tunnelling is to be done. On the other hand, if the tunnelling is optional, perhaps that text should go in another document? The RPL draft could limit itself to describing the RPL Packet Information and its use, without going into the details as to how the RPL Packet Information is carried within a packet. -Richard Kelsey From mdurvy@cisco.com Fri Jul 9 06:50:20 2010 Return-Path: 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 84B0D3A6839 for ; Fri, 9 Jul 2010 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.316 X-Spam-Level: X-Spam-Status: No, score=-9.316 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Z5gs+ro7ayBa for ; Fri, 9 Jul 2010 06:50:18 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A7A8F3A67A1 for ; Fri, 9 Jul 2010 06:50:18 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKvFNkyrR7Ht/2dsb2JhbACBQ4FanSVxpAmJKZE5AoQzcgSKdw X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="gif'147?p7s'147?png'147,150?scan'147,150,208,217,147,150"; a="156263184" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2010 13:50:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69DoJum027381 for ; Fri, 9 Jul 2010 13:50:23 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:50:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jul 2010 15:50:18 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_098A_01CB1F7E.6DCE5450" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication Thread-Index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybwAG+67A References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 13:50:20.0071 (UTC) FILETIME=[AB944B70:01CB1F6D] Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 13:50:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_098A_01CB1F7E.6DCE5450 Content-Type: multipart/related; boundary="----=_NextPart_001_098B_01CB1F7E.6DCE5450" ------=_NextPart_001_098B_01CB1F7E.6DCE5450 Content-Type: multipart/alternative; boundary="----=_NextPart_002_098C_01CB1F7E.6DCE5450" ------=_NextPart_002_098C_01CB1F7E.6DCE5450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 This is an important issue. Some comments/questions below. Best, Mathilde =20 =20 Anyway it appears that the spec could be clearer in: 1. Explaining why IP in IP is used in general 2. Specifying the rules to determine if a destination is inside = the RPL network 3. Specifying tunnel mode operation 4. Specifying transport mode operation and when it can be used 5. Specifying how to determine the tunnel endpoint in tunnel mode =20 Proposal: =20 1) RPL needs an instance ID in the flow label, and HbH header, and = eventually a routing header in every packet for routing and = inconsistency determination. The HbH and RH are nonsensical outside the = RPL network and can only be present inside the RPL network. The only = clean way to insert and remove those headers is to use a tunnel mode (IP = in IP encapsulation) whereby the router places the RPL headers before = the inner header, leaving the original packet untouched. a. A source inside the RPL network (router or leaf) places the RPL = headers and flow label in the packet, either in tunnel or transport = mode. Aren=E2=80=99t the flow label and HbH header mutually exclusive? = Shouldn=E2=80=99t we force the use of the HbH within the RPL network? = More alternatives mean more complexity. Why would a source inside RPL = use tunnel mode? (see also comments below)=20 b. For packets originated outside the RPL network, the first RPL = router (called ingress router) has to place this information in the = packet in tunnel mode c. Further RPL routers find the information and use it. They do = not re-encapsulate, they do not change the flow label, they happen to = modify the RPL headers. In non-storing mode, how does this scenario work? Host =E2=80=93 RPL ingress router (must include HbH)=E2=80=A6 RPL = routers =E2=80=A6 RPL root (must include source route in addition to = HbH, can it do it in the same IPv6 header?) =E2=80=A6 RPL router = =E2=80=A6 RPL route (decapsulation) - Host d. The tunnel endpoint decapsulates before forwarding the inner = packet. This strips the RPL information from the packet. If the packet = is reinserted into the RPL network then there is a risk of a loop.=20 =20 =20 =20 2) A destination is in the same RPL network if: a. The destination is the root of the DODAG (all modes) b. The destination is in the same Subnet as the source (derived = from a PIO) (storing mode only)=20 c. The node is a router that has a DAO state indicating that the = destination is a child (storing mode only) d. The destination has been seen as tunnel endpoint and thus is a = DAO ancestor (storing mode only). Not sure what you mean by the last point.=20 =20 =20 3) A RPL router that injects a packet without the HbH option into = the RPL network is an ingress router. =20 a. An ingress router MUST place the RPL information in the packet = in tunnel mode b. An ingress router MUST place the instance ID in the flow label = of the outer header c. An ingress router MUST use one of its global addresses from the = RPL domain as source d. An ingress router MUST use a tunnel endpoint that is in the same = RPL network (rules above). Doesn=E2=80=99t d. contradicts =E2=80=9CThe last entry, Address[n], is = exempt from the strict source route policy and may specify a destination = outside the RPL domain=E2=80=9D from the rpl-routing-header draft? I = think this also impact your point 4 and 5=E2=80=A6 =20 4) A RPL node MUST place the RPL information in every packet that = is sources. It can safely use tunnel mode for all packets. It MAY use = transport mode when it determines that the destination is a RPL leaf or = router within the same RPL network. In transport mode, the outer headers = are built as follows:=20 a. The source MUST place the instance ID in the flow label of the = IPv6 header b. The source MUST use one of its global addresses from the RPL = domain as source c. The destination MUST be is in the same RPL network (rules = above). =20 5) The tunnel endpoint is determined as follows: a. If the destination is in the RPL network (rules above) then the = endpoint is the destination b. If the destination is a host attached to a RPL router then the = endpoint is that RPL router c. Else the endpoint is the root =20 It appears that the b) is not supported correctly with the current spec = since we do not have a way to inject a route to an external host while = indicating that the host is not a leaf. Probably the router would present itself as parent in a transit option, = with a bit saying that the targets as non rpl hosts. =20 Opinions? =20 =20 =09 Pascal Thubert IPv6 Engineering Product Development pthubert@cisco.com Phone: +33 4 9723 2634 Mobile: +33 6 1998 2985 Cisco Systems France Village d'Entreprises Green Side 400 Avenue de Roumanille=20 Batiment T 3=20 06410=20 BIOT - SOPHIA ANTIPOLIS France Cisco.com =20 =20 Think before you print.Think before you print. Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 = limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum = Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, = 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel = Givone, For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 =20 ------=_NextPart_002_098C_01CB1F7E.6DCE5450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

This is an important issue. Some comments/questions = below.

Best,

Mathilde

 

 

Anyway it appears that the spec could be clearer = in:

1.       Explaining why IP in IP is used in = general

2.       Specifying the rules to determine if a = destination is inside the RPL network

3.       Specifying tunnel mode operation

4.       Specifying transport mode operation and when it = can be used

5.       Specifying how to determine the tunnel endpoint = in tunnel mode

 

Proposal:

 

1)      RPL needs an instance ID in the flow label, and = HbH header, and eventually a routing header in every packet for routing and inconsistency determination. The HbH and RH are nonsensical outside the = RPL network and can only be present inside the RPL network. The only clean = way to insert and remove those headers is to use a tunnel mode (IP in IP encapsulation) whereby the router places the RPL headers before the = inner header, leaving the original packet untouched.

a.       A source inside the RPL network (router or leaf) places the RPL headers = and flow label in the packet, either in tunnel or transport mode.

Aren=E2=80=99t the flow label and HbH header mutually exclusive? Shouldn=E2=80=99t we = force the use of the HbH within the RPL network? More alternatives mean more complexity. = Why would a source inside RPL use tunnel mode? (see also comments below) =

b.      = For packets originated outside the RPL network, the first RPL router (called ingress router) has to place this information in the packet in tunnel = mode

c.       = Further RPL routers find the information and use it. They do not re-encapsulate, = they do not change the flow label, they happen to modify the RPL = headers.

In non-storing mode, how does this scenario work?

Host =E2=80=93 RPL ingress router (must include HbH)=E2=80=A6 RPL routers = =E2=80=A6 RPL root (must include source route in addition to HbH, can it do it in the same IPv6 header?) = =E2=80=A6 RPL router =E2=80=A6 RPL route (decapsulation) - Host

d.      = The tunnel endpoint decapsulates before forwarding the inner packet. This = strips the RPL information from the packet. If the packet is reinserted into = the RPL network then there is a risk of a loop.

 

 

 

2)      A destination is in the same RPL network = if:

a.       The destination is the root of the DODAG (all modes)

b.      = The destination is in the same Subnet as the source (derived from a PIO)  (storing mode only)

c.       The node is a router that has a DAO state indicating that the destination is = a child (storing mode only)

d.      = The destination has been seen as tunnel endpoint and thus is a DAO ancestor (storing mode only).

Not sure what you mean by the last point.

 

 

3)      A RPL router that injects a packet without the = HbH option into the RPL network is an ingress router.  

a.       An ingress router MUST place the RPL information in the packet in tunnel = mode

b.      = An ingress router MUST place the instance ID in the flow label of the outer = header

c.       An ingress router MUST use one of its global addresses from the RPL domain = as source

d.      = An ingress router MUST use a tunnel endpoint that is in the same RPL = network (rules above).

Doesn=E2=80=99t d. contradicts =E2=80=9CThe last entry, Address[n], is exempt from the = strict source route policy and may specify a destination outside the RPL = domain=E2=80=9D from the rpl-routing-header draft? I think this also impact your point 4 and = 5=E2=80=A6

 

4)      A RPL node MUST place the RPL information in = every packet that is sources. It can safely use tunnel mode for all packets. = It MAY use transport mode when it determines that the destination is a RPL leaf = or router within the same RPL network. In transport mode, the outer headers = are built as follows:

a.       The source MUST place the instance ID in the flow label of the IPv6 = header

b.      = The source MUST use one of its global addresses from the RPL domain as = source

c.       The destination MUST be is in the same RPL network (rules = above).

 

5)      The tunnel endpoint is determined as = follows:

a.       If the destination is in the RPL network (rules above) then the endpoint is = the destination

b.      = If the destination is a host attached to a RPL router then the endpoint is = that RPL router

c.       = Else the endpoint is the root

 

It appears that the b) = is not supported correctly with the current spec since we do not have a way to = inject a route to an external host while indicating that the host is not a = leaf.

Probably the router = would present itself as parent in a transit option, with a bit saying that the targets = as non rpl hosts.

 

Opinions?

 

 

= Pascal Thubert
IPv6 Engineering
Product Development
pthubert@cisco.com
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

= Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille
Batiment T 3
06410
BIOT - SOPHIA ANTIPOLIS
France
Cisco.com=

 

 

3D"Think= Think before you print.

Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 = responsabiit=C3=A9 limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal = information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.h= tml=

 

 

------=_NextPart_002_098C_01CB1F7E.6DCE5450-- ------=_NextPart_001_098B_01CB1F7E.6DCE5450 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahAST7V/3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L8OpvbV6Ly3WpD7HxVvyWoZOWD40gGTtkZFfTJGnok8g 3137O00SA6kuTJ/LAAKpaX9aaLCRpGWGEziLfjMSgVNvUklRM/uCfUXleQTkkv2mYjExjM98vRH7 TwwskFN+3COA5M/KZrsvINk/5i15BWUVEkixOmllsjPOUfMxn1AkZOT0GkSEJKTivXUHxE1/eoG6 MK8cVQ4UkFoOvnhhyWZhshmEr/cY9wpkdV09QsksWpCp58VSVVfXK5DLfjcT42AgWRMfsPUaMCC9 zicIrcj3hWv37Gf7RffsznCQlZSZh+Onw+AWFosiCg6HwK76PxZIjgJt/MJFILFglyF2UATa226c oQRkI5k6X/Jf2S+cv9NARLfeEQlQ9LABeKgByWmn3465YiHd938fOAqr06FCOdzQQF4iU8d+1eUJ 2oTXl+/AUa9glQCSc4jbLZzF659b/AueI8A2mdj3qCWHGpDc18QVuzCGxjF60UbhLydl5d3YQCZn FWDmFi08/Nlq4bONJGdfx+mMSgBZQ0CuJe342Bdq1Pc6PPq5GlZpHhOVGFUA0pgifPZjH5+7lu7/ T5ix4Qji0rJvbCBTcgoxb6e+CFIYgrHLtsDILUAlgKwlIH8hjciwMGC8Z5HNN+cbVQFITnGN//c2 oQT4Gp9v0xGbgm94IOfs0CPtuFZA8MLSzTB09e/x9cHxqe1R9oLBi7JH9SPKZiA3GNsJEBmwp6n/ NXonegXyyij790GJstXps6r3GWVzkn7ct1sxgoDkzzp7q7Y4EHdDA3kxuxBfbtfFE3PWipv+/JJN MHDpDcihk4dkINcbnRLjGCW0zDqo6dr0CORg5yE9WvOQT/YzD2nmESws0oiFl3fTzyLXiQOdGxpI zoHxacAxpC1YK/GBJusz4T2+PuJipjgXI6oR1GYMcKXmqGeIKBuKSs3Xv+BHrZ4rNZyeYqDGf7tN vH7c0i3YZeUqUkHdyeVKzQkKfjaJSgpXagxdAwYMyMDYi5i5WUuMhfv/bKuOSEn1JLyBhM8bjfpq PZ75aqOItFNyCm5sIHljhI7jGUxXPyRA4E0HIWSWexKuZe+ydBU3kuHdYGTXq99ztUD6xySLieGx sJNv6BKAsh5q2by7xjEoCnN36Ito9YttujgVEIGGHvKorDnNPILw8UYNTCRXg4/mno5MHDAgL2Tl Y4upA976ca/QjnzCMjWn51p2eFI6VlIQxn74++sOknXwQUHpH54g/2OBrG1oQBCZYU6XLD9kCTPP oF7PHnM1xD0sDmt0T1BEe1wAV1RROWBA8hFZPv/8/UELbDNzFMdOe0rUc7ktISMPh0564bsD5vjd xgNx6dk9Ph2DE9F8wIw3PfyH+tdz9sOlXjY/XMtuH8fgKKwmrf6TtjX51tFi+1xPwnsyLbxDxM6m jbSw/WMuoKbuD38QwdCo1PiSr8N7BC9k5fVaqeGaMQcHbgSlU3C0MPm97YfkU4cvdzh1+H4fpw45 t5iQnotT/ufhH933fkg2zwy4rd85hCWloaq250oNA8wPKQiITRZP0Yjr40kUfOrwQ3HqcK0InMb1 cepQ0fqkC+eQGLiSX80PSWhs6rnG3tDYSD58PuwDI+ETkSisVXPzDV6pUUopTRRvKOWb1Ke07oou 6MeOcceQKHL09wgNyVByJBmVktnre9jk8mSW9XPbWQ1BmVNUiqoefMfutHxOUVmfdXsOML78VZei d3WhISet2A1bArmvBV7QtmO8b7i4qsQLvPSPr9AMLSCVGqT/r+3f69kf5ceQcL6Nj8OqG5zs1x7B q63pDsbrM8hfZlPK4+bAadFuIwTEXOzXfby6ezmkDjv8uU8d8g5wbQdfEZl/s8cYNhTBD4F6bb+E 3QXWiEtoQbGmPEJBx6Xcoj/rVN0YQFbX1+Mc+Xi6TmdEhJtMPlPDAB1JGGxhc3qRomRzz2CRiQjt w0eVQKqAsDli3463taUQjIpG1YCxDUoKVFJzCoQ/yWmjIWZeJZDXPLEEYmOTajwX8kppoki5QcUW kgRSigRSihQJpBQJ5FCWpro6NNbUoImiafF9dTVaBtFX5Osor9d4nddrVijE+5tqa0Xj75sbrr50 J96rHBN9VVRVoUV1fU7VA5LjzCaauKqsLGT7+CDNwQEZLi5Id3Ki5oyiyEgxMS3d1ZT5T2zQxDWU l6OuuFg0/p5hbunlKGtzYxOq8/KQc+ZM+/WcnZHu6IiCc+fQUFmF5n6C2Uyw1JWUIC84RIw5w9VV tDT6Pi8wUIypP0Dx9apzc5HNY6JxiDGJ5oqiqCjxmSSQg60RFY0oTknFBTt7BG/7FW7z5sH+rbdw auJEnJowAQ7/mg6/1auRameHusLCTiAqNSpP4Fl1dbjNnAlXasFqashwd0dDRfc7Xero5xkBgQjd tx/uCxe1Xc+OmuP778Pn++WIMTFFceKFXrUlp2wqc/OQ5u2NcwcOwHPJUjh+OAP2770vGo/de+ky xBsYojQhkYBr7nFBcj85gUGI0dGF97ffwf6dd2hMk2BH/bh8MQdBGzYilRZO2aVLaFKRvzqhckDW k9ZLP+2LgLXrcJJuvNnIUdC/915o0vAPtzatm2+G2ajR8P1hJUoSEroAqaisRLyhIazHjcMBev3v 1KxGj0bUwYOoKei6F7CKJj7xuDXcF30N8xfGQv+v90OD3nOo9Xp8bd37H4DNm5ORdNwGjT3UpxvJ POfHxOLcoSNwmj0bFi+8CIMHHoT2rbeK/rhp0tiNHn0MzrM/Q4qDI7kEXWvjjGjRhWREamrBkxbH CYLQ+LHHoUXvP9I6Hv17/wrzMc/Cafp0BG/ajAzfM+JzSyAHSJilOrqhKR4ecFu0CEb33Qdtmjxd GrZ2a9Np/coTo3PHHXD84kvkR0R06YsnJtHMDKcmTRKTxyDYjB+PGC0t1BR1LsvVV1Uj2d4B9h9+ BP177hHX4MbX1Rs2DHoEk95tt0HjlltgRAsj6vARKBSKbrS6Ajlk1v02boLFuPHQoffpdBiz8nvN 1v9bEWQxZkehuOJBUax9C2PjELx9B4699jr07rhTjKXjZ9fq0Kce3SPjx/4Oj0VfIZ1cgoYKlYBy 6ANZT85+iocnXOfOJa3ygJg4rQ4wGhAspqQtTZ58SkwQ/85+1izknT/fVUOSw59kbg67yZPbJtH2 tdcQq6OD2iuAZE0U8MsmmDzyqABXqxVG85Ejcep/34MdmVtu5i+NFxovzsCoi5llPy+XfFrfn3+G 2egx0CKQO45d7847YfzEkzAbMQp6d90lfmfx6muINjahsbbX3Hn0ZWlpCFr3M0yffho6tBA69tO2 MIfd2gVQo4ceggdp00w/f+HySCCvU0oupuC02loYPviQgFGn9UazdrImTeH17+8Q/OsOAY87+5TT P4Cf+noUKU12h0fK9hdIDjxSvX3gNIcWAWkiASNdz3zMGASsX49Udw/yBX1wydMbscamiDiiibzQ cAqMOpf26ihgCj+iAbMXx3ZaSLq33Q6L51+A64KFCCCzyuP3WvYtHD/6GB70NZlNdofjtHU07sST drAhWA937Ie04NGnR8Bh2jR4z5sPD/r8J96YDCNauErNy4vJ5O+PI5Q0a0V6hgTyeoRTI6nOLjgx 5S1ok2lUmkxd0ia25LdF6ukjLzoGFdnZKCUHPvfceaS4uSHd5zSq8wuuGcjG+gYy146wJ0CUQLI2 s546FbGmZqgpKRWmWIyRIGwgbaaore0UqQsTS36j+1dfQ/d/7mo3+bffAStaSEE7dyEjKBhlBEl5 Zhby6XOk+fggxdUNRXHxaOrgjxbGxcFnxUoBltIkM9RWpJn91TfgEpnk0thY5J89i2gjYziSH2pE vq0OActjN7j9drh88gnS3dwlkNcjFTnZCNv9G0zJ2VdqR30C0/bttxFF0WgVBSLKIwMiHUQQMBgM SHM35qnfGpL6zPDyhvuXX8Ko1ZTq0nWNyfy5z1+IWHNLZIWEoDInp8cjC7VlZUi0PoGTU6Z08nUt xo4VMBYlJ3cKgrgfBaekaIyNDHfrIuJ/OWI+PnYcNG+97bJ/eNPNMH/+RQRt2UqWIFF8Zl50zY0K VBcWId7qGOw/+EC4M8rrmj/7HKK1dXpNb0kg+xCOTE+v+AFGd98jgORmQKYzkHypiryrPyHXG5BX BjWlBEyg2hro0/UOdQg+TB76G6wnTITzp5+KFFPCseMoy+y6C521dtiBg6TFXmgPuG6+CW7kBuRG RPZ7zA2krWP1DWD24IPCXGuLRTmMFsYCZIV2f8aGNW7Yvn2weOaZNvOuf/+Dwmy3DO1NJkMbyGwy wZ7kIxrdc6+4sewPGZLpjNPSvqb+rgbIBtI6yba2ODV5CvTJf9XpECi0TfLdd8PmrbcRums3iuMT hO+plLL0dATTz4+OHt32Hl0CMkhNTSTS+yu15RWI0tTC0UcvB1fKRRmyYSOqCrvfsKuoq0eykxNs 33ijPSC7626c3bxZAjkYQMbr6Q06kGwqawoLkeLoCO8fVpKJfF6Y7SsjW23yCS2eegrh5FqUZ2V3 BbJVSymj9OC1a7vNMfYKpIZm90AWFPYMJI3bdtKkdiD/8hcJ5PVKPjnzvitXdTbZ5KCHbduG2tKS q+7vaoBse09DA7kOMYg1MYEfjcV15iwcI8j0WoHUaP3q+PEnuESRd0trZaSC/MvwQ4dh9eKL7Sab mvfX34jMQX+lvrZOVGRMSUsrI2z9YcPg881iFEZFdfueitw8hB08CMsxz7YtBr377sNZum8SyOuQ 8qwshFIAYPrY39sSx5yUdvrkUzJJzqjv5q8McO6PI+A2573DLutrAbKjcBCVExyC0C1bYDFylKi0 6LSmX46TXxljZCI2XVzWbOXCv7TloIZ+r9SoNhMmiOxAZV7XR9/x4S8euzD9ynInfZ5k25M4xqkj up4y3WPzyiuIOnCgPZvQKuxqXHR2pUh7Ngzv+2vbdY1Ji587eEgCeT3SQMAlWtvgxJSposKh3Wr2 OP3hsWSpSJFw8FBXVi6AKk9LR35kFAqiY1BPUe7lWW7uV9qnE5AcsfJuHN6Jc8UOHAYmOyAQDp/O hF5rFMtjsnr5FUSSJmuovpzQ5hpyFsHLuUY98jWVKSsDgsRuxkeIPWqOkpRU1JaUoo5aBZn7wrgE 5J6PoKAks5M/yp+J863GjzzSXt2543acevNNJFhYojwjA/Vk2vl9XNHy+n45TB9/XIArFjHdO9t/ TkMSgT3Ej0EMbSA50VwYGwvfFStgQlGm0uzxjTYhrWk/7V0ErN+A89o6IqINIL/K8z/fI3jHTpQk JbVryKvMQ7J2rSDtnO57hibxFC66uiMrLAw5ERHIpwg5ljSc9auviTKlEhCrV15FlJ4BFNXtFZaq /HyE790Ly2efbYvSuRnefz9s334HvmvWIvywBs4d0RApHM418s9SXFwvp3JahRdckpUVbF9+uc1F EPlF8qdPvvEm/Fb9iLC9+0VxwHHmTJgNHy7ukbIkafzwI/Bf9zMKO9b3JZDXqCUrKpBC0a7jv6ZD lyZA84qgwvjRx0S5zXzsOBjTROiT828/azZyw8I6abyrAVKU/MLDEbR5K+xnfAx78hs9li4TzYt8 NzuKXg1I67T5Z1w/J42Z4uLWSaOKfoKC4LNsmSjhaXTwJTlpbchj59Lj+Jdh8vQIGJAGtJw4SeRY OR/Z4QOgPDkZAatWweChh7qUT9k0m416BibDn4IeBVlaHaDVv/c+OM3+DJfc3NFQM+T/kJJq7Pap zssn7aMvEuIGd7VXPbS621xB0Dp+/gXyzve8ueLkxIntmyteeklsrrgyMZ7l5wcv3szBEf4tw0Q+ Utn0Omg7vdtuxzHSjudIQ3P+78q/fMmbJHj3jsucuTB8/Anq65a28XbZXEG/s5wwCTGmZl02V7AJ T/cPEK6KCe8UojHpdFPP1u5QVuRyqyMtJnZ7aopLhvo0qw6QLBU02fHmFnCnKNX8pZdFOU6jddvV kQ5b0HTvuBNui5eQPxbfFUjStvFGRrAePx4H6bW8Bc2KIuaoQ4dEiqddobYgkzSb6/z5YnL3t245 69j42kYPPwy76R/i7O49KIyJExt5u5Pa0lKkkobyXbMOx96YDIMH/9Zp7Nx4PBoEmc277yGR3ITG bp77U09mPIv81wAy69Zk8g3IjdHs0IcyLcT50WOvvw6v777HhVP2qC0uVoUpVi0gxcRSoJIZFIwI HT2cJsfd8Z13YE/m12HqVNhTNMum2HPefAFuFWnVK4W3++f4+yOMomTPOXPgQe3s+vXI9PJCwxV7 BkvT04VWdp0xQwQPfA1l4+s4krYOUFPDBXsHFJM5bVL0/qweRW0d8mJiKZixQID6ejiTibejYM2B xs3tJPXpPOszEQkX0Ot6Kkky9EWJSYg/bg2/n36C07RpbfdA9EXj8l68GNFk9rNDw1BXPmT+Bs2f D0ihvWiimkh7VFF0nePri0xXV2QRUJkUXWa4uaE4KupyLbiHIwwieuazJwQgN/6ef3alqeX3sxnP CwgQRwz4GsrG1+HjE5UU3bIp7W/g2tKa1qkjjZkfGir6yfL0FI2vkR8SIn7X13EIUbenfqpzcsSx io73INPdvfd7IIEcPGEY+FgCBxLioFd9/YBfo6XjNZSNrtPch0bse/DNnfvlcz3XkCPscg84D6q6 T7iQx2ClSCClSJFASpFASpEigZQigZQiRQIpRQIpRYoEUooEUooUCaQUKRJIKRJIKVIkkFIkkFKk SCClSCClSJFASpFASpEigZQigZQi5Q+U3RJIKUMSyF2yyTYE2nsCSP5HNtmGSvs/hQgkdONYbE8A AAAASUVORK5CYII= ------=_NextPart_001_098B_01CB1F7E.6DCE5450 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_098B_01CB1F7E.6DCE5450-- ------=_NextPart_000_098A_01CB1F7E.6DCE5450 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcwOTEzNTAxN1owIwYJKoZIhvcNAQkEMRYEFHtITrXP7WLH4cn0 V/UvsdQJnMMYMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAKnazJeDKk6jq9jxxSaLE213UxqoyvXoE 0PGquVudpS84QLgfhGsHJbWGj9P9hY5ojZeCNSDlhT7N22YN6daElD4JqEmxdDvo7vOOPnhG9bO4 3rq+7L0g0a/whD8I5mcMvm4+DZTZ9HHTR8v90yIgk92fj770vDmNz2UlYLCtMpoAAAAAAAA= ------=_NextPart_000_098A_01CB1F7E.6DCE5450-- From pthubert@cisco.com Fri Jul 9 06:51:32 2010 Return-Path: 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 3C38A3A67A1 for ; Fri, 9 Jul 2010 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.745 X-Spam-Level: X-Spam-Status: No, score=-8.745 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, 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 41V2Lqafqrhd for ; Fri, 9 Jul 2010 06:51:21 -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 BEC903A6A67 for ; Fri, 9 Jul 2010 06:51:19 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.png : 837, 1465 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusKAOfFNkxAZnwM/2dsb2JhbABzUJ5/caQCmmIChSUEinc X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="130455385" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 13:51:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69DotSJ000569 for ; Fri, 9 Jul 2010 13:51:24 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:51:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB1F6D.CFA6F7B0" Date: Fri, 9 Jul 2010 15:51:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD3FB@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0A6@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Transit and Target address mismatch thread-index: AcsdCoejDG6UKjQ3Ta2pAgc9CJPsdACU2uaQAAHhG3A= References: <6A2A459175DABE4BB11DE2026AA50A5D0243A87A@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0A6@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 13:51:20.0740 (UTC) FILETIME=[CFBDA640:01CB1F6D] Subject: Re: [Roll] Transit and Target address mismatch 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: , X-List-Received-Date: Fri, 09 Jul 2010 13:51:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1F6D.CFA6F7B0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB1F6D.CFA6F7B0" ------_=_NextPart_002_01CB1F6D.CFA6F7B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde =20 So based on your comments here is my understanding of the current specs. = Please correct me if I'm wrong. =20 In the non-storing example below we would have: - A sends DAO with "target Ag, Ap, transit Bg" - B sends DAO with "target Bg, transit R" together with the information = from A, i.e. "target Ag, Ap, transit Bg" =20 [Pascal] The "together with" above is not to be taken too strictly. B = could pack the 2 messages together with -10 though it it not required at = all, and if we go for end to end DAO for non-storing then they are = definitively 2 different messages, one from A to root and the other from = B to root, with source routed end to end acks. =20 The address Bg is on-link, although it is formed on a prefix that is = advertised as not on-link. [Pascal] Yes =20 This is possible thanks to a flag in the PIO sent by B that tells A the = PIO prefix is also an address (in this case Bg) that has to be = considered on-link. [Pascal] That is the R bit in 3775 that we are missing as Navneet = pointed out. Will be fixed in -11 =20 Now, my last question would be, how does R knows that Bg is on-link = (when source routing to A)?=20 [Pascal] I think that the clarification to that belongs to the RH spec, = not the RPL spec. I spent quite some time in the RRH spec explaining which address must be = visible in a multihomed router. https://datatracker.ietf.org/doc/draft-thubert-6man-reverse-routing-heade= r/=20 In very short, what's really needed is that the next hop when forwarding = a packet is on link for the sender. So Bg should be onlink on the R to = Bg link, and Ag should be onling on a B to A link, B's address being = anything. R should be able to resolve and NUD Bg, B should be able to = resolve and NUDAg, etc... =20 I really think that this should be clarified in the specs. In = particular, it seems that for the DAO part to work: - Nodes must use the PIO sent by their parents -- to configure their own global IPv6 address -- Install a prefix that is not on-link -- Install the global IPv6 address of their parent as on-link. In = particular, this means the PIO has to be included in the DIO for a node = to adopt a parent as DAO parent.=20 [Pascal] I did not explain that well enough it appears. The child = address is onlink on the link where the PIO was received, so that the = parent can forward the RH packets to the child. The parent (PIO) address = is also onlink in the classical RPL case where the routers have a single = interface, but not in the general multihoming case, because that address = is oriented towards a parent. =20 - Nodes must use their global on-link IPv6 address as target in DAO [Pascal] True, and they can have other addresses on other interfaces, a = hosts attached. For all those leaf addresses, the router should = advertise a DAO with self as parent and those other addresses as = targets. We're missing this additional bit that indicates those leaves = address that are behind the router, for which the router terminates a = tunnel. =20 - Nodes must use the global IPv6 address of their parent as transit = parent address. [Pascal] Yes. Then again, there can be multihomed routers, with = interfaces up (towards the root)and down, and a different address on = each. In the multihomed case, the node may have multiple links to = multiple parents and children, and thus form multiple addresses for all = those links, eventually from a same prefix. The address placed in the = PIO(s) is/are on links towards a parent. The transit/target pairs must = match so that the address advertised as target must be installed on the = link from which the PIO advertised as parent was received... =20 So I think that the text must indicate that: - A router forms a global addresses from the prefix in a parent = PIO: o assigns that address on the link from that parent so it is onlink = there o advertises in a DAO that address as target with the address from the = PIO as parent in the transit info - Once this is done, the node can advertise that same address = in its own DIO as a PIO, regardless on whether the address is onlink for = the children =20 =20 Is my understanding correct, does everybody agree on that? =20 [Pascal] Would you agree with might limited rewording above? =20 Cheers, =20 Pascal Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 6. juillet 2010 14:56 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] Transit and Target address mismatch =20 Hi Mathilde: =20 Yes we can improve the text : ) =20 Yes, all the RH are based on global addresses. I tend to think that the = non-storing mode should even use global addresses as source / = destination for DAO/DAO_ACK so nodes talk directly to the root as = opposed to sending DAOs hop by hop. =20 And no, global addresses are not off link. They are not expected to be = all onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a = strict source routing. So a node should be able to NS those addresses to = assert continuous connectivity. =20 One even more tricky thing is the use of IP in IP that seems to be = generalized now as soon as we insert a RH or a HbH option. I think that = the resolution of your issue should also clearly state what are the = tunnel endpoints, in particular when the destination on the RPL side is = a dumb host. RPL should be able to differentiate the last router from = the target. =20 Cheers, =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 1:17 PM To: ROLL WG Subject: [Roll] Transit and Target address mismatch =20 Hi All, =20 Let's consider the storing mode in a simple topology A=E0B=E0R (=E0 mark = the parent relationship). Let's also assume that A has a prefix 'Ap' and = a global address 'Ag' to advertise. In this example we have: - A sends DAO with "target Ag, Ap, transit B" - B sends DAO with "target Bg, transit R" together with the information = from A, i.e. "target Ag, Ap, transit B" =20 Then R recombines the information to get the route to for example Ap = (Target Ap, transit B, target Bg, transit R) For this to work, transit B and target Bg need to be matched. How can = this be done? Does it mean that the transit parent address has to be a = global address? This would imply that we use global addresses in the = routing header. However 6man-rpl-routing-header says: "When processing the Type 4 Routing header, a router MUST drop the = packet if the next entry is not on-link" As global addresses have to be off-link in NBMA network like 802.15.4, I = see a problem... =20 Can you please clarify how addresses are supposed to be used in this = source-routing scenario. =20 Thanks, Mathilde =20 =20 =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. ------_=_NextPart_002_01CB1F6D.CFA6F7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Mathilde

 

So based on your comments = here is my understanding of the current specs. Please correct me if = I’m wrong.

 

In the non-storing example = below we would have:

- A sends DAO with “target Ag, Ap, transit = Bg”

- B sends DAO with “target Bg, transit = R” together with the information from A, i.e. “target Ag, = Ap, transit Bg”

 

[Pascal] The = “together with” above is not to be taken too =A0strictly. B = could pack the 2 messages together with -10 though it it not required at = all, =A0and if we go for end to end DAO for non-storing then they are = definitively 2 different messages, one from A to root and the other from = B to root, with source routed end to end acks.

 

The = address Bg is on-link, although it is formed on a prefix that is = advertised as not on-link.

[Pascal] = Yes

 

This is = possible thanks to a flag in the PIO sent by B that tells A the PIO = prefix is also an address (in this case Bg) that has to be considered = on-link.

[Pascal] That = is the R bit in 3775 that we are missing as Navneet pointed out. Will be = fixed in -11

 

Now, my = last question would be, how does R knows that Bg is on-link (when source = routing to A)?

[Pascal] I = think that the clarification to that belongs to the RH spec, not the RPL = spec.

I spent quite = some time in the RRH spec explaining which address must be visible in a = multihomed router.

https://datatracker.ietf.org/doc/draft-thubert-6man-reverse-r= outing-header/

In very = short, what’s really needed is that the next hop when forwarding a = packet is on link for the sender. So Bg should be onlink on the R to Bg = link, and Ag should be onling on a B to A link, B’s address being = anything. R should be able to resolve and NUD Bg, B should be able to = resolve and NUDAg, etc…

 

I really = think that this should be clarified in the specs. In particular, it = seems that for the DAO part to work:

- Nodes must use the PIO = sent by their parents

-- to configure their own global IPv6 = address

-- Install a prefix that is not = on-link

-- Install the global IPv6 address of their parent = as on-link. In particular, this means the PIO has to be included in the = DIO for a node to adopt a parent as DAO parent.

[Pascal] = I did not = explain that well enough it appears. The child address is onlink on the = link where the PIO was received, so that the parent can forward the RH = packets to the child. The parent (PIO) address is also onlink in the = classical RPL case where the routers have a single interface, but not in = the general multihoming case, because that address is oriented towards a = parent.

 

- Nodes = must use their global on-link IPv6 address as target in = DAO

[Pascal] True, and = they can have other addresses on other interfaces, a hosts attached. For = all those leaf addresses, the router should advertise a DAO with self as = parent and those other addresses as targets. We’re missing this = additional bit that indicates those leaves address that are behind the = router, for which the router terminates a = tunnel.

 

- Nodes = must use the global IPv6 address of their parent as transit parent = address.

[Pascal] = Yes. Then = again, there can be multihomed routers, with interfaces up (towards the = root)and down, and a different address on each. In the multihomed case, = the node may have multiple links to multiple parents and children, and = thus form multiple addresses for all those links, eventually from a same = prefix. The address placed in the PIO(s) is/are on links towards a = parent. The transit/target pairs must match so that the address = advertised as target must be installed on the link from which the PIO = advertised as parent was received…

 

So I think = that the text must indicate that:

-          = A router = forms a global addresses from the prefix in a parent = PIO:

o   = assigns that = address on the link from that parent so it is onlink = there

o   = advertises in = a DAO that address as target with the address from the PIO as parent in = the transit info

-          = Once this is = done, the node can advertise that same address in its own DIO as a PIO, = regardless on whether the address is onlink for the = children

 

 

Is my = understanding correct, does everybody agree on = that?

 

[Pascal] = Would you = agree with might limited rewording above?

 

Cheers,

 

Pascal

Best,

Mathilde

 

From:= = Pascal Thubert (pthubert)
Sent: mardi, 6. juillet 2010 = 14:56
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: = RE: [Roll] Transit and Target address = mismatch

 

Hi = Mathilde:

 

Yes we can = improve the text : )

 

Yes, all the = RH are based on global addresses. I tend to think that the non-storing = mode should even use global addresses as source / destination for = DAO/DAO_ACK so nodes talk directly to the root as opposed to sending = DAOs hop by hop.

 

And no, = global addresses are not off link.  They are not expected to be all = onlink for the purpose of ND lookup, but some may be. And this text = expects that those used for RH are effectively onlink to enforce a = strict source routing. So a node should be able to NS those addresses to = assert continuous connectivity.

 

One even more = tricky thing is the use of IP in IP that seems to be generalized now as = soon as we insert a RH or a HbH option. I think that the resolution of = your issue should also clearly state what are the tunnel endpoints, in = particular when the destination on the RPL side is a dumb host. RPL = should be able to differentiate the last router from the = target.

 

Cheers,

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 1:17 = PM
To: ROLL WG
Subject: [Roll] Transit and Target = address mismatch

 

Hi = All,

 

Let’s consider the storing mode in a simple = topology A=E0B=E0R (=E0 mark the parent = relationship). Let’s also assume that A has a prefix = ‘Ap’ and a global address ‘Ag’ to = advertise.

In this example we = have:

- A sends DAO with = “target Ag, Ap, transit B”

- B sends DAO with “target Bg, transit R” = together with the information from A, i.e. “target Ag, Ap, transit = B”

 

Then R recombines the information to get the route to = for example Ap (Target Ap, transit B, target Bg, transit = R)

For this to work, transit B and = target Bg need to be matched. How can this be done? Does it mean that = the transit parent address has to be a global address? This would imply = that we use global addresses in the routing header. However = 6man-rpl-routing-header says:

“When processing the Type 4 Routing header, a = router MUST drop the packet if the next entry is not = on-link”

As global = addresses have to be off-link in NBMA network like 802.15.4, I see a = problem…

 

Can you = please clarify how addresses are supposed to be used in this = source-routing scenario.

 

Thanks,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy Mathilde
Software = Engineer
Technology center

mdurvy@cisco.com
Phone: +41 21 = 822 1725
Mobile: +41 76 396 = 8116

Cisco Systems International = S=E0rl
Av. = des Uttins, 5
CH-1180 Rolle

Cisco home = page

 

 

3D"ThinkThink before you print.

This e-mail may contain = confidential and privileged material for the sole use of the intended = recipient. Any review, use, distribution or disclosure by others is = strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this = message.


------_=_NextPart_002_01CB1F6D.CFA6F7B0-- ------_=_NextPart_001_01CB1F6D.CFA6F7B0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CB1F6D.CFA6F7B0 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAU5SURBVFjD xVdbTFNZFL1FFE3UoBgFBBQqIi/xEQUN+mEiH/7ph4kJmpAQlRiN/mGCMSSDDqLOgEAfNIC0PFpb ecdIeavgoCMQOgzC8BYQ5SnIU1hzz7mXRwdayFBmbrOa3ra5e5191l57Hwb/88WY8mEN3xqQ8DEB sioZMloyMDA+8N8QGPsxhq+jX3G/8j5s5DbYFr0NPuk+0DRqKInJqcnVJVD2uQzX31yHs9wZzK8M mAcsYhgcUx+jpFqGWlaXgPaTFufyzsE+3h6MiA0ezcBCbAEXhQtult1E/UD96hLoHulGaVcpAosC YS41B/OIwS7FLoS9D0NlTyWGJ4ZXl8DQxBCKO4sRUBDAEXjMwEHugNCKUFT1Vq2eCH9M/6CrU/2l womsE9gq3QqBWEC3YZ1oHazjreFf6I+KLxUYmRzB9PS0aQk0DDYg7EMYfJ75UNExkSzELKScCIkg N0o24kzuGSR+TMTg+KBpCVT3ViOwJBCOTx1hLjbnBCjhQYiw95vEm+CW5oZ7H+6hd6zXtAT6x/tR 3l2O4PJgWCdZg3nCB5bwGWBxWH0Y0bpo6Pp0GJ8aNy2BafZFRBbyNgQ2STaLEjiiPgJJrQRN35pM J0IiJrIaYkDnteexQ7YDgljBoltgEWsBe7k9bv92G+3D7ZiYmlg5AWK7sjoZ/LL9wESxge4ztPbp qiW8CAmBJ7wr/szAMs4SAcUBeNH2AlPTUysjQMQU8i4EXmle8Ej2gIfKA57PPGkfEEjYTMQyWC9b D8cUR/q9u9IdngpPHM84jqT6JNNogFRAdnM2CtoKUNJVgsLOQlx5dWXWCXen7EZ4ZTj9raSzBHkt echty0XrUKs+gezWbGiaNFDUKyg7eb0c6iY1yPeGkNuai/xP+dR+Z0CckBKImyPwoOqB3n8okfY8 vWcxzmnOcFG6wFXlin3Kfdibthd7UvfAKcXJIISpQrgqXeHxzEMP25O2c3sfw22BU6oTDqgPzMJL 7QU3lRtIzBkwTAQDu2Q7BL0Kwq2yW7hYdBFbErdwwvqJE9Cy8ZB3QxEvwmjODY2CNA6/HD8UdBTg 88hn9I314c67OxCmCCF8KqSrNQQiMjuFHRWfrdyWfrZV2MJCZsFVxBOeRDRfIaJFQH4UJglxqfAS ijqKqDA6v3dC266FtlVLe70hkJJ63vwcqkbVLIjp+Gb6cpkgpRnFI2aeSc0HfeP/cPblWWS1ZFHB EIs1iC4WneW0Gf3zIuOX6A8RTuecxul0FrkcSMZIeeq55SyBWI7A5vjNVIyHNIfgne5tGGoWSm9c Lb26KIkvo1+g69VB16OjPYCAbCvVVhSj75izzjXj35HLwGNOcJYyS1wuvoyc1pwlJ+Ca3hqEVITg qPIozCRmc66ptx9iA0IxBHY1ghgBLhRcQONg45LmReaB4LfBnFfMzA4LRLFckKz9wiKcwcmsk6jr r1uWg0ZUR2CtbC1Xgv+KQCwvWnYFZjFmcE91x933d9Ex3GE0cNf3Llpl/vn+WCNdMydGo8HEi0DE K5kl4KZ0Q1xtHO315HBi7NI0a3Aq+xSsZdazc+NCDUgWaaeRvGM94u73q/cjqDgI14quIbImEj1j PctKPWnf1KAe8ouQGiPABidpImVp9dQKVokspFZwSHagJ52e0R4MjA1geHJ4ycBkACGjG2lMlgmW 3GIWlOF88CebnYqduPHmBqR/SiGtZVEjpZOtsVOOofIL/T0UvmpfbIjbwGlIbIxALJfyg5qDeN31 esWHlszmTNgns0e2CN5npPrx/gbw8N1A6QE+ygAAAABJRU5ErkJggg== ------_=_NextPart_001_01CB1F6D.CFA6F7B0-- From mjohn.info@googlemail.com Fri Jul 9 05:50:45 2010 Return-Path: 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 2BA3B3A69BF for ; Fri, 9 Jul 2010 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 zA5tS7U2JHVl for ; Fri, 9 Jul 2010 05:50:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 989EE3A6A6A for ; Fri, 9 Jul 2010 05:50:43 -0700 (PDT) Received: by wwb24 with SMTP id 24so4045295wwb.13 for ; Fri, 09 Jul 2010 05:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=wmyzVXetZBETXeLPUBncjMpPwnp8aT6Qe2U/aTnHHOk=; b=laIPCjLYryPobnuFNBadRx7dkEIakxKyWFynsU3ec03wLjlse4iKi4LTTnBBbuJZ6D qjsrbIKkOQXJ4totd2w+d8x4lGCssu9cEvKad9lGQGpZtrt09+dqcbIeMRWh+HqAvnWe f5gecy4JY4pQmj4S3+zaiYt0aX9J0mAodFIOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SmD9DAguWhbLtPCk+rb1tPHscmc/Q5H8wmt3yjTpmugF5jy4Y6kq5559ilP9JrnOxj RTjt9vbuRhsfFCfdf/YkFL4B8Ghc5OcJIOMbHpenl61rIcLItvzQlO8ZxCo255/93ViZ WmE7hddWM+T7RTVNtJVYj+dNy+8Zzi5Pq8x1Y= MIME-Version: 1.0 Received: by 10.227.142.203 with SMTP id r11mr8243826wbu.134.1278679843228; Fri, 09 Jul 2010 05:50:43 -0700 (PDT) Received: by 10.216.230.86 with HTTP; Fri, 9 Jul 2010 05:50:43 -0700 (PDT) Date: Fri, 9 Jul 2010 14:50:43 +0200 Message-ID: From: Michael John To: roll@ietf.org Content-Type: multipart/alternative; boundary=0016364c75b7d64d80048af3d9a8 X-Mailman-Approved-At: Fri, 09 Jul 2010 06:52:37 -0700 Subject: [Roll] Using ECMP 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: , X-List-Received-Date: Fri, 09 Jul 2010 12:55:49 -0000 --0016364c75b7d64d80048af3d9a8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, I am new to the list (first post), but I have been following the drafts for a while. I would like to ask the group if the current draft of RPL would allow the use of ECMP (equal cost multi path) forwarding or if there is anything against it? I could see ECMP to be benefit in battery powered networks where using one preferred parent =93all the time=94 might not be the optimum. On the other = hand, this problem could be addressed by a dynamic metric which is incorporating battery lifetime. Once the battery is drained too much of the current preferred parent, the metric would get worse and another possible parent would appear to be better. Nevertheless, I am sure ECMP could come handy in other cases. Michael --0016364c75b7d64d80048af3d9a8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear all,

=A0

I am new to the list (first post), but I have been following the drafts for a while.

=A0

I would like to ask the group if the current draft o= f RPL would allow the use of ECMP (equal cost multi path) forwarding or if there = is anything against it?

=A0

I could see ECMP to be benefit in battery powered ne= tworks where using one preferred parent =93all the time=94 might not be the optimu= m. On the other hand, this problem could be addressed by a dynamic metric which i= s incorporating battery lifetime. Once the battery is drained too much of the current prefe= rred parent, the metric would get worse and another possible parent would appear= to be better.

=A0

Nevertheless, I am sure ECMP could come handy in oth= er cases.

=A0

=A0

Michael

--0016364c75b7d64d80048af3d9a8-- From jpv@cisco.com Fri Jul 9 06:54:56 2010 Return-Path: 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 56A6E3A6979 for ; Fri, 9 Jul 2010 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 mzvMO+Of5Zgf for ; Fri, 9 Jul 2010 06:54:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 839C23A6407 for ; Fri, 9 Jul 2010 06:54:55 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFANbGNkyrR7Ht/2dsb2JhbACBQ5JAjD9xpAGaYoUnBIhJgi4 X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="scan'208,217";a="156265333" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2010 13:55:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69DsYoC001360; Fri, 9 Jul 2010 13:55:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:54:50 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 15:54:49 +0200 Message-Id: <08032DA4-D489-40E8-ACF4-7D4CE8AB6D70@cisco.com> From: JP Vasseur To: Michael John In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-311--271221341 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Jul 2010 15:54:49 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Jul 2010 13:54:50.0055 (UTC) FILETIME=[4C809570:01CB1F6E] Cc: roll@ietf.org Subject: Re: [Roll] Using ECMP 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: , X-List-Received-Date: Fri, 09 Jul 2010 13:54:56 -0000 --Apple-Mail-311--271221341 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On Jul 9, 2010, at 2:50 PM, Michael John wrote: > Dear all, > > I am new to the list (first post), but I have been following the =20 > drafts for a while. > > I would like to ask the group if the current draft of RPL would =20 > allow the use of ECMP (equal cost multi path) forwarding or if there =20= > is anything against it? Nothing against using ECMP. > > I could see ECMP to be benefit in battery powered networks where =20 > using one preferred parent =93all the time=94 might not be the = optimum. =20 > On the other hand, this problem could be addressed by a dynamic =20 > metric which is incorporating battery lifetime. Once the battery is =20= > drained too much of the current preferred parent, the metric would =20 > get worse and another possible parent would appear to be better. > Sure look at: = http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/=20 - Look at the new release to be posted today, we have a new metric =20 that might be of interest on the subject matter. JP. > Nevertheless, I am sure ECMP could come handy in other cases. > > > Michael > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-311--271221341 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi,

On Jul 9, = 2010, at 2:50 PM, Michael John wrote:

 

I = am new to the list (first post), but I have been following the drafts = for a while.

 

I = would like to ask the group if the current draft of RPL would allow the = use of ECMP (equal cost multi path) forwarding or if there is anything = against it?

Nothing = against using ECMP.

 

I could see ECMP to be benefit = in battery powered networks where using one preferred parent =93all the = time=94 might not be the optimum. On the other hand, this problem could = be addressed by a dynamic metric which is incorporating battery = lifetime. Once the battery is drained too much of the current preferred = parent, the metric would get worse and another possible parent would = appear to be better.

= http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ - = Look at the new release to be posted today, we have a new metric that = might be of interest on the subject = matter.


JP.


= --Apple-Mail-311--271221341-- From mcr@sandelman.ca Fri Jul 9 07:00:49 2010 Return-Path: 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 5F6803A6979 for ; Fri, 9 Jul 2010 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 hGCdFX7uLNO0 for ; Fri, 9 Jul 2010 07:00:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 8478C3A6A63 for ; Fri, 9 Jul 2010 07:00:47 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 07F9834477; Fri, 9 Jul 2010 10:00:52 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9FBED9896D; Fri, 9 Jul 2010 09:59:06 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 09 Jul 2010 09:59:06 -0400 Message-ID: <4375.1278683946@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 14:00:49 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> It might not strike the eye going through the base spec but Pascal> most packets that fly through a RPL network are Pascal> encapsulated, IP in IP. The generic reason is the need to Pascal> insert / remove the Hop by hop header defined I read the draft. I don't understand why the RPL Hop-by-Hop option can not added by the first RPL router. Pascal> Anyway it appears that the spec could be clearer in: Pascal> 1. Explaining why IP in IP is used in general Pascal> 2. Specifying the rules to determine if a destination is Pascal> inside the RPL network That's could be hard. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pthubert@cisco.com Fri Jul 9 07:23:45 2010 Return-Path: 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 8CB503A6824 for ; Fri, 9 Jul 2010 07:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.243 X-Spam-Level: X-Spam-Status: No, score=-9.243 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 kaldwpCEOoRn for ; Fri, 9 Jul 2010 07:23:41 -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 51FD23A67A1 for ; Fri, 9 Jul 2010 07:23:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYGACrNNkxAZnwM/2dsb2JhbACUAoxAcaQAjFOOCoUnBIp3 X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="scan'208";a="130446659" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2010 14:23:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69ENidK015106; Fri, 9 Jul 2010 14:23:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 16:23:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 16:20:00 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD42A@XMB-AMS-107.cisco.com> In-Reply-To: <4375.1278683946@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication thread-index: Acsfby58n7nKf1y0QXCEiKNlK3iWCwAAgaPQ References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <4375.1278683946@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 09 Jul 2010 14:23:45.0515 (UTC) FILETIME=[56EAC3B0:01CB1F72] Cc: ROLL WG Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 14:23:45 -0000 Hi Michael =20 >=20 > >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" = > writes: > Pascal> It might not strike the eye going through the base spec but > Pascal> most packets that fly through a RPL network are > Pascal> encapsulated, IP in IP. The generic reason is the need to > Pascal> insert / remove the Hop by hop header defined >=20 > I read the draft. > I don't understand why the RPL Hop-by-Hop option can not added by the > first RPL router. [Pascal] Well, it is added by the first RPL router. Did you find a contradiction? If so we must fix it. > Pascal> Anyway it appears that the spec could be clearer in: >=20 > Pascal> 1. Explaining why IP in IP is used in general >=20 > Pascal> 2. Specifying the rules to determine if a destination is > Pascal> inside the RPL network >=20 > That's could be hard. [Pascal] The point is, if you can't determine that it is, then you have to assume that it is not and tunnel. This might cause to go to the root and back down in a different tunnel... In the case where the RPL network is an IPv6 subnet, it's pretty easy though, so it would be sad to miss the optimization. >=20 > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > > then sign the petition. From pthubert@cisco.com Fri Jul 9 07:58:08 2010 Return-Path: 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 082253A6964 for ; Fri, 9 Jul 2010 07:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.139 X-Spam-Level: X-Spam-Status: No, score=-10.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uv3UdhZVBSft for ; Fri, 9 Jul 2010 07:58: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 1CADB3A684E for ; Fri, 9 Jul 2010 07:58:07 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,564,1272844800"; d="scan'208";a="556619461" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2010 14:58:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o69EwAXU003379; Fri, 9 Jul 2010 14:58:10 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 16:57:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 9 Jul 2010 16:57:47 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD45C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue#56: Transit and Target address mismatch thread-index: Acsfdxc8k3tbkkoAQtuP//XeqeiSGg== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 09 Jul 2010 14:57:51.0019 (UTC) FILETIME=[1A21E7B0:01CB1F77] Cc: roll@ietf.org Subject: [Roll] Closing issue#56: Transit and Target address mismatch 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: , X-List-Received-Date: Fri, 09 Jul 2010 14:58:08 -0000 SGkgTWF0aGlsZGU6DQoNCkJhc2VkIG9uIHRoZSB0aHJlYWQgd2UgaGF2ZSBoYWQgSSB0aGluayB0 aGF0IHRoZSB0ZXh0IG11c3QgY2xhcmlmeSB0aGF0Og0KDQotIFRoZSBSIGJpdCBpbiBQSU8gaXMg dXNlZCAgYXMgaW4gUkZDMzc3NSB0byBpbmRpY2F0ZSBhIChnbG9iYWwvVUxBKSBhZGRyZXNzIGFz IG9wcG9zZWQgdG8gYSBwcmVmaXguIA0KLSBUaGUgcHJlZml4IGlzIHN0aWxsIHZhbGlkIGZvciB0 aGUgcHVycG9zZSBvZiBhdXRvY29uZiB3aGVuIHRoZSBSIGJpdCBpcyBzZXQuDQotIFRoZSBhZGRy ZXNzIGluIHRoZSBQSU8gY2FuIGJlIHVzZWQgYXMgdHJhbnNpdCBwYXJlbnQgYnkgdGhlIGNoaWxk cmVuIGJ1dCBpcyBub3QgbmVjZXNzYXJpbHkgb24gbGluayBmb3IgdGhlIGNoaWxkcmVuLg0KLSBU aGUgcm91dGVyIHRoYXQgaXQgYWR2ZXJ0aXNlcyBhbiBhZGRyZXNzIGFzIHBhcmVudCBpbiBQSU8g bXVzdCBhbHNvIGFkdmVydGlzZSB0aGF0IGFkZHJlc3MgYXMgdGFyZ2V0IGluIGEgREFPIGZvciB0 aGUgcm91dGUgcmVjdXJzaW9uIHRvIGNvbXBsZXRlLg0KLSBBbiBhZGRyZXNzIHRoYXQgaXMgYWR2 ZXJ0aXNlZCBhcyB0YXJnZXQgaW4gYSBEQU8gbXVzdCBiZSBjb2xsb2NhdGVkIG9yIHJlYWNoYWJs ZSBvbmxpbmsgYnkgdGhlIHBhcmVudCB0aGF0IGlzIGluZGljYXRlZCBpbiB0aGUgYXNzb2NpYXRl ZCB0cmFuc2l0IGluZm9ybWF0aW9uLg0KLSBBIG5ldyBmbGFnIGluIHRoZSB0cmFuc2l0IGluZm9y bWF0aW9uIHF1YWxpZmllcyBhIHRhcmdldCBhZGRyZXNzIHRoYXQgaXMgYmVoaW5kIGEgcm91dGVy LCBlaXRoZXIgYXMgYW4gYXR0YWNoZWQgaG9zdCBvciBpbnN0YWxsZWQgb24gYW5vdGhlciBpbnRl cmZhY2UuIFRoZSByb3V0ZXIgaXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3Igc3VjaCBhZGRyZXNz Lg0KDQpXaWxsIHRoYXQgYmUgZW5vdWdoIHRvIGNsb3NlIDU2Pw0KDQpQYXNjYWwNCg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJvbGwNCj4gaXNzdWUg dHJhY2tlcg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDA2LCAyMDEwIDE6NDEgUE0NCj4gVG86IHdp bnRlcnRAYWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBbUm9sbF0gW3JvbGxdICM1NjogVHJhbnNpdCBhbmQgVGFyZ2V0IGFkZHJlc3MgbWlzbWF0 Y2gNCj4gDQo+ICM1NjogW1JvbGxdIFRyYW5zaXQgYW5kIFRhcmdldCBhZGRyZXNzIG1pc21hdGNo DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t DQo+ICBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAgd2ludGVy dEDigKYNCj4gICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3 DQo+ICBQcmlvcml0eTogIG1pbm9yICAgICAgICAgICAgfCAgIE1pbGVzdG9uZToNCj4gQ29tcG9u ZW50OiAgcnBsICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiAgU2V2ZXJpdHk6ICBJbiBX RyBMYXN0IENhbGwgIHwgICAgS2V5d29yZHM6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tDQo+ICBIaSBBbGwsDQo+IA0KPiAgTGV04oCZcyBj b25zaWRlciB0aGUgc3RvcmluZyBtb2RlIGluIGEgc2ltcGxlIHRvcG9sb2d5IEHDoELDoFIgKMOg IG1hcmsgdGhlDQo+IHBhcmVudCByZWxhdGlvbnNoaXApLiBMZXTigJlzIGFsc28gYXNzdW1lIHRo YXQgQSBoYXMgYSBwcmVmaXgg4oCYQXDigJkgYW5kIGEgIGdsb2JhbA0KPiBhZGRyZXNzIOKAmEFn 4oCZIHRvIGFkdmVydGlzZS4NCj4gIEluIHRoaXMgZXhhbXBsZSB3ZSBoYXZlOg0KPiAgLSBBIHNl bmRzIERBTyB3aXRoIOKAnHRhcmdldCBBZywgQXAsIHRyYW5zaXQgQuKAnQ0KPiAgLSBCIHNlbmRz IERBTyB3aXRoIOKAnHRhcmdldCBCZywgdHJhbnNpdCBS4oCdIHRvZ2V0aGVyIHdpdGggdGhlIGlu Zm9ybWF0aW9uICBmcm9tDQo+IEEsIGkuZS4g4oCcdGFyZ2V0IEFnLCBBcCwgdHJhbnNpdCBC4oCd DQo+IA0KPiAgVGhlbiBSIHJlY29tYmluZXMgdGhlIGluZm9ybWF0aW9uIHRvIGdldCB0aGUgcm91 dGUgdG8gZm9yIGV4YW1wbGUgQXAgIChUYXJnZXQNCj4gQXAsIHRyYW5zaXQgQiwgdGFyZ2V0IEJn LCB0cmFuc2l0IFIpICBGb3IgdGhpcyB0byB3b3JrLCB0cmFuc2l0IEIgYW5kIHRhcmdldCBCZyBu ZWVkDQo+IHRvIGJlIG1hdGNoZWQuIEhvdyBjYW4gdGhpcyAgYmUgZG9uZT8gRG9lcyBpdCBtZWFu IHRoYXQgdGhlIHRyYW5zaXQgcGFyZW50DQo+IGFkZHJlc3MgaGFzIHRvIGJlIGEgZ2xvYmFsICBh ZGRyZXNzPyBUaGlzIHdvdWxkIGltcGx5IHRoYXQgd2UgdXNlIGdsb2JhbA0KPiBhZGRyZXNzZXMg aW4gdGhlIHJvdXRpbmcgIGhlYWRlci4gSG93ZXZlciA2bWFuLXJwbC1yb3V0aW5nLWhlYWRlciBz YXlzOg0KPiAg4oCcV2hlbiBwcm9jZXNzaW5nIHRoZSBUeXBlIDQgUm91dGluZyBoZWFkZXIsIGEg cm91dGVyIE1VU1QgZHJvcCB0aGUgcGFja2V0DQo+IGlmIHRoZSBuZXh0IGVudHJ5IGlzIG5vdCBv bi1saW5r4oCdDQo+ICBBcyBnbG9iYWwgYWRkcmVzc2VzIGhhdmUgdG8gYmUgb2ZmLWxpbmsgaW4g TkJNQSBuZXR3b3JrIGxpa2UgODAyLjE1LjQsIEkgIHNlZSBhDQo+IHByb2JsZW3igKYNCj4gDQo+ ICBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IGhvdyBhZGRyZXNzZXMgYXJlIHN1cHBvc2VkIHRvIGJl IHVzZWQgaW4gdGhpcyAgc291cmNlLQ0KPiByb3V0aW5nIHNjZW5hcmlvLg0KPiANCj4gIFRoYW5r cywNCj4gIE1hdGhpbGRlDQo+IA0KPiAtLQ0KPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9v bHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC81Nj4NCj4gcm9sbCA8aHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL3JvbGwvPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From pthubert@cisco.com Fri Jul 9 08:42:49 2010 Return-Path: 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 343273A68C8 for ; Fri, 9 Jul 2010 08:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.957 X-Spam-Level: X-Spam-Status: No, score=-8.957 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 pLB0TJls1Qm6 for ; Fri, 9 Jul 2010 08:42:47 -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 0C7023A6A2F for ; Fri, 9 Jul 2010 08:42:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.png, image002.gif : 6281, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4KAK/fNkxAZnwN/2dsb2JhbABzUIFanD9ocaQqiSmRNAKEM3IEinc X-IronPort-AV: E=Sophos;i="4.53,564,1272844800"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="130498925" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 15:42:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o69FgoU6009059 for ; Fri, 9 Jul 2010 15:42:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 17:42:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB1F7D.62B44170" Date: Fri, 9 Jul 2010 17:42:47 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication thread-index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybwAG+67AAAQubjA= References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 15:42:49.0935 (UTC) FILETIME=[62CFCDF0:01CB1F7D] Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 15:42:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1F7D.62B44170 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB1F7D.62B44170" ------_=_NextPart_002_01CB1F7D.62B44170 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IA0KDQogDQoNCiANCg0KQW55d2F5IGl0IGFwcGVhcnMgdGhhdCB0aGUgc3BlYyBjb3VsZCBiZSBj bGVhcmVyIGluOg0KDQoxLiAgICAgICBFeHBsYWluaW5nIHdoeSBJUCBpbiBJUCBpcyB1c2VkIGlu IGdlbmVyYWwNCg0KMi4gICAgICAgU3BlY2lmeWluZyB0aGUgcnVsZXMgdG8gZGV0ZXJtaW5lIGlm IGEgZGVzdGluYXRpb24gaXMgaW5zaWRlIHRoZSBSUEwgbmV0d29yaw0KDQozLiAgICAgICBTcGVj aWZ5aW5nIHR1bm5lbCBtb2RlIG9wZXJhdGlvbg0KDQo0LiAgICAgICBTcGVjaWZ5aW5nIHRyYW5z cG9ydCBtb2RlIG9wZXJhdGlvbiBhbmQgd2hlbiBpdCBjYW4gYmUgdXNlZA0KDQo1LiAgICAgICBT cGVjaWZ5aW5nIGhvdyB0byBkZXRlcm1pbmUgdGhlIHR1bm5lbCBlbmRwb2ludCBpbiB0dW5uZWwg bW9kZQ0KDQogDQoNClByb3Bvc2FsOg0KDQogDQoNCjEpICAgICAgUlBMIG5lZWRzIGFuIGluc3Rh bmNlIElEIGluIHRoZSBmbG93IGxhYmVsLCBhbmQgSGJIIGhlYWRlciwgYW5kIGV2ZW50dWFsbHkg YSByb3V0aW5nIGhlYWRlciBpbiBldmVyeSBwYWNrZXQgZm9yIHJvdXRpbmcgYW5kIGluY29uc2lz dGVuY3kgZGV0ZXJtaW5hdGlvbi4gVGhlIEhiSCBhbmQgUkggYXJlIG5vbnNlbnNpY2FsIG91dHNp ZGUgdGhlIFJQTCBuZXR3b3JrIGFuZCBjYW4gb25seSBiZSBwcmVzZW50IGluc2lkZSB0aGUgUlBM IG5ldHdvcmsuIFRoZSBvbmx5IGNsZWFuIHdheSB0byBpbnNlcnQgYW5kIHJlbW92ZSB0aG9zZSBo ZWFkZXJzIGlzIHRvIHVzZSBhIHR1bm5lbCBtb2RlIChJUCBpbiBJUCBlbmNhcHN1bGF0aW9uKSB3 aGVyZWJ5IHRoZSByb3V0ZXIgcGxhY2VzIHRoZSBSUEwgaGVhZGVycyBiZWZvcmUgdGhlIGlubmVy IGhlYWRlciwgbGVhdmluZyB0aGUgb3JpZ2luYWwgcGFja2V0IHVudG91Y2hlZC4NCg0KYS4gICAg ICAgQSBzb3VyY2UgaW5zaWRlIHRoZSBSUEwgbmV0d29yayAocm91dGVyIG9yIGxlYWYpIHBsYWNl cyB0aGUgUlBMIGhlYWRlcnMgYW5kIGZsb3cgbGFiZWwgaW4gdGhlIHBhY2tldCwgZWl0aGVyIGlu IHR1bm5lbCBvciB0cmFuc3BvcnQgbW9kZS4NCg0KQXJlbuKAmXQgdGhlIGZsb3cgbGFiZWwgYW5k IEhiSCBoZWFkZXIgbXV0dWFsbHkgZXhjbHVzaXZlPyBTaG91bGRu4oCZdCB3ZSBmb3JjZSB0aGUg dXNlIG9mIHRoZSBIYkggd2l0aGluIHRoZSBSUEwgbmV0d29yaz8gTW9yZSBhbHRlcm5hdGl2ZXMg bWVhbiBtb3JlIGNvbXBsZXhpdHkuIFdoeSB3b3VsZCBhIHNvdXJjZSBpbnNpZGUgUlBMIHVzZSB0 dW5uZWwgbW9kZT8gKHNlZSBhbHNvIGNvbW1lbnRzIGJlbG93KSANCg0KW1Bhc2NhbF0gLTEwIGFs bG93cyBib3RoIGJ1dCBpdCBzZWVtcyByZWR1bmRhbnQuIFNpbmNlIHRoZSBpbnN0YW5jZSBoYXMg dG8gYmUgaW4gdGhlIGZsb3cgbGFiZWwgZm9yIGFuIGVuZCBwb2ludCB0byBpbmRpY2F0ZSBpdCwg dGhlbiB3aHkgbm90IGxldCBpdCB0aGVyZSBhbGwgdGhlIHRpbWU/IElmIHRoZSBpbmdyZXNzIHJv dXRlciBoYXMgdG8gZmlndXJlIG91dCB0aGUgaW5zdGFuY2UgSUQgYnkgc29tZSBtYWdpYywgaW4g YW55IGZhc2hpb24gaXQgY2FuIHBsYWNlIHRoZSByZXN1bHQgaW4gdGhlIGZsb3cgbGFiZWwuDQoN CiANCg0KYi4gICAgICBGb3IgcGFja2V0cyBvcmlnaW5hdGVkIG91dHNpZGUgdGhlIFJQTCBuZXR3 b3JrLCB0aGUgZmlyc3QgUlBMIHJvdXRlciAoY2FsbGVkIGluZ3Jlc3Mgcm91dGVyKSBoYXMgdG8g cGxhY2UgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgcGFja2V0IGluIHR1bm5lbCBtb2RlDQoNCmMu ICAgICAgIEZ1cnRoZXIgUlBMIHJvdXRlcnMgZmluZCB0aGUgaW5mb3JtYXRpb24gYW5kIHVzZSBp dC4gVGhleSBkbyBub3QgcmUtZW5jYXBzdWxhdGUsIHRoZXkgZG8gbm90IGNoYW5nZSB0aGUgZmxv dyBsYWJlbCwgdGhleSBoYXBwZW4gdG8gbW9kaWZ5IHRoZSBSUEwgaGVhZGVycy4NCg0KSW4gbm9u LXN0b3JpbmcgbW9kZSwgaG93IGRvZXMgdGhpcyBzY2VuYXJpbyB3b3JrPw0KDQpIb3N0IOKAkyBS UEwgaW5ncmVzcyByb3V0ZXIgKG11c3QgaW5jbHVkZSBIYkgp4oCmIFJQTCByb3V0ZXJzIOKApiBS UEwgcm9vdCAobXVzdCBpbmNsdWRlIHNvdXJjZSByb3V0ZSBpbiBhZGRpdGlvbiB0byBIYkgsIGNh biBpdCBkbyBpdCBpbiB0aGUgc2FtZSBJUHY2IGhlYWRlcj8pIOKApiBSUEwgcm91dGVyIOKApiBS UEwgcm91dGUgKGRlY2Fwc3VsYXRpb24pIOKAkyBIb3N0DQoNCltQYXNjYWxdIEluIG5vbi1zdG9y aW5nLCB0aGUgbm9kZXMgd2lsbCBhbHdheXMgdHVubmVsIHRvIHRoZSByb290LiBUaGUgcm9vdCBk ZWNhcHMsIGFuZCByb3V0ZSB0aGUgcGFja2V0OyBpZiB0aGUgZGVzdGluYXRpb24gaXMgaW4gdGhl IFJQTCBuZXR3b3JrLCB0aGUgcm9vdCByZWVuY2FwcywgdGhpcyB0aW1lIHdpdGggYSByb3V0aW5n IGhlYWRlci4NCg0KZC4gICAgICBUaGUgdHVubmVsIGVuZHBvaW50IGRlY2Fwc3VsYXRlcyBiZWZv cmUgZm9yd2FyZGluZyB0aGUgaW5uZXIgcGFja2V0LiBUaGlzIHN0cmlwcyB0aGUgUlBMIGluZm9y bWF0aW9uIGZyb20gdGhlIHBhY2tldC4gSWYgdGhlIHBhY2tldCBpcyByZWluc2VydGVkIGludG8g dGhlIFJQTCBuZXR3b3JrIHRoZW4gdGhlcmUgaXMgYSByaXNrIG9mIGEgbG9vcC4gDQoNCiANCg0K IA0KDQogDQoNCjIpICAgICAgQSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgc2FtZSBSUEwgbmV0d29y ayBpZjoNCg0KYS4gICAgICAgVGhlIGRlc3RpbmF0aW9uIGlzIHRoZSByb290IG9mIHRoZSBET0RB RyAoYWxsIG1vZGVzKQ0KDQpiLiAgICAgIFRoZSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgc2FtZSBT dWJuZXQgYXMgdGhlIHNvdXJjZSAoZGVyaXZlZCBmcm9tIGEgUElPKSAgKHN0b3JpbmcgbW9kZSBv bmx5KSANCg0KYy4gICAgICAgVGhlIG5vZGUgaXMgYSByb3V0ZXIgdGhhdCBoYXMgYSBEQU8gc3Rh dGUgaW5kaWNhdGluZyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBhIGNoaWxkIChzdG9yaW5nIG1v ZGUgb25seSkNCg0KZC4gICAgICBUaGUgZGVzdGluYXRpb24gaGFzIGJlZW4gc2VlbiBhcyB0dW5u ZWwgZW5kcG9pbnQgYW5kIHRodXMgaXMgYSBEQU8gYW5jZXN0b3IgKHN0b3JpbmcgbW9kZSBvbmx5 KS4NCg0KTm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0aGUgbGFzdCBwb2ludC4gDQoNCltQYXNj YWxdIHRyaWNrLCBhbmQgYWN0dWFsbHkgbm90IHR1bm5lbCBlbmRwb2ludCBidXQgdHJhbnNwb3J0 IG1vZGUgZW5kcG9pbnQuIEEgbm9kZSBkb2VzIG5vdCBrbm93IGl0cyBhbmNlc3RvcnMsIHNvIGl0 IHdvdWxkIHR1bm5lbCBpZiB0aGV5IGFyZSBub3QgaW4gdGhlIHNhbWUgc3VibmV0LiBCdXQgdGhl IGFuY2VzdG9yIGtub3dzIHRoZSBncmFuZCBncmFuZCBjaGlsZCwgc28gaXQgd291bGQgdXNlIHRy YW5zcG9ydCBtb2RlLiBTbyB3ZSBlbmQgdXAgd2l0aCBhIHRyaWFuZ3VsYXIgcm91dGluZyB3aGVy ZSB0aGUgY2hpbGQgdHVubmVscyB0byB0aGUgcm9vdCwgdGhlIHJvb3QgdHVubmVsIHRvIHRoZSBh bmNlc3RvciwgYW5kIHRoZSBhbmNlc3RvciB1c2VzIHRyYW5zcG9ydCBtb2RlIGRvd24uIGlmIHNv bWVvbmUgdXNlcyB0cmFuc3BvcnQgbW9kZSB3aXRoIHlvdSwgeW91IGNhbiB1c2UgdHJhbnNwb3J0 IG1vZGUgd2l0aCBoaW3igKYgSWYgeW91IGNhcmUgdG8gaW1wbGVtZW50IHN1Y2ggb3B0aW1pemF0 aW9uLg0KDQogDQoNCiANCg0KMykgICAgICBBIFJQTCByb3V0ZXIgdGhhdCBpbmplY3RzIGEgcGFj a2V0IHdpdGhvdXQgdGhlIEhiSCBvcHRpb24gaW50byB0aGUgUlBMIG5ldHdvcmsgaXMgYW4gaW5n cmVzcyByb3V0ZXIuICANCg0KYS4gICAgICAgQW4gaW5ncmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0 aGUgUlBMIGluZm9ybWF0aW9uIGluIHRoZSBwYWNrZXQgaW4gdHVubmVsIG1vZGUNCg0KYi4gICAg ICBBbiBpbmdyZXNzIHJvdXRlciBNVVNUIHBsYWNlIHRoZSBpbnN0YW5jZSBJRCBpbiB0aGUgZmxv dyBsYWJlbCBvZiB0aGUgb3V0ZXIgaGVhZGVyDQoNCmMuICAgICAgIEFuIGluZ3Jlc3Mgcm91dGVy IE1VU1QgdXNlIG9uZSBvZiBpdHMgZ2xvYmFsIGFkZHJlc3NlcyBmcm9tIHRoZSBSUEwgZG9tYWlu IGFzIHNvdXJjZQ0KDQpkLiAgICAgIEFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgdXNlIGEgdHVubmVs IGVuZHBvaW50IHRoYXQgaXMgaW4gdGhlIHNhbWUgUlBMIG5ldHdvcmsgKHJ1bGVzIGFib3ZlKS4N Cg0KRG9lc27igJl0IGQuIGNvbnRyYWRpY3RzIOKAnFRoZSBsYXN0IGVudHJ5LCBBZGRyZXNzW25d LCBpcyBleGVtcHQgZnJvbSB0aGUgc3RyaWN0IHNvdXJjZSByb3V0ZSBwb2xpY3kgYW5kIG1heSBz cGVjaWZ5IGEgZGVzdGluYXRpb24gb3V0c2lkZSB0aGUgUlBMIGRvbWFpbuKAnSBmcm9tIHRoZSBy cGwtcm91dGluZy1oZWFkZXIgZHJhZnQ/IEkgdGhpbmsgdGhpcyBhbHNvIGltcGFjdCB5b3VyIHBv aW50IDQgYW5kIDXigKYNCg0KW1Bhc2NhbF0gVGhlIHRleHRzIGRvZXMgbm90IGFwcGx5IHRvIFJQ TCBidXQgaXMgYXBwYXJlbnRseSBzYWZlIGluIHJvdXRpbmcgaGVhZGVycyBhdCBsYXJnZS4gUlBM IGNhbm5vdCB1c2UgdHJhbnNwb3J0IG1vZGUgdG8gYW4gZXh0ZXJuYWwgZGVzdGluYXRpb24gYmVj YXVzZSBvZiB0aGUgdXNlIG9mIHRoZSBob3AgYnkgaG9wIG9wdGlvbi4gIA0KDQogDQoNCjQpICAg ICAgQSBSUEwgbm9kZSBNVVNUIHBsYWNlIHRoZSBSUEwgaW5mb3JtYXRpb24gaW4gZXZlcnkgcGFj a2V0IHRoYXQgaXMgc291cmNlcy4gSXQgY2FuIHNhZmVseSB1c2UgdHVubmVsIG1vZGUgZm9yIGFs bCBwYWNrZXRzLiBJdCBNQVkgdXNlIHRyYW5zcG9ydCBtb2RlIHdoZW4gaXQgZGV0ZXJtaW5lcyB0 aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBhIFJQTCBsZWFmIG9yIHJvdXRlciB3aXRoaW4gdGhlIHNh bWUgUlBMIG5ldHdvcmsuIEluIHRyYW5zcG9ydCBtb2RlLCB0aGUgb3V0ZXIgaGVhZGVycyBhcmUg YnVpbHQgYXMgZm9sbG93czogDQoNCmEuICAgICAgIFRoZSBzb3VyY2UgTVVTVCBwbGFjZSB0aGUg aW5zdGFuY2UgSUQgaW4gdGhlIGZsb3cgbGFiZWwgb2YgdGhlIElQdjYgaGVhZGVyDQoNCmIuICAg ICAgVGhlIHNvdXJjZSBNVVNUIHVzZSBvbmUgb2YgaXRzIGdsb2JhbCBhZGRyZXNzZXMgZnJvbSB0 aGUgUlBMIGRvbWFpbiBhcyBzb3VyY2UNCg0KYy4gICAgICAgVGhlIGRlc3RpbmF0aW9uIE1VU1Qg YmUgaXMgaW4gdGhlIHNhbWUgUlBMIG5ldHdvcmsgKHJ1bGVzIGFib3ZlKS4NCg0KIA0KDQo1KSAg ICAgIFRoZSB0dW5uZWwgZW5kcG9pbnQgaXMgZGV0ZXJtaW5lZCBhcyBmb2xsb3dzOg0KDQphLiAg ICAgICBJZiB0aGUgZGVzdGluYXRpb24gaXMgaW4gdGhlIFJQTCBuZXR3b3JrIChydWxlcyBhYm92 ZSkgdGhlbiB0aGUgZW5kcG9pbnQgaXMgdGhlIGRlc3RpbmF0aW9uDQoNCmIuICAgICAgSWYgdGhl IGRlc3RpbmF0aW9uIGlzIGEgaG9zdCBhdHRhY2hlZCB0byBhIFJQTCByb3V0ZXIgdGhlbiB0aGUg ZW5kcG9pbnQgaXMgdGhhdCBSUEwgcm91dGVyDQoNCmMuICAgICAgIEVsc2UgdGhlIGVuZHBvaW50 IGlzIHRoZSByb290DQoNCiANCg0KSXQgYXBwZWFycyB0aGF0IHRoZSBiKSBpcyBub3Qgc3VwcG9y dGVkIGNvcnJlY3RseSB3aXRoIHRoZSBjdXJyZW50IHNwZWMgc2luY2Ugd2UgZG8gbm90IGhhdmUg YSB3YXkgdG8gaW5qZWN0IGEgcm91dGUgdG8gYW4gZXh0ZXJuYWwgaG9zdCB3aGlsZSBpbmRpY2F0 aW5nIHRoYXQgdGhlIGhvc3QgaXMgbm90IGEgbGVhZi4NCg0KUHJvYmFibHkgdGhlIHJvdXRlciB3 b3VsZCBwcmVzZW50IGl0c2VsZiBhcyBwYXJlbnQgaW4gYSB0cmFuc2l0IG9wdGlvbiwgd2l0aCBh IGJpdCBzYXlpbmcgdGhhdCB0aGUgdGFyZ2V0cyBhcyBub24gcnBsIGhvc3RzLg0KDQogDQoNCltQ YXNjYWxdIFRoYW5rcyBhIGJ1bmNoIGZvciB5b3VyIGNvbW1lbnRzLiBMZXTigJlzIGtlZXAgdGhl IHBpcGUgbW9yZSBvcGVuIHRoYW4gZXZlciBzaW5jZSB3ZSBhcmUgaW4gbGFzdCBjYWxsIG5vdyEN Cg0KIA0KDQpPcGluaW9ucz8NCg0KIA0KDQogDQoNCgkNClBhc2NhbCBUaHViZXJ0DQpJUHY2IEVu Z2luZWVyaW5nDQpQcm9kdWN0IERldmVsb3BtZW50DQpwdGh1YmVydEBjaXNjby5jb20gPG1haWx0 bzpwdGh1YmVydEBjaXNjby5jb20+IA0KUGhvbmU6ICszMyA0IDk3MjMgMjYzNA0KTW9iaWxlOiAr MzMgNiAxOTk4IDI5ODUNCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UNClZpbGxhZ2UgZCdFbnRyZXBy aXNlcyBHcmVlbiBTaWRlDQo0MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUgDQpCYXRpbWVudCBUIDMg DQowNjQxMCANCkJJT1QgLSBTT1BISUEgQU5USVBPTElTDQpGcmFuY2UNCkNpc2NvLmNvbSA8aHR0 cDovL3d3dy5jaXNjby5jb20vZ2xvYmFsL0ZSLz4gDQoNCiAgDQoNCiANCg0KIFRoaW5rIGJlZm9y ZSB5b3UgcHJpbnQuDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9u c2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRp cyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNh cGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIg ZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUsIEZvciBjb3Jwb3JhdGUg bGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQv ZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwgPGh0dHA6Ly93d3cuY2lzY28uY29t L3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbD4gDQoNCiANCg0K IA0KDQo= ------_=_NextPart_002_01CB1F7D.62B44170 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAu ODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1NTkyNDYyMTA7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTAwMjM4OTQwIDY3 Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IC0xMjY3NDUxODcyIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6 IiU0XCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTk3NzY4MDA3 NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk0NzM3 NjU1NiAxODI4MDk2NTgyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NjcuMjVwdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjEwMy4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTM5LjI1cHQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE3NS4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjEx LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNDcuMjVwdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MjgzLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMTkuMjVw dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjM1NS4yNXB0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0 LWlkOjIwOTc0MzI2MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE5NzIyNjcxMTQgNjc2OTg3MDMgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2 ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2 bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDEuMHB0IDBjbSc+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PkFueXdheSBpdCBhcHBlYXJzIHRoYXQgdGhlIHNwZWMgY291bGQgYmUgY2xlYXJlciBpbjo8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xMCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPkV4cGxhaW5pbmcgd2h5IElQIGluIElQIGlzIHVzZWQgaW4gZ2Vu ZXJhbDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEwJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yLjxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U3BlY2lmeWluZyB0aGUgcnVsZXMgdG8gZGV0ZXJt aW5lIGlmIGEgZGVzdGluYXRpb24gaXMgaW5zaWRlIHRoZSBSUEwgbmV0d29yazxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEwJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz4zLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+U3BlY2lmeWluZyB0dW5uZWwgbW9kZSBvcGVyYXRpb248bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwyIGxldmVsMSBsZm8xMCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+NC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPlNwZWNpZnlpbmcgdHJhbnNwb3J0IG1vZGUgb3BlcmF0aW9uIGFuZCB3aGVuIGl0 IGNhbiBiZSB1c2VkPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls ZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTAnPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjUuPHNwYW4gc3R5bGU9 J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TcGVjaWZ5aW5nIGhvdyB0byBkZXRl cm1pbmUgdGhlIHR1bm5lbCBlbmRwb2ludCBpbiB0dW5uZWwgbW9kZTxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPlByb3Bvc2FsOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVu dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+MSk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAi VGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPlJQTCBuZWVkcyBhbiBpbnN0YW5jZSBJRCBpbiB0aGUgZmxvdyBsYWJl bCwgYW5kIEhiSCBoZWFkZXIsIGFuZCBldmVudHVhbGx5IGEgcm91dGluZyBoZWFkZXIgaW4gZXZl cnkgcGFja2V0IGZvciByb3V0aW5nIGFuZCBpbmNvbnNpc3RlbmN5IGRldGVybWluYXRpb24uIFRo ZSBIYkggYW5kIFJIIGFyZSBub25zZW5zaWNhbCBvdXRzaWRlIHRoZSBSUEwgbmV0d29yayBhbmQg Y2FuIG9ubHkgYmUgcHJlc2VudCBpbnNpZGUgdGhlIFJQTCBuZXR3b3JrLiBUaGUgb25seSBjbGVh biB3YXkgdG8gaW5zZXJ0IGFuZCByZW1vdmUgdGhvc2UgaGVhZGVycyBpcyB0byB1c2UgYSB0dW5u ZWwgbW9kZSAoSVAgaW4gSVAgZW5jYXBzdWxhdGlvbikgd2hlcmVieSB0aGUgcm91dGVyIHBsYWNl cyB0aGUgUlBMIGhlYWRlcnMgYmVmb3JlIHRoZSBpbm5lciBoZWFkZXIsIGxlYXZpbmcgdGhlIG9y aWdpbmFsIHBhY2tldCB1bnRvdWNoZWQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+QSBzb3VyY2UgaW5zaWRlIHRoZSBSUEwgbmV0d29yayAocm91dGVyIG9yIGxlYWYp IHBsYWNlcyB0aGUgUlBMIGhlYWRlcnMgYW5kIGZsb3cgbGFiZWwgaW4gdGhlIHBhY2tldCwgZWl0 aGVyIGluIHR1bm5lbCBvciB0cmFuc3BvcnQgbW9kZS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsdWUnPkFyZW7igJl0IHRoZSBmbG93IGxhYmVsIGFuZCBIYkggaGVhZGVyIG11dHVhbGx5 IGV4Y2x1c2l2ZT8gU2hvdWxkbuKAmXQgd2UgZm9yY2UgdGhlIHVzZSBvZiB0aGUgSGJIIHdpdGhp biB0aGUgUlBMIG5ldHdvcms/IE1vcmUgYWx0ZXJuYXRpdmVzIG1lYW4gbW9yZSBjb21wbGV4aXR5 LiBXaHkgd291bGQgYSBzb3VyY2UgaW5zaWRlIFJQTCB1c2UgdHVubmVsIG1vZGU/IChzZWUgYWxz byBjb21tZW50cyBiZWxvdykgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48Yj48aT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0gLTEwIGFsbG93cyBi b3RoIGJ1dCBpdCBzZWVtcyByZWR1bmRhbnQuIFNpbmNlIHRoZSBpbnN0YW5jZSBoYXMgdG8gYmUg aW4gdGhlIGZsb3cgbGFiZWwgZm9yIGFuIGVuZCBwb2ludCB0byBpbmRpY2F0ZSBpdCwgdGhlbiB3 aHkgbm90IGxldCBpdCB0aGVyZSBhbGwgdGhlIHRpbWU/IElmIHRoZSBpbmdyZXNzIHJvdXRlciBo YXMgdG8gZmlndXJlIG91dCB0aGUgaW5zdGFuY2UgSUQgYnkgc29tZSBtYWdpYywgaW4gYW55IGZh c2hpb24gaXQgY2FuIHBsYWNlIHRoZSByZXN1bHQgaW4gdGhlIGZsb3cgbGFiZWwuPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+Rm9yIHBhY2tldHMgb3JpZ2luYXRlZCBvdXRzaWRlIHRoZSBSUEwgbmV0d29yaywgdGhlIGZp cnN0IFJQTCByb3V0ZXIgKGNhbGxlZCBpbmdyZXNzIHJvdXRlcikgaGFzIHRvIHBsYWNlIHRoaXMg aW5mb3JtYXRpb24gaW4gdGhlIHBhY2tldCBpbiB0dW5uZWwgbW9kZTxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkZ1cnRoZXIgUlBMIHJvdXRlcnMgZmluZCB0aGUgaW5m b3JtYXRpb24gYW5kIHVzZSBpdC4gVGhleSBkbyBub3QgcmUtZW5jYXBzdWxhdGUsIHRoZXkgZG8g bm90IGNoYW5nZSB0aGUgZmxvdyBsYWJlbCwgdGhleSBoYXBwZW4gdG8gbW9kaWZ5IHRoZSBSUEwg aGVhZGVycy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkluIG5vbi1zdG9yaW5n IG1vZGUsIGhvdyBkb2VzIHRoaXMgc2NlbmFyaW8gd29yaz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz5Ib3N0IOKAkyBSUEwgaW5ncmVzcyByb3V0ZXIgKG11c3QgaW5j bHVkZSBIYkgp4oCmIFJQTCByb3V0ZXJzIOKApiBSUEwgcm9vdCAobXVzdCBpbmNsdWRlIHNvdXJj ZSByb3V0ZSBpbiBhZGRpdGlvbiB0byBIYkgsIGNhbiBpdCBkbyBpdCBpbiB0aGUgc2FtZSBJUHY2 IGhlYWRlcj8pIOKApiBSUEwgcm91dGVyIOKApiBSUEwgcm91dGUgKGRlY2Fwc3VsYXRpb24pIDwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+4oCTPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibHVlJz4gSG9zdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPltQYXNjYWxdIEluIG5v bi1zdG9yaW5nLCB0aGUgbm9kZXMgd2lsbCBhbHdheXMgdHVubmVsIHRvIHRoZSByb290LiBUaGUg cm9vdCBkZWNhcHMsIGFuZCByb3V0ZSB0aGUgcGFja2V0OyBpZiB0aGUgZGVzdGluYXRpb24gaXMg aW4gdGhlIFJQTCBuZXR3b3JrLCB0aGUgcm9vdCByZWVuY2FwcywgdGhpcyB0aW1lIHdpdGggYSBy b3V0aW5nIGhlYWRlci48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21h cmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBs Zm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ ZC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSB0dW5uZWwgZW5k cG9pbnQgZGVjYXBzdWxhdGVzIGJlZm9yZSBmb3J3YXJkaW5nIHRoZSBpbm5lciBwYWNrZXQuIFRo aXMgc3RyaXBzIHRoZSBSUEwgaW5mb3JtYXRpb24gZnJvbSB0aGUgcGFja2V0LiBJZiB0aGUgcGFj a2V0IGlzIHJlaW5zZXJ0ZWQgaW50byB0aGUgUlBMIG5ldHdvcmsgdGhlbiB0aGVyZSBpcyBhIHJp c2sgb2YgYSBsb29wLiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJn aW4tbGVmdDo3Mi4wcHQnPjxzcGFuIHN0eWxlPSdjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6 MGNtJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3Jh cGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEyJz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QSBkZXN0aW5hdGlvbiBpcyBpbiB0 aGUgc2FtZSBSUEwgbmV0d29yayBpZjo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFy YWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDIgbGZvMTInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPmEuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT5UaGUgZGVzdGluYXRpb24gaXMgdGhlIHJvb3Qgb2YgdGhlIERPREFHIChhbGwgbW9k ZXMpPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2lu LWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEy Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5iLjxz cGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGRlc3RpbmF0aW9uIGlz IGluIHRoZSBzYW1lIFN1Ym5ldCBhcyB0aGUgc291cmNlIChkZXJpdmVkIGZyb20gYSBQSU8pICZu YnNwOyhzdG9yaW5nIG1vZGUgb25seSkgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz5jLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+VGhlIG5vZGUgaXMgYSByb3V0ZXIgdGhhdCBoYXMgYSBEQU8gc3RhdGUgaW5kaWNh dGluZyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcyBhIGNoaWxkIChzdG9yaW5nIG1vZGUgb25seSk8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVm dDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMTInPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmQuPHNwYW4g c3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgZGVzdGluYXRpb24gaGFzIGJl ZW4gc2VlbiBhcyB0dW5uZWwgZW5kcG9pbnQgYW5kIHRodXMgaXMgYSBEQU8gYW5jZXN0b3IgKHN0 b3JpbmcgbW9kZSBvbmx5KS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPk5vdCBz dXJlIHdoYXQgeW91IG1lYW4gYnkgdGhlIGxhc3QgcG9pbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPltQ YXNjYWxdIHRyaWNrLCBhbmQgYWN0dWFsbHkgbm90IHR1bm5lbCBlbmRwb2ludCBidXQgdHJhbnNw b3J0IG1vZGUgZW5kcG9pbnQuIEEgbm9kZSBkb2VzIG5vdCBrbm93IGl0cyBhbmNlc3RvcnMsIHNv IGl0IHdvdWxkIHR1bm5lbCBpZiB0aGV5IGFyZSBub3QgaW4gdGhlIHNhbWUgc3VibmV0LiBCdXQg dGhlIGFuY2VzdG9yIGtub3dzIHRoZSBncmFuZCBncmFuZCBjaGlsZCwgc28gaXQgd291bGQgdXNl IHRyYW5zcG9ydCBtb2RlLiBTbyB3ZSBlbmQgdXAgd2l0aCBhIHRyaWFuZ3VsYXIgcm91dGluZyB3 aGVyZSB0aGUgY2hpbGQgdHVubmVscyB0byB0aGUgcm9vdCwgdGhlIHJvb3QgdHVubmVsIHRvIHRo ZSBhbmNlc3RvciwgYW5kIHRoZSBhbmNlc3RvciB1c2VzIHRyYW5zcG9ydCBtb2RlIGRvd24uIGlm IHNvbWVvbmUgdXNlcyB0cmFuc3BvcnQgbW9kZSB3aXRoIHlvdSwgeW91IGNhbiB1c2UgdHJhbnNw b3J0IG1vZGUgd2l0aCBoaW3igKYgSWYgeW91IGNhcmUgdG8gaW1wbGVtZW50IHN1Y2ggb3B0aW1p emF0aW9uLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxl ZnQ6NzIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTInPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjMpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5BIFJQTCByb3V0ZXIgdGhhdCBpbmplY3RzIGEgcGFja2V0IHdpdGhv dXQgdGhlIEhiSCBvcHRpb24gaW50byB0aGUgUlBMIG5ldHdvcmsgaXMgYW4gaW5ncmVzcyByb3V0 ZXIuICZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9 J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MiBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+YS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFuIGlu Z3Jlc3Mgcm91dGVyIE1VU1QgcGxhY2UgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiB0aGUgcGFja2V0 IGluIHR1bm5lbCBtb2RlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBz dHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6 SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QW4gaW5n cmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0aGUgaW5zdGFuY2UgSUQgaW4gdGhlIGZsb3cgbGFiZWwg b2YgdGhlIG91dGVyIGhlYWRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3Jh cGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMiBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1s aXN0Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPkFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgdXNlIG9uZSBvZiBpdHMgZ2xvYmFsIGFkZHJlc3Nl cyBmcm9tIHRoZSBSUEwgZG9tYWluIGFzIHNvdXJjZTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTgu MHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9J21zby1saXN0Oklnbm9yZSc+ZC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPkFuIGluZ3Jlc3Mgcm91dGVyIE1VU1QgdXNlIGEgdHVubmVsIGVuZHBvaW50IHRo YXQgaXMgaW4gdGhlIHNhbWUgUlBMIG5ldHdvcmsgKHJ1bGVzIGFib3ZlKS48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsdWUnPkRvZXNu4oCZdCBkLiBjb250cmFkaWN0cyDigJxUaGUgbGFz dCBlbnRyeSwgQWRkcmVzc1tuXSwgaXMgZXhlbXB0IGZyb20gdGhlIHN0cmljdCBzb3VyY2Ugcm91 dGUgcG9saWN5IGFuZCBtYXkgc3BlY2lmeSBhIGRlc3RpbmF0aW9uIG91dHNpZGUgdGhlIFJQTCBk b21haW7igJ0gZnJvbSB0aGUgcnBsLXJvdXRpbmctaGVhZGVyIGRyYWZ0PyBJIHRoaW5rIHRoaXMg YWxzbyBpbXBhY3QgeW91ciBwb2ludCA0IGFuZCA14oCmPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2Nh bF0gVGhlIHRleHRzIGRvZXMgbm90IGFwcGx5IHRvIFJQTCBidXQgaXMgYXBwYXJlbnRseSBzYWZl IGluIHJvdXRpbmcgaGVhZGVycyBhdCBsYXJnZS4gUlBMIGNhbm5vdCB1c2UgdHJhbnNwb3J0IG1v ZGUgdG8gYW4gZXh0ZXJuYWwgZGVzdGluYXRpb24gYmVjYXVzZSBvZiB0aGUgdXNlIG9mIHRoZSBo b3AgYnkgaG9wIG9wdGlvbi4gwqA8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMTInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25v cmUnPjQpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BIFJQTCBub2Rl IE1VU1QgcGxhY2UgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiBldmVyeSBwYWNrZXQgdGhhdCBpcyBz b3VyY2VzLiBJdCBjYW4gc2FmZWx5IHVzZSB0dW5uZWwgbW9kZSBmb3IgYWxsIHBhY2tldHMuIEl0 IE1BWSB1c2UgdHJhbnNwb3J0IG1vZGUgd2hlbiBpdCBkZXRlcm1pbmVzIHRoYXQgdGhlIGRlc3Rp bmF0aW9uIGlzIGEgUlBMIGxlYWYgb3Igcm91dGVyIHdpdGhpbiB0aGUgc2FtZSBSUEwgbmV0d29y ay4gSW4gdHJhbnNwb3J0IG1vZGUsIHRoZSBvdXRlciBoZWFkZXJzIGFyZSBidWlsdCBhcyBmb2xs b3dzOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJn aW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZv MTInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmEu PHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgc291cmNl IE1VU1QgcGxhY2UgdGhlIGluc3RhbmNlIElEIGluIHRoZSBmbG93IGxhYmVsIG9mIHRoZSBJUHY2 IGhlYWRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21h cmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBs Zm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ Yi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzb3VyY2UgTVVT VCB1c2Ugb25lIG9mIGl0cyBnbG9iYWwgYWRkcmVzc2VzIGZyb20gdGhlIFJQTCBkb21haW4gYXMg c291cmNlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxm bzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5j LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIGRlc3Rp bmF0aW9uIE1VU1QgYmUgaXMgaW4gdGhlIHNhbWUgUlBMIG5ldHdvcmsgKHJ1bGVzIGFib3ZlKS48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVm dDo3Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEyJz48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz41KTxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIHR1bm5lbCBlbmRwb2ludCBpcyBk ZXRlcm1pbmVkIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzEyJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNv LWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4i Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+SWYgdGhlIGRlc3RpbmF0aW9uIGlzIGluIHRoZSBSUEwgbmV0d29yayAocnVsZXMgYWJv dmUpIHRoZW4gdGhlIGVuZHBvaW50IGlzIHRoZSBkZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPklmIHRoZSBkZXN0aW5hdGlvbiBpcyBhIGhvc3QgYXR0YWNoZWQg dG8gYSBSUEwgcm91dGVyIHRoZW4gdGhlIGVuZHBvaW50IGlzIHRoYXQgUlBMIHJvdXRlcjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0Ojcy LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xMic+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yy48c3BhbiBzdHls ZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkVsc2UgdGhlIGVuZHBvaW50IGlz IHRoZSByb290PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0n bWFyZ2luLWxlZnQ6NzIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+SXQgYXBwZWFycyB0aGF0IHRoZSBiKSBpcyBu b3Qgc3VwcG9ydGVkIGNvcnJlY3RseSB3aXRoIHRoZSBjdXJyZW50IHNwZWMgc2luY2Ugd2UgZG8g bm90IGhhdmUgYSB3YXkgdG8gaW5qZWN0IGEgcm91dGUgdG8gYW4gZXh0ZXJuYWwgaG9zdCB3aGls ZSBpbmRpY2F0aW5nIHRoYXQgdGhlIGhvc3QgaXMgbm90IGEgbGVhZi48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+UHJvYmFibHkgdGhl IHJvdXRlciB3b3VsZCBwcmVzZW50IGl0c2VsZiBhcyBwYXJlbnQgaW4gYSB0cmFuc2l0IG9wdGlv biwgd2l0aCBhIGJpdCBzYXlpbmcgdGhhdCB0aGUgdGFyZ2V0cyBhcyBub24gcnBsIGhvc3RzLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0gVGhhbmtzIGEgYnVuY2ggZm9yIHlv dXIgY29tbWVudHMuIExldOKAmXMga2VlcCB0aGUgcGlwZSBtb3JlIG9wZW4gdGhhbiBldmVyIHNp bmNlIHdlIGFyZSBpbiBsYXN0IGNhbGwgbm93ITxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PcGluaW9ucz88bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBi b3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxlPSd3aWR0 aDo0MDcuMjVwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjx0YWJs ZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5n PTAgd2lkdGg9NjAwIHN0eWxlPSd3aWR0aDo0NTAuMDVwdCc+PHRyPjx0ZCBjb2xzcGFuPTMgc3R5 bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48L3RkPjwvdHI+PHRyIHN0eWxlPSdoZWlnaHQ6 OTQuMDVwdCc+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gMTEu MjVwdCAxOC4wcHQ7aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzY2NjY2Nic+UGFzY2FsIFRodWJlcnQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJy PjxiPklQdjYgRW5naW5lZXJpbmc8L2I+PGJyPjxiPlByb2R1Y3QgRGV2ZWxvcG1lbnQ8L2I+PGJy PjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjoj NjY2NjY2Jz5wdGh1YmVydEBjaXNjby5jb208L3NwYW4+PC9hPjxicj5QaG9uZTogPGI+KzMzIDQg OTcyMyAyNjM0PC9iPjxicj5Nb2JpbGU6IDxiPiszMyA2IDE5OTggMjk4NTwvYj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC90ZD48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGNt IDBjbSA3LjVwdCAxNS4wcHQ7aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxzcGFu IGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5DaXNjbyBTeXN0ZW1zIEZyYW5jZTwvc3Bhbj48L2I+PHNw YW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxicj5WaWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4g U2lkZTxicj40MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUgPGJyPkJhdGltZW50IFQgMyA8YnI+MDY0 MTAgPGJyPkJJT1QgLSBTT1BISUEgQU5USVBPTElTPGJyPkZyYW5jZTxicj48L3NwYW4+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojNjY2NjY2Jz48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS9nbG9iYWwvRlIvIj48 c3BhbiBsYW5nPUZSIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5DaXNjby5jb208L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PG86cD48L286cD48L3NwYW4+PC9wPjwv dGQ+PHRkIHdpZHRoPTE4NiBzdHlsZT0nd2lkdGg6MTM5Ljc1cHQ7cGFkZGluZzowY20gMGNtIDBj bSAwY207aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZSIHN0 eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiInPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE2NCBoZWln aHQ9MTA4IGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAxLnBuZ0AwMUNCMUY4Qy5G OTQ0Q0ZCMCI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9uZSc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0w IGNlbGxwYWRkaW5nPTAgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdCc+PHRyIHN0eWxl PSdoZWlnaHQ6OTAuOHB0Jz48dGQgd2lkdGg9NzE5IHN0eWxlPSd3aWR0aDo1MzkuMTVwdDtwYWRk aW5nOjBjbSAxOC4wcHQgMGNtIDE4LjBwdDtoZWlnaHQ6OTAuOHB0Jz48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMDA5OTAwJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE4IGhlaWdodD0xOSBp ZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDppbWFnZTAwMi5naWZAMDFDQjFGOEMuRjk0NENGQjAi IGFsdD0iVGhpbmsgYmVmb3JlIHlvdSBwcmludC4iPjwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxl PSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzAwOTkwMCc+VGhpbmsgYmVmb3JlIHlvdSBwcmludC48YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5n PUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6Izk5OTk5OSc+Q2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNw b25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFu dGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUg Y2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1 ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZSwgRm9yIGNvcnBvcmF0 ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+ PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xl Z2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBsYW5nPUZSPmh0dHA6Ly93d3cuY2lzY28uY29tL3dl Yi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbDwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90 ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlI+PG86cD48L286 cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUZSPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1GUj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= ------_=_NextPart_002_01CB1F7D.62B44170-- ------_=_NextPart_001_01CB1F7D.62B44170 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahAST7V/3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L8OpvbV6Ly3WpD7HxVvyWoZOWD40gGTtkZFfTJGnok8g 3137O00SA6kuTJ/LAAKpaX9aaLCRpGWGEziLfjMSgVNvUklRM/uCfUXleQTkkv2mYjExjM98vRH7 TwwskFN+3COA5M/KZrsvINk/5i15BWUVEkixOmllsjPOUfMxn1AkZOT0GkSEJKTivXUHxE1/eoG6 MK8cVQ4UkFoOvnhhyWZhshmEr/cY9wpkdV09QsksWpCp58VSVVfXK5DLfjcT42AgWRMfsPUaMCC9 zicIrcj3hWv37Gf7RffsznCQlZSZh+Onw+AWFosiCg6HwK76PxZIjgJt/MJFILFglyF2UATa226c oQRkI5k6X/Jf2S+cv9NARLfeEQlQ9LABeKgByWmn3465YiHd938fOAqr06FCOdzQQF4iU8d+1eUJ 2oTXl+/AUa9glQCSc4jbLZzF659b/AueI8A2mdj3qCWHGpDc18QVuzCGxjF60UbhLydl5d3YQCZn FWDmFi08/Nlq4bONJGdfx+mMSgBZQ0CuJe342Bdq1Pc6PPq5GlZpHhOVGFUA0pgifPZjH5+7lu7/ T5ix4Qji0rJvbCBTcgoxb6e+CFIYgrHLtsDILUAlgKwlIH8hjciwMGC8Z5HNN+cbVQFITnGN//c2 oQT4Gp9v0xGbgm94IOfs0CPtuFZA8MLSzTB09e/x9cHxqe1R9oLBi7JH9SPKZiA3GNsJEBmwp6n/ NXonegXyyij790GJstXps6r3GWVzkn7ct1sxgoDkzzp7q7Y4EHdDA3kxuxBfbtfFE3PWipv+/JJN MHDpDcihk4dkINcbnRLjGCW0zDqo6dr0CORg5yE9WvOQT/YzD2nmESws0oiFl3fTzyLXiQOdGxpI zoHxacAxpC1YK/GBJusz4T2+PuJipjgXI6oR1GYMcKXmqGeIKBuKSs3Xv+BHrZ4rNZyeYqDGf7tN vH7c0i3YZeUqUkHdyeVKzQkKfjaJSgpXagxdAwYMyMDYi5i5WUuMhfv/bKuOSEn1JLyBhM8bjfpq PZ75aqOItFNyCm5sIHljhI7jGUxXPyRA4E0HIWSWexKuZe+ydBU3kuHdYGTXq99ztUD6xySLieGx sJNv6BKAsh5q2by7xjEoCnN36Ito9YttujgVEIGGHvKorDnNPILw8UYNTCRXg4/mno5MHDAgL2Tl Y4upA976ca/QjnzCMjWn51p2eFI6VlIQxn74++sOknXwQUHpH54g/2OBrG1oQBCZYU6XLD9kCTPP oF7PHnM1xD0sDmt0T1BEe1wAV1RROWBA8hFZPv/8/UELbDNzFMdOe0rUc7ktISMPh0564bsD5vjd xgNx6dk9Ph2DE9F8wIw3PfyH+tdz9sOlXjY/XMtuH8fgKKwmrf6TtjX51tFi+1xPwnsyLbxDxM6m jbSw/WMuoKbuD38QwdCo1PiSr8N7BC9k5fVaqeGaMQcHbgSlU3C0MPm97YfkU4cvdzh1+H4fpw45 t5iQnotT/ufhH933fkg2zwy4rd85hCWloaq250oNA8wPKQiITRZP0Yjr40kUfOrwQ3HqcK0InMb1 cepQ0fqkC+eQGLiSX80PSWhs6rnG3tDYSD58PuwDI+ETkSisVXPzDV6pUUopTRRvKOWb1Ke07oou 6MeOcceQKHL09wgNyVByJBmVktnre9jk8mSW9XPbWQ1BmVNUiqoefMfutHxOUVmfdXsOML78VZei d3WhISet2A1bArmvBV7QtmO8b7i4qsQLvPSPr9AMLSCVGqT/r+3f69kf5ceQcL6Nj8OqG5zs1x7B q63pDsbrM8hfZlPK4+bAadFuIwTEXOzXfby6ezmkDjv8uU8d8g5wbQdfEZl/s8cYNhTBD4F6bb+E 3QXWiEtoQbGmPEJBx6Xcoj/rVN0YQFbX1+Mc+Xi6TmdEhJtMPlPDAB1JGGxhc3qRomRzz2CRiQjt w0eVQKqAsDli3463taUQjIpG1YCxDUoKVFJzCoQ/yWmjIWZeJZDXPLEEYmOTajwX8kppoki5QcUW kgRSigRSihQJpBQJ5FCWpro6NNbUoImiafF9dTVaBtFX5Osor9d4nddrVijE+5tqa0Xj75sbrr50 J96rHBN9VVRVoUV1fU7VA5LjzCaauKqsLGT7+CDNwQEZLi5Id3Ki5oyiyEgxMS3d1ZT5T2zQxDWU l6OuuFg0/p5hbunlKGtzYxOq8/KQc+ZM+/WcnZHu6IiCc+fQUFmF5n6C2Uyw1JWUIC84RIw5w9VV tDT6Pi8wUIypP0Dx9apzc5HNY6JxiDGJ5oqiqCjxmSSQg60RFY0oTknFBTt7BG/7FW7z5sH+rbdw auJEnJowAQ7/mg6/1auRameHusLCTiAqNSpP4Fl1dbjNnAlXasFqashwd0dDRfc7Xero5xkBgQjd tx/uCxe1Xc+OmuP778Pn++WIMTFFceKFXrUlp2wqc/OQ5u2NcwcOwHPJUjh+OAP2770vGo/de+ky xBsYojQhkYBr7nFBcj85gUGI0dGF97ffwf6dd2hMk2BH/bh8MQdBGzYilRZO2aVLaFKRvzqhckDW k9ZLP+2LgLXrcJJuvNnIUdC/915o0vAPtzatm2+G2ajR8P1hJUoSEroAqaisRLyhIazHjcMBev3v 1KxGj0bUwYOoKei6F7CKJj7xuDXcF30N8xfGQv+v90OD3nOo9Xp8bd37H4DNm5ORdNwGjT3UpxvJ POfHxOLcoSNwmj0bFi+8CIMHHoT2rbeK/rhp0tiNHn0MzrM/Q4qDI7kEXWvjjGjRhWREamrBkxbH CYLQ+LHHoUXvP9I6Hv17/wrzMc/Cafp0BG/ajAzfM+JzSyAHSJilOrqhKR4ecFu0CEb33Qdtmjxd GrZ2a9Np/coTo3PHHXD84kvkR0R06YsnJtHMDKcmTRKTxyDYjB+PGC0t1BR1LsvVV1Uj2d4B9h9+ BP177hHX4MbX1Rs2DHoEk95tt0HjlltgRAsj6vARKBSKbrS6Ajlk1v02boLFuPHQoffpdBiz8nvN 1v9bEWQxZkehuOJBUax9C2PjELx9B4699jr07rhTjKXjZ9fq0Kce3SPjx/4Oj0VfIZ1cgoYKlYBy 6ANZT85+iocnXOfOJa3ygJg4rQ4wGhAspqQtTZ58SkwQ/85+1izknT/fVUOSw59kbg67yZPbJtH2 tdcQq6OD2iuAZE0U8MsmmDzyqABXqxVG85Ejcep/34MdmVtu5i+NFxovzsCoi5llPy+XfFrfn3+G 2egx0CKQO45d7847YfzEkzAbMQp6d90lfmfx6muINjahsbbX3Hn0ZWlpCFr3M0yffho6tBA69tO2 MIfd2gVQo4ceggdp00w/f+HySCCvU0oupuC02loYPviQgFGn9UazdrImTeH17+8Q/OsOAY87+5TT P4Cf+noUKU12h0fK9hdIDjxSvX3gNIcWAWkiASNdz3zMGASsX49Udw/yBX1wydMbscamiDiiibzQ cAqMOpf26ihgCj+iAbMXx3ZaSLq33Q6L51+A64KFCCCzyuP3WvYtHD/6GB70NZlNdofjtHU07sST drAhWA937Ie04NGnR8Bh2jR4z5sPD/r8J96YDCNauErNy4vJ5O+PI5Q0a0V6hgTyeoRTI6nOLjgx 5S1ok2lUmkxd0ia25LdF6ukjLzoGFdnZKCUHPvfceaS4uSHd5zSq8wuuGcjG+gYy146wJ0CUQLI2 s546FbGmZqgpKRWmWIyRIGwgbaaore0UqQsTS36j+1dfQ/d/7mo3+bffAStaSEE7dyEjKBhlBEl5 Zhby6XOk+fggxdUNRXHxaOrgjxbGxcFnxUoBltIkM9RWpJn91TfgEpnk0thY5J89i2gjYziSH2pE vq0OActjN7j9drh88gnS3dwlkNcjFTnZCNv9G0zJ2VdqR30C0/bttxFF0WgVBSLKIwMiHUQQMBgM SHM35qnfGpL6zPDyhvuXX8Ko1ZTq0nWNyfy5z1+IWHNLZIWEoDInp8cjC7VlZUi0PoGTU6Z08nUt xo4VMBYlJ3cKgrgfBaekaIyNDHfrIuJ/OWI+PnYcNG+97bJ/eNPNMH/+RQRt2UqWIFF8Zl50zY0K VBcWId7qGOw/+EC4M8rrmj/7HKK1dXpNb0kg+xCOTE+v+AFGd98jgORmQKYzkHypiryrPyHXG5BX BjWlBEyg2hro0/UOdQg+TB76G6wnTITzp5+KFFPCseMoy+y6C521dtiBg6TFXmgPuG6+CW7kBuRG RPZ7zA2krWP1DWD24IPCXGuLRTmMFsYCZIV2f8aGNW7Yvn2weOaZNvOuf/+Dwmy3DO1NJkMbyGwy wZ7kIxrdc6+4sewPGZLpjNPSvqb+rgbIBtI6yba2ODV5CvTJf9XpECi0TfLdd8PmrbcRums3iuMT hO+plLL0dATTz4+OHt32Hl0CMkhNTSTS+yu15RWI0tTC0UcvB1fKRRmyYSOqCrvfsKuoq0eykxNs 33ijPSC7626c3bxZAjkYQMbr6Q06kGwqawoLkeLoCO8fVpKJfF6Y7SsjW23yCS2eegrh5FqUZ2V3 BbJVSymj9OC1a7vNMfYKpIZm90AWFPYMJI3bdtKkdiD/8hcJ5PVKPjnzvitXdTbZ5KCHbduG2tKS q+7vaoBse09DA7kOMYg1MYEfjcV15iwcI8j0WoHUaP3q+PEnuESRd0trZaSC/MvwQ4dh9eKL7Sab mvfX34jMQX+lvrZOVGRMSUsrI2z9YcPg881iFEZFdfueitw8hB08CMsxz7YtBr377sNZum8SyOuQ 8qwshFIAYPrY39sSx5yUdvrkUzJJzqjv5q8McO6PI+A2573DLutrAbKjcBCVExyC0C1bYDFylKi0 6LSmX46TXxljZCI2XVzWbOXCv7TloIZ+r9SoNhMmiOxAZV7XR9/x4S8euzD9ynInfZ5k25M4xqkj up4y3WPzyiuIOnCgPZvQKuxqXHR2pUh7Ngzv+2vbdY1Ji587eEgCeT3SQMAlWtvgxJSposKh3Wr2 OP3hsWSpSJFw8FBXVi6AKk9LR35kFAqiY1BPUe7lWW7uV9qnE5AcsfJuHN6Jc8UOHAYmOyAQDp/O hF5rFMtjsnr5FUSSJmuovpzQ5hpyFsHLuUY98jWVKSsDgsRuxkeIPWqOkpRU1JaUoo5aBZn7wrgE 5J6PoKAks5M/yp+J863GjzzSXt2543acevNNJFhYojwjA/Vk2vl9XNHy+n45TB9/XIArFjHdO9t/ TkMSgT3Ej0EMbSA50VwYGwvfFStgQlGm0uzxjTYhrWk/7V0ErN+A89o6IqINIL/K8z/fI3jHTpQk JbVryKvMQ7J2rSDtnO57hibxFC66uiMrLAw5ERHIpwg5ljSc9auviTKlEhCrV15FlJ4BFNXtFZaq /HyE790Ly2efbYvSuRnefz9s334HvmvWIvywBs4d0RApHM418s9SXFwvp3JahRdckpUVbF9+uc1F EPlF8qdPvvEm/Fb9iLC9+0VxwHHmTJgNHy7ukbIkafzwI/Bf9zMKO9b3JZDXqCUrKpBC0a7jv6ZD lyZA84qgwvjRx0S5zXzsOBjTROiT828/azZyw8I6abyrAVKU/MLDEbR5K+xnfAx78hs9li4TzYt8 NzuKXg1I67T5Z1w/J42Z4uLWSaOKfoKC4LNsmSjhaXTwJTlpbchj59Lj+Jdh8vQIGJAGtJw4SeRY OR/Z4QOgPDkZAatWweChh7qUT9k0m416BibDn4IeBVlaHaDVv/c+OM3+DJfc3NFQM+T/kJJq7Pap zssn7aMvEuIGd7VXPbS621xB0Dp+/gXyzve8ueLkxIntmyteeklsrrgyMZ7l5wcv3szBEf4tw0Q+ Utn0Omg7vdtuxzHSjudIQ3P+78q/fMmbJHj3jsucuTB8/Anq65a28XbZXEG/s5wwCTGmZl02V7AJ T/cPEK6KCe8UojHpdFPP1u5QVuRyqyMtJnZ7aopLhvo0qw6QLBU02fHmFnCnKNX8pZdFOU6jddvV kQ5b0HTvuBNui5eQPxbfFUjStvFGRrAePx4H6bW8Bc2KIuaoQ4dEiqddobYgkzSb6/z5YnL3t245 69j42kYPPwy76R/i7O49KIyJExt5u5Pa0lKkkobyXbMOx96YDIMH/9Zp7Nx4PBoEmc277yGR3ITG bp77U09mPIv81wAy69Zk8g3IjdHs0IcyLcT50WOvvw6v777HhVP2qC0uVoUpVi0gxcRSoJIZFIwI HT2cJsfd8Z13YE/m12HqVNhTNMum2HPefAFuFWnVK4W3++f4+yOMomTPOXPgQe3s+vXI9PJCwxV7 BkvT04VWdp0xQwQPfA1l4+s4krYOUFPDBXsHFJM5bVL0/qweRW0d8mJiKZixQID6ejiTibejYM2B xs3tJPXpPOszEQkX0Ot6Kkky9EWJSYg/bg2/n36C07RpbfdA9EXj8l68GNFk9rNDw1BXPmT+Bs2f D0ihvWiimkh7VFF0nePri0xXV2QRUJkUXWa4uaE4KupyLbiHIwwieuazJwQgN/6ef3alqeX3sxnP CwgQRwz4GsrG1+HjE5UU3bIp7W/g2tKa1qkjjZkfGir6yfL0FI2vkR8SIn7X13EIUbenfqpzcsSx io73INPdvfd7IIEcPGEY+FgCBxLioFd9/YBfo6XjNZSNrtPch0bse/DNnfvlcz3XkCPscg84D6q6 T7iQx2ClSCClSJFASpFASpEigZQigZQiRQIpRQIpRYoEUooEUooUCaQUKRJIKRJIKVIkkFIkkFKk SCClSCClSJFASpFASpEigZQigZQi5Q+U3RJIKUMSyF2yyTYE2nsCSP5HNtmGSvs/hQgkdONYbE8A AAAASUVORK5CYII= ------_=_NextPart_001_01CB1F7D.62B44170 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CB1F7D.62B44170-- From richard.kelsey@ember.com Fri Jul 9 09:31:20 2010 Return-Path: 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 93A0F3A67CF for ; Fri, 9 Jul 2010 09:31:19 -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 amuJBy+cLZTS for ; Fri, 9 Jul 2010 09:31:16 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id CAC2B3A6946 for ; Fri, 9 Jul 2010 09:31:13 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 12:31:18 -0400 Date: Fri, 09 Jul 2010 12:31:43 -0400 Message-Id: <87tyo8fwgg.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Jul 2010 16:31:18.0476 (UTC) FILETIME=[286FF0C0:01CB1F84] Cc: roll@ietf.org Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 09 Jul 2010 16:31:20 -0000 > Date: Fri, 9 Jul 2010 17:42:47 +0200 > From: "Pascal Thubert (pthubert)" > > [Pascal] -10 allows both but it seems redundant. Since the instance > has to be in the flow label for an end point to indicate it, then why > not let it there all the time? If the ingress router has to figure out > the instance ID by some magic, in any fashion it can place the result > in the flow label. Pascal, I don't see how this works. The RPL draft says: If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the RPL Hop-by-hop option. How does the ingress router determine whether or not the flow label contains a RPLInstanceID? It isn't safe to assume that any non-zero flow label is necessarily a RPLInstanceID. -Richard From pal@cs.stanford.edu Fri Jul 9 10:25:44 2010 Return-Path: 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 570D73A6964 for ; Fri, 9 Jul 2010 10:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 YQWbzQNx4D+E for ; Fri, 9 Jul 2010 10:25:38 -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 88D853A6AB3 for ; Fri, 9 Jul 2010 10:25:37 -0700 (PDT) Received: from dn0a208a69.sunet ([10.32.138.105]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OXHKX-0003k8-Fs; Fri, 09 Jul 2010 10:25:42 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6427.1278635611@marajade.sandelman.ca> Date: Fri, 9 Jul 2010 10:25:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39D6B8E1-CD63-489E-97E3-A43407ED92C8@cs.stanford.edu> References: <6427.1278635611@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 141d226533ffcaa1e99d974c461e2c05 Cc: ROLL WG Subject: Re: [Roll] rpl-10 --- security questions 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: , X-List-Received-Date: Fri, 09 Jul 2010 17:25:44 -0000 Comments inline. Rene, there are 3-4 questions for you to answer. Please = take a look. On Jul 8, 2010, at 5:33 PM, Michael Richardson wrote: >=20 > {I have a lot of comments here on rpl-10, mostly about the security=20 > stuff present since rpl-09} >=20 > Exec summary: > *** I am not happy with the lack of algorithm agility implied by > RPL-10. CCM*-AES-128 and the ECPVS signature scheme[X9.92] > appear to be hard coded. While there are some bits to permit > up to 3 additional algorithms to be used, I can see no bits to > permit a different signature algorithm. =20 >=20 > *** I am *not* of the opinion that AH would be a better choice here. > AH can be made to work, but we will essentially be creating a new > mode of AH, which is replay-enabled while still being multicast = and > multi-sender capable. =20 > What I am saying is that there is no code savings: restricted code > size system won't care AH vs RPL10, because they won't have any AH > code to reuse. Systems with AH will have to implement new code > anyway, and it will be harder to implement RPL on any system that > already has IPsec because the code may be hard to modify. >=20 > I am of the STRONG opinion that the text, and essential packet > format of the AH specification should be extensively used. =20 >=20 >=20 > =3D=3D=3D my detailed comments. >=20 > In section 5.1, RPL Security Fields, the Key Identifier may be present > depending upon the value of the KIM field. >=20 > When KIM is 00, 01, and 10, the presence, absence of the Key = Identifier > is clear. (But, if Group key is used, then Key Source is not used, > because, I guess, the Key Index is no longer a local key, but a global > key, so that's why the Key Source is not present?) >=20 > When KIM is 11, a signature is present. Where is the signature = defined? > What is the format of the signature? =20 > When KIM is 11, a key source *MAY* be present and a key index *MAY* be > present. How is this determined? > I think it may come out of the security level, but I don't quite see = how. Rene and Kris, can you answer this? >=20 > It appears that the RPL security fields are not a multiple of 64-bits, > and block-mode AES requires 16-byte blocks, while CCM mode is happy = with > any increment of bits. Assuming that someone will define a second > cipher at some point, we need to know how to padd properly.=20 > But, I don't see any statement about how padding is to be used. >=20 > I am not happy with the text of 9.2. =20 > I suggest it should say: >=20 > Authenticated mode requires a would-be router to dynamically install > new keys once they have joined a network as a host. Having joined = as > a host, the node would then use standard IP messaging to communicate > with an authorization server, and new keys would be provided. >=20 > A protocol to obtain such keys is the subject of a future standard. OK. >=20 > =3D=3D=3D >=20 > I also see no way for a node to tell if it is joining an authenticated > network or a pre-installed network. How does a node which is > authenticated know which set of keys (pre-installed or authenticated) = to > use to authenticate a message from a new prospective node?=20 > Is this an inate property of the keys themselves indicated by the Key > Source and Key Index? =20 >=20 > The 'A' bit of the Configuration Option tells a node what it may do. >=20 > section 9.3: > 2. When a node resets its Trickle timer in response to a secure DIS > (Section 7.3), the next DIO it transmits MUST be a secure DIO > with the same security configuration as the secure DIS. If a > node receives multiple secure DIS messages before it transmits a > DIO, the secure DIO MUST have the same security configuration as > the last DIS it is responding to. >=20 > The fact that the DIO transmitted is always the same as the last DIS = it > received means that any DIS received before may never get replied to > using an acceptable (to that transmitter) level of security. =20 > Isn't this an opening for a bid-down attack? What's a better way to do it? It MUST respond with the same security = configuration as the first DIS? This opens a network up to a denial of = service attack: as soon as a node sends a DIO, the adversary sends a = DIS. The assumption here is that it's much harder to ensure you send the = last DIS than the first one, because the DIO transmission time is = randomized. Security policies can always discard DIOs whose security = configuration is below what is acceptable. > The rules for the 'A' bit of the configuration option are written = wrong. > They give rules for what a node MAY NOT do, but nodes will do what = they > like. What we need are rules to determine what a message being > processed with a non-Authenticated keyset may express. =20 >=20 > Text like this: >=20 > When processing DIO messages secured with Key Index 0x00 in a DODAG > that is marked as authenticated, a processing node MUST consider the > advertised rank to be INFINITE_RANK. Any other value results in the > message being discarded.=20 >=20 > When processing DAO messages secured with Key index 0x00 in a DODAG > that is marked as authenticated, a processing node MUST ensure that > any RPL Target Option containing the same address as the message's > source address. Right -- this reverses the requirement. Seems reasonable. >=20 > ...continuing with >=20 > The above rules mean that in RPL Instances where the 'A' bit is set, > using Key Index 0x00 a node can join the RPL Instance as a host but > not a router. A node must communicate with a key authority to = obtain > a key that will enable it to act as a router. =20 >=20 >=20 > {Why not just ignore any Target Option prefixes, and take the value = from > the source address? That way, you can avoid sending unnecessary bytes} OK. >=20 >=20 > 9.4: >=20 > - the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL = nodes > + the 'C' bit is set, this Counter field can be 1 or 4 bytes. RPL = nodes >=20 >=20 >> 2. If a node receives a secure RPL message with the C bit set and = is >> uncertain of the 32-bit counter value, it MAY send a CC message >> with the R bit cleared to obtain an uncompressed counter value. >> The Nonce field of the CC message SHOULD be a random or >> pseudorandom number. >=20 > It says, "MAY". What other choices does the node have?=20 > What does the node do with the message it received? Discard? > Are there parts of the message that may still be trustworthy? > Is there any point in asking for an update on the CC if the message = does > not change any state? The point of the MAY here is to state that it's the implementation's = decision of when to do so.=20 >=20 >> 3. If a node receives a unicast CC message with the R bit cleared, >> and it is a member of or is in the process of joining the >> associated DODAG, it SHOULD respond with a unicast CC message to >> the sender. This response MUST have the C bit of the security >> section cleared, MUST have the R bit set, and MUST have the same >> Nonce, RPLInstanceID and DODAGID fields as the message it >> received. >=20 > It seems like this should have been discussed more in the section 3? >=20 > Why is the nonce only 16-bits? Seems small to me. There needs to be > advice that the nonce is not an incrementing integer! (cf. DNS queries > with 16-bit ids). I don't think the problem follows; in DNS the need for random IDs stems = from the lack of integrity (an adversary can generate a response). In = this case, the ID is intended to avoid attacks where an adversary = replays a response. > Why is the destination counter included? Of what use is that? > Is it valid to send CC messages to peers which are not onlink (one = hop)? > I.e. can CC messages be meaningfully routed across the DAG? > I'm asking, not because I think they should be forbidden, but because = if > they are not forbidden, then we might need to say so lest someone = makes > a different decision. The destination counter is for when a node reboots (a common issue in = LLNs, e.g. due to low power). If it can't store its counter value, then = nodes will ignore its messages until it counts to where it was before it = rebooted. The destination counter provides a mechanism where it can sync = with the last counter it set before rebooting. >=20 >> 2. The timestamp MUST be in 1kHz (millisecond) granularity. >=20 > Is it 1/1000 that one wants, or 1/1024? Good question -- Rene? >=20 >> 3. The timestamp start time MUST be January 1, 2010, 12:00:00AM = UTC. >=20 > Making it Unix epoch (Jan. 1, 1970) would be simpler. > As the specification says we are supposed to keep 6 bytes (48 bits) of > resolution, this is 274877906944s, or 8700 years. If we go to Jan. = 1970, > then this changes the lifetime of RPL from 8716 years to 8675 years. >=20 > As I understand it, we are only transmitting the lower 32-bits of the > value, in units of 1/1000s. So the timestamp for my email would be: > Unix time(1278331381) * 1000 mod (2^32) =3D 2726094088.=20 >=20 >> 7. If a node does not have a local timestamp that satisfies the >> above requirements, it MUST ignore the 'T' flag. >=20 > I think this is confusing. I think it means that if a node does not=20= > have a timestamp that meets the requirements, it must set the 'T' flag > to zero. The question of what a node does with a message with the 'T' > flag set, where the node has no concept of time is not dealt with, I > think. >=20 > Also, I guess that if keys have Start Times and End Times, then in > principle, one can have multiple keys with index 0x00, which are > non-overlapping in time. In principle, that is, if every node has a > clock! =20 >=20 > If a node hasn't a clock, while I can see ways to pick the key by = either > trying all of them, or using the Counter value as a clue, it seems = that > this introduces windows for replay attacks that the counters had just > closed. >=20 >> node's security policy database. The configuration of this security >> policy database for outgoing packet processing is TBD (it may, for >=20 > the term "security policy database", while generically used here, may > well be confused with IPsec's SPD. >=20 >> to the particular destination address. Where a Counter for the >> intended destination address has not been established, the Counter >> value MUST be initialized to zero and sent as a Full Counter for the >> initial RPL message transmission. >=20 > To aid in implementation, can we please start the Counter at 1, and > even better, forbid 32-bit Counter values of 0 (matters when the = counter > rolls). >=20 > The entire Compressed Counter mechanism seems like a waste of code > space. I see no savings by doing this in the resulting packets due to > required padding. The ensuing CC process that is needed to deal with > this seems like a further waste. I'd rather define a standard > compression algorithm that we can apply before encryption instead.=20 >=20 > I was excited by section 9.5.1, because it was going to tell me which > bits to apply the AES-CCM encryption bits to, and which bits to > authenticate. It failed to do that. =20 >=20 > Do I understand that the security bits themselves are *NOT* integrity > protected?=20 >=20 > page 74, re: zero-value Full Counter receipt. > Is the message itself discarded then? Assume that it otherwise passes > all processing. =20 >=20 >> protection for a received RPL message. The replay check MUST be >> performed following the authentication of the received packet. The >=20 > well, no. The replay check SHOULD be preformed before authentication = of > the packet. If the replay counter says "old", then you discard = without > further processing (do not waste your time/energy verifying old > packets!). If the replay says "new", then you can authenticate first, = and > update the counters if it checks out. =20 >=20 > I can't tell from the specification if the contents of the "Security > Section" are protected in any way by the integrity check. Section 9.6 > was not helpful, as it says "entire IPv6 packet". I guess this means = the > layer-3, but someone will get it wrong, and include layer-2 too. > When the integrity check is calculated, what is the value in the > security section for the MAC code?=20 >=20 > (I would assume zeroes..) =20 >=20 > Should any fields in the layer-3 (IPv6 base header) be skipped, the = way > that AH skips them? What about any extension headers present? =20 >=20 > As the recommended MUST is AES-CCM mode, which performs both integrity = and > encryption at the same time, I don't know how one can have the bytes > under integrity check different from those that are encrypted.=20 >=20 > Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for some = text > to steal. Note that this might=20 >=20 > section 9.5.3.1: I have no idea where in the packet the nonce goes. > Is it simply created as input into the CCM* star? Or does it have to = be > transmitted somewhere? (I don't think so) =20 >=20 > *** I am not happy with the lack of algorithm agility implied by = RPL-10 *** >=20 > 9.5.3.2: I am not happy with specification of a possibly encumbered > elliptic curve here. Has then been a proper IPR disclosure? > There is no algorithm agility available here either. Rene, can you respond to this? Phil From navagar@cisco.com Fri Jul 9 10:25:45 2010 Return-Path: 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 BD2A33A6AB1 for ; Fri, 9 Jul 2010 10:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ruPT-BjdOxR7 for ; Fri, 9 Jul 2010 10:25:38 -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 56E7D3A6AAE for ; Fri, 9 Jul 2010 10:25:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: RPL-Path Control_RA-01.pdf : 75071 X-IronPort-AV: E=Sophos;i="4.53,564,1272844800"; d="pdf'?scan'208,217";a="556693099" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 09 Jul 2010 17:25:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69HPbK9019267; Fri, 9 Jul 2010 17:25:37 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 22:55:37 +0530 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_01CB1F8B.BEB4B661" Date: Fri, 9 Jul 2010 22:55:34 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQ== From: "Navneet Agarwal (navagar)" To: "ROLL WG" X-OriginalArrivalTime: 09 Jul 2010 17:25:37.0561 (UTC) FILETIME=[BF00D890:01CB1F8B] Subject: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Fri, 09 Jul 2010 17:25:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1F8B.BEB4B661 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB1F8B.BEB4B661" ------_=_NextPart_002_01CB1F8B.BEB4B661 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =20 Scenario-1: =20 A B \ / \ / C / \ / \ D E =20 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. Assume path control allows two paths. D and E have learnt a common prefix for a node below them, Pfx D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will set x10 in Path control of DAO sent to A C will set x01 in Path control of DAO sent to B =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =20 Scenario-2: =20 F G \ / \ / A | | C / \ / \ D E =20 D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will send a DAO with path control x11 to A A will send a DAO with path control x01 to F A will send a DAO with path control x10 to G =20 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =20 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =20 Scenario-3 =20 F G \ / \ / A | | C / \ / \ D E =20 Suppose G is preferred over F. Suppose path from E to D is down. D sends DAO with path control x10 to C C sends DAO with path control x10 to A A sends DAO with path control x10 to G =20 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =20 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =20 Thanks =20 Regards, Navneet ------_=_NextPart_002_01CB1F8B.BEB4B661 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = WG:
I am=20 trying to get some clarifications on expected behavior. Have read the = Path=20 Control document on path ctl field usage (attached). I have put several = setups=20 and flows, assuming storing nodes but should apply for non-storing = scenario as=20 well. I could not figure out from the reading the doc or the=20 RFC.
 
Scenario-1:
 
A     B
\      /
 \  =20 /
  =20 C
  = / =20 \
 /    \
D     E
 
A, B - = DAO=20 Parents.....C - Node........D,E- nodes in subdag.
Assume = path control=20 allows two paths.
D and = E have learnt=20 a common prefix for a node below them, Pfx
D will = set x10 in=20 Path control of DAO sent to C
E will = set x01 in=20 Path control of DAO sent to C
C will = set x10 in=20 Path control of DAO sent to A
C will = set x01 in=20 Path control of DAO sent to B
 
Suppose E sends a=20 no-Path DAO to C for Pfx with path control x01. What does C do? I would = think=20 that C will need to send a no-Path. But it has to remember that it had = sent a=20 DAO with path control x01 to B. If this has to happen then C would have = to=20 remember for each prefix what path control was sent to which parent, = which does=20 not seem correct as it would not scale as the prefixes at C scale, each = having=20 its own path control settings.
 
Scenario-2:
 
F     G
\   =20 /
 \ =20 /
  =20 A
   =20 |
   =20 |
  =20 C
  = / =20 \
 /    \
D     E
 
D will = set x10 in=20 Path control of DAO sent to C
E will = set x01 in=20 Path control of DAO sent to C
C will send a DAO with path = control x11 to=20 A
A will send a DAO with path = control x01 to=20 F
A will send a DAO with path = control x10 to=20 G
 
Suppose E sends a no-Path to C = (path control=20 x01). What does C do? It will likely send a DAO to A with path control = x10. What=20 will A do when it receives a DAO with this path control when its = previous path=20 control was x11?
 
I see couple of other flows where = path=20 control settings may change due to sub-nodes going away and coming back = up...for=20 example:
 
Scenario-3
 
F     G
\   =20 /
 \ =20 /
  =20 A
   =20 |
   =20 |
  =20 C
  = / =20 \
 /    \
D    =20 E
 
Suppose G is preferred over = F.
Suppose path from E to D is=20 down.
D sends DAO with path control x10 = to=20 C
C sends DAO with path control x10 = to=20 A
A sends DAO with path control x10 = to=20 G
 
After some time E comes up and = sends a DAO=20 with path control x01 (higher path preference than D to C) to = C.
C merges this and sends a DAO with = path=20 control x11 to A. What does A do since is has indicated a path control = of x10 to=20 G. In normal terms, if A had received a DAO with path control x11 from = C, it=20 would have notified DAO to F with path control x10 and DAO to G with = path=20 control x01 but due to transient conditions it could be = reversed.
 
Will appreciate if it can be = clarified if=20 the above flows are reasonable and what should happen...in general I = dont think=20 path control should mandate which path control bits are tied to which = DAO parent=20 etc...
 
Thanks
 
Regards,
Navneet
=
------_=_NextPart_002_01CB1F8B.BEB4B661-- ------_=_NextPart_001_01CB1F8B.BEB4B661 Content-Type: application/octet-stream; name="RPL-Path Control_RA-01.pdf" Content-Transfer-Encoding: base64 Content-Description: RPL-Path Control_RA-01.pdf Content-Disposition: attachment; filename="RPL-Path Control_RA-01.pdf" JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO1d2W8jtxmHatmWLMG21t7N5thUabuNtI24w2OGnB4vBYoCQV8S+G3Tp7QJ UCALxP3j+u+VHGnIb2Z+4lCHt1k3uw8mhvz43QePGf04z5hQ88z9rxvf/nDx+ms9//7fF9Xj+dd/ 3TTuv7/48UIxXhSFrh7Q9rc/zP98ZwHNnHOWqfnddxe86uBzLea5YHkxv/vh4s1isFxlLM/KnPPF L5arnHGpc704WWom7WzlYrjkzGQqF7T7dJkxrWQm9eJsaZjRsjSL86VkRc5VuRjZZ4URpViMlytu WdE5X3zzdpmzIlOFWEz8yAA9tVOarNCioCO/uV+uSlZII/LFpZ2LlbnkskH11XJlmFTSAgZar5cF MzIv1WLmWyMLz3mRM2Gbf7/7shJPybhw0lGFZMpJ/O4fFxbm7l9N4SknsHXnyHWuVGHmK17B+Id/ ubv46sJyy7NSGqtBqW3LzslynVmqK9Vt703SJ7calKwULYXqzDLpFGolU5FumfLjDKv5mm866SSS iXXvG6fgwj7OuLD6z1ihpSq5Faq0hOSKW63bfl2Y3Olt5WaQWWnVrpg2XDu12/5cCqNpc+yawlge nWItmLYiUHQEmYzgxbNNlk5ymRLWYCzpUujCGYmVVWZkl+xCFQ2sl4EYgvXK2puQSpRkqj62r62t SWeYFumKW/IKTcFnlpLMk7LiimWWUkIfHurs3aqES0vg+nmpcmkWT5aCaSvlvCahsvGaAiLim+VK WF5KWRAOAq5bOJJKiLD41Dmc4UbJxbPKYaS0cjK1uXzgvDTXUlIYbEPPlysrgJK3tDGzCDTjWhFa va4dqw7p2qv2iH1czW3syUzLV4pSWrEFZ7E+nltX+NvF3SvnAjbuZVm5iYBVa+hbA9869a0z3zoH rdA78q2xb1lZ1M0JQVKZU2YK2h8mmkYJI5PfV01hXQV2vw140JQE92WjW5Q2TJNnA0DZGeLmBFAR 2D4B0hsHYDRwGqUhrsCOnDbNysxtNC2L2syv4DyesMDqKUBzheR5DeREuglB04Bn5h8+iVtSoJLq yPG12jBm06Bz44q7G0DqOZBmQHULxiEJXwIuR4jgUWAysDaDXHR7zwD9iGpq7hMw4y0QL7Ilohxs dIAXZKfXAB+lEfE6RFTE1YYiFhVe19xvIH/AiZHOrwFZszgnbxGWMONT33rmWx8QzEVma1lZts3b RXTHDRHULcAe6B0DQY3BOKTVMREo4Os54uvDqA0i+75FWO4JYR7LOZgbxrvQfQMYvAQCG6CkcQYm DNMES5gE4Bswd8MU9o/s1Aa75o2tEWVcRMOB5uTRHGRPH0XCem33MDMErOdERl119xYoMVu5RPwm zzNAqIOAR2AgRoMKtKBxZO698gdePAQSHQIs6RYW96pUH/gYWH6IOJ8gd4YeeY+aQWQTAPMRJBuU S6lm1JP/GuEMBCcsqJ600VOhXYM5Z2jgc8AtWmJsic6enQMzQ9dIadIBJWaY5wWgESUGgu9T6ilO wvbP5249VpD12Hr3pKiq0MV/NvsSJgwgGy71rgVdzoXNmjcweiBrvgaCf4K0BrWB66IgMBAdeqwo QLcF79ZsTV2JssyL9DostZoNEL8kkROUsITsAeCK1t4eep4YwPYqlMPAbqQ7A8DXgS5UmgZ8I0Ah rFFgqiJ20OMlvTFoCBhHJhwv4mAun6YOhPnh2AvFjwMSnKPq1jNAdu+agoieuGgrQjWD0+qho9Nn yKbvkSpQrR4vbdACnJRIp2AalMR6pDkGHBDX36OChPtNeG0E0CBJjCHdHvhXcdNH1KaWX3Troxue jrUJsteWhceyQ5zrCVQPFxngGuDXMF2AxIgKpGNJD5ED3XbaDjUrSaXnz2uycNYklDv722xID5Y5 k8IUysbGlWa8LIxyD0vBhMk3sUuQU76ctSMTmbp52pOzTEtjbJWqWJmpTFmjV4xzk+e2jFdM5iJz WUUynWtLgVVHyTIh8rKK2YwXupDWkARThSjc0YFgRsiczvOJO8QwquTVfn7d77IxK6QqjJWaOyDk XBFEQ3dcIKWFW4dtN1Yaq7LuUEKTy72GldwWSk+XtiF1oQklV+5gIct0aVwIyRk3WSbp05PqIFGI jBOJXHqcgfogOQJCaD61JGkhuW7KxiUNUYeE118LopeVMMzmHDtEb5zKeh3LjaXcYpMWsMjNlme5 cCRs5iSWIDgzrYM/ipK7I5PaFk6qY9pMcWfZtkOW2rhCULCCc6GqY9pcKsmtw9ZSGFkpcG6VSEDG QR5hoFs6W/ZyoXOrDpccueZ09jB0uj5I0so4xdcHt2TW6gy40Nrq42oprA+oajfFqtPwojpvruc/ rxM7Scxr3xOVezm2fxONgSgZoqV/ankGo9kURWSUzV7GZwwgPdt2vfV03dqrmoxXAGhymjPA8n2f crJu9VWT3dSM68r43g0J9njvI61mIOvw+Flfcj1GV5DJa43edAbzYt1KLU3hPuoMpVe0N5Rcr2Ei wAL1FODbYclbt+YIS/yAEJsH2Ewg5ATUwY0+I9AxyeOTs64nvA9naPGasOcoe6tP1Cej+MCsK/n4 NvYEyPFFnMYBFHhfgO8KAB274rVFCHB9mtk/8MJV/m8TLfQMpYbUzdX4/Q20GzQFDoErBOCoPYcZ qXpshF+AZnfzPHBPHOulO/khSXACmKK5IHpjBYW77Yib92LoFnrqtZhmiFxfi4nvtZ8iLLuRvR4H tnNg4sKb2qlJk6a4rkMgiFNkqXtd1ohReBtPEDDR0GDRY+ifA3rx9Zz4kQhSbGqBREqAkNsCszdE Fl2Da3uWqG5LIouK1xlDINyRN/XkRco9WnxAj0LZadxOgdLgrbYhkAm6wYG8un1TqmnpfVvj3ywA wmC4KMPA3a4leIhPt+PHFU2uRZnzAi5IYWTFa9i+aza757fjH1bgPDkFokKH0O3qxTkNXjZGN2q3 Zoq102yJSHXrFYWOMhPPoyPkNDMqqe6MPUdu9wBh+ybKtsX0KUEH1ngoAP4OuE8P2XAFgTSDJBbf Nt6yxu/xiri24sEgeZsGLfxoMRqv7ZEXEjRftECcU0CbgFvj8Wu+wSlwGQawUA8fAwn0XUgFTrHl MKYrlX0upMaW1UPI1bEvAsG9uUAsusAD772lx/dtzrDyY1iYNmS819G4+GGUulRhfBBEEK6QZmAg B9wi/eMQ5pE89T4TL3zDrXoUCVeE/kBgC0lThHssppN07Rym76YXUkXsGuZhm9Tx6BeEfYuwxF1s Wxxr11NUhj0JAa0O4ytZWByjJRPaU9pS1IOVBbKDlINUZ9tb7AXkg4Qt4+1ugF8nQMVxevRuRURp jrZExaYVywc9yzK0tzqLUoju4p+TWRI3IBC64AY4bRy6WiDw1QFewZRZn4zPBVu/cGlTR+fejXQH nqvNiDeNRNI+hBe6Gts6h2+8CkZWdfG1+nmvrCKOeQ/0RcMEcKOd1urbGXhJiQAWh15Yi98h7LsI Amq31EO9k3bt1gTu2bfep4KK5ayeXJqSGJupNF4Bw0XTTseAa2ft24YiRtDjwbvfLz3SCRtdIKVe U43XCHA7b0JnBGab+o5Qz2X/xlIqvhcXL7sx+EPcBw1zx96UPJLXpx7lww3hXW6G1s1Yyui4gc8Z 7sSwvq3VJe5dt4Ah7N4Kiw4BWx4J7j5Gi6zWwnrsafI0D0bh67ZlNKqGR2MBcnckfSCxceoQThBw vrsY8j3GtWzhEZhAqhYJkkMU/4AmQIBTVbuPMTwWE0hXfIBIRJI69UOawO6q3ccY1lWRrq9ZL6oa YbV+Qivo98hC9rGLRCS7T/1uLOQhbaVbN3dCCFpy/aQMJpSHZAsf7uYHcAhTQJA4Hr07GhZHg7iF 8xgyD4CGMOXu5P4egnQNBwL/IVDWKVV/8oZ1nDC8h59jkN3D4kGcHJnCPoiuQclHZjCppvOABrPH Oiqdk3dqMPIxFjeptnJ0C9ljmbUPJ+/AQjpB471dAYV8GuqSnqoGYkHz4ErnHdgALKcCNfFqKs4T Laseiw0cPQwf4m7HN4F96pz/N9Umx8/3U7UdhT7OI4xkJPuUhj8lzdJK4vGeR+yBJKSskOR60/mD sbIKwIEcXBU80ijbfOXqYCTrb2Klb9AdtCEOgX/WU5qempe8+zR20LZ0D/DPGttHY326O2iPP5nC R6q7/wESehc/3KClmbFVIS7cFxxblyKP9Krbp6D7j76FX3701B30Iam+i5IeC3qrEb2pHEgMdKG7 cPTbzx7Jn6JywN+YOeTK2IDIs4tlyzWx2Ete+DsRPTczd3snz7Xgx2uP+GXA+odhwreZ/BZ4Wf1m SvUJt8R/S6ksFp5DgPDrFpaOuZJqXti/cn7/z4vv9vtpH1F9xVBUv20x8veji/U3DZWar4z75lPr +nT9CziSOR49iwP3fSYtFF+88i0rPiFZXnJNup22N82h7576ZyP/7Mw/m/nWS9/rtLB5OPAPx3HU I986ASDX/tkJmbpuTdu9QpWEgc3AvNCE2jPAyzQukgByCcQUQMZYEOtW5uza978Fghr6Z+cAzQv/ 7AmgO8BeBnxrRxC6cF8k2/j6hEzTVfQQqDyg+wLwHGQzAwoKOK6BSgM2Ii/b7GK5BUqDdhVY+agz TUYNC6l8i/7oPWphMiaFc0Kz+cTMOSDoZVSnSIxTwGDoPQHKeAFwDIAcTohyu3iRz03avVI2VdVF MkC6CJxcrp9lvEFrq7fByQSY1RBy7HXbCQbK/a5YxCMbvCD2CS+h+5Tou+tewcyhs0+JOdTdX6TG zDA3ksmTOFeEiEnU/qi9dAm7BY6Pwgd0yTEg9pwQ03C0tVhX68y2eeMoqLVu3XjwzwAVs2jAOkVW dAnMd4RUiQJk0MslwDwDU18BDUDlTzrE0qiIUgJKmMEozwEEEhzhGCEJtKJ4RJzuORGIr5m+uvgv 2aKlumVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozNjk4CmVuZG9iagoyNyAwIG9iago8PC9MZW5n dGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztXelv3MYVh2zrWhnS6vCR OklXbYMsg+yYM7wTIG3TBAGKfomhb04/JU2AAAkQ9/8HOiTFmUfOj2+GuytVdgTDwIjLud59zDz+ toiFShdx/a9rfP/L7OWrYvHTf2fN48Wrb64bb36a/TZLhczzvGge0Pb3vyy+vNIdy4WUIk4XVz/O ZPODXBRqkSmR5YurX2avlzvRKhZZXGVSLh9Eq0zIpMiK5cOoEIkerVo+iqQo4zRT9OfdKBZFmsRJ sdyLSlEWSVUu96NE5JlMq+WBfpaXqlLLw2gl9VaKTC6/+zXKRB6nuVoemTdt78d6yDLOC5XTN797 E60qkSelypbHeixRZYlMeqs+iValSNJEd7RrnUe5KJOsSpenpnWg+0uZZ0Lp5r+v/tmApxJS1dBJ 80SkNcSvfpgtz6Krn/vAS2uAtT8e1D+u0rxcrGTTxzx8+UrFtku8yIu4gfMPDZxzkZVSlhqMiX6a Z2XvWSriLC1zvdxMFXrBql2gUnZApTfXrXDhzidr/Lc/v9b4q+Eep7IGiv4hqYpSY22lRC6lShu4 ZxpoUmNNiVIlWUr7zGtUlzLXGDzReKmqotDNs6gSSZlotNUPr8Hfe1UpTbZ6F4cNTpSKZYu1vChk anslZNbH0SoRlSrSskZ2h6vDqIatLHD/3qz21f1rrMp0UW+krKGySnKNp3pZLWDeqwk7jqtCT9y1 dsCzh6b1CLx3alp7oIVG1jRtX1xJjfhYw+mYneXAtA5HV6hSRXqcm9aJnWQfdLYDXphW/Z6qNA/C xdj3zsh4ZhILL41FDrB75FfTux0yKWmXI7DYDwC8CGTRfHa1pw15JHEuKsMnR2BAsis7IMIU2SmC LFnYGXzRTLOH+vxhDfrMYy3Zk6re5+p6o1rmiUy1u70gsHC774Jnp2yPY7BE+8zu6oDuz+z6AIDn lB0b06ALEkJZBB08XfIMH0z9/NCwM2L4M37ZiBot+iAJPgLUj2C8axeGpNw56PIILHsO0WLfM5OQ Jc7BiJDH7HJOweBTRK2HYcjsttc+eDYHq4RoOAILRtK9h3azic0ZuNYXmIHNJC/MQ6ss3wfLfhp1 +gLxLxTQhOqfgxH/wnLjqe2MWLSH9kCxjTSn3cwhYJneZgA5Q6RjBe3Sk08/s/v3oc1D6k9ZaTyC TQBSpLbIz0iS0N2YLaKfkVA5QyuDUv8cTePRDz0B6rYQeUGewvaPu4d90gLmwQHovC2b1aX1HfDe KdJbEAefgjXMwYjnoLUH9YNnwrXUB9nNCIOo0uF8Xr74rF6XSKGUQnxGbMZdFtDT7RrK62CStnOt PcZMwlYVhJttrPF0wK6fWpG8CP8IiYQWsrW3gbQxNmBZTUDtNmA9IZggbjwh0Blddt08CvVQ5mic Nw2yMkmFH/RA6uALUtceTfLJOnTdtRBZBxtSZ+TZ7dpMXq+HPhw3mjD3DNzkMf5GkoWicMeQPdI3 UEevpQjD/IwDJAA8Xv0ZvzAslgGrIDsCKUVo/o/4kUBbeznFQt9i7Bw82yRUReBzAia5REYl8qrs tnbBrxeGUTCNskYDMoCtRjlFW/EEVGCcyOf/s2w2wlzuz9iRgNLPZZSRLgBFmKU40nnILwfaxCP+ qEsnE5SYmYZKcA+joHDeJaAfiO3naI87DfSvp/jX7OoTau7udIFkEl5XaRND7l7NRKLKPNW+1qoQ ssrLVBNdViltLmbXnUnoXmYi70fu6dAyEaqjgHkT7k7SvNTwSYWUZVZnPuokipRpvS3dlHGWaN+u jnGnlX6DPm4grEQhc9pvz8Tbn0SVSFVWZdrjW5mUy7O6nSRVXtB3yWL0sJWIle6oyUyJNFd5SloP bcC/NoH09FXeW8oeis2rUpS96Px3S0AzR4C2kCq3+MtZtt0HrRNKOMBrOwUE+Jgnux0jErGoZi1Y pMoOjUhEob4tBXXO0Qqvd1WbDmSDFhIoig69fwRQC/o5kIiPwXueQBDvdZHV2BEvQGsPmfJTNHFr Y3v9SiiNrYUyQqMuAUATPlR/Q3cMAReFiXhj9GMEUegFDNVJzTs2KWVHvAS7t6OcI0Vu0Yrijg/I BjaKsSEuAkjrMVFYUoqw8u4ATH3QIftjghljZrkE40B7GFkiHlr0UtuYHXAMNmyXtws2rFhR+Rj0 VWAOux8Slttnu/TzqsP3vjCtzwB8jpHo4feJuAOZYtAB481FZO8R5YCU1gdg1ftgQF4oPSHTuVyC bPxTR2eNybEnYA0IXjiS2s6S4awQbyEcR17N0FE7n3KCMsYTnLd7WAF6GWF0EOQI5vQ5AC4OIPKq wQIARTv7NpKzBboIRB/BYu0C8eUe+RlABdlLMOry0rSoinLpniorAD5i6URA8FwCQPLUTjU+sIx9 Kp8lTY+E9XIIbwhbMCNkQiPqTywofDpzo3SxjbBjPuMzIuNGaN92gjzes4mBYL8A04wYniDa6DsI Eb4ZV2pwSSsaDgFKG+mjSzCdJ9ToqoWe7fhXIAAP4VY6teCV64DVscvjYR6cdXQHQklH3gblPVoo 9UPPzUDi/9ywDk7jgCNHI9kbusbxhBaOewHhGJy5cIL8Y4wz4XSduyt6uM7lHHzMjhc72zsWB4xR rxeB8TaEMjzZxwQFXV7RP1z9bIOF+s+PZ9dRLDd0uI3WF2v0Bay0/dbkSYgRcktbuTE45IYxh5Hi MQ1099FTtF2kzIbEX9WHzZn9bJe4IZnkaGcFeFGAZyV4VoFnn6FJPgcv/u1ObMV09u2la03bSp+6 9VY48n7b8NPaV3pTowK/lenbI/q/m5Za45lZ5jqd351JbmWF9plL8W8r4NgBb5r0041GmazIQiPz X5oWMW2RkwadL3TE8AbtkfQ2rIYXDSF8fTX7diYzVS1kWVQLlS3U4s1/Zj8G3DGkKd3ukmFSqJqs 0rS8vmmo0aJN6OtZsnRbs5SDWd4nsxTb2kuZDmbZsbPk8bb2UsWDWZ6QWQxe8k1n0WqQTPIau9Yf 0djB9RKyrF1CseFGU5kNlnDLNu8EnmtFZFqfz9i6QXzHFMPbOcm9bXBztkHL9wvZ3jWXeam5tyi0 iFKF/t+KgAlX0ZEsKLQgUKXI020IAs7ysOk+m854Zlr2xDKNYMM4FhSXyCywY76AawwUW5vkKR+g kxAo+hhse1jg8WepbQzvz2DoZ6CvhiZ3EMJzlpQ3Ntc5s8LfzfVlsILUyr3TeYcnuVcst+B0btuk umWf88Yn6TJawyRu8CShXrGVyPCGGTowhW4sjDvFw6i5bb3d8fN+qzvXcy/0385J7oX+faRxw8VY idtLiIeeDTgzcv+xkfvBCfGn6HhauHluOtuzgf8YLKxunYJh7K+XprVvBD9SC88A9cOQ6xGCnbXZ X4Kx77Tk37bNg86z/65tnjsDht+nzfP89gT/PenfVdIfb71LpO/S4725/zZNcm/uv8MxHpvot+Hy S7RtdH/De8y9a1pTuXeTAxwzpa0BrG7gKOkdI44AglnWh2pbYmkBsfW74B+CX78C6KW3iUAwzHfl umuFxt6+QtcGxi6LunCAFxWWYFvkegK+I0pS/i9f1QcOumydUsoILVO/oHePv33Bqrlle2C6o+sG t12fPEtkUx9ZVGmu4iYVKBKVZEW5MM8KtVBl0dRHqBODMdiPm/saufyE8N7L+Lk/B9/Y5/OKO2AY V9xQNiMS6lPwMzcMnc5XmAMctvdcUIAJOHwnx+0cXmQP36tpNKdKRSoTN1ZAD2+BfaGVBV+dtIug F15AlGVIEf0qS72TNSPXP1UsyqxoeCipqoypDbDJ/e81LlfsIbq/ZPE9XgOndnHWKqE5JmuHtbQg gV2gafiiDvhmspNPzycwHeAGH88BwsehNsCSOwB2nhS2vRKKXOsvPSjiDkdOqpAGTi3gEmlDBipa /mk1TL/gNZ/5h1SDZkeqBt0+phc8wXaQ7kI2hEWxr8gjQwAb3kulIoO/DMbf5n9he/vrCvsxEFKJ FrDP/1WjIfANq+nVmgPX5e4Uhyv1817VXXB0hSoqL9MgCYOqJ6GqETyZIu2OSsKOnMKCQIdVmIaU 0VWScRdp5oHVdfqoV1ovS2LyjSp4l1oQ5sP1OJs98ijy4ILUZ2QLgHHWKUQaUAtznNFhGatpOrYp WPWrYZzRgnPQ9ppUTzUIKaAmHYXbe+hFYHNgQx/6jnyRcasgzrftg47VTkN8AEt0Q/jSRGogA1Ap iCvGWC3g/nqGOOHYDA2lrufYKHdkE3vmuHqiR+5B2TQ38yCddgbnmWRvIXLkS8BA7kGIQtY8kgbz cFJmDXHKmSiHvsvrWcRlcwfUI4YU9a6AgOU/xXLCg2K6mYlMRlyvFjBL+G1/1hnCyX+eOh65aoPG UiZ9LwER+/ZqH7gvepS67XyMONWjFaDJ2po1/Qq+PbMGEGJAeGJYw9cXnuDOXaOPhlBngootRMgI LFPqswx38MhD8FQGgEAyVzkFf68GyXwKWp6r1or1IVbz20638aEpn28P6NUVwCM2AwTViNMB7DNe xvK6F9UmP0SCHClJd+J8pObZ1oihm4aiHLAFrpKGVsbv5i7c5UBuMVFpSMTRIL1XsSB1zGc70Ocy UDAKf4vL3Ss1tJHTjiI9PFf7quYPiatfzKmGSOt9Q2OXP+MIK2bxsapdAp3QmBdfbXMkzIGIkOUe So9A8pAhkRCaUJweAMAnFYdCo3a/H0ad942EBk2fmWlo/myCEeaJDqFjq5bR+Ct1CJQ0FWeWjlN6 Q25eL6MHGDL0IqDPY7J9kUAO95ieu5zWpfdH73/Ksr6Rbm7VT80SyyITeTklSxx+OAAdIcGVwgGW fElEFyOITXEAB3AkKjfMV7D2Oi1I8E3wWoDQtab6MWiFey0j9faB4MSfxABaxxMmDfU+qVNpZtm0 QviQ0VCtbFV/MLxqPqagWcL5eqWv8L77Xuj5Gn8mBAguT0FylFNEHOMp1s8H3SzhoWTn12Dig1Az 3C4BRgj5j5vx4A7/gCTgBiwkAKNOkBIAadM9+2KLQoIP/3H8wqcbkTBAtIZtI6wtEH3CyKs7DZ8v vW2XCB+PM7PwlZiRkIZ19qd701ikItsHMgyWICyGQj/ChOKrNAoAdNRN8Gd4PmWcb7al1p2DseNG o6pE3jMaJ32p6cNtfKnpgR45LpKypB8/0sSRiiSJ9SS7USUKlciCfFDpj1EptGtLv+2kTcZMyDKO E9r5uf69itM4JW+eR4kosiL3f6FJo7USmYzLgqyCrJLMSb4cZb/m9CLSaM4K6flsE1ePfjtiiiVJ KqWAPAuP3PR1az8ETn0xoMD5r0rZA2q8vLrgd+L5sC33sYb+HbTgOAHSViMJR+6TTfSCKBDn/Ecd /B/DclVPYL4Lntq/iLpIBX/EZdoBG7fsOrL8+bLVdgvotivipo2Uy8QPHdf8gqMY4BaEnSVUbPhY FgTBUPxkDRuDj5p8AAYcB1KLAO7yG7x1wOfTEb7DP5uO3Hvvd9NdpvPyQFNG7NvZ/wB3C7QgZW5k c3RyZWFtCmVuZG9iagoyOCAwIG9iago0MTE5CmVuZG9iagozNCAwIG9iago8PC9MZW5ndGggMzUg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztnduLHMcVh1lp9ja7aDWrxchRBCPs 4BnjbfV9eiDEYJI4BL9E7JvkJ4cYAjJY+f8h3dszXdXdX59TfZmVTIJeSrNdXVWnzvV3TlX/uvS9 MF76xb9946f389dvNsuf/zO//3n55vtd48PP81/nsRekabq5/8Fu//R++d1d3jFbBoHnx8u7f82D +z8Ey024TEIvSZd37+dvV0frW99L/G0SBKtH69vEC6JNslk9Xm+8KH/bdjVbB17mx0lo//l47Xub OPKjzepknXnZJtpmq9N15KVJEG9XZ/lvaRZuw9X5+jbIl7JJgtW7X9aJl/pxGq4uqidN78v8lZmf bsLUfvLdh/Xt1kujLExWT/J3edskCqLarK/Wt5kXxVHe0cz16Tr1sijZxqtF1TrL+wdBmnhh3vzx 7u/35Nl6QVhQJ04jLy4ofvfP+erZ+u7fdeLFBcHKP54Vf7yN02x5G9z3qX58/SaIl/ly/azo4i/T TeSFxZ/f5nPP6en7201OkX1rUbVmVetp1bqsWqdV65uqdQQ9TqpWTsD2axb58tOcaFlqPXkKrXN6 zwUMfVy1ru0u1TBHMLUrmNkRvIf+OrOeqwYx638MXawVmDk8Mb1n0OeVSG+i0zP47dL6rWC2yE+9 7Y6H3nZRtprXJayK5vqian1etX4Pz31GpCMGRNbJpbD9ykug7NE69XPdEm2LFd/ulpxLnZfs5OAM 1mVoJu/l9Yj1P7OWWq3fWpbVNMNciKQvRTqMQ5t6HyzyVOOgQBGrFw+G21wLsiwTKSxeNjoGNxYX a7FcSaIos99OAvBKpMp1gz5F66XVoy0KCyQEbdIM3v0c5vDIUXhsXWX00jNxpQt4j9msY6QXMEKH bCnSg7QgTXlmUbL9HIkeshlrIdDvr8TxDEUNd9xU0sOzrgYhC9UUwj1BStm5BCItYDI2k/0CfXrS oZAcWukXQBvzHPEdmq8rEB1mVdDvrrzqbk6qQa6Bxi7mJMydt/RjmhNXE3sDe2rrLJBuM7DZ3lPx NUeVOPAWgMw9IXJ/gOX1MD/gIar2x7Rkx6LD/rRpdi2PbbN6WySOaJQZSrpZOBmRP8J8ZIZ6YUZx d0Zk8rAvYjGDIh9yiGEY4wZ+U4RYNja21gbeJT35B1EKyfkzg5xQPHAND/4OXoPyQdJ1Q3GD0qdG O0cpdjdgimC3xePcIpnVWQzZyFCQ4qUFoL0ku6RpY4XRNSXdJtlQHV1KuqOOfgFrcdPRhSkYp6PN 1AoeK12jPiECLKeHjm5ISuEcuQcJbjtYU/BtVn8C87ok6pFaOhEJJbPtNVobkqxOt7N0jjRvTJGJ z4Dezj6abRItTijGyocIs+XdD/P8/1/NdwP+ML/7+u3qa1Fp4MJldIvUvrXvHVAVBA8y0ENRi3HJ kOWOlBB1srAM5NDVdUU3nTqbLl/Ju2XDie0HT0WHzCY3AF3dUWJ9hsdAppk1BaNaelOuRxAMbDBS XMd6he2ZD7M+Ist0+A/tsevWp9laoCd1iAgBeADFtcPHlY2trLs4oq2voW4X85lJLtsQHTcEIJZ3 iQhFbrXpQqa9tnEDonxyEtyhm/ZzGlNY2sQ5P9KRfChaddj4yJokiB9KQx1CKt27U1g2BXmntLFk dCkdZSnvlxUPT896ZjfE7EkNVaomRgG97JsQIsfkrAa5gQf7uxm4uUqSpvTDBiDEJKdTp5peKLp9 EDDVliP2jDSzAzKuWh2SSM3smL/KXqICrbiYkNZ82vJixvvWYnNQaC/h3cTcyrRrsHUjwUSUKjRI F1hdhkIaWF0N8lDxkbWbpGwUN7oWwkACT843HcPL6Tnzli+Iic1+yJqMlAabZEVptclt42APpTUk QTkArt0RPBLDAYY5g/eQO0VgB0eb1SBait09F6k4ROOD8Ab1ZrScCZKf9Wyk3UV0l0iPDAqyISjm KJtUAmhzjorbnf9atf7k3GrLDj33bm3m9b2oMI0yv4L5axbRuW5GYer+xT2jgmQa5AZjTrkIgqTp m0OwdBlmfCSWrscZxNKu7i2XmUkQck3fw6KmM0qmM/gFY13Z9szYjWZXdkh1iuIpHgBWkRGfnraq Lj+qxynJz6KSnyHQ+5eiYmN/q+Hz1bGmQ5QPtCWog8nBG52KyWv+FvCCnBKv+1tl7KH5W87oleyO EIebvsTrPYCF/rmKIU5BNUrNA4Cm8QWGIBKUXmsCbM0+Zqtdw3mLUhQfyd6qvQQpHseUqfxq1zwJ Lg+TIgdIx7qXqLjCT9NrCtuQiKkiWQqbuFhhMqasmSttBq5gBtR5Kkd4mvoDn8uwgjPy7Y4ptoWD 0UURJJkOJ5Az99PxoKyEelgX91SwRIKRmWDxYMmQzG2775msHl3PCxy4dsA12ziVwR0ThauWov8U wf53zKf9oz2xJrMX5SZd5YxopuUDVTKURtHH82YNzKoofSkqXob45X21ZA1O37dsNB1i+aG134X1 UjRwL9y8WZI/yGfHFISmWcsxCwNGgf+gUg/ckAcoy3fWIe5nTcjvfrHehzwftYClIyPqJlM2A42q YNZCNPCynOsKaA5soEVfTrXQwHKyhR6QqjZKdyHG/zfWFGBezggZJSYZMAKXEaMVgibPgSR0dHVG o3Sn5yn5hqsc41Trcgjep7Mgthi6sBha9ZSM2bkujPbRQomPobMaX4lF2+PqVnA8KGbpoDIcTex/ oImR7v5aTPNAJMpjFZ1t5qY69fgpxDhOGrSOKmPsThpbAzRk1Wgz+LiDSgQmDtAkSmbcLlppS80V rlqEccaonh1TFN6kU0VLUwLsOXRXtDCEZrO6IioD7PcBjgqLqcU++HspKYy/D1LcZTTSx1GthlHY mnLa71akNbRKnTZfuxfqSOX3NhzyfzRN8894KLOLdIqSyCGn6w/h9NcJWAgQWyzwm3RYrhQgd+3h eASDNhsP2A9QcD0AODc4TcG5OOOFya/pUvPiYtUiUzwU5ww890uPtJVytyi4e++KaXPB5upOGVex 9DFozVy/jDoy8OWeHGto9EJWxmXHNMmWTI3NG+KBy0+hdO7Veu+STZhFV4SnP9bPqoThc1QlthZv rceVz05gsbJsDRhkkF/gqgmczdSw7FGb0TgZJ5UeKxMbeUKTBMCx8qCT63NVFwio15DMlqMsyEWl XxIlD5qdGRkalq1Bhx0klYpF5u43vSmB+oVI0Gvg9aZ7XJ7/cLR/I3M4tP4+mFbz3iLetskshbPD e8ijXcDVw1M8dT9LS/25OLTNoEQtKh0FEzUUSeME7ziglJhKcrQm0wodlAWpB0BE8WzrUlrKz8A6 /X0hwAHIDIpdE92KFAOi0ltUlfuWDfSPrGFtboxW9jJEe4yDk3tpj/KNbZkYedgJ5tDDwwPiHSAX 4ZzNHWZLnBn/ddXqLov5nJaAWp8UDkktMQ8lBBFIU/w21+JhKr1FazJGQA8hYhNlbI5hgScwNgko H7AXj9K4HrCntOg5DaJEkVgF7soldfelT7mmnKM9bHG2RA82R+2/klo5lWPKIed62r9d0CAOLkhL pg6R+8CxpWrnkSeOtfiXOEbUj67mn/bNPh8JBbXC/RWflmP3m6koqHfRgiotYjfDOFaWThanixe6 /raAFnH3pZLVbpEb5tjJB4YUQy/nrZ2z/kPu6Wd9N6Z2TbupFrZETrfRdC3BpokZNe96db0Cvz0T D5gtLCqBtVRKDgfpUTFpOaoupeNWYT2bT5t8AkP1lwBr7lewXC5H/hb6OKdrH/qrK7UVglwgF/AK ZexZSVxR/ITumr1hjvbkhGIEtc5HZcH8D+VngXzzJaEwLr7stLsv9WideFGYpXFhbDZesE2zeLVc J9vQC7Ok/EZREFrfcEq8/WeIlu1XB8XnhnbLfJS/2d9EWVZo5iwfJPSDYgdiL4r8fJDj9dbbhFFQ rD30sjBKYqvP83Xsbf3YjwsibT0/DJNtrq+LTxvF2yBL7J/x2cX9t6Iy348KhbD1ksDPdmwaepsg TfJhd8uzPpl0G2Ze8VmlcL8G2RxOrF246k2uYep3/K7rUueheb4S+J4oz6edK646u1vRNm3Mq2XA g7JGHK1CeCGHZvLAN/IgA2rMSW+paR8yOvL1YM423R3EEY9CYqmcYj/OYWK26TqHSdKN7Wgf+DwU CDLXQLVJYbtYEKuNXnb7z/aq2/yv1YiZA2+uqpE80AB7gH66AZLhop3xkXqwOtG1Gj3qlnUF3tQu D1yp2SfOK20DXQxhbRJeWi/rcg6Iqs43FRMq0BXpMPeb7drS0XGf94i81gFOXZKLa4oKetgHynxQ jo9sBlGUis3Vg2m9K7u6UYB6UcCDfa3QMBRIMlmeUWdBpyt4F28JVyrjJ0sjmBdWo3SD0PVz2I0d bNbUENivpsD+B6/XL6SGWUlObXSCxsJdM12FONO4VVcVk7jfYd5f00gxxWQ6x70QS3SqaOh69FFK jRp9IC474LthrvGVduExKVhyU5xvfHHy8ApRUQoCD+hdnTQ5vU5Q2SJbWOfu5YWcyBfCuR5UOIbZ UBaGrlHpOPvea1uaIoH0BA4m6ec57uWEpvgp3iDeABWrzyutdh9bKj+9VICHrvCYmRHxnmtKl7lM RJ0VjLjp99e/iYHnFGSkug5OlCLa4/PgIgTckVyFOZownIiHTIFJBK06XQqBMEYl9NP5K0jskini 09adY30vSmHZuzDqe5iudVkckkrG4zEtwVUDkqW7qCQGdxDvKNa9jFJkemCc1SgMcu5bCnjytJKY A3yRzLywLTBs8V2r0M3Ioy4xHfnZsMOe4BZ1wp+r1t/Mcr6rfnwEXVzC0IKrx30Uvr4LJVe73/4w yi1vhA5dQJjmjRAjkDS1eVqTVBn9lSvGVMvgzNRsGUpPTbcMQ0IapYriYSyDqPuJKt0fo6p/mNL5 217SGT6/TwH7uJOJjXxKPfAfkNklDWzrmracMPgl1iMj7dC3cS/5oqyr7H9eVoKiHbf/mCENW4l9 SzYSeKHlEZCn53VuhcgYjrqizdZR8mZYYVqcs+1fdGVHX53piy48dRiUtH9OqiTTQaU2IahqbPJj Rd0fW6gnVbpYFtFrx9qev9zN/5H/+y8CQED0ZW5kc3RyZWFtCmVuZG9iagozNSAwIG9iagozODEz CmVuZG9iagozOSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJztXetvHLcRh2y9ThL0stLIsZ2emgbZC3L0kvvuwwUM1AYCf6mhb3Y/JWiAAi4Q9f8H SmrvyNnd3w65e3eqrBYGDOJ2yRnOiz8Oh6tfp7FQ6TQ2/5aNnz4dvHxfTH/598Htz9P3bxeNm18O fj1IhczzvLj9gbZ/+jR9fa07llMpRZxOr/9xIG8fyGmhppkSWT69/nTwIdqazWORxVUmZfRoNs+E TIqsiB7PCpHo0apoeyZFGaeZoo93ZrEo0iROimh3VoqySKoy2pslIs9kWkX7+re8VJWKJrO51FMp Mhl9/NcsE3mc5io6tG+63kd6yDLOC5XTNz/ezOaVyJNSZdGxHktUWSKTBtcns3kpkjTRHR2vp7Nc lElWpdGZbe3r/lLmmVC6+ffrH2/FUwmpjHTSPBGpkfj1zwfRxez6n03hpUZg9cN983Ce5uV0Lm/7 2B9fvpfpVE83Lk2XeJoXiVDm8YdIGnnGcVVEP9jWlm09sa1z25rYlhbHsnkU+iL88VALINdiK3NC +8K2zmxr27Z2wG/1eypV5DdC5dRR2QZz3QX0jnVLVVr7HSrD5nKO3jwGTDx2ves+SdnTZ8/HBjfD HfLUGFwS56Ja2NEHoszHRMpgWr8BE0SdXY/vADMNM7JUzsCbe2DEq4YclPa8nPCg3bTb5ZzOJY91 zEkqI4X5QgzaG0W28I+xVtjXAyn9GEx1n4rHsrsPBH7Gjn3R6mG8A6vIEjnlzbYp+rZ3oFm5p0fI Bd0EXLiBNk1sEE11B4y4C8beIuwgQ+dcA42869g6AkT2WSJQsIjKCaIS7PpHYEQUnrz+cAhovwid F1olzgDf26AHNSxgRMTRPeJphyrjERMgHup3g7RZu0SolZ3xqxISFH3Pdnb2fQLiJZLJBXiPZ2GP XSzgnBjB+41oqynY9uNveMdz0t4Fc+4PkW2dubk4G7sM95jXYLIo0O0BNs7AU4TTEONbhAZSB1Zc l8P22tX0F0o50JAbkKy7gkBPpuAMeCUZcrfFbstBb9rdDcDinRo7XldQ2O+6HoM9kBVej/lzSsfW z+JsHsTd6qXGV1ssNxPoMW7Ir8J9x7dAD9Y/dQpgcMhcr9x0+DjJr7En1nkIPRjJh0DO2nnQey0v Wz4GBgBXSYxOW0C0tTkZjk4x0AlzHt+eC+3nVkRlPO5AUzhrKKH2Hqp0j/2jTR5aOxCwQoss3HRB +6cmZaf9FzDDCezS51DG/t1vdHoAyKD5tfRf23/4ZhcAhuDIctLm0Zj/FeiN7A2zw8fgrvW3ojEz KxSCEK8Dcj2AiifZg7a9l9RXsd3rB3XSKnZ5LqX/f3dw/b1JDGYiUWWeRk9n80LIKi9TPbWsUkKV WZ0+k4qkFzOxzJBNu+NKkwlbSPeRHjkukrI0oK/URFQsjfmnIkliTWRnVolCJdJIV4lSJVka/XZW Cm3VpbbBVEhZZpmJE5mQZRwntPOlfl7FaZySN5/MElFkhZ5K6IDPZyaLl1b6d2MCMhYyzpLbjIYo tCi0HkxaU0pKEM+GdK9JVWWxJCVv86cLWZLU4VyVwqQXlUkCt9DtD8g2Ech0hqZAOJ4Am0HmekpM HcHbHTCiixMoQvtCJ6Li+Jnb1gsb6SY2Qp2DHs9s63vbeo5WsteA7SsgxF2EIYKXgZeBMYHuP7oR CscYy5ebAERBCCPwMY0aiaWCdA/DUngqaO0LNVoaPEkT70oFxOyYGLZSGfNFKxVBw2hWEEscWTdw M+B3rCRDy6MKaEVH/B4P8f0YPB2gja4f4CQ5Cz8GZMm7+qNJchBCkEdsky7UnWqUegn4ilGoQSH+ 63DP2cAZAi+d7oDkYMiT8T4H43R2AE2MS90OKMZxi5YkgnH5IEnhJQiDaMMORTZpO55xHWQoKAvl cR205ZoA1zkF7/mOJ/CWmlMbMgQSOPhYewXm7AmCUENrS4Bs1Issu0NO4trDPLG+4Tik2Vg24Pft TWrXgNZ2gmZF03/8IcMcUCSRdc86h+vyChmAQ1UooD7yqLfrHD2ZLjZ7iAyBX39955C9yzw3mdrU 8z5T70nXohgFNDsi74HiA5Gk4wem125Qsx0LW+m+8FzSRR/rC4u/AZN0/kfzlCwY4HNkXW8xBn/E Sjr4HHKEwVNUaxlbTwIGxy7e3v2IskZSXkTpWXR6lghV3hsAtYM2BX3wst/5FjwYp8Hn+2AhQqpu K6GvQqGnQIk9Z0dQAh5NT6zDwCCGqoicEZ6AHj3RjNt6OGafINmt6KtgmF0UPl2fKY6ZHgzkZvEC zIw/QMUxsTsHl4t5alvPyXt2WsjbPMcvHWBoDByjgUD4OeK4iwYrcJ6FjBklpc9471hp7e0pjesa OMT9dLFCGT8P8XAoDRbUoICalLWl1IuCD0qzWRavyyC8jEofetInnDoHFBoBSW0DxvB+rynRvnRU 8I7tuDGVek1wA/J1fAREQbf2hRGQjVopjKD8bANFAhR1AwgeekAotBO3NPF6gy7D7zr6Fpx20QHK CB8hItS1PB7TAzOdQ3IGshrKRBEs2EVRLDu1LoMAHCUzaB/XrmvbVKBsrTO71mkw9OyKlEeePds1 ducBM9P86slbgg9bWSI+YIIjQe0xeI86xP89TuOpoXGDosIBHknzpz7QzEIPtWmlUvM94zLI+2Fx jr+AuXYYtJziZC4gErql22mHv1ZpDrJLtMm4bLMjZbbAYAu9vzPH8991TueF54D+d5s5oL/z4/lv zLWfRFZl9Ht7V4icrz8zB/EyL/JEK3F5Eu/G0RqpND8qKzUgVyLN1e3gtUwUmfXioF3LtVDLXZ3W RqkZ01JIRJbneown4DctfWW4WYxJ5KykKNOmoClJaa5pLSV9oceTqZnmF0aH2jUqc+NKv5JURalD v5ZhJrWZfKlVImWeGAlmokiMA9kbUHtWbI5799tT1/xqJrWotN1pAZqiBJVnhIb7TZu5ErmUKiU/ Tpz4TXlEobRyC0Jn37LoJkD6uBd1EFteyTp0zwnNPVQSkeSNggjPEgczd2jr5k9sdFcNBwDQgRZ/ RoL20XsgVjSyGSBpjyIWf3blyY99jPiNHTo3g0tpAQZfpfJ3B8zZk5DxXOeAMkEra3i5AVgdhxdZ DLgfMmzBbeoPXdEZDqNgah3pL2SVbSXwO8ujofIUjN2boenPRkL/pIcux0CMnt34szaXBhb44WOH oR74CPtw9k9PHkDsQPbvOVb13Ufii7YCzpyYHD68++BNfAVnO49Ba8xRFDqn4Pcu4cekR4BKO4IY HxpzvtKbGWxvRD/OQG9KkQ21HpFetEVhXOgUCIC/ysRXTryxrVfAf16Rp65l2XqFBIH6vB0i5E6Y e8OO3deq3QeySJpvB9xLeEAVE8OTF3RhZOt8QsXgc2BQlj9khRiRYAxOfrYxS12Nwd1Q3EfSCz8E 4kynJ3kLIk8PnOiS3rLu4wNV7CVQiqo8vjMGbHWnjczMd9HH9R1+5t6/ljVXHs9lqw3mc8KTWUAO 7tAAXz7nXCT4oPCShW20TAkAHaipQV8RYBQEI4Pnppb7EoS3hhdmDz0VFx7EEHr/2oPd6QUH0IUG l23QiQcmbXxtPAUBE4oE0Y3Sfb8imMd6aw+CWPjWftkqVqlyGlXm0PUWfPxu+XL1hMKN6AAQunwx oCBu+HX7/+7mBO6jUZq5zid3ZXPXLWBfw1vOBhRsWSL48TpaXzoi7stPXwQPszEOX7bN4EEpPhlO BEFD1ELv4b6BM0nhgIPFkI3g/05NIHw7u8pG26d5MPlVNL9BGxjBIbKGcLEPzoP05RP6FrPPMryE G9Rg5x2X4OHUgDzCY1vDI+CYmFPbVrE8WY5uL5zP618+UxMZYxiBRIZrYpPRZz0c+mylG30CPlxw zwzG4U2cdUWbDtgnh114OsVwMoIng2YLxynJOKA37FMNZ/cPsEvXcGDnPzrOOtj33hvWusLwHfj5 SpEIz2TNHOJwd+8i0Rh0wGMChA5429mgxfjeW2kDtDGLwUpZ4QQRbnEeLprmXX3t5rbSntOz+6Q+ dAcRqhODFvnxd59v5sat0zkSNcIFkAoaByOoO7BrCNMcNzxK4+dE4VpfEvezNYa1h/lVHHD9tuAD Hd1Wcj8ztG/4UMm3BsCStejWF/8Dp9IT/wcrNwlmDLXCUIbm1fL1v4AjRhAZg3nvU7Sgmaf7Exju WotorXSrqxdHbGwqc1QAj+HIA1Ve83tcKxNRVZX5nHYlIomv8//1NIaIT2Mr5dk9nR+oxkwLQ4dV kEx4Xoidig/dDMaNfaXLweJ+wFZwx0RoNRVKMnY2pNGymKhRcrZsjak4W7a+Bk//ZFuuShd+iyf0 T7DAj9fypdukCP1bMOIhmCj6VggqhKclyiC7EP53mJzq1qMVD8r6M1vk2rjiiKpc+XLNMfcJwDWB cZ95bWymKnPN155qW8uPwSD8N4MQkOUTWehPVzhqL5BYPVWOW70vtq7mrV4OyXxMEtc9ghts4bey yIck6jFNhTe6OXTGMg7Lo+FdDXQztedyHbhZ4vlS4PAPUpF9SXBFbLOOvv1ZmCvAA/w+0Ir3IILv Jq52nwRdnWE+Ktbnur5cryXjvQnGjY2P7petfaQFdIEDf7zXdg794gpf0u014LDibvy5noEfc29+ XhkF0uCPhvddMmn/SUzvRyb/en3wN/3vP93IA1BlbmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjM1 MDAKZW5kb2JqCjQ0IDAgb2JqCjw8L0xlbmd0aCA0NSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+ CnN0cmVhbQp4nO1d64/cthHH+Z67d7jbe6Q+O3W6QVtYSrM6UW/1CQRIAxT5UmO/2f2UIAEKuEDS /x8ouVqRI+mnISXtXepN4C9jrcgZzoszw6Huh2UYRMkyVP9q4Jv384c3+fL7/843j5dvvtoCP34/ /2GeBCLLsnzzgMLfvF9+sZYDi6UQQZgs19/NxeYHscyjZRoFabZcv5+/9Q78VRikYZkK4T3zV2kg 4jzNvUM/D2I5W+kd+SIowiSN6M/HfhjkSRzGuXfiF0GRx2XhnfpxkKUiKb0z+SwrojLyZv5KyKXk qfDe/cdPgyxMssg712+a0RdyyiLM8iijb7770V+VQRYXUepdyrmCMo1F3KD6yl8VQZzEcqChdeFn QRGnZeJda+hMjhciS4NIgv9a/2PDnjIQkeJOksVBoji+/nbufeSv/91kXqIYVv14pn5cJVmxXInN GP3w4Y1IlnK5YaGGhMssj4NI/fxWUiH5GYal4lcXutDQSw0daGimIcmYGlxo6FRDVxq6xINXIpNc KzIpgC4aMvkJmOioNSRKIm+ln+VmGt+geWDXddPAEpVS+t4rgO8a8GlmkEgV6aOxOeaQvKdHVy/G BV4qmfsCs7S7GPTiyUbf4jALyq0avaWDKU80ZZdACNc8jQQ8ILhr6Jj8atg3TOwKWm3ElYrMC6jY a/ABobkAWA78LJSeKC4Vc1Zb7kgbDdKt1dwA5GSNUBBGtU/ZRXysoRca+jV471dmDTe8HAwNF71i UFZDXjQkfm7Q3IPRz6AW11YDuWOove1X/GqFnBIfEmr04Nfaak749SO/dwrWB434AlhNjxmynm2G 0PAe4goP0WhuAc+gOl40XqysBr5oln1JhWSxkGOW07eI0+PsvYJ67B0oFbb37ox5e0ZlIQ9gyIXB ws+YNWesLATNeIN4cjl8MVR/9OAjbSHmRdcgAK3quYaEhj4C9mEWSt2IJusFi26SbuQGixEBliT2 ZV3Pi/ySRkIdk8VKXoNlTXJXnwKjRwylbkITfjfcRZGHd9pKTiERQH3J6D79razkEHIcWQ6Pxbox s2bSsxeMl8IMRV89bG5R1qsprs7hCLB0gZW4huyRSbWNIPuggQkK8egCLEaDPKrx1gMcqpuzDsDU 90jPvtCQ2aSNJkDl+Zu2mSvwKw0fDH9oaFZDL1tSUDZzxiohjJ6gE0L4GItTJrOrUBjbUddmekwU MM+SvI7ZC0AUjtlcQ02nX5mM1elrLNTrO8dgM7AGM5GxBJQNu3KiJ00FQhiVp9aGstPstLIU6HJ7 YktQQnDeLDtUKltxLyywngR5M2QqaCuYvGtyakE3DY0G57P8rsGaClVc5+2DpAoFcPKT9g8y9x/h 3JoXxskh/+oc+W7lpUyE0gNCX/teuTUL971SY0GbJcozsIu4a/2u7MPUE5EtIOtBGxbNObpGgZMP 4Ll4DzgmjdJIcB7V5WZ7q1cmgQiEARelusdMoqLiySVYggkpiG6Yh8hukeYgPl0BPs1gpIgKKXeA hjZTNpsHcssLtIU7BAWVlfQUZGroUyQGnIex7vaiTaSyDWu9pkuPe1TIFoYNkt/yYZaZ0cj6jmcZ 1mYQpBrWn8MVNJhTWYrVh7pXuKCvh9VmFFU570L8AQVNESZtSPfaRraOT2xVYLvir+fy/6/n68+k GnhAptcAuavfXID5iK5BtVvwgeUr8My8195o1bKpRhs+g7qq0d6+wKdyDOcsWTjLc05PzOTXyDEY GpE9mO1uTLzf9QvY+7KlhOHlYafjsr4JpxUzYcxv8Q588eUxat2IZUAG/Obb70iVjTjLwGF9TqlX w2k5nt7iGk5rsDISq2ftEs4fFNDqMlekwLWwdiW17e+6GuweBrNmcgQQW85ze2qQaDEDLIXfJXji jsGza3YElSrYQ0dHvcpQkMbcuVaKmseslZ18BhbqdNDTfJFPMjp8UFaCVHAGmAj1xFaM7loJDoj5 irEldDZE/AF4vEYnBbCTYUf9VZRpq41YLOIRUy+XRKmlCjdo2Tx/2ubWSr2uCHvY5AF3iNQ2YfFR dHvTWMyYBRh9QAgDynerjQIFlS4FzJb8CLV0M+KaCywbr7t8uzqEE0JXk8C5YbdCgVNDeAY5YuMY G920luAelBnPxOdXTsFG39ZxbtBYc4munfAFRue9w9aNA86Bdn68TU80ulaCzzaAAv9dQ3+dABGJ f2WwIEEjGzttQJWV4LIR8Mm2mMliOVAarj2K/Am85QgE9h049Cd1Jm/T3TQd2GJiDh1sMVRtOa4s uUaWw5+R0Z29Hd0o03m8rV3KhUtOYAo/vKbDR5rUSAaX2ZsL7a+AHyAW26qeYxo/+7a+fivhq6KP XQqlmJt2A52Ne6ETeTxEo8U9Y+dXQ7RaiPICGJyjJdqSQiQEbtOh0SPwBzCORsrhnuiCsLZ/Ucqr dPyiSJJtwNnVdvnD5u5AFJrrBlGirn+sv94UgqW1BGkhROE98+MgzbK0kA7ePEuCME021KVRHhRx VN1tiCIynwiK+nLDsotOqKsjpswYB5nU2E1JLg/yUkRqlfKVuMwL1YmRBmEspEI/lw+zSHnwez8N 8li112yvZcRSOFFQRHFa3cCoaDXPXhjwlb+Kg1AkmVABWBHEURSKCk0qJAs/UXc9tpdNrvwokpyR i12o3wuRlRGZVUq8vuxx45dBkYs8Jz8fbi6jhInIyHqO/VUUZEJEyeYyShonsfB+o26dJFmRCDL8 pS+CSEixmmWqN4WkKA9zPAbObpDPzILNmDPJTCGyOLG9SJZLOEdQIto/9iUPRJSlhMXm2bEv1I2Y vJRjKzWiV1pWsVLcrY/ua0lv25l7e3kNDYhngY9GAe0toHABaIB1SXzXBBXPkUsxhKHDEuowcVmv S5pT+txEw2f9ozqzOBdNd+VdN1SeAbrI6pFUUWJjOYLGJ+ZkE2368spAmjH/AkBmMqMglvNsdGKP dml8WAmTbTTROUCIQmKMxszIB+ausSch+wppNgpd0NEoCV1QMvIIFcCuWeBaiWu/3tg2jK1mOaYW fLJpy6v7zKJUQUeLB7CGiEJW3Hfu5jewcoEwjj+6hOnt9ri+snhyXG/ZtEaEyyMqgcRFodTAzP17 NKMhsXIrzfP6RhMp4CUqwjb9S5XtDyitOTbvOV/xHNcB0UWDGyC4evLnaFWE4ShThZ7IuXXhnYey ceTmkXGaecwxOLqX+CXa3/GElpQ/BBxwParnbxEMaAMDXtlSFmNO4ZT5DGgUrKG+6x/tq57Trn/0 nIkgXpxo+3E+hoS1jBLIhj+PmdahMK2d+E98DzoKQ5sWUFXMLNENCVCwslvaR50Z7Vw6Nlw7RS86 N7a7369uYlZW03O9esIhprt3AfU4vqf7vhMbNFr5dIBwAIh+agjIaThkGBNBSCPBP+8Cem6QoLq3 bZpHo/ChrQt7Jfh4OBLbEO69ZMpK0OB0OBvSEe/tnwq4SpEgmSL4R1QBMthVtGOUYV9UwF3wZoQj EtepH1MFhot2jDJUca2MRLYHMJvznlX1hGZAH5CGjNELRyTDp34aDXlMXelmPh0XglLm/yuFGXN8 Dcfgj4fwePi7lnAIrhSwgrdeJgKjRyRoA263OqbMjVz2Q1Os3bjhEXaOhwz3WJOCzknh7nCGcC1L 8Z6pzjROTVCdEeH0cDY4Jzs8rYg1rqqzvwozhj+DFWZ4JDQxz3dMjVz9YmpZnS0urmucH6SG9H6P rgLRvg+xoHn4z6s9jYoM/zoUvyYaju1L9jzGh+zEaT+NCgynobMh7L1oqZD3ULQ/Z4HufL/86QRK I42frxTNQ+bztAp84l2X3H7Dl+D3XnjNr21NRhKVZTqk/j+pbA4H/yInNzk1O15sEptUvLYM/kVi YyRmk92kkwBnCvdUdj8BEvp1HNNf1vMpeMV2D3zNajfdiJ+AX/+sIfpxqRq6NcTZPy5VQT1NtjWE e2w1FtRkew4WakjkPyglyDON5C/gRVu3k2OdgW+mhLdmUEdZzlaVd/jh0o7MGu2Oti51b1N/2iis 7u5Wmvs7sGJbr2uXUvMMNaEadZ2B9+AVCDPhwEstzc9gwy9x9vXStYeYK9yIDZYvOfDVIqePnbU+ gn0AuAh/Rp1/6CvOkovcNSf4aaPjFrubStLHRUcXBDogXfv8X/rdzx/0OGWNxeaVYXOquQtVsJI5 BVDP94I4l4muHuG/2TL84ju6FNJxNNUX20CvPeqkPWispf35A+uVGIDFcleIXnECd0M6d5yUSe3q UwiOf3XB8pddplwMsH1TfNu7K0TK7wpfruf/lP/+BxidZV5lbmRzdHJlYW0KZW5kb2JqCjQ1IDAg b2JqCjMyMTkKZW5kb2JqCjQ5IDAgb2JqCjw8L0xlbmd0aCA1MCAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1c2W/bNhhHm8ZJnCD3ml7b3BVDpWJmRFLnrocBa7BhLwv81uypwwoM aIFm/z8w0bJJyvqJIiU5hxPkIR8kk9998BPJz6OAsHAUiL858P7j8PQ8GX34bzh9PDo/mwGXH4af hyGhcRwn0wc6/P7j6JdJPjAdUUqCcDT5Z0inL+goYaOIkSgeTT4O33kP/HFAoiCLKPUe+uOIUJ5E ibfmJ4Tns2XeI5+SNAgjpr9e9wOShDzgiTfwU5ImPEu9DZ+TOKJh5m3mz+KUZczb8sc0ZyWJqHfx yY9IHIQx87blL9XonXzKNIgTFuu/vLj0xxmJecoibzefi2QRp7xE9Z4/TgkPeT5Q0brvxyTlURZ6 BxLazMdTGkeE5eBfk9+n4skIZUI6YcxJKCQ++XvoPfYn/5aFFwqBFS83xctxGKejMZ2OkQ9Pz2k4 ytkNUjEkGMUJJ0y8FmLO5RkEWXKN0JjGuczSuNM0YwkxCEkk+HUf0IlCQuXDL6ynWRqFp7qEhX3l 1hPl+v9jOHmzQhbA3ZE8sZwa/Q6PteQEDY7cxdCG/gVbWK4JvJXQzw2QJEs9vPCNY86sNQ+Y76L5 JdqANjhqIUQTpElTA8+mRsCDJE8IRRp5ME0jxZPxLFLc2kxhbxlKK53Ud7U2ogcPd0Ztf7eCFtLG LiyR2Mr1qi2kfwoVVFhITLJZLfqu7Ebi9Xj2/sYajCogcaQ8BcPhmBgOMeNJ3NEQMxrELZwn1eYB o+GYzJ3c7+GQquHAwT8oyirF7I03LPMPbQP3Nfr58iJR6CyQniMRS5djMG1KNkmmdd3bRlS9WAz6 3VvESqsyFYxWPCOTQcZjr4Gqydjr52zFopFthOrdtuxjVadegXM0MgsE9wWudIW9RBNQqViVNA0F EcSC5sFF0tXaAKLLXIiZedIrslWxgTZBoucF9DJNwNblFcRvpmrfdsy5ptd6wdGLbptysyUrkOwz d+Vya8IQZFc+6GXNXSgaWiDpVvhff7TQe0o3JzBctRZRilRJtbF8WBorYzVYkYOrkBVVHgtZn0hY lkVNTtsJCW8afK8nOz2lgcuXgk4d9IbBK6oxAeHSoUslY9/xMbLSVN041411HxKtxb3CVnDFSFSK JbA9VVmH5v9eDzOShvPdHxee/PGWhLYltCehAwk9AoSojwhfgbc/SuiVhA4ldKSIPJYPN4zoLj6B 1zsS2pTQQKNfYvkWzLgNGFUkKrrWwFiqPZNIfgI/VHRtAarXkJ08BtTsGKl5DZjX5LWjMVpduqgh G4ipp0AiSGeKPaWe3fpVT7Ezbf5lWe5OmhqrMFJlP1+CiTXmHhhlpJhTZr1tlOUhEsIReP0KsH4E 0BXPyhl+XZtPOTFiCjEgGF1M8QMwty4aiUXxjNwbed6xGlxwz1Ms7ItLMHrL/PoYoEZWegQm1Lja AdPsSuiZpbUg7veR6AaAmv2aaVgW0bhBP8+Rv73QfhgHjEQ8q+scoJCB1AuDAtQLsvhdo6BeKh6+ M8fvgXFGSI7eewWLOrSwPESodxvmnkNabkVzQ9kquvfU6A0gcOgcyPkPwbN9IMYjo8OUcgLIN1BQ yJpnHJbdfwCE0rT1Ae0lKDd7CqehiMZLjTKJRtdrg6/AFOkeF5AJIKEpFR9rOIAamiJ4HVnlzPJc Qk8VkhdgwiNA61S2RWbRxKxkv43HAGbWgZwGAPeDSvoT1tUxQMwhHB+qrlITKSw/a+FNOZaRQsut yIyU1pUZleuhwlFUlFGh9xkScpN11/jOfM+Ebl1zCBlXyUmBcFEsRCEF2z8QGRL4AECLiIXzKKWe SIgqJGo3P9Jvub4vfEdpYwOMUILXaj9U5DY5/4J9CsdpcBdkTppW0HJjSxNi1XNqshYIywpq8IgG 71bepn9eacj/cPaB9J59wK0uC2BvDvmmaQVooryvRSFaY+irwqqjIMt9KV0GcXK0uEwo4lt1mnKi W1zI9P+hsG7vztxpoC8oBaMK3+wp2jTbwGlaBDVc9JX1UktD6aFEsw3QtC1BFk0VGAK21QbXcehr uFhwnS/C0KPXN6jxhCY3rH+E9+DyRvmoS31TuI/D+qdDVVM5JyG8JwCiNy8UXXZdm4o1heVLpCJl E9BHYYWCJK/XJUB4LuuFxVYArksanAKXK3PIXK2gzKIxXRPCqh5VKT7Ksd42RZlLvl2k1Uo1U05H U7oLn2iqZlBQRJJqqmGQ30JDMkdX6+WPeQd9U30082FKo0pLdm5iRUv29JwF6swxC8UZcHl8NJ8h pTT1HvqcRHEcpXk2qj4b+RFLCWfF+WbGtOmo+B5RHC0aVbFRcXx8ztuxOKCd61nY9jghSUaZEEf+ E54lqcg2EQk4zc3gJH8YM6H7J35EEs68PX92NJvnxstIyngU5gjnpKpnTxX40s8IT3mYqdFUdAEj ktI4Y/l6JyAJo2kgFts0IJTFkThbLjhlAdXfq0lFfg9y7miskb7ujxmJKWXh9Ox5xENOtTF54clJ xpIwFfY0PzmuYdLGa/Rpv52LQc35Tc4c42GaabRr00yFGdFMF/BJPgmlMQ+9r33KCEumjBU61c+Y j7kwIrvMDWMOMvYD4CkwiOGvQ9IB8OehOYS+Dmkkwl6YvmySaA4AWyi0ua8JtDY0ligSwD4SBeok ICpQEYNUtA5myampBim8epJ02beMAM9NIRP0I0uR0pQ0lbJQhoepoH6Pn225YNtpadX5B/kOrTDs zEskYNynAiZnNq9DH7QfoUvqn2KAk8O+RE2zXeVvT2bgLt/FVXMb7V98Y9tFgZ/sGj6m9f+N3CUK VsWjB0GJRu9L1nmJg2fPoRZbD9cA8SW5Gtumtp9PFz1Z+MsLhMTJlQs3gWtX9LVTL3Jbddfl6IZz IQi57WGQRcvos0uPvgVYHFj2ytsTVmoL0/31OQvQah/haXFXju2VCeh3eOO882G8FoeMbPcn10y9 IopvcUFOF3X3rnhdT85isDeBVVG8++0m3BaJ7dS9K976oNBdNoE2irdE4j71Mk3AXbVtjOFWXny0 svfYNN5eY0tkb7fXqCFgHa/fXqMGr9bJT1tXWkIosI1LRiTWZ6HcL6qxp/92p5xu8uhgAi1q2jb0 G03APLiJ/gXFz7bWrURjwV4czhbgXoh0tGVLC0CDMf1Vvd/yhtItvSjmNyPixLyj0Ez1/VUwTkjc r2GBnLRZo7RYXN81heqqXZpCrReiPSn0/raO5lZKtwJseVq8111d3ry/aeUmKO/+ppU7qqf7m1Zu t8aadNepQ25N4Yrq7hqQtLsfpcd7UVSr+Q7ei/J6Ubq/ToZ/5n//A2WgpgxlbmRzdHJlYW0KZW5k b2JqCjUwIDAgb2JqCjI0ODEKZW5kb2JqCjU0IDAgb2JqCjw8L0xlbmd0aCA1NSAwIFIvRmlsdGVy IC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nO2dW2/jxhWAocQXWTYcy94km6YpZCRByGBF8y4xbfMQ oF20yEsWftv0KUUDFFgD2f5/oKQkzgzFj2eGlGxslGBfZoeaOWfOfS7n+JdZGMTpLKz+1Y2f3kzu Xi1mP/9vsuqevXq5abz9efLLJA2iPM8Xqw6z/dOb2Xf35cDlLIqCMJ3d/2cSrT5Es0U8y+Igy2f3 byavvZE/D4MsLLIo8t7z51kQJYts4b3vL4KknK3wjvwoWIZpFpufj/0wWKRJmCy8E38ZLBdJsfRO /STIsygtvHHZly/jIvbO/HlULmWRRd6PD34W5GGax965+qUefVFOuQzzRZybv/zxrT8vgjxZxpl3 Wc4VFFkSJQ2sP/DnyyBJk3KgxvXKz4NlkhWpN1WtcTk+ivIsiMvmv+7/uSJPEURxRZ00T4K0ovj9 vyfex/79f5vESyuCrT+Oq4/zNF/O5tFqjOq8exWls3K54bIaEs7yRRLEq8+j6nM5WVb+9/vJ/dev vS8qAodhsSH1qnWkWlPoG6nWNfTdwNfPVesMflfSLcpLIi5zo1NPeAwTloxp//Bk1YrTuJyx7rsw fqegnMDcIxhSESQuSllAMhBBnmkg1x0TbhbwFkaf6dGb78nS/H4JsI+BtAZ1jmCwSdpK+pIwD4qN UL02iDMl2tFiiBKIgx483uLaGp6C8qUobMbc5qqqtcw3i5lvpL9aEcncM9U6BTxvoM8AeuFIXpNW amlTWLmW13Mgb5dotomvgHwEVKPBeuqvAC1c8pT06BRmvAXJvGhJeNX7B5IfD4afA8VkC/UNSPgI Zj7ViJ0CEAPZC4BMRD6iwQMUSUvqiQzlgah8BjiazMrD0gMnRUN1imCZrilFtDVW8wFMeQHENVA7 hxVewgrH5mC1mjGsZgrzEPXWIyrv0GGPFRTStxOYO/Rr93ACOBAv5xpIoEH7qnmnWs9NdCrubOzZ 95UL/6rpwb8GfEnG0edc02fkMRlFk+Qgc+imifwWJK8MdMmAEK0JDOlpk581txUUG0Pr1sLkpxp9 J1Jcz/0ZQJkCskinI7BxSEbDLsg2Z41YFXyg3lt0/JqM3JlBXFE8rldalUUm6S+BKEcoCY11k3Hb aE4z0qEw0EDOXb3rlkW7kSVkYlydxKfKuH2i+v5IukmBAVr5B2XcSFU6iKPAyNTJQWvu9ODnSvpY N/syYwGA78S4wLQYCi2to86ejSh7BX1nBEWOLZtbr7XCfKr6WAos+nAMeGtq09bsMXQE3PAYKC9H sxdKH2ijYegDB6loTWp9QL9DSjIml2jxfg+EpKsV2C3qByeyU/xPO9MjGEHS3d4Jd0n/LcwohwOm HFg04hFcdX8bL4YifbxyrRLslDXB5aCt6abWKuGgO/VniOXJ8bEp27INlYvo5dAEHHEP+iCej5j8 AKtl83eSVHeccCgoNHcAcz/fYlblJeQDP3O7ZdWPney/K1VsThSMLOlohzxqY12rB4ujgsKutW41 N0kth2E0NbPPaTGIrjapTqd0lX7IHkODthCPbMIlaEeHZZL3huSteu0XanzAVFqOMFoevtKQITFK hw/vUKB4czSpjSBFA1fwlY5N9IhjaMmH+aa+UxDTL6ao9KfjJBGgUJjZjCTWCtQjSIPjd/mAsOGc QX/ILxAWzgcuzwx4bf3RyN4YEwLt+p9Bk11D5XnUCAe3iBY3s4/A512wLiYWXZ7miERYNgQnSlHo HKNDZcCE2baP2iRsoVjpyZCY6zlM/h5aRMcDLtu2gU6a8aJKvs48w2D5An8JYM782tFYjg+s53UW vZGv22RP4q5fV/BDQVhkB1K1hKuo5vbF9B9wfWPfiq61Rt6KSg7CgTrn5kTiERdJPklkj0uZttqw w5K1pv9JOo2YkumXL7yaQNYqY7lCN87r2O9bVMbiYORzB9QeYqbNUYtXUa7SoZ9D0MWh5Xipi79r jbmC36H7vJWPhPGC1SQTbPhteyDJ1o8JW/NSUQrIcCMu3+Y724bNdV8UZd72O4ZaNr3V053V7V91 6TeCJT91C8S0f0tvtmJsKSD8eR+tjzWQSHV+6DzNnjFsbC8rWTgodlPMZwFiGyL9jseKK0mhL+tP hmwA1ofHeFfejbZjo12n3onxf1etb42WGvwtfm63jDMj3fnSGVm6odySEAphfpUS4y4neoQIhFk4 gG/Adc1CshVIB1drQPbDfSltieHf6XjfNxZ1WLI1RKIcgew2dW9r5EyGXYTMNqItWq0nau+8wOhQ 05B7ywMdHJPjEBmOfMmFQ+hGDxmPo5cDkCz6I/mNZQgc3enBfzYGC9JUX5e8U9K0H/MzwDLsJ0Cy ALFZBjWY7JQM2WbZ9CyHEg/vPVSlIUMiHgoE6JcUtFpkQEbWNuJQOC9TYU+c7x+PDFgJboHdVVli /OGwm163WAIMi0PPocXT7LCUf4iAF/J7dhlrM4Y5FC4PUfneYcNTm/O0Px2S3xxHO2yWqxC4knUv K3FmqAnvN8ZF52NH+aum4GOcHKrRpLY20P1b4obtJZFuEEt/FScGTwykI52sbu7d78stI1uRU2gO 3mxUl+d7BBIXRdbnKHiAQ7YM/p1PbnyqHjnoPuezEHfuOA8+UI5VrZ18pXOEy8wTl/KY7rzDl8ot KVfxd6f6JEDMnADaZrV2t5tja0rY31tti7r1J/j6F9XS1Xf0a60bja5cCkVPuP+KLuewUI2ixkt+ JMp3Gu4kFl+oyRcif4U+W7KqpMtmsoX4PI/oYK3b0v7hKenLJ8ABkhHK6rzsNkZ1PR6v+Y5NQ8P3 nETNU2jpEbeuQmy+igQZ4HpJEjXXT8WbsUgr9SFCtHQfK6vEB8wVtdTgYM0DkyCLHCXHuD5UvQJN eB+oarxOptR5lBp6tC+nJRoPVV+sOptvs22LWr8qzrvcL3KDMngo/YdEksr60Hwj43eUs2ChKCUP TUHKG1oFaTIWdlVYbBfSodpC+AJXE0BOfjPTFOBZ8YC6ZlQah6zPVLT5ZhUSsMZUtkmWHGvqk5jo NQJqNx9Qt1JXuCoTiIH19X3X0/9txuwpTYFzBEUmfAZ95Jl0tv0tfEUgdueyvS91rhxAE1JSAF5Y fKd0xJL+0yeZYxtt2uNcAa5DE0m3OWVNzQTayZkH25nfzQpGI1jzCTncuHMPpwXphfFrmra9HleZ sZX7tCTXoD9of6Y4vG06FhFnl5D1w2R7srG7FVhpGH812mb9a/Vhm+9qeMXyLKYJBh65VMbraWsV FFdjSyGuJd0Qvbz52Tn/sV/OlIt5rFtUmKqxU3YUMorn25nEls1F1y62K4l/rTI9tpU72N6bbRQr laDEZlR6lBQqSWXGS22VOQVkjTJNg4puSIQwU8FEDjkUOV67FDnNDG2aQ8Gj+oGlvHnucMhtNGSZ IFG3hPYd9XDatozSH6lwG9aqs5SaGvntghTXNLghrGKkJ0tUO8+80hncVhEXqCzIC0LSzEiUtiqm y3A8nqItq1xfokFHgPICoFAZFR2FWQo79Kp4hCI5eBfdRKlHNSWIPSzFirsPRyoV+VKGYkk5b9qk 7Yrp8gYBFVEPQbsvlS2rNKRPDNim1JMcW+0WC5LoDquNvNYQawSIr2S2jnobf6ZA604aGH+Y4G/3 kx/Kf/8H/Fj7s2VuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKMjcyMwplbmRvYmoKNCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250 IDI1IDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjI2IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzMSAwIFIKL0ZvbnQgMzIgMCBSCj4+ Ci9Db250ZW50cyAyNyAwIFIKPj4KZW5kb2JqCjMzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAzNiAwIFIKL0ZvbnQgMzcgMCBSCj4+Ci9Db250ZW50 cyAzNCAwIFIKPj4KZW5kb2JqCjM4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAv VGV4dF0KL0V4dEdTdGF0ZSA0MSAwIFIKL0ZvbnQgNDIgMCBSCj4+Ci9Db250ZW50cyAzOSAwIFIK Pj4KZW5kb2JqCjQzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9S b3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4 dEdTdGF0ZSA0NiAwIFIKL0ZvbnQgNDcgMCBSCj4+Ci9Db250ZW50cyA0NCAwIFIKPj4KZW5kb2Jq CjQ4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1 MSAwIFIKL0ZvbnQgNTIgMCBSCj4+Ci9Db250ZW50cyA0OSAwIFIKPj4KZW5kb2JqCjUzIDAgb2Jq Cjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA1NiAwIFIKL0Zv bnQgNTcgMCBSCj4+Ci9Db250ZW50cyA1NCAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUg L1BhZ2VzIC9LaWRzIFsKNCAwIFIKMjYgMCBSCjMzIDAgUgozOCAwIFIKNDMgMCBSCjQ4IDAgUgo1 MyAwIFIKXSAvQ291bnQgNwo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdl cyAzIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVuZG9i agoyNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoyNSAwIG9iago8PC9SMjIKMjIgMCBSL1Ix MgoxMiAwIFIvUjE0CjE0IDAgUi9SMTYKMTYgMCBSL1IxOAoxOCAwIFIvUjIwCjIwIDAgUi9SOAo4 IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjMxIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjMy IDAgb2JqCjw8L1IyMgoyMiAwIFIvUjI5CjI5IDAgUi9SMTIKMTIgMCBSL1IxNAoxNCAwIFIvUjIw CjIwIDAgUi9SOAo4IDAgUi9SMTAKMTAgMCBSPj4KZW5kb2JqCjM2IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjM3IDAgb2JqCjw8L1IxMgoxMiAwIFIvUjE0CjE0IDAgUi9SOAo4IDAgUi9SMTAK MTAgMCBSPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjQyIDAgb2JqCjw8 L1IyMgoyMiAwIFIvUjEyCjEyIDAgUi9SMTQKMTQgMCBSL1IyMAoyMCAwIFIvUjgKOCAwIFIvUjEw CjEwIDAgUj4+CmVuZG9iago0NiAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago0NyAwIG9iago8 PC9SMjIKMjIgMCBSL1IxNAoxNCAwIFIvUjIwCjIwIDAgUi9SOAo4IDAgUj4+CmVuZG9iago1MSAw IG9iago8PC9SNwo3IDAgUj4+CmVuZG9iago1MiAwIG9iago8PC9SMjIKMjIgMCBSL1IxNAoxNCAw IFIvUjIwCjIwIDAgUi9SOAo4IDAgUj4+CmVuZG9iago1NiAwIG9iago8PC9SNwo3IDAgUj4+CmVu ZG9iago1NyAwIG9iago8PC9SMTQKMTQgMCBSL1I4CjggMCBSPj4KZW5kb2JqCjIyIDAgb2JqCjw8 L0Jhc2VGb250L1FFR01KTytIZWx2ZXRpY2EtT2JsaXF1ZS9Gb250RGVzY3JpcHRvciAyMyAwIFIv VHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzWwoyNzhdCi9FbmNvZGlu Zy9XaW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoyOSAwIG9iago8PC9CYXNl Rm9udC9RRUdNSk8rQ291cmllci9Gb250RGVzY3JpcHRvciAzMCAwIFIvVHlwZS9Gb250Ci9GaXJz dENoYXIgMzIvTGFzdENoYXIgMzIvV2lkdGhzWwo2MDBdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMiAwIG9iago8PC9CYXNlRm9udC9RRUdNSk8rSGVs dmV0aWNhLUJvbGQvRm9udERlc2NyaXB0b3IgMTMgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDMy L0xhc3RDaGFyIDMyL1dpZHRoc1sKMjc4XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5 cGUvVHlwZTE+PgplbmRvYmoKMTQgMCBvYmoKPDwvQmFzZUZvbnQvSFdOREpSK0x1Y2lkYUNvbnNv bGUvRm9udERlc2NyaXB0b3IgMTUgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIg NzMvV2lkdGhzWyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYw MyA2MDMgNjAzIDYwMwo2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAz IDYwMyA2MDMgNjAzIDYwMyA2MDMKNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMg NjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzCjYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2 MDMgNjAzIDYwMyA2MDMgNjAzIDYwMyA2MDMgNjAzIDYwMwo2MDMgNjAzIDYwMyA2MDMgNjAzIDYw MyA2MDMgNjAzIDYwMyA2MDNdCi9FbmNvZGluZyA2NyAwIFIvU3VidHlwZS9UcnVlVHlwZT4+CmVu ZG9iago2NyAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5jb2Rp bmcvRGlmZmVyZW5jZXNbCjEvc3BhY2UvVC9oL2UvZi9vL2wvdy9pL24vZy90L3MvZC91L2MKL3Iv YS9tL3AvUi9QL0wvcGVyaW9kL0EvY29tbWEvRC9PL3YvY29sb24vcXVvdGVsZWZ0L3F1b3Rlcmln aHQKL2Ivei94L1cvay9HL0MvRi9vbmUvSS9qL3kvcGFyZW5sZWZ0L2ZvdXIvcGFyZW5yaWdodC9O Ci9CL2h5cGhlbi9zbGFzaC9iYXIvYmFja3NsYXNoL3R3by90aHJlZS9maXZlL3NpeC9zZXZlbi9l aWdodC9FL2VuZGFzaC96ZXJvL3EvbmluZQovcGx1cy9TL1YvTS9IL2JyYWNrZXRsZWZ0L2JyYWNr ZXRyaWdodC9VL3VuZGVyc2NvcmVdPj4KZW5kb2JqCjE2IDAgb2JqCjw8L0Jhc2VGb250L0hYSkNF RCtTeW1ib2wvRm9udERlc2NyaXB0b3IgMTcgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDE4My9M YXN0Q2hhciAxODMvV2lkdGhzWyA0NjBdCi9FbmNvZGluZyA2OCAwIFIvU3VidHlwZS9UeXBlMT4+ CmVuZG9iago2OCAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VFbmNvZGluZy9XaW5BbnNpRW5j b2RpbmcvRGlmZmVyZW5jZXNbCjE4My9idWxsZXRdPj4KZW5kb2JqCjE4IDAgb2JqCjw8L0Jhc2VG b250L1FFR01KTytIZWx2ZXRpY2EvRm9udERlc2NyaXB0b3IgMTkgMCBSL1R5cGUvRm9udAovRmly c3RDaGFyIDMyL0xhc3RDaGFyIDMyL1dpZHRoc1sKMjc4XQovRW5jb2RpbmcvV2luQW5zaUVuY29k aW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNjkgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAzNTk+PnN0cmVhbQp4nF2SPW7DMAxGd5/CNzApK3ICBFzSJUOLou0FHJkOPEQ2HGfo 7cufpkOHL8CLRFlP+JrT+eVcpq1u3tc5f/JWj1MZVr7PjzVzfeHrVCoM9TDl7ZfsN9/6pWpOr/3y 9b1wLRt4dH7rb9x8pIP9gz6T54HvS5957cuVqyMAHceRKi7Dv6U2+sRlfG5F8kCLJBjIA4EVW/LA DhQjeSDZ5h15oIuKiTyQ9oodeSDY7J48EJPigTyQ7EM9eSCOihfyQLdTzOSB2CoO5IFkm5k8kGx1 JA8knUV5C40cFRTFFd3XUFzRfJPeCsUVzbc1FFc032hHiSu6rwqiuKL7DoriiubbqS+KK5pvyori qgmAekkUV3RfWxVXNN90UBRXNN/UKYormm/Ut0JxRfc1BXFF8+30ZHlsiygYimsw36iXDOIazDcG 68ezCFoV7dyzYnV+rCuXzYppxdPCTYX/urvMi07VkuoHMZS9tgplbmRzdHJlYW0KZW5kb2JqCjIw IDAgb2JqCjw8L0Jhc2VGb250L1FUUEpPWitDYW1icmlhLEl0YWxpYy9Gb250RGVzY3JpcHRvciAy MSAwIFIvVG9Vbmljb2RlIDY5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAxL0xhc3RDaGFyIDM0 L1dpZHRoc1sgNTI4IDE5OSA1NTUgNTI2IDM0NSA1MzAgMjIwIDUyNyA1MzUgNjIyIDUzNSA1NDAg NTA3IDQzMyA0NTcKNDA3IDUyOCAyOTIgNTI4IDU2OCA0NDkgNzk5IDUyNyAyNjcgNTAwIDUyMyAy NzEgNTIyIDY3MSA1MjEgMzgyCjUyOCA3OTIgNTk2XQovRW5jb2RpbmcgNzAgMCBSL1N1YnR5cGUv VHJ1ZVR5cGU+PgplbmRvYmoKNzAgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNlRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2c4ODcvZzQ4NC9nMTkvZzEzMS9nMTUwL2cx MzgvZzMvZzkvZzE0NC9nMTgvZzE1MS9nNi9nMTQ1L2cxMzMvZzEzNS9nMTQ4Ci9nODg4L2cxMzYv Zzg5Mi9nOC9nMTU0L2cxNDMvZzE0Ni9nMTQyL2c1MTQvZzE1L2cxMzkvZzEzNy9nMTcvZzEzMi9n MTQ5L2c4ODkKL2cxNi9nNV0+PgplbmRvYmoKNzEgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyNDk+PnN0cmVhbQp4nF2RTW7DIBBG9z4FN/DgH5xK0WySTRaNqrYXwDBELIIRcRa9 fTxM3UUXD+kBg4Zv2tPlfElxVe1HWdwXrSrE5As9lmdxpGa6xdToTvno1l+rq7vb3LSnd5u/fzKp 7QIF8au9U/s56bqjpcYtnh7ZOio23ag5AuAxBGwo+X9H2kjFHParGgUYO9y0QwFGYO1RgMGxDihA 51lHFMBoVoMCTAPrhAKYA+sBBejqy28owNCzWhTABNYZBTDE6lCAqTbpUQBTuyIUYKy1AQUYuCu9 ZaFrGz3URPavczic8h6qcs9SKK11FDVqjjgm+ptWXjJXqY3mBUu2hA8KZW5kc3RyZWFtCmVuZG9i ago4IDAgb2JqCjw8L0Jhc2VGb250L1lCV0JKRCtDYWxpYnJpL0ZvbnREZXNjcmlwdG9yIDkgMCBS L1RvVW5pY29kZSA3MSAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMS9MYXN0Q2hhciAyMy9XaWR0 aHNbIDU0MyA1MTcgNDIwIDMwNiA0NzkgMzM1IDUyNSAyMjYgNTMzIDUyNyA1MjUgMzQ5IDIyOSA0 OTggNTc5CjUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDddCi9FbmNvZGluZyA3MiAwIFIv U3VidHlwZS9UcnVlVHlwZT4+CmVuZG9iago3MiAwIG9iago8PC9UeXBlL0VuY29kaW5nL0Jhc2VF bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjEvZzkwL2c4Ny9nNjIvZzg4Mi9n MjU4L2c0MTAvZzM0Ni9nMy9nMTgvZzM4MS9nMzc0L2czOTYvZzM2Ny9nODkwL2c0L2cxMDA0Ci9n MTAwNS9nMTAwNi9nMTAwNy9nMTAwOC9nMTAwOS9nMTAxMC9nMTAxMV0+PgplbmRvYmoKNzMgMCBv YmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNTY+PnN0cmVhbQp4nF2STW6DQAxG95yC G2DPTIZEirxJN1m0qtpegAwmYhFAhCx6+/qn6aKLh/RlxsHPuDmdX87TuNXN+zqXT97qYZz6le/z Yy1cX/g6ThWGuh/L9pvsWW7dUjWn1275+l64lgs8eH7rbtx8tNF+Qa8pc8/3pSu8dtOVqyMAHYeB Kp76f0cxesVleF5FciAiSQzkwA40RnIg22kiB9qkcUcO5L3GTA4Eq23JgXTQuCcH2qjxQA60O40d OZAtXsiBPGgs5EC22p4cyPbPTA5k62ogB9pWIsosFGmj1yiuaL6ZNYormm+2y+KK7ls0iiu6rxqh uKL5Jn0Riiuab9LhoLii+2rPKK7ovkGjuKL5BnuvuKL72qm4ovtak+KK7ps1iiuaYLTLIocmmHQa MuxjMIWoXQVpP5hC0kkGaT+4wt4W4vnldTd0yZ47VZfHuvK02SbapumGjRP/LesyL1pVC9UPMN+5 +wplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjw8L0Jhc2VGb250L0NVVVFBRitDYW1icmlhLEJv bGQvRm9udERlc2NyaXB0b3IgMTEgMCBSL1RvVW5pY29kZSA3MyAwIFIvVHlwZS9Gb250Ci9GaXJz dENoYXIgMS9MYXN0Q2hhciAzNi9XaWR0aHNbIDU5MiA2MTQgNTM1IDM2NSA1OTcgMjIwIDM1MCA0 NTkgNTk3IDUzMSA1NjkgNDY5IDMxNCA1OTcgNzk4Cjg0NiA2MDQgNTIwIDMwOCA1OTcgNzA1IDY1 MiA2OTUgNDYxIDIzMiA1OTEgODkwIDMyNiA1OTIgNTkyIDU3Mwo1OTIgNTkyIDU5MiA1NzggNTI1 XQovRW5jb2RpbmcgNzQgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKNzQgMCBvYmoKPDwv VHlwZS9FbmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwox L2c4ODMvZzE5L2cxMzEvZzE1MC9nMTM4L2czL2cxMi9nMTQ5L2cxNTEvZzEzNS9nMTQ1L2cxMzMv ZzEzOS9nMTM0L2cxNTMvZzE2Ci9nMTQ0L2cxMzcvZzE0Mi9nMTQ2L2c3L2c0L2cxOC9nMTQ4L2c0 ODQvZzEzMi9nMTQzL2cxMzYvZzg4NC9nODg1L2c2L2c4ODYKL2c4ODcvZzg4OC9nOC9nMTU0XT4+ CmVuZG9iagoyMyAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1FFR01KTytI ZWx2ZXRpY2EtT2JsaXF1ZS9Gb250QkJveFswIDAgMTAwMCAxMDAwXS9GbGFncyA2NTU2OQovQXNj ZW50IDAKL0NhcEhlaWdodCAwCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0F2 Z1dpZHRoIDI3OAovTWF4V2lkdGggMjc4Ci9NaXNzaW5nV2lkdGggMjc4Ci9DaGFyU2V0KC9zcGFj ZSkvRm9udEZpbGUzIDU4IDAgUj4+CmVuZG9iago1OCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAyNDc+PnN0cmVhbQp4nGNkYGFiYGRkFPJIzSlLLclM TtT1T8rJLCxNBYkq/5Bm/CHD9EOWWZbBZ84b3m4e5m4elnnfJwh9bxH83sj/vU6AgZmRsWLKQuf8 gsqizPSMEgWN0KBwTW1tHYSIoaWlpUJSJUxGwSW1ODM9T0ENyChLzckvyE3NK7FWcAaqzsnJTFZI z6ksyChWSExJSU0BaQtLzEnNVnDLzMksKMgvU9Bw1lQwMjAw1AUSRn6ZuUmlxQrBiXnFCj4KQanp pTmJRQqeJYlAg1DkGBgYGBWAmIGJkZGF/fsqPiAqWfRjwfzvvvN9FrHd5HrMfXMCDw8DAwBhr1c3 CmVuZHN0cmVhbQplbmRvYmoKMzAgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9RRUdNSk8rQ291cmllci9Gb250QkJveFswIDAgMTAwMCAxMDAwXS9GbGFncyA2NTU2OQovQXNj ZW50IDAKL0NhcEhlaWdodCAwCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDAKL0F2 Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAwCi9NaXNzaW5nV2lkdGggNjAwCi9DaGFyU2V0KC9zcGFj ZSkvRm9udEZpbGUzIDU5IDAgUj4+CmVuZG9iago1OSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUKL1N1YnR5cGUvVHlwZTFDL0xlbmd0aCAyMzU+PnN0cmVhbQp4nGNkYGFiYGRk5HDOLy3KTC0C sdV+SDP+kGH6Icssy+Bgksfbw8PYzcPczcOy4HuT0Pcywe/F/N8LBBiYGRkremc55xdUFmWmZ5Qo aIQGhWtqa+sgRAwtLS0VkiphMgouqcWZ6XkKakBGWWpOfkFual6JtYIzUHVOTmayQnpOZUFGsUJi SkpqCkhbWGJOaraCW2ZOZkFBfpmChrOmgpGBgaEukDDyy8xNKi1W8M3Py1fwUQhKTS/NSSxCEWRg YGBUAGIGJkZGFvYfb/iAqHz+D9P534Xmz5/Pto1rC/c2Hp4tPLwMDAB+alBjCmVuZHN0cmVhbQpl bmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9RRUdNSk8rSGVs dmV0aWNhLUJvbGQvRm9udEJCb3hbMCAwIDEwMDAgMTAwMF0vRmxhZ3MgNjU1NjkKL0FzY2VudCAw Ci9DYXBIZWlnaHQgMAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9BdmdXaWR0 aCAyNzgKL01heFdpZHRoIDI3OAovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvc3BhY2UpL0Zv bnRGaWxlMyA2MCAwIFI+PgplbmRvYmoKNjAgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9T dWJ0eXBlL1R5cGUxQy9MZW5ndGggMjQxPj5zdHJlYW0KeJxjZGBhYmBkZOT3SM0pSy3JTE7UdcrP SQEJKf+QZvwhw/RDllmWwWfOC95uHuZuHpZl35uFvpcLfi/h/14owMDMyFjRNd05v6CyKDM9o0RB IzQoXFNbWwchYmhpaamQVAmTUXBJLc5Mz1NQAzLKUnPyC3JT80qsFZyBqnNyMpMV0nMqCzKKFRJT UlJTQNrCEnNSsxXcMnMyCwryyxQ0nDUVjAwMDHWBhJFfZm5SabFCcGJesYKPAsjZKCIMDAyMCkDM wMTIyML+fRUfEJUs+rFh/nfb+dGL2L5zcX1X5P7ONYWH57viVB5eBgYACdZUNwplbmRzdHJlYW0K ZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSFdOREpSK0x1 Y2lkYUNvbnNvbGUvRm9udEJCb3hbMCAtMjA1IDYwMiA3ODNdL0ZsYWdzIDYKL0FzY2VudCA3ODMK L0NhcEhlaWdodCA2NDEKL0Rlc2NlbnQgLTIwNQovSXRhbGljQW5nbGUgMAovU3RlbVYgMTQ0Ci9N aXNzaW5nV2lkdGggNjAyCi9YSGVpZ2h0IDU0MQovRm9udEZpbGUyIDYxIDAgUj4+CmVuZG9iago2 MSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMTMxMjAvTGVuZ3RoIDgzODM+ PnN0cmVhbQp4nO16e3wTVfr3c86ZaybJTCZN0rRAWkq5FbaFUq6RjtKC3Cs3LRAVsWhBBAQqF1+o IIhFBTSAsuuKN5RFQMHluq8itqhYVxbBl10r6oLL/nBZwF3FhWZ4nzNJafH1935+/+7nszmZyWSS Oec5z+37fc4MEADwQDUwKBs5Or87OK9urXA3bvL0STOT3/MLAEj95Ko5WQOODa/BEw24/XPKzHum /+KWwwx/O4LfW99z3/wpyf+zHgDta++tmHT32zP8AwAKFTzZ8148obUT38b/X8Dv7e6dPmdearw5 eO6B+2ZMnpT83ulHALHn9EnzZgp9ySUAmoYns+6fNL0i+XtBI/8+c8bsOcnv3f/qfH+gYmbw+JB7 8P84PtgAV7/G7Qxun4tMbCv0F8aJH4jnpDypxJ5rT4Q6OApx2CuVwfarqZf4AZyUSshNV/+HL3gM XkgdHYZLYg/YCq/DfngN9gm5ECYvwUnoDpdoBNaRmbAQJtNN9LR9AlaQjuRGPPsK9IVNsJVWwluQ h9dOtPfCQzAMZsAi2AuPwmnYAovpBqkELpGOwkb6MAyhf2IMe76RdIRLsAJeo5JdhjP4GCphLcx7 M6J3ycmqqSktuy07O7O0pLxrl6GjbistyczOLu/KVYX2lsrsMgDhU/5VOMrPXPci/AzdAPOgDZSC CBQMCMI6/OVTnCUDYg3McN0dGT8sJ1Ks5ER0b07E486JaK78iEvyREQhN8JofkRVohEC+RFZyo9M vmu8HpvwlX77vK/0eRPG6MPNjfoN5h6SZfXTo+YFvV/fr/TRpj9yixGOlBgb9QcCR/W7jDv1O4yv 9Nvwcxx+jsGtP259jbf0XvjZvZBfr+uFxhI9gN/9uPmMPcSyMnXT+LVumGZEbzWz1czW1a2FiDRD el5i3clechWUoaNve4O8QZ4sX/YEP6xuXT57Nsn7f1/wM+fyUA+Uq4wdFXEHMkC2L9uXizsC9Gji fjoqsU2EK2AJ1ahLUm6fEG6Q8jDGOljpmXKaJ09u5xE8w2GYPFxye+ShLoN5jZPnElEoThQnYt0K SDvwGZAbEPiHKNxg77cnkedJqX3F/gvJIKJ9oh31kPlkHvW0W1FkT7J3YruzCK0Wt0+wec5Y+Vab XkDS5ExPOznPGc6Nww3ryEjLEWNNQ8b8ycGKkkPHyUDya+x4PxFJhn3GvizltUv8w37UXpH4Bw6J wowgw8jGIu4r49CHFqKva9DdCsjMdFEqglgMgqxqpkAh6Da4jkuryj9Lr48m6nGaxT6zT340Ee1W gEoryvYV+rID2T7axu5NPlhLPrj2sdbuzTV43H6HJtDbVehqmRaMlEaIoIwYCNVCOzHoqs5w+h/A +8/4ICNalUiH4nOJDNRjUc9ikoN9G+T4FJ+wkHS035nsfakr6bjTHo+SH6URAehOtKG5m5hQxkQQ jM+Mz1Ap3Qr8RdmBo+wXNBKPOzKg0bkMDCKWZpERaPkREBRaDp7A6zKcKfnIcQzvjhjmOMpQtP8K tAnGrOWGYdTNbgGR3EJxqAS+URvdClSSQ4QVjfe+wp6R8n7cKo/GmJtx9XNhsngO9eqHflbnIqlE oqLbZQTcGUauu7Ox3P2YobhNEA1T0lSf1/QZrIBRlmZ8FjvXkLhmWbEtN2lhd77vkOUzsnGjlWfs c8R/5gzx2+fOcEntE7lkE7mbTCav2BPs5+xf2ePjtIrOSTyeqOGz2ItWjqM0KvSwQmNFIjBRklFp Ao4tGxT1GHQ127khaiQacGaJqHHgyAGUohCtLBbloi32kpX2XFpGVsaFxeUL9l5+NY69v4bqvIS9 h2GmVVLFqoTlbLkgBNJ8IYFJpEeoJDQmdHdoTuiRkNR00ieBl4RQANX0aqEwCU+VFkg1EvP5JI1k GCdrGxKxWvQzRw9RPOhD+I5vMbh2xCVDJ+lZ1KN9Tlu5qGdh92AgTdKJJGcHXlvwXfmeJ6pWHdrz xkeXHlgx5q/5NLb1bxfKd+97cNW920Z88du5v1888kTdVpT/LNoqU/w7tIPxVp82mkszXa5wDjNz xDQzrA1sM67Nh23+q43QRnK5XBIMzBovlfumSgulBb4an5zlk1r5fEHI5UKfO5aI8ejALRmc/Avf dSvoVRQs7M4lzSNFeNDreqFFwZcm5LQ9++F9y19+7607+yyd333kovvWv/bSq4e+tL8nve1vv31K 3jbwleXrXnwyu9uIhfc8eMvWPjuf//GhafYXH3/H/Q0tjOgILsweZVaX8Z5pnoWelZg6BMltqoSA AILg0rQKbba2RBM0pkguv+BmEPQ2G/730QON0QbjQKw5yA1ufx7npNBXGMjxEYz0E4n1tHJvXV3i EfIeWbmJrW+8NY5eEaEbeax5UZsSShKEvlYrxdQHeZgZED0Bt2uINF6iHtMn6Sa4gqHmcWvR42tx 0MbihFHVkI7xm5vUlpHdVnaySxYE0iCnLfFunrLgOXtEbiHdlbhAJFJg/+3IXGXzTf/7aTJUoAdf t6vtH08dtv+JGnnRicC/QwCyYazVw8WI1MpUlDRv0PSKzEzTMvyd/T0jw/Qh4Yn6+HBVZHlEJZox I7w4TMMRCW3atlnCxIGGmCNik025WkgALUh9aEHTkY5ijGZ3Z92TpkVfDwrmm5X765d+su07+/JH F6+SKJEX/Pb+lWvnL1jzK3HX5uH2Afvzt+1/HDxl/4lUk/vIDLLn8sP74i+8v23N6x+hZ36IVi1F XWrQ08oAQRH9kus2YaqwQKgRBEFRRK0ExJYp+hiqz0hasPEApqbs/sRPMEkHZGAkbE49QIoSxeyh Ajunx8ZGMppm7d1U1thgj8L8thH1NQKjOA0i0Bm2W/Pby4QDpNvUImlyoHOWktt5QuQe1z1ZFZ2r MhbkLs+oyTU6Z7mYpyMEIqw1HRgakjUuVN56VOeKUGXr+7LmeqpCyzzLQ+6Wf6IdW3sEQ8wwDTHX FLW2fmWUp6OfjvJ7jNYhw/ATfzDPmc5APh2eCo3v+Tul+RDPA6E+fON5IHWEeZK0L+qRCqU2JMBj qX2Rkctt4ERdPrlmlBD57eEz7+760E7sfNy+cPTjq2TR755bPOvZv9B3F1ZUzH+ftY8f2Hz41Wf+ /Nx9+5fsu3hqF3HdtmFb9fMrKl567OyCFyfOmFr++Dz0r7Wor7GoL+5fI6186Zp/oW+J6GOaz5/t 7xu5SR8YHqWPCy+I1ERUny8iQdjQUq7lzPFcbcOBxE88y0kWGCjoU0U9gB+iZ7X1t702n/Z/2XfX 3vqlR7ZdJNJHF227zr4yd9v9j6+bP/+p5/TNg5FetnubeN49RdrbD9txe419s7ho39MvHtq2ZstH yH8cPBT6O/ynq5VmwQiiiCMEymSERoEIQSUFjUkrRFPshqMyx8cURtonSEcW5J+NZ5N4ScGN19eJ vF8XPGgNVMVO6gA6yDWBjKMVdC5dRlVVFFyCIsmySzAQ8GQDk4aqmKLkQkiiRBLwUooHhAqywIC5 QeOwzg19Q35DugMK0WIHE3iCkkUjIfP3sVq+EQ4KpJDksGzmz2ZucrmOXP7D/MSuhbvIsW9FdjlB brTfIcdpBWd/HBdvQ2m9mK0iELP69JOLWw+VR7YeK41RKqQpiiLr5urIxgiNRIg3YBIp3fTC/MzH zMcymeAzVV8m6CHk11mOtkqcVFFrODhwzaKxBKZ/EkOalOVLk2TM9LIX5SvMcsDA14QKe8mvycFf riQVlSXb3n27lDy54YuJO957+uInN4vM/uyBV3IG2z88M65PLj1xcvqwxtyyaQ89hRliytWvhaVI EgLQ22qTycIyJlhF9puUCEapMdZgGsd/wycGg81Z4lxDLJXLuGC5Uk4WOKkrxBMaz7SF3XsJSw9t t39v15A5pMtvDh56/X37Kml7umZ/x0GYpfJIPpnX97cT7IY/n7ZP3ox2X4KaXIaaVMGEoVbXJwwi UQxQKrlMgLCQ4e0kdPJWeud7JcGH0O91GflQAGVog6D/uniPNWvumtYMrrAOhVk9fQYqaglZSqtX 3nr12GOTScb5E43PiCzxjH3qjRl3xL8iCnGf4TNGZxQqUR4NbrBaiaYyUAEioP1UFEdCpYiq8Tz+ Ld3dbLgYol1DbUPT6FX5HIiS5Da5nWCTE3fR3okPaL3I4vbCuN2fs0us40BY4cy9mxXAsRREWxwK B6J8HEhxqwFN3uFwKyfWW/Z/ia1J9KCTE8/xvgfGE19iz8PRupVo3TCMsoqWyCTTHw7Rgeo4lXpN jyfdZGa6rJomEaWxEtUMD1qaGJKvLHBnoDqwMSAEMhw6Gautb5lhOHTFIEZaWNuXgxTvmh8I5Sl7 f1048iLZ9eFb9mf2SscRhL86Rj9lf+Emo+OJ1y3yAHJldAauB1SG0N/ReZEVwlLCRZAqSwqAbAgK MM1oqiYcW3NtRxNNsZzUBWoDNyT9vngdjRw6lPgabfsJ7XY5QfsnDvIxtuIYuc4YUSuiCJg2VOSx IGuqynks1rpvwAE4gnVvyrSDHNPWIqtA46IOavGdZLQcFrnqt2KR9yqbZ79KyuPs83i8Mdex6kmH UTHsKctyE4nhKAIzIF1q9phzjrOkBA+crKM7RXZljXP17fjv2Xi1DlOsG8eyuYx6mItpRNOAJJUi UhcL0jDL1Yq0eexxt+Jxay7KRFnR5UJF774aNuJcjiBxCxrXI2IS/Ypri2uTXNNBQJQB0x5XXg6W Izm+28+RDEoCl16g9peb7K+oyBrPsuDlhDC88SDrcOXwNXvJqMuJVrcSNobdzeawlarI/Iqiqn5K GVMVKlIuLX5qUiErEIkIqlYIoZaWRJ+O1XLfak7NsuCkZWiSjJsVpYrvo8PpC7sS23GejRPYC5cT 7PXGMZg/+qOnx9HTNQhBiZUX0DMCuXrnQIU+NTBXXxBQAibDVKwSyQcmMd2+xbAKdcMgPb2Flc8d i51rqpz8TVUT+rg/zUQMLepBEU/7k662jduntm1/enTnpk1vvbVp0066BJU33X7a/tiut58m00mP Rvs88TVeIT77PMe106n8xuu5m6xcUejpLfWWG5XGfGOlgRyJO7uZDHqfDm7u62nXR32iRdTztNY9 hGRFyM4Jk8IsHweA0+SFL+84aL9vn1u9kKxe/0atyDqOuXD4L3aYLiTpVVNQij0oxU4Hr0LwgjW9 JkAM1XAZmuHOUrNcWVqWu0AtcBVoBW5LtVxY6roNQRVdISlNDbh6qEN9E3xV6hzXcvUR12HVo+KV mltSPUQ33Z5BmD2COAMEDLemMpfXFZZ8+UjIQPfibNKvR7hYIgnJ3A1T2TLqeADH4yiJzWoxScR1 tD3OM4V0e8g9X926b/lz5NB5e9qOe5/f9/jv5ossd/h7y3cOT+yhwcRZuuXxB2eM4nH0MvoFL4Lb Qo11a3ftJu2uIFJfMdJB6ZNRYg7OGOcaZU4hUzOmZc7PWJi53PVYRk2m7lIVt5iRGWrTRgy5BT2b mdlymqmTa+ehxN3fCJGQ2L+NL5TT7MnHOP5U1aY3VZh9rtHOa2ccsomZMwupWIQKDtXMLRKSc8sn vyAOD2Xf/XGz/f3djy6aR0L2qfOb7H8RaetT2+554ZG6Z789vlX4ZsuYtwaX53fpdNfZHccHvVc1 e9KQcf0KBm+o3sqXVzHfg7DXYVGjrWKJmgz9CkRDzBLLxGpxtbhRfEM8In4lugzRwlMzUycP4ElV xIo+C+tBrMYIUKogeWqIzUoYx2KzuAfWppZt+JKNZPuFjbjNiMevrOHjPova7oPjmpBvhQaK40Sq giSi5jRDoYaBkfcTtHZ4eS0Pt0JfkppioKfJUjYWQ8/WPbz6meWv95lvn714BtPP9/W7d/+BSYnQ xcovEadNHM+L83wPx5NgmlVazUgum8mqGZNokLanPel4GCdNpgtgLpst1cCjzI2VgyhRgwBhfJVT wLQs4cWY+CUBM5NC5CaqmN5EFWt5JZsiiRz1eDlLClUMdwq29wjZQF56zWYonsAaLyc4V8J+33Uy 92armgker6xIIogiEOS2mIBUpnnCLNPTSevsbqf31fq4u+tDYCAtlUo1FJiOlcZqU2EKrZAqtIVQ RWdLc7UF7ge9c/WVsJwulZZpNe5l+i5hr2e39xvWQREU2a15JJHpALpbw/mpiosYLuLyEYNPJ5by v+S7Tzg/P/367I8plhX6U43lYPvkndd+xfa+vYu+su7Tz96kOxCWPmOZjReFNoikFxM6r9N/Z58Q cqU89LHWli6Y1C2ZMEyiY8UxoDQvaDqM34FJ8jtaaZfwy+TR8X8dd1BuCPbxqLM6lm35yTBwh1gH dg9jcAsT6S0ktUgWS62SFRL2Z2eVjHfxI1952WqfYEFHhjaWLpmym5lkGAowlkkoQzSRgGYhHMRm wcR6FKGEr7PFpTy++gRX7xOO8gVd8O9GbBCcdcCoEQUjihcG0NOFo/F4HLPniqvnhF8L45Dpd4Rx Vi+WZqR11LPSeusFaVbaAr1Gf1Z3KUPatqWmxzTVsNmmg0lZpThfpK2ChgpZ7Xy6OKiTUeUsWByo TTTgxM4da0xm9aov0tG1kEtj4dmjXT/ScnnHCY1eIfyN+ZzEgQliwM4da98lXX5YMKVqy+6jez7Z 0rmvP8+cXPjUqH72tHvHPbx03W+WbP59bPZdd24e+vKHdp+7BrmqskiQmJ+PvBPnsvXqGWEyas4L 6TDCyn8r/b30Y+mn0wXiDt4gqj5TYx6gg5UhaeXK+LSpaaLim5FG0sDDdMzl4RYLG9GokeTcH3BN F+McQhjCzpqGgXjZQfYnV2JwMlvrVh3be7yxfvuCbt0eW7Zk1TevPu2WeiUGnbZP/WB/Z++IP0oy 49/8nlQf4b7xEko4ErUdgEIrE4sSFYsSFjTaGz2MRwxBK0iWJen/TVnyk6IkWfj2EkZu32aftj9G xul9ffu7K3Z89Md3Vu3MiSIHNYhGuvR4pfSr9+q+HMARezGOX5TS0I1WpzBplV6isXQCbjcWbirQ 4A2MefGy9NK0sWk0zQeSIVEpzBlzrCEadVIbvg1nCTS7yCnGDSQSXD/MkclAkdjM1cf2OEqpq6t5 xFFK/TekzQ/ES4bHaeW/jrNfxE9/Yj98hMv0BMo0BHXic6yWt85HTBOBlypB1I+O+sn19PSUesZ6 FqRVq5Lp94Db5/eglsIt1gsaErUt1xeTdUqqiksuFgSyzezuvUg2t5okDPl4i/1X+1OS/eXXxxOt gmTe828nMqn7+6qn80pIFnEnyEC03qlie9UwsrcVaf+bJi7/plSC1hth/YJrJkuaKVVLYho1fawY zYnupRn+Mv8iuUYW/OBDbxHyeUUVbFFRRes5y4/VcuApxmI9tZaY7WBk0rCtCU8vPK2Qjse+27jq qSfXz6dy4l9sTXz26Q/yflU4e/WKeOMMrr2F9kShp3AromM7lKpoHSFhqVVGqcFam17Vp+TcoFAs iPRhQmnWbcLYrIrg7KDkN0TJyMjyAWiGRrVctG79uYba2qYll+LUDZReQWRhvZptXFTIa3XEMeK7 5n7HAm8+Q6LqQ9/u+9z+6PkNe3sPX2hf3kA+X/bkw6sXzdpur900lHSt/ZpkXkCKP2jtQ42//PT4 qKUsl2xZ99XhLe+icnahVtuiT/pgkJU7W1gqUMMS7pSI2xuVVBdQJHNDQPAZBnySZLdmc3Tw8pQv jjqMq9jIOJHxQZJc+wI9C7PCSK6djOPbVbfiLCmqGxmLvyjl2f760/aaRJi+uXja8URfrkWsoJyc izwe2lsBubfUBwmGAlTqrYoG5cZ3GSdj9YljDmPlwZi8z8OKCgO0N1/+P3mJ/SZ+5aDY4xK/uQtx O8YWYY86cuNCq802Qny9/X0UU1WY6dXBQ4zefiTECkhESuNd875T6neoenKx1xkkDU1AcKD4hvWL YnYJffj9Pz5Jyi7Za14ZuPh1tireKCb+S/o/fFwCx1GbL+O4LlhmqQj+30pnZSrtufo3KyqJkswE SVZUhzIohozfEboFRRQU4pZxuoKkMNlVhrShRJfzZSoDkl6s77SWRLcW/aWqNpaepLrHaos56oaa +AR+RGXFiJLevKKexW3BqUU28R2vIx8ct0fTDPsHG6S8Rg9yrVBiC188SFWxKRu0tgzUvhuoo3oD tSlhwNQ7qm9SPC2zY7RSXI+oi9fGcNZVDopVWoNnuom/n8uV2U9UiaKHgHr76jrJ14v1xfoqXdBB CfbVQyQ/tDhEQ8Ai6AEkCwrAgjKYCdWQLDIR23Ces5xYbdqjm+Fsz0WNRNLLAjxiC5Nw1uRqyU9J 9sW2Lp79dGf53senTNya0e726VszOnSenSf0rz99+vTaTY3fMH+5dT4xgJ6fOfSxKYnSpkjAWRg8 EuawRxjVLXanSBRPVOTJWTHUIcCM5kjwtYyE2p+PhP82ELgkLcOAQiVm4kocn9ebltV1lDxKo0Xu vmape4gZo6MEyTQl1W0CU32gEz3g3J4rYxuZwNKTayrX7tGR62/StVj+p5XnsYo0/36eV5Hnn9y4 8UncwgheaCySb//B/tG+ZP8hfvJQ3cmTdYdO8ljaac915OKoNcTK87OhHsoRnSgc08HbBOlCC0A3 eNoNX5cpmkC9KcH5kwZMYXqYXMP0ndcwPYXo9lzxw/priJ64TDekIJ3CDJQtF2XTMQP3sdplhks8 ozzMNDVVV0I3iAwhz2CecGlgbICiwhSiZLQA0yZRCLpNc54t7NUMpUJuXROWSpHcFJgK/S/3orde Q9SH7AspOCWkB1+hcXxogNX2AbYs5UOq29EXZtN8FAE44+EK8jWX485KX4wvwxWfa2jyn+yUj/ty ipJOTXrUrUuUz4p3aTdrS4x7UNiuX++qXJS4Abvbj/4TwbGx0rJupG5Pa9PduvUQdbxaEZ4brlGX hV3h9FZBRZU0LSi1EiJeP2IUMyNshUSafvG16i9BsL+Wnt1iSak2Ce+pW50/LT9jzTcS81O3PJr4 UYTwGx+o2f3fvDrvuf2fXvqy/tnD771w38NP/2vFg/Zn+7vsmDxpyB3R0rLD8RfzN/YbcdMthbcW LJu6YTfOZgnOZoSoYyz0t7J0nFi+UCwIumy6lWKXFEBi4gXRbRiqLKYWXJoeCIgmV9WKU+ie5L8O xBcGOLCnBUMOcRsRr7m4zb5I9EPkazsSal+yZOF8krH1InXHz56NJ47FBmZ0bYWSvIGStBL6o01v tjo8zkgyK1DMCsxQFPQvTG8RfaS+XWe6y/hEJvJ1mQHjclZyUbE5MaDDIXnDxJAsUXv5hFZ1K761 6+tG3M4zw5WDyNdm0jOJkdXTPqOHUIb+/G45yiDBdOvm5LoYL0vFfsJAOkGYD/OFlbBMWkuV68tR KhCFl6MznWOnIuXl+UyRNRWmTiWXH2v42cK0ZV3a/zCpJHO2292F/o0b2JQrB7FL584KSqXDK9ai aon8pDSl6PKa16UHpUw5rOVCe9qedVbytE7uIujJ+ij9sFAdBiXSAG0iTBBHa9OwRL1bewjmYoG6 QK3S5rsfg2V0OatRlzsFantelnqxLhWuL0ybqtKWXpny1Z8sSP6kJj16aNdq+u47u9nG9X88+A79 FKe2jZ5v/CebceUg69J4DFLYtgTnqMFha11AyHBRkalqgGWKYTWg5bI8sZNaxPqJfdRSNlQcrI5l E8RydSqpYNPECrlSrdAWkLnsf4lz5QXqA1oNWcaeEJfJNeoS7Rs5l7g0l0pVWRBE1VCYwgyKShNk l0BBUTUkQCKjCnEJsqBqTNRUARmLoWQpBfhnD+WwScGNVuSkoLbp5iPHyVq+NfOCc0o0Khu4S5qV G9V556gkRuL2/ZdIF+J/z15FfvmD/aH9Cc2lYXsGWZP4a+JP5Hl7EuphLGbaXzq2nmTdoCJ7kSW3 KgF/ZMOruDQmKz3dg12l7nLXWPdUcZproWuue6XLpbhUSXRLmlygEe1mH8gDDada5btYatU4FHWq huRCnRDl7AvTSTFJ+p6X5DxZNnNK725273oymUx5M/GFteNle2785gfvFbyNn7KuV3qtmoUSrkBL DUEJVZhoRYJEMVF9zBSUoKzyI6Ra+aSAlBFGUnc/eO0SS69tqE0uY+Cp38omoaZkJIwElGMOQcGi eHqHHCZ7rjb2Jr3L+Tq9c/caa4QV9P3EKLY+0Zv+Kc6C8XjjWb4CQSP2CbrTWYFItzwwjLiZaSCv oSAYDkQX8/gv9NFIPLXowGWnEWEI3ZB8cujmn3lyaAU7SCMLFzpPDuFhAvtXINcKWNIIYSS4MfRG gJwlF8hMVqszjGOxxAG+WuLcHw1IciHmP4MmZrgX2iekvMmeP9gn3iKvXN9bjuW3YCQmXbc8ArOH kCVQgffVEDvgVJ6pJ6B6pR6Awr5IR3ZwsvcIf/xpAn/OL/CzbSgsw7YL/gw/kgDpRuaRV6lMK+k2 +h0mshrkXNXC1pZNFMQKcbN4UeogjZG2SF/IptO6yUvlD5WwMhHbcbVMfVytdXldS1LtZVet6y/Y rriuaJO0Hdp37qh7jftzT9SzyPOq55TX8t7ufRdp03D9l/opI9tYYXzs033jffVmmfmC+Q22q/8O zR9Itaj/rv+0/7T/tH/v5jwfTVNPTKdh/uePS2fgxm+vsF5Dbx48auT4YbcMuXXcoNsGji0pG11U mO9rp3foXt561+7S2IS+Izq375TWZfhELeTulmuYdxQHgunhjMyOO/xjWnl79inI62/1vgn+PV8C 7HD2AtfPhcFXr+Ke8D3whwf5+novRJebYTCMgpEwHobBLTAEboVxMAhug4EwFkqgDEZDERRCPvig HbKXDtAdob014tFuKEV2NwH6wgjoDO2hE+q/CwyHiU4F7oZukIuc34Q7oBhRLIjVbxgyIBM6olR+ GAOtsCLuCX2Qg+UhP7egN9zkSIa8AxsgV/cCDJs7ufLuSVkDZtw/e8Z9FXweZDWIoPwPNfCT/12A C1evO5F60l44SpIP2f/kRcohjm0cOQ5HcRsKM2AvvAZnYQbxwovwIWyEteR4y4bz3gtTYAmcgEuo izhsddpJuB2P+8NpbHvgZdTEszg7I9nI71Dr/F/8tQI/X4LF8AT+fyFqeSt+Hsd9DI8rYSeO3AP2 Y/9vYG9uPDsWr0D28+/QuKS8OXqCZKz+f16OOSx4843t++7Qo9+DljTmZt+C1vzzzfv1ZQB2mXBU KsOv7ibz/V8XVvlfCmVuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250TmFtZS9IWEpDRUQrU3ltYm9sL0ZvbnRCQm94WzAgMCA0MTAgNTE4XS9GbGFncyA2 NTU2OAovQXNjZW50IDUxOAovQ2FwSGVpZ2h0IDUxOAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAw Ci9TdGVtViA2MQovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgvYnVsbGV0KS9Gb250RmlsZTMg NjIgMCBSPj4KZW5kb2JqCjYyIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9U eXBlMUMvTGVuZ3RoIDQyND4+c3RyZWFtCnicjZHNalNBFMdnkqigaf0AV7b0uCh+EC64EGm7kopB CDU0lNKdk3vPTQYmM8PMCe0tuHVzxY27iNa3EF/Al0jfIbjqdOfchBqX7s7M//zP73xw1qgxzvmN XjHqG1WFSXjAw1otrNXLMiRhcm2ddb59WQnrTVY262Wz8Tn8uhe+3w1fb4fJHVav/Kf8I/95sH8I PZPTsXDYgl1jCycHQ4JnW1svoF9A1BPoIQINEXKpEHbfdo/e7LXhcXvvANqo0QkF3XFfyRQ6MkXt 8QnkxoFaPCA1OpMkjfYJvPQgwFtMZTThSYq2Elpg0Y2k9zEG6WHghCbMgAxInapxVuHjf240gXUm 6qOoxFJd48mnTlqCSOy+er3okYaCKq6XUQaTx8zMpOMRRv+VRkJqD4QnVHH6CJn0VokicmMp6+S8 hbGXerCkt8DhQLhMoZ/XrbaynA/+mVpYq4q518yz/vIleVR50iOhs1gJFkf00Fku/z+OwhjjPxgj VuO88fDi02p4Fz6c8Yv3YXJ/c3vn0eZ0ezabTn/Pds6fbqxePj+7Xt4sbzH2BymryRgKZW5kc3Ry ZWFtCmVuZG9iagoxOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1FFR01K TytIZWx2ZXRpY2EvRm9udEJCb3hbMCAwIDEwMDAgMTAwMF0vRmxhZ3MgNjU1NjkKL0FzY2VudCAw Ci9DYXBIZWlnaHQgMAovRGVzY2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAwCi9BdmdXaWR0 aCAyNzgKL01heFdpZHRoIDI3OAovTWlzc2luZ1dpZHRoIDI3OAovQ2hhclNldCgvc3BhY2UpL0Zv bnRGaWxlMyA2MyAwIFI+PgplbmRvYmoKNjMgMCBvYmoKPDwvRmlsdGVyL0ZsYXRlRGVjb2RlCi9T dWJ0eXBlL1R5cGUxQy9MZW5ndGggMjM3Pj5zdHJlYW0KeJxjZGBhYmBkZOTySM0pSy3JTE4E8ZR/ SDP+kGH6Icssy+Az5xlvNw9zNw/Lou+NQt9LBb8X8X/PF2BgZmSs6J3lnF9QWZSZnlGioBEaFK6p ra2DEDG0tLRUSKqEySi4pBZnpucpqAEZZak5+QW5qXkl1grOQNU5OZnJCuk5lQUZxQqJKSmpKSBt YYk5qdkKbpk5mQUF+WUKGs6aCkYGBoa6QMLILzM3qbRYITgxr1jBRyEoNb00J7EIRZCBgYFRAYgZ mBgZWdi/r+IDopJFPxbM/+4732cR202ue9w3J/DwPJjCw8vAAAAOilL3CmVuZHN0cmVhbQplbmRv YmoKMjEgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9RVFBKT1orQ2FtYnJp YSxJdGFsaWMvRm9udEJCb3hbLTEzMCAtMjE4IDgxNSA3MDFdL0ZsYWdzIDQKL0FzY2VudCA3MDEK L0NhcEhlaWdodCA3MDEKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTIyCi9N aXNzaW5nV2lkdGggNjU4Ci9Gb250RmlsZTIgNjQgMCBSPj4KZW5kb2JqCjY0IDAgb2JqCjw8L0Zp bHRlci9GbGF0ZURlY29kZQovTGVuZ3RoMSAyMTA2MC9MZW5ndGggOTM3Nj4+c3RyZWFtCnic7XwJ fBvVnf+bebrv+7YsaSxbtmRLsnwpvia27DhxDtuxiWQ7iRTbiXOSkBASCIlpMAkOFEzJQcK2gULC BihjKDRQ/pByLd0SttstlF4LpXSXHrShLW3ZJPL+3khy7BD+tIV++t/9R6P35l3z5r3v756RjSiE kBKNIIw6Fi0OliP+0/wAZFcMrE9tzNSbTkH20sDWLa6KdzrKoPwjhGjXyo2r1m//zYmroXwOIcWs Veu2r8yM1/0eIZ9teCg1+NaJ92FslwIaq4ahQZWSHkdIXQP1guH1W7ZlxsfIIn6x7sqBVKZeq0FI zK1Pbdso+nfldhjfD42uDan1Q9n17SX1jVdu3pKpd/6Kr181tPHJbz3wcxi/AyG8VXgrkiEk7EEa 5Bf2IylCAjOUsx/8dKY8eWbyH0ieKSOU7iK58AASQulsbrToeqTB9ZNn6LeQZvLo5O+Rlm+uI1n6 ejTjk746V5Jkk4AHER1D44iMXYo2okVw7oEUQJ/0ee4TR1zq83/Qk4jjSxPoQXQ/+iJffhhm++q0 UYnseRHqRttQLzoKa1qJktCyCc2dGpWEcWE4ECTZVOsz6F30jwhRv6B+con77+Hv/Bz6EpqPhlCD 8LfC36I7YSVfQu1oN+Bw4fMqn79Bp9AqvrTzoplWoQWQt8GKCF43wio5dDvMuQddjQ5AfQ+6ClD9 MTqF1qEvoCOw/mfRvegGdAc6InqCp9rvhBNISc8CakqACltRU/qN9HOTZ9j48mVL+/t6E/Ge7q4F 89vnzW2b0xprbprNNjbU19XOitZUV1VWRMrDoWBZacBfUuwrKvQWMB63K9+Z57DbrBazyWjQ67Qa tUqpkMukErFIKMA0hQKUhbM0x1vWcNbmJKdgYozGxSkWnlkQ5JDO7ma0rkgwUZodxQn9HNK3c4aO +ARiaxKcyH/xkIUc9mp+64aLF9hdLZzAC19mXmqQ83XF3YzmdftUfwKu4WzNcbfbztFe+M6FLvjO S7kGOU0HtLvtmZa5HOqIk3Ry8u0aaEQ17gTkXXHOmasmEpda5JMgJ6cuWuZCakwzobA2xzhkmECK tzlkJMPO1ACt6jifHxaigRI/GwpylOG3HKXnKOMCWPLMW5DL3qq5BAYtg2uYlsHVgOhg8gKmZzKI ul1jrrGuuDYCRX7R7dzLnfEJuayZaR6SQQPiG9CETA4tctIAU2ycoBQNFF+gFS2zJmgkUQJ8OrLc FpLWcOy+JBSYGOAGPfoLPScnT90yvQvBZbmSPlPKLIITNXPizCJcqzk2xaF9ronAqbFbTmrQiqRf McgMpvrjHE7BgAmEvS3D3ZyjvaMXmuBWkJLDLkLuGJ8R4rlahl1jUCdjk5AzMUL0Ge2Dw0NJwiZU kolBn7Q5vsd9ys7p4NzCaf2cEoYpr33HjsdaLKtdpDo2tsfFHYXlTut1kxyYwAJLH2th4G4wWcua JkKS4BTZeG6cO8gTh92XcnEjK9ZkeC91S47/3WMaTvEHN1AH6ANX8hdmoRxMriFLXpMi22xZ4xrb N8Rv9RZ+a8CvrpY1MZLIhcD9qAeu7o23DDMtF24IG4cC9l58rdvNWf3kwrGxFrLE1CCsPrNk6Liw fiITdj8F62nm2G7+hLp5GsAd2VQskW3KDugll5GeZCyRcGfoDkM5sXePsIxxjZEZxV7O4Ne4X4C+ U6WB9q54S8zO756jm+P171ns70G5vWOqmbLAmLHge/YMRu2LmfbODBcM57Jkd0aA6SnKw9DseH7W 0xb76Uy5P97KtCbHxloZV+tYcix1cnJkBePSMGMTCsXYxpakixd/Ctqf2mfnWm9JcJrkMDWLpxCZ zkV4r7WrndN39hFStbqGUxnF0ci4a+xu7dSYjo/rzsoccD/IAJG5Mc2vYG0K0E52VytRNSdBQ9g5 TQ0RWVhQTxxkYoDnXz4DWVkMk9uJ1OCEt2X14ixYwJlZ5iE6sDPbCpO43USe9p1k0QqocCOd8Uzd hVbYH0Vs0A90TJKeU7keYw/pGcn1TF2eZIBulvbFn8Df03l7TMvoXNEgjz+vege5U92wxz/VcJKa LOn1zXFsp7Ml2o5JSeYHVVbHmf38hQQT0JhjGsb1bYbT+Dlhc/yUvS7h0mhB1VEwps1PJAg06reZ b1JEjyKDhqPqOMpE2hHoVV69Y3MNdE4xkqtlLJnltOnbyhqDweFL7w3GaBjYnj0zXqtjyA5f4dVb Vmt7W4lc2d2ZEfMSnIroZk71Kz6D9dqb4y7QRCC5nXzB1eIaJsTmXMkYrxIS9unNJyffSsaICoQl kyH2LItDnoF2Jq+VBv5cRh8BRr/hlsTwLJiFLYEduCrhtry0dMezKNXYsxJF7jWXbGVm/xSKuTFA fBA8NxeyfdMCjGqzvJe4FOTt3TNq027G99VMaYbuONfqz02eqc/x26dX2y7qnpvrBvVxvf1aYkZo 1DTBUHs7J1hq7+Le+JPg6Lr2dscfpSm6OdmUmCiAvviTLoRYvpUmraSRVFykgtopmO1RWsKPtz/J IjTC9wr4Br4+cJJCfJsk10ahgZN0pk2Ta6OhTZBpY/m2jFfRYhkGCOIMEH2QYzviOxLDY8kEARuZ MgwInM00II5mGiYoWqTgZMxQEydnmkh7I2lvzLSLSLuYaQL2B+FwEVEfSzIg/qCA48hOJQgLE3ah va6Tk5OgQU+D5nVzIm8/JFCwUn/CBVw8D8bNISkJzXO4kYEUWQdhU0x0+dyBBCeZmhCGzOWkMIM0 OwOMaOWvIVYALhoAZk0xfBGaQThGElzCT24aX00mcLnAH2pjZnGiwsycwkJyo2BiTMeU8+ZE5OVk 3j3kJIW1EUXIt9ihCjdLZEASK2DlAwx0DSRdgLYADSwGZhQUkq/MnmkZAqsuKBzik8ye7UQZCZIr ZZy0jNgqMV+Wl8GE8BUnEpnF87U92QFwbw0nhxUVToMyewGgA11zyVrguweWSoZ+g0zTeRJ1MdtA Bsmi+ZnE0M0pvXNToHAy18uhhanJXQxzSfgmMscLmVYx2bmCd2i7T04eZ7a7p31KAwxY5zhhTGQH H5JFibGLG7g+UJySi1uVfPPYmER56QsyeEmUU2dohCEQN4sPp6MISV86nzj/krQTbUHWyYMXwha8 jYzB34NYR4h2IDFIggYFSWxF3zQ5CXSh2M433zKZHd99DbLrdpjs1+2w/ut3oLz1GsjWb4Rs3ZWQ rd1gsq/dsOsq25arDUbHqjWQrVwN2dCwwT40PLrJZt1surbZ6t4OCYzHY0ec7iicWdPdLibqel2h ir7xDOXi5Moo+2IgDF2nHntMr+eHeM7Y86Jnx2l/7E97x/e+f2j80PvCk+9T0gHLwD8NYNeAUk2G PTYn38sPLz7k8Uarv0gd2E/7LQeLS6Lmg5RmfyMb/f5+6r1f0H72FwZzlH3ZYCA3Yfsn4C43jwr9 I7to/w27KP/OXUL/ud20/6ZR7H9jF7Vr1Ju/d5Ty74F0IwzbDUkyKq1GzWxYqonaq42WKqOx0qir MKojRkW5URo2ikJGHDSiMuNsPyWmJEhNCSkRUlGYEkCZomikQo0UBQlDEiIWzqRHCAQTIw0kF5Rd cA5BTwjKISizkN6Eq2SUkl3X3OAuLFL5itTqkpCPLvGrAn61h1EVMGpnvsqVr0ZCjZBWa7QKqUyu EIklCiwQKhBFK0R4MN+JfPlydbualqNaFMNb8IPoh2qRHMmxXF2LaqUJ3Cfdio+gI9K71N9Hiicp FaVmdWo7lae0iG1Ko8as1AkMSvQMpUJBiuxFhW6jVGyhIFBXUuerK6wrqPPUueqcdfY6S52xTlen rpPWiepwHarriHRTnK4dtXc3cXoKzoubuIi//SR2dXHl/nZO2tEXn6CozyeglaP3gvbu5gR7QWF3 Q1zQ2xc/SVlJ9ygwP2DBtSdHb034/XncIPEWRvISXDkp3J6XAL+uvJOzM03+iz+bM/mWq2fU/Zu5 khYu0JLifC1JrpCJ8WMuupTKnKY1oy2kRhq2ZEdnpuMsXCPs7eJ7T0jJJju6mojz284Nguvq7OhL cjamCfxQqFV19IFL04TI45hnILtJ2I18KIBCqAKlWL3BoPKIRCoU8PtDKoslVMEGARvWHkIRTYSO 5Ml9CJX49YZyg1+OI6WlVaFI8LQuGtSZo6eDcERJhoJLT9t+bCPtp7XR4I9f1Ua1EaiEQ1RlRQNd 3YArKwoZj4oWM5VVVZFyJ200QEWFjUazkamktG4tSXS1yFRSYC60q2c3uEIFVmmy7ubm1oEGh7qg LuAqNIp1t1Pnzotw6lwN9Z8mk7ekssgajESZ9i5DQbnzc86yvEhrcWFDfWupO1Dkc4g23HNP+h3B 4bMrBX/8r4dg2wijEkDgWWEPcqJSFEU/AVva3BNnmyp2YmzfxXq9tepoaVmgTBMow2oULS2N4ug4 W2qSlo77QoESUwkuGTexJuOxmAmXhaQhHBqXslLZsZgUWYJ+ZLNoFrzn16KIpXFaxQ99NlLUoShE kOaIZs+pU1odFSWt0eB74ZCdLf1b3CwcSlAmE4GacQMNqvVVQIaianc5aRSJveWELmU04xFjbIqU V5HuQobBu5YOtt/7ncPpZnlhoc1kOmEqq5BTvznweM/RL6Z/Mbyro9HrnLt80ZL2TeMLYwfvXxm5 MvU4/XXvzUtWffna8rDIHmoZwPTgrHAhDjde27/7+Qq/o6Z9ZYu/vdKMz//x/FrB/Ie2ze6tAjtx /eQZwVHhEFDldJYSMr3ejpB8J2tHRPWGVMY20GEaaoTCKkz5RnxCLBxnfQKDBXoMan2+nlZhvXnE rMKqcdasR5ZGsnuCxyvLly2N+i+qhiiCTiRImNPOP6v5G9wjQWGmkOd34HMe2OoIFokYT2FhZUV1 Ve4AQTAJjtYlJX1D3XfeuKJi7VXtG1eEkvUrnxnc8ZW4TGFzl1e1zJ7fem9f3xFhefr969YPfP1s +uzqL99VujaZfsdhWfX8zW2x7oHrhtZ2zY8EK0yAKOHvl4G/w1R5FtFSnVarvk+jQTbGfZ+Hvo+l PGCgi60ymxSOAC5W6ygj1rFSRZvOqiYWrAKKapnMiq3jrCxcIBsPhajwSDh0LBaWYuk4G8ZqN6XC 7oIC77FYgQ3bxtkCXRYUYD/NC4BCtkIwyXEk9Lzkhy/0AhWyUkBFgpEI6Q6+F9ECUYA0kbCdVf49 FkXIViZg3DhLMaaiDIM0uEFMoDZdggQvtySxxmArKkg/ddWzgdry/L7eHonS4PK+PEL5AvXlZeGS VPzczTn5CZXLhT3p022dRXrJ+d9bauvTI9UVVpXo/LNKV6SjK31sSmrqg14cztLxCaBjiGrM0vHK kuLiovt8Pgttu4+1Wi0WNfKEsJvWubFaXZxfHCz+UvEjxc8Wi4pDyKfxuXxHfZxPKMU+j4doDhZ5 AFGPWeYZl4aQVWN1WUest1uFKmwFzjYdi5nd2A3cjSVymfxYTEawyyiXC6ABSAQ3OGWhI6BqXsiQ UwtfIB5BdRohu//eS0tQKiKEJrN4hgr8CKVphqG2iSUigy8sTw9NU3z4ppakQGUktH7lmq8HZpV7 +1JxoZ4pe4FinCX15nxGIwjP1Hrp03M6fUDptyyN89O9Da0OeYai+Me85dmXpWiR/T7W4XCJDEYs VCuUimMxJUYOSokdTqcRG8edrBMdizn57WYVfI6RyfZDvC3R8VYEkHb8NVMkMphkQQGDLAZIwGAD u1dmIJApgHmp2+WFbrvd+Pofmhe0NHlSQ+ceze24rMdJWDYsMfh6kufCtpat8fQ1JE4Av0G0B/Zb j36Q3e9ClzvfXefOd9bXG8slYqlIajWbkNEmktrAEWgsJy8ZCt1wVODyemc+K9W15eeX0tSs2tpZ x2JWdy1WabR+QWlZadmxWGmGC3TIHLU0RiK8vYvqomAYI5Ep9ZI1s+YIX54yuxHgVKgAaMynu0+C ymAmEgGLTXFYNSMSiSkGY0Z0cVcWaL1wPlWbgfRBpaS0Up7emOG4UZtPlRetSUfXJ+2GwsKkVkY6 75VPp8XQVcKeLNx/qm1xlHpz7Ef3XbO3amDpeS39a0p59ivp+fPnuS70Ytq/0EdIda4qQx3hnUCd KnQsS51okUJSUlbqD/pFYn9QUFJSk6dWKTRyOPJxnlxR4hdYqMoq7C0sBA1biE0Si9ViPRaz5ACK RnNAgW8YmnJ0ciTIqnst0QqOv3i6BMUDzVCFRYyI/hhYKZM5UqWbqgvvzED8y73pH1X6lKIqZ1yq +CiejZQkmi+XRC2tYjWvqDPgnn0N9x6+K5L+yc3pTSULCy4F5AcPbKmnHGuoWndvIa+3abRj8jeC 74FHo0N+tCyLrFWwU68vde9kldICXDDOSvWIyCZ5SJH1JDInghmcifIEjDSfMDhB8W4cTQsyfoWu gaY04MqJcgfvemQ8Ddyy4/HUmm+m07fe8rUr5u565A1q4ZtVoZpINDzLX2q3bdrY2znYcUXQIRxK vnD7kfT16Z/dvO4bu3dRtelH+9NbqXKdyR+e37t5277RdXffVd18xz+8PQp7JTbqVuAhBmKJr2X3 WiHcyRYXlztCckVQocgLYodcmt2IlDEFS5lSXDrOsIznWIzBBrPJDM7tBX0+zY/VEhmzZcqhj3jN RHQ/i4kBRBKLEN+sCF/KUFCgDXmvGHxk+ufX3DUQ/vzvTqyMsVKx8COWgqK2719eUbehpyG2V9jj XbB14YEfDQvSPygORAyXsBLn55Svvv2KnhXF+Py9gGb35Pv43/FpZEcRdE8WzWC+UoHkDho7sFxe Wbyb1QONkcfqwZ79rFWjVAQ0ARw4yGpMMunxmMzIq/kMf8DuIlMl0FwZx1c3pQwBQedfP1mCqjZf kMEi3reFSA+Mhwnz0gfOryDn+8IXN/Wzd6lkZbOl6bcblcmHkhu2BxI7vpxs2OiQipoWlMxfOGeW K9qc39xVEazW4X1NmvOJutnGYq8wfFZwy+eOHUh+4+EbF+alJ4rrmIVz7I0r7zi+aHiVo31u8+4E YLdg8gx+Q3gAsAujU1nsCg27gRMjtEOlRAqwvQpMKyh+Z0ilDGj5rWo1EGW8xWqlyjbksfFA2EyU iSZ7b8zt1z8dA4LIBfMyjR0Nn9XkiWpxEZXVYGCHzXyYADEcZjwZxMFAC3Lh9M/7WQqLtJEmxflZ nDJ1omf99trVN9y2aFQtE7Z0VFyxoDFkrZ0dWnpVmzU8WyO4xrosr8RDV0jPxwSf23Ls4LofcJtq qHWljY5Frb4FG249OHt4uP7WOzcT+71k8jd4O34FudC3sojO1mrzJeh+lys/X3Iji8yUAptdjhGH AAv2sw6NlvV427QuteZKzS7NbRqBGrJJDdaDo2xQYuVB1mCaUmGa74ILsslmPe2/EEudBlwz/htx I3knEnAt+0zvkKBIuCsCQXfSwJvV5izn6niUzWL6TdoY9A/ds1LtrQ/2jc6rX/bshvEDHYdfvbrj mrIw/cr8mOee9Pf3lsyrym+ZVz+cfOi+tRR6LqlTvA1c2AVc+DmQYAdoxtezmDU4EDJpRwsKAqYb WakhD+cdYNWGfAOdhw0GlUBVhIv2syoNYl3eNoDaccZBy7FDIIA45yAruGg7F3ZD7OOUtzvNbmij vNcd/hvdKOFVAXxlNHmow3OlwJ3hyKpqb4OQZ0qRCJfN27u3a9FV7QUL7v7Bddu3p7+RfknRtbT/ QFe6pH/fYFOROlrTumfVP3Uu80US17Wt/eD5tSuGT5yoa129vGPxOUrvLquud9e3DD0IXJj+XXo2 fkB4N/grOUTd4DA47HaVSKTyeVEBUqtMyFSAVWrt8Zja92uv2kEe9QKjkDNrtzraHCSMdLhYqwu7 QNNRAggYD7ECx0yDmgkL/f7GBedf8Gcszp5TuRgVIpsXIQG0ss/2PgkzQbSo2sS73XqGmB7Ci2Yx /wQBHElxRMykPdec2B5gzJayyuZoxPyt7Yqwz2rQV/74wRVziuKq0kC0I2qx/sz0H9qjT3fJ4hJH 4/YBPBoRavMqZ3/1cc2JaHnD9avXDyF68jbA823g0SBqQr/KIjonr8BZ4FAq5JXOgkowNDG9YDQQ YMHaFLqkmrZCZwlyBYOaEmeexhG1RnE0Yy5CGgjeiLkoEWPxfrbkon1ebDOIPANfwSnHsFkhzxik jD9e9re6I8E5ozvpmebKTAyZmPeYgBKuygpg5fLc80piwlbqbfJ16wdu7G8pUKWOJddvnzW8+45F jRuj/eywXGELOjxl/q1HVqdvirVTqyJDm9nSnD2ru8JcWpLX3tI6/tqjePTa+w5d+cZXNtc4C5o0 aX954+5fJVa1NPaU/aimP7K79dDYq/MvGDaifxeAzXoSbFoA3ZZ7kiP0eTBFlantCqXKplJpbFiN AsCNyKiwS/IlWHKQzddYzMdjFmSjiJWZiUzE/1GvHDC3/YVzJNxufc7G08Ql5z2kGcYq65+bzPj+ 9Es7VcZQtHhgw2x938MUJZcKeGv1kGLZiXhq0NAtkxj9Qepc9aaytvrYvl3x9CLBNeWlheqMnWoX XH/V2tVsb/puf4U+36MVgp5dghAdEsYQRhZ0IItNyEIJkEBFQ/iLBVhJD7AbMaXGb2JajZdjWoqx 5QS4y8djJrVCfjymyHk3ROMt+BlRcJuW2t7jLfueTKQIyHj+2mkgWmGqcxiIs3DxENGhsomyVrnI UBKSpv/5oFKmBS/y97XC2HPPnX0iEtQ4PTphmL53Vos5z6WhK6VZTqArgBOMaF52t3qKVmDwN42G 4zEjmuGuTTkosH7Vx49IUBFqan0ZChJv98Pa9Dl+cZL0yxQtkwhMxZUK4YGzg6Gwll+aYEcg4COv hHAF8REginwTfIQm9Ex2ZY0u7EZwFGKPJyRVWMD4xEJ1wdpgsKIWh3BdPbaLilm2GBcfZFnNrBPR aM3xWFQd8uj1uuMxvTHrsUdykDbaMjYoai6fYt4s6+pyUSWh1KebOQE4iS/w7gyyZbn8EpXpPI+f pZY81L98wNCt5UlLuL68qii1ptnQ9/BmozpS5Uutm63re/iQUKstDiveqWlS9D+xNDlI/0kllly3 NcPjbSU8yFlpYG+8YWm6nTq3NOFqq5+9d3dvehH9oLnX6chX40pp+rzg5tH1KEMF/DxQIYD2Z6lQ 5hPO0BR60BQUkXLKaDth4aVbPU3c0UVOKEHnY5SF/S+f5mJ98VHwyMuILOr4kfSLuxTmcEVJas1c wxRcP402K1Y80ZcaVEp4gKlz4a3BOQ2zbxhdPhOUc4Kx0bWrC3rcOTBBXywGT/YpwMeAPBdicvVu h6PAuJsFJYIt+1lkkufj/P2sXIP+bzH5JwxOCD2ZJ/y8e0SYSUVTvH+kyzhHNHXXkQfVeqb01q+t 3vyFJmvB2LfTb/b1rzgU704MH0lov/Llus7VnUNfWBA/OJAYuvPVtVThhtUcVb9t3fqvpJ8G+/2n dBd+B/biQTXo69m91Nh2s6HQLKmhusCD9AjJ9FgqER+PSeweV7ELBGI/6zJVGyLmCI4cZM0a/Qmt VnM8plWjGbJwwXoSn69xOv2nBzrez2LqhHmacrzADbqpUKdI/5FY53WZkFdM3zqvz7HEk1/LxTvx eTJhc1fkigUNYWstGxnY2qSfCFVkdVa8u26KPSh1NuyZRZVX1tgXzvHNX3fbwabVq1oO3ZnMSdNO QNiBvprjFdn9rFQqkRh0tJ6Cw4wN6IRDg5XKk5Pvsg6DuQ1JNVLagKWiERHEIaxI47AfjznUBuOU AT2dCUDIY2ptJAK4zHwFErQBtE98BrOCXhebpzmQWYnLqvfP17Uqlj+enBsOrZJ4CopWrqlUgYgZ db6QHL/4B8HunfK3Kqo6btnaRoRqWZgHDTCZnITIRsdrmH/JxYLm+4G/jV50fyDg96tuyssrE9/k dcvlNowCycDGwEhAoMCBYtDHGO9nizVqU76J1mGTTmfDtv2sblrEMfVqJrcZ8Ni05IFFRu7K+WiQ jwmB/QKf6T0SVMbL5nmRfytKXMOi6oiJCC2PGol2MoDSd8o7e4LzA845bGph790r4ne1BReK+5Yk Bp1sbeNCf9fBoft3ltH/1tvJNJd665v8s6/tWLabtRne6O9LzPXHGnz++X3Vi69l/a8Cn+0ETFWC x5Bz6olFg9ButNMf2CkIGfV6iVFn0po0EqlUa8IStRaiba2OlYLXITX+mtWpEQmGkcuJsR3bD7J4 egiXi98gwsjtl5oRzwCuaOkm8uKZ+dQzQ1SYdaiz8UtE7Ba7cS4wpL/cdbR3zbBux355bUvQ5xyr pupN6eeSvspI2VDdyYGhdasaF9IQ5XjrVyz741B6x70d9Y1z2gChUUDoffw0RNNXZxEqsCotKpVa jy2WACUswC4VQiXHY0hts0okeUDB4zFzzs2JgERAQWN5gRe1XKBBHtX8eVcl9O6pBy4QmkU++ryr Kveo+S6qdpfKGK7wD27kbbxIE2Tl6bdZZerx/tSgXNYtE4ca8NNpXHNl2ZyG5lt3LqEePd9jjztK GEH4LG+ynJ0BaiBQoSstID/amfweaKFHYe9+9GwuSqPdArlNpkVaj1tgtcnMRWYaSm45lG0CmQly MyoqKtWaabnVIzCi4hKc73LlH4+51BKpGRsNvC9onPY6Y8bTeoIQJJAK/uXIqUySnJJkc/6B4V8+ c4ISic1ODOoI8+EU4FdUVV1UhkHI9CTOIi/jHn3uu0u9gYKCIvmH+yyL5jmleYw8/VP9D7+7PK/A 7ffJPxwNxwtUrJzKw/v+5Z9/GF/s1YKXdIexvaei0GBzisLhX770ZmxOkRGH03tKkzUBS7WEvEUl f4D0AXoXIgXtExSNuBFKhxp5Nz8SrgYX/YPIM5F3330XRl5BvYKfpTtgZB6rxhRNYURraPoMDUUU PL10E28Og2HKDcu999xX8/B86pUbib24Eih1hXAI5aNNWUo5rTabzu5AOgdWm+y2kNUqsYtFUokU S7/ESixoWoxKItRv6qL8+1P+9SkRSf2fdxH5dYdo6om1oDrnZInERWAERGI6pStJrVSfb1B391Z7 bIqjUqnTaFuzuog625Kn0VHuLsZXpMVz5wpUFk9NDf1aSbnGaY00dFDSq9ke4MEPYGe/hZ35p94R Ba1pm00vE90vFnvGWL2+1C8rViqRyeYccZqw6TDrFIslIzIkARzvmrFqoisu6N+cgs++vYxmHgQQ 9Z73KeZLeHNv6slD52o+qCFwMJmfWvBuZuagW7zFNodZt3TeuTOyWV8/elOkL+lbHu/a7bvBv+kb yRW3zXV5SpYsfOy/UkclaqevKP2j0PA7h3ZV9t+0pa67b0XvqVL/7M0ts9dWsolFR9/aDVygnzwj oAGrcvRG7jdFSmlhYaA8jVDA6tmn1UrHAoEKqz1tY21WZWFRUSEuPMwWCUxFh0MhJBgRBHHwMCsQ W22mEZMTOw+zJuu0J0ano9MeHk37iQ8vuTZN9p17Dkjy+6wooFn0Gd4oQVXnfrpFnkplf1d0wVjy zMfkfuolElOS4o1Pr5y9ZUmk7Z591I4b23Y/M9L/neayzaINawY/v2jfvkH99qe2hFf0JHcEBAtO BYudDanm/tu2VcnzDm1Y/MDW+mLnd1cm4yfWrlsXl7Rt2NHY1b9sGXjz44C0E5B2oWp0IvdkxOV2 iPf5fFH3eVaXX5CHSjAcR1iMCxx5dnsezjvC2sXKAlxwmFVaZzrtZHPTXgkBfhd8/vMv8a8r3Z9+ ygSV40Hi3RKfgufQgmqzWITE2JBFkH/iN3VQOxfeubD75k5m/tYvDfaOxgMKrav44OuUYNwrO5P+ x0TTlesXfW7ui57ZzU6XRiWTiUQSMf3tUHDugXVzvnBDqmb25sO9HYs2LNn0r8fX66vD2vRPz6a/ MD6+6qmrf6N0GIwalU5vtrKRzA93b8gdVBv1PvU+/Rp+5sIhqBIKhROiItGr/7sP8TqJSfKI5BFp QkbJXpcPyH9IDoVP8UvldcqfqO5Q3aF2qF/SLNG8Rg7ttsvH5eP/sePWT3GcuHxcPv5/OHRm3cP6 FeQwKP8nHmCvafJ3NvAxgG9MPiuQCC3k/0LHg6+h3kF6tBsdQGPQK0W3Ix06CP3jaBTtQXfibWgv 3gFe9WF0G7oDfZ6mkRrtQzcjLboR7cfbkQYJIXYa5P9mQEDuc8YzOQk5RfJMXPWZ3APxs+lgLzSU RAgC8+bU+hVXrU4F5m5JrVs9QO5N3Q4jJZf4XwuX+lw07gw6MzmjIYMZEsbQM7lEPQ/NkAQvohJB J7qeT7dAufpjUhCViK5APuEy5BN8iHYINkHb5fQ/N1WiboEfLcDXoCV8egB10UvSvxeUTd4uaEAL aD9aMpU8aIFoEC0RtEFSocWC6skPScJNcB1wL/082gl9o7mED02+cTldTpfT5XQ5fXyiDiHB3yOB I3PF5XQ5XU6X0+X0vyTNQldO/gFiU3KQ/7iHPyFmJDEhRd82wT3y1HJ13QdIngkin/yPQ/XkfOpD xazziXSDtFN8GOJUKR+rwue/AVNNek0KZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvWUJXQkpEK0NhbGlicmkvRm9udEJCb3hbLTIgLTE3OCA1 NjEgNjgwXS9GbGFncyA0Ci9Bc2NlbnQgNjgwCi9DYXBIZWlnaHQgNjgwCi9EZXNjZW50IC0xNzgK L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDg0Ci9NaXNzaW5nV2lkdGggNTA2Ci9Gb250RmlsZTIgNjUg MCBSPj4KZW5kb2JqCjY1IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovTGVuZ3RoMSAyNjIy OC9MZW5ndGggMTA1MzM+PnN0cmVhbQp4nO19CXxU1dn+OXNn32cyM1kmyUwymUlCNshCFiAZskEI AUIYTAKBhLALAgFkR9S6RakLat1Fq6KiMBm24IoWtdWiVq22tbXa1latKO5rku8599zDVmu/r//2 9339/5ibZ57nvPecM/e855z3vneCkVBCiIVsIRKZMrmloJDIr+m17K17addyXo5cgbebus9d5d+9 7cBX0L8lRGOcv3zB0s8/bzJDv0OIIWnBknXzef2iaYQk9iyc1zX3D5nuKkLmj4Zx5EIYLLtM0DY1 yhkLl65aq3zeLbBtXrKsu4uXJ/6UEP3hpV1rl2dRyYJzWTD6z+laOk+pz8qJy5etXMXL85PZ+eU9 85YPvffnN1F/PLo3EaK7jZDBbeTk1xSymKzEeLeQi8lWso08Tl4nc8iFUDeS7eQech+JkifIz8hr 5F/4GlynWUrM0gGiJXGEDH09dHTwHqBfYz3Jsg2lOLX/hGXIPvTBabYPBrcN2Qf7tU5ilNtaVC/B +gkdGPpaVcXKQyNZWXUJtE1u8ZHutsHdgztO80EzaSczyEzSQTpJF8Y/lywki+CZs8kSspScI5fO wbkFeJ+P0mzU6kYtpk/UWkaWAz1kFVlNzsWxHHqlUmLnVsjl1WQNjrVkHVlPNpCNZJPyvka2bMSZ 9XJ5LbCZnIeZOZ9cICvB3HIh+QG5CLN2CbmUXPa9pcuOq15yObkC8/xDcuXf1VtPKV2F42pyDdbD teQ6cj25AeviZnLLadYfyfabyG3kdqwZdu46WG6XFTv7CHma7CO7yG6yX/ZlN7zGPSL8Ml/24XL4 YCNGeOFJV8z9t+a4tzZj7GxsvcpI18J+wUktzlX8yGpeiJq8Fz4PrJdNp3niKoyB6xMj4qXr5PGf sJ7sle+zCn/ccpJnbpZLTJ1u/Xv6enIrduAdeGdeZepOaK5ul/XJ9tuO190ul39M7iJ3Yy52yEow t9wDvYPci719P9lJHsBxQp+sOO8iD8ozFyV9JEb2kL2Yyf3kAOmX7d937rvsexR77LjlIHmIPIwV 8hg5hEjzJA5heRS2xxXrYdnGy0+Sn6DMavHS0+QZRKhnyXPk5+QF8hRKz8vvP0XpRfISeZm8Ri1Q vyDv4n0AIOFxc2fP6pg5o72tNTKtZWrzlMmTmiY2TmgYP66+rramemy4qnLM6FEV5WWlI0sK8vNy s0LBjEC6L8HlsNssJqNBr9Nq1JKKkty6QH2nPxrqjKpDgfHj81g50AVD10mGzqgfpvpT60T9nXI1 /6k1w6g5/7SaYV4zfLwmtftHk9F5uf66gD96pDbg76ftza3QW2sDbf7oUVk3yVodkgsWFNLS0MJf l7Cw1h+lnf66aP25C3vrOmvRX5/JWBOomWfMyyV9RhOkCSqaFVjeR7MqqSxUWXUVfSqit7CPjUrB uq650SnNrXW13rS0NtlGauS+otqaqE7uy7+IXTO53N+Xe6j3in47mdOZY54bmNs1szUqdaFRr1TX 23tJ1JETzQ7URrPX/ykBQ54XzQ3U1kVzAuiscerxD6BRTdAe8Pd+RnDxgaPvn2rpUizaoP0zwiQb 4nE34bzQBNeGK8T40tLYtVzeHyZzUIhuaW7lZT+Z442RcEFOW1TVyc4cEmfcEXZmizhzvHlnII1N VV2n8nPuwoToljn+vFx4X/4J4gfn/VEp1DmneyHjrnm9gdpa7rdprdFwLUS4SxlrXd/wAtTv6sQg FjE3NLdGCwLLo65ANa8Ag5/NwaKWVrmJ0izqqomSzm6lVbSgrpZdl7+ut7OWXyDrK9DcepAUDb3Z V+z37ikixaSNXUfUU4NJCdX1ts6dH/V1eudifc73t3rTouE2uK8t0Dqvjc1SwB7NfhMflyZ/otwK YzuttqjMRq4L6v2tKq/UxmYLBn893gLVo3HCjumSi2xGq0f7W6mXiGr4FKUGU6f0g4IUrBnPTkms ac14b1pbGn99zyV5lWvSBKP6k/qyw3D8mvjn/N1L47XZBWX76+bVnnSBp3SqUS5Q6e27r1PFfKF8 MFro2XSOF6ekIHYubCp0I5vYLCb4o2SKvzUwL9AWwBoKT2llY2O+lue3sSXQ2NzeKs+2skqmnVLi 58t4KUrScFoUVDVYg/U5XjGtcnmcXD5eHH/a6QZx2t+rDzS29LLOA0qHxI8dhEFrQw1dl5c5i7E1 6xHdAvVdAb/dX9/b1T+0ZU5vXzjcu7yuc2EF6yPQMLc30NI62itf69TWTd717KOcpJE2TqvOy0Xs qe4L0Eub+8L00pb21oN25LiXTmuNqaiqprO6rS8D51oP+hHcZauKWZmRFfyswHqaioJeru89GCZk i3xWLRvkcnc/JbJNL2yUdPeruM0ubCrY1NwWlm3shUlKWAgXI9zW+eey6dnYtrC3s41tLuLBVOKH RmmgkkRVgco+qtKao8bAvOqoKVDN7FXMXsXtWmbXYWFQD4VzWEzq7QwgTmFBtRIv5UtRYl36+4eG prWmHfEebUvDUpsJtLdGDTmI/ZrgBNQbx9AJ87jolu4udh0k0sra6oIN3W1YtqJDVGmIGtCDQekB NerlNmw5olE35gYTKLffgkJ0S1u0LYd9aOuiNnk526NkfKAC08771ITYBxW09ToDhfLexFYwBi9h ZMC1kZZWbvGiiA9r407SmXHl3QGc6u70w9tq0t2Cpc5jqdHLLfMQEtWheTKMXuUkYcOSgiaLMWrI R4f4YdqUz7akJqhra+MXL5cuUSrgs+1RE64odJIrlQbwDk41sGvBzyW4VFb1CdZNcz+ZGliLyMIu Wu5Jh9NRS7ChC8GftzfBEigTjfUsRpiUPg5zq46N3Ay/S8Fp/UM7AuvSTnrl5QbYzYEtTOI9iIVN 2npPN0Rn5OTl6k+3WmRzb6/e8t0NuL/0luPMjP463DVQEc/AWjJI6GHjpG9HDF5h2M8sJ7+k55hF 3YUsT4cMUYf9YCcFBE+jgYShIcwOjRkkf7/qB3sNCXQCxIVCXCDE+UJsEeI8ITYLsUmIjUJsEGK9 EOuEWCvEGiHOFWK1EKuEWCnECiGWC7FMiHOEWCrEEiHOFmKxEIuEWCjEAiHmCzFPiLlCdAsxR4gu ITqFmC3ELCE6hJgpxAwh2oVoE6JViLOEmC5ERIhpQrQIMVWIZiGmCDFZiElCNAkxUYhGISYI0SDE eCHGCVEvRJ0QtULUCFEtxFghwkJUCVEpxBghRgsxSogKIcqFKBOiVIiRQpQIUSxEkRCFQowQYrgQ BULkC5EnRK4QOUIMEyJbiCwhMoUICREUIkOIgBDpQqQJ4RfCJ0SqEClCJAvhFSJJiEQhEoSIF8Ij hFsIlxBxQjiFcAhhF8ImhFUIixBmIUxCGIUwCKEXQieEVgiNEGohJCFUQlAhiCLokBCDQgwI8a0Q 3wjxtRBfCfGlEF8I8bkQnwnxqRCfCPGxEB8JcUyID4X4QIijQrwvxF+FeE+Id4V4R4i/CPFnId4W 4k9C/FGIPwjxlhBvCvF7Id4Q4ndC/FaI14X4jRC/FuJXQrwmxKtC/FKIV4R4WYiXhPiFEC8K8YIQ zwtxRIifC/GcEM8K8TMhfirEM0I8LcRTQhwW4idCPCnEE0IcEuJxIR4T4lEhHhHiYSEeEuKgEP1C HBBivxD7hNgrxB4hYkL0CREVYrcQu4R4UIgHhNgpxP1C3CfEvULsEOIeIe4W4i4hfizEnULcIcR2 IW4X4jYhbhXiFiFuFuImIW4U4gYhfiTE9UJcJ8S1QmwT4hohrhbiKiGuFOKHQmwV4gohLheiV4jL hLhUiEuEuFiIi4QQaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8VaQ8V aQ8VaQ8VaQ/tEULkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1Tk P1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1TkP1SkPVSkPVSk PVRkO1RkO1RkO1RkO1RkO1RkO1RkO1RkO1RkO7RmDxPImmOplT7kzLFUN+gCXjo/lloB2sJL53Ha HEs1gzbx0kZOGzit57QuljIWtDaWUgNaw+lcTqv5uVW8tJJTDzeuiKVUg5ZzWsbpHF5lKaclnM6O JdeBFnNaxGkhpwWc5seSa0HzeGkup25Oczh1cerkNJvTLN6ug5dmcprBqZ1TG6dWTmdxms4pwmka pxZOUzk1c5rCaTKnSZyaOE3k1MhpQszbAGrgND7mnQAax6k+5m0E1cW8E0G1nGo4VfNzY3m7MKcq 3q6S0xhOo3nNUZwqePNyTmWcSjmN5FTCOyvmVMR7KeQ0gtNw3lkBp3zeLo9TLqccTsM4ZXPK4pTJ uw5xCvI+MzgFOKXzrtM4+Xk7H6dUTimckjl5OSXFkiaBEjklxJImg+I5ebjRzcnFjXGcnJwc/Jyd k40brZwsnMz8nImTkZOBn9Nz0nHSxhKngDSxxGaQmpPEjSpeopyITHSI06BchQ7w0recvuH0NT/3 FS99yekLTp9z+iyWMA30aSyhBfQJL33M6SNOx/i5D3npA05HOb3Pz/2V03vc+C6ndzj9hdOfeZW3 eelPvPRHXvoDp7c4vcnP/Z7TG9z4O06/5fQ6p9/wKr/mpV9xei0Wfxbo1Vj8dNAvOb3CjS9zeonT Lzi9yKu8wOl5bjzC6eecnuP0LK/yM04/5cZnOD3N6SlOhzn9hNd8kpee4HSI0+P83GOcHuXGRzg9 zOkhTgc59fOaB3hpP6d9nPZy2hPzVIFiMc8MUB+nKKfdnHZxepDTA5x2cro/5kG8pvfxXu7ltIOf u4fT3Zzu4vRjTndyuoPTdk63885u473cyukWfu5mTjdxupHTDbzBj3jpek7XcbqWn9vGe7mG09X8 3FWcruT0Q05bOV3Ba17OS72cLuN0KadLOF0cc3eBLoq554B+wOnCmHs+6AJO58fcEdCWmBvBmJ4X c48Ebea0iTffyNtt4LQ+5p4LWsebr+W0htO5nFZzWsVpJe+6hzdfwWl5zN0NWsY7O4fXXMppCaez OS3mtIi3W8hpAb+y+bz5PE5zec1uTnM4dXHq5DSb0yw+6A5+ZTM5zeCDbuddt/EPauV0Fr/c6fyD IryXaZxaOE3l1BxzhUFTYi72CZNjLra8J8VcF4KaYq480ERepZHThJgLeQFt4KXxnMZxY33MtRlU F3NdAqqNuc4D1cRcW0DVMWc9aCynMKcqTpUxJ+7vdAwvjY452kCjOFXEHGxplHMqiznGgUpjjlbQ yJijHVTCzxVzKoo5ckGFvOaImIMNbHjMwfZmAad83jyPf0Iupxze2TBO2byzLE6ZnEKcgjEH81IG pwDvM533mcY78/NefJxSebsUTsmcvJySOCXG7B2ghJh9Fig+Zp8N8nByc3JxiuPk5A0cvIGdG22c rJwsnMy8ponXNHKjgZOek46TltfU8JpqbpQ4qThRTiQ8ZJvjYxi0dfsGbHN930J/A3wNfAXbl7B9 AXwOfAZ8CvsnwMc49xHKx4APgQ+Ao7C/D/wV595D+V3gHeAvwJ+tC3xvWxf6/gT8EfgD8BZsb4J/ D7wB/A7l34JfB34D/Br4leVs32uWEb5Xwb+0LPG9Ygn5XgZegv6FJcf3IvAC8DzOH4Ht55alvueg n4X+GfRPLYt9z1gW+Z62LPQ9ZVngO4y2P0F/TwJPAOGhQ3h/HHgMeNS8wveIucf3sHml7yHzKt9B oB84APt+YB/O7cW5PbDFgD4gCuw2rfPtMq33PWja6HvAtMm307TZdz9wH3AvsAO4B7jblOe7C/xj 4E60uQO83XS273bo26BvBW6Bvhl93YS+bkRfN8D2I+B64DrgWmAbcA3aXY3+rjJO8l1pnOz7oXGB b6vxbt8Vxh2+i6Sg7wdSme9CWua7ILIlcv7OLZHzIpsim3duipg2UdMm76bGTRs27dz0+qZwk9a4 MbI+smHn+si6yJrI2p1rIufuXB1Rr3atXrVa+nQ13bma1q6mw1dTFVltX+1fLZlXRXoiK3f2REjP lJ4tPdEe9ahoz5s9KtJDjf1Dh/b0eFPrweGNPRZ7/YrIssjyncsi58xfGlmMy1pUtiCycOeCyPyy uZF5O+dGusvmRLrKOiOzyzois3Z2RGaWtUdm7GyPtJW1Rs5C/ell0yKRndMiLWXNkak7myOTyyZF JsHeVNYYmbizMTKhbHykYef4yLiy+kgdhkyS7cn+ZMnOLmBSMq6EeGn1cG/Y+6b3mFdNvFHvIa/k tCX5klTZtkRaMzmRLks8L/HKRMmW8EKCKpyQnVtvi38h/vfxH8ar48Lx2fn1xGP3+D2Sm43N0zSt XuaqWs4jSuSxNnkCoXqbm9rcPreqzuemxPGm45hDcj9uf8GustmozTZkU4VtqG6z+qwq9jZklcLW EaX1NovPomJvQxbJE7bAwnrMNE+ZVm8z+UyqSJVpskkVNlXV1IdNecPriUT9lBJqB0l61N1L3b56 6RHKfo2jIZRe1TetJSensV9PpjZG9VNmROml0WALew83t0e1l0ZJpH1Gax+lP2zro6qaaVEX+2Wv XL5o61aSUt0YTWlpjUnbt6dUtzVGtzAdDst6iGmCKm05s1auXpmTs2oW3matXJUj/6BEV7NSDjOy n5WrUGbHarlMcr73xauBZq/Ea5ViW/X9jf6vv+j/9gX857/6CPs3CmOHVD8gc1UXAhcA5wNbgPOA zcAmYCOwAVgPrAPWAmuAc4HVwCpgJbACWA4sA84BlgJLgLOBxcAiYCGwAJgPzAPmAt3AHKAL6ARm A7OADmAmMANoB9qAVuAsYDoQAaYBLcBUoBmYAkwGJgFNwESgEZgANADjgXFAPVAH1AI1QDUwFggD VUAlMAYYDYwCKoByoAwoBUYCJUAxUAQUAiOA4UABkA/kAblADjAMyAaygEwgBASBDCAApANpgB/w AalACpAMeIEkIBFIAOIBD+AGXEAc4AQcgB2wAVbAApgBE2AEDIAe0AFaQAOoxw7hXQJUAAUImUth o4PAAPAt8A3wNfAV8CXwBfA58BnwKfAJ8DHwEXAM+BD4ADgKvA/8FXgPeBd4B/gL8GfgbeBPwB+B PwBvAW8CvwfeAH4H/BZ4HfgN8GvgV8BrwKvAL4FXgJeBl4BfAC8CLwDPA0eAnwPPAc8CPwN+CjwD PA08BRwGfgI8CTwBHAIeBx4DHgUeAR4GHgIOAv3AAWA/sA/YC+wBYkAfEAV2A7uAB4EHgJ3A/cB9 wL3ADuAe4G7gLuDHwJ3AHcB24HbgNuBW4BbgZuAm4EbgBuBHwPXAdcC1wDbgGuBq4CrgSuCHwFbg CuByoBe4DLgUuAS4GLiIzB27hWL/U+x/iv1Psf8p9j/F/qfY/xT7n2L/U+x/iv1Psf8p9j/F/qfY /xT7n2L/U+x/2gMgBlDEAIoYQBEDKGIARQygiAEUMYAiBlDEAIoYQBEDKGIARQygiAEUMYAiBlDE AIoYQBEDKGIARQygiAEUMYAiBlDEAIoYQBEDKGIARQygiAEUMYBi/1Psf4r9T7H3KfY+xd6n2PsU e59i71PsfYq9T7H3Kfb+/3Yc/g9/tf1vX8B/+Cth9iyWYZLBldJLGiuRiI6UkyYyicx4hFiwpj2k gu7b566t1efpHsN6VRE/VrweKWlN2KZWWQ4kJVUFDpRot0qOBjy4763SbUUsrxp4Y+D5goE3jjrL C47Sgt+99cZb9o+ed5QXFL31ylsjhlNHmkOGy6rS6VzaQHq+qiQzNLKoqLBSVVIcCqRbVbKteGRp pVRUmKqSXMJSqWJlKr30bbs0eUCr2hyoml6kSU2yuSxajSo5wZk3OmhvmREcnZ+ik3RaSaPXZZVW pzcuqUv/jc6R4vakOPV6Z4rHneLQDbyusX79scb6TY16yTfXStpRM6sypBuMepVaq+1PTUgcNiqt Ybotzq42xdkdHr3O6TBn1c4cuNidzPpIdrt5XwNNcEtg6Gv1Zo2LpJMQufUgyRh6Z6/ZTicG+hUR 6h86ttcEYRICT1bHwklMBe3s3SK/m+X3cBYNstO5JtqUEQgFPzWbzAnpKQGjhXrUZmK2m1W7A48H XghIAXPA7EyZ6oxoIqSqqspZXl5Q0NHhiC93QDqK7EcLHUXweE4Hn29k60GPRyu7PFNKk6xSID0U GllKuZ/jdQEpTb1aT+1Bny8YZ1AvG/jzYskYF0hOCdqonsbUlsTMVP+wJKt6A/09fXKMx2tVSzqz gY4a/JnBYlBrrF6POmay6iVJbzNtHdjA/rVa19AxtVmTipU1Z08yGZUDn+yx0ybwsT02md/fY5H5 gz1mmd/Zg4HnPIbkxkoSaAFJIyGaG4trUT9Mh5ESMpzm9xmmY5m9cpSBFrwlD87+6uERw4Muq/ak paJ1K0uHLSq3K1XF1hgbqtqs0uhd4dkbGjY/d2VTy/W/OK9scXu9V6+R1HqT3lo4ecXk6VvnlpZ0 XzWjaWVzsU1n1EoH7AlOqys70zvtro9uvePb3TPd/mFea1yS05UcZ8gsyKy7+ImNGx49b2yoIKR1 pGLkDxAiNWJVJJHxB4mbD9utDFtmi8yfs2G7lWG72b/KIQbbVHc/zenTTiNVR6towRE+RHl8qkBa eqjEoewFtyON7ZBGNfw/cDg+W+9KT0hMc+npi2xCGl3eOIMvU71Lb9ZpNDqz/ps7DI5kghX7wNDX 0jPY88kkm6zty9Aqs6JVLk+rXJ5WuTytcnlaXF443pGSgLopdht7M1voxBQ/zqWwX28RR7CfGvdo teZAPzXtcTeb2cpUQsEr8jDsfDCFWJhsNAGH2N6O4pFFGI1aV5zPzGyupGfCax5cu80Ql5bIRjUs ibqHNS1aOjF736izOnJvv3nSgvoMaVvXLeeMHswXY1Tfn5Wui6+aue6syYuLrQNfZY3rVkasNmHE I0ktuTqcas93lOpx1aVsFKXyKErZqEoTmLFfVXQgO4xidpWDuQLKobjGobjGobjGobjGwX7tlZxv 76f6/cvDNByOHwMP7Etrjld2J3NCx9FysV4LX8nhAltVmVh5W+ZLf+MST3yqxFayLlWKj/N4aHEo MxRSPKQ2aV0ZqUlpLpN6jTuvctqolcJZ2fE0bsTYpMaVkzID1TPL/cV5Wa5VVv3gQO2UxKqiq++t 7a72JenhL7XBbqYjis+qCgz8+rgTd2X6NJKlbPqymrELJle4rDmjJ40Y/GNGinTRxEXxOu3gxLRR U+DVmUNHpSrpWVJEwiQa9tuqfdUF1ZLJEF9shm+K7XBUMfNosd2GyFbcT78IW0lmpo1QM2GeJxXM nahawdxoUdjEeS9rU9Gv0oddjvinSLG9WDXqUDElxbS4OH/ssH7qDdteTKfp6eqU9/InjPmtuUlN CrBhuKcd7H3FrA4RIQ7nzOooL+CrrxAun9URdLFYGAqVlGhPRI2ikmIeLxSLWt5mOh5BPEWFI0ul KnuyN8lnHXV187iVzXmVq+5dtNEzYlL5mK6GEWa92aDWeaunzy/uunRa6K6ttXOrfW1Txi4bk2A2 Y1eY26vqg/Xzx05cPiFYXzylxJsSSNHbE22JKUmBlLjcyOZph+PzqrLrW6prEUFuxC7drllBCsm6 vVXFdFic4pw4dhthzolTFmGcsijj+umX4fhUkxE2E3O+iTnfJDvfxM4ZSRinSOqwRCxU7YG8CRn1 iRM1E9n6ZG6jBQU5J21SeKkjeGItMr9odSctThGDRo6UWdqud/oTEv1OfUJ+w/DKjbUoJib443S6 OG4ed1VD+4aJaYmIsWoWaFW2plm1Ga2RgcuFRVMmr0i8Dbzd2DBm/mVdhPuBVsIPbhI+UBU/OX5Z vESUERPFA0RxDRGuIeyf/xnt9fLglCVw6nCUq6eVp19m4t9eDRGzgbVeSK4N25x2Ng/sTZkYOUjE KUHixHwcnx9l4jAH3lST3S7mh20CPl3yTOH8AWWK2ASFjXkThiVmNIg5cpZXHT0+RyKSsllit/Z/ PFHufzRRWmdyvCfFrpv4o6Z/MFHSD/QmgyQZTPo1kcmYp04WY9sRDd6Ah+JIJrk3nFyVTbOcNNtB QxYaMtOQnoZ0dJhEs1U0VbnhpCoOA7/JHJaqpAGpisNS+1XGcGqBkRpdLDq7mLtcflR0OVHLxXzm ekhlJGTo0AEbaVqOaUpkvw+xTcD9R9WnaWI3ULisQ3FZQYe4lXaIFz0tvdQVn5ovSG9UrHywZ9nd 54wsX/nASnDpLm/l4skNi2rTvFWLJ49fXOunb59z8OLG6s17e8ATwBsbLphTXjz7gqYJF3SVF8+6 gK8e1Q45UnbvXV5CQzZladiUkdrEwrUpa8fG1oqThOOwGMIOvLFhkyRjPw2GDTkTQja3v8HNVgVu IGyIhzGs47uWnpT4fNdCkDM+rWqHSmvQ6+NTMtyJw0sqAqcvg+DYivIUS1pGilktUWmOJ9VhMBj0 rvyJpQPRv10IF46szbRJeqPRYPWy/ZI29KFqqfpBUkFm7s0mjkCeMtd5ygDzFA/kKWshT/FEHhu4 Od6SdzQwPsVyNH78iH6q7tPxqTzChlqk3EKPHC6Ub51qPjrEchHCxTjldzxk4JbqEcmfaqne7s/O j6+fG07ZbHNq9Bb9JrH1/8Lit9P2l9Jx8RnJLr3GoFHPSEm3Ww3aIG6kKqs/Iy7JoXsVSS9um2YI R1Jchn/Q2DHbYDRorAls3HV0rypfNYbYiHUv0ZmO4qaEaz7C8h2tnLzxPEelync6Bmc58aJ36i0G Df0qM9UXCqVqHUmEDn01uE1NhhKIhdj2EZ3xXfVkUvUd3XjUxO74dozD6XRIP7E7Bl8N+FMD6el+ 7MazsRsf1fhJMRlPbjxIJgwdCsfbVE2dE2jO6io6v4rWVNHiKppRRav6VTVhlzk52by+hC4uoY0l tKKE5pTQEpzYj03lx7DYDrXxQHsA3ZDhZmruH/o6bETBXDE0fLgm1E9JLK6ttp+6+zSziXInxkXn dLySk9PR8Za835zsJiwrTF5HjrJS1cqt9pSUXccfTMSO1Ikd+WjxkntWNG+cOSZod+ZPXnPPOcGJ 4VyrTq2iOpPBFBrZVNRxcSRbShrbNH3EoqvaQrviR7ZXByfUVSWlVc2qCs+qTKE/jty+riFrwpLe u2a13H/b5QtGG2xOk8UWZ3Um2fVWh3Xilvtm2lITbOXzLuusmF2dYYn3Oc/ftShvePM8FunGw7fP aNIQ6XLIe+HE08JcUIS5PParnyBzeh49KYB5WABjQd/FEmdXAlMPq9h/3ePnW8GvbBXwe2yr+JWt An5nPzjDT9l/uxA2GP1kOFIvSX6eNKBFgXGyUYU5elEuGe1spthFsFkiRmLMy/WyXzfbWlie3qeZ Ls+Sw0nZoyO2VEdOBybn5LsLC5U53xMr1SfFSrX0TMHS6Pnrd8zPGb4kumUDOGr15oxuGh5ZPMaT Onbe+LLImKwEg6r3us/7us6674vt134h8wNdN50bKU2ccsUjS65+bktFRs2snouw5HbhCep2TTzJ J2+HMzJSaUYKzUimAS/NSKIZiTSUQEPxNFv2vdMPtw1nI7Uwdw+nhLmWZCuxJVtxaLYSe7IVh4K/ ZDEnmz3YWFMTWKMEE3s3OZQFD35lD/p0sF8Q8gcBYT+kPADA9Wix3UEdcc5+WrUnMDUbd28df34r rBo4wm5A8usI0tCij2T5lOxZkkOP34k6lMc7xb9pDp1WG5JDWmmQ7wS3Q/5C5Hat0aIbmKkzm7Ra g0VPrV/HxVs1ktZkoMPUZmeCM8Hv1L6ntxo0tXFJdp3OnhTnTHIYpF9dZ1RbUuMdCXaz9nFJraZq nUn7zZUGBBx4uwfevgVruhL5jSV7JM1JpdkpNJRKw/0idISph61ij/y85GFu8mAZ7i8K4iDliq/L H1KdR0zcOSY4K2xiOY6jrNzvL8fiy99f5NHmt9jL+2mW8BBuYUcd5QUgBAvcxY6w5SgvQNlHHfR0 55TGVUqnJepaHuvZt0ryM/EtGoPNMFBiddt0ktFm/uasReXO5JIpxXKarjMhWmj0CaPazh41a2tH vmfcxcuOqIr0NpNmghPP8zp7qseVGh9vocaZ16ydk5PTVJGenpWud6a6bR671Z0RSCiZub6ucsOV u3teNTjl+90CxIRr4L9WqjmIVOhQOJm5rJ2O0MMpI9jGHyH7bQTz24h+VUnYOKklNGlSAu7wcPE7 4RCqhPx4C8MaCktWL2vpZS29cksva+lVlqwXnt9H9DznxbMS9rdVWZpWZbVb2cTFYRqso8Iojgqz TgpGUXnpKks4bGTGUY5RDs9IPLCGjQ0tuZ/4/ZqGFg+KSoRgYbzcjimSowTWMpumnFdyxCNsPOzM gmcuu8i0RWTXshtVIY/c8pSdeNQSlu+aRHeqJF1Tuer+s8euaK2w6bWS1WIoaVlWWz23Nj2nZV3T BsyVTmuyGlZUL2rITCpuLqnomlhoxMRKKq0+riKyLNx+6Yw8f2X7qJplU/JoT9uV80vdKT6r1ZXi zkj2B/3plZHC0tZwOraHOy7RpksPt5VmNYz0BbICGpvXY4t3WOMwz/nTVo8bs6i53KTSlUw5G7F/ OJ4DXta4yDDEpW/CFcF8Gsqjmbk0I5NmhGgwmYa8NCAHqGACDcbTkIeG3DTkoiE70j6aoaEZaprj pXK0cvJoledJgPCwIOZRJpHxAcydJzk/394/9G04BTXsbPvZ2Yqws8cHO7uJ2NlTiP1hlQNZt5rH KjVuAGz7qdn2M+K0Wj28INObL0+wOifNbjemTTVG5OQRu67oaGEhuwewKVRyq5xCR9ER5XsasQNP e1GeV4nc8vjWpCdilYcGaJr0sst5jd7FU8uB98x2i0alNeroS5q41NzUtBGp9msc7sE7VIMz6A66 PC00eEzkltSutacmxKUmxlskJ57CJORqhm+fDqjeHahgO24edtz1Gisi1hNhS2YpzRwpP2RIcsTa zwNWqRKVSuWvXtnXPA/BU1lwfRasWWxfZFknFy4rPK9QKvzuL7YeUhXhAeOdPcq9dB/LgsJ4pMMj B3sGj0vAxskNm3MrPvWzbyM0uc0Jp2ydjqNs6xTkUPuryo453PEK3zzcucy7J3YLv7We2BzsOwrx 5ZiczKYpD9zS9fVb+paMXjJtpE2rUUl6k844bNyi8TXLm/MzmzdOH9MaSk7wpajG6G1Gjcs5mBJo GL7snmXldPvCO5dVOBITrGZHktPhdegTU5L8tQsmVM6u8pmTgipbmt+AIJiRNXidRlXS1Ts0JHJJ lRZPMMzz3dgDu+F5H3ntIHEgdhkdaXSiw25XvhA79Yuyd5T75JfyWlyFTMlB7f2ilZ21siut7Eor +bTJZKYTV9vZxpG/kUTjNDGzaSwjlW/I4F/tZWHQrdyRT3yZyvsEv7kPbdwaRz/N25PUbJK/lCyU gxhuyfIsIMeR171CcvTS0eNfkacpzxbyrWW3pDFoB/M1tviMpPSQQ6Wl7w1si4vTGK0G1cdWt0mr PuxM8SZav3nebDNIWkucRT0hKyMO9xU8Wcn/kfYd/KAF33M88G86vv6fHqqV7JBSzxz/0uPIf9ah bv5vH9eefGiCpxx7vu/Q5n7Pce+Z48xx5viPOZ477Xj///ahu+n//dA3GdSGu4w3mDrMTnOS+eD/ vwdh34LxvzzjIpLME4mWlMnZYTxpJ2eRSqmHquhNtB3nnXQTPZdeQZdJ64lael86Kn0gfSgdkz6S PpY+IWoyCe3U7G/TEHIsHvkmOUbZO8rsr6/+z3ojcjsnrk9F2B/L0RFS07Vk0ZyeRfwMoVcRDdH/ N/8c6mn1jpFjQ6cYlL++o7aeAH0BfAcJ/FOoJV3/SZA6yAP/bqjTT0LrGZzB/11IvyQzz+DfB3Ux ufFfDfrq38f3ti0j7f8sVM+SG/8p7CJpZ3AGZ3AGZ3AGZ/AvxkpS932Qvh36+gz+eeD5+Ox/wTGe 7CI9ZAEZTuah1M3+7O0/eI5nz+lU4+uL7n5otm30ZySRP9g//NeNP2f8ROb4um9HDK407Gf/HxZi kL87wOu/AI3eNJYKZW5kc3RyZWFtCmVuZG9iagoxMSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlw dG9yL0ZvbnROYW1lL0NVVVFBRitDYW1icmlhLEJvbGQvRm9udEJCb3hbLTMgLTIxOCA4NTkgNzAx XS9GbGFncyA0Ci9Bc2NlbnQgNzAxCi9DYXBIZWlnaHQgNzAxCi9EZXNjZW50IC0yMTgKL0l0YWxp Y0FuZ2xlIDAKL1N0ZW1WIDEyOAovTWlzc2luZ1dpZHRoIDY1OAovRm9udEZpbGUyIDY2IDAgUj4+ CmVuZG9iago2NiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMjE5MzYvTGVu Z3RoIDEwMDU2Pj5zdHJlYW0KeJztfHl8VNX1+L3vzr6+2SeZmWQmb5Ykk8wkmeyE5DGZhISwJIFA hrAkMEBARJClCrIoQSRgVSg2opXaBVpq9dFqxfarxRaxi/Rjq7XVbmi136r1V7StXxQy+Z77Ziab uPX7++P3/X2YN/e8e8/dzz3n3HPunQRhhJAW7UIEtc+ZGy5D4me6F8D85df2rU+lm8sB/GL5lk3u me+2nYf47xFimleuX3Xtc79NQB0C5TXTVq29cWWqvCWBUIG/f0Vf4pWXCl5GqOsGQFb2A0LfoN6G kL4f0t7+azfdkO7vJhjEy2uvW96XStcfQEj+jWv7blgvf59phPKQRu51fdeuSJeXAMhZf93GTal0 VzfNX3/9ivXPt9/2Nyj/IELSx6SDSAfvLsSioAiRpIzC1IecT8VHLox8icJUHKFkZyo+8SPbjlgy deQCA7VGvgwlDB8u8+GPIh3ocNF29Ef0ExH9BaA3pcAQ2o+mol604WMb+den6WniB9fjSlyMveir aB8uwR5sRwfS+DKcjx4aLbgDbUbPofvRfegutBH1AzO8i86jWyBnGVo3WoqOLwoPQgvF6aT60OEQ +ifwQecVBvACehZKGCH/ObQE3YBmo7uhr9+jVyGvF70JfYyNtWgUDsI4vgzv2yF8T8xcBulbRZyA EtA7QifQ9WjGxM5kTyIFswnW52ZYl/PoRUBtRl2ofrSHWlyIc9A3gO6vwcjuZiTo9/gDdBr6uIB1 gPkezPg8/iNaSGQwyrvRBbQFxv375G+Tf6C8wMcTS5csXtSzMN7dNa9z1sy2Ga0t05tjjdFpfEP9 1LoptTXVVZUV5ZGy0pJwqLgoWFiQH/D7vFyex52b43I6srPsNqvFbDIaWL1Oq1GrlAq5TCohDEZF 2C7YG7ub1ghZjb2ChotxrFvQzL4wKywgo8PDGdyRcLw4XUqQBgVkahPM7d0nEV8dF2TByUVmC8TH vuuByrMc7iZB4oMvN6MvIeR3dns49kXHaH4c6gjZjd0ej0NgfPBthSz4zuhzJwS2HfAeRwrTKqD2 bhpOjbxaDUhU7YkD7OwWcjLJePxKg3wcBOr0pGHOxoPsSU1WY0xA5pNI86qALLTYhWpY4DohPwgD YSEmtobCAja/K2CTgC2zYMgTu6DVzldfgQZNiTVcU2I1UDTRO0bTCymKetyD7sHObkMEouKg24Sf dHSfVKsaucYVKkAgEYFOqtSAUVMENLH+JNbUYzHCaJpqTzJIoQXyGelwm2hYI/D7eyHCxYBukGMa yzk1cvrA+CwE1TIxUyqWGoQgaxTkqUG4Vwt8n4D2u08WnR48cIpFy3qDmgSX6FvULZA+KHASEV9T /zzB2da+EFDQFYTefjdd7pgI6OK5m/rdg5CmZXsBcjG66BPwif4VvZRNcC8XgzxlY/dez2mHYIR3 k2AICloopt36moMMNtlXu2lycHCvW/gyDHdcrodCYAI7DH2wiYPeoLGmNVG6JOHRZRO5sTUhLg6/ v88t7Fq2JsV7fQcy/O8ZZAXNex5YHVgfqClWTJMy0buGDnlNH51m0xr34P4V4lQPiFMDfnU3rYnR QCsC96MuqL2wu6mfaxrrECYOEeKbXNfjEbKCtOLgYBMdYl8CRp8aMmSMjZ/KhCOIYTyNAj9PfKF5 4hpAj3xfLJ5GpQsspNVoTm8sHvek1h2KCnLfXmmIcw/SFuU+wRxkPWcg73RxUVtnd1PMIc5eYBq7 p75td7wN8bb2UTS2Q5nB8NuOFI3a5nJtHSku6M+A3nkpAWZGVx6KpsuLrZ6zO86l4ou6m7nm3sHB Zs7dPNg72HdqZNcyzs1ygyc1msH1Tb1uUfwx4L+/3yE0H4gLbG8/rhVXiDbnprzX3NkmmDp66FI1 u/v7UoqjgfNUOzyG0TLtH5WdljngfpABKnOD7N9gbBrQTg53M1U1p0BDOAS2moosDKirG2Riuci/ IgBZmQuNO6jUkLivafXcNLGAM9PMQ3VgRxoLjXg8VJ72n+LRMkgIuzq6U2k3Wub4DuLDQVjHXppz OpNj6aI5uzI5o9V7OVg3e9vcT+Dv8bw9aOCM7pqwSH9R9SaE0/NgjherBUV1eulNjd3EwaRjjIPQ mCoIqqxOsAXFipQmoDEHWc79HCewQUHa2H3aURd3swZQdRjKtASpBIFGfY77KaZ6FJlZAdcJ2Erx CPSqqN6JrRoyRxnJ3TTYm+a08dNKbwaJ/ivPDcqwHEzPkSpvMHJ0hs+K6i2ttX3NVK4cnlSJGXFB R3WzoPubCGC8jsZuN2gikNwOMeJucvfTxRbcvTFRJcQd49GnRs73xqgKhCHTIo40iwNMkXYirxUX fVpG3wWMfvOBeH8ttMIXwgzcFdCtKC3zutNUqnakJYr21UqnMjF/lIqZMrD4IHgeoST7p3Zg1Gz7 2/Erkbxt3oTUuM7EvOpRzTCvW2gOZhpPpacHHeOTLZOyWzPZoD62O7bSbYRB0ZMcvq3jJI9vm7uw +3GwiN23zev+DoOZxt5o/KQX8rofd4MNJGIZiqVImnDTBGrD0Np3GIVY3vE4j9AuMVciIsT08lMY iThFBofR8lNMCsdmcAzgJCkcL+JSVkWTvR9I0M3BoicEvr37pnj/YG+cEhtZUwwInM3VI4Hh6k9i RqYRVNyKqKDmohTfQPENKbyM4uVcFNgfhMNNRX2wlwPxBwXcjRw4TlmYsgvjc58aGQENeg40r0eQ +RZBAAWrDMbdwMUzoNx0GnoBPV3YtbyPjoOyKaG6vHV5XFCMNghFWgUltKBMtwAlmsU6dBeASsuB Wfs4MQpoEI5dcSEepJ12r6YNuN1gD7VwtYLMn2pT6qcdheODRq5M3E5kPkHl20tfShgbVYQixgFJ 6CyeIpJcAyNfzkHW8l43UFuCls8FZpT46VflSGFWwK4u8a8Qg8qRzkQpCVJrVYIyRPcquRhXh6BB +Mrj8dTgxdTedAHomxXUMCL/OFKmKwB1IKuVjgW+e2GotOhTtJmOU6iTuwFkkA5abEkO2YLW19oH CidVXw0YrjpTGdpSiCjaxpkUVk5nrhEN2nmnRo5zN3rGfYqLONiduyljIgfYkDyKD05GCD2gOBWT sVoRPTio0F65QopeCu3omyLdTatjxaITAh7tkWQNQmrV5YvJhOoExYz/kE0UQ55Ht4GP1YukIBAs CiPweMmXR0bAP8ePIzfOeURpxzPcp7ArE3FmIrZMxJqJGDMRQyaiz0S0mYgqE1FmIopMRJaJSDMR CT8ixi6J8AMRvinC10T4ZxG+IsI/ivC3InxehOdE+KwIfyrCn4jwrAjPiPBHIjwtwidEeFKED4vw gAj3i3BQhPtEeKsI94hwQIS7RXiLCG8W4S4R7hThDhFuF2GHCNtF2CrCFgr/dN5qc77wawDbbrI6 tt2U9ctfQXwL3/s5eF27HsDa6wBcs87quGbdzuuzN202W5yr1gBYuRrAin6zY0X/ng3ZWRutWxuz PDdCkD9je4b5z7/i4KbvYtuTOPBi75Prn9z1pOSeI0yQP4KXHsJ3HWSCsK3z7FsOV41yuX35M8uJ e7lWX0ORRdNzfTXsiRU7au4f4nLtX/QX1nxxCAdbhvDdh5kge7iBr3npMFYLDmFAINO0WI6lwFZB LEu/Jem3lG8dRMH9EPZBGNwjC968Ewe375AGdwzk5d62Bwf3QhjYIw3uhuCostgrLZYKi7Hcoo9Y NGUWZalFVmIhYQsKWU5hN7+rsd7jD+jyA3p9Ic6/OBK8+L7+vf/S/fNfupL3Si4yFy7iwqCuKKjP 43ReTp+Tq3Pn6vWsQaNUqTUyuUJDJFINwoxGRhK5an2bnlGjKShGVio3kb3Kb6Fjyt/plWqkJmr9 FDRFGSc9yi1kk/5edK/yHv3jypeR7nHswXm8Ue/ALq1dnq21sDatUWLW5k7TYQ8VKoAshDCEBghH IfwQe3i/rKiusC6/zl/nrcurc9fl1Dnq7HWWOmOdvk5ZJ6sjdaiuPTIPC8Y21DYvKpgwvOdGhUiw 7RRxdwplwTZB2d7TfRLjz8cBKzC3wU43T5DcBpvbPPChFvZ0n8JZNHsPKAqMkdDWu+f2eDDoEhLU strligtlNHKnKw42cFmH4OCiwcmfjZvSr80TsMI/m4SLTav7hIvghL0HHs7Fpl7hPS62MZVb2CQU NfUJ+YD0c7EJDeJJ7SPoINUHfW3cCF1tpDHBLjTAfCeP56SSTry9M0qdhzYhAaa/o72nV8jmomDH Q6qyvQdMwuhJBFbHSYYCGYCenu5pLpyDEtgFwQnBBsEKwQjBAEEPQQtBBUEJQQFBBkEKQcLPSlxK fJB4M/Fa4s+JVxJ/TPw28XziXOLZxE8TP0mcTZxJ/ChxOvFE4mTi4cSBxP7EYGJf4tbEnsRAYnfi lsTNiV2JnYkdie2JjkR7ojXRkvgQlT/NJ/5v1aLHf08CuFU6D+WjIlSCylEfbzKbdXkymQ4VBYMl Oru9pJwPA9vwjhIUYSNMxKXOR6gwaDKXmYNqEikuriyJhM8Za8JGW825MDw1FKDw4nPZf8im+HOG mvAffmGoMUQgUVqCK8rrmap6UlHu5/J0jJyrqKyMlOUwFjMkdMRisVm4CmzwGGhgqmTWQq/N79BP q3eXeLOUvXX7GpuX1zv13roit98iN96JLw/LSN/lavyfVquvsCKQFY7UcG2dZm9Zzi05IVekucBf P7W52FMUyHfK1j3wQPI1yZFLKyX/9cGDMG3EjFxESJonXYRykAd9Ewyyxq5uPuJGYNbnYqlHyurB XbVaOanSo9TnYpJ7EKxE7CAYK/VEbrETlU2pVB2LKZE9HDSgiMEWsTfARJcuWZw96+2gwYhqSrA9 XAZEiAAJIuze06dpKHXwuf9+i3HskctkFrPN4qkAaoKeyWFovLISyBrweQgJJLs8OmN/sstXHcrG D2A1nmHNKQkO/7a8TMcme3H/l/Hxpflthcvk0aikaOZ0yYJLX25rCCijUVmoMHdm7W+YCLUNVo1c kEyTrgDqnE7RRjwU4yt0lhYgXjvTyxAlYZxOKZEe5J0SAwsZBr0e64jebAbVeNBsYrCeZ1m3Yrsd 6DDrFZhJ9rkXzqGGt4PIzp6BWdUEG+jERlOlJY5UL0WfuhfebEL2ia1MbjOODZwfWI4xsMZIWWVl VcQgk3F5Xqai3OiNlFkl026z98+7/ytfuKN1UZV537rvLXsu+f72QzjnmRVfk1Ym/7jhmuQvky8m 30r+uXRZPPnLbPvdOPzXl/C0h6wwRLCLkLRO2oWcqBjtSHORx1lMig86eafjWMxJ9C7iOqjn9eyx mF62PRAIu3ZYMgR5BYWDKNvOiiNuyESBDnzWR7ZBueNKdeK4LIdYzDLgD7mMA/YgFYbyEBOowNZI WVUlfYBHgBBypv/4+YeuKW9tnfbEtjUPJGt9QYtMagn68QPG1nVt1YFpHu/Kx2+ud0i7ytffe+7m +y52z1lpMUZVtoKGErIkzOdnqaKXvMRtL2xad8O3n7z0OYZyDFBCMgMoEcKmDMdoR07zM5WaFq2C 5eHFshaFhVgO8oqQR3GwpAQxGFY3FJIT+cEQHyo+FguRHI/HSqwHPbwn71jMo2X1eiuDc/jc3BKF dUdApFuZyEkviiqmbDwB2TMN4xOw/vAOp9nhbDjInk2xGB1W3f9kWBOW4FP1SpkwxHCcIc2BmUS9 pCpCxq2VhN/nCfGzXh4oKvPoN2zQ5YXDAy9xJX7OkWPcZ7pckFkqaVfyR0sbA0l3Vu3U5JraqdnD byqt/qKWhuShieuUXhnmWpFHu9IcarGZLeZjMQuRKRXKYzEF2qHT5bgMRlxDCYxE9QO8BZDyon5y afuEAnGfOYeICikzC48F9DmDJRpbvmv4H5kxM9qCgFlxiavzZ5tA+aSGubSkvsCuikbVWd7aahjr YoRkCRhrNXowPdbySgevNLc4HOX5KFKVYyHl5ZFjsXKi1PhJgTo/v+BYLN+RXVmZV2WR7jQYaity 824OpRiFcsorEdh+QP+iMZ0KEVvEEDEYYbZBcYbcp+hjvFae3EIc6xiLwWy1jpKhsooDOcQc9gc4 68Qsvx8ohLFHlqjw6zW+muGRojyTUkYsGocv+U8h+Zcsk1GlKyxP3uoLWqVafzV+B1twEf611KTn prRdPjp1uk8fjWqMrikx/GbH70P5s5YPh0iwKfb1V5LlM2r9WiCuPb++hPTNrPay0cs/JxWgqdaM XJD6QaPrkAv1pGlrR0ZihG3IJHcQx0FeLlFtt9ly9dvJmIJqyBb1THZaL7GTa4yq33SRuNSNDFSz wsvMyGSYat16ULYM1cHMY8mXky/dga2ncRAXxb/2ejJx1+FZaxtdDTuX33U7i7vxgldww7HkN5MP PZF856FO5mfJXyVfmnv42a3PYO2+5FspjSu5HzgkBxWiL6TnEXC6iRt2CKdZbi4khQfNsC8ci5mJ VCFXHIvJ7Tu83qJctEM7qj/GeDwtunR3TUktnWXOx7c3JgBXqE3FgZkoDmVW0Muw5wQqqPhntDBW 2YLFw38ZFY+m4ctbzn+jr35+YktNzbr5zf4PolUeqyI6UaAf/Y89Z1ZINtTctLp/WzkD9KiDnZol F8CSi6D30vSYpS4gBffzvLpdzaxXY7VaorfkWnZaiIpYHA6WsEO8g833HweuxhESRmE2zJglkjAJ 3y2xIqzOl7gHIpEKhZm3FO1RiFR7IfucgRLOFhF3cFBzVBLCwYnbL5RYvCFDxan//ih4GEa64U/u Ke4LUOr6/RXlXl+KuiB7HCwAbO9U+ET1RKjdZBUXgPm6vvPeBfN3TgP7yV8YDYUaK7VPLNr6uSXh G+9qkWnNrvzkAfu9h2N1oc6S3dL2lob1rYe+aV26eEWBOz7newVFLg1/587k1mgLZ9Gqovi3krX9 9dNKO0OwGiFYjR7pEMqG9bg9w51y2fGYXIlV6nzi1XuJ9zDs5NYcYs8Z4q3WbONuj6dQ5RjIHs+d IHY1mRlTZWNveDrFmR/fFnAmrXKFqnFTeYgEKnygwOqZyChHygNYJIpolQOFjjIqsKaxbRuuW7iy 9jvfWf3c0P27Z+zCnq74or75PUXzqyUNLTOr3WZlVDf8Y1xVx1364NtvbK6pMeLmbZuf+u7TPwp1 RUCP94xcIF8CrsxBW9JUyGHVu9QmYhri1SySSJzEeVhiZXk92MBu+255RuNEXswetRFT6w0i9iyd uuXDDYxjk0nF49gm8kRFOfUyQPmKNiBoadDEMF3SPmvZY2tfem37m1/seCB6Vl9X7WuM5BQta69d BXtQ79yRf3zt79ts5neWzPf13LN58wMLyqjmgbUdhLV1ozB6PD2rihzX8VgOcmMzrMUQb2ZlCqI4 IZNJj8dkMqUqTILaIAke5rVWhdJG0EA4XJq/mx1Vr1SastPLFKYszs56fYzRGxrENS/41H2MX/WP aC6ORfUk5aoCEwhUIaoqXwSnGSEtKhKn1JgfTl64UalvOdr6vUfXvXRPUVetzOQvw5btyT91dtXH i+f3BLtqsXdmc6FD1ai8E7fO+eDSiTduULM918TD2apG3TDauiX+jY1P/ygYrwU6Ut54H3gjCyj5 dJqOtW4TcQ/x601Yb8o1zTEtNUmsxGRSERWYvkO8ikVZWE2yCAEz7DBPrFnIOJCdnec2DchGxead s2Xp7UrUEA3Zo5oZUoszWin8GXuaqHau2GjcN56UVht9PCKfVRFRG8nJn1b+5JY33rrxj4d69i1z +01mPHwr3nnLzK3Tn5C0tM/qUX5v7cKRS19568bCtoqGjrlbHv1WTQtuu+fu+w6BLNUjRPzS+5AP fStNrTITNVxN+l16GOQQr8c58uMxac503qHnoNjxmM/lyjXxxlxHrkyTOyCRBPwZ4y5y1hBhXxQd 9MweCJMoG+USEJ9zIp08n9jH6DZ4pQbiVbDpG6gSrqJUSQsgMJYlYuHS9tC8sI/dGvbZdYR96zfz G28zFHiCIcNTT7EF5UldVJc3dSbT3yQ3uELeRx7XPVtVXrN66cztw0Nt9V5NFBHkTfISF/ARyBCa gwvStInz7tkBlSKsqCJVQzxRKMIsRmVlUH46X6YPTyVTh/gwy84m+tm5s8OziY3M5nXGltk8a28m zUN2Z6tZ2ujScLyLK8RMGSlE0j21tR3lA4UZqX3nrNFWw545k82egyfj0oJPEkwZ/+MNIsoqoplY k0lRY5TSd9r/bJy83Tna02frOo4DcivV/6D+ZaI+HN0OQmCnVVb5RU4WX+JWYfOM3yNG91Fxp+Xy JK5vSZy+588tbyjLqqu6ePzYja/eu+HULdNbphX6A9PKZ7c3bj66KDLbh1cPL54+s6l1euuM6V6v b/veHbvtzfyDrWShSe3siz30iLG4PMdtuGXfNUc6zBWLptf05uXMrgl3NuYX3dG7eM+8gEqW/OGO bddv3nbzxssnnNFgS9O8mXklburh1IJNuBc085TRPTc/YNCRwoLC4zG2wDIlB4xV4gBpZqurjseq US1WDFgsU6e4B0rGbbqgH0cVaATYOiIqUrpWro9tTXTDr1QxjlMKIWOCVFCRAD0rygHgJCJOQnGp rRk/13NH27obqojG4nckHWFOq80tzffPrSIytTHPmbTm5Jl0EqIy+wtB/ZJFHY0dQzcmDxXNCrnM 4FKpC2csxdLEdVNzwh2h5E3VUz3ZViPg5aasQBNPNPM7qjxmBWzcT4MWbgWvcKr0OuA3B3osTbUa whCynNczcxhmhMF65ofMnyAiUSKGZRiWMIYTer3ueEyvz5I4JMdjDmxkjAMKhcuZUS9n2DNjpjXd fqiaXLJ4w/XZKe1b8ll7GGdrf6i5OAb6kTRRRQKmaIp/mfw/a0p9WmVWMA+btqeJZ5de969/ffC8 trBlKf5laZ3XJI8phmsyREpxEVMCXGRDHRk/2WI+HrMgG5bIZaD9ZGhAq82yT/aTU7u0fnJZ+7hs 2HXTHuDYauNnNb5IZkmVFnFJsWdpS1D74RWD0cF6yc6Dtouj36RHxyu8atECBHsIxwgv4QkPJhEb P7FgwfzjsQV6W3Zpeat0ZiSrrW3m8VibYSBHUTRQnVNdndMTR00D7aNeck04zL5SxqZnlPZxRXqP WicZ9ha30M/YcZoUn9AumGzp/TN9MPwhqdFJKI4Zw0nSkpSm7Rgj4J9peg7OnLEsZllxuKN9dSw3 JVE5xXlaTV7Yn11U7DbJpSznS3pDnEaqsTh8Tl9HldpbnPSU+LRSU6AEG3eQbtLV7G+dsmRmYffA oklyplm4gXeynrzC8inJ78dailz0FKOwtRdroj3Vhdm6UGc4uX1JW1AdjYosd++M6UGHKqZAqbWU HIa1rEH3pNcyaGNqSHZW9vEYzrIETvh8Xthg9fkGXbGO6A7zxWxkQCabkpMfMA3kiMsmnj6k/fOU 1kkTdkxruT+pzQlKa1L1uOcTiSwXPYnMQkkOJx0hr1amtTm9Tn9ntcYXTrrGaKnX1C9ZVdMJrr64 FFF1sHUpVk/vqQ1kacJzw8mdS2d8iFR3kqoGX3jhLfOTB1OkRynrURIB2unBtxg7xxD9AmRVgmIe 4pWsZrfd7mZ3Sz7mHGNSjQ+fY+SNboB0cxS3QHqOIVoxzJRDv75hxsBj17z73tZXk48s7a2YHjQu XRzr9LOr/vzwrWd2TR1576G3rmf0LzxfufKO+G9+Pf9BOva6ZKdkFYydQ6Xoicz5FtUXRH6clzks J0wmIzEe5036EltxdjEpPsxns54ACQzxHqtrd2FhxGL1ghehFudlK5s8s9RKps3VjJCJvJD/aXuZ ZEN8RINx6QR2ICl2EMU37VgaJriV+FnRpgN7j6jNAT+2bNNr5h+eI/qXq5ZT33LBouKuyu+Kpp1o +ZFrptcVOsyKmOIuMrdVdDKzcT11MZ85HeqqSEsRoVLkRz9O07LagNVIwSoYJVFIeEZtVOepiUEi URM11U/+E14vdzzm1Vuz7FnHY3YFL5fn+8GTcI2dF4L3OWHDEalLr2DArKVHESnjLfTZOpq0iV2p zbT2s6UuK3Tkilrt59rWIwunNj5qqApZK4pNMl1hWdI0Tl91kPkztcm/1dY7SiPl5cmnls4MKier H4w6wP9aCHQLZ3aSxxE38tfHlGyLiuNM3KmRv/KlqQSxmXgTONpDJhaFwSsKF/FFhJChIqvdZgvk 7tHrQ4E9Mlkp4umJq+hUpMTNUBNOmcXpKTZkPAN6Fhukd4Kpo/jJ/Xo+vl++yDrezfiohuMma8ZA DYTI2BGAaHlRi9eWunakJ3K/sfcvaJvFdSyr6msp7H/qptYD1w3YqqKh6Gxny6olW+rr1n6x5+s/ w7qenti0gtqKoL22dWHVwoFmjfkNvtlRV+mvjAQDXdfN6Ng80xf+O1DXB9RlJC8jJxpKc2WRSXk8 Jjfp9VhD9KbpPKt38hq2xem0E3ioj2k0IjNr1inMaW/2bASctDPgoaXd2bNh8VorxSxp7+yT2hzz WyfXzrirKe8sYvFYPIbUsQj4q0z3ne2HD22fCg659O/YlfyzpcznLCp13NA29YGvMuEmVX7j2o4P tienblgbUWXbqRzy9FyEnEfF6I7MiZeh2IhQ8fEY0hNF2HkiW+3KIXIPKKDDVJE5zQNqdZgZ8I2q 58j4c5BZr8PWJl4uGFLW98e2NuHMY2LVuMlD7QXxICN9FGuYePrhFze4AI/3aPJK/b7OGpnBW4Bv zZx5aBYfnLFmZzUYkCaPk5wf/nXv2gZXaG4Y39I6Pd+hiQ7HMoceZH5szj034nXVdR4HmJNAFcfI e7JlQBUf2p3hA7UzlyhMLizVZXFypVJxPKbUI6OFEB+ymE2YMEYMKUVWbkBHD10j7Nkyg406bakv Ctsi6auH1Aaf9ZENgsKZUDYuJYQjqbsZ0X+zmUwRkyl1bSze18gxeeM/fvezf1hz/G78BtiDqu1/ +f6Pdpv1JUX4xhyPy8cl/6Fi9gxvY95vbuDACFIU+LKm5iX7mIeHO/DqyhnOwip5tFFpL2yPD8+C +dO/bnLD/GvRdzNnPEjvKpbYfYHyKuKtSJsjUoWVZMntoposRrICl17l1aMqU7Gr1F5apZLJ6gq8 JnqDHDlD1TNAWOGa8WHizQ6NGMA/Fw2gT+pw0p3OWN04NqUv1kUlEpCniCbetFdVEWAZSkiKslWN ElEmkzNfeNMTKXUls+plGuOG1XkGbyC5M7ig/pdvWd15Dpsav9ZgNK9aaTcVcHh78cwWxpt8JDw1 TwEWf7HGYsn+ys0Ffrs9TxKNKpunv41nugt8FiUGFR40+JyHduYUWJ0cA3ZmwwJ6Rw/CtwmHwIPT PUoEBj/M0JPjt0tLxF9RbEr+A4eSv4J8jO6HtaiRrkDZaGl6LWxGmxXcG4VNTi/1vhlTWNGgTud0 ZHybs5ldUNwSjSI52cl1Rre10UL0dHHsLlA8+grgiMxC8rSe+iWzLj9w3dIyW64jq6d/KqPaJcO2 2ik+i5rp6ZEa8uqbmecLvKHpa3BN7wmqV9bCqG0w6gC6Kz3qAovVqpdLeGnuPr2+ICDXW3OtjJ5Y HQ4waI7yDrkkIAc75ggvH3cFO/74Dofpj1FmvfNi6jbjHJ1W9mduhapQ8R6XiPyQsQrplQMj+vtm mXgNb2Hencb7NBttl9cWHr1+7YbqZV3tq+2PbB3cO+fQ9+dOuevBWbe6/2UKh5NHor2v3rrzawdn r9u+YevfSgPmOXsXzrntoa+03RNUUUrsBA1rBUoUo3fSlGjRqPM4Lo/kHeU5YuaO3lCiR7kIZoEI TwpIwVEiX2/HejtWEruZN8NeetScpVHLOQ7JB/3sYE5O2FaMsnibuG+/IFJj1isvUGVMRWrc1j22 xY672hZPkyjxKj77OHhz1qRN/OO6iJsqKkdpaqH7tqi4AxURumNRHuNSv34RL30ODv9i2xOrYtuW Lbija8Nfvrbh5Y5HXGvmv3B4aM5DjyycXzp3ml6ieXttbPfirpt7Q0r9/DuXbnp0VYHv0vWrsOz2 wevlh2+/bkPwmvnUVi8H7tspXYQcKA/9PE31Oo9brlQgFkwStdMklzvJ085fO193EkBpCOu8DwxK h1KWBZWOxRwsb1ArXW5i3i+Vep30hiPFfLZI2QtjZiaVnVnDlK0Wp/YtiFHfTiRv8WfqcII8fkSb cR+IZoWnAkfSv0WQc5aUTw3MXF7FYfyKN2iVDf+VWfpKbmm+S7taM6KyF7qT+C08X6VKnoiqbIH6 8OG1JHH5Ia039IfDFQ0+kzLKqF6/8+jwMOXWLwG3Vkm/iPzYl6abVqt2qYvVxC5xqonu1Mjp7zrd LfTNR422Fp36Pl7vxE6nl94Phi1ESywsC2bMEVa2HmM9BubBXt4rJdKj3iwGZR3Q6xXIwlvdgwpF PgK6imTN3FC2Cbr27pNZ7uo4e+7DjAyinL49BAqdpb+GEwXa8TFjLPuMY+S9V2bwj+g6XpXi5TQT ywMGT1q5GCpHWR9Y/kuPZq1bcG3/rTtLNxQtZOb48qzadebhI3Xbe276waqb3vzq6pfrP7j2mr23 7z9o1FYz31LZ3cmnkkNGw6KHtwz+YHEh5el1sDK9oEfsqAB9O702pdIsRRbJuo9XKOysFrtwMaYm JCb4Pt4uZ0XRZrMwztXsDwSCktz95rEjU8OoiTp2V2tM34SnHU/fp2p+otf54Xbi2CJDaQczQw8/ /QFXFaa+0qhvTk79LnmhWDX7/iUbvz5v/RvfvPdPW57Ga15PXi6dH7WpVq6u6yizLpW666XJS/+Q VJatOLV1z8+vv+ndb7+Jt/6FHV7oKs2tbX3sVGju5ul3HBJ/BH9z6sEsPF9jCpj3Ug+ZmX7eJ+9L Fkte///7kT4oK5EdkdfLX1QsU65SYdWg+Lyk/qFmseYH2mXwJHXf1vv1J/Un2VL21avP1ef/see/ rj5Xn6vPlR9Dp+E3xrtMIdMl86H/jQ+itk3qr9fM4A3Tz0okQ53iX7l5yUZkQrvR3WgQ8jToMPoi 2ovuQnvQfnQrugex6E60D30eHURyJEFG9AX8GhpAd6DbyCayGcnIFvI5cgNSoCOQS/9HigQe6OuC d2QEIKYQ0hKE/q/1k/rrPCOiv+5DMA8NQo191y67fnVfUfS6tYnU3+7hO5F07H+ffMJnUrkL6MLI BET6L/+kMfRkJuAfQ7pq5H0aJHejVdKvol7J0YmBeXZikD2NFtMgvROtkbwBZa6G/72hBdVJfoBC 5DTqkTwD6QbUw9yH6iUFyCs5i2qZAdQ6Gj6HauW5qFXyAoTPi+XraCAnUSt5EHUwf0M+SPM0yJYj h6QcsVfD1XA1XA1Xw0cH/Du06mq4Gq6Gq+FquBo+S5A8ge5Ha9FOVI6+JP7nTPIJPiL1AbE096Tw 8PeX6uv+hdQpp/HxvwxNpe+nSqYdu3wxyatOyI9AWaXom8LnvwHf6FKZCmVuZHN0cmVhbQplbmRv YmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC42NCkKL0NyZWF0aW9uRGF0 ZShEOjIwMTAwNDI3MTY1MDAwLTA0JzAwJykKL01vZERhdGUoRDoyMDEwMDQyNzE2NTAwMC0wNCcw MCcpCi9UaXRsZShNaWNyb3NvZnQgV29yZCAtIFJQTC1QYXRoIENvbnRyb2xfUkEtMDEpCi9DcmVh dG9yKFBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMikKL0F1dGhvcihhbGV4YW5kZXJyKT4+ZW5kb2Jq CnhyZWYKMCA3NQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMjU0NDkgMDAwMDAgbiAKMDAwMDA3 MzE5MSAwMDAwMCBuIAowMDAwMDI1MzQ4IDAwMDAwIG4gCjAwMDAwMjQyMTYgMDAwMDAgbiAKMDAw MDAwMDAxNSAwMDAwMCBuIAowMDAwMDAzNzgzIDAwMDAwIG4gCjAwMDAwMjU0OTcgMDAwMDAgbiAK MDAwMDAyOTI0MyAwMDAwMCBuIAowMDAwMDUyMDI1IDAwMDAwIG4gCjAwMDAwMzAxMTUgMDAwMDAg biAKMDAwMDA2Mjg0MyAwMDAwMCBuIAowMDAwMDI2NTg4IDAwMDAwIG4gCjAwMDAwMzE4MTIgMDAw MDAgbiAKMDAwMDAyNjc1MSAwMDAwMCBuIAowMDAwMDMyMzgzIDAwMDAwIG4gCjAwMDAwMjc1NjIg MDAwMDAgbiAKMDAwMDA0MTA3MCAwMDAwMCBuIAowMDAwMDI3Nzk5IDAwMDAwIG4gCjAwMDAwNDE3 OTIgMDAwMDAgbiAKMDAwMDAyODM4NCAwMDAwMCBuIAowMDAwMDQyMzU0IDAwMDAwIG4gCjAwMDAw MjYyNjYgMDAwMDAgbiAKMDAwMDAzMDY3NCAwMDAwMCBuIAowMDAwMDI1NTM4IDAwMDAwIG4gCjAw MDAwMjU1NjggMDAwMDAgbiAKMDAwMDAyNDM3NiAwMDAwMCBuIAowMDAwMDAzODAzIDAwMDAwIG4g CjAwMDAwMDc5OTQgMDAwMDAgbiAKMDAwMDAyNjQzMiAwMDAwMCBuIAowMDAwMDMxMjU0IDAwMDAw IG4gCjAwMDAwMjU2NzUgMDAwMDAgbiAKMDAwMDAyNTcwNSAwMDAwMCBuIAowMDAwMDI0NTM4IDAw MDAwIG4gCjAwMDAwMDgwMTUgMDAwMDAgbiAKMDAwMDAxMTkwMCAwMDAwMCBuIAowMDAwMDI1ODAx IDAwMDAwIG4gCjAwMDAwMjU4MzEgMDAwMDAgbiAKMDAwMDAyNDcwMCAwMDAwMCBuIAowMDAwMDEx OTIxIDAwMDAwIG4gCjAwMDAwMTU0OTMgMDAwMDAgbiAKMDAwMDAyNTg5NCAwMDAwMCBuIAowMDAw MDI1OTI0IDAwMDAwIG4gCjAwMDAwMjQ4NjIgMDAwMDAgbiAKMDAwMDAxNTUxNCAwMDAwMCBuIAow MDAwMDE4ODA1IDAwMDAwIG4gCjAwMDAwMjYwMDkgMDAwMDAgbiAKMDAwMDAyNjAzOSAwMDAwMCBu IAowMDAwMDI1MDI0IDAwMDAwIG4gCjAwMDAwMTg4MjYgMDAwMDAgbiAKMDAwMDAyMTM3OSAwMDAw MCBuIAowMDAwMDI2MTAyIDAwMDAwIG4gCjAwMDAwMjYxMzIgMDAwMDAgbiAKMDAwMDAyNTE4NiAw MDAwMCBuIAowMDAwMDIxNDAwIDAwMDAwIG4gCjAwMDAwMjQxOTUgMDAwMDAgbiAKMDAwMDAyNjE5 NSAwMDAwMCBuIAowMDAwMDI2MjI1IDAwMDAwIG4gCjAwMDAwMzA5MjMgMDAwMDAgbiAKMDAwMDAz MTQ5MyAwMDAwMCBuIAowMDAwMDMyMDU4IDAwMDAwIG4gCjAwMDAwMzI2MDMgMDAwMDAgbiAKMDAw MDA0MTI4NCAwMDAwMCBuIAowMDAwMDQyMDMzIDAwMDAwIG4gCjAwMDAwNDI1NjUgMDAwMDAgbiAK MDAwMDA1MjIyNSAwMDAwMCBuIAowMDAwMDYzMDUwIDAwMDAwIG4gCjAwMDAwMjcxOTQgMDAwMDAg biAKMDAwMDAyNzcxMCAwMDAwMCBuIAowMDAwMDI3OTU3IDAwMDAwIG4gCjAwMDAwMjg2ODkgMDAw MDAgbiAKMDAwMDAyODkyNiAwMDAwMCBuIAowMDAwMDI5NDk1IDAwMDAwIG4gCjAwMDAwMjk2OTEg MDAwMDAgbiAKMDAwMDAzMDQyNiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDc1IC9Sb290IDEg MCBSIC9JbmZvIDIgMCBSCi9JRCBbPENCMzEyNjIxREQ1N0JGMEY1M0E1MEFGRjM2RTc5NkIxPjxD QjMxMjYyMURENTdCRjBGNTNBNTBBRkYzNkU3OTZCMT5dCj4+CnN0YXJ0eHJlZgo3MzQxNwolJUVP Rgo= ------_=_NextPart_001_01CB1F8B.BEB4B661-- From alexandru.petrescu@gmail.com Fri Jul 9 11:23:25 2010 Return-Path: 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 428373A6AA8 for ; Fri, 9 Jul 2010 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.919, 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 oatgveM1HwMZ for ; Fri, 9 Jul 2010 11:23:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 09CE73A6A08 for ; Fri, 9 Jul 2010 11:23:21 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6ADA494006D for ; Fri, 9 Jul 2010 20:23:21 +0200 (CEST) Message-ID: <4C37690B.50608@gmail.com> Date: Fri, 09 Jul 2010 20:23:07 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <6427.1278635611@marajade.sandelman.ca> <39D6B8E1-CD63-489E-97E3-A43407ED92C8@cs.stanford.edu> In-Reply-To: <39D6B8E1-CD63-489E-97E3-A43407ED92C8@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100709-0, 09/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] unsigned integer MUST be at least 6 octets long? (was: rpl-10 --- security questions) 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: , X-List-Received-Date: Fri, 09 Jul 2010 18:23:25 -0000 A nit: > In the simplest case, the Counter value is an unsigned integer that > a node increments by one or more on each secured RPL transmission. > The Counter MAY represent a timestamp that has the following > properties: > > 1. The timestamp MUST be at least six octets long. One would expect to read here 'four' instead of 'six'. On many platforms simply saying "int i;" defaults to 4-octet. With that "MUST" this default is ruled out, making it a contradiction: implementer reads 'unsigned integer' and thinks 'C int' - yet it is forbidden to be a 'C int'. C unsigned integers are very often 2, 4, 8, 16 octets long and very rarely 6 (I have never seen a 6-octet unsigned int actually). Alex Le 09/07/2010 19:25, Philip Levis a écrit : > Comments inline. Rene, there are 3-4 questions for you to answer. > Please take a look. > > On Jul 8, 2010, at 5:33 PM, Michael Richardson wrote: > >> >> {I have a lot of comments here on rpl-10, mostly about the >> security stuff present since rpl-09} >> >> Exec summary: *** I am not happy with the lack of algorithm agility >> implied by RPL-10. CCM*-AES-128 and the ECPVS signature >> scheme[X9.92] appear to be hard coded. While there are some bits >> to permit up to 3 additional algorithms to be used, I can see no >> bits to permit a different signature algorithm. >> >> *** I am *not* of the opinion that AH would be a better choice >> here. AH can be made to work, but we will essentially be creating a >> new mode of AH, which is replay-enabled while still being multicast >> and multi-sender capable. What I am saying is that there is no code >> savings: restricted code size system won't care AH vs RPL10, >> because they won't have any AH code to reuse. Systems with AH will >> have to implement new code anyway, and it will be harder to >> implement RPL on any system that already has IPsec because the code >> may be hard to modify. >> >> I am of the STRONG opinion that the text, and essential packet >> format of the AH specification should be extensively used. >> >> >> === my detailed comments. >> >> In section 5.1, RPL Security Fields, the Key Identifier may be >> present depending upon the value of the KIM field. >> >> When KIM is 00, 01, and 10, the presence, absence of the Key >> Identifier is clear. (But, if Group key is used, then Key Source is >> not used, because, I guess, the Key Index is no longer a local key, >> but a global key, so that's why the Key Source is not present?) >> >> When KIM is 11, a signature is present. Where is the signature >> defined? What is the format of the signature? When KIM is 11, a key >> source *MAY* be present and a key index *MAY* be present. How is >> this determined? I think it may come out of the security level, but >> I don't quite see how. > > Rene and Kris, can you answer this? > >> >> It appears that the RPL security fields are not a multiple of >> 64-bits, and block-mode AES requires 16-byte blocks, while CCM mode >> is happy with any increment of bits. Assuming that someone will >> define a second cipher at some point, we need to know how to padd >> properly. But, I don't see any statement about how padding is to be >> used. >> >> I am not happy with the text of 9.2. I suggest it should say: >> >> Authenticated mode requires a would-be router to dynamically >> install new keys once they have joined a network as a host. Having >> joined as a host, the node would then use standard IP messaging to >> communicate with an authorization server, and new keys would be >> provided. >> >> A protocol to obtain such keys is the subject of a future >> standard. > > OK. > >> >> === >> >> I also see no way for a node to tell if it is joining an >> authenticated network or a pre-installed network. How does a node >> which is authenticated know which set of keys (pre-installed or >> authenticated) to use to authenticate a message from a new >> prospective node? Is this an inate property of the keys themselves >> indicated by the Key Source and Key Index? >> >> The 'A' bit of the Configuration Option tells a node what it may >> do. >> >> section 9.3: 2. When a node resets its Trickle timer in response >> to a secure DIS (Section 7.3), the next DIO it transmits MUST be a >> secure DIO with the same security configuration as the secure DIS. >> If a node receives multiple secure DIS messages before it transmits >> a DIO, the secure DIO MUST have the same security configuration as >> the last DIS it is responding to. >> >> The fact that the DIO transmitted is always the same as the last >> DIS it received means that any DIS received before may never get >> replied to using an acceptable (to that transmitter) level of >> security. Isn't this an opening for a bid-down attack? > > What's a better way to do it? It MUST respond with the same security > configuration as the first DIS? This opens a network up to a denial > of service attack: as soon as a node sends a DIO, the adversary sends > a DIS. The assumption here is that it's much harder to ensure you > send the last DIS than the first one, because the DIO transmission > time is randomized. Security policies can always discard DIOs whose > security configuration is below what is acceptable. > > > > >> The rules for the 'A' bit of the configuration option are written >> wrong. They give rules for what a node MAY NOT do, but nodes will >> do what they like. What we need are rules to determine what a >> message being processed with a non-Authenticated keyset may >> express. >> >> Text like this: >> >> When processing DIO messages secured with Key Index 0x00 in a >> DODAG that is marked as authenticated, a processing node MUST >> consider the advertised rank to be INFINITE_RANK. Any other value >> results in the message being discarded. >> >> When processing DAO messages secured with Key index 0x00 in a >> DODAG that is marked as authenticated, a processing node MUST >> ensure that any RPL Target Option containing the same address as >> the message's source address. > > Right -- this reverses the requirement. Seems reasonable. > > >> >> ...continuing with >> >> The above rules mean that in RPL Instances where the 'A' bit is >> set, using Key Index 0x00 a node can join the RPL Instance as a >> host but not a router. A node must communicate with a key >> authority to obtain a key that will enable it to act as a router. >> >> >> {Why not just ignore any Target Option prefixes, and take the value >> from the source address? That way, you can avoid sending >> unnecessary bytes} > > OK. > >> >> >> 9.4: >> >> - the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL >> nodes + the 'C' bit is set, this Counter field can be 1 or 4 >> bytes. RPL nodes >> >> >>> 2. If a node receives a secure RPL message with the C bit set >>> and is uncertain of the 32-bit counter value, it MAY send a CC >>> message with the R bit cleared to obtain an uncompressed counter >>> value. The Nonce field of the CC message SHOULD be a random or >>> pseudorandom number. >> >> It says, "MAY". What other choices does the node have? What does >> the node do with the message it received? Discard? Are there parts >> of the message that may still be trustworthy? Is there any point in >> asking for an update on the CC if the message does not change any >> state? > > The point of the MAY here is to state that it's the implementation's > decision of when to do so. > > >> >>> 3. If a node receives a unicast CC message with the R bit >>> cleared, and it is a member of or is in the process of joining >>> the associated DODAG, it SHOULD respond with a unicast CC message >>> to the sender. This response MUST have the C bit of the >>> security section cleared, MUST have the R bit set, and MUST have >>> the same Nonce, RPLInstanceID and DODAGID fields as the message >>> it received. >> >> It seems like this should have been discussed more in the section >> 3? >> >> Why is the nonce only 16-bits? Seems small to me. There needs to >> be advice that the nonce is not an incrementing integer! (cf. DNS >> queries with 16-bit ids). > > I don't think the problem follows; in DNS the need for random IDs > stems from the lack of integrity (an adversary can generate a > response). In this case, the ID is intended to avoid attacks where an > adversary replays a response. > > >> Why is the destination counter included? Of what use is that? Is >> it valid to send CC messages to peers which are not onlink (one >> hop)? I.e. can CC messages be meaningfully routed across the DAG? >> I'm asking, not because I think they should be forbidden, but >> because if they are not forbidden, then we might need to say so >> lest someone makes a different decision. > > The destination counter is for when a node reboots (a common issue in > LLNs, e.g. due to low power). If it can't store its counter value, > then nodes will ignore its messages until it counts to where it was > before it rebooted. The destination counter provides a mechanism > where it can sync with the last counter it set before rebooting. > > > >> >>> 2. The timestamp MUST be in 1kHz (millisecond) granularity. >> >> Is it 1/1000 that one wants, or 1/1024? > > Good question -- Rene? > >> >>> 3. The timestamp start time MUST be January 1, 2010, 12:00:00AM >>> UTC. >> >> Making it Unix epoch (Jan. 1, 1970) would be simpler. As the >> specification says we are supposed to keep 6 bytes (48 bits) of >> resolution, this is 274877906944s, or 8700 years. If we go to Jan. >> 1970, then this changes the lifetime of RPL from 8716 years to 8675 >> years. >> >> As I understand it, we are only transmitting the lower 32-bits of >> the value, in units of 1/1000s. So the timestamp for my email would >> be: Unix time(1278331381) * 1000 mod (2^32) = 2726094088. >> >>> 7. If a node does not have a local timestamp that satisfies the >>> above requirements, it MUST ignore the 'T' flag. >> >> I think this is confusing. I think it means that if a node does >> not have a timestamp that meets the requirements, it must set the >> 'T' flag to zero. The question of what a node does with a message >> with the 'T' flag set, where the node has no concept of time is not >> dealt with, I think. >> >> Also, I guess that if keys have Start Times and End Times, then in >> principle, one can have multiple keys with index 0x00, which are >> non-overlapping in time. In principle, that is, if every node has >> a clock! >> >> If a node hasn't a clock, while I can see ways to pick the key by >> either trying all of them, or using the Counter value as a clue, it >> seems that this introduces windows for replay attacks that the >> counters had just closed. >> >>> node's security policy database. The configuration of this >>> security policy database for outgoing packet processing is TBD >>> (it may, for >> >> the term "security policy database", while generically used here, >> may well be confused with IPsec's SPD. >> >>> to the particular destination address. Where a Counter for the >>> intended destination address has not been established, the >>> Counter value MUST be initialized to zero and sent as a Full >>> Counter for the initial RPL message transmission. >> >> To aid in implementation, can we please start the Counter at 1, >> and even better, forbid 32-bit Counter values of 0 (matters when >> the counter rolls). >> >> The entire Compressed Counter mechanism seems like a waste of code >> space. I see no savings by doing this in the resulting packets due >> to required padding. The ensuing CC process that is needed to deal >> with this seems like a further waste. I'd rather define a >> standard compression algorithm that we can apply before encryption >> instead. >> >> I was excited by section 9.5.1, because it was going to tell me >> which bits to apply the AES-CCM encryption bits to, and which bits >> to authenticate. It failed to do that. >> >> Do I understand that the security bits themselves are *NOT* >> integrity protected? >> >> page 74, re: zero-value Full Counter receipt. Is the message itself >> discarded then? Assume that it otherwise passes all processing. >> >>> protection for a received RPL message. The replay check MUST be >>> performed following the authentication of the received packet. >>> The >> >> well, no. The replay check SHOULD be preformed before >> authentication of the packet. If the replay counter says "old", >> then you discard without further processing (do not waste your >> time/energy verifying old packets!). If the replay says "new", >> then you can authenticate first, and update the counters if it >> checks out. >> >> I can't tell from the specification if the contents of the >> "Security Section" are protected in any way by the integrity check. >> Section 9.6 was not helpful, as it says "entire IPv6 packet". I >> guess this means the layer-3, but someone will get it wrong, and >> include layer-2 too. When the integrity check is calculated, what >> is the value in the security section for the MAC code? >> >> (I would assume zeroes..) >> >> Should any fields in the layer-3 (IPv6 base header) be skipped, the >> way that AH skips them? What about any extension headers present? >> >> As the recommended MUST is AES-CCM mode, which performs both >> integrity and encryption at the same time, I don't know how one can >> have the bytes under integrity check different from those that are >> encrypted. >> >> Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for some >> text to steal. Note that this might >> >> section 9.5.3.1: I have no idea where in the packet the nonce >> goes. Is it simply created as input into the CCM* star? Or does it >> have to be transmitted somewhere? (I don't think so) >> >> *** I am not happy with the lack of algorithm agility implied by >> RPL-10 *** >> >> 9.5.3.2: I am not happy with specification of a possibly >> encumbered elliptic curve here. Has then been a proper IPR >> disclosure? There is no algorithm agility available here either. > > Rene, can you respond to this? > > Phil > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From root@core3.amsl.com Fri Jul 9 13:00:02 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3CBDF3A68A9; Fri, 9 Jul 2010 13:00: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: <20100709200002.3CBDF3A68A9@core3.amsl.com> Date: Fri, 9 Jul 2010 13:00:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-08.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: , X-List-Received-Date: Fri, 09 Jul 2010 20:00:02 -0000 --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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-08.txt Pages : 30 Date : 2010-07-09 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-08.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-routing-metrics-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-09125630.I-D@ietf.org> --NextPart-- From gnawali@cs.stanford.edu Fri Jul 9 16:17:25 2010 Return-Path: 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 5E8C83A685A for ; Fri, 9 Jul 2010 16:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 1-cdGJoQcv9L for ; Fri, 9 Jul 2010 16:17:24 -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 A5DCF3A67D0 for ; Fri, 9 Jul 2010 16:17:24 -0700 (PDT) Received: from mail-gy0-f174.google.com ([209.85.160.174]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OXMoz-0002Oe-Sr for roll@ietf.org; Fri, 09 Jul 2010 16:17:30 -0700 Received: by gye5 with SMTP id 5so1589608gye.19 for ; Fri, 09 Jul 2010 16:17:28 -0700 (PDT) Received: by 10.150.2.11 with SMTP id 11mr2298894ybb.257.1278717448265; Fri, 09 Jul 2010 16:17:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.192.13 with HTTP; Fri, 9 Jul 2010 16:17:08 -0700 (PDT) From: Omprakash Gnawali Date: Fri, 9 Jul 2010 16:17:08 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Subject: [Roll] metric ordering according to draft-ietf-roll-routing-metrics-08 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: , X-List-Received-Date: Fri, 09 Jul 2010 23:17:25 -0000 "8. ... When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-brakers in the order that they appear in the DAG Metric Container. A node propagating a DAG Metric Container MUST keep the order of metric objects unchanged. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criterion, LQL as the secondary criterion and Fanout Ratio as the ultimate tie-braker. In such a case, the Hop-Count, LQL and Fanout Ratio metric objects need to appear in that order in the DAG Metric Container. ..." Is the semantics behind the ordering intentional? A packet could be forwarded from a node that prefers to use one set of objective to a node that prefers to use a different objective. For example, from a low power energy scavenging sensor to a powered node. Not allowing the nodes to change the order allows a node to dictate the relative importance of this metric to rest of the network without regard to their preference. If we had already considered that scenario and determined to be not important, it might be worth making the last sentence in the following paragraph stronger - are there other cases besides those mentioned in 8 and 3.2? "2. ... Note that the Routing Metric/Constraint objects defined in this document can appear in any order in the DAG Metric Container. However, for some of them, the order is significant (as described in Section 8 and Section 3.2, for example). " - om_p From stoleru@cse.tamu.edu Fri Jul 9 15:07:31 2010 Return-Path: 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 96B133A6937; Fri, 9 Jul 2010 15:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 dLEnrFvLAJlx; Fri, 9 Jul 2010 15:07:30 -0700 (PDT) Received: from smtp.cs.tamu.edu (postal.cs.tamu.edu [128.194.138.107]) by core3.amsl.com (Postfix) with ESMTP id 14A0B3A68DC; Fri, 9 Jul 2010 15:07:27 -0700 (PDT) Received: from [128.194.143.227] (radu-pc.cs.tamu.edu [128.194.143.227]) by smtp.cs.tamu.edu (Postfix) with ESMTP id 52B0C18FFD4; Fri, 9 Jul 2010 17:07:32 -0500 (CDT) Message-ID: <4C379D9F.8040507@cse.tamu.edu> Date: Fri, 09 Jul 2010 17:07:27 -0500 From: Radu Stoleru User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: sensorium@lists.stanford.edu, tinyos@millennium.berkeley.edu, MOBISYS@LISTSERV.ACM.ORG, tccn@comsoc.org, discuss-gnuradio@gnu.org, pvs@csl.sri.com, ecoop-info@ecoop.org, tcpp-announce@cc.gatech.edu, podc-related@acm.org, ahsntc-mailing-list@list.trlab.ca, mip4@ietf.org, mip6@ietf.org, roll@ietf.org, SIGMOBILE-MEMBERS@LISTSERV.ACM.ORG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Jul 2010 01:04:29 -0700 Subject: [Roll] Sensys 2010 - Call for Demos & Call for Doctoral Symposium Papers 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: , X-List-Received-Date: Fri, 09 Jul 2010 22:07:31 -0000 [Our apologies if you receive multiple copies of this posting] Please note the two announcements: Call for Demos, Call for Doctoral Symposium Papers ************************************************************************* ************************************************************************* ************************************************************************* SenSys 2010 Call for Demos November 2, 2010, ETH Zurich, Switzerland The demonstration session at SenSys is typically very well attended and is one of the highlights of the conference. If you are a systems researcher who is bored with producing slides, and you would rather show off great code, working systems, useful tools, crazy flying objects, new platforms, and any other technologies related to SenSys, then the demo session is the place for you! Past instances of SenSys have awarded prizes for the best demos and we plan to do the same in Zurich. Submissions from industry and universities are encouraged and an abstract for each accepted demo will be published in the SenSys proceedings. DEMO SUBMISSION INSTRUCTIONS Send a two-page description, in plain text or PDF, to: peizhang@cmu.edu and regehr@cs.utah.edu Please be as specific as possible in describing what you will show. IMPORTANT DATES: Two-page demo descriptions: 11:59pm (EST), July 25, 2010 Notification of acceptance: August 9, 2010 Camera-ready abstract: August 23, 2010 Conference dates: November 3-5, 2010 SenSys 2010 DEMO CHAIRS Pei Zhang (Carnegie Mellon University) John Regehr (University of Utah) ************************************************************************* ************************************************************************* ************************************************************************* CALL FOR SUBMISSIONS ** ACM Sensys 2010 Doctoral Colloquium ** November 2, 2010, ETH Zurich, Switzerland http://www.vs.inf.ethz.ch/events/sensys10dc/ The purpose of the doctoral colloquium (DC) is to provide a friendly, supportive, and constructive atmosphere where PhD students can present their research-in-progress for an open discussion, guided by a panel of experienced researchers and practitioners. Applicants should be far enough into their PhD to have a concrete proposal, and have initially outlined the salient issues and proposed research methodology. Applicants should not be planning to submit their PhD thesis or dissertation for at least six months after the DC, so that any advice or input may still be incorporated into the doctoral work. The DC will be a one-day, seminar-style event, consisting of short presentations followed by roundtable discussion. Time will be allotted to each student not only for the presentation, but also for careful, in-depth consideration and discussion amongst the panelists and DC participants. In order to provide such individual attention, the number of accepted DC participants will be limited to twelve. SUBMISSIONS Topic scope is the same as that listed in the SenSys call for papers. DC submissions should consist of a single PDF document using the SenSys paper template. The document should contain the following: 1) Research summary (3 pages) describing the work in progress, and including a 100 word abstract. Things to consider for inclusion in the research summary might be: the expected contribution to the field of sensor networking; the original idea or thesis statement; the problem domain and the specific problem addressed; a brief overview of related work; the methodological approach; research carried out and results so far. 2) Student biographical sketch, including the names and affiliations of the research advisor(s), and expected date of dissertation submission. The submission site is http://www.easychair.org/conferences/?conf=sensys2010doctoralcolloquium Research summaries will be reviewed by the chair and panel members. If accepted, a student may be expected to make clarifications and improvements to their research summary by the camera-ready deadline. Note that the research summaries will not be formally published, but hardcopies will be made available to colloquium delegates. IMPORTANT DATES Submission deadline: August 28, 2010 Notification: September 20, 2010 Camera-ready copy: October 18, 2010 Colloquium: November 2, 2010 ORGANIZERS Chair: Kay Roemer, University of Luebeck and ETH Zurich From mdurvy@cisco.com Mon Jul 12 01:08:26 2010 Return-Path: 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 D34743A698D for ; Mon, 12 Jul 2010 01:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.007 X-Spam-Level: X-Spam-Status: No, score=-10.007 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 K5DI0QhptrAw for ; Mon, 12 Jul 2010 01:08:25 -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 701E73A6A4F for ; Mon, 12 Jul 2010 01:08:25 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-AV: E=Sophos;i="4.55,186,1278288000"; d="p7s'?scan'208";a="131255487" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2010 08:08:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6C88VUr023247; Mon, 12 Jul 2010 08:08:32 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 10:08:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jul 2010 10:08:30 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0066_01CB21AA.29C4EE80" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C3A0@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD45C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue#56: Transit and Target address mismatch Thread-Index: Acsfdxc8k3tbkkoAQtuP//XeqeiSGgCIKQiw References: <6A2A459175DABE4BB11DE2026AA50A5D024CD45C@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" X-OriginalArrivalTime: 12 Jul 2010 08:08:32.0331 (UTC) FILETIME=[6B40C1B0:01CB2199] Cc: roll@ietf.org Subject: Re: [Roll] Closing issue#56: Transit and Target address mismatch 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: , X-List-Received-Date: Mon, 12 Jul 2010 08:08:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0066_01CB21AA.29C4EE80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, This sounds good! Few minor comments: - The R bit in PIO is used as in RFC3775 to indicate a (global/ULA) = address as opposed to a prefix.=20 [M] OK - The prefix is still valid for the purpose of autoconf when the R bit = is set. [M] OK - The address in the PIO can be used as transit parent by the children = but is not necessarily on link for the children. [M] Is it really a "can be used" or a "MUST"? - The router that advertises an address as parent in PIO must also = advertise that address as target in a DAO for the route recursion to = complete. [M] OK - An address that is advertised as target in a DAO must be collocated or = reachable onlink by the parent that is indicated in the associated = transit information. [M] Maybe we want to mention that when a node receives a DAO with a = transit address equal to its address it must remember the target as = on-link? - A new flag in the transit information qualifies a target address that = is behind a router, either as an attached host or installed on another = interface. The router is the tunnel endpoint for such address. [M] Yes, I guess this would make sense Will that be enough to close 56? [M] Yes, thanks a lot for your help in clarifying these points! Best, Mathilde > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of roll > issue tracker > Sent: Tuesday, July 06, 2010 1:41 PM > To: wintert@acm.org; jpv@cisco.com > Cc: roll@ietf.org > Subject: [Roll] [roll] #56: Transit and Target address mismatch >=20 > #56: [Roll] Transit and Target address mismatch > = -----------------------------+------------------------------------------ > -----------------------------+---- > Reporter: jpv@=E2=80=A6 | Owner: wintert@=E2=80=A6 > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: rpl | Version: > Severity: In WG Last Call | Keywords: > = -----------------------------+------------------------------------------ > -----------------------------+---- > Hi All, >=20 > Let=E2=80=99s consider the storing mode in a simple topology = A=C3=A0B=C3=A0R (=C3=A0 mark the > parent relationship). Let=E2=80=99s also assume that A has a prefix = =E2=80=98Ap=E2=80=99 and a global > address =E2=80=98Ag=E2=80=99 to advertise. > In this example we have: > - A sends DAO with =E2=80=9Ctarget Ag, Ap, transit B=E2=80=9D > - B sends DAO with =E2=80=9Ctarget Bg, transit R=E2=80=9D together = with the information from > A, i.e. =E2=80=9Ctarget Ag, Ap, transit B=E2=80=9D >=20 > Then R recombines the information to get the route to for example Ap = (Target > Ap, transit B, target Bg, transit R) For this to work, transit B and = target Bg need > to be matched. How can this be done? Does it mean that the transit = parent > address has to be a global address? This would imply that we use = global > addresses in the routing header. However 6man-rpl-routing-header = says: > =E2=80=9CWhen processing the Type 4 Routing header, a router MUST = drop the packet > if the next entry is not on-link=E2=80=9D > As global addresses have to be off-link in NBMA network like = 802.15.4, I see a > problem=E2=80=A6 >=20 > Can you please clarify how addresses are supposed to be used in this = source- > routing scenario. >=20 > Thanks, > Mathilde >=20 > -- > Ticket URL: > roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0066_01CB21AA.29C4EE80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMjA4MDgyM1owIwYJKoZIhvcNAQkEMRYEFKeeHQmFCyo9Zoc8 Tx2gi1UHd3cOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGApeAkiV/F1gND/5t+YOdLZL0AZQvaWCiw 12L9UfNeAlxMSlP7MDT1XXE1zvbD8hycI1ngqAc5d0QENZAoHoQPuriHmnapx8qxDSqmNU8SrQcR bjEcdRrXcnY85TSIwLfkw8arJVEN44s+7NpPVkIa322o5K3TfLqkf9gawLYObaoAAAAAAAA= ------=_NextPart_000_0066_01CB21AA.29C4EE80-- From pthubert@cisco.com Mon Jul 12 01:31:08 2010 Return-Path: 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 311553A6A8F for ; Mon, 12 Jul 2010 01:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] 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 dNsp4F9Espwv for ; Mon, 12 Jul 2010 01:31: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 BDD7E3A6A98 for ; Mon, 12 Jul 2010 01:30:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN5vOkxAZnwN/2dsb2JhbACgOHGibJl3hScEino X-IronPort-AV: E=Sophos;i="4.55,187,1278288000"; d="scan'208";a="131238417" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 08:30:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6C8Uit7015618; Mon, 12 Jul 2010 08:30:45 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 10:30:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 10:30:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD632@XMB-AMS-107.cisco.com> In-Reply-To: <87tyo8fwgg.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication thread-index: AcsfhC36Ys97pg/QTimojus5mYBshwCFKkpg References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com><8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> <87tyo8fwgg.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 12 Jul 2010 08:30:45.0614 (UTC) FILETIME=[85F398E0:01CB219C] Cc: roll@ietf.org Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Mon, 12 Jul 2010 08:31:08 -0000 Hi Richard: I agree there's no magic. The ingress router must have a policy of some sort that indicates how the system is expected to work.=20 The policy can say that the flow label in the ingress packet has the instanceID already, or that the instanceID is derived by some specified computation from the IP header or even deep packet inspection that would recognize the application flows. All of those methods are already practiced for route mapping and traffic engineering, in particular for voice and video. I think I mentioned earlier that there is a lot in common between sensor data and voice though the scale is different. In the end, the result is always the same and that's where our own specification comes into play. We remark that with the HbH and the RH, all incoming packets are encapsulated. If so, the ingress router owns the outer IP header, so it can safely place the instanceID in the flow label all the time, which makes our spec simpler.=20 If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the RPL Hop-by-hop option. -> An ingress router that injects packets into the RPL network has to encapsulate the packet IP in IP to add the RPL=20 Hop-by-hop option and eventually a Routing header.=20 The ingress router MUST add a RPLInstanceID field to the flow label of the outer header. For short term, I expect 3 forms of policies: - single instance (0): The all RPL network has only one instance, that is well known by all routers, probably 0. - flow label: The endpoints are aware of an abstraction of the instance and place it in the flow label. The ingress router copies the flow label from inner to outer header and route along that instance.=20 - destination: When all traffic flows via a root from/to an infrastructure. A given root has only one DODAG to its uses the associated instance. An ingress router at the edge of the network matches DODAGID and RIO routes, and picks the instanceID that has the longest match. In it not unlawful to have a RIO with default route to indicates the highest preference DODAG for default as well. There can be tons of other policies, like there can be numerous OCP/OF. What's key for us is that we know which node is responsible to place the instance ID in the packet and where it places it, so we can safely use it through the RPL network. Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Friday, July 09, 2010 6:32 PM > To: Pascal Thubert (pthubert) > Cc: Mathilde Durvy (mdurvy); roll@ietf.org > Subject: Re: [Roll] Use of tunnels and end point determication >=20 > > Date: Fri, 9 Jul 2010 17:42:47 +0200 > > From: "Pascal Thubert (pthubert)" > > > > [Pascal] -10 allows both but it seems redundant. Since the instance > > has to be in the flow label for an end point to indicate it, then why > > not let it there all the time? If the ingress router has to figure out > > the instance ID by some magic, in any fashion it can place the result > > in the flow label. >=20 > Pascal, >=20 > I don't see how this works. The RPL draft says: >=20 > If the RPLInstanceID is not present in flow label of the > data packet, the ingress router that injects the packet > into the RPL network MUST add a RPLInstanceID field to > the RPL Hop-by-hop option. >=20 > How does the ingress router determine whether or not the flow label contains a > RPLInstanceID? It isn't safe to assume that any non-zero flow label is > necessarily a RPLInstanceID. > -Richard From pthubert@cisco.com Mon Jul 12 02:07:08 2010 Return-Path: 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 874613A6774 for ; Mon, 12 Jul 2010 02:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 LJPgJxlBPrbm for ; Mon, 12 Jul 2010 02:07:07 -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 3F3DC3A6403 for ; Mon, 12 Jul 2010 02:07:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,187,1278288000"; d="scan'208";a="131247038" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 09:07:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6C978vo029640; Mon, 12 Jul 2010 09:07:14 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 11:07:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 12 Jul 2010 11:07:05 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD694@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C3A0@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue#56: Transit and Target address mismatch thread-index: Acsfdxc8k3tbkkoAQtuP//XeqeiSGgCIKQiwAAJSwhA= References: <6A2A459175DABE4BB11DE2026AA50A5D024CD45C@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C3A0@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 12 Jul 2010 09:07:08.0939 (UTC) FILETIME=[9B508DB0:01CB21A1] Cc: roll@ietf.org Subject: Re: [Roll] Closing issue#56: Transit and Target address mismatch 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: , X-List-Received-Date: Mon, 12 Jul 2010 09:07:08 -0000 SGkgTWF0aGlsZGUNCg0KPiANCj4gRmV3IG1pbm9yIGNvbW1lbnRzOg0KPiAtIFRoZSBSIGJpdCBp biBQSU8gaXMgdXNlZCBhcyBpbiBSRkMzNzc1IHRvIGluZGljYXRlIGEgKGdsb2JhbC9VTEEpIGFk ZHJlc3MgYXMNCj4gb3Bwb3NlZCB0byBhIHByZWZpeC4NCj4gW01dIE9LDQo+IC0gVGhlIHByZWZp eCBpcyBzdGlsbCB2YWxpZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYXV0b2NvbmYgd2hlbiB0aGUgUiBi aXQgaXMgc2V0Lg0KPiBbTV0gT0sNCj4gLSBUaGUgYWRkcmVzcyBpbiB0aGUgUElPIGNhbiBiZSB1 c2VkIGFzIHRyYW5zaXQgcGFyZW50IGJ5IHRoZSBjaGlsZHJlbiBidXQgaXMgbm90DQo+IG5lY2Vz c2FyaWx5IG9uIGxpbmsgZm9yIHRoZSBjaGlsZHJlbi4NCj4gW01dIElzIGl0IHJlYWxseSBhICJj YW4gYmUgdXNlZCIgb3IgYSAiTVVTVCI/DQoNCltQYXNjYWxdIFRoZSBwYXJlbnQgaW4gdGhlIHRy YW5zaXQgTVVTVCBiZSBwaWNrZWQgZnJvbSBhIHBhcmVudCBQSU8uICBCdXQgYSBub2RlIGNhbiBp Z25vcmUgdGhlIFBJTyBpZiB0aGF0IHBhcmVudHMgaGFzIG11bHRpcGxlIFBJT3Mgb3IgaWYgdGhl IG5vZGUgZG9lcyBub3Qgd2FudCB0byBpc2UgdGhhdCBwYXJlbnQgYXMgREFPIHBhcmVudC4gU28g d2UgY2FuIHBsYWNlIGEgTVVTVCBidXQgd2UgbmVlZCB0byByZXZlcnNlIHRoZSBzZW50ZW5jZS4N Cg0KPiAtIFRoZSByb3V0ZXIgdGhhdCBhZHZlcnRpc2VzIGFuIGFkZHJlc3MgYXMgcGFyZW50IGlu IFBJTyBtdXN0IGFsc28gYWR2ZXJ0aXNlDQo+IHRoYXQgYWRkcmVzcyBhcyB0YXJnZXQgaW4gYSBE QU8gZm9yIHRoZSByb3V0ZSByZWN1cnNpb24gdG8gY29tcGxldGUuDQo+IFtNXSBPSw0KPiAtIEFu IGFkZHJlc3MgdGhhdCBpcyBhZHZlcnRpc2VkIGFzIHRhcmdldCBpbiBhIERBTyBtdXN0IGJlIGNv bGxvY2F0ZWQgb3INCj4gcmVhY2hhYmxlIG9ubGluayBieSB0aGUgcGFyZW50IHRoYXQgaXMgaW5k aWNhdGVkIGluIHRoZSBhc3NvY2lhdGVkIHRyYW5zaXQNCj4gaW5mb3JtYXRpb24uDQo+IFtNXSBN YXliZSB3ZSB3YW50IHRvIG1lbnRpb24gdGhhdCB3aGVuIGEgbm9kZSByZWNlaXZlcyBhIERBTyB3 aXRoIGEgdHJhbnNpdA0KPiBhZGRyZXNzIGVxdWFsIHRvIGl0cyBhZGRyZXNzIGl0IG11c3QgcmVt ZW1iZXIgdGhlIHRhcmdldCBhcyBvbi1saW5rPw0KW1Bhc2NhbF0gDQpbUGFzY2FsXSBTdXJlLiBU aGlzIGlzIHJlYWxseSB3aGVuIHBsYWNpbmcgYSBTTExBTyBpbiB0aGUgREFPIHdvdWxkIGhhdmUg bWFkZSBhIGxvdCBvZiBzZW5zZS4gTm93IHRoZSBwYXJlbnQgaGFzIHRvIHN1cHBvcnQgTlMvTkEu DQoNCj4gLSBBIG5ldyBmbGFnIGluIHRoZSB0cmFuc2l0IGluZm9ybWF0aW9uIHF1YWxpZmllcyBh IHRhcmdldCBhZGRyZXNzIHRoYXQgaXMgYmVoaW5kIGENCj4gcm91dGVyLCBlaXRoZXIgYXMgYW4g YXR0YWNoZWQgaG9zdCBvciBpbnN0YWxsZWQgb24gYW5vdGhlciBpbnRlcmZhY2UuIFRoZSByb3V0 ZXINCj4gaXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3Igc3VjaCBhZGRyZXNzLg0KPiBbTV0gWWVz LCBJIGd1ZXNzIHRoaXMgd291bGQgbWFrZSBzZW5zZQ0KPiANCj4gV2lsbCB0aGF0IGJlIGVub3Vn aCB0byBjbG9zZSA1Nj8NCj4gW01dIFllcywgdGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAgaW4g Y2xhcmlmeWluZyB0aGVzZSBwb2ludHMhDQo+IA0KW1Bhc2NhbF0gIDogKQ0KDQo+IA0KPiANCj4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHJvbGwtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJvbGwNCj4g PiBpc3N1ZSB0cmFja2VyDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAwNiwgMjAxMCAxOjQxIFBN DQo+ID4gVG86IHdpbnRlcnRAYWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiA+IENjOiByb2xsQGll dGYub3JnDQo+ID4gU3ViamVjdDogW1JvbGxdIFtyb2xsXSAjNTY6IFRyYW5zaXQgYW5kIFRhcmdl dCBhZGRyZXNzIG1pc21hdGNoDQo+ID4NCj4gPiAjNTY6IFtSb2xsXSBUcmFuc2l0IGFuZCBUYXJn ZXQgYWRkcmVzcyBtaXNtYXRjaA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0NCj4gPiAgUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAg ICAgfCAgICAgICBPd25lcjogIHdpbnRlcnRA4oCmDQo+ID4gICAgICBUeXBlOiAgZW5oYW5jZW1l bnQgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3DQo+ID4gIFByaW9yaXR5OiAgbWlub3IgICAgICAg ICAgICB8ICAgTWlsZXN0b25lOg0KPiA+IENvbXBvbmVudDogIHJwbCAgICAgICAgICAgICAgfCAg ICAgVmVyc2lvbjoNCj4gPiAgU2V2ZXJpdHk6ICBJbiBXRyBMYXN0IENhbGwgIHwgICAgS2V5d29y ZHM6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLQ0KPiA+ICBIaSBBbGwsDQo+ID4NCj4gPiAgTGV04oCZcyBjb25zaWRlciB0aGUgc3Rv cmluZyBtb2RlIGluIGEgc2ltcGxlIHRvcG9sb2d5IEHDoELDoFIgKMOgIG1hcmsgdGhlDQo+ID4g cGFyZW50IHJlbGF0aW9uc2hpcCkuIExldOKAmXMgYWxzbyBhc3N1bWUgdGhhdCBBIGhhcyBhIHBy ZWZpeCDigJhBcOKAmSBhbmQgYSAgZ2xvYmFsDQo+ID4gYWRkcmVzcyDigJhBZ+KAmSB0byBhZHZl cnRpc2UuDQo+ID4gIEluIHRoaXMgZXhhbXBsZSB3ZSBoYXZlOg0KPiA+ICAtIEEgc2VuZHMgREFP IHdpdGgg4oCcdGFyZ2V0IEFnLCBBcCwgdHJhbnNpdCBC4oCdDQo+ID4gIC0gQiBzZW5kcyBEQU8g d2l0aCDigJx0YXJnZXQgQmcsIHRyYW5zaXQgUuKAnSB0b2dldGhlciB3aXRoIHRoZSBpbmZvcm1h dGlvbg0KPiBmcm9tDQo+ID4gQSwgaS5lLiDigJx0YXJnZXQgQWcsIEFwLCB0cmFuc2l0IELigJ0N Cj4gPg0KPiA+ICBUaGVuIFIgcmVjb21iaW5lcyB0aGUgaW5mb3JtYXRpb24gdG8gZ2V0IHRoZSBy b3V0ZSB0byBmb3IgZXhhbXBsZSBBcA0KPiAoVGFyZ2V0DQo+ID4gQXAsIHRyYW5zaXQgQiwgdGFy Z2V0IEJnLCB0cmFuc2l0IFIpICBGb3IgdGhpcyB0byB3b3JrLCB0cmFuc2l0IEIgYW5kIHRhcmdl dCBCZw0KPiBuZWVkDQo+ID4gdG8gYmUgbWF0Y2hlZC4gSG93IGNhbiB0aGlzICBiZSBkb25lPyBE b2VzIGl0IG1lYW4gdGhhdCB0aGUgdHJhbnNpdCBwYXJlbnQNCj4gPiBhZGRyZXNzIGhhcyB0byBi ZSBhIGdsb2JhbCAgYWRkcmVzcz8gVGhpcyB3b3VsZCBpbXBseSB0aGF0IHdlIHVzZSBnbG9iYWwN Cj4gPiBhZGRyZXNzZXMgaW4gdGhlIHJvdXRpbmcgIGhlYWRlci4gSG93ZXZlciA2bWFuLXJwbC1y b3V0aW5nLWhlYWRlciBzYXlzOg0KPiA+ICDigJxXaGVuIHByb2Nlc3NpbmcgdGhlIFR5cGUgNCBS b3V0aW5nIGhlYWRlciwgYSByb3V0ZXIgTVVTVCBkcm9wIHRoZQ0KPiBwYWNrZXQNCj4gPiBpZiB0 aGUgbmV4dCBlbnRyeSBpcyBub3Qgb24tbGlua+KAnQ0KPiA+ICBBcyBnbG9iYWwgYWRkcmVzc2Vz IGhhdmUgdG8gYmUgb2ZmLWxpbmsgaW4gTkJNQSBuZXR3b3JrIGxpa2UgODAyLjE1LjQsIEkgIHNl ZQ0KPiBhDQo+ID4gcHJvYmxlbeKApg0KPiA+DQo+ID4gIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkg aG93IGFkZHJlc3NlcyBhcmUgc3VwcG9zZWQgdG8gYmUgdXNlZCBpbiB0aGlzICBzb3VyY2UtDQo+ ID4gcm91dGluZyBzY2VuYXJpby4NCj4gPg0KPiA+ICBUaGFua3MsDQo+ID4gIE1hdGhpbGRlDQo+ ID4NCj4gPiAtLQ0KPiA+IFRpY2tldCBVUkw6IDxodHRwczovL3N2bi50b29scy5pZXRmLm9yZy93 Zy9yb2xsL3RyYWMvdGlja2V0LzU2Pg0KPiA+IHJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93 Zy9yb2xsLz4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gPiBSb2xsQGlldGYub3JnDQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From mdurvy@cisco.com Mon Jul 12 02:08:54 2010 Return-Path: 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 A81843A690A for ; Mon, 12 Jul 2010 02:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.371 X-Spam-Level: X-Spam-Status: No, score=-9.371 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 phrdhry2X6YQ for ; Mon, 12 Jul 2010 02:08:50 -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 C28693A6840 for ; Mon, 12 Jul 2010 02:08:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.gif, smime.p7s : 837, 87, 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAAN5OkxAZnwM/2dsb2JhbACBQpI0jEJxolmZdwKFJQSKeg X-IronPort-AV: E=Sophos;i="4.55,187,1278288000"; d="gif'147?p7s'147?scan'147,208,217,147";a="131269928" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2010 09:08:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6C98uAc001144 for ; Mon, 12 Jul 2010 09:08:56 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 11:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jul 2010 11:08:55 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007F_01CB21B2.9DEC1060" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279C44C@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More questions on DAO Thread-Index: AcshodpSDqKkQ1SPSqmLkwAo1Ikx+g== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 12 Jul 2010 09:08:56.0472 (UTC) FILETIME=[DB68C980:01CB21A1] Subject: [Roll] More questions on DAO 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: , X-List-Received-Date: Mon, 12 Jul 2010 09:08:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01CB21B2.9DEC1060 Content-Type: multipart/related; boundary="----=_NextPart_001_0080_01CB21B2.9DEC1060" ------=_NextPart_001_0080_01CB21B2.9DEC1060 Content-Type: multipart/alternative; boundary="----=_NextPart_002_0081_01CB21B2.9DEC1060" ------=_NextPart_002_0081_01CB21B2.9DEC1060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 A few more questions on DAOs: =20 - What is the DAO parent selection criteria for OCP0? Same as for DIO parents I assume. - What actions need to be taken by a node that didn=92t get a DAO-ACK = response when setting the K bit? - Section 16.2.6 (which deals with configuration) introduces some terminology not used in the spec (e.g UNREACHABLE state). Is this some legacy text? - When should a node initiate (i.e. not propagate) an increase in DTSN? - =93Multicast DAOs MUST NOT include Transit Information options=94 = (Section 8.6). Do you mean =93MUST not include a parent address in the transit information option=94? =20 Best, Mathilde =20 =20 =20 http://www.cisco.com/swa/i/logo.gif Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 Think before you print.Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message. ------=_NextPart_002_0081_01CB21B2.9DEC1060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

A few more questions on DAOs:

 

- What is the DAO parent selection criteria for = OCP0? Same as for DIO parents I assume.

- What actions need to be taken by a node that = didn’t get a DAO-ACK response when setting the K bit?

- Section 16.2.6 (which deals with configuration) = introduces some terminology not used in the spec (e.g UNREACHABLE state). Is this = some legacy text?

- When should a node initiate (i.e. not propagate) = an increase in DTSN?

- “Multicast DAOs MUST NOT include Transit = Information options” (Section 8.6). Do you mean “MUST not include a = parent address in the transit information option”?

 

Best,

Mathilde

 

 

 

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco = home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain confidential and privileged material for the sole use of = the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender = by reply e-mail and delete all copies of this = message.


------=_NextPart_002_0081_01CB21B2.9DEC1060-- ------=_NextPart_001_0080_01CB21B2.9DEC1060 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_0080_01CB21B2.9DEC1060 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_0080_01CB21B2.9DEC1060-- ------=_NextPart_000_007F_01CB21B2.9DEC1060 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMjA5MDg1NFowIwYJKoZIhvcNAQkEMRYEFNDWktaq2jDK35Z/ jZnw8if3pz5pMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGADjodVShSzaOz9fcBN6SFDD0BblKn8H7S w/bwgqlWre/KpevlVZTcg0aXiMkFA+IAs4LKdsaR2lf63Q8GMeH7vrGIQeGIajocoC7u8zU7yDwB QVvfKKLRqKx60icLdLIB4IA6zQ5YqJjrpixrCsk15hbkzDX8emh5r/WqQytx69oAAAAAAAA= ------=_NextPart_000_007F_01CB21B2.9DEC1060-- From pthubert@cisco.com Mon Jul 12 07:38:35 2010 Return-Path: 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 E19B23A67DB for ; Mon, 12 Jul 2010 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.139 X-Spam-Level: X-Spam-Status: No, score=-10.139 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 O4hFwGmYKBc8 for ; Mon, 12 Jul 2010 07:38:30 -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 E13D73A63EC for ; Mon, 12 Jul 2010 07:38:29 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAGXGOkxAZnwM/2dsb2JhbACBQ557caRhmkmFJwSKeg X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208,217";a="131378147" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 Jul 2010 14:30:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6CEUARt006603 for ; Mon, 12 Jul 2010 14:30:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 16:30:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21CE.BC91F630" Date: Mon, 12 Jul 2010 16:30:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CD8F5@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] More questions on DAO thread-index: Acshzrj/WADjYdvCTwWluutqfxykdQ== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , X-OriginalArrivalTime: 12 Jul 2010 14:30:12.0398 (UTC) FILETIME=[BCC1ACE0:01CB21CE] Subject: Re: [Roll] More questions on DAO 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: , X-List-Received-Date: Mon, 12 Jul 2010 14:38:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21CE.BC91F630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Mathilde =20 - What is the DAO parent selection criteria for OCP0? Same as for DIO parents I assume. [Pascal] OF0 only mandates one preferred parent with good enough bidirectional connectivity, and it enables a backup if one is available. So yes, there's little choice but pick it as DAO parent as well. The draft could have an additional sentence to say that I admit. =20 - What actions need to be taken by a node that didn't get a DAO-ACK response when setting the K bit? [Pascal] We have to refine that text in 11 for sure. Only new information is sent asynchronously to the DAO parents while the full information is sent in demand (upon DTSN or new version). In short, the rich implementation can maintain per parent what was acknowledged and flag it as not new. The constrained implementation sends the delta once and flag it as not new without an ack, waiting for the next full information to fill the gaps. So basically when something new is learnt, the storing router arms a timer to schedule a DAO. When the timer elapses, the router sends all new information to the parents. The timer keeps elapsing for a given parent till the parent acks the most recent DAO sequence sent to it or the router gives up. If the router gives up, the parent is out of sync till the next change or full information updates it. The path sequence that circulates via other parents that are not out of sync is fresher and enables the ancestors to select the usable path. =20 - Section 16.2.6 (which deals with configuration) introduces some terminology not used in the spec (e.g UNREACHABLE state). Is this some legacy text? [Pascal] It is. That state was in the FSM that went down the sink around 08 =20 - When should a node initiate (i.e. not propagate) an increase in DTSN? [Pascal] Can be upon an inconsistency detection, or upon an internal timer per policy though that is not mandated. An inconsistency can be an RPF check, a DAO entry not revalidated, a datapath validation failure. New DSTN should be caped in time. =20 - "Multicast DAOs MUST NOT include Transit Information options" (Section 8.6). Do you mean "MUST not include a parent address in the transit information option"? [Pascal] Oups! Correct. We sometime need the lifetime. =20 Best, =20 Pascal ------_=_NextPart_001_01CB21CE.BC91F630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Mathilde

 

- = What is the DAO parent selection criteria for OCP0? Same as for DIO = parents I assume.

[Pascal] OF0 = only mandates one preferred parent with good enough bidirectional = connectivity, and it enables a backup if one is available. So yes, = there’s little choice but pick it as DAO parent as well. The draft = could have an additional sentence to say that I = admit.

 

- What actions need to be taken by a = node that didn’t get a DAO-ACK response when setting the K = bit?

[Pascal] We = have to refine that text in 11 for sure. Only new information is sent = asynchronously to the DAO parents while the full information is sent in = demand (upon DTSN or new version). In short, the rich implementation can = maintain per parent what was acknowledged and flag it as not new. The = constrained implementation sends the delta once and flag it as not new = without an ack, waiting for the next full information to fill the gaps. = So basically when something new is learnt, the storing router arms a = timer to schedule a DAO. When the timer elapses, the router sends all = new information to the parents. The timer keeps elapsing for a given = parent till the parent acks the most recent DAO sequence sent to it or = the router gives up. If the router gives up, the parent is out of sync = till the next change or full information updates it. The path sequence = that circulates via other parents that are not out of sync is fresher = and enables the ancestors to select the usable = path.

 

- Section 16.2.6 (which deals with = configuration) introduces some terminology not used in the spec (e.g = UNREACHABLE state). Is this some legacy text?

[Pascal] It = is. That state was in the FSM that went down the sink around = 08

 

- When should a node initiate (i.e. = not propagate) an increase in DTSN?

[Pascal] Can = be upon an inconsistency detection, or upon an internal timer per policy = though that is not mandated. An inconsistency can be an RPF check, a DAO = entry not revalidated, a datapath validation failure. New DSTN should be = caped in time.

 

- “Multicast DAOs MUST NOT = include Transit Information options” (Section 8.6). Do you mean = “MUST not include a parent address in the transit information = option”?

[Pascal] = Oups! Correct. We sometime need the = lifetime.

 

Best,

 

Pascal<= /i>

------_=_NextPart_001_01CB21CE.BC91F630-- From jpv@cisco.com Mon Jul 12 10:01:46 2010 Return-Path: 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 A84583A6B6B for ; Mon, 12 Jul 2010 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.04 X-Spam-Level: X-Spam-Status: No, score=-9.04 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gLSBzrq1kV6h for ; Mon, 12 Jul 2010 10:01:44 -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 1AE9E3A69BF for ; Mon, 12 Jul 2010 10:01:43 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAGbnOkxAZnwN/2dsb2JhbACBQ559caU2mlwChSUEiEyCLg X-IronPort-AV: E=Sophos;i="4.55,189,1278288000"; d="scan'208,217";a="131409818" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 16:42:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6CGgr3h008640 for ; Mon, 12 Jul 2010 16:42:54 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:42:54 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:42:53 +0200 Message-Id: <72818E15-1AD8-4C9C-A1BB-161C17D2F335@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-75--1938244 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Jul 2010 18:42:52 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Jul 2010 16:42:53.0353 (UTC) FILETIME=[45DB0190:01CB21E1] Cc: ROLL WG Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Mon, 12 Jul 2010 17:01:46 -0000 --Apple-Mail-75--1938244 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Pascal, I think that you really complicated what is indeed much more simple. =20 Let work on a text with illustrations that will show the overall picture. I'll call you. JP. On Jul 9, 2010, at 12:00 PM, Pascal Thubert (pthubert) wrote: > Dear WG: > > It might not strike the eye going through the base spec but most =20 > packets that fly through a RPL network are encapsulated, IP in IP. =20 > The generic reason is the need to insert / remove the Hop by hop =20 > header defined draft-hui-6man-rpl-option. There=92s also the need for =20= > the root to insert a routing header in non-storing mode. This is =20 > what we can call tunnel mode. > This seems true for packets originating outside or terminating =20 > outside the RPL network. An exception to this rule could be packets =20= > that will be from and to routers or leaves of a same RPL network, =20 > because in that case, the originator can place the Hop by hop and =20 > eventually the routing header as it forms the packet, without IP in =20= > IP encapsulation. Something we could call transport mode, or native =20= > mode, or insider mode ? > > Anyway it appears that the spec could be clearer in: > 1. Explaining why IP in IP is used in general > 2. Specifying the rules to determine if a destination is =20 > inside the RPL network > 3. Specifying tunnel mode operation > 4. Specifying transport mode operation and when it can be used > 5. Specifying how to determine the tunnel endpoint in tunnel =20 > mode > > Proposal: > > 1) RPL needs an instance ID in the flow label, and HbH header, =20= > and eventually a routing header in every packet for routing and =20 > inconsistency determination. The HbH and RH are nonsensical outside =20= > the RPL network and can only be present inside the RPL network. The =20= > only clean way to insert and remove those headers is to use a tunnel =20= > mode (IP in IP encapsulation) whereby the router places the RPL =20 > headers before the inner header, leaving the original packet =20 > untouched. > a. A source inside the RPL network (router or leaf) places the =20= > RPL headers and flow label in the packet, either in tunnel or =20 > transport mode. > b. For packets originated outside the RPL network, the first =20 > RPL router (called ingress router) has to place this information in =20= > the packet in tunnel mode > c. Further RPL routers find the information and use it. They =20 > do not re-encapsulate, they do not change the flow label, they =20 > happen to modify the RPL headers. > d. The tunnel endpoint decapsulates before forwarding the inner =20= > packet. This strips the RPL information from the packet. If the =20 > packet is reinserted into the RPL network then there is a risk of a =20= > loop. > > 2) A destination is in the same RPL network if: > a. The destination is the root of the DODAG (all modes) > b. The destination is in the same Subnet as the source (derived =20= > from a PIO) (storing mode only) > c. The node is a router that has a DAO state indicating that =20 > the destination is a child (storing mode only) > d. The destination has been seen as tunnel endpoint and thus is =20= > a DAO ancestor (storing mode only). > > > 3) A RPL router that injects a packet without the HbH option =20 > into the RPL network is an ingress router. > a. An ingress router MUST place the RPL information in the =20 > packet in tunnel mode > b. An ingress router MUST place the instance ID in the flow =20 > label of the outer header > c. An ingress router MUST use one of its global addresses from =20= > the RPL domain as source > d. An ingress router MUST use a tunnel endpoint that is in the =20= > same RPL network (rules above). > > 4) A RPL node MUST place the RPL information in every packet =20 > that is sources. It can safely use tunnel mode for all packets. It =20 > MAY use transport mode when it determines that the destination is a =20= > RPL leaf or router within the same RPL network. In transport mode, =20 > the outer headers are built as follows: > a. The source MUST place the instance ID in the flow label of =20= > the IPv6 header > b. The source MUST use one of its global addresses from the RPL =20= > domain as source > c. The destination MUST be is in the same RPL network (rules =20 > above). > > 5) The tunnel endpoint is determined as follows: > a. If the destination is in the RPL network (rules above) then =20= > the endpoint is the destination > b. If the destination is a host attached to a RPL router then =20 > the endpoint is that RPL router > c. Else the endpoint is the root > > It appears that the b) is not supported correctly with the current =20 > spec since we do not have a way to inject a route to an external =20 > host while indicating that the host is not a leaf. > Probably the router would present itself as parent in a transit =20 > option, with a bit saying that the targets as non rpl hosts. > > Opinions? > > > Pascal Thubert > IPv6 Engineering > Product Development > pthubert@cisco.com > Phone: +33 4 9723 2634 > Mobile: +33 6 1998 2985 > > > Cisco Systems France > Village d'Entreprises Green Side > 400 Avenue de Roumanille > Batiment T 3 > 06410 > BIOT - SOPHIA ANTIPOLIS > France > Cisco.com > > > Think before you print. > > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille =20 > Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les =20 > Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, =20 > Directeur de la publication: Jean-Luc Michel Givone, For corporate =20 > legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-75--1938244 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal,

I = think that you really complicated what is indeed much more simple. Let = work on a text with illustrations that
will show the overall = picture. I'll call = you.

JP.

On Jul 9, = 2010, at 12:00 PM, Pascal Thubert (pthubert) wrote:

Dear WG:
It might not strike the eye going = through the base spec but most packets that fly through a RPL network = are encapsulated, IP in IP. The generic reason is the need to insert / =  remove the Hop by hop header defined draft-hui-6man-rpl-option. = There=92s also the need for the root to insert a routing header in = non-storing mode. This is what we can call tunnel = mode.
This seems true for packets originating outside = or terminating outside the RPL network. An exception to this rule could = be packets that will be from and to routers or leaves of a same RPL = network, because in that case, the originator can place the Hop by hop = and eventually the routing header as it forms the packet, without IP in = IP encapsulation. Something we could call transport mode, or native = mode, or insider mode ?
 
1. Explaining = why IP in IP is used in general
       Specifying = the rules to determine if a destination is inside the RPL = network
3. Specifying = tunnel mode operation
       Specifying = transport mode operation and when it can be used
5. Specifying = how to determine the tunnel endpoint in tunnel mode
Proposal:
1) RPL needs an = instance ID in the flow label, and HbH header, and eventually a routing = header in every packet for routing and inconsistency determination. The = HbH and RH are nonsensical outside the RPL network and can only be = present inside the RPL network. The only clean way to insert and remove = those headers is to use a tunnel mode (IP in IP encapsulation) whereby = the router places the RPL headers before the inner header, leaving the = original packet untouched.
       A source = inside the RPL network (router or leaf) places the RPL headers and flow = label in the packet, either in tunnel or transport = mode.
b. For packets = originated outside the RPL network, the first RPL router (called ingress = router) has to place this information in the packet in tunnel = mode
c. Further RPL = routers find the information and use it. They do not re-encapsulate, = they do not change the flow label, they happen to modify the RPL = headers.
d. The tunnel = endpoint decapsulates before forwarding the inner packet. This strips = the RPL information from the packet. If the packet is reinserted into = the RPL network then there is a risk of a loop.
2) A destination = is in the same RPL network if:
       The = destination is the root of the DODAG (all modes)
b.      The = destination is in the same Subnet as the source (derived from a PIO) =  (storing mode only)
       The node is a = router that has a DAO state indicating that the destination is a child = (storing mode only)
      The = destination has been seen as tunnel endpoint and thus is a DAO ancestor = (storing mode only).
 
3)      A RPL router = that injects a packet without the HbH option into the RPL network is an = ingress router.  
       An ingress = router MUST place the RPL information in the packet in tunnel = mode
b. An ingress = router MUST place the instance ID in the flow label of the outer = header
c. An ingress = router MUST use one of its global addresses from the RPL domain as = source
d. An ingress = router MUST use a tunnel endpoint that is in the same RPL network (rules = above).
 
4)      A RPL node = MUST place the RPL information in every packet that is sources. It can = safely use tunnel mode for all packets. It MAY use transport mode when = it determines that the destination is a RPL leaf or router within the = same RPL network. In transport mode, the outer headers are built as = follows:
a. The source = MUST place the instance ID in the flow label of the IPv6 = header
b. The source = MUST use one of its global addresses from the RPL domain as = source
c. The = destination MUST be is in the same RPL network (rules = above).
 
5)      The tunnel = endpoint is determined as follows:
a. If the = destination is in the RPL network (rules above) then the endpoint is the = destination
b. If the = destination is a host attached to a RPL router then the endpoint is that = RPL router
c. Else the = endpoint is the root
It appears that the b) is not = supported correctly with the current spec since we do not have a way to = inject a route to an external host while indicating that the host is not = a leaf.
Probably the router would present = itself as parent in a transit option, with a bit saying that the targets = as non rpl hosts.
 
 

Pascal = Thubert
IPv6 = Engineering
Product Development
 +33 4 9723 = 2634
Mobile: +33 6 1998 = 2985

Cisco Systems = France
Village = d'Entreprises Green Side
400 Avenue de Roumanille 
Batiment T 3 
06410 
BIOT - SOPHIA = ANTIPOLIS
France
Cisco.com

 

Think before you print.

Cisco Systems France, Soci=E9t=E9 =E0 = responsabiit=E9 limit=E9e, Rue Camille Desmoulins =96 Imm Atlantis Zac = Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 =80, = 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel = Givone, For corporate legal information go to:
 
 
__________________________= _____________________
Roll mailing list
Roll@ietf.org
Date: Mon, 12 Jul 2010 10:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-trickle-02.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: , X-List-Received-Date: Mon, 12 Jul 2010 17:15:01 -0000 --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 : The Trickle Algorithm Author(s) : P. Levis, O. Gnawali, T. Clausen, J. Hui, J. Ko Filename : draft-ietf-roll-trickle-02.txt Pages : 11 Date : 2010-7-6 The Trickle algorithm allows wireless nodes to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-02.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-trickle-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-12100043.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Mon Jul 12 10:25:51 2010 Return-Path: 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 9F4A53A69E0 for ; Mon, 12 Jul 2010 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, 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 omllVG6GVAOd for ; Mon, 12 Jul 2010 10:25:50 -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 AF5103A684E for ; Mon, 12 Jul 2010 10:25:50 -0700 (PDT) Received: from dnab405e14.stanford.edu ([171.64.94.20]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OYMlS-0002Pi-NW for roll@ietf.org; Mon, 12 Jul 2010 10:25:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Philip Levis In-Reply-To: <20100712171501.A3EA63A6B90@core3.amsl.com> Date: Mon, 12 Jul 2010 10:25:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7216824B-458C-43F1-96AD-0BC7C8FF9722@cs.stanford.edu> References: <20100712171501.A3EA63A6B90@core3.amsl.com> To: ROLL WG X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 6b0537b5faa14548adc1759647fcb4de Subject: Re: [Roll] I-D ACTION:draft-ietf-roll-trickle-02.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: , X-List-Received-Date: Mon, 12 Jul 2010 17:25:51 -0000 On Jul 12, 2010, at 10:15 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 > Title : The Trickle Algorithm > Author(s) : P. Levis, O. Gnawali, T. Clausen, J. Hui, J. = Ko > Filename : draft-ietf-roll-trickle-02.txt > Pages : 11 > Date : 2010-7-6 > =09 > The Trickle algorithm allows wireless nodes to exchange information > in a highly robust, energy efficient, simple, and scalable manner. > Dynamically adjusting transmission windows allows Trickle to spread > new information on the scale of link-layer transmission times while > sending only a few messages per hour when information does not > change. A simple suppression mechanism and transmission point > selection allows Trickle's communication rate to scale > logarithmically with density. This document describes Trickle and > considerations in its use. Changes based on feedback from Om, Tim, and JP: 1) Added Om as an author based on his redundancy constant studies 2) Added section recommended k values (1-3) and including note that k=3D0 = can be k=3Dinfinity 3) Added section on relationship between Imin and k Phil= From Michael.Cowan@us.elster.com Mon Jul 12 12:10:06 2010 Return-Path: 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 F2D673A6B87 for ; Mon, 12 Jul 2010 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 HD3wbpoAOLgQ for ; Mon, 12 Jul 2010 12:10:05 -0700 (PDT) Received: from mail136.messagelabs.com (mail136.messagelabs.com [216.82.249.3]) by core3.amsl.com (Postfix) with SMTP id ED2013A69BE for ; Mon, 12 Jul 2010 12:10:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Michael.Cowan@us.elster.com X-Msg-Ref: server-4.tower-136.messagelabs.com!1278961811!39469024!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 20939 invoked from network); 12 Jul 2010 19:10:12 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-4.tower-136.messagelabs.com with SMTP; 12 Jul 2010 19:10:12 -0000 Auto-Submitted: auto-generated From: Michael.Cowan@us.elster.com To: roll@ietf.org Message-ID: Date: Mon, 12 Jul 2010 15:10:18 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/12/2010 03:05:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Michael Cowan is out of the office (returning 07/15/2010) 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: , X-List-Received-Date: Mon, 12 Jul 2010 19:10:06 -0000 I am out of the office until 07/15/2010. Hello, I will be out of the office traveling on Business July 12 after 2PM through July 14, and returning to the office June 15th 2010. I will be checking email in the evening (will not have access to email during the day) and if it's a emergency, please call my cell at 919-696-4209. Thank You, Michael Note: This is an automated response to your message "Roll Digest, Vol 30, Issue 26" sent on 7/12/2010 3:00:33 PM. This is the only notification you will receive while this person is away. From gnawali@cs.stanford.edu Mon Jul 12 12:37:29 2010 Return-Path: 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 A211F3A6B6F for ; Mon, 12 Jul 2010 12:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.629 X-Spam-Level: X-Spam-Status: No, score=-4.629 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 p2K7sciJBmAR for ; Mon, 12 Jul 2010 12:37:28 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 761913A68C8 for ; Mon, 12 Jul 2010 12:37:28 -0700 (PDT) Received: from mail-gx0-f174.google.com ([209.85.161.174]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OYOoq-00075a-IC for roll@ietf.org; Mon, 12 Jul 2010 12:37:36 -0700 Received: by gxk23 with SMTP id 23so2757795gxk.19 for ; Mon, 12 Jul 2010 12:37:35 -0700 (PDT) Received: by 10.150.163.8 with SMTP id l8mr5204347ybe.356.1278963454328; Mon, 12 Jul 2010 12:37:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.192.13 with HTTP; Mon, 12 Jul 2010 12:37:14 -0700 (PDT) In-Reply-To: <20100712193542.5349F3A6C29@core3.amsl.com> References: <20100712193542.5349F3A6C29@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 12 Jul 2010 12:37:14 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-minrank-hysteresis-of-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: , X-List-Received-Date: Mon, 12 Jul 2010 19:37:29 -0000 Updates in -01: * Edits based on feedback from JP and others on the list * Added section 3.3 which talks about how to compute the rank - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Jul 12, 2010 at 12:35 PM Subject: New Version Notification for draft-gnawali-roll-minrank-hysteresis-of-01 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-minrank-hysteresis-of-01.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-minrank-hysteresis-of Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2010-07-12 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 8 Abstract: Hysteresis delays the effect of changes in link metric on parent selection. =A0Such delay makes the topology stable despite jitters in link metrics. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. =A0The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). The IETF Secretariat. From wintert@acm.org Mon Jul 12 14:58:30 2010 Return-Path: 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 6B8ED3A6857 for ; Mon, 12 Jul 2010 14:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] 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 OJlY3sShsAdk for ; Mon, 12 Jul 2010 14:58:29 -0700 (PDT) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id 61C2A3A67E5 for ; Mon, 12 Jul 2010 14:58:29 -0700 (PDT) Received: (qmail 9980 invoked from network); 12 Jul 2010 21:58:29 -0000 Received: from [10.56.17.107] (wintert@71.178.253.216 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 12 Jul 2010 14:58:28 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 234Vem4VM1mPJFOWM1bLuYhSWcJ5rvv4b.eqGUVfbYZ8pCX 6zI1DaLC.CRR4dVvN.PPDbmucFX_kJIoyGbAXyTRmh5VSsDBqInd.u65s18r Gwkks9fpA11z9H_PMJCwjPhpfaOO7lu2zFoClV0D2_qTyphEpluYTZFIuhSz 8h4cPRNqmQ9PZsIIcCNQnQdsk.j.UeT_6Z5zwGtRmaC2_euDIX.sgs.ymqOr b3IPTd13n6Og4XLYfG1u2vOunesdDpyEejjg6VL6dSSjQrF5iaTGF0ubf1hT N7x0_twnQtqZN4WYQLQUyY3lrIor1T1tidjLoD_xFf60IOO3LwBkWzRKHTzy fKmSoyLZypo22 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3B9001.3050505@acm.org> Date: Mon, 12 Jul 2010 17:58:25 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> In-Reply-To: <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Mon, 12 Jul 2010 21:58:30 -0000 Hi Nicolas, Phil, On 07/01/2010 10:45 PM, Philip Levis wrote: > > On Jul 1, 2010, at 11:51 AM, Nicolas DEJEAN wrote: > >> Hi Pascal, WG, >> >> 2010/6/30 Pascal Thubert (pthubert) : [SNIP] >>> Anything else we need to add / update / delete ? >>> >> >> As you asked for other updates, I had a look at rpl-10. >> >> Despite the impressing amount of work performed on this version, I >> have not seen any change concerning the DIS reception and Trickle >> Timer Reset. >> This issue was raised while dealing with Ticket #29. >> http://www.ietf.org/mail-archive/web/roll/current/msg03810.html is the >> last message posted on the thread (by me) before closing with the >> conclusion that DIS could now carry TLVs. >> >> This is already fine but the other subject discussed (that was not >> part of the ticket #29) has been lost in the battle. >> >> It seems to me that we had almost reached a concensus on this subject >> by adding some flags in order to break the currently existing link >> between: >> - the transmission method used for sending the DIS (unicast/multicast) >> - the Reset of the Trickle Timer (inconsistencies) >> - the transmission method used for answering (again unicast/multicast) >> >> Some flags were proposed: >> - C/R flag for driving the reset of the Trickle Timer >> - U flag for driving how the answered DIOs must be sent:unicast or >> multicast >> >> In rpl-10, some options exist but there is no such flag defined. >> >> Moreover, the second and third bullets describing the different >> Trickle Timer reset cases in section 7.3 contain hard MUST that could >> be softened by the flags proposed and let the door openened to some >> evolutions. >> >> IMHO, adding these 2 flags gives some opportunity to implement >> solutions like the 'Quick connection process' I described without >> adding complexity. Moreover, methods, goals and consequences will not >> be linked (Clarity is also a protocol quality). >> >> What do you think? > > A couple of thoughts/opinions: > > 1) I personally don't think these optimizations matter much. The > possible cost of disrupting Trickle is much, much higher than the cost > of a few extra timer resets. In highly, highly dynamic environments, we > see CTP's trickle-based control traffic to be 6-8% of the total traffic. > Since CTP uses datapath validation, this is tied to the data rate (it > wouldn't go up much if we lowered the data rate). In stable > environments, it can be under 1%. If we're worried about the efficiency > of RPL, this is *not* the place to start. > > 2) There's extensive research and deployment experience with Trickle; we > know how it works both in theory and practice. This doesn't mean it > can't be improved (Joakim has made several good points), but I'd > strongly, strongly caution against tweaking it without a lot of evidence > and testing first. Even slight changes can disrupt its delicate balance > (e.g., waiting until interval expiration to reset can prevent the > network from reaching consistency). > > 3) It is absolutely critical that reset be tied the transmission > mechanism. In particular, it can be disastrous when a node responds > immediately to a multicast message. > > 4) The Trickle timer is not doing more than it was intended to do; it is > a simple yet amazingly powerful mechanism. One major use is establishing > eventual consistency, but there are others. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > RPL-10 does keep some bits reserved in the DIS message as well as the Solicited Information option -- do you think that it would make sense to get more experience with the proposed C/R, U flags and then, after they have been proved out and all of the ramifications are understood, to define them in a future extension to the RPL base specfication? -Tim From pal@cs.stanford.edu Mon Jul 12 16:06:55 2010 Return-Path: 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 283C13A68B1 for ; Mon, 12 Jul 2010 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 lV25Dbjt-3BE for ; Mon, 12 Jul 2010 16:06:54 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 842B63A681D for ; Mon, 12 Jul 2010 16:06:54 -0700 (PDT) Received: from [172.27.75.114] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OYS5W-0002iO-Ra; Mon, 12 Jul 2010 16:07:03 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C3B9001.3050505@acm.org> Date: Mon, 12 Jul 2010 16:07:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> To: Tim Winter X-Mailer: Apple Mail (2.1081) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e Cc: roll@ietf.org Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Mon, 12 Jul 2010 23:06:55 -0000 On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: > Hi Nicolas, Phil, >=20 >=20 > RPL-10 does keep some bits reserved in the DIS message as well as the = Solicited Information option -- do you think that it would make sense to = get more experience with the proposed C/R, U flags and then, after they = have been proved out and all of the ramifications are understood, to = define them in a future extension to the RPL base specfication? Sure, makes sense to me. Until then, we should strive for the minimum = viable protocol. Phil= From richard.kelsey@ember.com Mon Jul 12 19:08:14 2010 Return-Path: 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 D23093A6A26 for ; Mon, 12 Jul 2010 19:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, 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 hve9-wCX-0rP for ; Mon, 12 Jul 2010 19:08:14 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id DF28E3A6A1E for ; Mon, 12 Jul 2010 19:08:13 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 22:08:21 -0400 Date: Mon, 12 Jul 2010 22:09:31 -0400 Message-Id: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 13 Jul 2010 02:08:21.0775 (UTC) FILETIME=[44C559F0:01CB2230] Subject: [Roll] Routing DAOs in non-storing DODAGs 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: , X-List-Received-Date: Tue, 13 Jul 2010 02:08:14 -0000 ROLLers, After some discussion with Pascal and others, I would like to propose that in non-storing DODAGs that DAOs be sent directly to the root rather than being processed as RPL messages at each hop. The main reason to do this is that the DAO acks can then also be sent end-to-end rather than one hop, which avoids some hard-to-handle error cases. Using end-to-end acks is both simpler and more robust. In general it makes sense to send the DAOs end-to-end, as in non-storing DODAGs the intermediate nodes do not make use of the information in the DAOs. Sending them directly reduces the amount of processing on intermediate nodes. One other change is needed for this to work: in order to send a DAO to the root, the root's address must be known. Part two of the proposal is that the DODAGID be required to be a routable address of the root. The draft currently gives this as a possibility; the change is to make it a requirement. While this would only be needed for non-storing DODAGs, it would be cleaner to require it always. Thoughts? -Richard Kelsey From pal@cs.stanford.edu Mon Jul 12 19:11:57 2010 Return-Path: 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 13C8B3A68B7 for ; Mon, 12 Jul 2010 19:11:57 -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 ewb0eX5RImrq for ; Mon, 12 Jul 2010 19:11:54 -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 7CB523A685B for ; Mon, 12 Jul 2010 19:11:52 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OYUyV-0003EU-Uo; Mon, 12 Jul 2010 19:12:00 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> Date: Mon, 12 Jul 2010 19:11:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2021FC1E-1A65-4172-8BDC-074BF821DD4A@cs.stanford.edu> References: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] Routing DAOs in non-storing DODAGs 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: , X-List-Received-Date: Tue, 13 Jul 2010 02:11:57 -0000 On Jul 12, 2010, at 7:09 PM, Richard Kelsey wrote: > ROLLers, >=20 > After some discussion with Pascal and others, I would like > to propose that in non-storing DODAGs that DAOs be sent > directly to the root rather than being processed as RPL > messages at each hop. The main reason to do this is that > the DAO acks can then also be sent end-to-end rather than > one hop, which avoids some hard-to-handle error cases. > Using end-to-end acks is both simpler and more robust. >=20 > In general it makes sense to send the DAOs end-to-end, as in > non-storing DODAGs the intermediate nodes do not make use of > the information in the DAOs. Sending them directly reduces > the amount of processing on intermediate nodes. >=20 > One other change is needed for this to work: in order to > send a DAO to the root, the root's address must be known. > Part two of the proposal is that the DODAGID be required to > be a routable address of the root. The draft currently > gives this as a possibility; the change is to make it a > requirement. While this would only be needed for > non-storing DODAGs, it would be cleaner to require it > always. >=20 > Thoughts? > -Richard Kelsey Seems like a good idea to me. Making the DAO end-to-end to the DODAG = Root makes its processing closer to its intent. It also allows DAO-Acks = to simply apply to this case. Phil From jhui@archrock.com Mon Jul 12 19:31:34 2010 Return-Path: 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 943383A6844 for ; Mon, 12 Jul 2010 19:31:24 -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 yuzMVOS-RCML for ; Mon, 12 Jul 2010 19:31:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 8FDE33A67AE for ; Mon, 12 Jul 2010 19:31:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4FF15AF9D7; Mon, 12 Jul 2010 19:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWUEl94EOX2H; Mon, 12 Jul 2010 19:29:13 -0700 (PDT) Received: from [10.0.1.2] (adsl-71-142-91-124.dsl.pltn13.pacbell.net [71.142.91.124]) by mail.sf.archrock.com (Postfix) with ESMTP id 3DDB3AF916; Mon, 12 Jul 2010 19:29:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> Date: Mon, 12 Jul 2010 19:30:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Routing DAOs in non-storing DODAGs 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: , X-List-Received-Date: Tue, 13 Jul 2010 02:31:34 -0000 I support this change. It makes the DAO information end-points explicit = and processing at intermediate non-storing modes simpler. It also makes = the DAO mechanism for non-storing mode conceptually simpler and easier = to describe. -- Jonathan Hui On Jul 12, 2010, at 7:09 PM, Richard Kelsey wrote: > ROLLers, >=20 > After some discussion with Pascal and others, I would like > to propose that in non-storing DODAGs that DAOs be sent > directly to the root rather than being processed as RPL > messages at each hop. The main reason to do this is that > the DAO acks can then also be sent end-to-end rather than > one hop, which avoids some hard-to-handle error cases. > Using end-to-end acks is both simpler and more robust. >=20 > In general it makes sense to send the DAOs end-to-end, as in > non-storing DODAGs the intermediate nodes do not make use of > the information in the DAOs. Sending them directly reduces > the amount of processing on intermediate nodes. >=20 > One other change is needed for this to work: in order to > send a DAO to the root, the root's address must be known. > Part two of the proposal is that the DODAGID be required to > be a routable address of the root. The draft currently > gives this as a possibility; the change is to make it a > requirement. While this would only be needed for > non-storing DODAGs, it would be cleaner to require it > always. >=20 > Thoughts? > -Richard Kelsey >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=802f94894=Roger.Alexander@cooperindustries.com Mon Jul 12 15:57:02 2010 Return-Path: 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 A575C3A681D for ; Mon, 12 Jul 2010 15:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Zp9cvlKPJOdk for ; Mon, 12 Jul 2010 15:56:48 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id C22753A6860 for ; Mon, 12 Jul 2010 15:56:46 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,191,1278302400"; d="scan'208,217";a="60676357" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Jul 2010 18:56:54 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:56:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2215.77F4E256" Date: Mon, 12 Jul 2010 18:55:59 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19C3CA@EVS4.nam.ci.root> In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8g References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> From: "Alexander, Roger" To: "Navneet Agarwal (navagar)" , "ROLL WG" X-OriginalArrivalTime: 12 Jul 2010 22:56:54.0040 (UTC) FILETIME=[858C1980:01CB2215] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Tue, 13 Jul 2010 03:03:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2215.77F4E256 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Navneet, =20 Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group). =20 One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root.=20 =20 Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. =20 Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO.=20 =20 If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries.=20 =20 Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. =20 To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. =20 Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents.=20 =20 There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and downward paths. =20 The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. =20 This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10.=20 =20 Make sense? See also a specific related comment below. =20 Regards, =20 Roger =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =20 Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =20 Scenario-1: =20 A B \ / \ / C / \ / \ D E =20 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. Assume path control allows two paths. D and E have learnt a common prefix for a node below them, Pfx D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will set x10 in Path control of DAO sent to A C will set x01 in Path control of DAO sent to B =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =20 Scenario-2: =20 F G \ / \ / A | | C / \ / \ D E =20 D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will send a DAO with path control x11 to A A will send a DAO with path control x01 to F A will send a DAO with path control x10 to G =20 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =20 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =20 Scenario-3 =20 F G \ / \ / A | | C / \ / \ D E =20 Suppose G is preferred over F. Suppose path from E to D is down. D sends DAO with path control x10 to C C sends DAO with path control x10 to A A sends DAO with path control x10 to G =20 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =20 =20 [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. =20 =20 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =20 [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. =20 =20 Thanks =20 Regards, Navneet ------_=_NextPart_001_01CB2215.77F4E256 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Navneet,

 

Thanks for the scenario examples which provide a = good opportunity to highlight/clarify the role of the Path Sequence in the = DAO exchanges. Below is an explanation of how I envisaged it would/should = operate and would also be interested in the WG’s feedback. (Note: I am = assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 = destination address, prefix, or multicast group).

 

One advantage accruing to storing nodes, in = addition to DAO aggregation, is the ability to further reduce routing overhead by = removing the requirement for sub-DAG changes to always be conveyed all the way to the = root. In all of the scenarios you have defined, when a common ancestor = receives a no-Path DAO that is not originated by the Prefix owner (and hence should = not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor = does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate = path(s), its ancestors do not need to be further updated. With the maintained = Path Sequence in the no-Path DAO, only nodes that have a singular downward = route to the affected Prefix need to update their individual DAO Parent(s). = Correspondingly, only new or changed routing/path information that originates from the = Prefix owner and hence indicated by an incremented Path Sequence number must = always be passed along to the root.

 

Note: The implementation option of limiting when = the Path Sequence number is incremented by a Prefix owner provides a capability = to further reduce routing overhead for storing nodes – though the few = bits needed to fully support incremental/partial updates within the DAO would be = still needed.

 

Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor = node that discovers the loss of connectivity (neighbor unreachability detection, = NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO = will be the one maintained by the ancestor node (only the owner of the Prefix = can increment the Path Sequence for that Prefix). This would be the same as = the Path Sequence maintained by all nodes along the path to the common = ancestor. The first common ancestor receiving such a no-Path DAO should mark the = affected downward path for deletion and should take no further action with regard = to upward forwarding of the DAO.

 

If the owner of the Prefix discovers the loss of = connection to an existing DAO Parent and wishes to update its path connections, = including potentially re-selecting a different preference set of DAO Parents, the = node must increment the Path Sequence and transmit DAOs to new desired DAO = Parents – a no-Path DAO is not required. The incremented Path Sequence will = necessitate that the updated DAOs be conveyed all the way to the root - in the = process updating routing tables at intermediate nodes. Where new downward paths = are established as a result of the updated DAOs, existing intermediate = routing tables are directly updated. Routing table entries that are no longer on = the re-established downward paths will be purged through the normal = expiration of the associated downward route entries.

 

Note: If the node that owns the Prefix chooses = to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do = so by sending normal periodic or triggered DAO updates to the connected DAO = Parents without incrementing the Path Sequence in the DAO updates. Where = connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete = the path through a given DAO Parent. By not incrementing the Path Sequence the = path through the particular DAO Parent will be removed only to the first common = ancestor.

 

To redefine DAO Parents and preferences (including = where necessary to maintain fan-out limits), DAOs must be sent with an = incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is = conveyed to the root and recognized by ancestor nodes that can delete downward = path entries. Where the updated DAOs are received at nodes that do not = currently have routing entries for the particular Prefix, the information is = cached and the new DAO information conveyed towards the root.

 

Based on the above defined operation there is no = benefit to the node owner of the Prefix sending a no-Path DAO with an incremented = Path Sequence. This will travel all the way to the root and will have the effect of = outdating and marking for deletion all existing downward routes for that Prefix. = Instead, to re-establish desired downward paths, DAOs with incremented Path = Sequences should be sent to the desired/maintained DAO Parents.

 

There would be some benefit to being able to send a = no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths = (as well as introduce the difficulties raised in your assessments). Note = once again that multiple DAO Parents guarantee only local diversity. Therefore the = fact that deleting a single DAO Parent using an un-incremented Path Sequence = removes diversity only to a common ancestor should be seen in the context of the = local guarantees that are provided.

 

SUMMARY: If a no-Path DAO is sent by the Prefix = owner to a connected DAO Parent to delete the single downward path while = maintaining the others, the Path Sequence should be maintained (not incremented) = indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the = particular DAO Parent, only to the first common ancestor, will be deleted. Where = the no-Path DAO is being proactively sent by an ancestor node due to = recognition of NUD, the same would apply as the Path Sequence number will be the one = currently maintained by the ancestor node. The prefix owner should never send a = no-Path DAO with an incremented Path Sequence but should instead send updated = DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and = downward paths.

 

The operation for non-storing nodes would be the = same. However, in the case of non-storing nodes the first common ancestor is = always the root node. If in the non-storing case a no-path DAO is issued by the = owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the = root to update existing downward paths (removing the identified DAO Parent = while maintaining ordering of remaining DAO Parents). As in the storing case, = a no-Path DAO with an incremented Path Sequence would mark all other = downward paths from the root as potentially outdated (and marked for deletion) = and so should similarly not be issued.

 

This is the operation as I believe it should work = but I look forward to understanding whether this envisaged operation can fit within = the model given in -10.

 

Make sense? See also a specific related comment = below.

 

Regards,

 

Roger

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Navneet Agarwal = (navagar)
Sent: Friday, July 09, 2010 1:26 PM
To: ROLL WG
Subject: [Roll] no-Path DAO and fan-out

 

Hi WG:
I am trying to get some clarifications on expected behavior. Have read = the Path Control document on path ctl field usage (attached). I have put several = setups and flows, assuming storing nodes but should apply for non-storing = scenario as well. I could not figure out from the reading the doc or the = RFC.

 

Scenario-1:

 

A  =    B

\  =     /

 \ =   /

   C

  /  \

 / =    \

D  =    E

 

A, B - DAO Parents.....C - Node........D,E- nodes in = subdag.

Assume path control allows two paths.

D and E have learnt a common prefix for a node below them, = Pfx

D will set x10 in Path control of DAO sent to C

E will set x01 in Path control of DAO sent to C

C will set x10 in Path control of DAO sent to A

C will set x01 in Path control of DAO sent to B

 

Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C = do? I would think that C will need to send a no-Path. But it has to remember = that it had sent a DAO with path control x01 to B. If this has to happen then C = would have to remember for each prefix what path control was sent to which = parent, which does not seem correct as it would not scale as the prefixes at C = scale, each having its own path control settings.

 

Scenario-2:

 =

F  =    G

\  =   /

 \ = /

   A

  &= nbsp; |

  &= nbsp; |

   C

  /  \

 / =    \

D  =    E

 

D will set x10 in Path control of DAO sent to C

E will set x01 in Path control of DAO sent to C

C will send a DAO with path control x11 to A

A will send a DAO with path control x01 to F

A will send a DAO with path control x10 to G

 

Suppose E sends a no-Path to C (path control x01). What does C do? It will = likely send a DAO to A with path control x10. What will A do when it receives a DAO = with this path control when its previous path control was = x11?

 

I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for = example:

 

Scenario-3

 

F  =    G

\  =   /

 \ = /

   A

  &= nbsp; |

  &= nbsp; |

   C

  /  \

 / =    \

D  =    E

 

Suppose G is preferred over F.

Suppose path from E to D is down.

D sends DAO with path control x10 to C

C sends DAO with path control x10 to A

A sends DAO with path control x10 to G

 

After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C.

C merges this and sends a DAO with path control x11 to A. What does A do = since is has indicated a path control of x10 to G. In normal terms, if A had = received a DAO with path control x11 from C, it would have notified DAO to F with = path control x10 and DAO to G with path control x01 but due to transient = conditions it could be reversed.

 

 

[RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be = forwarded since all prior path information is effectively obsolete by the = incremented Path Sequence. When subsequent DAO updates are received with the new, = incremented Path Sequence, only then can the combined path control information be = forwarded.

 

 

Will appreciate if it can be clarified if the above flows are reasonable and = what should happen...in general I dont think path control should mandate = which path control bits are tied to which DAO parent etc...

 

[RA] Hopefully the above discussion supports the view that Path Control can = operate as specified without the need to maintain state on which DAO with which = Path Control was sent to which DAO Parent.

 

 

Thanks

 

Regards,=

Navneet<= /o:p>

------_=_NextPart_001_01CB2215.77F4E256-- From pthubert@cisco.com Tue Jul 13 00:55:02 2010 Return-Path: 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 239923A6987 for ; Tue, 13 Jul 2010 00:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.183 X-Spam-Level: X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XrIVUgqWXxM2 for ; Tue, 13 Jul 2010 00:55:01 -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 417E13A693E for ; Tue, 13 Jul 2010 00:55:01 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACu5O0xAZnwM/2dsb2JhbACgLXGjJpsDhScEinmHAA X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208";a="131675189" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2010 07:55:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6D7t7Qr014017; Tue, 13 Jul 2010 07:55:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 09:55:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 09:55:02 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CDAD4@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposed DIS flags (Re: LC RPL-10) thread-index: AcsiFvepTeUSk40iTvye257c3B7juQASUsqw References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu><4C3B9001.3050505@acm.org> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Tim Winter" X-OriginalArrivalTime: 13 Jul 2010 07:55:07.0846 (UTC) FILETIME=[B627D660:01CB2260] Cc: roll@ietf.org Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 07:55:02 -0000 I'm on the same line as Tim and Phil for this one.=20 In one hand I agree that the every DIS is not necessarily an inconsistency that should trigger Trickle to reset its timer, but OTOH I'm unsure that the originator has all the information to figure that out. Let us get more experience in determining which inconsistencies we really care about, and then we'll publish add-ons to the standard that cover those as required. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Tuesday, July 13, 2010 1:07 AM > To: Tim Winter > Cc: roll@ietf.org > Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) >=20 >=20 > On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: >=20 > > Hi Nicolas, Phil, > > > > > > RPL-10 does keep some bits reserved in the DIS message as well as the > Solicited Information option -- do you think that it would make sense to get > more experience with the proposed C/R, U flags and then, after they have > been proved out and all of the ramifications are understood, to define them in > a future extension to the RPL base specfication? >=20 > Sure, makes sense to me. Until then, we should strive for the minimum viable > protocol. >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Jul 13 02:05:53 2010 Return-Path: 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 2EBDF3A68C7 for ; Tue, 13 Jul 2010 02:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.291 X-Spam-Level: X-Spam-Status: No, score=-10.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 S0Peo+UThk02 for ; Tue, 13 Jul 2010 02:05:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 54AEF3A6961 for ; Tue, 13 Jul 2010 02:05:52 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABvJO0yrRN+K/2dsb2JhbACgLXGjIZp6hScEiE2CMYcD X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208";a="225489144" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2010 09:06:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6D95va2022182; Tue, 13 Jul 2010 09:06:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:05:57 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:05:56 +0200 Message-Id: From: JP Vasseur To: ROLL WG , Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 11:05:55 +0200 References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Jul 2010 09:05:56.0998 (UTC) FILETIME=[9AD8FA60:01CB226A] Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 09:05:53 -0000 I think so too. Nicolas, you could have a simple ID defining those bits in a separate document. At least the DIS format is now flexible to allow for such extensions. JP. On Jul 13, 2010, at 1:07 AM, Philip Levis wrote: > > On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: > >> Hi Nicolas, Phil, >> >> >> RPL-10 does keep some bits reserved in the DIS message as well as >> the Solicited Information option -- do you think that it would make >> sense to get more experience with the proposed C/R, U flags and >> then, after they have been proved out and all of the ramifications >> are understood, to define them in a future extension to the RPL >> base specfication? > > Sure, makes sense to me. Until then, we should strive for the > minimum viable protocol. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Jul 13 02:10:26 2010 Return-Path: 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 CE18D3A690E for ; Tue, 13 Jul 2010 02:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.305 X-Spam-Level: X-Spam-Status: No, score=-10.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hTbWhz2hjtI6 for ; Tue, 13 Jul 2010 02:10:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 27C293A6A3F for ; Tue, 13 Jul 2010 02:10:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL7KO0yrR7Hu/2dsb2JhbACgLXGjHpp6hScEiE2CMQ X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208";a="343403513" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2010 09:10:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6D9A86a002135; Tue, 13 Jul 2010 09:10:32 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:10:25 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:10:24 +0200 Message-Id: <305B7D5A-5DAD-40C4-8971-277B70B1DCB5@cisco.com> From: JP Vasseur To: Jonathan Hui In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 11:10:23 +0200 References: <87mxtwf7z8.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Jul 2010 09:10:25.0132 (UTC) FILETIME=[3AAAFAC0:01CB226B] Cc: roll@ietf.org Subject: Re: [Roll] Routing DAOs in non-storing DODAGs 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: , X-List-Received-Date: Tue, 13 Jul 2010 09:10:26 -0000 On Jul 13, 2010, at 4:30 AM, Jonathan Hui wrote: > > I support this change. It makes the DAO information end-points > explicit and processing at intermediate non-storing modes simpler. > It also makes the DAO mechanism for non-storing mode conceptually > simpler and easier to describe. > Fully agree, process of DAO on non-storing had little value anyway. JP. > -- > Jonathan Hui > > On Jul 12, 2010, at 7:09 PM, Richard Kelsey wrote: > >> ROLLers, >> >> After some discussion with Pascal and others, I would like >> to propose that in non-storing DODAGs that DAOs be sent >> directly to the root rather than being processed as RPL >> messages at each hop. The main reason to do this is that >> the DAO acks can then also be sent end-to-end rather than >> one hop, which avoids some hard-to-handle error cases. >> Using end-to-end acks is both simpler and more robust. >> >> In general it makes sense to send the DAOs end-to-end, as in >> non-storing DODAGs the intermediate nodes do not make use of >> the information in the DAOs. Sending them directly reduces >> the amount of processing on intermediate nodes. >> >> One other change is needed for this to work: in order to >> send a DAO to the root, the root's address must be known. >> Part two of the proposal is that the DODAGID be required to >> be a routable address of the root. The draft currently >> gives this as a possibility; the change is to make it a >> requirement. While this would only be needed for >> non-storing DODAGs, it would be cleaner to require it >> always. >> >> Thoughts? >> -Richard Kelsey >> >> >> _______________________________________________ >> 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 trac@tools.ietf.org Tue Jul 13 02:11:25 2010 Return-Path: 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 49F273A690E for ; Tue, 13 Jul 2010 02:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 cLfQouQjfWrL for ; Tue, 13 Jul 2010 02:11:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 026493A6A46 for ; Tue, 13 Jul 2010 02:11:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYbWS-0007FL-Rd; Tue, 13 Jul 2010 02:11:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: richard.kelsey@ember.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 13 Jul 2010 09:11:28 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/57 Message-ID: <055.3e4b6aebd2ab17460a59e9c452c3da42@tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.kelsey@ember.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #57: Proposed change: Routing DAOs in non-storing DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 09:11:26 -0000 #57: Proposed change: Routing DAOs in non-storing DODAGs -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: richard.kelsey@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from Richard Kelsey: ROLLers, After some discussion with Pascal and others, I would like to propose that in non-storing DODAGs that DAOs be sent directly to the root rather than being processed as RPL messages at each hop. The main reason to do this is that the DAO acks can then also be sent end-to-end rather than one hop, which avoids some hard-to-handle error cases. Using end-to-end acks is both simpler and more robust. In general it makes sense to send the DAOs end-to-end, as in non-storing DODAGs the intermediate nodes do not make use of the information in the DAOs. Sending them directly reduces the amount of processing on intermediate nodes. One other change is needed for this to work: in order to send a DAO to the root, the root's address must be known. Part two of the proposal is that the DODAGID be required to be a routable address of the root. The draft currently gives this as a possibility; the change is to make it a requirement. While this would only be needed for non-storing DODAGs, it would be cleaner to require it always. Thoughts? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -- Ticket URL: roll From trac@tools.ietf.org Tue Jul 13 02:14:06 2010 Return-Path: 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 54AD43A69A8 for ; Tue, 13 Jul 2010 02:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 B4dAf-3KbBiV for ; Tue, 13 Jul 2010 02:14:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 206D33A6A3B for ; Tue, 13 Jul 2010 02:14:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYbZ8-0006J1-1e; Tue, 13 Jul 2010 02:14:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Tue, 13 Jul 2010 09:14:13 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/58 Message-ID: <055.2b0240e94b11938c1f27781717c93f00@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #58: Clarification on DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 09:14:06 -0000 #58: Clarification on DAO -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Hello Mathilde - What is the DAO parent selection criteria for OCP0? Same as for DIO parents I assume. [Pascal] OF0 only mandates one preferred parent with good enough bidirectional connectivity, and it enables a backup if one is available. So yes, there’s little choice but pick it as DAO parent as well. The draft could have an additional sentence to say that I admit. - What actions need to be taken by a node that didn’t get a DAO-ACK response when setting the K bit? [Pascal] We have to refine that text in 11 for sure. Only new information is sent asynchronously to the DAO parents while the full information is sent in demand (upon DTSN or new version). In short, the rich implementation can maintain per parent what was acknowledged and flag it as not new. The constrained implementation sends the delta once and flag it as not new without an ack, waiting for the next full information to fill the gaps. So basically when something new is learnt, the storing router arms a timer to schedule a DAO. When the timer elapses, the router sends all new information to the parents. The timer keeps elapsing for a given parent till the parent acks the most recent DAO sequence sent to it or the router gives up. If the router gives up, the parent is out of sync till the next change or full information updates it. The path sequence that circulates via other parents that are not out of sync is fresher and enables the ancestors to select the usable path. - Section 16.2.6 (which deals with configuration) introduces some terminology not used in the spec (e.g UNREACHABLE state). Is this some legacy text? [Pascal] It is. That state was in the FSM that went down the sink around 08 - When should a node initiate (i.e. not propagate) an increase in DTSN? [Pascal] Can be upon an inconsistency detection, or upon an internal timer per policy though that is not mandated. An inconsistency can be an RPF check, a DAO entry not revalidated, a datapath validation failure. New DSTN should be caped in time. - “Multicast DAOs MUST NOT include Transit Information options†(Section 8.6). Do you mean “MUST not include a parent address in the transit information option� [Pascal] Oups! Correct. We sometime need the lifetime. Best, Pascal -- Ticket URL: roll From jpv@cisco.com Tue Jul 13 02:15:37 2010 Return-Path: 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 AC71A3A6A4A for ; Tue, 13 Jul 2010 02:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.317 X-Spam-Level: X-Spam-Status: No, score=-10.317 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 RLMvaEU7f4Hb for ; Tue, 13 Jul 2010 02:15:36 -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 C6A9F3A6A3B for ; Tue, 13 Jul 2010 02:15:35 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAK/LO0xAZnwN/2dsb2JhbACBRJ5pcaMrmnmFJwSITYIx X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208,217";a="131725428" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2010 09:15:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6D9FbiN003500 for ; Tue, 13 Jul 2010 09:15:42 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:15:37 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 11:15:36 +0200 Message-Id: <9893E03A-3A7B-4615-804F-0E4FAB300F3D@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD8F5@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-81-57625013 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 11:15:35 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D024CD8F5@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Jul 2010 09:15:37.0213 (UTC) FILETIME=[F4AEC2D0:01CB226B] Cc: roll@ietf.org Subject: Re: [Roll] More questions on DAO 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: , X-List-Received-Date: Tue, 13 Jul 2010 09:15:37 -0000 --Apple-Mail-81-57625013 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Since this leads to clarifications to be added to -11, I have opened a =20= ticket to keep track of it. No need for action item on the third bullet since the FSM is not part =20= of that ID. Thanks. JP. On Jul 12, 2010, at 4:30 PM, Pascal Thubert (pthubert) wrote: > Hello Mathilde > > - What is the DAO parent selection criteria for OCP0? Same as for =20 > DIO parents I assume. > [Pascal] OF0 only mandates one preferred parent with good enough =20 > bidirectional connectivity, and it enables a backup if one is =20 > available. So yes, there=92s little choice but pick it as DAO parent =20= > as well. The draft could have an additional sentence to say that I =20 > admit. > > - What actions need to be taken by a node that didn=92t get a DAO-ACK =20= > response when setting the K bit? > [Pascal] We have to refine that text in 11 for sure. Only new =20 > information is sent asynchronously to the DAO parents while the full =20= > information is sent in demand (upon DTSN or new version). In short, =20= > the rich implementation can maintain per parent what was =20 > acknowledged and flag it as not new. The constrained implementation =20= > sends the delta once and flag it as not new without an ack, waiting =20= > for the next full information to fill the gaps. So basically when =20 > something new is learnt, the storing router arms a timer to schedule =20= > a DAO. When the timer elapses, the router sends all new information =20= > to the parents. The timer keeps elapsing for a given parent till the =20= > parent acks the most recent DAO sequence sent to it or the router =20 > gives up. If the router gives up, the parent is out of sync till the =20= > next change or full information updates it. The path sequence that =20 > circulates via other parents that are not out of sync is fresher and =20= > enables the ancestors to select the usable path. > > - Section 16.2.6 (which deals with configuration) introduces some =20 > terminology not used in the spec (e.g UNREACHABLE state). Is this =20 > some legacy text? > [Pascal] It is. That state was in the FSM that went down the sink =20 > around 08 > > - When should a node initiate (i.e. not propagate) an increase in =20 > DTSN? > [Pascal] Can be upon an inconsistency detection, or upon an internal =20= > timer per policy though that is not mandated. An inconsistency can =20 > be an RPF check, a DAO entry not revalidated, a datapath validation =20= > failure. New DSTN should be caped in time. > > - =93Multicast DAOs MUST NOT include Transit Information =20 > options=94 (Section 8.6). Do you mean =93MUST not include a parent =20 > address in the transit information option=94? > [Pascal] Oups! Correct. We sometime need the lifetime. > > Best, > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-81-57625013 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Since this leads to = clarifications to be added to -11, I have opened a ticket to keep track = of it.
No need for action item on the third bullet since the FSM is = not part of that = ID.

Thanks.

JP.

On Jul 12, 2010, at 4:30 PM, Pascal Thubert (pthubert) = wrote:

Hello = Mathilde
- What is the DAO parent selection = criteria for OCP0? Same as for DIO parents I = assume.
[Pascal] OF0 only = mandates one preferred parent with good enough bidirectional = connectivity, and it enables a backup if one is available. So yes, = there=92s little choice but pick it as DAO parent as well. The draft = could have an additional sentence to say that I = admit.
- What actions need to be taken = by a node that didn=92t get a DAO-ACK response when setting the K = bit?
[Pascal] We have to refine that = text in 11 for sure. Only new information is sent asynchronously to the = DAO parents while the full information is sent in demand (upon DTSN or = new version). In short, the rich implementation can maintain per parent = what was acknowledged and flag it as not new. The constrained = implementation sends the delta once and flag it as not new without an = ack, waiting for the next full information to fill the gaps. So = basically when something new is learnt, the storing router arms a timer = to schedule a DAO. When the timer elapses, the router sends all new = information to the parents. The timer keeps elapsing for a given parent = till the parent acks the most recent DAO sequence sent to it or the = router gives up. If the router gives up, the parent is out of sync till = the next change or full information updates it. The path sequence that = circulates via other parents that are not out of sync is fresher and = enables the ancestors to select the usable = path.
- Section 16.2.6 (which deals = with configuration) introduces some terminology not used in the spec = (e.g UNREACHABLE state). Is this some legacy text?
[Pascal] It is. That state was in the FSM that went down the = sink around 08
- When should a node initiate = (i.e. not propagate) an increase in DTSN?
[Pascal] Can be upon an inconsistency detection, or upon an = internal timer per policy though that is not mandated. An inconsistency = can be an RPF check, a DAO entry not revalidated, a datapath validation = failure. New DSTN should be caped in = time.
- =93Multicast DAOs MUST NOT = include Transit Information options=94 (Section 8.6). Do you mean =93MUST = not include a parent address in the transit information = option=94?
[Pascal] Oups! Correct. = We sometime need the lifetime.
 
Best,

________________________= _______________________
Roll mailing list
Roll@ietf.org
From: JP Vasseur To: ROLL WG , Anders Brandt Content-Type: multipart/alternative; boundary=Apple-Mail-88-58687354 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 11:33:17 +0200 References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD20E@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Jul 2010 09:33:19.0119 (UTC) FILETIME=[6DA0C1F0:01CB226E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17502.006 X-TM-AS-Result: No--24.563100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Tue, 13 Jul 2010 02:35:25 -0700 Subject: [Roll] Fwd: draft-ietf-roll-rpl-11 RC1 Comments [2/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: , X-List-Received-Date: Tue, 13 Jul 2010 09:33:26 -0000 --Apple-Mail-88-58687354 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Thanks for your comments Anders. WIll address them soon (see new ticket to be opened). Thanks. JP. Begin forwarded message: > From: "Anders Brandt" > Date: July 6, 2010 12:35:35 PM CEDT > To: > Subject: Re: draft-ietf-roll-rpl-11 RC1 Comments [2/2] > > Cheers, > Anders --Apple-Mail-88-58687354 Content-Type: multipart/mixed; boundary=Apple-Mail-89-58687355 --Apple-Mail-89-58687355 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks for your comments = Anders.
WIll address them soon (see new ticket to be = opened).

Thanks.

JP.
=

Begin forwarded message:

Date: = July 6, 2010 12:35:35 PM CEDT
Subject: Re: draft-ietf-roll-rpl-11 RC1 = Comments [2/2]

Cheers,
  Anders
=
= --Apple-Mail-89-58687355 Content-Disposition: inline; filename=3805_046.pdf Content-Type: application/pdf; x-unix-mode=0666; name="3805_046.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJSDi48/TCjEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1 IDg0MV0KL0Nyb3BCb3ggWzAgMCA1OTUgODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jl c291cmNlcyA8PAovUHJvY1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmpl Y3QgPDwKL09iajMgMyAwIFIgICA+Pgo+PgovQ29udGVudHMgWyA0IDAgUiAgXQo+PgplbmRvYmoK MyAwIG9iago8PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajMgL1dp ZHRoIDI0ODAgL0hlaWdodCAzNTA3IC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAg dHJ1ZSAvQml0c1BlckNvbXBvbmVudCAxIC9MZW5ndGggNSAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhE ZWNvZGUgL0RlY29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCv// /IDpheP///////////8gLg+lQXj//////+Wx7L5bGqxDHJDkEHO2E4YSO4yOiuCKIk4LkdXLYA0R 4jhBiJxEdEcU0URDBEeNrLojovF1ENhNIRhQyPkcUj5HzHFhKR0R0LVPGgyPkdHM7ElEWi+IicUF SYIIvmEYj2YRHZcyOFI+Xy5l8uiOjGXy8Xy7y8XZfLovkdG0SFHMYiIiMGXReiIiccw40gggrQSC CCBEfbhMER0EcexoRl8j8GbRHRoiIUWGXiJhmEdgrsqEMqwRHSwnxCBUJH6Gnc+gT5J4WTciOVBQ 5WT+XRxGijRHpDYOU4TQiIjCGscdxGg4iLKdQmg87hAt9ighCCEjojpS6iDMOUOcIWOccnLVCOOR 0XxERETaPxfiLmMREXrUwhHNoujCMKImMREVMRtCI+R/m84hCKhwYiJjL8RUviMIvkfI+R8RMIj5 fi5hGEYQi9JiOXi6iLBMpylxzjmHOssjouoiJhF0Yy8YQg5HRHx7iIiEFm8XI8XQiXRfiOYRxEhC 0gy6GjFEc8gkcRdF0asQ6ZfEGcc7SqERSHOKgwQLBi5HURERE+KPKYGkQaDKhkdGEymYZlb0E8s4 jREdHkIeHIrNFHERERF2Q45TlDnZpdRJwMBBSmsRdEcH4ieRzGI/////////5NtFGWmTUZTAso// ///////5ZpHqJawxbj//////////////lrhFLXrBJa5waJa+BqQRDQOVB3IO2YCILjA4IhRs44Mt Va4IELDeERAQGMJA3QIGHCOOCboQR271dAg3duJSCBvBvLXOGzyTncGNBCDD0aheG6Qb0G7QbgkY T6BBDI2zD2bGXRgGI2hFXqDKchgc45UYiIj/lrlx0DlrxQdNExw6DSMzoOmHlw0g392+f9vpq3p8 N7EK30g3evYYTfHhyBoeR4nRtF8jiwwyOGVsjgYgwmSHNB/URERkB0CUf+Wv1ut/u9b8zRdF1suB gjrQRQ4sthVXZDA5x4+Tso5Q5Q4XEREd69v+1h2o/LXLVCD8tceSp+HVtcPhkKr4aVknfB2RTlDq HgyOgQqIYioMKGcchxwos45TZECP///ybBUQEy1SuqHDOxfGEQu1QM7AhKIx2ynDUm4Gi7K6hGFR qMQ2i3KHghhOyuF5fOzotQzVJwwy6hCOuFs7cQfxejdQIj7auF+EW/oa+CLrmzdTtTQSds9/6V6T RahmsUhCc70DFnl+VzV/eJlwEDahatp/w/p7ldVcLmPQ71h3XnuYPFp2g+xFB31KUC9cREZ/tFea iK94iGELUw5UFDlPEZNlnEaERaldLztS87Gom4HCO7s7B7k2LUR0R2EGV+RUZXhffwhGgRHjJLSZ qEIvm4ypnEmdqSI+Y5XU4j4S/1QJu8LDTBCMi7LuOzIQpXBQXf7RvW+8kPpOWOtOnMpmnlj1+sav 5/SU8YU2anfVp9oowQwUjwX/8fxpukvdGh5aRSt3URufXX7X//9N4/ZQ5tmCQ4UNO8EOzytf/19t 7Qjg0MbapFAYil+/1tvi1qxQZbgiOl0rVilbSdjiM80wg4jN5x4a2K1YqG8RHoXFpod3eVyTMnR2 oQiIhghEQ1K6kFtMmxJCNPo/ggyo6NN/omOzWKVwLIPIVGQeXyWZ3p0g52CJb4QcKVy4Q6d4XCZH js1MKZTE1oMuFb6tGHMOkl9bS4pPfrDCq9U3O53u+gRH3giPuix6NB3d1YU30P//b8iUXC16T9Ht K3wZHQKPyxzj9f//6/72m6duxELWELvX/4KF5+//j/wYQv8Nbb/0KFb/uvtbiIuxTUfe196vqdui PhW0uIaFp2MGcKWxFRFAhFMfERYWLTTUJhNSbLSOyZiIgwQYTKavlVldL0yDSZaCzERGVwslfRbs mynkoivYQ7mjI6MgRU28YTdyCSWtoMrCTz26UjEr8OfdMigjOx0Yd1bzsEBfq9mgz9WDCp3B9t8e ibCsXCJO9ntG+Zamixyn6BEfZTstTVdu5yPr03bHiRGEoQvVWIYY22Ne9pG7+r2ECxrcMitRXDd1 bCQ968+54P1XW7Q7H9012coZ2qNs93WCJxiIsJrYxs9lbBcPZFNBgih7GpF9J4i01HidggQIRHSU QuIYLnRQKTHJD34LlkDxn+IyysELiNPJstZ0zFjTCEREtT11CeXz+TZSzUMq87pkKzs1QnYniP4I jy+TYp9M1iHbiESBdSNZCsnIj4Kdqhkodap/7ua2oWs/nTsi/xFBNMyfOzEX5Nitlwq//uk6N2XG ezR9dbmfNDRh0dmSI5Bf/7qtddCghFBBu/feFP1JtxP4Q+7SN914j/v/fffHunXRIejvePxSh7Xq 3+Gv+rryEfO8P/9pIM/wQq/PefXoYVVX32P9fLSKVa3/ptY47XCFAhWvzuUP/fxiIiODMEFabaU/ 2turXE//frGg1N2aCnUV4ZgUygbDCS9t1elEMIRaHDQu7tMVl07xsRyuZZ2qmIiIiIMEGExYi0wp XJWFTISEaEYQ0aHk3Ssg8hM7cjtYhMrRahCqk25N1hBSHrpksi+EGVaO4zCLcSEHPNJOpN1MJvou GFtFjs1iBOzsmy8QcdrGp2ouPmcXC/9OroIOq6+dqUg0THBSDtJZ3+kZyo9miOJaud/TaJDqd9oE R931ghb2fX0jc6Vv0GENX/+d7+9f1O7zNTWZ3YZHK0h32/qvX/120vXycMJbsdO9Dj1vwQ2p/v/+ /37+uv/5FHnZaGB/Wh+69bX99f5yPWjOUOCW/PNSQ5Q5x208YM4T2sXTdf/Xr8fQi9cRnIQi1jsU GKj42I2IrVwlmateIg04hpoMIWmE07tcMj4WMZXMkZDEW6QxEREQwgwhoaiMMKV1VBM7W9TuaOwW IEeV7xERkY8MKhR2qiHQITPTy6M0g0CMgfZXNUditPOPCS70mmjRdT6hnaxqdiFnZUhHP+Yc70b1 /9N5h6cGp6Uvn8mnDgzsbwQJMg47VYvk8Zf/S23HvadJ1Ux+Ss3f1XYYQjwvl0ZoLFv/6017w1tu DD+t/Kc1derTO1MT//sR9P7qyLsEf/uG5/877/WV1VF0F/hm4rYYq/CqhQW1v32RdjImgL+/vO5U aEU95mC7QM0FO3WI1CLtIbEfhfS+/W7wtjwZ9raHhpXN0lBOrlKBwi82eU5G/Yj9y0ilZ5DqdC3d jnOqurZ/hm/nQb2n76u/jEREREMIRd4X74MwMLO9AX1vSDN3+VwtCI00OPwvd2I3+OoiIi1U5ERY QuLWzIeL5B53GXzslMREREMLIJsk2Q/C2EyEilkZF4vkJlQjuGO1dbTdFwzp6hc1iqEyp52N5CZU I1Edn803O/3Omc0Z10+8xzyRwvM7JWIdqOzqIFTKWC5L5UZqZHztWZiNZFXnYQ+G//Tur0m/9He2 i76CbCXqdREXDo6dmoRbfQZ09Puvv/rf9uv8IdXkh6ujZWE6NBr7hJXp0a/o0f/69/X9Ia/kYGPn e/0M7lRW2qdeccw9GfdXTf02bVpX1NAd62t1BDev1/239e9x7f3evIhq+/f3FKOqEW9b+c9vWz6m RfMf//b6pP67f91r/6yusDYwZtzEUwwlJDgu/pj/S/zsQGLPb/9qq//TV/9f6DCcNMUDQq1Ea/DC r/Uf7ddAhT/f7q6ghxHERDBMLZKQhTZHiPYwZgftYydNhWvV1UYaV1WWkUqIjhgqcVGnn6LFNbFB mCWNiKYpjlDm2BmnGTYLRCoREZyI0ItAwhacWmE00LiNOy3TsREREREQwT5BxQMlsXZXTnZkQREZ hEQjubKTNed3iNtlDhqnQdNVCl9BlAYCDTKkZJrNZnYhup3wnRoYTsJ2ix+mwZSQQZrEIOO/zscZ IR3plaWncMGXVJebunnHTzjp0E3M9Gt2RgSaIX00R7nPpat8X/hdXVvSfpuFP2nO8aSTc2fmt3p5 2Izr/0WOv9r7rvTtJx72ww53O+nSarSd/9bpZExh9ff6NrWvr0n1kWnbXcScMFKDFYvRFV379BWx S/vrv7Xa3+YQV/f/7uwpcLHjGF6xHa9/fvTrdKUrReV++zynRnRujQor6hqsXWNWIpiO1tLXiFv7 qaAuuu/D2p/jERFnPQ3YTFMVEaC+1hhLe37Cujcx+IzQVFhNNNbCt2KYqbCnj1ZWwxPsj/JvaJkq EzQiIzo1QhoMKEIiLSi1Q5ahCk2WuyKJMREREREWdEREZNlTCqXz6OmmaAuZEMvlcLMjDKdHadEr yOYjCHSp70udiInwmmmpCQIZNMjaO4ZkC5a01S3/ns+UCI/fouGjQ6P52OIagkjHCz6NQQi6P4TO z5pEDi+RREfMIjpTucNGc7+vbFK63fhOk/qlPudNU7RY7OzULl8/roREZ2ahDrGL7d3Wu/8fdXej dRu59bzZ+EG+vC3LHS4T/sR9evnQXSfd+hoYad9Nbq82fWd+0z5mjU7v+2CH/5OGJ3KHMPv+Gvcb 6i/XT+/uKTdA/vfwzdq1fSRPw1EQ+tqXkNvqN/ve71X/dtf7G+DMEDCUawgf3p65h9nNs5z7ns8i KERxfMYuxG/+PX3qnpimKhC/DWOqP5SgxHo3ScQE4ptLV/7+0uIiIhhBhCLsUhf2sMw3dDZQ5nCi 1K2FBn7elqdmoVjWIiGFi86M3OP5nKsoeOMdbsRsMJJaUZyEIiIoijxGhENNLON2mKmc5PJstZ1I q8hMRZ/iIzkREWmhGTZTETzUIdMwztTiBZ2kR/IvHYqxEREao1vVNc9ENhNVgwmZamdqmWyFKjZp vRd6gi//d8hdqy3Z2rZdkQi8EGdzjoj/JDkyktz7cknJVnGjpzwVuyaszUFdId+E1S78JHjqyrcJ t0wQ5onbiJ3ENdNBqfRrFCqEygFx65my4THq7f7tBEdDSvU7tUmwl7Ig7QIj+jW576YVbRcOu/r/ tr9AxCEECq0t0Yc8Unnc790bL12k6Tb6LygRH3rmc17Z71Gf9nl9If9f69e/7b9brvVq9vCGm+mx p8d18jHcVpR52IBw311+3//7fX7+/6Wr7ZGVWP43Czc2gqYYNtb0v//BD1v/V9Dv+teDLUQs3Wh5 hzD2ut+aZQ8i8ErpjVtvtL9K6pvSbrXc9/tr9jaEMEMIRERaENNCHiCY2vjY+9k3BNhRjW1ukbsd 63Tqw4iIiIwTCHGmnYw4xTFMUx+rEVYWGkDWCERDCFhNBoMJpoXmy0xTFDLITxEREQwQYQtBwwgw g1JssxBcg46iHa3GqL53eYRqztVyqwiIiIybKQTNQmdqQdbCaakDzWy/aZ36P5KGYzs6IXkLVLCS JD6V1fPZDrXovn5hrfZ27CZK0FIPJwwdzyF5CIhM7W/O538w53o3ZsoER/nf/6BEfvvZQ4drToYI ZDrU7HEVc7HRuKdl8nDFdsiQYr6Gg3Xa9v71v+IMO0qbRMevs8FvUlIhqEUJhNdf/7eP31ve+v7W wy60ER18EDz/3qE6N1Qrvrc0Gdf50f2z6+q9Y/r7VKLBiEK6jj4q3QzuVGYc71IOqd3O9xoG///w 1Xfb6UnIjoFb9iMIt077/0+t3W5pFwqpbr6WWoQrsf9qhnamEbVfWbMRXpOSjCCDlYDGuf7PLW1b 9//9f/xvQ7selEVEVTsKNQzc4q7uoa2mCFfnv/7an/9K//EMIRYU/qZWmnwZ1AprgudCY446bSKU GH+7ofFjr0r4iIiGCDCF9oWqxdheDMoFL2u/rSxG2Fk2WYREREREZ/U/3amRFihjFw0rTFSbKQQ7 JwiIiGCadpoRDQaYVI1MvkJhBnaXkJnc81mSaKhHcMRERERowT6Ldnap3nbioMjEmmgyni+VGdmu ZE7oER++E2vhUW8EM6hAiY9O9T6OsXZ2JROGCDyDjITjeUZ2UK2e631f9E3wm1WE2k/qqekudqIu zrGJfKTNxLGX1KuL4ILGvmbLhKvcnyPEdLCB1bRvSN6ptAi697ane88FvfVPCfal89Q011PS36/1 +sIRHQ140KvS5QKvSXe8IP9Tv53dP/Sa/q7VGB/DU/+td9+6+7CHfq52ni4UezOMBCcHpbrev3qe M77ekeHj/SH7wQqZGz6tXe/qph8fX6vqvTr/b/+lvd69s5RH7YWvKWDvUGYoZudd+iRretT9f5+z WVj9X/qI//7rq8bT8UDMn4WGFjQq0mHrfNBT46HfUd6HvrS73//j+qgwhcMKh5eFDlD2KW2KYimu h2l1hpf7Hxq2oZIfFK3pJ7rm6IiItCIcMKeebrTQ72GunYr/oK6xTBA7rGs3WOoiIiIiIiIiIjQa GhaHGmvapiq45N0Ml2IiIiDBDQi0LQaoMIMhedqbMRCZ2ohERGjPRY/86BTufBkuy+dqUQPO7ZSI hM7ipBuEG+nyaXISr0fzp2EGU4hmC4QZTsvnTP5ri+U8XR2Jo7oioR2fIRa1fSua188Nb/dFuwtI sdr6hcLanWLtNMi8U4Lr7qyMijMBN6DdWLzve/4QdExyh1PZooINrpquudhK+3OoTPdGoT/2q/+4 Iuv7/rcIXFBPXO9vWd7c7/6QIj2vcz19GNuoPn6+Pr/3909Dtq6+G0ev6Xe/TrP/xn6jd3+rY762 CZfSbf0PrV13/wxVf7vr5EouFxbruhxqhQP8NI6BYjDB+uThi+z6f9//////fV/GcDAa9iqhGrWN Kf9PRQKutr6mYLt63pHYgZHG6Xz/tD/osc8HH4jhqbfnCCCYrzpwwqHDShhKNLvSdVio1H7NyusM 5lqI7Qi86Ii08INP7FTDlD2KKWGGKmRYjiKZMcJ0tY5u3UbxEREZ11oKhNEGraEWEGgcWFi/WxWM m5EJG0IiM5ERBhUI1P0Xef8mymy+EGVGdMjWdrcQedqgh0QiIiIiIjW0WOzWLIIg/TtTCmYLnY3B VO6kRhGpmI7NagRH3QQcLe6VHavdGBkHMjO095GkOMOObY2fQ6cwES2grQ1nVn3BmtlfVok+azO/ mzNBr+7apo0e4M62dQh2oXn/LozSa3ZToj6kZFRhBnZ4g+v7zvenfvcavvP81mdtTu0g3CdlW/VO 9aTTRrfuEIyG0zr2ix2duE/6//f002k+8dP1vX49XP/f/6fhWva6CDr3ff//1H/6S3VfvwRae6i+ 2+1S3q6N6hI8Xern7/W1++sENb9Kdyhj/r6//++76crYYfx+/V1E0z0uIptK2+16O1QK6ghqL/Gl feDDCZhBJtVQ2I7Vf/r/1LhbUU8UxiDPtbUNKnPq13V1bVhoR2bgQr3pnR9/1V9/hoNC0wuZQKBn CC4oWuKijs1gWFHU/QZudqvaUGXceEKtbOQz/iIgwhaa9odoNRBAzg4MwO/mgY9jQ2gtWlFfERFG 6IgwQyy9lTuOLSjtbWDOoFJ/JvrtCMIRGhFnRcMEz/FhbU3R5XWUdmkQ3ZrZHyEiDztTyrM7Ridi yMMl4RFxERERERidrIT1s1CKp9JkyDBT5hFPF8hMEM6BCEQ1hNpOp0CaaNDUJphc1BISVnaiI1nb xfNYzWMyKGQWo394Iv6NlL0m2eC3SutqjAzjeQcOuqnZIyPGuL4QZCQQZV5K8wioyoRahCuK6X0M 7nhv09Qm0Z/O/RuX7YSC2jW0XDXC6LdnT01CdnQKU6Cj3/v/v7FJ67XfFs5Nnvms8ZIfO96em0nW 6D7o13XwQ////Fdd/1/HGaRcKk3aM6f9W6dAi/c73Sv6Daoz7mylhnO1uqs9/a/f9X70l9e9tr// Xr+/fmmbCV+87neWoGpXMkdggLthJ01ju6m5tr1db62ckYGcYp//r7+//7//Xppe4t+2MVYpiK9j +0m1btb6ivH7V3//XX6///eaARHv/+zkWEwp+jTWxTFMRTEUm2c7OXt1X8aVpXTf+raROGLUaHvS X+IiIiGEItNNNTdQuOuMdjY2NjjWNK1abSXfU6hf4iIgwhHxEMIaYTCaYpimKBnUDa2IpBbHLIkR kMxn9T/EQYQYQYTCDTWwhdqYJ5NlnIjNURrJ0fwp2to1BDsviIiIiIiIiIiGCk2CqyHIOQQvCEdq dxl9EJBWhhsramUuSFNp99WH52pVzbo7YuQcQyZyndcQedjcQcgysZ3PKeMg/9Tu5oM/mg+fpXRN ynt+es/nbimoQ7VhDUIwZGRdlAYKUGAmVcQeQmQfZG0dP/ukHc8jeR0Cir72e538IYU1mfX+FVQs hQ6aqjDh51ENQh07gyDEz/f/q7TQjr9jS7aCVO3v3yQ9G7NmbJGG1O7Z4NeaCY9IPqF+wl9V6//7 r/cQgvzbI4Vun0eE9DQpCEvcacYIPT0jdn+rzwDRefghUffjP+6BAoZHwqPufSCCPJf9Dhgih+vr hAkvStK1zSMBaHHxbp7/hJ0mvdYiK2/CCV/Gf6oR+227vr//d/vh6F+DMEXGOsMJMmOFZ7vVQRT7 X7mgp6MPt1s5We7PIGDulv6ejG6Nyv1IulbjuLTQuxQcY2IpCOKH6G3P/ehR2MBeLtjp6vvx9s3W cicHsEFntdCGEIaa2pY9x/94r1JAWgsMK2thftDj4hHUMI1lD4iIz/FhEhBghEREWp/zkZuUjJ2K YqI2vzpwgri8XERERemnYIQwmlF5/z94TMdfJuVZBoqMRERERmRERERoXEanTs1CHYVnGdiaKmjp nYaMIREZNxIItqg0GdqGE05BNmrs65hkJHZjMZLo7PndEdmLu6LvUw/TJSJDC6anXwnnSCDOzVaZ B4QZCIq8p8vkpZiow54/CGkg21O9WW5nwRH+oIj26+t36Z1YQZ08LfkLiLo/a/+q0ltGc74Qbbru kn+d/U7tXrmt0t2r02SkS////09Ja7pb/+l2u5Lv/Sep4e6BF11qr/s0DDZ7/9L2////93/fK0y4 QnDFX/XSfujDne/u+kO0ko+2/+9dcFMIL///r+v/1r1v92KBmsFsYV1f39+orQjukoryJhhqbnOj 1/r+/9/HcZ+tbCXjhhIYjcKwnTXUaGtdtWKwQrftfcEOGFW44tC0xtMLBn2KCKaSDLsFe/fhdvW0 rbVKIiIiwgwgwhHaHDiOOxTVAzBBFMU94M1hREREaadoapoNVFOMmymMp4uioyEzXl8yqhEREREQ wumtmsU1CBbMqaZ2fKfL5UIrgaMhPMoQjRdwthVVwhZ2ahQnZqEIOO/yEzqjcTMHOkRpEJndowky so7HEJp4VzvdF3RblD0CI/yLD1cKdRCaXoNMLntM1ChO2yqJVIRFQrJPL5GIwiprv/CGELVPzxeb KM/myvfSBEeZ494TXgyVhUaCi5x2a4JwwuE7JWKQmdcw66/46dr9PXaTSM530/VPz56ebKO+wb6E IUEKhra4W1W+/371VY/+NJfmcXC/irb5OyOjCVIfciKf+f1Wdw0CI+6BEftF39AiPf9XPdnl139/ v7f//T3oRHr8iifY0ZyoozlREGHX1vQeqp9pX1HF2q9/1Vnlt4QKy6Bef/+se9eot/d12//9CThj +xsRrsRURk0Ct2sd+hEUPxXes6NnNvUIu+jOUOCI697TchoL+v//aYU3Z8tdRFJvawvcK2lN3eP6 Og3IugtCIv+/YQX7+2e50f4YTKHCafDQYUx8yhTOVGooGdR2tiq9ViNBZEwv+/xCvS9IiggL8VxE REREREGEItCGsaEWhxeboaguFIXTHxwTEbEaF9uFlkJ4iIiwhFp2E/PucWhappqW5Y6ra5NlpEJk KzoEERERGZzjxBqhDCYQnEIiMmwWkzqIQedQmdkkXzItVC4iIjTwp0CKjbSuTxPnYlEvGoUr4iEz URGERWIGyTRLGI95oKH8w5Q6pb+jqImp09NPCDTIPCZ2qZJ5fKc76QijDnfQh7Pc73f1RMf+i4aL h0Xj0i4eQ7RY4an0FwmaouZ3TNeRz+9b7bH+h8453oEDX3CeE+/Cd+4QfVbRcOM7gUIdf/HVL87G Auu9CZLLI+R0F321v3W1p1ftAgV6bnc7sKiMfBDs8vvn2tv5nJv627QiP19/9zMMfVt9L0/ujDnf P/ROGLfOgTfXF5kdvc+pCj9frYjf9d3//X93xhl1+6Ss93pf7fwYTRkQQp1bWtZju6tUK/9/pb4e Y8Y0W4KNiK9/tUKfq0rSBmcocER60qwQ+l37XS/ez6000wmh2hEd2K/BmCBqw1xHJ+O+m1m7aq9R rbfYWIiIz/ERhMqcemKYhO6GODOrFVbEUUA7pPrHJuVY4iI0wmhGRRzjsXad2k2F8Vyb4ZCBDWZr CGXRPnYJlCERnIQiIhgpjxEQ1P+ump2p8Z2kOy8CiItNCI4InSMENDn2tz3nZrF2nEZCZ38QcQcd xl8lLMRUIlZnYqhE7NfV0k39sn1U0aHJwceahDscIQ/NQidnWLv0wmStl8hNTueQiIxGFZVLq2e6 ez2+GG9TvSbbFtV3ChXVOnqaGvZ0CHY4hqECdwyIgg8cfsd4YY0vuDDdGHO9G5fN2d/U76vSdW/U KF4ee0WO9f70G+rrDDGt6H6Fe6W1fq539I3Ubs2Kd+dkh9oIN5nKHKHKdowPo+0of/7/f/W/T+Zs uEV/zNlwlDTpOu2G3qn0Ij1a6ggjffVqYwvvev/+/r/+vjjXhkU7/72e20rPc3MIFse9KECPd3tn MnDFnu9K9Lw1N1/9qbrdv+t6+SBjYqOtQWgsWoQSu6xbCjfVjWwkP2vqNaZzc92e29QROKG/9rd0 MNOhoVxSgzhMRVKx1dpMaV2aBhDNAX+jtSG/awwRHU/xn+IzOSHiM1OLU81z/DQuwhpimKapfiOF zdbSiIiItC7QanOxEREQwhEQ00Ls6M2ZvKe1C6uOTZayaZvIyERP4iJCYiIiIiItAwVOLQYUmyoK nYQZ2ZI7VBCUhCbFCERERhd0W7O1hAmdjeqR3PITITO55KzTom+rhNghRoyREzERgU26mapSMQU7 cUJlRnc9skiO8M1sxlOZJ5Bx0R2VqgQ06urBnCWqwhnUIFmhnSyaXBktkGg+0GaxCcMJl0XRdEKj UyPHRp/60ZyohikYc72z22fVJJItyh6Tf9pqmjRp0aKpMREMlAqvvf+6TwZHt1vHFlbzASdzxnc7 4QjT7e7PAOp3pBurSDaLcofM5cYIjwVer2eX9btj/0mv37eu1+IbpbrV/hC0MJ5stok6Rn3T4u1t b/7RgU23UzlR//b9Vr+vv68dut53t1uvVim6f7+qGh//89uoTS1IaCX10/frr//7+aCntMfHsOrP bZ777/ylBi6QwQpCFH/q+Y7Pb//3/9oXDCYQtPHGh/sexq2sKmE0ra2laWCOOGC2r/+3pWsREQwh DXi0NDUyMUDNvzFwTrFMVFhQhG2lDUbb41YYSiM3ZsYg0LThproWmmkOWOSHsUxTxTFMVJsqGRZE CRvKdG0IiIiIiLQhhDNMofCENNBoWmmFTUJ2CplcaRFEI0LiIiIjRoeXz/+2VwgpCaZl2QmdgSMI ROyTOqpN/03WF6L5+O1MQ1CBUyDyEyCZCZUZkLmao3nZgRdP/XTojH/eFChNyHWdRCUQQZ1kHZ2t ZBwTuyEjWjcsOv/v83ffm7N2cf+vaq/ot3t4Q0YGH+7/+hNIwE+qGhV73RhzvqeLU7teoQevWod9 iP/7W1/rf63/S3M4uFIhdrdPz8rPqeA9q9ratn01P9iP/Wv7SX1+oM7GMjhTNlwlP5oC6ixiDDtp Bn+wwkw0kGRzHw7Z7s9/QJkfC/3X187nH3Xr/19Yr2KYorpwx7NzOy0ME4Yv4irbdj2NIcW4MZ/h qbtr86Ln0jAzwoaF2E1JD32tVYimn1wlS+H8ferXu1q0oiIzoi4tTIzIuGYJig1v1kmv7hhWK+Lz /EKIiIi0LCaFoWhaFxHHYpp9Y4KTZayUkS1G0TYrQiIiIiIYQYIRm9dVTKjTTO1nIOOyUzWkxERm cofV0a2dQgXO1JoM6NM7BmXIJpn1DJiIOOxLNRGvO6s7shEHEhPpaUER93WrpUW71hlP5087JiJq eRKYuzWIQeQlnf5CZC0VCKhDybFqOZH1Ih7zud6TfU8OkeNTQ4Qfzu3vuqNb4a2FIdeQeTTs6iJn QKmduyPIHCYQj6v29LS/+q1bfYf+jdp+mkd3NH61dPS1dv///f/+q394ZFp/odt/3oH3yj35+TzZ pHflO4o33uv9rtL/6/jX/OzUevel775oGF/USKJXf+ww/i6/3qxrFb9OqgidwUulBFDwoIH/Hfi3 //4TLhRbM2XCJbsitQm/DC9qxFaTrardTOceTQehFIRQRLAbZ7dVdLUEy5Tosfu/6/rHYhCxTTC2 lYoLYLQtwnaagiRHwxaU3Y0jqFQr8pQYs5jP9Rm76hF3iGE0GhaFprYp+FgzgzbEJWGtbSpMmOF3 Oe0Tgv50C/fR0G8REREQwhGvcWdFiEOPM5Q4IHEaXBnT9UFVsaoK4iIiIhoRaEd3+dEXmCdioKpN lpE8doRlGdqMREREREREQwn5NgtJyGDNnZIC5B9naGd2jmW+uIjT6o/0sGEGEHZ2SEQmdcjWSzLo 1iHRmMlDOxtHYmu8816LcmPeGi3fnYUede1Po6BQtr2Qmmd6pBmvIrmok/4QV7ChB87twg7CdCVD 309dGBrtGdnc8ECTkUOYR/NQicjLSvPUVBYQ2xI7SSnxCT41ZoEUMNbW54v/zRQIj99N1ThCOD11 RcOQpRUJp/XCCOKDCq6HIi2np/9tvoHrdz0r/m9IiD+0bMJ2Vfep3vwQ0FaH+v67+u76/FeaBhW+ dzvVekh7H7pb/QSWZzj3WZEETza3r/UYt/7+/+2EXp91cEWWf8zBc7EBiyhzWCQ6F7S8Et6evwQ0 l/RgdZ0VX/uI9/66f44/sbXC4YWOI6m6dQj6XdLsR/ZGN7PeoMmKkQf6U5GY+1OdC7CHhbFMJwZw e1jVz2x9r3R0WDN00Be60Nj/fiIiItNBhAwpz9p5oKLRSG0NMpHY0Or2GFOgUMmOFS6/ERERcRoQ 1hgnERqRjNTHsVBBoWld/k3IIsiEdlqERm6IjMWIQwpYLERoRldTCHZl2dMwzIVyri+dgaMIhEUd q053PERYQjCZ2qhCX001P62dmqPQJpmp3nZfhkvhSVEasrSEVO3RdEeJoho1GldTj9V1dXXy+f7h 5/CpyNzFZUMgsQedNQhGSorI2inennc7yf6V30CI+/zjrQIj/91KgPwQIj6NbiGCGSgJhNJBJoii GEGVLIIiPHYl1te/6sjK6r+0m+u/rFh3ggutgiPKloQpws0NgwqLdkqEJSE/+/X1D///tL/ytxgI GGR58InEVefk8/qdzv54XQeVjl3hB1X9fx38OP/rWveIYIp9rFXwrq1u1H80jARWrOSVikgmltGH O6n/wwYK/2x7a74Ie13qxG1N0ETihoNbo2q/XbtXpj3BAsaetvE7EBjELbWc+goPNztV79+nGs6D fijafW/c+v2pu+b0rXe//4YQx+ONbEUDOoEVEYZu9oLRuzQ1td1eDBN/GtV5wvREHn1r98x8WFtC 7TW7TV9MK93DHGtpCh+vbEfa5OGG6/hm74iIiLhggwhaF6ocQ6GxUsfsU+sMw2GkdQi2FtuiJgu/ EREREQeaCnKHKHtNHscWmc+ONApnKcocoexTx/ybBeSZELRkW+IiIcREREcGFLrQiIaDCFqciIyu ZefVkvKa4vnaWjWlOxNHVGQ6EZ/i0IiIjVbJeIc507Ts7JIJmYLnc81ihTsqzoaZTxfOxKIWhEe+ 9a6ThCqwue+nXKXE+aAupCog8hWdq0ZKqIy95pr27oEXWs9nzomOUP76sLf15Dsi9qfztRF2VESt AgSYQM6RhHYEOVwUF3//6XRnKiKV8IXeunne/s8Hx7/3qt0CEcsfEi7EB9D66/u6/crbI4WhvOxA Y//UVfWrr3pAiP2qCbYaJw7OhrFhMugoVdqtNv/4f+vx1kSZcIRJlwu+9703U3Unmsz0CBvfNBT9 CMIVetv+wp/2e0NGgr/v7969a6t5EX5oGKGrp3p7+LznwmmOn+1HwQNZh+Pa+qMf01N1pG6CKdpd IcNf/1b/7TX4M4Q6gfGxXhDz09sNKOvbUax7iMEPhuks6Nn1dOt/ERrf2ELTQ8kOYfX0xTH8Nf+q n63HX2Ff6q1iIiIiGCFghBxEXYQYTTsQh2sGcKPsSuVfSrkTBewtq7FRERERFpxH/Edq9imMWFK5 KjIrjeVCKhHaUhEREREWURYTCOwLpna2y+nkQk1OwuTNRnZCMtMRERut1Z1CHQICFBBncCkHGpEd EdEeOqN4IGVGQcdmMmET5kD6oER92nVeaIU6eCERQTCDXNQgTI8dEuUuIPIjIRQzuhkujC9elc/5 uzwfqTcmP365reFK2yRK6d5ePfnRoMoMEHIu4DCdnWLs7pkLyEyE7//jQj3ToEH7m7U7un5usMLO 6/6/paTncHNELqnko1OmqnYNnrr/Xq/0P16WlZnGAlCGISV+6/9Tw6nuIdJud91O+993QeWkW/f7 +//6Fv331wwtbrfyJhg0ZcJ/XYJU/9Ldf3oz3b/q6wzdZudfbPoEGCKHr668znH4/XxDI6C+q/7w Xpb9ORkRUMd7mcXC0GHjTYioqMzBe6bWDBYjWOm6Ghez3tYJlxsRzotTddL1///7+vXV/TTS7FRS HCOoVpbC+aAvarFBkUf41xr0kDJmnvW9KDRkVMJcJPO5UXb4doMJn/Mi7UseDODCaViv2Ippn/3+ lGp0+1fqPbfBCMEMVH74iIiIhhBgoR/59iqHmPaDMD774a2gsUw0ojaClXewqfhhjiIiIiIiGmhc WhxaHgmKaYWNYM4Q4TtvJstZXVIREREZ9kBBhCIv4tBp5XS47LQXJfNcXyni+QedpWdQgiIiIiPo 6hFsLnTs7VREjseI5EKyEzscZV5B52lIqEQq8zlxSV1vcLPuYyL/dqdOztXmGRmEwpEwwQrJUMpc VlEZlQik+MJuccz0CL/O9/mxdXdBF23XTTOgU6id3mEfRCQTI9qCBnYnSuFAurq10t/+k7Zyn5/1 +9Iw/VFuWP0a3qnpPnpT2p2kCUv7b2v/6GPenNAxTlDI4j9U6N6RvjCB6Set6QRH/3ua2uZD//uv /tIf18If/0ND2RLMBK/9Lu3+m5+/bV/v/U0DDZzn3WwmFZ0bzHLHJj1/71dP7vzQMV796TqP20v2 I2Oqjzs8EkK914Qg4If7tn17zuVH2I/3tW697TsVxTUUddOzkEOvtLvqK4Mu4YK6io3daMj6oYQ7 XmSvEWhdhBrm7HCBnGLiOsGbYnCoaHaXtqDN1++kYfvVnKIiIiI84VHUdx5Y/YprinftiPP83YYU 7EAvLI6n+IjMeIjCM1P9oWmvemnV7YrldYZkVRECCJ3PEREREREREMEIiIYU6MJnZlhBhSuCiEFx ERo0B6c0iZtqJ0iXOzWyPHZMZVo7pkKRGOk+jZoyECIwMg6OuqZSgwdcxFO7CZUo7G87nmtkvFIi MiH917z+tXCdXmhmoIkmg10W7JUEO1Yh2OIEGEGa2CYIPK3EH6s7LYuFp40Yc8bPbPh4rc77SbSm g0OkYet02qqi3aLHYQ5Y7y+fyUNM6tB/X/32NW+nS+nnc7xoPVPO90nRvSN1F3hB0EG6QQdb6vvd GNqftqX5nKHBUm31/+667aX9r9XiS/TwnX3m6lfXSM+p33XFXeroR30YH7bX1f/7+q/9B4qNN1ve 7/10l4/WGFrv617pvr3/r+/unYe9r4v9//9nZK6GLoRchZHx2e2Gk1YLGsML/axW+r9nKGwznZ7e rzH6sR//w/+LUcYhimKbS420nCxpWsUHKwGI9XSyQiOT08fHTDzkRnIU2WFhhMJpihaYw1sUxSYr mkhxqZhYahm50rShuIiNCM/xEQwg0whFhNTdmRRnOPQ0OExVbS6g1JvWhHERERERcQ0yxyhzvmHO OU9nVoYQsIWhldUjI1kyIyMi+T5l6O0gh3RFclQjCEQehE9iIiPPR2pNM6hCGwmF1L5/O1NWQcFI OIONAoU7nmojXndERvOoQ6o5nYFiOP6TXvuvTzqEmUSGFQzscRNT6TITI6VQg8lkXyDQQdkJm/9T xn9Qp3o73/7ql2Z6aNbdOj+hGjBFYXOjBBpna3EHQwnZCZ3EXyni+Qatv+o6X/f06MOd9ntG7Nmp 8ovFvv9dOv6Nbc6iQ3c6WtrZ0gmdintV/+///rtjoacVeENXffPzc9Jc77anfT6lOcK+1dX0+hX7 /X7Ef+/i3V+7e37x9pbpLa5B2jDmHhvf0CI/oER/qd39iuzlH+rghX6MDfvepfjjHr/+n7TO08XC 1ThkWf3q+m79zsGjCLpc/vCxTSt9Az//6s5raue7rVdGBur/1ejG//av0vXrpeCER/apNpYj8Mty hm1s9xkMK2lG66N2Yc7zrkdAih+6vpR1/VT/9wROOt1/vVrvFoXm5C0wn3F2OPpilQjd6F0Ijc+o aV6tLaWI/beQxvdAh7/W9cx8REREREWuf85NTd6/gotimIp1iPX1hbHTahW1WNL4zdERDBNDOeIi 84OGmhdR3ioXQM26CKiKaV+IiNCIzchEZkRFqnOicMJod3lclzI1iXyEzplWRXSIWhEREREMIGCE RpnayEs1YLIIQztUi7OqPwIGVedMqBndkZaZvE7A8R14Q7mit3p6nu0ztKwqmtl87npkdmMhMheZ VfCN+kRjqazO0g26BEf3mt/o1tGtnaoJtr7EWdAh1iOZrEOybL5Bx0dkJmtkeJQzEVCKjviZxcJO 6un60qb8g9J/0nSdade0RvVbVc6b+axV9zrpr379/f6/06zSMBG+rq0Yc7qud90z8FNmp3o3UCI/ /CcKr1e//nHKcodf7f+v/3r/71t+u5W8210nelunrvvbkh877p//ZyFRH+9e+6UFI8F+uZynx/r/ 9emhiEELfXilvuujOnS3/s0Rz6aH3d1aW2rHSEU1eNC63V1/f66M8II8v/9dfpf1/wmEMtRC1tbs bFDFUFZxzDgiOhbC/N1tW1+3Vvoc9oJVjqz39Aih6T/3/61pDdn+LQ07QacaEWK+tirC23UMJXr2 FU6BWljv4jtK23vq1CGM/4iIiDBAwQjsIcdpiE1GxTEVWhoLXY1pjfVjVtKruIiIiIYQtBhNC0zD 2cDz9YoGdQuKYpjDMD8mxJk3DQiIjCJCEXDhhYMIXaYTi8rpcCDLc0RV5K0FO54iIiIiIiPTO3zE ZFcdUbiUmmUERxSDwQzs1CEIjswZK0QkdkRF10bIQoyFhE06bQyHqgiOls6RdpkHJ2QXgzUVkCM7 SIqudkudreWkpr1apaBEfrlurefczqPaLdnVpyDoBqetOQeoM7nJggZqyNZC+7GVwoMK87neiT6p unYU+Pu9LQIj1NxbYN+QejW1RonZr8g4s1PZqEWDh1/+d9r/Yq+7DLmwzbnc76p0E87njNZ4gw3r p5vSTau2jZ9Xhw8zlDlw312/d/+rrior21/v9Juwwy6vKPW3CCp/nw8at9G7kYztYPiL6v/+l9da ojHCr9/6+/dC/X3EILt9W7V76EiiPIjpQwzCBhmF1hpf/xpN94IVPuZwn9L/6rwib47I6MJXwl19 f/6YIRsWx32Pj7XThgk2tZmv+NW1j2/NBWlYiPVAj/4KXQL+/G34KE4uwnadjapjigZgYYWz3sbr aTQW1qFc3PtIJdqhHe+q2cxn6i8QRO8REMIWhFgg1UcY0NMbWxQwutGPYqNhhJhNhatKbpOGNzoV nZaPiIsocIfaFhCwqhbtPurFBmCChYr1+FwuTZZRUIRn/P8RERERoQyqjnhhOGmheZEeuFyul52p tMnZfTIeRtGRbiI4iIiIiIiMJ6a36EVIJoyHno7U0fycMGpl87pkQjswEIWjvIyryOhER9NzD7X1 0lzs1Ck5gg1smegyoyERCZE+IZ0yTGW+ZCv1wmfrNBnaNne7mg0Vvq5liEJx+ahfMI/6ntztIiOi 8QeQcSpl8hPJMoZ2JKVwsMK49070P04pNzveftI0aeYdN4X1sg/sg8IRmoU6eudPQNOGnCXq6Tev /T/71VtnGqTvr9/+oXde+GjQ4dH/Ixy3v/+//6+P7xREwX/NIwEmcqJQD7WT++T/P9fnfdWzuGk5 Tu/Mh2rr92ewQwQZHH7/6qlXXrS660u3S6jO549rvuIMOnBgzCf/aV1aTxpRVr631U5YdDr+fvty Y5Q5h8R5j0N//6r9X7jv1himKYxyHyQ4TaUaR2ahY17e7Ud9vQIRcOxGsb+2q+vRKMJdBFj44tNO 1P3BximKp1s90sR/evhm7zd4Zu9QQ2+gQ8JN6QdYiDBAwQiNBoNThAljH33in6tGPq0Y+O29qNai FakMbzZiIiIiOM6I4uONe9erxQZlIUDMFBGoHhdPK60ibqjn+IiIiOItOz/Fp2qQJOF/K5IKZaRH yoyFZ2lIhSTERERERF3mPaxHYVs1CEHHUQ7JBSLtOERPIWjtzIgyIM7FcyDQiLiNGuup1EUJfWqD CYTOwYVSDyEyFZFZEhBJuTOjSed9o3VRsrTeYslIiNbmhzQ0M6iZKQi3moyPHY7L5CRB5B5rI7yt Tp9v3oZ3O+hRv0+mY9a0m0m5nSevM8hNLXNQhrFIfpqX7CqfR2J+tL//oV9rJwqow54q9PTjNjRu WjcoVXwRH37ULdo11u0FpnZMT9/a7fb/Wh19X/09CURc1x7cn9L0d7o3USHXpWgRH3DoJ9Lavq57 f7Pbn1r6zD/v11/0I661+7/oZ3hun3rwxW6MOd3bSvSQ/zQMQ07qI8o/7p//b28V/ql//+v+r63x TEfxqhsML/d7raTa32cp0bOd0x//3/a3mP8EeEc4r+GmFNl2pnKgqNRUx7W7dQ0m1bSbVCl4vVbd X1bOf2CFOv+vr9xEREWhEPPODCERxjYpimKit9WSdTHsRUaSHbdVDSW9Yjm7/ERERDQaaaDU3R5u TH7se1GDMEEbEV1dt1Julo3CIiIiIiDBNYYIMKf4tUrUw5U77UcrqkdmUXyDRUYQyHmRjERERERm PDCaHERa57C5070pD7VCxzUkHEUIgzLxT5hFQjseN5UI6xvJsp4iIiPvtb5wYavWlTp2dO09bs7i L5UkQmQrJ87IjmduJ9He+/stzO15oNHgif7C/1Z073WyV4JmrBFDyLhcwjNWoUg8hMg41EVeRVE8 SojsV76/5Ouzkgned9tJN9cJ53/dOvCtXBCghH6rtzKCx51CHUImU4oQ0ztJEfXf+1hMjhY6vS3G nNMwEv9Lb+r33QIv/U2V+tIIaqjWwtIuGhHQp/T/rf/9Pj///fXr0dzxR3O+n/p3PpZuo3UnReZ4 NmE9b9QQoZ/zg/fpLujQU//16//0v/2xt/+Lnc8aHGrhCNNrc/vP++v+0qb91HG5j776BDuifTI+ Ff/9v94j//6//f/sRgzA/ZybCjGsNL62wr6pOsRFWF3X/7V75wfvbvv/Hu7WPHFMUxtd7FRFHWim SHCYpjq21u6JQEBn+6/9nuzm9Oe/deIiIqDCDCDCFqRqwg1TQNC1G8U0xpfFZ/tvNAwaBi1Q7W6O yYSz9ERFoQwnHDK3MIXHmB9qN4pbYrbSsKsmwVEFxEyTwiIiIgwhERxamRnQmpusUxUkOClcl+ys I7VQhFokmKN0RERDCaphBhTtO+DJNyNUaRqZfyWFBkJkHmQbO1gQRIPERERrDKcSD0YJ4Os1CGoU hNBnY+RrCRCZKshDNWRvIRHZNqdMyVfzOGpEH/cOEDqFOoRGh5/OnaLHBeEHIJpNcmdvF9DgyMis 52axBhTsS+INzjnil59I73ngOtGyi76T/8IdZo2oQwuixwRHUHIIC4NI7MJe3vggRFouFYv8QYdl z6GEKMOd9XfvZ9bpBtluCI8iT1W4QjO4Nh8hNDbEx2ztYQSVNt/r/pr+t1d/2GFNSBFD1rhNNz/n /O97PoQ80Fv5VvXSYQW+DJi5/owP50wlde39/f8ZowhG/e344/sYJUHsgebRHWO57nn3FP/9eqhB b7Z7z6/fQ/Sr+l/1/QJd0whGCJpxePguMhhNWz6Y0ohRGhmgYtvtcnDE4Q/+/3bPdnv9Ggov/969 QnaghdC4qF/9WlP9q/V110DC2r60IMnp8Z/hg0bYkz3FoQwppFcNQpj5/zHjGGK8GcGRufT8Uw0h jjjSs9nTXX87NU3sMFiLU3IWhp3F2E0Pxju7HMOYfsccVFD9hXPaHERERERERkh4iDBBhQhDz/YX JCEOhBIXMPlcKzKeQ8qzKmp/iIiIjMOYfOTCFliFR/5fM9VPpBnVH+ztVZfIiIyL53TINFRndowi EhGhDiMKbojW1fTRo3eudGmFyKZR50Vk4YCaZoC5B53TITJRGIlOVjERaH176Tavr0mvfp6hXo6V k0CmrI5JtqeyVCkJkJkzjurITKXkVQ/c7LUcRHS3VP+jPup4zvv/tng0UYdczlx+kKr9PNQkg+8m oRS6KSU1svnYn/VBoRv9vmgYrf/3yPkfBFDzTBFPpxoPTdjCb3n6sJ/RdrCTdr2egtrnaQSxFaof +v/6/ERHZcL6V6+/7c7nf76CfmHO+azO6Rs16BEfdAiP6VsZvrdAhzI+v//+v/r+P7f30Joy4Su6 dyS5vI5Y+9fXaMOd8MvvzddUqVvqK31mPan+CFXW9P63/8d6+/6aHV/+lvW3a6XuGEgZq/GuFvS8 f3W67UEKS/tVbObCn/+t+gRH7Yj///7i7VMU4uxTWxH/hlucYGrEU2k0djhe9tZswwo/+9YzdbOf /f/xEREMKhYQwTCGh2hYhOxQZtzC2NiqdC/77X7jBm7er6X8REREXDTCaecwmE/MOWOh3Y2KHpd2 IqI9viIiIiIi0IiLCoef7W0GnjldLztSirzCKhGQqitYid8hdxFphC1K6p8gmjuyDkyNZOKR0FK8 ZK2J2GhERH2w1/kH0oRSmuL6DO6ZUZDz+U+XyWowiMzsPCZknzsGu81mejvv2wlM8ySwgXRY7OzX s6hNQtgnYUvEHETDB3PIhErCFQiEyVmQ8mAif6e/f5rPFEh9T9VbQQfdb1ddXpI7iCkNoOlwnhL+ u6XmgYNAwk3c73Hueed71ZB/zd1QIuud/BEe+aDRBCtNGCeaGpfPU2wIgjSMte+/7rf298f1dP6F tBEdUuvaT3tJN9Tvf0m637gh9b6oyM6F//+v//hiEPfW+ln2XCDTzud9JXZyRhzxKF0/7npno6T/ 9f23/+tn0/uv+1/691r67f0RDiq9D+/ikngy9rYxiN/7Wv7SMljQZHP0r2iKBiz2aBja763w1P// /4aX6+xH32mmhx4oeNjQjY1bSFooDCt6v90o/av8ew5gfuZHV0bYF7gwRCIRDQtMKQ49iooGdPZ0 YiojYiu20v2lDufVt/3QZY5UWhWIiIhhMoiwg1zIi7TCcaj49Qe0+K9sK0LpnsEUPiIiIiIiDCDB CGELQtChQ47FfGhUrrKMIyDMk0VCITEREcMIWEI9QTs7NYw0HZ0CmpqdrcdRneZhHeM7E46ol2Vh TziM3Rr2mjR6CGdqoqYVMmcmdzjQF1TIK0yEzpkmZ2KZkWoRF6M+6Rn0G9GiiY8KjZXCE7smn0p6 giPbnXuz6TJVF2aouzpZ1zDKjO/iDyjI6I6I+FO5463qtfcHggdEY+rQIj7zOn3mct/oJurX1Roa pqnqmqnZqEwhER53o//35OGKbxnhPvTfX9jCDv7mKn39Jup31O/WoIjzr13/+vMJR/X/XIiJd//t 2//vv09d0l2tJPz92VZ8671j37Z0Vs9+3/XBw1r9e1//7/0v7BiUn9mcXCqJnGDCik2vfppbS1zq iOLDXvtd9hsN3wRQ7S+K+v+PUwvf6f6/tD8rbI4WCI/iPWI3whUduthK1V24jiNtViO1Jwwt0t6W uaBSP6/P16mH/XHaGlHljlDDD3ijQMMRQODXCbSm522lU3W12PitC48d7PY0f/an/OPiMyIsIaPo XtoRRhyvgzqBT850xRq60I6CuFZnKxtBfj+1H4q1iIjMeDBNC+GhaEWsew1j0INMLfX2K9YiIiIi IiIzHQiIiIjU3R2h+VzJHdMlZlORGGWQUQuIiIMIapnY4gQaaDISIPO1vIvFZzpn8yT5rdk8Ir1R cUa2jRNQRTtUCSCFPUimT6pxRLMvkrI7PkoysorluVHOOujdhN06TaTpMML652rCBFjuSHYXCZ1i 5kpCEJqfRri8akR0mdzyVRfINFUV3GU69CrrdPOOd+jdmsz0XewvrQbaPy3Nbu1NQmoXCEZ3CCrZ 0gmaou1g0Gp0M7GqVwVkcP/v6u5pFwtDT3CG1fn9U4YN0CI+6T1O+a4XuCI+9AhS6pqmdQjDYeTi Hatp//f97b+13wYnDIETGorYYY19XSXQedzunpJvn6qBEfep30jPyWMzZo6Wk7Cn+2e3XW/+p/uf X/S7+H/3/r9tv1vbRnKjXtLdejud4YahiCI+jfqeMfQ7q0nX8V7V/s9mgYZ9M5+9GNf9fxv9A16x 6Vv9d+r92LY6H/+xw1hhLtXVD1yBhi114Zh64IEe/W6j/7Q967v/6/r8Kt/x5+tMUxTsVXsUKzQV BT2v44NcJLfTa0pKAn8z78Lv796Uf9ou2Fc+v4iIYIGEGELQjP+pj2hFoRa1QjQpiOKdVth1ntiK OoR/tVY11vyLDZ3mCMFBgsfERERBhNCIiLP/tpoeYcocE1HW6XGxFNK0u3ULutDaClpFSiIizozn iDBDCERYQiGEz7DTQuNDHC+Essc49rGVyXO6EVJEUyDibGqKMRoREREQwQiwn7rhCHEeEyUcPKFl 0ZGMhWQtHXQZHCWdiyK5mhERneLCEac0O/L91Z6MgxkpCEXSdnkQxIzsS5BAs5QyTzCOzVm8p2Ri OZ1R2gQbTukH3X/wVb6TCDZPp2TEhkX7kYivhBhB8MKQedMjWQmQiCCI9nVGFqr//9EY+bO+6L62 6U3L5C677Rb6uQQyM5xwjrrn86LOmp0SZCtLwmmdmIv//f/53TpD98IGwYejDnfSC3JacER96eEG 6eGkI/qn/eResGOlcLf6riNiDCKHX51H+3+GGJ33X0l5REdl0bQVJ+teuazPfffu33/Vfet4IbxH 7YIG66H+g12xCC8IRFotPT+6vuneQoe2+ur73b532jv+60GZzDwZY728ER4HZzCH2oWH+EEeWv9f X9bf9X//T7BEfpLf/cUDMCxej1esEDcXU/WGEgi+Pvm/hBJkTDE2kGT0v33V/8zlJ+h/1/sQ1//t NftbxTCDShmsFuxQSwb7VMji1WTrvVtW910uhOgYUEKBDBDIoGI/X+IMJoRERaEZuuNbCQx2KiiU YjGxFRVhYq1fPqpv1SVbfW6xEWhcRHHmcqCnfIxCaYppihhkdBMGYJwZi5sCBlwEyQ5xwmd1GrGl LQEQiznjCEWhmSBCGEDBNIRvXTi0INCNs49imKldLzumdwjCMjQQREWhERkhyh4iLv0xGwmpXVO8 J2dzwkUIoRUI7gzLVidkjZU0IiLiP9dUZzultMIMhNMq8iMqmQrO7RhMhG5mu+jvt8R15o6MOzrW TmEGpqI1eCacg4Q+1o4Q4M4Q6c7nLSgkqEdk1//8+v0m9IN/VuTpP1dG/qdApqFNQgXCZfyIQTX5 W2Rwq7laBdi4zTMGEqfp96RoemjW+537hLO1IIkFVbXCZ0CZ//XX9UnH5oGDsQBC39U5E8416f0u xBAtKbKLzM5Q9AiPugRH7X1ghjP9vWZFGc+hnPj1/X3/1BDrb390CNUYCTueG7dCghGr63tG/b0v +q6Ghw1N35j5g70Y1X/nHLH/6Wq3r/T176/0L8rql7EerZ9ePdq/va4IVaSji/agh70CPYN5//j3 f9fMOZ/DXQ9C6F/7DCXtbH0xhL4626XBgx//c9ue+tv4pNtDuIMENCI0xXiKGT7S66gz7oIrLhPt vOgWOO9fSWz+gZHPiMw5x4hhCKpC4uNboUPxpKrEUxH2EIqftoQcWdERERDBMlIGmcGbs2WqQuSc ofvK4VnYNHbkd5CJPlGIjPIwhaGg4YQYUhIsoiNcwjPJokyURc0zWZHgg4zoj8TNlYzsSRUISTzs rxERETSkvYiNU1t10XDS0WO9PYMlAYK3HjOsmmd/ErzCO6evQIp5v9ftIER6E6BEfdBBtk/6yEQV 53PThPU6hDs1CFDLkE0zscQ1MvQyBQSITOmSeYRGZhFR2kyh3IRqCnv3063T9O32kd4SEc0Gjz27 VVQtXVeGRnhM6iIg+jsKmaAuQqoJsp3IPsTO0kr19L99PIiXBgxdBEdJY0HdXjn9TdRY5cUZ+i7o ER953Bq4Im8K2F0+tJgxQn/2Irq/1/hvhsMQhIJBApeHelf5rlGhp3ruEHq/bfCtTZlwZ3O/nHvN Bo+GWOHQXtgh6W9bXD9Lg3DD/7f/rb/Ix49Yg34InEaGE7r2k+KQb+gYYcES2L4ZfUmNbW9W7UII 5mgYhhg28fbtIEU7f2l17//6/b63+6sjbLhLBHO3CBHaSLhbWDMFpInB2IoHbSBBLYdsMdpMRxBE crOUM3WNbVQdnr8i+XIEUPCw/Xv/Wuvi6DFr/cdWhY1LoIofOiDk4d21YSTxlbBdtW9Q5GgxbrEJ COMwmz267eltftI3cj4UMscG8/YjjMdhhMKIjoRkUvYhAziE6/xFFJqxFQTCnhpmgYuq9W9bUe2o gkUPlYDHeLTQjM5Y8WZSQu83Zj32hljlOU9qEDPu4MasYxHEUw0v4SEWvxEyWToQahCIiIiIgwTC ETyDCrEPMjTCaYoeoQMdcm35C0QrOmQmb1ERERERDiIMIGEGE0O1ITZRldLlTJQIpfLojpO4IjaK fJKiXzCIXleE0IiLQtDK6qEO3E1iIh7eQZhBqfRKJBhVIaNsl0CKHk0GS8Xyni+S+SppkLzsTROZ sxOmQrITEN8K6LHOPYIj1bmHp62q2EGgwQjBAwuFzrIPc1jNYh0i5kpR6NQnmoyPkYjEVvhkD7s7 nhzsSdGHPGdzvWEIea7dPqY2FPD7pAiPIER90J3qieVtfWrNNVvV1oHSsEOSCA1hw1dB679yJMuF xSd/VrVJ2+qevnhNzzwQed7zvbSnd09o1tF3pAi/6LHwtAiPusOYcjB4OHnoUZ/3+9LfX3fr3r/9 d8Vb/X6V/94Qeq+4R/y59Xz/oQ7zDudw/Sb9/7Cm92e/f9f9D//d/9fr+v6q8f98d/rURCRQjaLp ROQgw3qm9v30PkSEBf7VCO1119/Hs9vv9///9/6/X+4QIJoR7tv/jpj1jhhRYrYoJTdiltVtY4YS 9X0o0rXunPceCFWe9r37PIpQ3fVYve00+Oixzjlj2KaZz3Xt1YitdjiKjV1bSjVDpVJwgWLW/tNM GTOp/kPBBGrBBLqX4hhCGELCEXDCERDCxcaaepnOPDCDTFNbFfuoZOChwkNDYio6INYqsQohIzlO rSuIiIiIiGELVC400NNDU/RoNCMuDjlD2Z7qGUkFPwoWLba1ERERERERdhCIahCwmf4ojMYUJrQj ldUjued1ohaNbK63mRZiIiIiwQ1QtLz6z+mdEejUIgzsLIqRFTRqCE7PRkQEK6riIizo9P9dUWO8 iaTTSvKjSKhEoyBIqcpCYj++t0WPQQbRjnoWho1t5xibNQhSjRlbU/kiBBkVDB38SGpOGCEzstyB 5fIzMIqMr5lpFVbf/0Ef6f2GCVP8J1QeEtQhpHZr4TQSRrEUvn0nYVM1CEKyoztS1+r5Wwx+Pvhi ErZFktnLtGHO6mcjLJ/kh78w5cOez53mcVNBohKtMK66kpCHUJajikP9/jDBeRIF2NetugYONGHT tuk7YrfdMJpJuSH/zj+CI+6Lcoekkq150QQ7PL1H9J6/sG6r7Wt6f/Gnne/ur2k3whanc753O9jz c5+91DBO1Zz3WcjOM/3g84PbaH0v9dG/tdu/rfW1Fa18GW0jStX9k3BIbaS9pX9r/iu/2PeCH/0/ sR+v09W2+293fGg0MsfFex62cmGlbdbn03qjdbrVULW/9762uz3f/rEREdo+g0ySkELxsU1HcXxT vqxQM1go2wl3hm6+t6xv/52Fh4iI4YQqGELTqLjTW04sm9j2N3iKYivte9lvlcyQiz/ERm6IiIYX KIsIaraansofTFbHCD0zuMwipIrq2SlCJObQndERXEREREQwQYWLjQtfK4KDATTJUIS8QWJfOwo7 QZUjSMrQhSXSDEREREdJOvkPtJ5FLAyo2EdlLTNcX1JztImMujsCZbiSzQa6BEf0bNa7CDzDg5om oJgmawgXBe4QWGReMMIMlKP52IyK53NJmSg403TdpNdO6mLENpNpKXM7UU0NVwRIe09L2mi3d2pf P5qEuzLQ7pPr4mgYIky4T9PCCp53O/zHpNz+p3thJqrzBm0gRH3qd8J1/14PB//X/+1oF/t4a/dR Xwi4ir3rX0tq+9ejZ5hw4J9+1uf50Wp+gih5HwXfv/3r6+vS68Nf/XVvned/QlKStBhkKsw1ut6x +K6ERTrgwd/8Qa03vf3/1///9/qmXCiG0+3xTEUvfbSEZKF6/odqsM3PpRmNtWI/46ugRQ8wlg2I 3+n2u01N0ccGfZLQ2GEu1ZhynKHxpId6zw+0lvX3VCI7ez21P8i+CX1wwgYJoRHZz5GCChY4QiL+ xFYMbFTHsRTQWGkwg2DP+MfiE1qsRERGZUCYQi0z/aEO007Qa2MM2xH/WEMRybfkshESoxERDgwh EGEIhhNCOjdF4LluthgIMhM6ZCZVmZA0dzRrSuTmIiItNDzo1TvP6nsIM7CsnzUIQeShpqQep2XM 5FPF0dYjUOS7ERI3iOaCx0jZ/7RcV1Id75/CaVa3IQc+qglJOL5C8hMnM5FGUmdisQcVaO1jBFD7 SCBurq9+E36LHKH91eqEKm14hhdQuSsU1CVal8/5/CDCDOpwynRiBCONaufZcI/dbvwhD709vPCp 0d9styx6Jw8w2CJ/bChaD+qqix2ix34IcI6xh+6/vbv0NRr9/aJPX94QduEGvMSWjw9EY6m7XW+6 CDaCDwnVGBtP1e6M5UUNCvd/+1Wk/X13odrv153V0Pd+3kvU9XXN16nfvdRof9UY+zyCBWXQS9Df N8H7/+37x9fv/+6pkSAjtX7oYZHRHdLe1hpXc/0bt18MECTQiO11+3X1/z6vV//u+mI0Ovp/+I+u xTFNV72x/EdMMJI34jB7Svp1zgYiNGP9f7N2r7z6P/umz6hfw0Ghxx2mtFjwZ1MU/g0wYViOGkP1 sdXdRw6Bn6jdH7W1ftZwdaiIiIYIRYRmnDCGmc8WITTHN5TudCsusoUbsex7/02k2lGaAvsUsRER ERBhBggwhFoRjEQwhef7T7TiMVG1wzdrJvPKqi39nayhERDiIiasREQ0GEGCmRjF5NvyFSDISL4I M1ZkDZ3NKEGZAWIiIiKj+RE7tBqfwgynZfBA4WUkXyUsxlSSkhHjIREozJ0yprvM4aWjXdZna6dQ lyEltMhwSBPThlOiSkRh2S1FTyFoq8R+LoECvTe6QdAiP81vMM6R08wiOlzUI05KPCaWDnUJIobN IJhBmgLkTwgZKXZCZ0aZQGCF5qIiIupbrUYCESjAUIKl92+rrtBP2Y/0LMJAiPtqlq87ioXzuD3m ii41hd/bSCoMKnTW1QXevaq67r7XGfBimrr0Zyo9vqwsw8I3xD1pN03NBr81uFfXM5MeSoRGuk5a hCtT9eaCnt9fob9e/1vfWv0vT/VOu4ggo6enFK+tX6emEG1ptAi/pR3HFwZMP7r63r+qhlDlDlOd yjlucckPv/+2//c3q18L9env/M4wE8UnRnKir12P9SRpN62kjdun6tYjEREaEXiN9bfbUiYY/2u+ Zzucf7/t+/a/9L/q/2uIURTFO7YWI20v++v7SqNXCa2bgZM6EXtdfthr7U3b/7bf3Sji8EGmq4pq OdERmPYje1YpkxzDhRoRxkX+1+6tWIq1Gt1v39euIwQiIhhBhBhCIiwhYpoHEZhzj/iFuxTGwwkG ExXxTYW9bSbtYiIhhMIdoT+znz/ghFppiiW7XtRTxscRyblWTcTxEREREZ9hggYIMIQwQ0GEGhaY TCk2uKlkTMwlIPNRHarlaWIiIiIhhBhAwUtzNpkotCMh2nIcuasqJCoKaiKvISJWhEffct12jW4e EMlHkyZdnZqaSZTinUIEy+RVFGdquXyVkRGdh5E/CnfuM+P6dljlu3TVwhDTQSNbCarZpnXTwtph S8RYQjGFyK5ri+dj5GvpX6T79wg7qjen5nLjPAqnmzM5T0CI+/+m6NbXCDQ8vn9V1Po6a/6/r3Vu zDLhMfpq1a7SGhevtfRn9OgRH3Rf0Rj19wt6e/6tftdS/X9/rvVK/v/HHXf18JtG//zvd/vHghV4 IVdf4aRuufShX/ze+43/Xr9/7uL+aRcL/b/oLtruu2rj8MKCHqt/pZ7X8Zqd68wv/7//9d7WDMFC gZgYjhpC+hbCiKiOGsZ1C+u919Lv2tnuI+fv8elFhU06sVXgz7wm6zQMJpMRXuq2vera2ocd9+gQ 4iIs6IaEZ5rEZj+blMFquIqI2IpiFGGf/sRSNzqIiIi08x207QYQiGlaaX//DM1Ckm00QpEYQiIi IiLOiDBCz+hcaDCHepKGnkJkHmQzOzELiIiIiMtzQJ7Kf2ZECkHhBlRkJmQxHdM7Ws7AkXh8Jsfw p07TOveTtTrF2SyCnc8igOQrIPNQQh52QzIz6N1XNPXRblD10bGvoGdvHTIsIqYQ8KSkQ6doKQQb OBMp2XyEyDjqjcVLJ6Hof80jAQ0ziBFOoQh96d35hw/Vqd680JV0YG5JQW7XzqETTJUJl0ZqH//V MIR4v/5oGMGRpcxl0R5UZzvSW0b0rU/NG67ufTM5buDQTa3rpp0mnD38fMOd79//+DDiIj6/dxKW GBS6H7ToO88A6ed783anijcvynds5trjQuKNzc9k4Y8KqNBTlRcHapW+vXv+NK9QYNdfM4wEof8d 8MGX6HDCU9nv/x1ahDxF1Ee+9bPKZH2/rfcHf/tf+r3j4YrG/fWccscocE2lC/t9jqL+6TOZOGEY HW8ff6m7Z5ftsRhEx+f7C6HGpnKeNCMYMyddva0F9W1ImGK7r7X1Gu7iuzm0EEHiIiIi0IdoMJx3 FihdFjlPHYpTpsMjovMMKKbaURXmgL4WLDNzBBcREREWCFoQ7tM6OhHFPFNfta/C5Nnjt4S6ERER HBhOGgwhGZERm5C8J4QZLYvhMmMqM1xfLdCTZ/QiIiIiPVFuwugRHiIYTNQRc7Ssg41MvkoiBwIG S+dkgU7NURtCIjSbW4TxaredQi9H86hEwQZ2Ti7SVTXF8qMlUXyF5CZCI7VWVaNXp53v2Y53PGfq O99JfVZrZpJ6c2/noh1hbNQidkX1NQlkvEqIqJBnU7gyXRuJYRLB6tf3v9R/5xzvnfdvP9J+fNTu 9/4Ij7pJPuqnURN0WO6uDQaaaf//r9/zstZHCq7pbvqNXrfu2cr3dW9GHO9Ai6yD/Ru4SInI0dBB unngHSaNbmt+v9f///tv+1f63X43f6W6+k9PuhJ1zud/TfXWL1PGm0n2r6xHH2c/xn+/3qh31b+v CQ/+vb+/rCZcJ7bq5oyOFV/BFp/r12+NLoLF3pf+/XnK/1etG3OTkXQXr/3r/e/99Lf7Vfp+7FMV OeGtWI/7WI5+xthYtKNJz6RsxFW6/3W4IdnsZ///hqf+t0G3+/q00Ii1NyaHdimt1imtpbXdpiPv YtRqNV/Q1FVunUMHFbq2sRERERYQYQ0z/DCGh0LacMygJ2OKBnCX9jbp8n44o64XC2layb1YiIiI jjTTQtBrn+O/O4IjpRdDaiE1sURUMS3M0e0yV5kFU80IiIiIiIYQiIjJDljsGFL3RLLdbKyCx06I TCDKvO1tGoIQ8qsVNCJ2t4zkRhAwpkbVkXNMIMJGoImagh2paaVnkEGU7L50NM7EohMhaJYiBZ0C EJiIiL4TtKhCVGtrujAxJixY7/bJDPR2OIqYTL5raqRiUgmd3F8heRRnsrjNe9Tw5oU3abmz+wRH kEHC2wsJ6nUSl0OYIMi7Ca5KhLs1ZiJZF8hcTSQ62l9VQq9D22e58vXO90nmdujdXQIj7a0tWtrT aaa2SgLIJP6/6OL/+Pe9v/um+hRnKiRdAin16N6s9z/pGegRH3Rs09IER5XSYbJ//a/p2/9Uu+v/ St/S4IRr+LHj1ZoC9fTSV1ToER7m7NZnhvurFJd7Zu1s5Ahzg+vRj/v2/7b391/0H/j/9d7dPYYM cNLTiKQ7SNAXX97/91djs92+jI/2eU4R/U0FOUOUOU//fX/x/cN2Kaq9isGYIzk2FqPYwlDCUN43 //WRjvsuiPR+IiP62e+nX2q1/hoWpzqf7Ux7obFDHGxTb/G9saUdnuI2gu99R2sUt+v4II3xERER EfYWGEGhDz/FoaYpEh8e1iLEewwk6sRRKQja4QXLI6Fn6M6IiNCGELCYIH5/i01NlimF6UYpLJuK xECCIiRmIiIz/ERGEIMIRDCm2gJDhBhSXzumdjo7FBCCI7MkImSfEREMLpom5Q4R17OxxCUxdhSN QU6jJBQzumQeUIjo4gprIqaIxGERjIhnZKwp2IMZ0c0OEIrqqeejqJMDbXnURCI01CdhNBkKRrII ZCkpVGS8VRFTQjSDufW6LzU731pF24Teno1si9a6LdozslDCDBA5nOnM5MG2CJOMQQYQZqyEaZFC I4pCeuDBN+ENLd84535/p9+bM8GvT+gRH7QTaQek0Th0KqdQi6cztGd563jNQT8V/1u6W7HVrlbz cRySEadb3renpup4wRP5/andpZcza0CI8kHSD/Vot6/mHC+/pD+16+0PVunf///tcl0wwvvO53u6 dU9XV29Owp8z92tCSAw57v675wf/3/Vf//+qbQND/9vapfV931x21G2ln1SHGqNBQ+3fvdRn/Zz1 vBD///7WHCX/19//4avpP40MGbc7S4tvrn9sLDS80DDaTaVetrax7aTc4Sl/sR679qX0P7+Grebo 7/FRsUxX2xxQZbhMRTaTaTQVjD59Rhf1iltXq+11bOUZoKHiIiIiGlYQaHnRYQacaY4prYQxbVcc ul1sJR8/2KbSjluZpoQ0M3Q0DK2lJhNBhMINCwhxxdhO1TFIV7TFLhnfRUI4hFoROrEREREZ3MPE RERDCkUdjQYTU3dlV4YTTO1Uipop2UiIohUrlHi0M6IiVJCODJWaDkSq6dhBkZBUyBxfIOhGWZ0M xlSzqEOxJEXQiQqIVCI5UOlngOrRrfNDCHl8/hc6fRkai9krFSOqNxUSkIrKTL5TxfOoRIhM7jiG G1PDF6dJ9J06173zBhOsKjAw08i4VOQTTrpEWMKdTCkHnXMQQM1o3EsZHiEyE7DI+vggX99No3r3 R3v95jReKnRJ70gRHnSdtbW5wTCQo6VpposdhNNXs6iYuvr6ciTI4Veh//7proauf1nqqdZurPh3 aO90d/maQIuS/UER5BB3TX1gicbXb/Wv7bVV/rrrdRj/NIuFdsnDC7/rvYVKFN3eknpup4zvukbs tzMYdilDJBtboZ/urn1Eb+q392r1/4603//x7u3/3/6+aZgLQ4S6RD6YaTa/dQwr+oQ4jbOfVnlO D/z9tnsocqP3+/09HEP/16/W6deFhriExUV7YVDBn/GlXG2sXxSjuFxF7X9fWcs64Uji/+/+vNn0 4tQQYTQ8VfsYM4wx6bFLZzddSLhbV0mr6vriM6GCoVH2sV30KXZ7iIwQgwhDCnmhoMLEZuTCmzFs Lrgn4xYjYjhm7QqmgraWFY17jiIiIiLTi0GlERanUk01HLwp8IGZQuNrYqtZNyImyriIjN0REQYL YQh2UoQiGELCaGmf8m3RCoIMpUdl8lKP5pndcU6JjURGf4iIiIjTyuEzsW3wix+Xz/qtlCITCDTB BnWU7/ITKhGsjvkdjSOIqaIXiJXBEIx96Dda99F5M6iIsdsghDTSOzXs6LTTIrk+Ey+QrCaanTIx qdhI3ky0/a0//YX9UEHufGhCXTzUIjW+1yL17ZGZfOoiIP4q7JVKRSIJ2VEX/kbjARWyW/vxBEf3 0Yc76bmsztXRoTv2qT+gRH7+nJwwrcseUrOnv5fPWRdpwa36tfQd6lbZHCksh1qt/p3r6+nRnKjV /W7vWqN2azO4U2V4V9f6bKHa/WpuerDYj/iP79b+6a/6X+KX/7k7MPoadxq/V/3ep3YhhoER95br YYH3qG4z/JQKR9/f3/rzfra+39//0Hd/v3Y/780i4SvBhl+vsL7UHDN35bjBmHM+2+162+/KUGAQ q77qc9/ChfYf3+vv96rerx98GcLWxQv/T42+raUNewsR17q2v+oQq1DGLZu69R12I3n71gib+vi0 1Tj7tfFRsULFYMwMwTFWEvYimmGEnQ7XbSusOK8aR0kE+/ERERhOIiGEGEGmFMe9C4YraoGdSFB9 jFimPDP/2liE96xERERGnYTCEQwsMIZ/tO1+1usJWIqTZaRCIp4hSMguEREREREGCFoaFoQ1ThqT b9NQgyowQM7OiCIwioRqEERERoeSkIdBEzUETOzXTBNM1ChTumQ47KYg8heTSKfK9SHqs+VRr7q6 c2z89nagKahCL/l0YsikQTJfJPITITKEmdjcdzztR9G+jdVuflTZCL0YfouOEqzSOnQW9iIal89G oQi7CZIYQea4KoIZNIuygFyDyKBghWdJZbrUYCY41qO4T7p+EGnPckPv+fs/auCI9W4SpNC8IV12 lpEoC57YPq7/r/62oxzvd+PbUfny3/O531PFGg19eez50CI8zwa/M5b/uD8/8+v3f+t/127+v33e ////NIuFnc7snR6xSuqcafahB5+vzuHH0GCBJwzFa2c9aBD+mzyRtz+hkPOIwhv1X2Mvhfb/qr9d wmCFbr6tmgYHb3vEGy1CF8iYLmYYbSjtIab1i//ERSbOYIU/xGv/2/zuVH/X3/1XFvpx1rcabGDM FiK3PXaz/O1AWOvwd/ivGhxd/Gbn+vrMi+sZ0wlF2chToQaZ+TVNIt6FbH6SYM+6Bq7P/tXCtr// 2sUr/2uuCUREREREQYTCM1Y0NM4M3LYofdimv/42tinWGlXaRKAs3OIKIjNyEaEXYQ0OLQ0OLQ7U KmKfYqvhSbmWIiIiIiIiGEIhoRDU4koUm35CsguEGdk2bzIhEFhERH5F6yLdoO7KXk+pMIvIM7Eh kZF8g0RhEEy6JYZrzvER0fzs1h/7o12vtT0dQiMO0wudYJphbISTys6F5CZUeRrIVncRSf3+m0n9 9aDo2V9NGtrmoIjQ1P+9nTs1CQZLiEpEIONTL4QZIDB2Jo1xfluthj/VyKRdGMjqr+3Rv9mPbnfd TvSdAiP2kk268JvcLDVddFjtI7ApNbLUIVa/8IREmKeN/Ffr90u6ut0Zzvp79X+bszho2UXl0CI/ aCDc0GiCFLjmRtdde6q1fr9L9X3X+td8iUXC1+kIhumoWtb04pPoER9/ghQIb1PpfnO0PPrv+/69 f9O34YRQ//93xxM2XCpf9NozlRr/1Vr9r/DTiO99K+r313f0Irn7eq5CJe/v/Xpb/tYMwKdQKcWK 9G7H6+rGFbS+n+1RY4Ijw7uEghwzcmCCs9uexRuv/v+/8XfaFrp3WY9imI2ljYj7VtKh/tajiFHH /pWtrbfvxERERGmf4i0whdhU7FMU/WxQM4PBa/GraTaT/apREQYIRBhAwhaaFocNbP+kbs2R2Kji uNiMtQNSb1YkwhERERoRaaFoRDCDCDQtBhDK6XndMrYYIVmuL5Pn4qmSzL5C8rg0FK5WxEREREZX VO/sL2EGSkKE7ImGCVMvlRkFghkJnXKzkIiWIkmp3p7+Zy313SLd6T65rEJSIgrU9krFNYoTL5FA xCInkJgmVaIWiEiDRB5Vo7V3fGEH0d78J5soEXXPBroER9sJBZhpeChV1rNQiDKfTs0Bc1OzodlP BM1MvkrZHvWVuMBOyJZgJ/fdPV2NPXyQ+bufX8uKJD0CI/c0FjrMPVGuCH0vTYQ11eD/aq6evv0P rrf873oWDBMnRHZHQIoe+ghRvVbigg35i0SHVNpc8GugRH7rVAiP2vDpl8LU/9dFuU9/tvv6rX12 +NCIjv8V+n2nM4wEne6vO53403W9PP+t533PAcEIofehof1YcV7Xe//3M5w8bu/9/6rt+u2RJkcK rr/4r6XiDZ2tO19r99MZKQrer16v+e0hRkVs8s+v+r15+v/v//X////Bn2fsU1bEYYKoioYVjS74 3Pr5/kUDEX62sRjv+6/jP9+9fs8n/6OmC/F2haaGZSTFRWx8MK9+qsRTaXr/aX/2r9Wtp+rf2guI iIiDCDCDQwp/oY0/MfNBT2mOdGn42Pj+wlEbFRxpRrEEMRERGxEaaaFphNCI4tMJ2h2Kaa2KYqEW oWqVwrO62RdEVRkMRkNZQmVNCIiIiIiGEIYQMIGFP6aYVDwmqZGRUZ0ZiNSLoKQvIWiWVpkszsjE SuS5CkIiIiItcvHpFu8vHo6CHRpnX/JAUiwYJUIdEfzWKEHGS8CDJkGDXF0U5EYRUs7hqdEVAQfW gm/1pNem00lTsKjDuSHkP01C2mpKlkJHTMQQZ2aypqdMydGsyVo7LOv06+jdqePdc9HPZ8aLz8sc oekDbnrefHM6XRraNYadnURNOZ4TCCo/zOUnns7VBEyorKkMiwQKdiX9+3rx/3V0nFXhPughD04Y b+k5B9M+Od9pOl+tIER5JuCI4/oe1RoZrEU9Wh3Ysjojl8WXX/1v91eNdD4MGPfpik671dPujOVG qenSYV+f/RY5T0mwl6NbmdeI7piKc+v7X+v2+/fr9ev39//9bqm+NukENU8kPfSdqbHUMiD3UPDC x4IVasNbqz2Tg7nv0gq/v39r5hL0m3+/5ta73j873vqxpzsuyPkfWGf8MJM3ONoLTaUGCTqRQMck PtIEEcwh3v/pPTa2CHb//Rj2rQ5hyhyk4r9dtuv9CI/lbBenVrBmUCgxUUrKHMDGCKHGEErTYSG1 b1tbSWn+KW17TXoRVz69/Q7r5hwRH4tSKPHm6LCdoME1MePMPCGhgzqBsUxFMUhGDNALtXWNYjn/ n+bnHa/pv60PFlERERERBhNC1RmpJzO/DCaaa8XYphVH/HWm2l2s3YYW/uIiIiM5GakRBghDCnRa FhCKLHOOUPnRH3qWOUOmPY/ImGGK+TZUY7QiIiIsIROYiM9lDxFhCDsIWELStDUrpcdz0GQmQmQe QmduRU0VCOxwglvplCEcWhERFnRIIhlckCHY4iM7OoimoU1CGhpkp0zUIQckQqITIiJZF86RVlFm tEIZ2TxEp47DQidUNJUg6uFWGjW90jUIjKXOkmFuQTR0mX0yWRfg0GqdGHM9GHO6q5xzD+SHo3Zh waX6NjVwvprsNGtyfsLaNDC2To68iFbKWGCDiLo/EKrIFHYmtNdbauk05pGAiM6dIaDB0/aTSMOd +f5u9Tvne81njTt6BEfdJ1deeA0a2p1CXkqEgyIECfVv/9fWlvzMu/xreOhNIuF9/6btbBg2q+m5 3+ouk89nyluEgbU7Jie/7/75+3u+Gv6f7///13pw2P6/8YIF4q8454/OOZ4MNGyu3/20rbcd3b7O WN0CHZ5e84Uz65+//+vv++v1XkQ6tXv1fDDL9CjOVH6232vr/rHtqlF239qO8Uv/vaQX/38d8xw/ 7f/uPpe8bUUxTxVfFLDiiU6+tnuP9bwk2u2oIvzhvW0vUGTKPw7/wUuP3BE39ttxYQtBoXHF2ftN c0FPaio/2tiOKFigkrEU2rF0SjW0sPpP6G/k0Fez3+WkUqIiIiIiDBU0LQtLP8cWEwmmo2opiohR GS6YYS7VgvWFxvqMRERZ+iIiIMIMLYQaaky2LFOxQM4XioWvHK6riIjOdCIwUyIYQtYtQtn+LVTt EXjsKiNZNI7IRhHYpiIi4iIi0Ihhc9BPz2ahDUVH8J2dj5Hy8aAuaovkJEHEFiDyEyny+ZFuJT4j +n7SJ9P10I6Ts6fkX8p0p08J2dq0bjt0p28XyKojpSV5fO7d9Ai/vro1u9AiP2lM5cUcdOrvudAl 6ToNNDC4QjCdkKgmdimdIjXt6W7pGc7+nfr5utQm199V/tAi/0gRHqW6SfRofns1oj64YL+3+3/e u7tjvX+Thh9GcqNPXdU8/Z3vPBswRf6Sb+whHQrapDf/0P8df/1+l//Jbf7f41aX9PvokOsw5n3e v/fvrv76rMeq/ev8P8df31yJhjyIiZBi6ne/G2Iqbv8az/+ju0C2t6gh7gh224IVdVD19/X3v+99 dvW9fHpexGTQLaTGk1S1606atxSnZrL6uv1Oj8GjIhDf4tMIcWhd9qExUYM4zgzBMUDOoEUVTdUK Y6um9V7Vv/+IiIiIYJlJEGFi04vhoWFUKNjiKe20gf5u/yuSoyfOxpCIiIiLhghGfZwmmq4xfr2O V1MIdwipBCFIlAQyTx2tYiIhggYQiDCHHGqapBSDlJzORC8iuUgQ6orSNSKgQlkIiIjRfuQcUMFS GFmHPrbJR2pfP+mfRK4JqFITCDIXEHkLzs1R/JWZ2PFPkUWFt/pCwn3/RgdMIanqZRTJUIdRMi2b adkPNwTILBPKRpkJmuL5C0RiMIjDNWRqOwLLUKl3nw8XP6N2brn9b+vfpX6VGyFXCF6w05oZKGnB Eey+f/NQRclGmE7CeRgYOmbipYIGdpWNbSu4yM6GuOn7v7OT6N+3z+iQ6q5uo3dESHpUgRHknpNJ tfhNpLe66Lh56STCep2p/d9+kHi3Wv/xV+LqxzvDe9DiRWI6I6I+s93bWqdK6njTmL/dG6jvf0CI +3Cf5nLi/zW76r+jGA75nKHX9MR8MK96/r+hER9YYlV/3///Xof+0vW7cYT1PD6b7x2vw2zctCN0 RQMOjAx2eSFThPv7r+7///uxq/a/v/Tv7deRMMJPT9tJpz6KhoZDC59NrQZvvMOYfYIEmjDv/tbP dnOZGxycOR/9/+9Y/d/0v9YMKun6/+Y+MYseFFsUSnfzjoXiPPVnvvbSjj/WOKW0oriMHtbOfqCG +t6G66XNZXbXW0LCWf7OXtb8V6/Hscaq+3zOVzdWwrhdn62EkO+q+m6RY5h97GuP0CFRGbkIizwU 814iKYiypxaxoMJn/N0dqoQiNRTC50d2KtiMGdQI7CtDtpaXtrVoaFokYzehEZuiIiIiIiIYQiIj TCm5NdMVvFNbWxQMzSUik5XWEJSEU8IoMRESExEREcGCDCEQ0Ii7VDCneuQrwgzrEH0VvJWZLowi MZ2SiEGi3VUIiIiOzvglkvpyDnn+ESQRBgnYQZ3SNUXwp0aZC8g8nykyqoiMk0bRUKGYzca4p8pM 7FkZFva/nxt65uVGj6LdnbiLcwPqa9cwj/IIKBqE1UlKN0RhB4QZUZUkmdI3lOyTR2BC7Rhzus09 Xms8X9TGjdSDaBEfuEHCSvVNuCHrwwg89LZDrQuSei3ef0zr2FNAwnYQZTuyEyF4UiM7Gov6rbIl GAn103bb/dDXW6845no7/P9P6+zQZ6L9+gRH3+YduekE2qo1vyUBNrmdrnSvRoKTmcML1/tf9d7X a/0vptX+9j8iUYCIzlR/p3hB3qv3qeIMN6d9J1dZ4NenSDoER+/6HTX/21N2P/VD+r+/19vq19Vp d/Sb/u19/8MMfv7+dzuhp0rrrffs+qnjO+7f41favvURue731vf96mB954Kf7cR/fxT+qr7ft9O/ 7at/3/5EowEY/13rbdXzntpWujc7Q3X6dL+16tRUXtvf+1X8EQg9/CXoVa6//b+vtdr/15aRStNR tfcbFDvOdcVEcMJdqxFZ/Yp/1Bm62rsGXQWaCn3rFRShAj3apvROD/eul0Y/wTI6I5VN1GB//G0L QtdBhNNYjP9oNMexvG1q8VXFCxFUNsRTIxwtQglbSm7a/7e2t++khFDXWu3pREREREREMIMEGEMJ hYYIXFodoME9UGEIYVIVHWxQMwU2KbCTFMasR19nuKX1lkVEIiIz9EREMIREGmhGwwhaaceKaQ6B mCuxtKxFSuZI7pkyZ2jTFo7E0IjOeIjQYQYQzDlOU8MJoaUYTVTu1kL0yB5B4QM1JI7UojSOz5DQ kZHeCiIiNCIOIjM5TxGV1SsEMlIRGd9pggwkRWJ+QQMr2QqNAXhkHhBkrGFNQyrztyKvOxGUtCNC P1Sp+ka/XsNclQlSDon9NNEY4VmsQiwiZTinf0g4UyDyERC0VGa2dnyU46ef6MOZ/Zi+m0aBC+W5 Y+7CU9mi+qNlGzMENbUINGthXyUBLBMi+mdAoQZC86HckDLc9ZnO1Bv8d/ejSMBDTMBN6rPfCabr nc490E3Ph4dvV1efSTo3UX7p0SfzfWjqJuki3ZKO34a6/+lb/1TVf4j2/ddx3X3992OroYQdbn9d BBTd1+bMIOvCeeAa4W4IodkfBbPe/r8/Xmcp/7Ru1319tem7tfX9/98StsuFEJPZpmDCzud/e63v 2Lzv53vQiKg1v4jHcaF3XTqY/1BCn9/9D9+aAWv//hBC6aGu31V1+rgi067/tRva+t3aUR+6v/2t pV2uqQ3TZ7v1s8nn+gjy6mc7//F/f///gz7oYfsVOfu1THfw0hZQ5nKLdq2k6vP9tKGlnttUNhmy bSix8IJNRod/BDW6IoRfCut//+j+OIji7CnPadjGh2Kiox+KY2DCsVsQm11VDIuFv/Uhh21iKugY O+vy1CFEREREREQwWLQaDCGg0GEhtT/DCikZyhyh4voKvjIv1YVpjJRqxreEhk3qxERERGZ4u4hh NCL1NTMNRa5oKECgZ1YUQmKYjldZSkURCKjNCIiJCIRERGmhDCoGFJhAmFCZfO6ZMpSD00zL0dpS JZnc8RTEREYIRrnbiINBGrujGe6MZ/JNHYPTIOIPO4wQJMg8IGVGEGdoyaRGs6hDtVhI30CI/aoV vreqmmnudRMIRmoVM69p5Fs/SNOfqRNEciMi+EGVGdM7KkVJHZgWlujDndT2v69//XUKjY10a3hB 3IUPo27YQYW0zp6n8i8XMhI6JMg81sKa2XwpB5aga19bfX717Ugg69GHPHn+jDnHVPvT9uyr2r1M P9Gvfrd6uQ60LXRcAjVWP//o4vtPtU4/p80ZcIo1hv31spWYyPqj46FXXPdIJtHi9N1b9Iz/t3VA iP8If//fqCKerEbEb/q3r///qhH3hFiBKTi6311f76r9/RvVbdn0770v9PiN2hBDu9qf7n1/6q+Y /272q///d/80DH/ivsfnY12I7bqI6DN0M3NLfH4af9qCFXSjP/boGTOTHZdI27r//qh/+vvX/p2m o8GcGrfBmCY/Q+9tKmwtew2M6rQi3ul9XUEKSj50QQonCBc+r1Ri9WDhhC1OfjQu7tP+xxgzBQj+ 3Q5Y53KfntjCTGlDSqbnSr8VDCv1QIVcREREaFhCLP6FoMJ0xw7yMMIRDxbXFMUDMX7q9yTlOEyK OFFxrZ7oNy3SkSEIiIiMyEIjBCKjhpqhcaHBoRBghViowZtgqlcy0zCI+p2rRxFWhFhTehERERem VNBhbjK6wiOgsRGSpl8JpqdMySZCZKM7Fo7RiInYliIiM3RLULqCEbJPX3NQin87UouZrENQuRqN aMRpBBkyMjwUhMl0doRkgIQpVj89oER/q1dbtVU9GoQEPL56CYQjOnnSQZ2OrIONTL5KmX1IjNRq U8XR2PG8pzKoiniFmIkOo3oGHpbdOjd+p3o2IImOUP8JL/NmW6+0086hF15gZnDewtp2gyEjoYUI NOGdjVxDDGv/G+ktJ4Qu3zjmHz/reranx/SM/tJAiP2gRH261hOu06LdmoSNFjsMofDz33//br/G hd1d8f9xV+6rp53O+t6/P9Tu+533VoIOElhBsXncP7n0t/7of/cMJe33qvV7/fr3/+x+6X7r9zud 83VfEN/iwRfHF+la2c049z257Qv+z6Yjfv1+tfdf/VL91/enX2m/IpYYZffqEtjVhhKObtLHGjD3 +1e18EKjwQp/fX+cG0u1/f19sf/jvzOUOUPQ2KYpX3VVz16xgz/tJtKml//r12NJ6fS1un9fMcYI m+PQi+GgwmftONTY5hyhyh/7H+xTFAzqKhluUOC74jYirPesMFv7Sb/zXq2l5KNBB1iMx4iIiItB qhEOIjCn+NBprFpoRdjaaja2KYjYpsL2pDCxrMehC5u2hERERERDBCLi0GE0o0GE01FOxwkP665X VUJMkT5WMRERZ+iIiGELCZQQw541sLHpqpAovhBkZF8hM7MGS0yCOhERoTPERcS0ipc9HakFovn4 Lphc1CBBkJIMIMqMhMp0YjpkkiozXF87plPmERiIEiF5PiIiP/uu0a32mi4moRGhzOzpWdRAh5/I vJmoRbO3FTsJl8pxVUima4vlPF0ayO0I65GkU7O3vo3rrR3uk6O95+RC1QbWg6Qb9ILqqqm4TXWw UlASi8esLhbTJSy7NYins1ihBmtGGgyYynGdgeY7b0P/+3+ohOtGHPFevdEnz/vanho3UYfzYkd+ gRH3k3r/ra6NbjXwVFuwnaMOyIYTTCa4pu7C/1r/fdfVq7877UX/6GntIV7r0CDU/99Z3877p5hw RfRsXyY5Q+g+gRH6D1aNlXp59MR/2v7/Xt//+73r//16/io9UaRcL7pbr1Wk78ELVXVX5v0Z9XO+ 80FPOwRIMEwwRH/V99bObX2/dPgpdAv+hX7f/7v7vFl0ECv1/1/7xvxV63X6q1df44QjZ/sdWlfU WLave/aSEV/DN2xXZzuqc+r0v8+tiIrn7/++Y/rj/16/9+t9ckP+KYpiNYrjhhJsLC740bnhUNi1 i3+9ScMQZdg47vpN9fx7ZyXPp1ulu1+v/i1BEhC4aaYU3Jp2mOKBmCY1fa+KSiNiKSjm563retr0 sVMOd5PwYTumOojj7SvSiIiIiIgwhYQYIMKhDTP8WhGf4am601N5Q7V8diKYiojdVoW0I7C0u0th WNYiIiIiIiLTgwTCoQ0ypxaaaaUamgp31JjmHsU6zHtKaBiKldZR2qsk2VNEYjtUifJ8oRCZFDII jsFxEREREREZkRoREYITiDCEREQ1YahMvphBkvHU0wgZV8dkcKdRNM0iWalcEMREREZyIMKF6Rbz q0/TyF/FBYIqGboyhFGEGFIPINFXlLyriNoIMiGZF8yLMcc77QInqbpNhOjW72T/J+5iyoQckPVU wpr1OjCeRTJ9EMBkaSETgMIMhM6RA0U5KQiNZmvITOakU+u/pPU8VunrDew6rMHUz3P+6NbBEngh 6Z1CdvIXQ3YQeZ2dO89ENhBoMlg000RjA7ISItKQnYU7EvXt1V/79mmbgRQ7JSiOgrDcGG7Z76MV JWDD/pwl9Iz16n9Mq32k2kHXf1RrhdGhwdZqETSKcWwkdq//x//qumEIoiYLgwxBsY9rqnDBjGtg icRR3PGu53PH9BClvT1bv9Tu6cERxpJtlYHTaoERxhbQV+/W6/66Mbs44Ij/6//v/X/1/xiEgixn /f76X7CJvHpxSXRhzvppQdKr+lMdvx77rio7OiCRtAkbUxY00vwlOf0Y4f9/X+EEcV/6/t106ugm yQy4TwRae9bq1O54sQvsRv2tBYYWGl93oEoQJaiLtVQI9+2vGY+3j/uc9BKDDJAyOVq6qqH6X3Wv 3/3Vf1vaUummKapiojr8JKEuz3JjnHsUEgS72Glzw1t1aXulwS2HG2l0CFKx7pRjN28xgw3X/zf9 mmHOelDCYsWhoMJRpqkOOOCEHa0OtCPDHxWuxvxkOBWTHOOCtYatTc6W1mdl/20th3Vtvf/+oIca ERmRER08RHxFXNGOLT9acS64iGKYoGcGvVjoGOriGppgkxXrEdt1EdREWUiznU/xm4p8x4uGCEQw QiznUE0wgwsWhaYThxpDiCaeK3jwZ2nhXMkIiIi0LQi4iIsEIiIiDCEOM3FPRaQIWp0RanR5XVUo iIi9CHaERERF6diIiP9Od/FdIi1Q/6hMtXBPt2sEy6C9I3cRQvQ6Hgztkkd7OcUPyuZZ3in/K6xK VuBBlerPwvBD01CDH89vRn0b1q+kGy1SPQv//u3Vt/ufTd16+GRyiNhxRaprmDC0MNMUmh5hzPO3 QMLkY/QtCIz/iP/jyuFRRnc8rpMevlqGj/8hGmPl0RzyZkuyDtJLYiMrYLlfQMI3aLHTrpWienRm PEECr3u6Bf++7QtU+CKsjaRmIiIpgw+Fx5G07Z2nMf////////////////////////////////// //////////////////////////////////////////IDoH3j///////lukUf//////////////// ////+QHQJR/+QHQJRyA6KKPyA6JKQHQJZhEfiIsOHsEEo8f/lcSUfkB0CUf//luZ+yr5XUgqDCl4 yFYvmR8yLVTYaut59LRqM7s4Iv6+nn/Tgw0u0eL7/25En/Xvv6pfX7e/tIETz//HDC2GFJoPbpd1 VDLMBgxYhQuIpjqfsw5h6dhMKw1HvQvNQqMRhBhBhD/i8RERf4iMtzPlcy8/kHmQlmQPLoyKXX+Q SVNnaVhP/w1s7VBEW79+z2Z6BEfdJBNlmCilcKBd80DCTvXow53099D9v/rb/zI6Mj////dZ7KH/ r//+WYDDH8XfbSe9L+1XtePGLEe2raTOjEREWE08UxXxBghdpviI/Jt6NZEujCEZXUgqaYJpnY1k LzIg6ejW1fJUiOMJ0ajdJ0Z/oUjW9P11+iQ+nLT8X2VuLhe/s7rDE7w32E//19f+6NB3e0hn+3/o yP+phU2G7Bgq9q3//9Jr9iE6mgPEV/fDWvbsIXTaa9jiN/iLOiRCERa4YVdOIzosVxERDCak2HMg qMIRldTj8EyEgVM7NWXyEyCUJ6NbOoRN+8lDTLf8xEqRuoER370jP0CI+/VqmmnhP1aMOd3XaTf0 jx0CI9oER7hhvvW/vrmgY/qnqn76qYX//X///+1el+/S30ZH///DY7Xtum9b1+K//7bxG8cRTEV7 hYpYpbh8dpoet1dYjOiGEIYQiI0Gqi4iIjGW5mjPINFkQWGtlDMEduyPEHkpRuKlhBlWqr9hDOoi aZKhCuBaLtp7XpHuiY9dNSuDEQQbId4lP6+CB0Yc76nijdCVPuWYBRfk2fEzZHCr+Nb/0M7neu+t 7rpb//87FC9vv1eW5mMvjP+6qz3/+2fR2DBP3r0d/QIEP21wRQ4YL9xXahEsD/9TCC/6f4oKEI7b pwqGgQN/tqCEV/accNLJuUOce8dewg12sMJMmOv4uIiwQiHFoRn+IuxsUDjesREREWEGFvdSbWhE WIqVzLKUaJBnXGzrrRykmzKKVyUTfP52Ez0dvF8EDKXKQmEGMLCB/8LrRhH86RcwprRHShE4dG7R xd++3Nb071BAiPhCOEGyzH+OEGr/o79J/qp3YJapP/p7//q+v3OxuCJjoZ/VXIO0lv2uP//+/1QJ vHdu2cv1BD/umIr/v9Z8PHHEc/0v33it4aVnldJfX9lDmgocJjCVhQzd1FGcWX4t12/N2c/xcRim Kq2lwx8NL7iLiI4YTCFoaaB0WOVFitaiIiIiHaFwwmGk8sqNxEYoZXMsrpESkIZCYzslhIVhqV1Q OdjUdqeRzSIXnbkVGEGd5mERmYQIGS6NpR0dqwiHMsUzr2i8YVMKqYTVc3VWtGtr0HXW0b2tmoXV zud0jdz/0+6VoER90CI+9NoER9wiTyzEcX9uhYyJRgIrf09fX714ImPEsyxP/ra+///6/6CdKv7Z 7nK1P/17////9GHO+V1QP/DBFPx91BDdf/3/4PrbwrY0I8//aVQ0r1vWP1ncZhf5ti2YfG+xQMxc MJMRTEUrEUoY/4jR/x2nDFNNM57Tg/8rhaEZ+iDCoMEGEGEIsIQ/fs7FehERNoRF3Y62KZknzViL Vy8R6GdgSPxB52Nx2NwU7G4lAQEDHEQ4d+dqNzsmIp2MBdQg8sdzwDKhb/qdSL9TiDzlmPYRPCG0 /+0bIS54NfWwgy0lJVd0/M2XCekIRN4nfw03nqnmdj87CIK/67ToLXeP0nv2EFQIbU/1C9/9fWb4 rEIaHwh2e43+cZ/5XWBwTJ2F8KOeGR4bXj/1CDQjgz7G+DGw0s/92seh2fog7FRznxHEREXaUX5Z YNxZ/jOhQgzIWIRERlkH0XAZC87nmuL4QZ2jNZkujCIhSbrYiCDkrFOzVa6LxqEwqhS/Jt6CVNhU 9bpt5oYWwvCZFc8p3O9J0Yc7+0d7pPpNwRH3QIj7fBCRUrt/W+/9WtOl9eWYDR1////X/5W4uF/v /XvNp/tfvX///f/1jX+3X4IV62R0R7an/r1/xxfbVhhbbqr6iIx+6bVfWovHFPGDMEEf7YWIpiKG LCBhC1TCnQh2KaaiIiIiLCDCYUs40hEZbrURTOxtEJnY2jswk+Xz+dRDoy7OxxDQMEUyjIucM7dl 8IZ2t5B5Kj1qumqX1rwjslFNQp0jEg/6N2p3ou80Gj9OvPswYMxELpo0P70NJcJxoN/XO+8+mDBU XFFx0CI9T7/+8UuPbXeLYhIIYQ1Tq9iP+v/WvwYJ/+r9nuPs9/Ojdesw59kvX94M3TQMUoIba+2r fVDZ7s9uvaXdWlCw0vir1z6jNAxFK62uY8alzsV7TEVDCerSw0oiIiwg0GhElqajRuzHjTHEREUY cse0004hhSbOiuOiOmhaEREYQMq0dcEIMiGI0GdNOQRLPxtSY5hZhBlRnfZGRfKeL52toqEQnRcd 79dG9ot+TRoNcLnakk0zULhN+zQZ3vOOnSeE36hb+9wvf0nf0n+1fandzvdHe3vojH1/pv/Tunps zi4VL///WdNDP///r9f1f9f80i4XupoGPsEPa9bp5/9f7//3tKrSpJvWN8fY0vX1BDan+59WM6bG IMwQRXDC/S3pX0kK8drad5z2KHfYjYjBmcqE6rBghFwwQiGE4iwmE4iLzRiIiIi40ZqIjJsNZCZb 0XNQh2DR+O55CYIMg8q4mmd1fC3k0/CZ1kynEz6OsYvzd3/mt6DC6eEyUdybJ0cwtD/ek3U75s71 O7V6YQ/9zQMf7pDf7/5GP/1WnX3f/+M/2GcwQwUuNnRbV0vjX3/oaUa/UfZ7V0siYY/gy3K2OC+G FwkTgujdjSqPP9oQZxiylBhr32lZQ5nKHBRERxHGp0KnHHEYzoiIiItFNK1JsDxERluZ8MgeUpmD NSKzErqn+RSftM+iJguEGdnyDyEztyJNHTITJPMLrO4Pqd3S0ix2dmoWzotBp59ap3cQ/W/zwa6C Dfp3NH7U9JvvBInziI6VfvGm6ebL7pN/vo4/KZJVdKCsIR/t+/05pmAv05Oji77dXxoX8jH48f+L adP+mEKb367qDJ6H+6r9qY1dG6q/8aH9ZukP/upnKfavS49ghWoz81r8plYXeK9hgtC9pR5Wwv1e vP9G5t1ja5IxYr2KQqmsGbdAwk//xHEZ9iQQiGpnKtzjadihqtrYURGhBpxEMIRERDUsg+IiIybD xfIXqajOxp18FQZK2XzWyPBM7nlRnaQirjUZL5fOvC3gqNFdXRoZ2atM6+gzWKgwup9FMrCzvfBE cabQIj9o79JvTW5ohNGivqNfIoiOiOiPKETeKT1uv1tTu90E3NlJtAiPt//CERGgv/673SV/3oae vfv/f/+v/XX//9/1nIx//vV5j9bX/1+PfXzOy+2vpN1ukrHQIVa2eXvqtiK+gY4YSY1iOOqWtInB eGv1P+47h2KimEhbqDNswPbCTEfxEQ4YQMINTQU5x4i1cx7FNfcRGhENDMe0IYTCEZNoRC0d2YiI iIjBBmrBAwgyMMmxZ0Hn9NFwGmSpH86o/kJnajKsjs8QeT6kbVGv6NjQQdGh3a5qEU+kGduIdF5d Gahrpu/enSdf100a4VO1u4MpwlXfrW6vftGHO6fpubP18zh/7/p93/rbvV6He/ENow5330P//+v3 /338N1vtLtbNpbSMQKR0RyBSOL9oU/qsRhL+2s/20ojf0IpD+l1s9ghTkOCX3LdaDHmgY4imTHMO mccznTtvm52kUoF8M34grb+Pcx6g4iNC1HWx4MwPwvrMhjMiIzH1iwhaYUx7jwhjjiNOIiIiNDhq TY1EOwoURERhTXl8qNMpzzBOdQqNzTKlEHnaSLxri+Qmdmud1VJbSSdGhkrEOoibhc6eiDrO5/QI Fdn7TaThJV17tusjH0vtr1c7nejDnejPud9/Lct3PBr4/x/3X63r/feEHcabz2VX///b/919/9X4 +u62kY3/79J/Ve/+fV9HULaT9//3/pAhXW64tiNJgwSQiu1tumNY1q17qoYTPvhW7FNRsUxQM25s KNhc3RE7Op0RaFhMJqmIQYrQkIh3EREQaYUSrEKdHeGIiMmw8X1RI0DKvIXkrZ2ToXRgjCJ2zUEI mC5B4QZ3TzsrzUREZfKhFPmFW6nxwm1rRonY4SDVMLpqnne+fSvTzWp4NfSb4ei4a2dRAm/+Rjut bpsafpyDkbs8BvCbQIj7rOOuvsf177ZmyOF7WhEGzsujaI6I6XevncqKTf/RnKHC/cdevq/CaERr /r+t31oRvsui6Xfef/tNkGgr7/9Xe9b621iIyGF1H21qzmmEEM/9f7367EchdRXUMJfDSEigYiCV bSvSf29bC2p0ZgsUOxrCfYasR9rEVGbIiLQYQhgmdGh2KaFimpNv6aEREWhDBBgmEGFJsaiCJ1GI iIwpBoIM7BMgbKdGULNBRNovGdhIw1KEEGmQOO55OGDUy+dxF8hMhESnpDoIPa5fTRbuj+dPJp6X rnVZ0Sanlc//dIEX6+E9+/zOW8Lrad31eSHmmYCU9V++//3ChB532jv9978Uq//f9t/Zr/Htd/f/ fzOC53O//2I14YXo6BPV6/9/76Qji8evvRjQwUjigg9L7/9V1j59fxSgzOd9rzOcehSLoGCHq+l6 ghQIa2L+Yctyh7q48a0LsjHBEdIIPTaUa31pTdqPQi41vH4MIREQZ1ApimIwZi5gpeaDjxEREUaC rKHiPtNMLd/i00IuIiIMJoRGIiIjJsB5UZM8qZkminZVOTYH35/CZqChMiwYO55DjuqIUiWZf/6z Q6RoaRFM6ZDgWQTZrTC33/SdE3pNzQaMMKEKYakoCK/yhkeBFD7em4QenGm4MEuazxRspQRH/4Qi Nv9pv0nBiEjOVGm7SGdzvSb/yMcw9D8f/BgqXXf9s1HrcmycHnI1r2pj8fb/f8kB96/o3O6NQR6W 1tvfWzy/BEdg+uTYH++2FCUaTaT62rxf8EDtqvHp2KkxwSFsfFMUPxsIPEVEREMJghm849hC7SN0 WhFqI0LQiIiGEGFERGTb0QvO3RhEZnc3JsOKSrBFDwnYUvBBlPF8qM7EkdrWQkQfBIIRrro0Qtmo Q7MYU7VxdnVWahDULkh6SBEftAiPuk3BArpHasJpp4ULRnTzud3W9X06V6MOcf1O73ReJF392u// X+t1htGcqP79DCHq////9V/S67/X33/13///3bpL9vv/99Wq2tv/3e3pAh59Nnvx7GxGxFMNJiK7 31jVInDBOGItDTTTG7sfFNYMydrEQYIGCDCDCFhC41zHzHlMkqiIiIiMIWg4ybBWIjJsri/Z3QyM Mi2TCroGEwgzqj/ZQkzyISNTL5Cog4iM7fJOLog0VeQirdzw0XG7ovLVnT1si/nUQ6NNT6WzpJnX zok6O92eAah6b3+/3QIj77pun2F8J325TKwv4htK6df+/6/0blU7t1nfdTu+/H+7/v7VN//90P9/ v70//zogl0bX/EGsML//VpbvS////VMEF62pODsaGCkdr/q+lofr/r++mIVrvWDMOCI+jOYehHeo IdnNjSTfrSwQoEOxGgURnAcGawWNuLskOCY0qj1m7esa9WE0qbi1+DQsYM4O1+xG6QMwgvAo0zoz H0IiOwuf40LsIeg4xoWmhEREREGELvERERJtVybYirzpmQ6KdkQYy3M4IPz+dqQoQaZV5ToxEFjU Mg87yL50isrr+mi3aNDNYgIZKRAp1aa8ggJ1O7/RONB0nCSrNj0wuwyKia3KBFvQJqrpudzvn+jd randzvuW5nrT8ENvcVf/bxoVtJf3hBttGcqPrmHKHJj0P///p+nX1+lymtFY0qEQ62eWupe/s8mz 6v/f//v62s34tum6/7TtXSY0vV99t2UMa6/2wsdd5oC6Ha0t9a9+MaFx0Zzj4pDdj9in2I4ai9rE RaENBhTexYU5Gf4aGmExCFioiNEhCIiIiGCDTRTVSk2GkIiI8m3Z07KfL53CMIhaJYZLEO9QthOz oj8anaZV6lTi+QmU8XztyJNEHEgzX/VddPXRnfn9bwumpqETyhatUeLoER9t3QIj9pB/1fXRrZqE VGipfuW61mzu4IjrT6/63pvvQIuvnfdOqLvV18qqTQwYY/r//+aRcK/SeaZgIvraM5UYQ7mK/i6X 1v///9r9p9b/S///GebMwX//NAx/qXqn+h7VNI3f3ox/f9MR7XvSvSr0m6xXW/GtvS/tt7PKI31z IsRsRgzKBHF17P9jS+9bCW+sXgz/i0ItNPSGP7G+xFRHxXNT8RBgsZpxEWEO0oujdhP8RI2qBxEZ j2E00IiMmwSMZ2JIjIiBBEy0hERGtnVH4mbTCDCRBolWUmXyUZGkaxO9/potyhhnDNeXefwvn86K 1O1ebiEjVkC8K96bny0OoQ9Vv10bYk1/7r06V5/qd2lugRH3vu/Tdf/r7yQ9Ledzvb69+tz3U7tX /+/8Vr+3f/fvGluZxcLnWMBPhMuX/MOCI66/4/4/9f/XaoVa2qQixpfhf1BCkbY26S5+Xz9sUyY4 TDCTaTn1r3zfvWfvseK3jvDQOLFRxtexvsRW4MzlDgnPer/8MFsJhWOPW19CKG0tf8REUZyh4iIg wQi+Ii1jVoQaEZ/iIybOjCKhFRiJ3eRmInZrlgboTtMp9Tvol41xdEZmEg9Tsjojqu4IZNAh0CBb CdhODKrEHwyDRuCBiNAiP3qv689tBksCHUSGE1C63Wffn+j/R33O+0nZ3DpTswbpzY6+ZxcKqio+ /v3QMNGHO7RhzvDDqd6WWYKev93dfS/cet63DItF3Tfv6n7Z79//1L5Okv/tdf++kK8MFhm+GbvS b0rrsJffuEXG6atSzC4Yxq/HFx3rfuuhC+rbU7UDDsavXDFC6LHOPXYimIpCNgtjf0F0thZnOOd9 hU0Idn5T/aaWEPUVC2tisReIiIiIiLOjQYQhqFi01+hERERF7k26OiE7ShuMrqYhMwXUjMnjv0Sj I1kJmoiMIlpkmgmZTyTxhB0p687NRM+rOoiDQYTKcVF2zs1irZHjUy/IOGHRfueC4v7pKnrNGaM0 MLCDee1f9h4QcYT2/okPfpG6k2k2k3NdX7XC3P+ccMszRV1bfjRnveaZtAin0NPT06Qerfnfc734 QhhqWkWL38f7bdJhCPXX+h3vS3X6BBBhkfxvXrOf+hv77/3rdfv4pR+DBXWeDj/f1Gbtnv/tIxOf V1Hev4QR5AibyzrQYsQoaSi+/83OuO0m0n+GRzbVX69QglOmgg6wwmKdf4/7VjjiKQ7CU3ONY0kN CFszlDlDlPLSVOIaFoRFoWhpn+00sw5x7FexTFbCvEReoiIiIiGCnQ2hBwwhaDCDU1NV4ybBZDtC IiI04i/JsOZDMJnavI0hElmdiWIiMrpeE1RcBnf6DJdpnXJPL511O0gu0XDgiOkEHJnbD9T2F1P5 2N4U7nhSHEK9U9CZ6Tfc44dP2tuuCk09GLkH8rU6J/9XrT+IYdX0gQK++CI33e3BhdSzHyPyuFBh Xsvkf/dw2YSu/SffhEx41ue5rM7gwW3BCD/xEf/G/f1tqdp2XCIJ946dwYgnwnmPdZh9qqhFv+P9 D1/9fBgr5qP3dUUbaQIUdMIIPaS/qGp/x2XQWcv8UOnvtr8NWkK7Wbt6zdH53mECEUr/r9qKsj4s UGYuC2KrYit/UMcJz3aujdfiIYUYYTtYYT7TWO4ODMEGxQu9rFoREREREREO0rQ7FRcZsiLUrkud 6ZXC0d2MlrERLNDtnc6yJ5RneIq8g8p8wgQaDCDGoQ/JmwgzUIahAnZ0Zdpo2M6o9BBnfIvErRiI L2l+lSVelntpBtXRfTtwgIZF++jetanhqjYp39IEX0nKhU/wm0l3rjGvzud6Q/fX2E1+90bqNy8s w1j1f6/29Lf/f/f6HHwn9z6nPb/9//9TC39V7/Rnb1i/ikv7OV6Wv0r6ghT7n06rTftL9f4p/Ypb XG/jtbOYIat5aRWrUscocER/dr2NNiKpYjYMJMmObShxcLbx0whHERcam5NDSsUGhZz9SL7t8RER ERFnRBguhn+z+uGxybKaoRERERFt5NgUQ7LxpHcITtPmSG0HldLkzudGQiQMjCUIMR6N7OzUTTOk XYQaZqjDBTpmGdmGXwibhlRmpkeIO6Tpsn3VNFxnt4UKmmvCDZrFVzUJqrRuQYb01O+m0nqd2CJR qd62kHBJdZXCgx+IYYmmYyPaXdOt+4QIj40tzv69GfaNmu+G04j1f919Avp137ncqNekOZH33+v3 Uwn9N/Wv9bb93/HDNwIEcxRuxpa9Lpcf1/0/+v74wgvt1vteNZnZfY9vStf76s5WqnPUKRxa2tio jaXDHQWNWGl6uqxxcRZ+UYtDtY00DtbFMVxsRSxEZoKHKiIgwkZERDiLTQtNM/9CLi07iIiIyuSm IiJpELYmSfpnZ4i+d652JeEDIt9GgM7HEWztWIQcw0ynZHsKQcQea4v0nVLCnUIgaN7V8vn8FOoT X7zjniQeEFU3Umdw6dHH/4Ik9db1avppHfRcdpVO53iG1tX18K8/dHe/qlb9Y3Few3vXb+EXcVE0 DH+8x237bzucdb7pV/3mF+//dL/aYYqL2e/yHAlf9MRGg/mHKHMOU//Fq+ot9nYwMfxCjb8OzjjL 9nOhEf8sz3Q+KdrXjguI2f+DeaAuveEoeTc45x4tCLUx4tQpj2vwx7WxGw8oOIiIacRDCFxB50Id hB4iIiLiIiDyuqo7K0ZCaK6wYjTTTINmI7W8p2EzWOZEeeztWEKDPR2FRdyLXzsEDAQaJjhhBmpm I1lHtU/Tg6bVFvQIG5ufhP8/0aH1O7Iw6eaDWoTaTpNwnmt26xpt/18atXq6ftJyzBTx+3pbhFp+ k3V7+r1fW9vtL//9f/8tIrWWOcfZHRetjfSBk9Gt1df790WYERfLoEUP8IW4jYbxrtpPv3UdpPhC IjH0ix7u1nQLFWFhhWGFVsFsLxFo/iGh5GXTFMUxTOOcc45T4ooDDOjERGaQgJhMKhEXDCW8tIrU REREWdF8ZXJc7EmTcWxE1/XO9NBnZiL5KMpEYR3REqSQIGI1O8tGdhdT6BNMlEXM1u1PoFO6IJlM rK/aQdfTV/X7CndoKi+Y/6sg6d9kGn539IER5AiPt+CJOyaBIT3p919wndL309feFaSW/6+v/1uv /vhF3Gdzw6cpklVUwr//x+r+vwwRQ///HhCrSafSfvrS31Qjtfu/1ajeoo3X+NL6mHOPgiOMwv3S 4MwQUxFdxFNKxHQh8Nrd8NbtBppqmh2vwY6YpioiIiIMIQwQiIONNFNGvEXEGCKZS1y0CIRN4jK6 Xnc8hM7GsnyB5hFWiny6JWEOwiO6DXZ2ahFO1Ail8+gnZrFC2QkkSpl81xfhoMq8g8hMKUySrpad Kn4VbOoRGC9rcg62bmaxAgVnUQKWYP+pxzvohKflvo77mygRH3SeCI+6u2k2p0CKCJD4YyuFBhdz SLhVUff3Sevnc77OSXoEX+fDxp0bujdCT2WkpKtd9feqX0P6/H/S2r/0KM5UaEIuIwY5ke35+7sR V63/7df79Xf9fpZZiH+3xVtqzm2/Tnv1/Rgr/1/3em3d4YMuvb66jGGbv8d9P7+t12vFNnO33PcZ hMXeuKa7fYilYj7XPbEUxG2k1ofqaBieHYImOouLQtI3a2pstOxUW01GMscw5Q73ilwxlmDpBBst IWUREREQYUIODBC0oYTCDCghEZ/i7OiIPELGIiIzdEREREXDwuTb0QtHcIRJni1XK6XqdUbkwgZT kaoqZnYG8yVEaiGmi0hdbOzUImmagiDQcgguypSDhlWiOiPHaSL5KawgxEelqqNee7DRrejO4YQj W07RdvSN+p3aN+m1bluZ9NukHnHBqm8LhBssx4tJTUrhQYoffFXp4Tt7pVeG0bs7+nV6P41tf/XV t1yJMuF8QboUu+6v8yLn1pb6v/v/v+v+9/0GR0mxrDNz+vrqGkblqXzTBK96618tIsXylBjSjtK6 dXuh7tLiE2brrvza28b+GtWKY4NISBg/sfCQ2LVsLEccXnRFqb7TTFKOhwWxTFaxERERBggYUx2M w5Y+p/tMKdCn/EaehOeIiIj5aRWpXWGIiI/wgzumRGSedgud1xCIySsRGi3nZr50kGsghc4mjqlO 55CZNKyYyTWE3fr2QxNO/z3DIxphat91PD2W5nazwa//XBumdQhZgqtPT/mcYCwndGHO8ab3++eH U76UtIrXXVftLbut1esrUYCGkYCPiDDS7R3O7LMSBB//7U3Nd/v/11v9X913QIUxSjv6+74IVz/5 /xnTCXX/O53Vta11fe21tcfH1wk3pfft2KBmUKmuGCQ99hJk3C/5/xCjX/8tIrVqhaFpjGKYoOL/ /BNexX4xERDBBhBhNDQ49DQ/fJsWIREREaEGFt5aRWtk8IjGMrqkdlPGdmpFRkJkKiER2t4YXPd6 Z1XkTBc1CHbxfNcXygMHcZfKjOmSeXyni+JaRavfJdRrad9KFtbUJ3qewtrj/BhvT/z2e6LHoER/ V5oLdK/6uuWYjt0djMwFDDFb3xSbhH1W6BF/ahNzv/tAiP6O9sswcKWkVrenQb3fM2XCbqP9dik6 XZpmCVuqb//obz2CI+l6+q//rX+6aH+t/o0FDoeKjYII5uoIUM3X3Pr/f/1qYfH9L7iG8//CC7S/ tZJ363XfdUNH9drfX/taGxQMwNbYSjY0mLSbV01+bt630PFxa3cdikWPjjioivrYimI7LSKlEZ+K iNCwoRmgwgwg0Ghx2mizIC8mw0sWhERERERDBBgqGTYeIwIIiMzSVCk5XJc7dyPSQiO/zURryDzu tELRCKhr8wGyZrTU+pBBBgZqgVkoaZ0NMhI7cjVknF0dcjUPqeNaei4et51CL702ahE5BNN59GsQ pklV628+n7p/ZEdukgRH7hXWqNewv2FLMPjX1iycMU9W/Pl+dzvrfenRupWzQZ3O/vmyWZYv39Jv V29W84C/X//dDTpO69v0IUtIsV8amHKHKHCRnKHqr6HXettpf/X9N9b36JxCCGt9CI4mmCFar/OR /vX/vzH9+sfBCPbXPp17qa9q+r+/VratnNte/vpbPLvFRfgzBB0HbSH+1jVhhJhhJDtJXSpv5/mg YLRi+GlFqmn2N/imKYpiuI4xYj+1s9lpFaid0U0FPFwwhFhCIhoMIMIMKf6tMKuY8YxicTQtCIiI iIzHhhMEI1XK4WlEREREUXktIrVQpEZJ52rMq0VGQm041Lx7BTpIM1wKEzUrNYp0CkojEQuNUXyn i+dqURrIPEfVhE36hCpoa4VLTJSEW1uQTTlMrC/gr1PD0nu+WOUP0CI+qursNSHWP6CJxH9Gc76u tG7Qh6puf6BEf0CLrluZ6Lv5Zh+/1pfW2r70LVr+NX0nwneEO5ZkCFpFaxHfa9/+uL0v//q3e+Eh vBEcZhMUl+6ghTZ9bdf19f+vO53lpFqgz/w66/3XDBTqEjShm7f3/7PYIftpfwY2t42GFZQ5hzjg kMJUsbGkxq6ux1+McQ44tMUNCPLHBNaxxUMJCrKHNBQ4X8Q4iGE887CERZ/hhBhMVP8aEfy0ixXE RERERDVO+3jLcyFEi8IiLxyul6ZUed0Mp0doZqRuFhSuqejczUEg0GFKzhBhORpzuWFHDMYPvjuc YeCtDjZ00Kek2sNGjnrmd7hDJULR/OjQYWwmnIcOWYD/dPPyngOm39IPSNDUEte03S4Py0lhd/UR BtXv6br0b1JD7eEjPRn6BEfdluZ8zlDrH6/fvkSZcJ/+M7p3+uu6+E70IbkEaZrq+5CJLzCjpV8f W27/9f9Jtv7lcKDGRwtnJMEE/aXP91tXPp/Q/9/b/Uec70hxUQrS0aCh4/ddWv/H9V13/vK6psmO VFOCiPFv7CsMKh/z/aVtVbVXVzQLeWkVrwQh5u0rWOxTFXx/SxFRFQ0hqsYiIjUx4iIYQYTP8Whx aaaYqZmDVYtNCIiIiDCDCDVCeItIsUtzIURInndcIiOMrrGX0GVCOudx2VlZrZkZ8KE20bmRhKf5 DlIZL5hlO0wSCDIXnamzHZGkShCWkCKuk51E1uGmoQwmiY7JR2d0SVw1QZHy8NGfdOr89GSs6giP KCJRhB1ylovkcX4exEPX7aM5Ub9sG6V0bkFqr3CEdPO4fBEeKZVF99e7uh2RaavEIu4pO/JD6sQY Zp8/Wx//7xuv7/f7QM7/dMjhffeldP6ZW9QRO/1n1D3VVDD/oL6+Uypr6tr/N3SIuPj4ac7jMfQI beN50wgmFN38bEVFcdcVC2gpoC+G0oawgxthYhDW/w0GhafhQtr8GNigZtosVC7sK8RERnU04jOQ hDbCcNNQhpihKZU1EREXERGhYXLczIrqWIiMrpeEGask4vnYiMMEDJe6LtqfQXWDOkfRqRHRHRHj pm5BoMhWU4yER2jKhHTKsyrymVhdBBvTX2cfqEIjtNG6mSmQaZ1kGdwKqn0gynkx9b8724Shv600 m0a3rNeMKdQmqNEIcrgucRH1V7pf/fn7U8adJ6ndpXO4Ivotyh9ek2iY6LMhG4tItWGEI33uv/v2 1//96frJdwhFGHO9+nQIHTTH/oVf494//fr///W3f+OgRHoz/y+R0CKer62qHbpfT5jf//7/j/qn LSLF+IiObv09axrH/Fd8e+e/19z6/H2vcRwws/zoFpbhhJcJNrSix/zQUPtYMFX40zntYaYr4T1O dIRtXFOq22tC7aSFv5aRWoiIiDBBhC85ahxhBoamy1H7FcUoxERGZEWCFoOLCEWmVNalpFalkUR2 rMRERERFhUMrkudi6KjoIMRqdgfZ08FITITCJuyDypRBo652nRCZCvrd2E81iwgbOsgyVCEPTz+Q 83qaxSXjQFyDr/udlxmPCpOqr/hCDJSECkPespklVd/WtEh1VtTu0bO/ohB6ojH/NBo0WZkXx7XW EXcTRlwk7w3ulukP3o1hPMOd84O2KQbwvdNb/1/1139vrbrf+szZcIrZaRWqghQIVD2pu//1/x// +v/O/H/O4zGNf3dMaVns0DCtqv3Z7BMjj9pG7/wZgZtpIY/tumGF1jaRuxDS/NAxHaj2vlpFa9Vg 0+1GxTSqDOEvFW3Swm1rf+IuIbGhaDCENM/ccGe01HLHKcocp4M6sQnr1GLiIjQ0IiLTCERd2heO pZK4REREREMcrpedmuVnCBkvEmiUisItIEUrqnqeyVCEyggwgzUaZCSDIyL5C8leXzuiOxJCP/C5 7m5p03o3QuoXu/fzZ7SDz46fSbX1smmp2o8syEWkqL76TT1Wr11Tzvt0CI++62o978b+6+zQH9fI lm2Fr+91P/WPh/X9L3W6aH/9brK4UGFc9of3mP50Pr9//rW3LSK1qbMfG6W39Rt6Qo3d8EyPhbp/ ldU6dOf9xrDBLvvX7VUIoEO1H/N35z0NivmcocqLEU+xFNUhlpFauIi0LiOGhahCIdoXaBn2NmZl IxEZ0RERBhCGC+bsslZiIiI7yuFZ3Wi+RiMIIMk0W5LjlpFa5hH8FsJ2UZRnZqyPIuGddSFZKc7q zpkbzuask2I1W03X1V0EG7UlQqns7HEkUc1UlGYlhhMqP9Tv0CI/frpN2oXtYhhU0GdO4aNDNYpT Kwv691uvO+67XekZzj5Mct2iY5Q+kYfuazSbClmI//W6/Gl+5rkZyo3pCMIO8ELVU/hh08k/GxH6 17Xv/9+9fj9+GRadGdf/pvWc9vStcwqt4/b/69fpbWDL7f/S3+6R0FW/Wzy17PL8EyOgoRcL/cs6 XFwpaRWrVsRURvxrDWXA31m5xd1xcVxFHQbdrbeuN6cNbTFMVT8dVthR3C1C20n1eeCnxEGUEBCI YQYVYtDz9ikaCnsLBnBhbFcUOLlpFaiIiIiNNBhOLQj07QuqjJsFDOz52oQiIiIiIvlpFak2NTNW EztxCGKQjUWhldKacghy8DUIMkHcM153VmMp8wjrkmZU8lCKkjmMrqoRGhtoJ0YYbvw8wj+nhVsj sj6ZLUFITTIHhB2UysrpNyxwRHqb0m4IHh6eutxEGjQwQzUJR/OnbWWZ0NGHO/eEGm98906mLngP q0d9oER95Mcsek2oSv3pwnrevb12P3TyXxBh/XvXwg4bp5/zDnf662gRHi0ixfv13f/VrTr//+v/ Gttvf9BNj97Ux/6oyf78GUYViNf/7//7CBf70+21bpX+0uN/bsILfX//7/QjVXVb8VFrDCiwYSc9 3EYeIIGbv1elddrIxzafmHghV15aRWrWhsUxSHNNKUihVsRsR2otpR3fR/asL0YxiDU3nHhhAwsQ 7OeNDsJpimK2mPwZ1Ypv40LQjN0RGhDQYQYTU/xaF9hWF4iIiIiIiIiMRlpC6ldU1HZ9HY3E+UZ3 2TTITKsjs8QpFQjuiO4cyOlO1Yir5/U9pncCEOMSaZCsjEmQeExEtIXW9f/7Rra6e+dQnBEeH845 3vXe/Tow5UdAiPP66CbLMfPVvXdDK0y4R+6WyXaQjVOTpV5/6TquOu31vfp//TLhTNlwpEouFxM4 uFq7y0itVtt0Y9qbqGh2u////+8NfPZT/+xr1eqs567U/Q0jd5+3z/tWCBCU6Hjva/8/5u2oxcUo q47juT6DLsfehx/xT0/9WxSTq6uvoR/a5aQKoiIaERxxpqbmND09cscoe+xRZjhxiIiGE00IjQ0w hM8Xalxk2C2IiIiIjvK6XggZ2aqnLSK1K4KC527I8dIu0SHYIMmIlkXyni+SjKmRGGa87MmRDFoe FdbQIN5Byra8ggu01I1HfwTTKuHNBrwRH9pAiPwg85zh01wvDRraNDc9EOyaeix2jDh0WZ5xSdLv q/9qd2gRH3nfbNBn06Tf7q6CdIPlnMz9XS6W/ecWl9eu9O6t09u+/t0/g2WkVr+/rrxHq/9ek236 7//T9mgYgsd/1dfX0v//r78a/+v5h/q62NJjnPY6329K/dfUJkfCqtqXnoxyY53KH+9hgkxFUq/q 2q3q6vaVqi3KehFAhT138EIvupaRWrG4a5jv2liKYioYSFtWwlQ8kOmoYWrC65NjNdY2EGCERGSA ggwmmKYpimnOmIM4MRxG+P1EaEQYQaYTCEftR4jiIiIjOQmdEbluZGYyXRkUwiIznlpFa1Z0kDO1 mCDKjNbI8djcQedWYiWZfIXkJiPr1O1IRFuzp6udkxDp34WyLynQKQeOnqd6oJu7QIj+FXptfWv6 9ow53kHU9ddkvTZ3p0CI+9qjDlPymVhe6V/df3S9OhfXr4gi6xD47rrru//3f//yVwu2aBj7Gl27 V4Ip2R8EvS9Vf/x+2utvtOsRG37VnsEKtfyLikf0ZGxTSvqJI4qFGolbBftK9ZbjOgX7CF+KCFgz qxWDMoGxFU9PlMrCiIhqSc78MKZFwwmqdFjnSRjORERERDCd2EIxyFYiIybdmvMIyFRCUiFMraLc VUtzQQJpnahHolGYYU1Ijou1NcXiVDOrMRLIvkLyKM2QjVXTdNZggikZQ9P1yVCHSMW5Cujdnfdd QRHqWldGvTYW1tNBA5KRND790r5/Ru2e0Z/T1wRH3Rd6QIj3qUysLpeRF/Wx0LHXatq9fCGqejB6 MOd47/h9frf/76//3XW/PbelBgh/zhJ9IwP1/v//h//Heofj+GF7rdbX+z3rvX7fYiiYTKHMFILn 9Dc9sWtpNpXpRxSoR22pTJKs/2hGmuO0NimKimI9138eI4jzzWwmg0wkbo1NTUVEZ/iM3REQaaaF pxak2UI2xFoRERESmVlSbeghR2JI6IiSE7WoZNnQVIhhTuBUyOy6NaI+FOuYRHifKEQmdz7Ozma8 hSKTMIplaUtzMJMMaxEGhGhHrk6OuRT4ZqMwYQemYRHRHSpjXRqMIuLa0t8GFu2CI56c0c9MREmh vnc72zdT0Hnw8Ubs/XrgwXxbqeGk3/OP/vGvQq3dDtxmjLhAYgqcGGYUJXp7ebDw1fLSrX/f6/H9 QYL4+v36+uxLMFl+0ZO1bPd72eXOe1N0dQix//xS3+47brYMEo31YaarjWCFEoQSD3/pvX6XjbNt ilhhIUM6Bf7qITsUFtUWOVH9uu1oUGFM5Q9j4T/QMwKF6TDCVDw1GIymVlRDBY0IcMKf86yqhYML YprYpoYz/ERERERxEMIRDCDCiIiIybcjtaRUIp46ZAaBKW5lpnf5KTTNQoQOQwFH2NFVn2Kk1M4M 6aRuRKOn06rkX1O1EE1PpMlgpoGP/oEX9Z8c3rfT00aGFX3+vo3VekF3U7t9J0Rj2eDRKZWF+M8G K7oavCW/vfVo3oaDj6f1q+hCC1X39zVYpct1oMDMfvufXhBHvp/QryQF+9P38NbVBYIelr4QbZ5X wZt32IpDbSCHUYSm52kEToHDBPq777Hgz7E1+2FYQeNtdCIYKedhTU47TsUIojexURERaEREWFPN NSbFxTsUxEREplaVM7SCDLcyi5o3MKQeQmQcd9ksIqMqERmXRLDIg92k3MB81CE0aaZ1WmFsJhMh Ig7U76evC6aNbTvXmhzQzp/pK+yCTZ7+f8Kd6T/o77SbSbV/9enGZsuENIwEUdK/dydG0R0EUP96 enf//Trrav71+E0Iil//8zZcJ176mrU3an/fpXmNV////8Vtq1Q1j9nOPdcEKFG5v/2oJkfCtT87 hYobPf/G0tpL/6VrpIRQrxpqN99aWIwZgnYjbSKAdr4muxcaZ/iwloaaYpQZxrGf4iIjMe4hhMKX B4e1ERERFhCIjJt2QrMiM7U0J2Ry3NBCfJ46hCjMGSxkeJeIOCBlSyDoMjoj5SZrIiMxkLRUIhO6 rSQQtLIc509MlQh0+IgynETT0zXhM1SkHw6Nl9F5RhycUCI89e6NjXeGqNbXIvYQwhkOuHoP8J6a tX+/rJeRu/PSjZS0CI/fqvms+MeO70t7/unQ/tpDvW+84M8+4YZTKwv3/v6/7/Y/2vvri+GyPjhn Oc9z3iv0CZHSQIoeCKH/t9EUW70YX/vpaF410O+64jQiO1qzmThhOrPL7fUEyOOzys8rI6ChFwu/ ukxFUwm0hQ2nI+R0Ryi7X+kKKAxFghFHQbZTKms2a5s7uDOEOoHgzloiKWI2I2SHKHS8kOoWOhER ERDC8MKf/BTclaBoRmwp87lPBxhcRERERnFMx7BdCDWIdquTYGQiLQiIiIiMm3IIMk0dmqKhG87A 0O0XbUKCeVGQmS8CBlXnb5hGpH87V5JroIP0f3s1iqQ97NYidp2Ts2aZfL4TL5CZCfq++E4V/Rra he1tNiIa2Q7/vkvetokOvtJ0bs770qRowRHoIj798t1lkcL5oyOFV+ud4bNIuF3q6H3YgiPwqufL aX75TKwtf18Nbf//618Gh993/80DA2p/5hYz/dD0v+dzvwl9//6//WsfiP2ttfxxcEO9z2+kdBS6 1V//sLMj/8Z/xV3qtNqh/y4HFV/eoIV8ec8f2mmNpwZ1ArYj3cLDUWIqF8RERoGELQ1hhT/YVWGt imgZhrEREREQwmnFhBhMJp4iIiIjJus5xSbvINMhMg4iIqMhM1xfOzXIwzZncMpEdMqqwdNmoU6e dJM1Ca2p9eEGuVbL4Uv4OnC76rq+nBA2jRvP64W88A60Sf9Tw0bugRdb/VN+q+/Bg+53v/9CaRgJ V91mH7dW877QIv5TKwuH6///11+/tczZcI+u9ePG/7Vf2+Zzj+uK2qen4YWv1v6/ghUV2cxoX31/ 8x1P1Dv9qtsVbdPhUP21WbnEdrivMOYe+la/aeMGdQq/iK+417oe9WLSiVlC1i1P8cNNVOdRjW7E UxxERERER3RblQUPcRYTCKZW1LQIxFhCIOIiMmzokiK5dKIwUvHSLtTt4jxBY6ZVxfITCGSjI0js vkUVdU8EMlIin9Ozp2kp7WQ4wFZCZERCRTKwqBAr1O/1dVfecK51EhrnUIdJM6eOvpb0bqN3dGf/ +s9KBEfulXfp/TmYL0NDfXfbJjllHRnO/br0dzvand+Qd6//7X/qO+qxdd19Lf1796U5G7j+tUWO Cj1b//b1/9qrGt7DMTZu+sEOEK23nYjV9X9uvXsRVLWhoaN1i1SzNTd9dL6/jSJwwGrQuP+7FHXh ha3uo2Ne+lYQlMjahhCM/5/jsLjfFjhRWxhrBnTQgRERERxFhTgYQsIR84DBQm3Z0ysoZbmgin0Q mahSKZPkZEZF8p4vkvlXlPl8lmXzWR2ZI1utKahAq5Daa2FzowmRmoXCdpnZKgmmVPIiou94VE4/ 2ut1YIatpOjXCFIzhkqEOjTwhfnc74J/hIz0CBXne/O9JAiP8ER/q1Sdaut/vjH10v/SXO54dek3 q5Cmjfp0Yc7qkeN4/9/v9f+/+/7/x7rv/Z7X27PaMf9fv/1/1/XmFv/v/jmz2sMFrj919Y///rfv +jH//6fdKO9oKxpRpNL33q2q2ljIUNr/xS5++8csf7XGx0uxsRURURrGve6xDiIhhQj6EREMJhCI 0Gmlmcp1G7G1RTI0oiIiIhgipKY9oQ6Ix4tC0MtzMiV5kPk+ImEIiM4cRhBkQsk2dmBLURo2MFL0 GEzumFhkLyEyFhKQdeGjQ+ZOHIIRP6R3TMk+QcUyBrVwRHnncOm+p3B382/N3OnjV0nsQw0n8/4M OXBnf1V6vr1w/lajARjEGHCd29hm4gr3/370dEv6q+33xr52S5RFwr91/sEF/P+ZJ+0NL1h/+0rp YhWo/RGYIL651iCFQ+futgwrEVCYaX5/wgVpPP/HhjuTg9imoTH8cQmMfs5STn2Z/qDBBhUGCH4J oeMGhGs6cRERmvCBgh3H8IcZ/iIyulZ2oyExE9iJklKV1TuQ4c/kvEqRdEeJVF8oNEdZnOoOEOFl HLgkQXBJWUUFDZRBoM5WrI1kIq8P3QjXrWynS699msVMq2msXZrDCd3Zbmd/hVumd2rgh/U8amHh c9K+8Gkagn4TvfzdR3vSugRdaX13VPLHKH+vSNDNZzQWPX6Te3mcXC0P/9J87neT5tgih5E83kdL 3r2ghDvU77rww2oQNz///Hf/7X9+3aEahCPrfehu0t/w2XxS1GVwoMfajP+z6/xXar//x8Vtiv8d D9yzrfq10ayh/2F9W/X/Gf4z/uunPpb1tQi4/rK6psMJC4vrHHUNJjCX/+62saM53v0+Qxvawzcn 2K8X2Nio9j1+GEmGkuNxrDSruo2tBhCIz/DCaDCGhcdimKmcqLWxTFQWxrxERERDCEQYQaocRDCY VOGEz/GWU6ERERERERKZA1K4LHYrlIjucmRiOzLITO1rHl0Z8h9WXiGj8EGU8XyowkahlORVxFCV SMRhEtRhWdF74a96LHa2oVNM1BUgoKE0wnZ1zDCSZVxfKeL+vZnLdoECvugg2rudCMc+NGt1BE+d SI+CBEfV107NQmegthf/Qd6v+nQIuvC0r06NnwlhLXXaUIlHr1ss6l79Jv1v/pPJwcIu419uG/CL iIInEUZ9oz7Wd2CBEfH0d7zvfLSLFYj/+v/9P/3rjQXC63reldAt///H/e1gpHF/a5rKzD/8wh3Q ff6/9L8Nf1/gzdtLvWKtb+heMwm1tJdGPY4a/V631D0P9/LOKhjuwwosRTJ2E2kxpaz200Gk2Fyc LXPEvozjL9+/THzuMx/r6rfYpoNCxTG/hiicHQjQV+GPDGxHGtLhtZ/saUaUw53KcofEQwgwtphC 0INp7OWAxoO0aNpihXBj+KYqhEXiIiItTIzojiDi4YQYQiHFw0GvuIiI7iLQiPy3MsjSKhHSN53T KfIwYktRGI7oYmqE7niQvHldKs+rOiTuyFRoGAgwmCBoMuiOiOQQMEQlZwuU7NQpLAh1QyuqhNPT 99JGHaNzTYiNFw0THaqEGgyElWl+7wreaDPSDaTaNmQj0EDoEZ9H9GCFvRvZ03nBz1nc77f73xoN 09PVzZerq7+m0v/yzqXXbfM2Rwv+RKLhUnW/3r99/c9JPT95/fLOWC/46+v/3//v/2+Or73jbcJX 9Rn+CHrz8v6Mf/uK68db9a1aok/+jZ9K6Hu+/jtdX/VGBtL9KcIKnffY3fUGYIP2wk2F+0rSjY54 O/fjBD197+4u7VPGhHNZVtjYa647nuGFus/zc/4hghEaERDSwhENMQp0Wc/0LYqc8GcINr/iIs6I iGCERERoMIR8Wu+J9CUMZuiKN8djldUzshEZkbztJkQIEDIjOwIZTjKchElJjjVT+Ey/maNQh1Zf JSjcCDCSLHYQM1ZJxfCDCYQZ2KoIMk0ahB6reFVbTTTmGBH5PPpebGjc0XbKjIVlOgUInDUJEJ30 CI/26LugRH/QIj6NjpJ586YW0g2k2gg2ahLBDhBs1CTqHt63fQT1vVN0+f6tK/ne6T09OtaTrpX/ 78f//Y9923//vtGHPHRu02jfz/OOZ9D/jf//0v+///XryJMuEofoY1a6/rZ7//+cZX0P/+nr/X/q lbzdvSncqMd6xXft1a/q633/bU3W7SucG2/uxHi+xFYVsJZ9QwraU/b6hpNhbC941k4Ujzatm7f7 W16N1phVHFsVHuxGwwlBhJhhK3rtDtUPPr1iIiItBhCIYWGEGFWwmKDFMU1GNTOU5h7ELi9ioiM/ REREGEQaBghDQuIhwYU/8aldVM7IqETGIiIiIo3RhBncBCDQkIKQpZ1ZLzQwi7aR00yEydmDJTlW jcQmgyEwQZrwoIGCIQYTKCxsrQibwtMktBucH/TU/oao3Tr2mp/Cou2ibtNNNMp4vkJBOk/v1PDd VdJtXRrbqSgi+gg6BA6NDozR0nRvp3zO9XZy/re9H+tO/T+Eurq0m4Ja0rSd0E2WdS+8fmkXCqlv 4mkXC/63bhE3jvvTr/To8PVXLOVd/r169B+tf+7egv1/cuE7/80i4X1fnEs4wYz/v4q3n76q6l9D vX/4+v+1r38R6S7aSomOCI9ZzHuMEO61jMJ/7UxzuXEEyPhf+mp+fmP/ZyBmCeMJQh419hNhebsz u42N6XF4jjusfbX/OjG44a39rmHKgqIZggj+gxqsR/Ixwti0l7S9YitCLQjP8WoQi7q1Tg7Oeznq gYgwhnPY2uIyzjYPZ/QiIiIjMiIiHERGZysKHtuLsIWl4iIu0ItTuhERnIlnFeVyTJvxiIiIj7Ow 47UmXwgztZRhD9cIvGFT7oER+6bTfrW6To4/LNKIv8mjLhP+1ewtlpLX3/963X+M/v+v1ne49V9b Npfr/vsaURt1r/HiuI/4iDCnRafWTdUxEQwr64sRUrpaKWVlfs7WtqV1TXg4eNbnQVstDTh99Oew bBEdwf/cMMQw53D/FCDDDDMKgw7/UYh5XCgec7O1Mgi3r/OyzCCMjRBJzstwlBm3dqIIIQniC8lt VChcK1wULhRGmnriIyusZdDC2TeaO1U4WwQJNB53uTY0CI0f6JDpJuvzven/rt7d9f9d9P90WaV9 iP/WHYXGw0ocRaYphxDCDy3MhRGV0rCZ2CM2ybD8rkgiLx6DK952pBIWEH2d6rm6ttK287NBSmnN IadL/X/vmRKGGzkp/vrjrHrs5N1azOdyopP47VuqEXnZoK+rBglYXXh1m6xTEL7PYQ4iDBBoWo5h 3ER89SbmlP+qldU6ERep/KVk8CmRnF87JMevgmuFL9/wRHELa2Wyn9vl0YWi3jO94IFcs0oi+N1i IoIL/STwvQr//7QIj905z41/eq3zd7niY316/9P1hir0r1S++74diNiKv4iIiDYYTT6VxBhRHLcy GdqrEWpXJYvhMIGZGQzsy2FC6LxosdhBqNbQTaCPyLydqTCWd706ToINhUFX/r+eBRZoX//+taLN Kb//33td31sjojojoIF9dVm/ffURERx2RyX/7EVdxFxHXanQpzqYcoc45T+wSiIiMIRFqakEOItP IQdREGZpzK6VtSup+O77lsqS1lslqW+CHtVlcKB0b+qGDM2Qt6e8GXcUKzOCI9K6X0LUrqoQRrRv XEtlS/39nLxlsibLhK65uTU3YiNfuPK4Vk+PstkV/yNp/1II0x458fV857hBexBE2n316YOIlsi2 DB1DfI4WxI2nczTQP////IDpNR///////////8tsPj//////////8toJx/////8gOmF4/IDqRWUM HIDphR5AdMLx8gOmFH//////4AIAIGWyJssKZW5kc3RyZWFtIAplbmRvYmoKNSAwIG9iago0ODU5 MgplbmRvYmoKNCAwIG9iago8PCAvTGVuZ3RoIDYgMCBSID4+CnN0cmVhbQpxIDU5NSAwIDAgODQx IDAuMDAgMC4wMCBjbSAgMSBnIC9PYmozIERvIFEKZW5kc3RyZWFtCgplbmRvYmoKNiAwIG9iago0 MgplbmRvYmoKNyAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1OTUgODQxXQov Q3JvcEJveCBbMCAwIDU5NSA4NDFdCi9QYXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAvUmVzb3VyY2Vz IDw8Ci9Qcm9jU2V0IFsvUERGIC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9iamVjdCA8PAov T2JqOCA4IDAgUiAgID4+Cj4+Ci9Db250ZW50cyBbIDkgMCBSICBdCj4+CmVuZG9iago4IDAgb2Jq Cjw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvT2JqOCAvV2lkdGggMjQ4 MCAvSGVpZ2h0IDM1MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9C aXRzUGVyQ29tcG9uZW50IDEgL0xlbmd0aCAxMCAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUg L0RlY29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCv//IDqtWUX4 ////+QHS1eP/////52tqJhRztKXj//////////8gOpFH5UlH/////////yA4TUctCmpAkNY///// ////ym8UtBVj4//////////+QHUisoYlGQHTC8ZAdMKMgOpFGQHTCjIDphR/yA6YUcgOmFHyA6YV Y+QHTC8ZAdMKP5AdMKP/kB0wo8gOmFHIDphR/yA6YUf////8gOmFH/8gOmFH//+QHTCjyA6YUf/I DphePLSJEdl0ZBalkU8wZ2aZXNYvkUDCcM+pXFBoSJtUK9rrRjPcQZbKdQQNkb09bmgsfrbY0Txz +t0CI+7UIP1z4eJNwiwgfCCfrxV96S8EQIaRok2KX/1dp+3d/CCOJf/2I/59JaRWrqgkwQ/7p7X8 cNIEqq9JtQzc20hpqxUYMy/COKa4xGwrdoNDQYUriynQqK5CDBCMREREpksUtQQhk3KI7qI7S8r5 kpGQmdwMyKUbibi6lcE61MjMRM1SdoZNxKT+Xj0dzztUCBZrapo1tSbqAX/6pTZSep302jd/1lK+ dzvoaultXoWXh3yuNAvvXrt/9P+3WWkCKsRf///vthhpiNmcpyhyntRT+2e7q9LWzmx8RFwZu/5k shhtWNbSQw9/uc77VYqlY8Nfa/FjmRDQuwp/iWkpq4iO0wmnDCEMIRGIiIiIy0k4pZhCk3TxVkd8 R3ZlUzIbZgioSDKciTRXJcyMorpBJXFTkE0dhMlgnZ0SaLymvR/CcEQ8hcNFwzudNDWp33oJtGtn UJ9z2d2WkFKiMdyY5Y+E+k6LvW+9Ok/3S22NGPgg7atlK+m4Q/f7dWjDniVymMBCX2+nfVrvXv+v X671+qd99lpAiq9ffr+4///t80FPZHISG643791j+z34Id1aXeND3xXhhJ/uu0iKhi1psK2tuvg8 /37HDCi2FnPbCqwYSDLgFDCUbx+PhlURaQKrCYqK9ipqWKaFigwhocXERhljgg0GFuwmg4YTgwmE GEIxERERERERGWaV5TQWpNzCCnc87V5kWRAsyKmR4ZNy4hkQy+akbipSkUyfOnogkhKezrINXlcT j8q6YTJT4Kt3sP1VctYNQg9UCI/fBEe3BEb+quW5bv2p3aM+xosdujeq3qn7CJjxf3hB3b0t6/Cb 8V//0E8f/v6X78N/X/9LXr3hD/9e3tnk3/4Q2NGPBCuvjSvrbHF+lFKFRnZff7Xm66t67dY1dWSH BOGPtk9iYajW1sRVt5blD2KaoGhwfaDUUONNFraq7sIQ0GhHEOIuGEIiMRERFxGWaKQkqZTUKWRK RJMEDNeS4Qqed0RkW5TxfMgTK4Rl8ZbqkXzsSiDwUvksSkHJyTlDlIJDs1RdlOImZCYULmQr63C+ Q61whvNziINAgbVNTs1Ca/aBEfetv62uk3IQdwnqd2iQ9KbM77+vzvdd53ujfWnZ8h//RvU7nfTr vv//O07LhX/8TQF/Sbvul6FdsW6//6///v///vb//6//2kbqmEF/5j//6utz/+repkNBj++o+CEV 6kUUM3U8drUbGsf5kJh/SaYwlvS+o0kI9dtJ7pJe1hMRgzLgY7EUOdMMVvznsYznQ8w5Q5Q8WOZW FQYVpranIi0IsIRFoRDTCaDCEYiIiIiIiIlsmqlmiZDLKaoIMk0SjI2juiMhTIQzEZAkVxlK4Jnf 52KZTxfCkKyozXF8p4vkJIu2RmFVNOQQPmQqFZB2kZlcXEOx2gztRWFzscISjs1CBbCdnT4QbBDz 1uw6b8tIrVaT9bX1Xp1dX/+WOW+ubM1mdjRu1PHed7zdV0SHU73QIv39Wjff1hA7avT076H9/+h+ d7r9e9/Q3mbLhClAutv7trfVf9f3/b//6+4YX+vfHd7u/qr/ar+//Sr059IU0jc5j711XWi0itbP cVghXrZuBCv/W6wQphrBgsw4Ijw/Turw0jIVDtpOOLwtRpFKBf770mLV7SQ6H/4aQsVCjGrWdqNj wZlFjYimKBnknFftOOxhqZcaCyxynQtbCmPcaaaw1P8WhqgwhaBhWEIiIiIiIiIiIiIjEgKrKlmi Qp2NMmmZDWVCISMhciuN4yuCZ3cXzsSiXzumdicQmQmmVeQea2Xwg1MlYqmsRMrqxZXFQq52rCnR hM7NezsmEOn6NzzqEXmh5fPQXVGthetpRe6/pN6SBEftJ6+SHdoscp9OiQ6ouKBArzdnc8e5/99P zucfW6TfujDSQQirc7w3oHpd2/+lHczjATzSMBFp1/7+inZHC9f97/H/99dfte7/9jMJb/v/i/// /1zDlR9qbvu/vxG59NTdbPJ1+6/rFZSgxDNwIY0LxjW/+tqDxj3F2l3RaQKpXFwl6nagLhWo6//+ NK0mf6+rDXYxhBMRSCawZ9iUGcJ56X+KYpivljlPGphyrsUNZhwTTONLm/jiHHFw0GhphCHdoWmC BrQiIiIiIiIiIiIiIlpBaiMrjeZEkVwNFdKiuFGQ4rnyukPnYTOmEGZF8g8qMEDMjOJWC6DokIhJ U9negRT2mZEBDp3p57pFu8vKahM9Tw8gm49o2V/mt/M5bzqCQn/X9zfhzdetubu+k/woQcnrVvq0 Ycz3db809DfXQ+aZhEdEfWrbx7Wejp9/e76r0Df//pxEf+rtKH+JN17x35aQIt/H/7/x+L9qxv6U Rj1s9r8M5ghijfuldV3oGYdr83P1lLDE3YamWAul7azdtL4a56e1rmpifJatis6b8VWxXsU1WxT4 jWYcqd3amPxw0O01tC40I4TQiIgwQiIgwhERERiIldCGWgwwUoRFcyWUdmYhkFKW60inM7fJOL53 TJRhDQZHyOjaJCI6Uy0i6KiTIrpmQjTIPluF6YTz+tnY4kghBnJ6hREQwhGFs6hMvn86hEXjs6hD p2TYzjp/RcP11u7nGEUdSx660qrCD0qv/eE96BAro3WZy3dTvz6m8JpnzO+5s/zd7tG9fl0bl+rb 9LdOkHeku03CQq52Chj/fd0hVzK2XCYvnYIBB2VhniIy0ixf+/6xq7+4xCCq0DXcbvXr11/ayH/9 D/vf+qCC//diKf2puuoKjaObRiNwQ3X/c9/684MI/XzaX1VuzlGPcMuiPBCn+qpXU/bdY7S2KXC0 6X30dQgZux/oR10+9kgg92IpWwo6wzchxQixGk+s1lXHwZmyoBqh2poKHxQ1HbTCmBp2frQu1PNO Wzi4MIQYIRDhhCrOhAwhERERERERiIiLP8RGIluVZXUoyCKTa47FsyjITOmVrMhmdIrETmXgpkRF 87phBlOjEdkrshedj5hlqwuUKQTfHKJ1CZ/ztTZdmoJIJM5zaUIwtk0sImOwoTXJRWmmOi8nfqv6 aTD3qWOv7hPwRHl9+ceWrC/s0Gd6LvNaf6nfNmaDP9G7CmygRH3p6bqnRn38LbHvpO+09Bu/pK0n ptuzcvY03X3q6/W/6vv6bySsjhaf3yJgv+478Ri6/9f///14iv/GxtD/9d/f/tfde9cL63+2FP/+ ZG+rOX86K674IU2sVv0CFR1Bmc77XHyUBTqERoKj7GpoC7r6nQLe2q1pYWI9pS1YVxthhIfpJx66 Xih3QTFRFAzKBQapoGbaFjrYoeZyhhhyhwqxxeY93qZWmmmhaaaEYiwhaGhERERaDBCIhhCIiIlr BFERERLcZ8tB4r2ibKiNYQ7U0SSGW61najKjOzJlOEKfJJnapWVJHdEd3l87nnZ0dWmqYQZ3bL5a sKW5aGJEHOHPoIPCl4lIRbOme00wtk07O3YT+ba0QcXLHa41iHSo0UYJ13W903XCFU3TaCDa+aDQ mWOCI9ek3oER95r1/6M63fS8/kHzWeHTzvu1TaCDT/Tue6+g9XvS132jOVHeNNJt10t4pN03t/cf d/75my4QpQL6f1W3/////+GF/+hb6X/+v09+Zzq9e/eu6+0PpGB2tbwQxRuzI7WCHb9rQtX9q/XW 15hzD21q9SUhW1rv29Un9tLPoW17SjW2raQ0L2tntiKSYoGbAvpYigZt0xsVFxQsbFFqwrFR+xUb wTWI4u04tMLDTCDQ2EDCEWFhgpzbghEZ3KiIjERn+IjiMRLKTEEyU87tSbUR2MRkIR2BGZCeUtFR nc87nhSF5EZ2LIEGnLdUZHkGR8jo7wUhMmkVPCkpR6CZ2l6lCJQkzoFOxxCaBZGOESoKdJBnZgRO QdqGhQxXYiSNJqEz2hhXRbvoxppvS6MFpVCSNlsa9okPXwr8IP/+jZReZrufSN1qd31c1nhlqGao z+bDu0bqMOd783eyXa3/vu3Ceg9pu2lujOVHem/13W9DW99Dv052Wsjhfr6fF+MfXrtdLcfv//t/ pf1xH4+PX16b/f/S/bPr7CG2fQIfatT/bImGNs92jLNjW33V/3/8MjoL2+mu09D4MznH0dQpSgwT QK59EpC6X99r2NbUUI23Wf2RMMSQ4IYYXvFwZrBJdQwmgmt42KYobFMV8V0oNCxQ77izDn2amHKg p81hIcwHFpqrCan+LQuzo4YQiNQhhCIPCHERBghiIiIiIiIiIsqaEtZOoidcjSGTZOi3GkbiYR2q ZB5G0SsyIMy1M7jTINpnTOytErztOpbhcEzueQkdjsjxCohM1xeCDkacw9T6yTFCDQZ2Oj0g1P8i p7yD7BluGp/O3E57NQnSuSjzp6b1YIeuegs0UW9XRo6sHVtsfhL4X19716mjffqk2gg36QbfIg6e azPnc8N1/z/+d999oz7r0b0/bz+iDqevuu3SXp7X7dGcqJasK+olbjAQnDC7709b/0N7qoprfe/b pAgT6717a0tjve16/X/XH4dQe+/1r0hb/V+uh+9Ds8qn+jI/qlYJfWrZ9IaHZ5V14IVeoMHa3WxS rbf7TH/b0ghgh398NZh62mGrVtd1mcqN2k6/U3X1zdj97jWqYjYYSJwXo/M/4xYaUNJk3KHBQ0sX IYUMcULS78etX6pigZwhlCYpf9WNjDQixTXBMJoccWo7P8cXa2mE0zkIREWf0GCDCcNCMtTCERiI iIiIkuhERERFhDE5k3FMZNxmV9NTIoiXZJ5CZ01O4MiDNeZBWWsIUt1rITkti5ws4Q1IKREdpUEG gygMGoSSkQTiEwnn0RiLs7Vxc7O+i5jtYZ2k+9QpDaZ2p7osdosdpLB8KaGi4fYIVH66eeAd3VTQ WPBEo63aCDoIPNBorPAaBFySbpv1nc7vqd38X/2oQcLTU7uum6tpJuf4vUKnp70Ycz/f95bluYCG kXCggW5FAc0jAQUmwicRS33/cafEEXKl/9vqrS/S+mv01rfvXr/6/f9G//Q9t9f0stV1/mc4901n wq+jd+H9aYX3+rPph/66/7dLsajYU3RoXDJ7LisXH7WMwmNIIVa2t9hQw7TW6vRut/Gl6Uf8mn13 22lPDT1ptJtJsLGdMLEbYVsJb8bXter1igZizVVFYMbWDOrHHFcQWxTFPu0PjxoWpLYGhcXDQg40 7CDCDCn/BMpENMIRFoRGIwWIi4iIiIwQiIjEStoRk2pqdjjMhTImi3AsyJEYRU8tYNS3WqDO5jKt Hc4KEGZasv5SHDJdnZKjEpQiEiEyEwnZKxDs1i5jLcLCw1KfCnZqFBUXldS+eqc1CAhVGNN9V118 7kezU1sIaQRN2gg2v/VhV9/0CI/aLzU7vNkQ6T82QVr53t1vTzdRu/r9bwq9+4ILtGHPHdFxGrX7 9ehofzQFzSLhTQF19RS+02gqevFtL3r/V/4sul/r99Ljvf96f/7Ef22xHMjU/50N/s9t61Bk9mtL bdWMwrLovK3q9q2c7OYesf/0o40pbqQQ6fa3qTQLPFYiONIGfrDCSGhYZ/6/7Ee11imN40sMchB7 FbsV17uOPSLgoePmBkt+ELUxK50JoaDU/5/iIiIgwmELQ2oIMIWg4iIiIiIiMREaO4zJJll6iERZ VGHk2VolOcyfOykISsztCluFxPFAzs+dpCOwMgmEKO55ERGReO3ZfO4RiO7gpCafpBBncO8adppo vmixz74sedGmnrhDBD+8vH9GUjRW7zX5oaNbQTdCEPtXXVen9dJtAiP+az3SukE3T7ufSwkZ6M/n faN2f/XtbZyp63LVdab6cpZkfBFP3O/S3WRHFzuePV16/QqJoC/fbxra+Nd/QiLXTr+H//63W+/1 Ek+un/4/Xwe/w0WOVu/f1vXq3n+ZG9jnC//+9GRdbtK1h0P1H9bfVnOGteoZY5x/a+ldXC93httW GkHc/23tKxaxqhx2rFOIfPTDSYjw0op9ijsPjYYKUisFeOlYpitWnaaeNiqsbQtNCGExCFDGhYTC an+z+hEGCGlDQMKwgYQhhMIGeVcREREREWf4jEREWVNCJ2t0tBKxEhEdc7Tom5ojscJLckRhFRnd EQmdmud15CZDCkRl87JI1DI6CcMmIhMoBzucd/kyRQioyuOiOgqUJ3pkP87os6LROGF8IRwZr3wp 2OE1s1ighGjNUDX+7z0ncO4QOt8sdTuRh/lul/Cq5aqFQIj9///WlaO96YTPkQ/e1PjRu/ok6n/n odbqUtHER1W9u770/9ik2CW5pmAgq+JW8wEjne3jHXzMF0Ijrf//X/4LVVpvTX/6//rGq6///9cw 5Q5Q/V6mcp83FP/s8kZqoKTv8yM6IIahDBCtX/vBkzjGhF77OY0L0L/dpuP0vW6Rupcd6W6nT69t IpQL3391HnrEb74M2/7KHM5ThBl2C2I+KigZge2KVrrdj47Q407Ti4i0M6LW1JJ0NNM6ELiItT/W GEI0NU4iGEIaghEMKnERFn7ERERERESuoQjLUqQIHLdSyNo7gzIqM7RHalEnl8pyINEtGgZXmiPB BnYEy/VQmVEEyZAvIJpwmdZBpwZXNQiNzW+etFwzUEmhpMNO5rqnNbmHBqkHQIj//p0km2eDXljk 3aM6dK6RnpOIPN2rre/pNzuVE7WnWNNwgd6+nrvsFod/7eaBj1X99/9P/rp0Wua//xr+23+ut//+ +tt//CUyLr/++9e1/eldAwaZzj9S1jRZY5x390/hq1tf21VtWKVtTs1TZkSgvxpDoX9sL2othJtK GFGIqGEtY0K5hynKix/HYp2KYpimKaYoXDCkcks6MIREMKLQtC0wmgwgYQYQhhTJgDEREREREm5o csiwi0EmdBkmjIXwg5N9Yiqs7IM1oqMkzOzPIVnTI0ioyvUy4gQZqOzTOwWQaJuHJsn6I2gThpp4 TOyUQ6Zh6n0dVZrFQ0Xjq0GdizTYaBBy1YUmyBMvHoEODRoees/zQ1TT9NcJ1QenYbpgw0mxpfqd w0m/9JtF3qd/12i8TKs+NK6ww6niGHT0Yc799G9Bh07vfToIaStX94Qik/9gw/wwy/+tv6cWGR4g QEfavr/5oGL/zJXfT+w1+P/8ZHd6Hfxxvv9LHrcP/ugYb+EXG1/bEefQROFPp9Jfs938x6ghTnuH 9lzV8MOKyUCu3W/Bmcp5OFTJoN/tZnKHBEeRnO+1jYpd5u8bdrEcMFDDwsLsL26xdDQV7tpYjuLt pLr9YZYOZF9itim2uFsVajaeWOUPYWIsVX7FTQU8cf2pui0yiIYQNC1CcMKLQjCEz62haF2mhaER F2nDCERERoYiIiIiIiIiIy13csiyjs6O0+ZDMleYRVo7AsvncZhHeZfQZCZQihHYpkojvEUKW61H a1qVSL6lWy+VGRiU7W46mpCadphcJ2Ft9UzsCQWj+ty3Uwh2pd5/C+f1zWIdQjhDwuahFv1chP3O 1YX/qvqt6raryY/9UCI/o77QIuv/q/y1XWf1vbzve3ne6MOd0jelggdUZ9ow541uu9Xk9mkbEhkc JO53vxjUX3/319LbxOwWLhfJwxW9ev1+t/YWNdu//2q/DC/v7rjf6+3//1WXRHQIofUjHzDkY/9D mcocz7qqG/ob/921P3Rkb6/f29d+IiMZ/0Lv/QjlqusM3AhX6/r/DI5irnQJ7/bf6/Tar//8/7xx 8/Yip/xpW3xvr8RvasRTEcRUx//sf09TtS939imopR5Y50lqoppprxxEaHEbP/HDCGg0LTP94QuG EIaYTCDCacQaGIiIiIiIiIiIiIjLbqHLKVIreVyWIREYjCOx87+O60URtEDzNHZYMgmXwg5bqsXy IjvIvnZiL6ZLAXITMhkQrNAwU8EwnakeLoj8MvkfJok4kk+GmE7ReMtWFC50aDC62yCDazI9kpEw Q12IiGxEHb2sNGxq8Jxrfq2vczlv91ngt+gRH7kIO5CD+5qNF5YdaMP1fO92p3zv0CBXmszsYQb3 0Yc7oYQdG9V8/Xn637TwhBg96e+/6S3/SfTvuThj621uhS39/fobww/16f/1//reuv/7t/rev+UL sGH+///6/2ve/msrqr/rn1ev/4IadOfTDv+rLoj6/WP9fV13XHBCv3onChX6et/SwUnDAMNsJWks RHvppWOm17SatL2rb4aoXEcNRhhRZQ5Y5VQpWzsYDsRWWq6sRusbEUxixtYM4Wo2Kk7KHtMUxQtD CmRB0w1OiNoWmFTCYQ+LTTCE4gwmgwnZwacZjwwhGIiIiIiIiIiIiJPiIy1jMinWZKOWRYzsPIhE SRkXR3NFSRXA0EHDh8t1vIPO6Zri/ZWcnOS1qa4vhSMiWoKQmRiCndM7nqi7cj0Bwct1MIQwp2OE XhkLgr3n86BVs7UwpDaDCFkOs6BTs1CHZqJoINyFOYcHB11VuGEOp4qurpPOPX9JenZV6DDnd5uz Zm6jv54BpUu7z9R4ez8620b16N6nc753OP1sVEGGIMPQ09D+Ibnc7tJ7v30r3SS8afH9acpUXC+E Wrb8W/913vptRvuh//3Xbq2/61X/+TRBX/HQ/f/3TLoLn0/37z/fBk6wjIPBLZ7WGc/Wwgv3XXrO yVKx1DNwQikGE/38fhrk8ECiCluCBghhSlAvfUQv4dI3zoFY1O1MLSx0UAv3+vthI6wWIUKtbEcF sbH8JioTSqDMn7HsUOxUTaAoWZGbcGPahDTCHnVqcaU801ORGhoQwoKFVoRERxKdCIiIiIiIjCxi InMWjsXGZGqlupalPmQJFUyERb8zeSMnxQZBMwguyB53PITO7y+oQM1GYyowgyoycMJkKzvo7Hzd eiNzj0XbCaZSgXLVhURE87Nezp2FslDI5gqfZ1CJnT1IYUlFZNGnDTq4jQQbV6Gwae6ur9hE3o2Y WqNjvZn/xdLTyIPp5x/NBry3WDn5e+gRdcJGeCXTdNzdp6uFP2bu87njU8OrZWRW1exQTcJKP/V3 1hE3j/0Pe4rf1/r/j/W/wgVf+v+gnW9/9axb/+v/6/+7f/vX9q9at9XV/a67a90ULOJ/0vgyejOZ SwwThjrj4zHraSnu8EN6UEKililbVDI52Fb1tZbqSzQMU03rSzO+9hqaAu2tWp0CVrrFRsNKI2GE sUmTTBn3QRTS0DGxTFcUDMoFJAzbOsMKg1LHKc49imExWCZ0L2hpw7QYUyIapqYLQsIWgwmhEHDC DTRauLNWhETvRCIODBCIiIiIiIiIiNoRcYnZmzIgQTIzRGsqEW5RkojtYRIR2t0myfCZ2qo3JlTy DlKsVSFZ2rjDOzWLvKGYLPaanaqJJtS0WO0Gmje86fn9ci9eF0/vv19oIN0nTfv6LH/8ER6p3fSN F69G7+nqeO/96CPr3qn9ylI3Ee6q7siOOh79/a5E4uF7fxJww/+vpoRrv6f/6+v/43///91WKg5n Kcw++v/+83QRQ8xpLn0jIkUDGu6WM/+qVvEXz3BCrWPjGtCI0Zyoxv1FLGl8azdD/HptWgv204un 2ybndOtL7hasH9YM2xQU1zHjQM+0rzPGg4iNDjhhY0Iiz/0whaF3xFozQtCIiIiMRERERGWi2Wgo GdgZS3W87UZEkEDKvMihFYRBxCZ2YzCO7y6Oz5LIvhBggypx3PMhnLcFi6I48KdzyVxfCJjtSE0y YjrkfCmgLmoQKoW8Ly7cu2SsQ7tLwhHIOROxxFtBH81BDp/hCOlW1vXQQdBB1BD8t02qq9WvfyY+ Zy4qgRH3QIj/zj7SurRuaXYU+OfDxm6jdQIv9PP/fqEDjCbRvVfW5Mlq77kKavQzud2ZcGIpOv0N DXa2o/nWLhK98SXv18IdfX/+6+6bv9f3/VRbXeH+////3+zU+v7b6p6uwluz937PKH/+jIt62vmE rnv+n32vZus579rZcwQ8VzUEtYtu9fS/6jGI0L77W2r01GhsatpR19hLSUHYimI32I7+2N3xUY+x TFYM8gcahBipnOPFpodqchM58/oaEbTU/5/tNT/3GcmmhDtMIQwQiIu4YUREREREREREREREZZVR E3Fs7nnaUpNwNHYFkEEOgp2GjIXMk87Uwh2ahDtyKvTMhciuN8t1vIPUEGqZV50lO0rIPTIxAih5 BxrapJlOKaAuT5Rp8rigU7wQ6eduJaLcEjc/PZqEzqIi3YQjwg59zPuhrab3o1vpr2qNbhCk39rr Tauacw7+nCJwp4NetJ+i5tG6ujdSfM1T/o3eccw+nn+ukD2e7OS3CEabs4siyLoj5HRtdleoMYT0 O9D2wy5+aRgI3VCdgoYVp1tRM2XC9Wxx09K8RhCIiHTrVva+njX1/Wlv//+vuvT9ms45Q/9pq3qg v54Keh3Mfbb+59NT9/R9zPubSbPK1nRm02tCL3Sc9ghVnNupxgxxfbOe7+9QYTFXu69tYtur920r 8MLHodr/zc0P/WGsesa2e8/2qthfeo37FKDNudipGOY5Y5VlD/r2vjYpRd+ONipuUU04iwhGGFN3 n+1GwhEOOLU/xcWg0z/oWtQwmnDCEQaiIiIjMPERERERERGf7P8RER0fxEak21QidgeZKSE7MESa O7i6KlnaVmRylulIEGdoyuNIIM7Ms6akJkJlcszbTKcRbJWIdqggQOVwrO7RHQVB5XUCBO1PR1CH UQ1CBNBouGFWwkoT4IRouOEprdPpBIJUi3wuWOcejv0XdF3mn6wm8hakh6T/z9knzjmHkJQoVq2g ha94QwhoN+dzv3K3GAhL4TRh09WdggYvxRn2ruvvT4r/ryuJAv7r2qfXfq3X7+3qvf1///t+phzD 4f7/Mehe/v+9K6ufV+2e2z22uZH31GhdhvbfdbpAinDN3/4e1q0ot9JDQ2K/draXhsf21+bmEI+/ vGMLaqxH7Ct7sUx+LxsU1dfx7GGlYqZyhyh7U2Z/gwvjtDi00LQtToQhoaFoMJoRaYTQd3GIhhAw QiIiIiIiIiIiMRLOOZ3hyyjotyI7AkEDCDOzPNeYRKYrSIXHblJsQR28SeXyE0yV5hEZmEU8XynJ BlRkvqiY7RbhnYnHQappyCAsiYLpmVI/SuUyeewnZ07ImGAnYTTTtMJnSs6SDz+aGgQNoIH0KCvD 9GthB/RcOtXX11dXRrc1v9VWD3pv5x+yY5Y/Z4NdLv9PejP954NdGfzvtGfaTpPvU7tt5hwaTq9T dV7gg7eNPTz239Nv12+NN12v1/dNv+79AyKl787GMuEabrf3IEyOFW+1b+vf7+v/W+r//r9rg29f qPqq3/T/t/fj9V9//90nox666Wh4P79Td96f2pu33Tt/1W+gQ9fpvS/17onB2NVxtbUazUEv+sa3 V1hsfup/vrTdN6+t62ltr6U37bStK7CTEcMKPwwlDSd+wwvxFAzBY4imIpiKiNigZlC37Ypih4Jp ih2KYp37FPhpw000GlacaH2g0LKSBBpw00I2gwhEaYRC0GCBhTIiIiIiIiIjERERERJsX5NwTMiV FSSmQxHY8bzIujs/JsfO6+yoIgqMI7PqRbCnanECRUshMKUtFCCkJp2QuO0jvlcK8/nZqEhoMJ2S mLs1iGgLgh57OkEGSjs6dgqdnY4Qh1tZKgi/9Vhz3XVNPZh/eu6uESf6+k6SBEfv+82Z3Bq2jvup 3ovEzwfNM1/qd3/gk9Kjet6udzvr/304g3TrvS3Qirik29e/vou2MdDXuvaW5W2RwsriQLnfzqO6 //v03T3//6X3fr7//0HG2dEr//W+t6Gq+vsNKZyhzvfMJbr+9an/mRYaqoIL31jSz3frsVkTDBOG ECI5GPEQ8MwwQim1/fof1tozlROzUJEK1+nycMOk2lNzwlVYb/Qqop74j/52RuOlCYqI6C8Ux1tZ KMhNwY68GZTWxtD/HeYGE0GhebinbVC0P4hxGf7sELQYQxcRGgwQYIREQYQMIREQ4iIiMRERF5aS vOyQYk0GdmcQiMiOVyuOw87UZJkRhkrzutFORBcujslyYiDwTKhEnoNBnZ8qM0BcEyUo3Kd1UIMm YYkE0YQan0QuOitMqIFuyXENQiZqYQZrERuYReOzqESNQiDTz0TT6a2i4aLjpkpETtGtmoIvSqjW 6TVJug+kzOW9OkCI9+9Gxs8Guy3M7hPTb6+k6U77VGyjYtup4o3aerqccz4UIOjeqp3+9Y08J3W6 e9GHO/ftGcqK+6QpDT/0Pq5W4wE2sduhXyCd/mWtV1tW7p1363fp+2633//167VU7X/0HD/g/0/v 76H7ev//++pf//95u7u/evBoUFLoEmHfMdr6tpel+Tg9q/3qtnKzldcfZyY4x7f7Vhl2xSt2EI72 l9Or32szlDu2/dL9+rjjbXpY///VD1Kk5/sIyCWGFVhhYaQwwrDCWId42UOYIPjiN1VCNpedzjlR luU5Q9r42IVhrHwZ2qBxGxTGxTFNPVDTCFw1TP1n7Y1P/EXYQiHFoWmp/QhoWurCDCBggwhEQ04M IMIGCEREZ0IRERERERERGzkRERERERGIloQiyho7g5NvjcdjRGrK1krZVMlOdkuQMwQZEZfKjNZF dYyEiDyVI3EsZHgmmZF+VxfOyGX00RdzNq8+iUhQgyViKe8wj8EGgwtmoQJlLRqRWUakdl7NQQ6i INNXJQHRnfU/rtPSND7SRbtPvT0XGe6us1u1Ve1Wk16SDf9AiP9Tx0g/y3wg6LxevVNq2gRdaN1J 1790b6MOYfU8UZ9zd37d12v3t30DrdO9PV09PV2kNdkcUFkI53/jVOv1v3WZcGL0u/5W2XCVvtN0 9C3f//rT9sRxG//f/4v676/f1vjHvtCoiv//6aYSq/u/+vamNmPobeuKhqf7qu6ue1fXXa4ZztRE EKhm674rb6JagV6/r9N432lO5TyUhLSjmcqGDNzbq0r1jfpD3XCxGSgLGr+b3EbYSqzQMYhwkRUH Wh642NiK4oGYHeKDW1CQ/vTUUNfwlmgp27vtNNT/adn+Liwmp90Ix4jpwwgwhRcFcxFlFphyrOOx FoREQwgwRUIRBghERERnIxERYQtDQiGhERERk2GYiIlmDaOzSqUqOxZHafKlkIjtLR0ZiKhHRmIp yKvK5JEJkHksi+mQqQOVymO/zDBaJCISQZhF0dwISoQ6BTtTS+nthPK4KENQhDsLcg4qQczLH9NM Ll5M6iMRJmdUk7pv+aHqEu1dtuEG++CI3/ronFF3mv9PwnSfmxSQ/538+HhzWZ2r+p3YSHqkYc8Z rM7gmkE1h9/runUrpEkM7w9P+rfTvTfS3Rdv+vp3UcWm6/NIuE67M2RwqDde/X69f/66XEMj6f2t 7uO//f/XD/9f/fvtfdcGkxFW27957s9qdgoYtRn/fdDP+HDNz+aBh9b963rsaUw4zGyhzDgiP/9c GsGFOoSm0l21dfB4/2r6bXte19LhjHG31hqMXGEgZlA3ViorxXYwZlIRsULFCxXfcHa9imKVFucf JjlbJUwh2mh5ujVBhU01cREHERaaZU0whaYIXERDCERERERi4iIiIiJNljLdZ5Ng0JXLkSzJsZIt 6CXBEXZBQqVxtmAyIdkLRlaIXnRmI6sxFQlMg4vlPF8guFIWipcOVwrO6QTO7EQORhZxUnDCDgyY kQ+1UFZKFe3tnTTKUGAuFyUNBzKVYeyaBUXzV9YQbmh28GF7//1W1vWguV1B/hOiMfCni6TaTkY9 kIPnfavTwn3Z4Pmd7zvdqd3n9EY/Bh6m72jf/6em2HzXb936vvsd//0t4MFndORTMBWyPSuLIvgi h9avivZEouF9cMi2W+ndf//9Jsmg19f14/tPCHK4kDAt/41/vrqt9f/XXWoIH+/9cw4L30Zyh4RO Ov3Pp+p/2uoIncNM/3rvyJhi+8EO8IjgN9fWNKhtvHEHK4gYfORWOGE7UfeujoK4r/vpU2ra09QR O76vp1z6f9YS+yaBdDbS1hgrDCwW/DCjEYZMIKipTmxRwg7EbEbXF8U1wv9TU8dbFRULrYpoNNBo aFoRaYQ6i4vTxpnGIWVNBhC0GEGmsRDCDCxEQwQiM1lDxERLSKlERERERERERcXSk2IZ2aZZwrI+ R4ROy6K4ohhBnfNTJGUjMgrO1DN53TO4y+dmshGQeQkdjaTOy+srhaCJDhhBlRhSKZC8oShBkJHa VmgYIOIPuzscQJ3IOQTHBGvs6hDtQwg6MZ6Jp9nqmgQeZ2dKwVS+f9PPSNHVI1iHQJWqu3BCurqq /fRaQKvTaQfwRG+tf9JveaD5S6dF5nfzWZ3n1ui81O7f/8dU9W7pD77v0+o9ow53o7nfVwnS+neG n9CkvtPu3yuVpNbV1wi738d62fZcKdlrLhUnS2/f8dbX2N/3e011sLK4kDD19aVt67YSev19/+/v eu9L30tiO9D17qEy6BYNKI5zwhftI3Q1N3//7ps59b1zjB2cmNJwQrzIdrdIRUw4svv8w+1Hx3tf +9tY29b/qPUM3an/9tJtawYwZ//nptL9WGl2tsVFJxFRQyMcwZgdrfBmkn+uKijV0H/euNrHYp2N rDUzlDpp43m6NC9C8aDQaoQccREQwhEWhYQhoREHBhAwUkPoRERGIiLiIiIiM/oZZKIRGTY4zu0e yrQIi7SEVIdLKkJH2alGCpams+zlJzOdQfdnc+xQ+3M55CDtM1K5UR30Xwg4OzqiO0wmVKQZIDBq ZfTMlYh1R6TPoJkeO5ydhNc1iGkTwWyURcyVBE2zIgSmF0Xj9CKRfMlQRF40l6Lx/VfUK52OJWdj iLavrqqrrRra9Bum+E3oIPNBooER+zoCeqLHKev6MP1p1QIj7o3fQIj7tTu5uzvtEY+k3O9unp5u q6N2rap63NK93JdnY24Qu7v/aMOd9XO5319DZjBFPr0t0hS3ndP3/XXdv6HxSbX1nO//x++net/X b/4iPv1///Wv/49fv/772q//H/99f//19b/+39/ff2///x7Yj+z2CGvpXve/+tnudHfY0rPbeu37 X1jtI1pUOGc47V9fDhoNMGqUw53t/t7a/2/Gq2q6xxpXrbSvSVjBCuPtKIpcM/RFDZIc44VC8Rva sVxsRW+xFNasU8VtWI5blOce1U3FP5rKHKexTT++DQj7QxTQtNTZppoebrQtWKYTCEQ4YJn3M/2h EQ0GqaGp58RDBBoQwgYIREREREYYQiIiIiIiIiIiIjErqyMtMyC4m4qcm6nJkLVnYeCBlTyERTsy Bc7JcvwzsxmMlYzseMklK5RnaBhBhE3DJWM7yL9lVReJzRHtQyozWKahQgyQzbMtBTs1i5kJBbyU MuwnpyDy9VPpU0EG0wtwyChKbRvZqECqjQ7QYXV1yDtNdFxb9Jo1tGzQefHvBrSNFJ1RMcoeETHp B6RnomOU+p3egRH3eEjPnfdNzWZ83d9N1daujv57DRv19WjDndQheEfXcKnhC/udNa8n/rXdJ6e6 7vvut1/iDeP+9bdDQ0/3Q/mgL/ar91/r4t7/X/v9X2v//1VXtf/p//9+t/H7711+Q8Eux9f7Pdnu 96Vz26XOR/jjq9db8LW1tb7/WIUM3ax/w1Yab1a1HGv269K31e65lgXM5UbStJhhKwrGlBRsMJdt rGhUMKxhVaS9iKnPdWI2KihhaHKUGGNjYqOErFTUtR+xTSzDmHjjtbjTCaamac97DCYQYQYVM/2E Ii1P+ecMIWFCEOIhgqoRBhHdEMRmPERFoRERERERERERiInYzLQLouy3qUm5fIUKZBeU8pNlJHYE ZKTK0iUBSUMxHY+srlaOxNkeQMJkqMvELjpFQy+UBgIMKdpIgrL5CZnGSmaZ2axcwmamXaYWF6ns yIEprwaL502SoSj+tqmC62dRIe+s9uLRokKCIwWm/TqrzQDpusLqrzQZ0jYwRKPuoYaO/qCI8rzD mfTZtLn1T9o3K6M/F6enn7vO/aoN04UdHh6MOd4Ya/09XVfpzud7aa7+Oq7BAv9Rb/xSfwi7/9bh hnZMCK7X9/v39437/+6S/b3r/a/+l/YYO/3//r1+6+KffpP/Whv/vw//9ww59P1r2kYteI/5wuq2 c/fgyYmO1s9/rdWs7jMfb9t4b9v4pXXil/+Gs3OL06qdmuu2lHP+NJtW0sMexFeoYPaiKdUIp1nP 2KhmGxXrtiKQhTDlOccodsUvscVHg+7xQaEXGlGqEdDDCaef12pIlQam+NBhBoMIQdpghaEMELOi IhgsRERtCwQiIiIYIXEREXGeeIiJkMybGuJLIRk3JomMrgSNQzKoQ6ZzKiIRHdEdmqO60awmSszI LRkIUriedhMg8EDJAYO1vIOIXnQ0wgzsJlGdUYlQdmgLmuBTtxEzs7tIi7CQQYTMiBed1CHUImqn QL06Lx+E00YH9C1z2tzgjSmhmQsIFqXz8qU+ZnJjp66uEH+rqE80GiFRMf6BEffRnEJIOv90bKLy lbUIN8/enW/aRn2e1tqg83pAgd+vs5U1Vow54ow54/6Gh3GnOy2MBNsigYXrjWrY6cVuhxv/Y+vp 7r/66/6jr+//6097a/pbm/9X9uxDI43d/+YfzWU5T3/nR+kYu6tXPpz6CH/OW1Vurb7b8dnvPd/i kf1xF7WP2Ppv+GsGn3rxHav/8MjjGaBhsLavnQL7YJf0Fs9sbDSQtDn9sRVnLIoGON44YT6xTFfC a4qYc45Ufa42ExX+1HNBWVFoWtPP9nRaaHnWoMKhERERwwmmVNMqcRDC4QtTIhhDEaoRERERGboi IiIz/EWnGIk2BG0Jbi8IiJFxS3/ggztLxK0jswzLQIS1IMgmXRMy5XC0died0zXF8p4vkri+dj5G ohJExwztTOzWyPkswmQeEGdwyPJFRgmR5F4wsPkK04TO5x0XrYXW5BNJ0CoEDnZdGpVpWEO0W7V5 xur0686CpeHK4vZ2OET9XXV4YXpu7adXXoOgRH/5x1pBtAiPvpzDkx33S70CI/oz7giP7PZnz/n6 r+ugRf0blVWl3Zy0u66/6EN+53O+nKUGK+t0m7V3x3rjq6/E0ZcIr1uxmjI4Xt/W+Pf0u2+v/+r0 3ajd/frfr/qte6+9f+t/TWZyhy3//7S/vvi9bVOfTU3X7+cYp//Vr/OfrCBWXQX8EKoRf9vS+tez 32t7fw0x71frH7SVtK9fGqERX9Wsaxq2q2lUZ0CthKKiND9hhKI7OXsRTDBJiK3Mgx67UGbcJ2KY qIpjFUop2trimox3impKQNQZt6Dx2E0Gmmf7OFoGEwp5oWg0GFiGCO1lgwWOgwhEQYQYIGEIiIiI iIz/ERBhRERERO1MUZZygZNinMnMl0YSZ2BnLdTZiOxPIOIPJUM7RmoZTjIxkfCDO0vITNTI8Qkd jdoMJ2i8ZFY0gg5XKmX986edQl6aa2i8d6uagnl49o0VtBN1zRrdXrqjQ9GxzW0nhB60CI/pfVpB tAiP9Puk3V993RuSQfrSdAi61v67nHMP/qut1v6ejP6zsQGO8aspWYCb1dfudlrLhCcMLutOdiIu F/7X/j/9+vVeS1qq3vp3Xr19ba1F/X///r5bkh+rfUHzDmHvWu9e1N2c//vaRubHe/vU6Nr/voXJ wxZzb7Ghe+664xrV29K3x8O2vra++WsGr6thfaJwXtQf7VtWLX/41fV9m5nYKDsRTBglqRQHHEVF Vgzp5EwwD+xTFRUiDlD3x2K4x2qC0xW0naDCH50JRHDTQaZUvuGhYTQvNBUFRBhBhCMx9oRERZ0R DBCIiIiItCOItPERERO6RKGInc0Wrak2Rk25GRbFIiF5XUhkLSQQM7WhjU7ryEyDzsCy+UZMsEDM g8IMoBciYLnf527L5MmYPJUIChPMjxc5XCqDO6amoQh+E7Uwj+SoRNT3dUdmva6plRhQWb2dpVrd hghrdq7rhOa36NeeC3zwW9dd5nfLuCIsUn6nd87AjSRu+jDrX5uSWdqmeT6V8IPwg+877hU5P6Ca RMeNWdgu678MOdzxod6b/6Gm0wg76cVsVt9d1XvxCBP/18riTLhWRUr3162//R2OL9/77//1+9++ tr/C/9r/EbfkyDG8d5j98EUPMJX1/js9x6xvXaRvhE7/dnsEK2qezm2oRL21SukuuqER/TquRQMT PL8fGlHztQN7bqPY1Bm6RMF4aUEDYjN2GF2GlaTCjWKCzHrhj5z2l/C+PBm2Jiq7MwXFr0I2KYoM 26Cn/ljlDnHKe0Dzn7j2uFjz/oNDzIWIvu00Ghaa4QiLiDYj0MRaoMIRcMIRGZEZyIiIiIiNCMRE RERP4k2Lo7djLQYztbjsVFKfJPOwJmQs1IRAgzsaM7HMyLxdSuVo7EyOxXO3IlWRvQZMZKYJkkio woQM6nZrZfQZ2PneIo0zWGE0SHDCDTC3TO+jDT05BNMMjGmyCCbILJnT0ZzjG+uqntPRnanT0b5F M680UaK37TRrejW4asPTho0Pu/FGzCdAiP6Nb+unmg11dJv0m6s2p3v6nH0/Wyxy3o3SMbU7tmgz 6c30jP7c91a3W3Tvd62Yxp/3tafdP/0k+2diMxkcatoIO+IYMukt0nf/q94991/u+PfSt/4+/df/ 2uqHT03dRel03f/7+v/+7ddf//X+v//f/X+wiY///1+lVGB99/1LyHMfZHGvgh+PURvr/rSGf91+ 57OiCCDxrrxHHghXra+ldUvxHaSUdr314pYa+2tq8aELdK+ulpz6hpMMJRrHzc/kQew1ZQ5Y5xwr YaU1LEfdScH+wrFCsLa2KGdFpQZgg2KYpio/9nPYoWhGY9ioTTXHTHDEJqbrCx2hEQ00rQYQaTFo REWFQiGhEbjM5UFRFphNCLQhghGaCh2IizoQiIxoRaEREWhERMpogcW+tETscibWipoTIJHfR3Ai WZH5bkuYQQZGEVEQpFTRrI1GYypZCZFDhkpOyni+QmRiLxBxBwQaDQZ0YUhIyFUeiZsJKf5XCpUw idtM1iEoVqnVkqENQn1YXzqE9MIsdovq1QXTQWsri9hN4QdGthU7JQERrdarCbp19XdGzQbhNoEX Ld0ZxT/dGHXVpPNn9J6dG6jdp6ud98/9KrIPp90oX3tX3um7V6tIadGHO/vuhof/80i4RRNIuFM2 XCbpra+51DH1T////+t6///XdV1Xv1+vo3r1ub0P//++v3f1d/df8zne59VNBT3n77vRj9/mRBD9 Vgih6X1l13VnsEK/er2znZztffSHHtMccVe1ateNU19Yjm7QjtViNtY+2+1bCocbaTDCxr3H+tpD H8R+yhzOccF/piK4pQywrdQ0or2KYpinpWtrY0OY/asXEZhzuVFp5XKNqY9qbrQxhigwp/z/aDCa F5vi0LQYWIs54jTQi0I8NCItNOGmEIiLiIiIiIzIiIiMRERERJWjurEZNyeW40iYEO8YU7EItwJE +TNE2flcUzsHlCJ6SqI05LZIXB1B05nOoKCHFmVPCFHZrpluMMFUoRLBFqd6MFCFemdk2Xa3hcLo vnomOEp/y+fyvqjroeX7S+Xz+h53TRoaLh6bXrZ0CaCb2EOtKqf16Ju/X89nvpN03SM9Jvnfr7+f Tvv/N39Ag0W60v/P8UmyXZFPp6eu/J0YRHwRQ9d5hzxJ82JVkTzASLb/eOu/oSVMt+cf/1fX9f3p wmhEdfXphelXtb1O1ArjbFlysEQrd/tVFv/MIjpbzH/Xa1//dTDgiP38w5Q5Q+Zyt2NiM7EBgeNz 6CBijfsRq67ERuqv3pPQz/b1/Gh3UaEXod0S8MyEwgeGCBJhE6P7nY4S8VtLtJjW1/6tv+Gl+fSN 0M3YIOEgz/QjhB9YZvasMJTHxGx0rFexG8V7FfHu/CGF8w8RF71M5RcV6tC7Q8IXHDQ9jQtDONqj NDEaFpp5nK+GEIiDCEQYIUWOceIiIjERERERFhCGpZzVCJGEVwLOxNFOyIM7Fs7SsyIKTbVGEdcl scyufKEXRtBSGZjKjO1dkJkHlRnbxfITImC52kFCDQZUolQpKcwzuBE5XC87phO5BBMQZ2ki7JTG HoRFdnTyJqj+5rFOnarZD+lRbtFvwqaqjW5XKhLW4aDVO09Wn+DKH4OFXdXu5nJj1oOgm9Eh9QRH kTjT1pAiP7Jjlu5qand1O/Z4NdK+2DBK8ii0SHW+jv66hB0bqV0/P+lbQJruiT+t4IO7Tb/S2RXL 2NN17sQnu+d7vmkXCr+403Q062RJlwqj14q+d7lLDH6+Lpb/ghGr7+SgVuvXb9d/9e/60n/d1L9e /+ryNL1+n/tdRCHG/qrzwU/+1fz6tX2pu2e/qz3133nR/urTSuu9ZkXV6BCv/BDHF/wQrVhherUa 4YLHx2v/+9J1pyPgrGrHX2lDWp/zDmHO/+lWMLUNJDYYVhpdobQXiPbarbEcNRiKaSoK9sbFBl7E t0I3sYMwTsUDMFj2KYx3a0WPXUU1TTFIIccaaaadroacXDCphTzhhMIZ/iLCM1MjFoRYQYTOuLhC 4i7iIi4iIiIiIvERERERGTcGMm42jupFcbRUkdkhksRXKOVylHZXEHBMqEdUZxKMqmYRGZhGsZGE VRHYnmkCDKlF86uGdujEU7L5K0bjuMKQmU4qDTO6oypLU7T5oC5qEReM1QTJwXVO007QZBEp2r/L 5/tb3Caa4QwQzUICSLfR+7Xn47HEpUE2qdZ6C6ujW0a5KQn0qo0ML1dJra62gm+ntfrM5rouNPU7 ueDXfnfo77Sem1736cxzvenqeM7+f6N1Eno3KnvViU/ejDniNNoIe68aDd67f9WrzDnjv/9/r/a7 qNDO96HtvKVFwplpDbqv319X93r133+v1vr/9/+v/++o/9/2vv9a6H6/6/9+xF/X//V+59Nn17bn 161P8yOKR+h+77Z7ur99b6fW919zsQGHiP1tY/1tOGFttYYW1giPivLcftvtY2wrGErWaCnv/pNp XVtq0Gbtx0wwlQVvSjQ/zQF2GlP91Seje/VsJLDCTSsNLHiNiO0mN4oGYH5qWOKa2I13ilY/F2nv QxTFS8hihdimsNUxsIXoXEQwgYQhphM/55xaZyEGEL1TxdpphNBhC0IsIMEDCDCDCERERERERERE RiIiIkwhERETIvEKyzqilup6Z2tRXVFkpEK4WybkrRJpGhXC6yNZCIiuT6RT5fJbl0SoIayIwirj XF0U5FSiVsjwIGddSXwpri+d0yIyp4QZK0YZTsjx2J5K2R5XlcTBi1TjBQuFvTTKcQLaZKfV00Gg jr3M5xGztxSGwgyVCIseE0wvhXhB9QfphNbW0YIa2jXCro1vddGuoS+hXC+EqDfBEfRh0/OP6PJ8 sckPmHDd5oM5Q6BEcJAiPugRH/ptK5szvtJ/nfdNozit8+kCI+6JD2p3ckPSdqrrvV7wTWwmCD0G Gqi4iETeNP17npfdIV377S33phfF187w6W873q0t+8gkRRkcLX9PFKxDZnFwpmyOH0F6f7x71vX0 ////uv//rt/pf8Ov/a+9f+n9a+k/eYX/eqXr+0btUZyhn/u1/77/aqHU//q/+TTBLn61N8inm9j3 3+YJV+7Pd6uoId9a6eaBih3/4rf3pjSv2xXv4j2sQh3HWI53l61X17SsJcbelaVMaw0oiqz/Frd0 4X+GF02Iwd9iP2lC19cGKYimIps5GgYiNWI2MGZTFMdkPjYp2Nr2NimqaH2pqbFQQuLs59A200h2 s3WEwnaamp1DCFoYIaDQiGEIsJobXVU4hwwmFzQVmY9poMEwhEGCERZnKHiIiIiMGCaERGhGeeEI 0IiInYvDQhqIkJiIiJWc7PkpCiJTmd4ZkXyEyF5LIuiF5UumQOItnIlUVjMkHZCRKhaO/gmg86rJ QFC2SjslH2GRlgmE6P5KO39Ubc8ztGiUqIdp3/v+D9qCI968J8IjH0kkHSbgwS/n6jvvvvPAe9JP fut1P9s9Tud9XThiitrp913/4g39Vb79OaBjGP21fsGCKAIQZHC+PX/ud4/X73/f9L7/R3Hf2t3/ WlDk2Rgla/oaq6zo2e0bf/tIxN4z6Rn+CFb6kTDBFAxD4SBDtJcEO6+Gv+/Vr/5KAt9Vg+IKmMJT /qPuNz1tqhGVgH2uwZgpMRkoyF44QMwJ/BmkDX8bx2mIjVTWE1+E447hghGedRYU3lDqY8RERF+I iIiM3RoQ7TidkKJXGmIiIiCIrVCE2qQQM7FkUIyNUVnK4FkKyoRC8lEVpEsy+nLdKwQMqI7EslcX 0yoyEjUy+E0yl6kajUKQcdIwztXF2dwIRfwmdIufIOUHeE7CL4OW6n6Z0s7UBVtG5nXzWJ2dQlF8 /ano1CBTUJaqmt51CIe2ENXp93Nfel0g62Egrr374SRbwtIER5qd2i71ezud3zWZ2kjPtJ/pN/Pz R3vV7yQ+d+jeuvt5xzPhA87ndVT+6Ca3Rhzx9zoiPLT87nd1vV963vf/f0Z0/+P0ROLhX1e8fb/S /H6fS8zBdd/f/9f9Da/79K2v93+g1ff//v31tNu////W66+q7/qq97+59MRbU/41+z3967r2ewQr filmR/+76dYIVeCGl+3QIVb/rDVx/fwQYL/FLFLHv717f3e+sNLTYSo7Vhb0oYWn1Y0osM3/n/2o Q7bp11UMsJjaTrjGmKiKY4MwQYM2xIJiNigZgmONLV/9jkntRsLDC5oKe0LQ0O0O0GFw086mE04t BhTfFoXERhMohC0IiLQtCGEIgypFpTVSNCIiQRCIiIiIiIiInZShOcSvpiTcTFJsFoE1lk9FUEK6 tlUkzs+azKoiozXF8qEVJEowhrLdLyHFXF8hdDCkVRQiXipRBwQZFQXOrL5CpF4yEiUiBBhTUEXK cZLIJ5/QQLWj+FslISQcVIyimdJMlQQ1CIt2kuSj0E3rNElQihcFCH8+zkn/1dect+moSQTs8Gug RH290ndF3SbWbFO+9K+z6CXe+d/P0g9nw8PP+9Tvn/OOYfuNN1/fawmqdGcqKT+6O54ozne+2XQT CJvGW4UGH17UU1vjj98Vd6tX//zOLhcfpfFf/9u+I0E3Sv+vp79f/b3//p9V1+23/+/0OFaWQo9D f3Pr/mgocKZynO918//2v/gh9Bpn/Z7f37OT6//6NuxmPOh/8NXv6EaEeK4av/Treq2orx2t+aAv fVt7/P2jNTO/8/4wsWNq1n1+FImC/asMLDCTEUyhyxynCYMJa7DCTxqxG8Vx7wZHQXBj/7FKxQyM d+1+xsUxTQtCLFC80FD2KdqZFqsWh4ixB4uOwmf4YSGIiwpyItBhBoNYMKoQiGEIiIYIQwQjM6Dx EREWZ4iIiIiIiIjRmnwhLQKo5E0xE7NRjJtrndMSpDMhdnaGdkZkLGSaCGQedKzsWy+VNBBy3SoI GQcEDIPKvIXhBlRHVG4qIg8hJMqTL6DNeXZLBTpGGTLJ9B2gjUuQdAZBWRzCdkEQTReOW6oFs6ya Z0YQeSyVF4zqFCaZ18h1moRGdrosdp2FtNdGjzA3bcONXJSEoN0ka+mjZe8EOEHp01fwlToER+0E G6QIjyJPqd/pN/8uDO54Bzud2jP9LzdSup41dTx0l5+pTv73nHMPWzElvT1Tz/pLfp1bOW8J9w2u 9dow547/p/1f8zjASdzu6vut3/Vp////x+0PzSLhYp9dxf/Xr/tN+vvr9qu+4vf9P9t71X///v/6 r3r/v+3XH8vv/uvU0FPf/9dVUL/hDv79Ls9/U5/jP9GGD6zSBBRX9d9kcLW0rj9YrGh/41YpQQwQ p/jfV0o1InQYWP+1/pteITq3rb8ct1MOw1qgrDSwv/50CatV6yVlDuNInkN1QjaCrsV7ZhEeBmCD GE0sRXH4SEbXFNb+xyFH01hmBmCWNlITFIW1UkOUPa32h0I9qENNC0ykcwNiwg0LCHHnQpwu40Ih hSUHeIsoOIiIYQ0IMFQiGEI2pjoRERERERFghcRFlfERiIldUxzIUMRlkjMhxCuDCEIiFoIM7Qio RKcrSOyQyWct0vOxuOnlVwpCZKUbjtL1OgU6RdmpJkJouAzWy/Z001PolqTOzWLmEGp7luspdT1l 8/5/KopnKL0GmdqdcwOqauahEEG1v/TBDjRceytx05bqojvr35E+6EJUn9TDqp3+tB0CI+/v6U7n d03/19/q/8/yQ+p47tnuj3S/aMOd19f+3zud/vTv2XyOEoznediIuFb39+NjRnv/8e31e9bfr5Em Rwv+va/8PiP7a9r/fr7a/6j/6/rv//Fe/95hRTX95+ocRoYZ7OOe1MX+/gmR0Czjf6BCvt/9hT/B DX90t1tR/iuofERGn+K4isqAkev8d6j6U3N/jW0uf3f35vhn+jfz//hWCI6s9hJoKyTlDgrbpOIr wyYL9jaVCP/a//b8fG1hmBjaYWDQi8bOdBocNNb41vUWKFocWh8WhFrnCotCIYQ0IiGCGciI2hER mHO8Rn6IiIi9RhC0IoitcQInYPKWiVorOdI3mSMrKKcyWkRGYyWZhEEy+gypqW4VkCi+dcrOU8Xy EyF52txBykldqfR1Mjs1ip5UcijmFyuYTQaedYuYTTBdG5kswTqXRnp2p/JR2uahCVynan5qEoxn 9dU0MLV8Q10XDRcV9VftJwQr2qTvrq2oQ9wuqr/MOlp+Qg73p4ToER+6nhoz7QIj70363gi/3u6O /Rupdz930Z9u9HqbtXzZD/Tat1v/X16ujDnj/S7f/+hnc8P8fet2/eh8zZHC03///r/uvutd7/+/ /7/9bVf0GFH/rX/19f//f/23sR/oar+/2oSbPJiP1juz3dPP9/BDujE6vq696X9pf+6pQQ/Wzn+C Habt9Iw5Y86GEgRxxtqP66Tr3V9RSvrera3rBm66as/4UaSHd0wowzfiPHQoIbFewwkIMsGIpjYj aWIpiKinjvxFeDMoHbsYM4S+009SQ9oeKa2mhppoNC1pw0O4YU/ofn+NBhCM4woiIhhc6IYIMEIi DBDEREREQYQiIiIiI04iMREyE4jmdqES+TJSyEZLEVIZTjKTKeIVFUyWGVeUMhcV+Mi0RRFSwhhA 7Loui6I6JRrLcli+ayIyLxC8g4EDCBhBhBlALhAyQijCDIqC4TKcVMjVI9mZwU1QeXRmjrwzpFzN QkJOIiLta2E08lbU6eqaLxovHSrosdpIm7CwRH6gztVEJSIjRpNNeNOfYGaMjdWtea2rhDV5rc94 QeEHmcmPmt+gg3NBrwm+hP/PAYSVJv/53BF9F4s+qsxT+rWgRH3p0Z+k+k/m9b7qEG0n+tqnp0bv 41O53ow530+/v108NPfwgoIEJUdet13O54/Ta37q409XGrira9DZHCmbLhAi1Be+L07db92u+v0M a+IQQuP+v/7/+uuv//r/j17hv//UR/+3T+kcX/uvr9VtXv+9f5qX7X7PcsckPam6DBsGw//7w0UB hiuznPsDEYQJMi4pH/7/X+CG+hHHG63Vdq+2sNYQuPnRN3f9/qGbNamgY8KsuB71hhWLXvYVpf2k 2Ft20rCTDSjvq4yrjuf2tMPYYS2wZlCVORjm2XOfHXYiicMRWxhmUCmc+WOYc4+YcocpynsbFVxs VFTD4N3qCEXY3jYpp8eZFDpr3tWGhp2hdhCL0IiHaYQiGE0GqP9iIy9mYQhhBhCIiI4jOhC8GCnQ hEQYQiIiIiIiLUIRFn+IjEREROxIU7RiJFEdjKWc1RGGd2yCs7hFa0ztwh3ONREvl8hNUGQvluFI j5jLsgsQqNcXzqzEdg0UZRk+amX1TCDQaZLAwi8DOkYanbiIMLZD/L5/voRGRfclHrfp/9moQHmd ozvPawntZtzouK9/2dzstWi1+6vCetcK4TDpB0g/c0GurdIEX6mzCbQIj77f7/mg+Pv0CI/rf/O/ m5FC0rq3oacl3T1W2e0mt6/18pUpE82iOgRQ8YpPv3V9PHH/Qr7q96V//xuK/9b9PphCI/69dd// /+/Br///v/6xHZjBFPr/6r/rNBUFD5nK7/ceukY0O/tddG3NnLX80DAdCIxn/vImGAQ99uqEXxf9 s5bdX8w96DTaUV1HdXq4Zuv/VphMYWwt/xFIVMfaxrnuGFGGCThYZzVjYigZtiSuc/uxQM4WdQKY r/f9io6timKYXGzwU9pqn/GrXhhBhCIiGFP+sMJFuccodiIYQYQjiIhggYJxFxGGEIiIiIiLQicQ jP8REYnZniIidl0RtF2TQQ7W3JupCFcYzvo/ktZ2K5CkdqiI3wyTCpksIqiTIpybCM1xfIXKdzyV xfKeL514ZApO0GVGShHonDBrZHjU7Irk8Q4w0z6NYpFMnpDGiRfMJp2pfP8mwYRNslQiM5ThWtre f0YdkR9aM7NQibqFdb+1pQv8++Tc1vIO+6rrQjSur/QdXptIOvc0GvBEf0CI+/0gRHr0WOU/efwt J6fKE/9G5Iz7Ru2e9Ai60CI/3rm/6erRhzv8adLuv+qf4Qva6VnKtbIpmPVfrQ19CxlLB6Tuvfq9 /963p1ut/4r9vxjEIKPunQj//fv4X/u7+v/1///X//j8II4quvWzGCKexHf1tG25nMOcf1XVId2q gih+vRi+wQr/r+c711bPc6IQVz7ytpTEYiKfZzvqznTiIff/WIwQjtK+r/fb+9L4rmHO9D8Ku2k2 utgz/xsax5/XYtWNZv7CYaxa7dShy3ChglEbEfuFoX9Y4ZuY2N+c/umxXG9xUU/MeGYFFRbUYuLF NVtBr+YcqO1xsJof3rNyan/jQaDQ4i4YSLHKHPCFpoMIMIGCEREREQ4jOioMEGCEREYiIjNBQ8RE RFoRBxERERFn+JtDJsC8IRK4HiJksGI3JsUCCZQioSlPHZQjswiYRCSBkuiCmRBHaXBTtIR32X5b ksXyowkSuL5UZEZLBkqOzqdkJHSJeUIM7SZHFOx2R4JkeOqs0BcIm7Cl5BpnaqEBUGE7rZrwqJuC I6Ts1ikM0HdXVnQLntNJFjuNXV16QQNhdFu0aGoRN6Lir1whUEIpOFpUa3TtfWhCQQbSQIj+gRH+ 7mg+adAgV0E6QebJFheE3O+6BEfdbPpAi60mp3aT1pPP27RoW7PzILV2lt7ilddX7daQom8VdLfX ozlRYuk+dzw/er773braq900t6+vfvW6+9BX//v16//X9/8f+ja8f//1//r/e6/19dNtozlFtr+9 fW6urQ676tq9b1BD/9rurqzlGY3W+u/f0N/+xXde6pd/anZOCTT9P1VrHeraup2CAvPD7p9dqr62 e2I7usJNqwwsNI6hZ/cRtpIUMRxHOOWOUIYS2IqwlDCXgxscRViK4qLrY2rY2KY0F1xoJpoaFipz 3Y2OdFw7QatC+GELjCYQYQYTOJZjwwmfaAgwTTCEQwQYIMFQiDgwQMKDCDCmc48REMEIiIiIiIiI iOIxGhEhWJNhqIeZRna3namMYlTEK5PIVGShHUSyEyrM7gIRPUheQegyWxdEqZiKeL5KeW6XnRmI qEp0iBxFzMZUshMhwIGEGSxl8lWYZ1zDKcVYan0E1zCM0QmRMMErEOiwi8YW/XU/y3JBPNYiNYLP f2SoQ1CMg4bRY7XTVNNUYGHrNDIpnSnLKr4VO6Dr02t6wtOEqGvYTqto10EG0CI/dIER55x6Jv5h wfaTf//PBrzd3Sud906O9/y81ckPs93uto3UbrPh4pN09b1ToLbQJ3PVBt6p/s9r+NN0/7ruuvvW EKujunY3zSLhaehoUvr7X/vXoYxDbdrxsf5oyOF3xrrr//v//feq/3t3v1/9dd1SG/SsR//f/77/ Ht/3RgY3Z3Kja259f2v//3057RgZnSXjOW2FP/7PYIdkeI8t62vqtz3pd9Y47057tdd6vfWPY+SH 8QpnOPtcGZzjx+1IoGKiI2+rSvqbnLcKDEMLbrZ7n+vDCoaHDSe1bCxFNBaVDc9wWLbDCVnuhb9h hJQZi2xGxTEddWKeOP32K9jFimKaa2l44VbFRvQ7FTI86LQaaesyIYQtY4tBhT/n+00wgwhERn+n iIYWIiGE0IiIiIjERGbIiIiIiIiIzdEZ/iOhLdaQiIluVZ2SqJbmumdizO+ZJ52tZCIluXyUsxFR nYOUlQyrwgcrqSOzolEVOL5UZ25FTyEyEyKBg6TZ2dkeCDIXBBlOKdqgp00wvtqVVBCkzWIns7Nd PPa2axUyW6lPhdaP6Bq6Lfot2FC7rf5E9dFxCo1uVyn9+03Co1sEMEPmgsf8w4NdBN9B0XeZyn3a BEfeE/88GzCbm6k5knvf+jP0Rj0m1XahB76DaM+99K4TpC9deS77NEfXZdEdqNWrpD9/7b67ndPX O54zDniaRcKKTviDdfVkbZHC7qOO/9+EyOHiI1f3/77vXv/v/X/3D1///f1/rr2vf/Mf10gh+l93 /f3zd9DIvAlf3sKbm62e2zmCFfveM3x11s5OvUrioYBDtv/3X+/Gu64hP06Q/dRx96Qtr7fdE4L2 lj6m7Gtt1aVt7t/thZ/wURw0vsLqyhzBYjYrVimPiPJOdwgZgVbFPGxvFcV7FfBNMbWxU8FD5nKe NNMIdpqY9ZXKcRoWmELsIXFodofDCYQiGFQh2hD4YIRDBBgmhmR7iIhhBhCIi0IiIiIiIiIxEREr rJkYMyNOTdUjIUzIEzv4jSIMwgwmdpaKlpnYoRU8hMr5lpAqlcUjstyTyFYQZB5U8heQnlJEmjEd zlJCIPITy6M0Ey+gwibtF2yK5PkJko0yUBZE2BBkp7OndjyjO1cgynwXs6yDJR5KPOn5fP+egh+X 1vpNNdFu4QNoINrZ1E/g0XFdf5fvUEK0fHp3f3r/q9f/6BEfuE6T070u82SIOE3vvWuqnd+r1PH+ +//Ru/9fXW6vV9+jDniuQ1ThJX98yWAwWkCL/7ozlRIoGK/6fen/b6ErbLhb8zZcIaMuE26X+/XQ 6980DOOEC9/8d+v0nf6/+ur/f/GYLXWIuv63ff/+//+eDuVGxG/7ujOUOU5UbzG/2v3xHFNn00jf Y2putT/e/fMevU597ZEwxNpyMN1IoGCcMKI34rv8RHdePBCgQoEKdOwo+DjWPgzDlj31teOGq3tr VZQFOi7Sqn4Msc8cL/8NJaC9UDP+bqHqz/u/x4ioj2GEn3igZhnqKYwZgZlzXlpAitDbW8b6EbWD MFHCGB+vafx332lnPYrqtxGYuR7G07i0PoYQtD4sJraHFqf4iItCIiDCmPEQwhEQwVNQQMENDERE Z0RxxEREWnERERGIiIidmM7nFeqJ4tY0UmxVkLzsTRkMjtbZDySma43kYyHqdmoQhaKjO1exkqGd nzIQhldTRS8pMIMIMlWCBkKyEyojWy+EDKdkeIVBBqUIg4J3YQeYR/Ipk8CqmahDoyOcgglTOzWz IgJTy+f8/ppqf1JS0zVIM1CLoseuRe0W+i+mQ55oe2i3ar+FmWa9w5P6Lj2lK5WJ3qqNbRrb6Nb0 1VNboNq+6Cb7/SbhcIP/uCI3+jdqd7NBnhh8Jv0Rj69b9Ok99N1O7ando3Kd7pOjPv99/unV1//C Jjxc9rQ0laTuGGO+8zp6MOeP963W+r0ukr0K/V179Xr06/9/xoJ4yJMuF/6bsGGvXS3r/2//v/p/ +v/X/eMv1r7/sR/7/9fq/r2/24jQroxXmND//pbPq//egUjojoLqxGCFP6vRjedFDRixT/YZzj/w QRv1BCrf/um/Tpe6xpR02r6t1foRHaQftbq1wzOd/zPL+PobS2ugXfvru8Gbs3YYLwwqo37SaVpU ONK1Y1YTDSZuck5xwmwkxxG4v+GNz166sUISMIKxQM0hmPtrW/EcRvsfuuxsUxQM6mNrBxGKaX/c HQodmyLtRG1QtWooenVR2ENCM/2E0GFhhCLQYQzQV0RERB8REQYUw8GCEYhoRGZDnIiIiIiIiItC /P8aKMYiImaEt0YiTREQYiIjJurFK4+TCIPNYhKkbzKpGEVeUuk9AyCowjVkKZiKciUxW0dq8jeS vL0rlWdoIjIvhSEzXF8lOVmIPBA0yGdqE7O6RB4Ts6hSD00GiY4YTtdwnIOVFRIojqlP5qECb1Po JrotwVran0SoQ1BFNYT0YKt5qFW0jUI0zvQIz1899zQ2wQ0wn6r9Oa2Fuh19NVmtqwnqE+FQIj7y xyh4VLem0CI/fcJ0g8uDO1keJ9G7O+/0873c+qR3u+jc5+pOjdW7Pf0jDnfX0IeYc76X+vevrhO8 7niGIV6Qrv9b/izQMf29Co1eNbGtlaZcJ7r7Tdb/rru3/3t/4ME2r19vp/6+91v3f96+u/x/7Hfr 0P/Vf7FD7/FWv6MnO54Kj1oU72vejBXaRu3u/r96/eq33T9/rZyfWr16uoj76dnOzn1ZyeqtR72/ 1OgX6b436mgp7YSbW6q2+bsd6WZyodrelnt9jWbqFoW2FJwXjs9sV76sRSVsbDBK4jobY4pjHind WI9DsUxGh9xX+xW1G0PxTUmOCa4qc6DT0wmqHrZ+sL1TWNBoXm6z8mFORBgsREMIMJghEMIGEIhg hEQYRC0IiIjEQYQMKZynYiLQiIiIzdEREREYi0IjCEyGZkM5XLISYRkF4m87JY3msQlGVTU79FOR U8hMhMhMhedhDI1kXjJJyuUBDsUzoZiIXhEYQwsTWSiCkFaE4ZCZrZfBAyVsvkLk7U6I/KfR1jEF LwKTRWn5qENQmmsg8vN2mdk+3e1Ovpkqk1T86dr62Sjd9GBv08Jrgqei4fqF0aG7fdGm16uka3uj Q/+E966NjQIj79wm9Xf4IjyBAm4Ijj3T+i8zd6c381mfvp3dJ+m/pzG/1V7zvtLr/V3Pf29U9ei3 j6VkTRxZQuE6QkVyOi6I6/ydHECKH0911v/InmAiv39xxe/rvV/7/G++v62EF09OgwhhMjhccIRE f6DCEa7+WkWX/9P/r3qtWuv//V/+P///vrrt/+vvtfuqv6N31/WeARH53Kc8bpNfW/8EK1Rk41df aqMEPUZ/jP9s52e5kYjGf71ghVdQQ7UfdIEOI8bxG3wQ2+urfW66RoKfFK2qzvMdNpf6HH+va9Dj phhLu1rX+GCwo1bCsRTJDhMbntk3KcLF9YirBjBmUBr/6/Oi6xQgzNP8GZQKa2M6c1L/sUDMoFMU 4NC1FhxF8aaaB+KHHm6z/HdxdrzIuGENMLEaERDCaYTCDCxScREMIQ7QYQiI0IiIgwhiIiIuIiIi M3RFxERiImRyGWULMiCOxLMiEgyXRhFSzSKXkIiMzCNYyLZUzO1vMi7L8rlmd/lXF8qMmhmI1xfh 2Spl81I3HU7OycXZrZfTIOLs7PhEnDBOyUBcujNZ00wnaeXz+mp9L9T6X307dlOlwmE/VNfPd3wQ f0qVP3Xmhr2jQ9Nb3prfTpOdieNrfsJyUAlTvQIj9vdIER7ptHfzX7/0Z+k/1ub/ne/9AiPv1aBF 1qULne9Tu1siVDruv6qn1de8PtV9/dP/Wrbr+m6rzTNhFerzsv0uv1vTrOfq673/lKDFdbtN65Ew X+t13/3df+/+mv633/+ve1v0v7D19f/HiP/9+I/0N/2h/ujOd7rvUcV/16j/u/obrzI2t6q8yIIV dLq8RpepaQItL6jj39dW+rGr13Gl6ow+KX436JQFBmgp/q9pXgz/5ud6Q7m5sdfYSYtZhynKdzWV eNLSj9pWNLPTr/EaWN1nTiKYrudH2Iqvxu7FRVCIeh2NraXaWKfYWPMe1MOYYsfDTT0NC7VpqmEN Awgwt92EIgwTQiIMIREREQYTQiI0IMIRERLSClcREREaERERERE7G0MTspyEzsSxJuYGW6UJJtrh TUISwyVmp2oyEjIGzv2S7JNEp0GVaJWZJolZEYZJ5CaZ2ZKV1NHdxfCGtmsaGEGmVcXyIReJUy+g ZUsIMINM6Rh6NjNYoTKcQJplOJovmdrCTLVDpXKkmugkTHKCynaaLHBWmFzUEXRY+5not2+FU9JB sKi4azQ0aGvCbO1MKWq66evODBCLo14Qo0NGhrqugg3pN0H+CI8+k8zlO6dGykHSbRedXoR7o77z 6c/rTef6c305ine3P+d909U9X1T2/pC1TaTVdPTlCPpa53O//uwYTjIp0rsfr+vqKW/ZEouF7VzO LhV91+hXx7+hCEfrTetfj+///evf/q//9/j9v/7zCb7++3/oscFMWD9Ggrav/r/3r9T/6MbrU/9d X8+nVz3da3nuZF1f5XFgw+sIap1oYjiNvSs5P02o/a90PxSojH2poC91FuraWcDFdpf0vSz/n+ey hyow0s//GpOC8akUSFdxq2F91m+wYJbYVYqI0/Yrjsk598I4YIofBgih+I2xxznznsVsUhb1HFVs LfYqZynKHsVM53TSzIQ7QtQcWFEcR+wsREWpyLCkviKLHKHKiGEIiIidvwhE4mEIuDCmPacTsxjo MLRMeIjMOYeIiM5FoRBxERERaaETs6GIzhAj6oROxPITE2YiJkNM7DhEoR32mROJ+IiSlCqkoyqw QMgpEUzvUwgZVrO0hJka14zsFKW5KRV5CYIMgeQmdq9SHpGoVAyYwg0XbzpGJSJxByZUaLgM6qyL MJFGT5FWYJORS5UbBL5XLGX0wpTy2S/ZrSgmkg0rgyIFCJjtBBshfp5fPTujQzUIgg62ml3po0OD BDtJl/nQU1RC2jWzqEBDRoa4IeEEoSRrzQDBKEHp70CI9X+k2tN3o0CF9TRoORBpA2gTDchX3QIj 702kiQ6pzfuqNApGgQkmx5IfVrZE6qp//p0Yc71ffr6rXWdzvYoGGN6mVXr1edzu0Z7fr87niQV1 C63CLrM6dXr7//MwXM2XC/W/11Uaq3VhFp+20GGscOv/7+/7//9ZtPrSt/e+v2mR0Ev1/69dzarp fv7InOb/4P+///+q/ftHPavV7b3V6Qp12IjmRan+/93ghXpzn/V0DB//ggje857f/S/f4jBD/fTX TW6Bkw/3VrxSsiD/H7W/j4iu21VtTon+mIwgWPvfWGt39/CtvGI4jsKdcL6wwsMJTHbqGbnSr2Et h1yhy3BX7GFio9jTCruOIopYY2PY5zwZgmK80DCEJ4zQMMV7VPvtbFNRzHi4zOVBT9phbUE/MdRy TVMNY0NCOPOfOjckrSYYXQiLQtCIaENCLTQi0IiIYUxgEIzP4YUyGDQiIiIzowQs6IiIiIiIi0NF GMRoTtGIiIiIlrGapqWvmMrqedmoUhxA4i8kaxnWLTHzCU9SuCDqj+ahAmEk89kWzBa/BUYH1ukb PhCyzTMF36JD3vRuo0CFV/MOXft6N6s236Gq3b0ntl4d7a8Yq/3X+tww/Q/x/m9+O6ww8e2e5wez 366rirGjdx8/44jhpT/bw/lpAirZy9dj/SDQuOZzj4x5vznsIdrEbQg6iIiIiIxFn9RElGWxEX5X KkdjMg9Bnf5GsL7Po7HCrDU/lPqt1ujqEZxw3U6BJ3v1Rs0IYe+WklP+2+6MOeGGGX70Yc8SCu/7 7TdfG319/+DCj/hFxQ/b2vWh/2Q8JOu2rQ3pUZ52ahbuohc378WI+f0nY0F+8UwvzJEwnHFxiLQN CIjETtHJsFJSMRblLIKyuOZ3hneGdrJEtM7WTMi/K4JmEdnzURIMvkdBQoIMjCOwIYQYQaDCDQaY QZF2eggzJHcKmduIqERhU0yLx+TRb0THaNGaKNbRraLiE9FxXrqjW5nQIk9Gto1tB6NeE3CDpNpN 09PCbmHbwm96BEfdGyldTYwl06Tow7eg2raV09Otq3ukG/d8tIEWvoacacETuO39Bv+n37Xp/W6b 1/H3a/3S61q3r6/7+vvW3/rWt7zH8P8v3mPb/v+6+911tvdTLgxfqz26S3UZhXW67t7r02lratpW ldMNjvresdrWs8NNsL2ksNjh0wwthWGkw0oqNjd2KMkeIpUItisMaEaEbuxsUxTGxThpp3a4am7t ODru7TCaDCYQMIMEDCEQYIbTvMdMEIeZGY8RDBCIiIiMRFpxdp2hEtQ0URERFZXU0WySibCyuUyz d7lrJKhvZbkGn99/q9QznK4tpkdAlQx4iMVyQ4TP+DiI3jLajPxXEuV1PLd881CDWVwQaoPRY94L o0PhBvokP0vXK9UYCZ533bfVajb/7zDnfdvVhxQpC+z6timKfwYKxQYX4w0I+Ycw8R0IctkKojIV puW1VyGGkZllj5/yuLRPX6WqrEuP+WaZhiCwyPkfClu4Y7xEfPBXyvXhg8w+Y/HwYPRR/d2u/t6i vvQjIrTyE4iymmgRH//////////////////////////LMFlH//////////////////kB0DUf//// ///////////////////////////////////8gOlij///////////////////////////////IDok qUcrgqJskRigiENhjug6To09IzstSsCKTfWZFUun94c2n/pQf7Sj3fsGYJpTIKxGxTSjDBCMZa1V LQnRXA+yoi+TckRyk3hG8rwgmQ8yERhkqEg1sIMIOVyXCYTBCs/4VWU7V0J397X6ndou4hhoEXXP CDfqd2jdv94QcMMuqT/5XCkCKHpK9C+v4oX1q/K5SC/X3tfaLf+4+Q4/+z6Q7S3PZbgUEEH37Wzo saTa8axxC21X99Khz/aVYXEU9fdfxqftYaF7QiM/xoaDiIjERERlqLCOyTJuZIjqWgPMinK0jJYR dKdiWEDOwqMicXyWRfO1ISVwpGQhl8EDKdkfz6VCO08vn9bWwnK5YEXRMdpWqf1Pjrwuro0Gd0Gv CdXf54Nm1c7n/zvdAi/070aed7aTaBF/t8as7Lg9Wn//XfbdJtfp67dSJMjhVcJdd6r+tf6ev/+P /kQcp/7Eb/v3Xv9dfpRn+6zobatB/Xrj7q303V1o3fuvtIWb99NqrXgyOLGtqxa7+xXmgYfYjYih GxTFMUxTWO4tKOwmoZKSdMJhCIhghmRERiIiIjLWBURkScdzjLRSbnRXG0TPNs7QiusI7E0EDtBk HhB2VjKvk3dplfMp0FJTmGE0DO3dlcKETCcMJnWQaaIOLFjs1iSuWozq7BDTV2Yethea2yhw5res +NurShA+npagiPQqdAiPvNl0nEMNJ6nhq81md871pv3zdpX/r0mjsuFWrDDLqr/rp3pK0Zzvo1vV zIqyhlwlD1a9r+KFfF+v/3/+32/09f6+v3mHOOcd9BFv6//f+n/t77I/U3Wz6/cd/s5UInO86Chq 9iltdbj/+32lY12sfa+serawrbXVtK0mml/sNjYwfzQF2grDCTEUvxUFsU1UbGLS7Hbeh/a4pqbo tBqtoXDCaFoatODCF5yIiGEDBCIiIiIiIxERERGWckzucQtFmJSqdjhFK9o7E0dIjWQeU8XzuIvn aplVy+EyPSbDIvkpyuHkHELwqRFAwZGaI6TO0gue86dhdO8/hbV6+ezISZczV503wVGLIQigSr9+ 1fVN0CI/1tbQu7/BEb3ng11kh9/2jved/ujP0u6O930Zy4dfeEhs5DTzud873fJwx/6W2319b/7e mn33Iky4RF240rXbXbv+v/7X7//tr//0qVV//6GjOccocp//+qH9Xr/Qr9MKCKHZHQSef8Gs4U9/ f/ERcnDHrfS3W/XdU7TUIVERj8w4sv71//P/2r6Y1m69rEeLqbrEVVfgx2corj4/awZ1AjYp3Yim rG7st0DOEOpdoHjcWhafH2E0O0GFDCGhF8aEOoMEIiIiIiIxERF5vjJtUibGER8SFoRJsW5Bojol iOxiMgVHal7K63EpRFkhBpndowiuYR2eBBhCGmVSL6naVrZhGFK5L2ViCDKvUjSI5hMioLkHAnZX EQTO3CJ2yCFGzqEO1UUlISIg5XCxYZLQqLHZTi5fP4IaL50/qms90fHaukF2CI9CwfCDYXu1hNz2 e+jv2p3aN9W1ebDu0CLrRupI3Z+vReZ4Dm6ZFurok/rm7uKTevfvjT11vV3Qzud3QkRr3oRDdafc 73/of3NIuFrdL//79f9+HX6cW+q/u6111/XpXvMLzC39qm/24O99nY3gl7eY/bYjbPfvjP++mOrO TpJtpJ6X+mc/7Nzb/c94QSta++5QrWO1Xf9Y7Xte1di0icMd5EwXewo0OIRLQgx92oZuYQj2GEnV iKa1QjiNjFjvY3FivBIJDeKa5IeznsUL0PN3VhNToQ1Oiws/6Z17Ig8WhaYIoxFhCIiM6M5ERERE RuOMyIiIiW80IiMRETsuQJnYvmSjK4Hyb9le2QqNSI6CDIjMIqEVCykiPhAyW5fKdkfKjIoZdqQe dpWQvJwqnYlSuS52JYQMyKoIM6wIMIWi7YTTNQh00yURdwStphNtWzUIhGQ/yUehR2kElcEC6ZkJ NByx3nuZ2kgg2k6+qecwujXS11mdXf8z1+jZQnHoIP2kHYIn6eCI9ou6vU78JmOd903BF/nfaJDp pn50/9M+NGHO/Nnq0Z03V9JWutr2gmn2u+l990u19Ge4pfnYIGOxSenfTnYjMBN6adXb98wiPhfp /HtUn2nS9f+vfb79fX1u7ar//t/sRG/+/X/7f////1azQVBT+n+3j8zlR/rfCH/19WeycMRrEfpO rdU31/eCFYi4If2/UaHtbH13SRj7W6WOnrv4aUWsa97a1XUNX1lcEC+2lrDSn/DX2GEmIpQZlJBZ j2I2KYpitjYoGfaxwZggqorXxvsV2xW7FNTOVFxcRYTtNDTWPTQtZtlSDCGgwhEMJkggQYTQtUIi IiIiIjaEREaERESuJKIk2NRDUKZBSO7i3SnK5XlkNRST0wmdY7ryDzpFOMjjJfCDK43p1O0+VESp GIIMpxSDjs1i7RuaL5yD7757QzowmmV1AiM75tHfyDOnhU0X0KdQippB6bb/5bkx9JzW1pvEj2PT 304TaJ3SanfVpPNZnr+woIPU8UnRJ1uYrdTv+p4q8Lnc70lvf6eyS5sIaBVbxW/6ud9/0Y/3//6H 2/fWv3TVD+n//3+va//7+v9ft6+88HHzOdzD0PX/r+DTvu/6/rtnt/Y1tLX8cXxF++K7/4j6xWCH FbGThj/pvhpNrqr8/20sK2vfMPjWFhOFVeNpWKYpiha6/YpqmKdjhEhSupDawZ1Jcx7NhUXcdppo XHF2hdhDQjoWFiIjCEOLCEyF0QmDCERERGIiIiIiVxPlooioRZ8EMlpSyrSTTIRHadEty+QvK4Ej ueQmQvIiUg47VYvqQOL8mw+RGS2L6cOHZ3RWFslAQyGsniVIjkTTs1YLZDaaMEreXj2tnYjOnU6S YWzIVCQ4anpdXXwhSuEOqTpVfrX7uqfqazIg/7QIj/Nn1fRGP6njZ7RvSBF1r6O9/8JGejvefkGG GG/9X09kcdIzlR+d05FMwE/Y6Gk7f/45bqkYCdf6iGGR8Minfv9u3Efd/+mv/f1f/1Vf/9DVuteq HkIP91/bqYcq/6MD7XEf43mHKj/+4Rdwi7oYIVvrOdv4Ie3jQ8V1Zy1w/qWpqo0Lx/rZyIYrmgrp 96koC/+03r+Fs+kNi1DP9v+qtKxpRwuFzfZMLEUgv4wZwmK7DXHxXxFDd2ljWFwt8NNTSVULWLi0 LC5/TCFwwo0LCDCZ/TXCxpwYQiIiIzdEREYiIiIiIiNPLULiknnZiKqiDxErj8sqrFemShmNMkZH RtKS6CZV6nQ8p4vndM7SsIMqOTY1iXjXF46YIMiEXZBxqZfJWyPEoi5/aNwaERnSCDQeahOwt2dq ggTOvct1oIQwqb5/sEPW1fvp0nrVGvasJ98LNbV60vqjZXQIj+gRH/Rn9XTsqz5qd3T0jdW0ePU3 ad/N2fmjPu3q5/1W5LyXdV6/YpN++2aZgJQ165SouEoVv9DvW76uomgL/3W/5oC+/+v+mt2/eq9f 8fXtf6X/1//2v/1L7UzlD3detqZyoffr730N9z6nRf/615kXWL1YpbqxxD2c+vUceGbnonDGz3V6 S2sNPv0mm/il+0u/Sta7jhhWOvOwQMWrUt1QFyGFY1Z/2khrsajEbr7FTDnHOOUPYpriNqk2Kja1 YoGdqFPTFex78U0OO1QiLtD2PNyDCDCFqZFrzIzk0OGEypoRDCDBCIiIjOQhERERERtCIiIiIiJ2 BcS3AsrvluZZ2NCEL6ksiTRVo6ZCZCIz0DK4TL5L4QMqMhM1xjCkUDBknjvqTY1yEyXivkCkHAgy ndmsWQQifV+dIuYWzpINFjs6fafMVzTOmdhXnZq05brPZqFOjTwvM7XCw+9SE9V9Um7vXqaMNPfv 4XVwRKOkG0CI/ck9ljkx/2F6ndoECvU7ug/1O+8/tT9YMwKRH3CR491qd3hR6et0b8INN33lH+9L +9dZpmAi7xiuGIJPyI//zueNK5kSxcKEXc6Av6/Qq27eDErTpf+v9u6a171YMF+g/v//WtfX17df HX6/7/0mtTOcf6o0AvH6Yf1Vfv95+cPnQ/b1z6vwpOGI269+KW1BChoXb6obpo7LhiHHwQ/eNId5 3GY/tL6J8IMjm68zlPXjStUtJtKu71z+2otB2gurbVpVXDH4IoccRxHDCQuIeZGY9pWI2uMGYJ2I qNigZ9oXBmCYp1a8H8IbUjHMPYr2vx2hw00NNbWLCuLQiIiDi1JQUOwwpyIYQiItOIiIiM/RES1E 60OM5ERERGmhiIqWUaxErjXLQlhDuiKfMI6s3nRkaRkLxfIPKeL52JZFSI4p28XzIbIjojoKdIjX JsrzWy+a4vmRbkLkiEiDzUIFT7CDTC507C5S0de0KTbQiPPR1Ek2TiLrZkJ1kqEnGpD/T/mjr79o MLzPXmj0Fqtq/hL7sIvKMOnp6zfzvtdHe7I7VVP2d+1P1+f5alSo3UZ+gRf95Ifn/3p6+rW7NFS7 vf4YhGmYCCtpdit34joa3r30Z08ZoGK6H73d6CZcL/0vnY5Jr/uRcSu//+l/q3+t/Wq+//7+NTP3 9QQfx3bPr1/ULt86c6IJkcbnvfuojFG++poGPUc9Ot9BE5g7pbNxalS2rf74IU//xx2qtr6301fX 2kxrCDtrN2MZNiAxekxFV2uf+2RRwSbEUxUx/sRgzqBHWxTFCLFVfViKcyFfY4xwwQzZaaaEdhbC Fpppoan/Z0WEwsYSjTQaDBCIiIiIiIjERERm6IiJJUVyRGQs4imZLeVJhM7EkCDJajJOpZVjJVnM q0U7KqiERVpIg5SDwhpkRokOGFJjNfZG41xHiEUmxrEOPZCRB5kKO4dmpEdpoNMhpNMkNInBeDz/ M59gUhtBoEG89nSQanqQcRCuT1lqVKW62JqdQvvuhGEW77egmlUP6FXWE/6/dL+MLa/VwrRY6oP/ zOIU8GzPAO/P8/Kp3av9Tw32fDx533Xm7ao3enV6PaV/fTQ1Yg77Jj1FL+29ft1bs5mAq7x6E11C aBj/dvciTLhOjRkcL6vd6H6v1fXtrW6aVf/198d/X61o5+ZCaCUczn2Y9b6HaWh+tTOcfes2Gfvb mR/X1GboIYz/9X0IS0MM3MaVrsarauNC79Y+zmQwtnL7W6NaBbS7X2Iq1hI38+orVtKbus3X/71/ HLhmgL+xTGEKKKOsh/abFQT8Wm1xVW1VcUPbEVWWpUvTStbTSCQx8aZqJqh+bo0GhaFoWmhaaERz /3ZyI4MIMEzpybmHBEeGhhCGE0M7xERERERiIuIiIjBCLiIjn+IidMm1oRMqRkSI7A+TforpaUjW QmdUVxfCBnYllRlPF+Gd9EHknF9MhWVCCBybD5qZfITCDMimL5C41ikHQZBiEMKmfShM7VsJ2F4Z 0ifz2p6C5KghKRDWIEy1Cpdc6dosdhfC9r0nzW+9edw/79bVQlNcevegg2tuiT3NZo2JF3vdJ4SM /nfYhh/0/O95/o3URj6b877p6ed7kH8/1BhpO0H6K+sXC19WZxcIu4bL8bfev40M7p1eW6pGAiW/ 9/oMzi4XEzZcKyLSNbev3+v+h99pf//+1//r+l/1cbj53OP6+nncqL+ETfM53Kihxb/37bqWoUrU zlPvWwRQ+/92kb9ntqfoInfPrUVEPfHio36nQYehH19YZubOff0MaF36BCKdf8fhqK5DG8WdAk2d W1aX40kF3zc5u3pRodusNfxrUMJMYSHWP4WqVNtbFNK1sVC/qn2Ipd4onDH2KBmTi4x5x7XC5rKH zBNC9C0LTTW0IuLQaZ/z/F+OwqUMIc/iL7QtQhEREREREREREZyMRFnRERERES3LMty+PESuBRN8 RGCGQsKdgQQlkdjQktAoEO4ZBDJNFWiny6MiiL4QNM7uL5KIjemS1keNcX1CDKlkvhItQrUm6MyE 0ciMZfUlEYggyokGde0wthdBovmtyD6Qi+auF51Isd50YQaLahoTexATQa3MFU5nejQ/NQi2tz3h Nq7aUJtdbVBP/VXTgiPuloER5IPpB+1QIj7zvdW1dAi/zWeGu877ne7n+g31O7c9URjqFPdL3P9U 6V9XujOVGv/p66+m3RnKiuu6/GuRKNiUrx53Tar/xr+5my4T/pf9f//tf7b+v/38L11/qv//f/9f b/f/MK/6///9/nC/yxzj/57Bfv/+cLpeoo3boEK2//1tU21v39/Y29L17UYQuxpY/7X/41tLt12/ vSvptLbSdUrX/W9Y0s+rS+lz623TFBYwln9pScHrg0mUOdRjYjYjiOKiNih45oK6xFMVFsfusd43 VjjapR2Md2mmEoaDTQtNDtNKGEOLScWhoMJRGXxTsQYJxERnREREREZuiIzOVCiIs/4QtCIiZFCa aaEYiIluUIiEdgaI2iViFLQiJmpNh8iiJsJma87nmRY0wQNUyEQVSKZUZC8i8st1UiOKQcmRTK+Z CZrZHyEjUy+EGp9Z/+yiJ+QciahJtxLx7Ona+eyUBaGdQlF8/eahAlZqEXRcaT1ptHv9qEkl7Xfr 9Jd/pIER9wkgRH7p7renVuubDxn5IjHuf+q3Vb5ukJ2eD40bq1+iT6b5J9b039/08kP+1GYdPG/+ aRcKRPNhH6wnFXxfc0DBkshid/pXO/X1291/46bd9tur/101vFv1b3rqu33S7f78aH/mFM5N///P yiPV5+vPBT0Pa/n0xGjIzIv+/++uq9q2knQva8M3P+IcEKFXFRfJWl91av9f/W//V1M5UUbrYSte 964/8+gz/rXWf4IUNtYwzdfv7ViK7WI2GFob3YpCP4xXji/BmCJ3f6xSbT1textOxtMV01tYi1N8 WlHcccedqjhqecaHERphCwgwmEIiIzkRERm6IiIjDCEREREREWniWZMYiW9Sk2BcrgUUiO3R3eRX MjTL5CaDO0IhES+VKJWy+a4vkJkLyWZeITU6Ut0qLxB4IGVGEGRgpT5HZqZfC5IR1WU6MQXOgUIv GduIamEyG0GSjdcLnSslHYTc6eahKP9NzWLLHeix2FBDW89KX007BDW+g6oU6+ut/uvdp/XBJBBv QQbVUCI/vk6MAj/6SBEfeftWiMetTw+533O93ddGffz8r6M/kh9P08/5/1v4TT+t53O+v3V53Tzu VH/13X/fr6dRfC13O6dc0zAQyKr1HH9veY7+2v2/x6/+20v+v/X/3/h4fuu36a32//FC/EUn//3f 9r7f9X7+qqv9q6H9e/2puwfVnlZ7/Cau4IV/68f7/FKCG+l6hCgQ70gQqzl76f3Ua221tO13WYco cof4M3P/vo6Be2//Wo1jS2m9ajn/b19YaXg5mkKjNAXYisRf6wZgdjYjqRByh7UVxtUDOpimKNWD OFiKBmB/xFcUxviEL5Ie07+9UOwphhSIuLQtbQa8NVN0eGhdhDyHHz/ZRFhCIiIuGEIiIiIiIiIi IwwQiM5ERERESyA+IiWcYioCHa3y0CUS1EVRBEYRGGVweZGqIXkRF8l9NTumRQiOMqMleX5Nh87n Fe9gyYkyBOwTsJlRZ/OkXZ2rYQZKWgwtkNoPPU+0QhmsQJ3LdZ87cXsjPy+el10a2agnoXV0mvr6 qzPCSv8LlOe9egRH7nfdOlfM53876njO96nd9Of0SdQp+yQ9Gf+0Sfhvv3rdfVudyov0t0t//0lt 8c78VtGdPXfed7mQ0BB6LhWRKav/63rSu7Xr619f/v/bp6W///a/+xmEv//3uh/X1+//xz7p/Xt/ rr7zaef4Iu0CKHl8LEf/pNr/x8exX6x0v/fb91wQq2/x86DdCIwZY/0m/un9G+0rS4W9JpZuef+9 tJ9WLXXrX6CthUf2I4jj433V1apiNrrj2NiuKYqDNueKEfYWDOE9MJp2hxaFoXYQwhaUaaF2tC0I 1WIgwgYQMELBCIiIiz9ERG4iIiIjQxO6Is0SzuGJEs7SlTK4vkLRUIqSKlkHmRIiLZ3+QeREXygy OIQemVeTmXFJRlZ0zXF8g6W5plREHWV8RiJAYJWKaxTpFzNYhKhDqIJAuyaMJnWQYXQo1iow7NYi Hn+zqEC503lustM1iHUJDMhdlzCaaQUL4SCr/en3M5MeFSDYWZ19Kv/TCrBEcwhdQRHpoLeiMeib 9AiPIvM2UXnep31PFHe9Qg6Ix6TyTqpsf6N+d7fep3zckb9NzwXDpJ2kE3P9Ag9U9Ok1C/pb//Gm 53T+jPxp28iUbCYr++lbSHEQYatP9jT4uP9Djj/T//r//7f2thL/19bvX/63/7b/+l/+/7b5jf/Q 6ljnHu/9f/IRAk//T1Z7z/pee7OVnsEOPiv1179f/XGEL2cvU0DGNKzlZ7QrTWPtbI6UEUODBY1J wcigLmgYppcLfUPt1hhL721Rv+TgvfTV1jNAXgmIpoK2lEYQjdQnqDPs6UNUxGxCeKiPY4p/vYig Z2oUtKvBSbprjWTHsLmopj5j8WhphBoXUWmhxqdFri0z/nI4iIhhM/4IkIREHhCIiIiIzkRERERG IiItCIiIiTY0QjEtARGRUIRiJPO3R2MR2JoqFJspot1vI0ioRU0dGYgQMq0dmIvkJhQQM6nqScX1 IKiGSrJsPkHHRpkJmRREYjcS1keITRGXBWdVZ1i7NST3TNeR0FOjI5hc1CTDlDlDHVqf1slAUi7C eVAQhhd+2ahQg0Gmr7Bra6p39zRCEdWulQijXad8LrpzoK1/6wpkNaLHdJo4/5VhoER9+2p3avCd IN/O+d+uf6Da3fO95uVTu9OflP/T08kPWEG6nhq/j1+/v/1ow540lpbc7nfH9b/7t0v6j8t1XMBD SMBFtGdPq/vXZ9lwoRaf/pe/33X//+3r29qvj9PFON0/V6pb3/X/1X9df+uvv/1X5nPX9UN//736 M5UeZyn/7//X0Gp/gw38EKusnDF9/vH30/0LavS+qcazn2cljjjQ9rbf6x91j7DvXY0qbVtbbVpW 9f8+rShhZvx0SkK0l5oC5DC/9in1jpoKxHqQ4JMRQZYRKDMEFRTxVKxFbHFsbEJ9jhP7XC1e7XFO rW07xBU0O4aaFxaaGthBodhTrCkk50ZmoUC0NBhC0NCLCEWEDCcaERERngp4iIiOIjERERghESbU WLjEm4sKIldYR3dLQHFJnatmIlqMIqSMi1FSQU7nEHksi+QmQcSjUheg5Nh8heZLYoQMoDB0vCd2 ZCemSsaLgEd2EsLmoQ6fIILsi9aD+E1Wj/trergtD0thVe19Gv9FuCI9Pjmg0K+E6BEf99c+kbvO 95IdfNZnaNy3SctStfhO2rtJN/9b/zud7HQmcYCL6M936dvF+m+W5IDkTi4VdurGnb/XyJRcL/v9 r/7f7fX+NV3t9+7//v/9GHOOC6mgp7+//+2q2uZzjni8/evXpDtX1YU/wQ/8Rhm4aH9fycMa9nME K60I4q8Ne6v/+h9K29z6ju70u+m6aQvbX37FK2FbCz/YpiPzIT+OLWtiK2M6cY4MygV99p2Kivao fHVn+NNDW1P92o0OIsIMIXEGCERmgodCIiIiIiMRERFoQ5KqWrqhEEDO1hna2paA47EhkIioRUZC syW8hHZ2Yi+mVLIXJknkLwgZ28WorUmwiL5CRri+ZAiCDIyLxrZHjrmH2ahDoFOkXM1CSDo2ui+Z KPJUEQZrE089jC5qCBdU11dNSEtUvVtrW4Td2qNddGt9+1W+fGrr1BEefRoy46BF9F3mg0UnR3ur +jcqbS0m+qO95uzv9dAiP6M+6ScoXpA1Qeq4Qeg3ff9dPj87ndkUzAStv/0P5kBhinrut/1zSLha Fpv/Fd///339wq7///df7/X+/Wx///r9vtfzC/eSfeh//9msqARH7zHtV9fxtM/3P/pdnt/v9dQQ qGbrST/Gf7r/7PfpYjul37fx+PxnQLGpoGNdsK31DSoioL2Frv+0pu40icF41fjVi1jVoLNT6pOq xQsVEbFAzlmI9j9iqux7H6HFMU17jzQUPluCHm4q7TCaa2dGxodoahhTkQwhHDCYQjWLQhphCIi4 MIRIxCIzoQiDCGDQiM5EREREREREYiJ2CZ2JotzRFurRaoEpNivLdWiL2SZkmjrpmRXkayE7I2in i+QmQvIXkTiqGmSiGW5pkJoGTEZDRnIhcU6I6CZB4QcMJp5/kchcggbylmXKQSZjtbslH+Xz/7II 1CQt1qTOsE2DKcJTZKPCEVzDuGi4frIWQm1+79fW/1ae+n3PANa9wvQedwdO+5GGzQZ2i8XCRos9 md1oER9/frdKyD5rM71O7pHiLz/pv5u65v26vvVJ3pyhHktVau8MjhK80DHkUB7/dOnf7/ggSj/d CaRgJXiDauaAu+CJyF03eITI4X3pvj/V8L/X/1/9J1+vX9f43/ev/XmHOOZ/7O5Mcodqs0GHKexH frf//b+tWz65+2ECsKdMEF86KgychP9nMZ/6S/0Iv64i0CFUIu7pNPXdLjwYOzk+RQMJqO8RHEJt d53O/bVqL+NK67Vvrv8Gf8MKNr4wtKdNTQF4YVhEgMfwmwS1xchhYoV9oKxjTxH4MxX/YpihtbrF bFAzp77KRhRQvXI5FKm5DhhO04hhC0447TlqFijCFpEtTohhbORGhGgwhEYIGCacREGCEREREGCG IsIRBhCIiIwhERJfGJXNWJ3yKzCZKuQpHYogREJnCH35k53OpH3MwQ6ck1BqyoSeU+XypZri+ZGi BFPIPTKXk+qZGCnUQpQLhbJW1KUC5rwXLUrUt1pH81MvkpR+gkz6IOkZUThBbJWKFwQjshz+ahEb 2FC0uEOghkHjTtbvWlNQkhRWglcEu16+0qdE3zOUPmg0YIj7rPBcURj7/BEfdXy5m1dpEuc8CkCL r0d7zf+/RhzvVuCDWIcUg2l83RhNz+ihV3S/3dX0dzu1WqW53O/+hM2XCfFVt14tdffQ7qN5alav /v7Xde4RZRa712//+v/8W//13XH///x/9Zv+v/2z6aRugih4IofOf/9nl/tdn0/Z5McFLj/BDQjX 2yId/tb/+gyOgo/ER9/xk4YOgW1tVY7WGCfQq9Unmz2qxHar/GlEfcL9v1SYasRS2khox3YTEUGW 55CpnKgER+m7Yo6BdiK2Nj2sGfeWnjmpk7O+YcocrfCE1MOcexUsf8GdQnGhF32uRlBqWhphT/Fr ERaEWCF2hFpqhDhpo/vXDCaEREQwpgEKYiI0WQJnZRyyrUJ2nyER0gRE2gqpkoyTzCNWVMzsWRDc mxNEQjCSIxGEdnyKo4lvI1le8iIqMJmrMSaSl4vhVSQZBYp2X00zsq5bpURzNWCYKmZLbUJ2QmSo QIRnUJIxh+eQ2E+b2mgyL2jBYiDW8/o0SUBVvRofQwhpumgl9aW99/S6nHu7yEHoER9/Sblj13q+ iMeiMejD7RnFI770XllWfHP9ngH/U7vp6Sf89TZbr76ep4c73XcxHZdF8j4Iofn/PPT9NLuTrhOK TqIhvsjEZDcYCLuaBjv/uOt+7f7r180i4VfCERHUcfdarwmRwuPf9IHrX//9Ut/1H+u//9d/96OL +v9yESXw+btpaMj1+CKHZHQIoejBeva16uv/n+2ns6PPqz30vp3q1P+z3dWckwSJAYYY1saXxx6E RH/2qzZtWNfUV4i78NMEccMLd1aaT9D7G6xxBNP+r9tBWE57hq7EVTsNLSY0nWRR79DCEbEaEcR+ sUsEDOvfDXXOdDgzhBbFC17GwtihedCegl5IcmPaZMcp7Q83Wpv1i4tC4uOoYQaEWEIsKhER7P6Z Q2CghPIGCGhERaERERm5CIiJahWhiIiIiIi5b1Qy0UzJWjsPK4EjsExKlnRHfM9krRWksmyqjWdn aCJGCBkti+ThFMiuIOCnavMWdlWFXsKQiOSkNpHYnyuCjO/i+QcaxU4ZLo9HWLtPMI/prcZkJ75D Cqg8vn8Ief9vPUNM6VppcIMLnTdNGhmQ1nThq6po0NV0a6vMP//X0Rj/hP+gRHt0ZxC6J2GgRH78 Ik6SbW53D7qd2kH/ptAiP8Jn73zZpHj/P6v7fqnfpo7Jojoj5HS0CD1v8EHp3rDD+t6v9XrxW/M4 uEp/v9Rb17//WghER6f/6FeMQ3//v//0/ri3+xkdEdK8fUMIoev/0cXX//f660vqI3+/UEU+nRur 9REdnkr6EbpYIoeYQV9NnRv/hDs+vEowSBDvW99drviMezUiOljweLRblD7XjVCIrBMJX4a3qsMj oJ2sQtjptQZ+2k2qtpV4IRTQVn/tCHtKburSEb9ioipGOCiNhhKCZQ5giWwluxxFMUDOEXCDX6LH MP8MVWGqBnTknBEed7CaBhDUVCGh2KfaYTWLU8otC4u0LQjsENCMQwuecGFWIYQiDBCIiIiIiIiM REREREkmV1Xk2fLJrApXBBDu0VCIRkrR2WZ2JIq8yDUt0oQtzowinM6ZFEU5kvl8qNDNeXzItyD1 CZfCl8JpkfLouiF5B5OGDtI7NaUhM7CgkrrKCkKiXgnaDkMA2gwnejDnENuyRaNunCdot3ERD9Vw h6DpzLEh+ui3daNDV+hXrvQIj9zjp4TbfzQaEtpaNP6pdAiP3CDz+tJ0Z+pCLP87793Pdbq+rz8d 2u1Qbne83NaDfz/u9bregunrszzcCKemwYKluZGIwE+NfpO6sjL3IHFwpnFwopa+7mkXCryuVgux kSi4X1+nEEiGy4TvXTCEacf9q///Xwa+v/deOv+lv+v1QWvW+/SMOZ161N1VRtz/v9X+1P15/+3+ 8/XXNxUZytT/BDb1ukCP4z/v6oWf70I30NYIV+t0tq2/irj916nVgo7smOuN49pfTahf3VtNVxzN N6+057iKYum0ge1F19sLGkEPWKt+evZKAo1tUP4qIp1jYinsMwQbTFMYsULjsUxUELgwX43waFim KTHaaF9oWnUNNMJhULCaZ2qrEcRwYQYTOhCDCEZhyoiIzdEREREc/REaEaEWs7Esmz8RIVCJ2KsR OzVFWISzMIqESpEbRCZkGIQik20RAghXAkdMmCIRFSyDzrkSRDkzsVR07VVKdEdBNSogprQIoeSp GGQvClOkzsJn6V1KO5xfVIyWIgYsglc6pMlQh07kE1KHKH57CZ2kEU9KekZS2EI8/hDCEYTTIvXM DGEH8LeXz+jSNCNRsiNXVewhH8+NX36V1/X/rTy0gRff+tFuUPZY4Ij1+jd3msztLtXRhzD7/s9o EX9G9Xz/n/Cnd72e0b1Pbcejx/2z1BEdIIWoQabPf3Qv07zueG3X1Tu7bsdLeL/46X7Hirf9f+MR x2/a3/2////tUGCKH/+iMeP/1q+3lpFq1/F9GSytd9dK/+/0N8x/aHEaMFWqc+o7bPr+ws4SfTt4 7/Y0aRoRQc//xYIeeycMa/3692+tX8MjoJoscoedAqDBY6BCsjNBkdBOGx+33qpIf/5FAxV13dTd hpe6o3Zu2e2I4joQdKNoLWf0IjbfsRQZ/2eqQ2GEhnPZMrgzKBjTHVxG8Vu08bCV+RpzDmHtYMwW OTHtP3+MZY9j8NTIu0ONKLjjW1N8RnCIXEX4IkIR0whc+thGaYW04iIMEIzkREZuiIiIjP8RiIjP 8REREREyxNOQvEYiWgbkztDESVCHdMhxPHd52p5zlutok4lmVw0QQiF5CZCIlMQOO/oZCRfhoMlk X1IOJTLGU/kqZfKeL5UcO5XWJQgZ1rI8R0ZAma3ZrZHrIPNYp09Oj+dAhNAsiV+GjO1tGA6HlAhK hFwt//P6LH0foiSkNH+urkJHUQL51CevPANbZThpBtXrSZoNFVW9+E3f4Qbv7tAiP2jv9UXntIqF fNmbotTvcQw6dAi/2e9n7T6MOd6N2d7o7/Xrer/Nh3e9b/ZP6MOd8J/nc7036fwQX4bL/12xmbLh dtJt63of/zSLhdy1KlK5YDv1bfW9a+lv9O+O/tp3i2LcL9DX1r0h/H/X//8ad+7ft///9a96r9If t/hFx/fRq7Pz/9ts+v/+fr+Ycsc70O1CFa2ECsugr+3rF+257BCn99VDJB9ToMO2t10K5KUR0R0F tfWGR0r6+o72EtCPvV3WhEV6X122sdfjP8hhyZhzsJ1ekgttJi1s9+hEbaVt0hHGlGl7H+f8MLP9 tRqI4jnPe9QZwlj+FCiExHCWKYqMdAo2o7YoMdbC/7FfGDMoTXvFTXxx5t+bY2CYVOGmFtM6sIWp /TTCHYUWhphCIYTQYQYW4hpoRERGdezdERERERGIiIiIiIiZRtCVwPlqBWRtHY4QlObxI3kozsWZ LAhrcrqqMlCK+ZCIlOQeQvJOL5Voh52iTVQuVGaAvlWyPBBqgyryE4IM7RkqZfKdBTIWZfKcU1CK fUggtP6dlOgsg5pYMiBJgXfUg5HRY9FhCx3moQtSpU9cENcKut+lght0g1pp+Zy36T0G6QQbwkNG t63oER+1X2WOW79AgV1msz7Z4DRu5/S8YQbmw7tAi/aTbn+vnHMP0+jPdG7Xo30bk/CDt31fMOeN PeIbxj7M4wE3revrj3JwwrudjTrZW4wEr6Fd8aG9W9v1uvXf+joE+1X2///1rbh/1//3thha9D3/ v+jtYQSecQHdVN1/7+vRgnm84+/Yfox8//2z2/5/c+gh3/1X/9xChm7CJzDdRr11q/brtcX/u/j7 ekn+kCKHDBFD4YTmc4/XRu2q23tr8KPP8IPDCXcNKGk7Edq5/tL3vOxSwwv8axxqEIjQ6FthpC7s RTxUUOgSxiIYrpimKFpiozQF2vjHEfsVsVJj/pivareqm5bCFw0GmE0uOLVR2FP8MKCJGypoRaER EQYIWhFG6IiIjN2ciI5kREREREREWmmhEYiWYt4iUIjo3HYaOx0Msq2jpFaRUIlZFXkrMk0dzzsE MjtSEUXIwhwZgbIXpkxFTyF53EXzsT5XCs7qiDyEyEzIXScjCmdApByZ1ChBpk07QijWJ5qEOnnU J57OjQdkpEC91P5NAtkPvCHBhUqRreaMkU0deWPCVTxXdf/oJLddaq/VlWGs1+nRuTDBUm/eFNmS H12jd7n9L8JGd3JD53v35+9Po3x0b9B9be2IVOdUX/zsDQ1aM6dfofUSKRcK39ZEowERnv+diAxt 9s0DHmcXC4giZXF80ZcJT04MF5m0Ip9A99bf/3+197X21/t4//9Yt66jj5hOurD+rfGr6+fqH61N 3/+Y+h3Oja8/3Ppg3P6sKf99trYzeylA8P237Vs3AhwzcO/HQ1v76vfXwQofhpgw5IeasFH20joF ul1w9r6tpIdR/P9pf/jS6o3SaBfr4yHBUMEK+KSQjrBm2tiuKjwZwev2l74wxW93heDOE6xBSx8j HCHdncoEi+0LhhT/2f444hoaFqhEtIEX5xvjzzUEwjNTkgKhnREREREREREREYiIiIiwQiIjtE2G cRE7VpTsFyuHS3WskZK0VGW/orSOud3ggZ2J5CZ2o1NcXiVxfUksXiF5KMjeEHK6lSIPNea3ZOGD IUyFRGpMj5cyHF2alcgi0y6M9M7UWaoFz+CpuFvL5/TclHqetPx2uqnrPXEWqa3dJqjX7Q9QRJ66 /697+i7fkxy40tzQWOv92CI9U7/ZoM7/oN7pbhXRn3O969GfdXv0/YQf53u1CDbu9c+Juu90nfd1 653O9vCLuNf//W+95OGK+lbnAdLxSe+7NIuF2/V/pvtV9/24a/7r96+urar39xX/ttW/1/r1+2Ip 9Nf0O/1f2I//Q5hzuUOcf1/mgpyo3/oaFVP/3vSBCv71BCv1giOMwrqvUPfQIUtCIvf76Ed9bpVF d/Y/tcGbt1983VDqxax0Gf7GtTd9tS1Cldwl3Gk2s3ZuesMKNKyhzBBQ1sYMwOxu7gxsUxXsUDOF XfYr8fTHFO9bWxTSjTT7TQ0PQdhBodrHHYQ9odgg0NCIiGEIuGEIiIiIcRERERiDBCIiIi5NyTiW QJleaIXncRrFEiqOzRFVjs0VybKuV1KOyEVJFRyQQ+xyPYnIoRHlCDTIRKRLKpmpkeTQZU8hMg5O HK6znbxfITJwXIcZAsXzqjkCDKlmtp2ahM1CJnZMIhFJo3M6tB5fPxDaDJWIryDi7JWJnTzqEh1W zU1So/rw07tX1ITCouKmbKHM9GxpNun9Umq7aPjX3U7MHdXCHLcsf4W9AiPI2aQIj/ovPNmE3P9g wSqbNOk6U71+p4o3UZ/Ph4q6JDr+fkDD6BF/2oQN3zveqertLvhOUekKuohiENX79Lb//Q12rd/O 9ygMeositIlK5ajCI8FrtGcqI7v//q5EmXC1uRKLhcV/8GCV1/679f/evrXbX8KWkUqEIj/+1uH/ r/9f/+77i6vr/UR69+l/eY/5hyKP9widx/9W/SH+67q0jdvUZ/2e2OzlrZy+1Y48OxS2br+93Xf6 FycMQzcdqB+ZH6v3/1iu8e369j47qO6etpQz/1jY1bXtL/vqOF/jV9bCU/46wtpfEfqjHqxqxxou yhyh7r7XsVFChHxtZ01hOWkUrqxXFMfsbWxTW0PNn5utTdaaaEQ4tDiwp/tNYtD83axi4aF2EOGE IhoWgwhoO07TQiIMEIiIiIiLKIiIiIjEGEIMIRERERERE7GsRiIIiCDAzbmZIVs1IgIfdDbAjtOC bzyuOjvMikRPIGZqZVmd2R2BxfIVBMINBhBqQmmEGSeEGpaRIpXWcmkCBmRbqVNl9SDDB1i7UwjN IMIMINBrkpCTc7TTNQQ6iI3tPTz0Pz2p2VjKp2p6W6Lx6VU9VRocz0XFGuFvSdGto1ua2kqTo1vR r/65rZ2YSBrvoER//Z4Ndqd9fQemzapum536P+m0nSdJ0bq1dN9Nv+9J1vfet9+qdLv9K/Tp913U d6vuroZ3PHdc0jBLvfK5ajGR0CKHv1aomO32//SxW9Xv91fX//13p//tVd9DXYqEIiO/06Dfw1X7 suq362I9fr/f3+116b/f1L/MOYf4Xx3tYbVUN/YiPW/e6YjdbX1s5Wk9XVqmc/e66saF21kY/Mir 1kdNNgh/qG32NIGYc721W9tK+o20rCtq3mgYttWwsNa/Sn9/m7avhJ4U/Y0mbsNKloXimeliilBh iNWMoDDFMUm8UxUR+x9frYqPbBmB3Y2tih/eg7VsKbrStNM6ELtKO0LlpFvHfaYYIofuOGEIhoRE MEIhhTIiIizoiIiJLEzoiIjERFiKDkdCIiItOIiIwdiy3qhErlgzszRkLcm6FWdieQtEqRGtI6Mx GRaiDyMy+d3l9BkmiFZKXZCZL8MgedreWkCKV1MjtXEaiGdnYttkFjXF8nBcg41ojpMKfRrFISKD X7IfYXCdo3Mp4FJR32Q/OjQcijJ2qCDTkHD9jkpEW6OoUIR6YWrSptd10nSbCGvXfrO4NVLSBVRo tqwncKF5nLfS+iT9GcQq/0d7aBF108kP3p+2p3Yh0bqMOYeNJuazPRfV2FN2d71CDz9RuT8/+mFu ZC6//r/Rh07/dOkrggqGmn09PdDVjQ/jt7eNviaRcL/mQEC//6f9f//1wvW/+//+uPxXf0b1//+v /b1utfXvty0gRfX3v/39z6Wz21P/91nRBD9f4/yJhjUEKjoGT1Zzt8d7/Z7erPe/qsNOTHKHbGPo R3XpX03r22tMNadTtT9DfXra8cMLHGFhpHUKhwhde7Y/IexHEVMO3iiUbEIGdQliuoqw0ooVYrYp jQXXMOce9Mw5Q5TlOmhfaaooQvhrFqSGH+LRaQUrFNTfDCn+GEwmcIf0I0IOIwhEXEXBghERERGd qqwwgYTQiIiIiIiIiIxESzVtGQJna3nYmpZAPMlqO/ZJo7Ss7EkdreUvOIJkPOynJRm0pCslmXyg zCVOVwrOyMxkHGuL50MxJF0dkIoRCRri+dcIMp2XzWy+EHZ2qCJkNl2dYuZ24iEVn87UNBhCKwna EZ2oClpFq2eQTzUItv0EEK2dPC+f0110W861r6eq/6osfq8zrHVrhQvCeL9XW9UbKBEftAiP3CDf o3ep31O7RuzwbP1O7YTP3nf1Nmf5aQKt87+bM73W69+d729XX1uvWlR2kXSX70I1d9Lj2RZHEqXY 1fj9e6H7p2iozij7/fV13X6vdxOxjCH+v6Tt/TpORIF9a3Fu31+v+JGDBA/r+1//////f+1Q/7/f Xy0i1Y//6tQgkQcWM5Q5Q5x6r+hvv/94IhB1Z7Gf8frwzn/Gus5G63U7SYKNW+rPb69YRn0Ii4If /a+k+r1HGq0sUsbdI32km61dVvBCs3fWO/YYWCQT61eEkb9pRrGlDCyThL7q0uxT7qx7xFMVC1sR WxFMUwh9zpsRvsbFMUxQNCz9Fxcan/+LtDtNTNOPpG6wgwhER2EOGEGEGEGF0IiNCIiIYQiGCEtI lURBhNCIiIiIiIiIjESzbRlrkbRkK5lalnMZ3GbzLQztYy+EDNTMRT5jNZFWoNSnzGQvJWRVqyTy +mWkWqV1PO9Ig8hMg8yNIvnXI1nV2QbIOCdkJEHHVl8IM7VxcwnYT8J6ZTojoJwZThAmpKxAmddO GFztIEGp34imoTW8/nTvc1BCHdZqCa3NH0ua3Tro1sIRzuDVXCzR3hra9cKdAi+u9Wv06WgRH3Sb pAiPQQJuk9XO+6dIQ8/Kd9zZSDfzuDQIj7o3K6Ly83dAiPvf9Ojd3q0Yc7+vp+nS+tf3W53O8Kop bpNV9iDdfjWhJ0byPrQozlRr9+18f+tycF/11/W+90v39tF1/8f9//6aEa0v+39e7+/t1++///// /7/v/R0S/uWkSq7+/t/oaq/gih5Hwtr3oyP9+vtV06t6Tr+DJ6M5XrZy8nDEMEF/DNw/PYz9s923 /qCHa2ckIim0rfe711ilvVtYaXraXeShZoC79R2rUQr1Q6nY4YXNAX/b1m60wwkTgvUV6rxFMMJN KxFRTFMRUVscVxFKxQM4QExFZaRavv7xxFO4ZlYrBmUJ4ocNMUNNNNO0/BTohqbrXTU3IbzHjzIj TCHdhTo0DCENCwgwhDCBhCJLoRmGkLQhhPQMEI+nFpwYQiIiIiIiIi0JUIRERiIiIlf8TCILgmWs ZqWjRKV1bO8M7VURrOxNFRkHkHhAyowhnahmIqMhM6Z2V4yuWZ2XyDyoRXNcvghkHHc81svkoiNQ QaaZ7OnaZ1CWQ+0zqtAiCI3f+fztIJyhedUmZB4W0EagpNO189HUIjRRodf0v6NbTuZSHt/qEi0g Rcv2TSskVpug10YHvVv0km0nvV7RefdJ/z6ShP+8kPGv/v+gRH3czU3Led/87nfT1ZF2bvfJeKWq pqvr3bTRnO9bKdZQu9Ge5aQKv+77303cbtv/t61/vq3+mEy4TE0ZcJ/dcf2+ZsjhQmRwra12P+v/ vXcf0vvpNv/+P/V9f/WFW/Vfod7lpAisR6+uv0gRHVqrfoVb99qXt1Jww0M3bOYz/JwxdAhSMFP7 xn+M///4IUThgEK9rnG0CFev+6vWLUzlRprycMX02vn0/2F/0br+MGWOd/VBu1XM0dAtRpT+3tSf QqMJDQ4M2xtXfYMykKBmCNPjYrv3fjtC845nKTmBmkEsRUMKkDMoFfsYQtD9x5jx3apDdoNDQ9Yt fHF32o2fdEGEIiwpGPmHKs47EaGE0NAwnxDQiIiJaQIou17YYWIiM5GhENCIiIz/ErjEMREcZ5zt KxEROxGdoySYjZaS2pNw1YiSjOzhCFoqEdiWSo0yTRhFOZDckpTSIojVndeQiOyQyV5G/GV1lGXo jo8gm5CsqEQ6GQPU1MjxqiOkzWiOR2oCJsMFTQfZEwXy6M86K1Po6Mu9MIOQQjIdpGSZ2oi5oRFZ KRArIIQGqMouEIoIao0OGro0anfVJqnenp/NG6uVwqfXbU6hIc44b6+qLHOPSbJYcEX9Jut5oNb/ 9+p3+k2y3M7Rsz2d3/giPTwa+i7pS4M8Q3uf0Z9zdRvtC9OGGvdP9jT7+99JZKl1Twnd28Q2WkWL V1TjTdwhnc7uE7hgy+cDEdb1eO/siTS/r6V3/v/ZEwwZsuF7Vu6fcf/q7BEf/fvjX9RfH8wkt/8a 9iK9D+l1+vH/1/8X/e9hEx8w5McofMX/ufV2qYInf69+6wQ0o+ZEZuXV/6wRTsF19ez3/rmmEEHo RDpN9LDTO1GR0CT1gk7ddra+DM5Uam7S/3aurmgUaxHFK3TkaDHfaVRC/c/xqdAsaEcRSBcRTDCT DCTDBLGwZge3X62GEoaQpHYGWE6wwtrsUw1GF/GxVLBJ1uxTFMU17WOOPGxTMOfYmi0gpQZ9lKDF PMePFQsdWFOoP6nCjHtOGEGEGEGhFoRERBggwoQiPFhbQcMIGELQzdEREaaERERERGI2IiItCQcI nZJlcuriVYQlkS8dmWdiWpC8hES1GEgzshGEd8jCJTyuso7OiERUZrzHkrRqRG8hMhMg4hNI6QQY QM7UwhC86I9GoQFJWKmE7O6ci6E3JFjslCPwJpog7U0KDK6m0009PciSTTPfkYlNQhqERgZBwyx2 ix6kqEV1Chdfg6tdPSdsavvr3b1+dQgUJbaCDoINyxyh4S7RJ4IjfNHQIj95EHo0UCI/bugRH9mc t3X/R33f/6U2ZIe59TWZ3V08IXnc7/n+ETHQpA/X4ShVdb903aQdy1CFRn3r+793nVF0pQi6I7Wd zvSFGe8XTur/v7f4oJuhM2XCLuVsFwi9e//69Xjrythg0i4U0BdL/280kIwhEft/t0v/2P/1//X9 /r/W/v/f/v76j//f9GB/f6v8EOz2g1bPYan63rMiDB6q+oIf19/SnRan/Mi+uCGrU/5kf7Pb/v9r anamiPhL/kY+Zxl+MVv69u0v6W67Sy1CFb/sf++nSn+P//H3ue7XtJtIIRXeyY4KPDGr7EfZICsY ViNlDlwUMEUwwojiP9a4jtknBf/7GuxocULFMdOxhoZh7h5nKHj0NQQaSoWheKtDi44awaHxxxpn +NWGg0wpyULo/iDdCDiDBDL2QFhggwi1C6sIRFgnxERDQiM0FPEREREWhEWEIiIxGxFoRLdYhMhC G4mQEjtbQQMhSMI6xvKtFO1Mj5VDNeRvIRHYki0gtSbJEVaIRWTNE+RXITITOmVZFXEHEvHbsKdj cahQgwTTuzWIEGTguQvIpk9IIUB2fRrFs7VwQYyus53OTVN1UujNZ0Crn9B+Q/QztR6o31enVGjR KxPYaNGlC+v3vskgnd9PqjX33VXRY+m539WiY+m5oNbX5CD0m/lj+p3f+vWv0bPuk2/2jd7QQPuv augQNK4pOjDnf8+W6e9BH1+5aRavr7ow5335IzaBFD3bJ8xkeW/c0i4U0i4X6F6oV63fx7rreK3f tvoTSLhUvGVyuMBClAuaBg0BczZcLdb/hCI6cKhG31qv9f3/r+9d/et/wwtrt/tdfp/2I1HfQ72p u8/VVs+gUvhXPp/61bPLzH17znfX6G57DU/9L80FPnRmPnIhqfv9vMjjP/dIfHcENMjoKhHDWNv7 Si7XtbbX3+0pY+MV4wpaQIo0Pvv4rd94M8FR86BVVG/a+qtRGwkNYjY1jCsNXuvhqLDShH5X2sd+ v3ft2/jv07+xT7uDPucGcHZz2mFIx6GxXHuxTH1Ix441q3xxofaivHRhuO0LQ1z/5/0IYQsqammU PYQhoRYQYIRZXxEtIEUWhGhacWEIi0IhghEREREREWhcREREYiNiIlulkInYK+TYCiqZ2JYQZkXy aYIGdmEVpFGdlUX5NiRGk2a8gZknlQiDiF5EZIiKQQMigYJRm4qMnDCLtkqi7NbL5CRKhZB6MqUp mjUZHjW7Uul5XU870lzsRemRgqmoQlkpDadGEfjp6LHrDT1hBtU18K3N7JUE1V1+z+t0zvgl0Xj0 TT28vn9GhhTUIoIenp68INs8GvSBEe5oNCV6nHoER+3RMcofLHJj0nS+cfoER/r0d7lpFitJVv72 vpNotyh6ou6TU7v/dXquqfapurpW634QvCB2653O+9Xuu//x3O53/v7v+8IQ6MOeMIZ3PD99p36s Um/zNlwgpOv1/mkXC0Pv2vt9K6W9+v6/InFwv/bf9eNf/pfdr//969v+6+vrf/t2u6/sWR8K/lpF q67a8R9QRH4sjj82v71/S2I1W6v+mpu9dek/tT9bPb//6H/esR/j/3n+4IodkdBWNjtVbPf9nt/j 3BD/qKxrtbWP9RV4ML1xv630/QZIfekWkCrv49gzOYehEVYMsc4960O74/3CQZu02FbVwt7aTBhJ oLEVqhwwo/as/2NYjDCP7EY0+/8dkx1cIXiwvvXsbW7gzbExTFNdbGxTW0PsVOfx+xTXtfjGmsHF /Q5stRz9HHGnYTCER2EGEIhhDP8MIRFhCLCDCEQwRaSmrQtCLXYjMOaDj2nENUHERERERERERERi Ii3Qi0IiIlooy1yVXESvXldVFO+ZCkEGSaOyWJhFSR2r+TZJnSOyrgiPmsyCESaITIPNZGvI1EJw Z3pkqZHjtIiOi8EGEGEy+QmEGU4p2a5uCDIiCZqZHjWKp/GV1nOzGFgyMzDO8QK9oNNVOitNT2ax Fg9XQjm7M9c1CIvoWwmix2CFK4XUtIsUrhVghyE1DsEONFvRo51CJ6Nb7CvPAPXCpNpNra02ixzj +CI8gg2iY9AiP6vj7We3SBEe7hNpN6W+/o3cX533N2np53ujDnfToIXquuEDpdz/t+83R6p0brat 0/O53v023WJpGAgJFKjARLeh/tfrf8V33offF1LSBF+hBFp/0L19mbI4X2//vVYK19f///9//6/Q xv6r+3///+phRTvIx/U3fqz6/oxv/2vn/X8xtnv1s9rVbPoMG69n13XTU//ycMXSa2chn+DJmi2/ bCx2v6/scMEUPYpW0lPK9vqGFm7BCgRxwYKGHFLDCtv2o//VhebnGuQ/+NUPY1jStulQj1j0I41j 8tItWkIzppOsbcMKw0vttQZggivV+K9iuc9DYpqNnP2tDVitp2UQDNtJQgmFW7FMUOMU9tVN8eS2 HYU/6dFjwwhaEWf4js5EMKf4iN5kWEIz/thBoWFU6EIiIwQiIiLRRiIjOREREYiM8lliIiIiIiMt 1tDZ2p52lIyNI6I7KoqudgRGsyGjs0iTZLs7FkWkCqVy1IMyBpgiPkojrmI1RvNQQhMlcXzWMkER 2maiOz5F4INMimEDNSNxIDBB1hNMoRKc3QYQYQaY07JiIVBS+9lWGAradqaxV00Iwmdmv57Toxns 1CKmmlnc+Z3ReTtODRbtFv+Xz1Bmv8Lca/XOoraNeZ1Nb/0bHrazW9OaDRfSD/6BEensHCDoJt9L sp3u+7c0Fvp6fRd0d/TdTY0n7f360Yc46Sep4wkE2pS11f9U40t0698QYfqjw+xhB6urs5Qh91ca er3vq/qsN03+O5oC6dq+0/4IF/nYiLhS0ixf2GR/siUXC622t/ux6///7f9//r+v9fFqv1/rjtaQ +v/bp/1S///rUIfTEf/6786LG+xv8N68NT/sRouNrz/3pvW6upwjPfq/94IV3v+3UUlrv2oeKwYd 94r7JoNwQx9uvunVteNvq1tW1qbrYUM3bb7C6cNLWc9tJm7hSaalChhWwlqWkCKDN1BdKsWk22sV FWe9iNimKigZgVcV28bFBrYr1uKa2uISEbGLj9hWDOs2MMER5img1HNlhNNBqhcMIaFpoRDQtPQY QtCMnq2EMWqraYUW0DCBhdNBhBggwgwTiIiIiIiMJnQhLUEKIiIi4iM/xERERERGWQJ2InaVlcJm RZHVHIlOViO1COwaOwM5bkuUiO0sRhEfIEiWowipZPkCI1sxFER0XQIoeQedzyVMjxCoEGVKIVks RiCDQcjFSHVnqDJYy/Z2GaYTldaSpkCiEwpK4vsQZBpQmmSkJl0Z6foREedwgRQ9XJR9krakX8EN P7VFjtdS+f6bRbstIE5XU4E8vn/PZ0aZ07mC9wzUIrqt6NbpusEI190a2EK9UbHCnijTboIOt/09 BxoVWtca9bumvM5Q6/puueDY9Z339N/c/6/tw31c73/rq6JD/e+eDu97PaO/RhzPRvSM+6Fv/dXG nJ0R0R0R0R9ZhzxXftdHgqO6juvi5mC6v//2vne/7fq77H3dd0Nfu/r+uhERHX1/76////6+/9P1 7tVtev/qu+/ceI333v+/Xr/btJ/xoius6L7/Ef9GL7sRof6qjBX+Lc+vXfW16Rke3voigYdK28EO GbrSb1S3tfV7W1q/vxqCFV+xO7hgrfRKQgZvw0rStft1Y1atfWowRThhWwrHraUaQM/2KiP+Gb8/ 2kmrPd6VIIj6FxGr5oGGNhhJ94pigZ1Ap4oGYKhCOKQXsbH7WWkU/jf91Bn3MbEbTF7SJDlJ14YT FDi7W0L1P+wwmcUQYQYQ4YSLpGLVY4hrwwhbnmmEwQiM5DEMIRERERGdEaEREWE8RERGf4hsREXx ESDxNmdq8oQjxcVMlvwg9MlmZKXJsDhK1sMiiIRknmsyII1hCF5B52a8GVz5CZCYKi4ZUcYIGQeU 6Nx2qayuF53phBmqI1nbxfIqZHEJUyP2Q8KXgmSAwg00jrGH6nuRJGk1CGoQKgg2ahNTVIMJhNNa nomjQadH46iJ2hq254Im6LdqjRRoowSFNQT7ngGoSUESek4SZP81tVftf0nNbvSV5nS7DSXQTc0G hJNpNvUER5L8WkpIeiQ6BXpuSHhh6T1O7qd2xBEfv1PFJ/RhzvRn7U2Od+8kPRn3uNBunp7OXTzu d2Toj5dAih70ECnc753ujPdF3FdGe2DBjV0rpbg0JaRYt/9bfXddjTpdhtGHT1vWl99x/ruhER3p HYEKu37ft1uvu/9f7jf/7/3/X92K79f7/6X3/jsEDf/3+Gvv6X/2lnalqX6Ff+hX/0/6wRH9/q8x 9dXSMEr/oyKgwYRLA///0CI4zCuvwgjndRpMaUQQIdY+6v+/vb6Y2+63XtbXV4pb/5ukX+CJF3/+ uGNhhfUEEratLqk+bnQVtZ/97Gusat6sWsUraTaTDCVnJ1pjfq4qE1sex7Hg7FbGmRxsU6tdZaQI r7WxX7GxTFMUG4pikONimKjGhocakl8Q0NCDsIajaERpw46cWmhaGmmmt2FhpoNKIaEYIRFxGZyh yniIjERERERYQIMZyIiLP6EXhCINWMRES3PlUzI4okVQiVxEbOV1rOwmZBaI6hkuyqo65zKlkJkL R27L5KiJayPlBojEGIJjmeStl87NcJoM4jERfMoyEzXF8LcrlqCnc+GVcXyIjsfCEMqWGwmQkRCC oNSUhVX01us61oRrqekXzYjU9HaoENYq3QOWkWqhXIifnRpyDiz20WOGdAoIdN05KAgXRraT1M7V OZ679N76hJXhOP5hw1uk20bH3CDyx606LHKH/O+6dAi/db0jPqfM773p57PfdG5KgRHvMH57PnEP O/qeM1njXhg1bqd2jdq6EOU6I6VGHPFd1uv/qrHbXe/xxb6FGcqNf1xSspWXGoJJb/pXe5FAfrre h9pszYIR19fT/7X+vXtqv2vS3ve19wscF//T62FDf6/0P/3/f/iv1v+h+RVZxIbdtv/+WkWqv9// /vTO5Q5Q5h7d113fsKfu27ek6V1V1H6t6Ssaeq2c/7qrTUbqM/wYO9Yrv71ERcMN1jSYZidSUBRV 7+/tfVtWlbSvWbqsRc3UN9WNYjLSBFuvIft6ThXV21e7hq6ocUl72rEbFMRUGCWrFMRTvLgocqPv fFRWNj+ITEVXFDFeDEbCXamcoCjFMJoNBihaaaHYQi86I8/xcNTo2h4TQtNNDViM/wwmhFoRDBBg hZQ4QiIiIiLBCIlpAisIZtmgQiyIhCIiRLERN4iZajEYiJKMo2xMgxDtViCsqmpBUVKIeVpBM77L oiEYRBEYRKsk2UiKdybEiOxNQyOEJUZVoMMmMxlQjozEdYlzMQU1xfCBhBkVDAJHVHo1OyKBizyJ SFRdsizNmFsJ2E4an0EGU4gQct1tH5VjTNcE2wnhduj+9zQUI3M9FvUJpuutJ6CDdpra2vSot2FR oZala3kX7O1YkllGhqmGH51Cf9OkKuk3Cbmg0QRJ9aBEf2eDX9FuqekaKBEfdAiPugRH3+EHkh0k 4971bD021O7bQIj99PfTuf0CLrSdXaoOFa7S7Gnt6B+4VXX19feto3af3ujDneDD1ddww0t0dzvq 3146TvvxSsIu471urbeRE7a/uvr/7fT49lqVL1XW4MMa6XYdf7/e//9f/6//YIofDHf/f//4/fx/ //eY+th3//SH8wO1XmN8x3w8EKvXVCOHd1r/v/62ufTdQRQ7L6ggUf2k/37b6/d/a1ftr2lvU7jM e/T1MPbJAS1ulvX19Zh70UBi1oRFRVtuCBHu0tjUMgh/Vt7YWf8MJZ/YtY1i1sLhjknCjWGtH8q4 JMMJMYSYioimIqj/DCqaA+pJwvUJcQ1oJBuI3imK9io4qNDYrBwaFimK8ZGOExTXQar2KluUPTlu t4NC1FIaGGnDBhodhDhrDCWRxaEPhhBoRZ1AQ0DCDCBhC4YUIT6l4VH4tcw5eRFgiOwwQYQiMw5T xnIzkRcREREREREYQvERnRoXBiDEaENCIiUvEyS477EYiIg2IlSR3EERUhQQrcEysoGQmx5Jmdja MKTYkzXmEd0ztbjWjeDReL5VEa4vHZrGsMIGdicgynyOgprgmQqTNUYcMjmR9Ex2wYQZKsxAmmQk Wq6k2jOmYZGNQqZ3Gp2JRqEMwXB4oKn0f9PRuaEYQ9Fju1iIaCPyc0U098ZbpYiaYQ1wQ8LsIEIR HiVBFf5nLejZpIOq6CDdIER5uFzODSbpAiPIER/qvOPVAiPv1JD2eDXFi1Rh/fUIPV9aN1G709U6 Nh37tN09U6Xd0Yc7qttG9V6N/RvQ084+dzxp7fFbVztPGAndDiRJlwn/1v4g2v/W5my4TW3S9D3d CdjGXCYpWL//30/2v36//t66v/+upasL/1313r7hr/6Q/1qbvTn059NTd//987NcEtf/pqf4/72n P/059NTdc+rUfu/21eh+LhgsNMe7WKXS40IK6iu/H/2xrHeskPH4vSu/VZ/2lDWr0OOttJ1hq6bC NQO4VjW723VKrEUh1asNdimIr2KYp+anV9imtihZzpAk62Ka/G0s0FD2ph48w5Y9ihw0O0GhaEZ/ zzQtNCIYQi8w5TlZEQwhGLQjQh2qM01QuGEGEIhghERERERoRcYiIiIiIiJXHIctY0UtQawmdmM3 lGVEbjsXRrMpwh2YZVUMmyqinM7MslDMZGGSaJZmESwjVkZkVyDztayUHouAyEyDwnakhXIwZtuw mkVLCDKjNeR0FOqPUt1vNxUZrdpnZ8lmq2E0zpF2nacgny+fzXgudhd1aCD3b+X1/WaHOp0W7Olo Ra+Gna2jQGdjiAhtaLh6phdGt3+EO+6dJuuE3/Cni6pNqEkEH7XfUER6l0nVabpvandow/SeXBnd evv3v69eq+jeqds9yT+90b/elfne9OjDnfP9enr33urhO/87niTg9dPWZsuENIuF3v980i4XFeOd 909eO/qzOLhF/ut8d1zQMJfX/33/6/r+q/t5hL1//+//6RZioiuYX9Vr+vv//X//e2I/uaDjnemY S32rU3WkblrER4/P9z6fRgv7agmXQK59ApfCiP6am7f3+9uvzo3X9N1rv/QjhCKbpuhrH26DtqPw wnav/pRFQ00I8eNb6utt8Mu7SbVdjSb1tbSoGf9t/bUdhb+4wz/bSVUNtKzl3kUSHUbCLUGLQW7i KKOK9Y2O0u9OIyKBhjH+K8MykmKa2tr42vio9jCGDOEgztQntbVNBC3ithMUNDTS0ONDVBhBhC4t AwQiGELU80GlFqQ7+eaxjCFwwsWp/hoMJxDCmRBhCIiIiIiIiM3xZ0RERiIsoiIiIiI4k3F8RHk2 JMRKXlc0SktR2po7MxkF1JQiqsl2UiJbEsEJY5NgQIpfI6I6I7JWyqIqEQmVCOmSZGsIQcCBlSky tRLGR4IMqMIGSxl8FNJMuyOggwma2FIs0GpCaDNWYZaidVYiIoIMliI6TTOpppyKObVpGsRMlIWj CP5F2mro3M1iosdrhcvn+Ig5naM7Q0NGUNFjtNRo2wImPRbwhFYQriGi4c6ii7aWnbqvQcKgg6BE fsERvrVtIOkG0phy7dJIIPUER7tnuE2m/toLtGzTzZ/qd2jPtdEY+rrcJDe81nildPN1Jrs9ow53 1dK2WpUrnoMPV0b0s3efDw9thmHQ1dPu671vVzwnV18Inf9Ju9/duvYv3V+scYMMavE0ZcLTZmy4 Tb6eK/Fu9a//fX+vpX1r/8f+q2/9+//j6r+qX1sRtr+uv39/B8R37//6MD3v+tG2J+nPppG7tTc/ e6nCM93q1FK31Hbe2r6zDjMb+9q2kU+Fu+rftKOuECOV8MJjudAo+67rmajbUlAQM3PSjXf7SjSw xgz/bWrSJ9DOgWI7Pb62rQW5/BBU2qHql9pDDWGqxST7WxUscocw/imKYrB/YoWKQuuPjYproccV jwQ7FMQo2frU260ItMIRDQtBoMIQcaaDUjHs5adHFoNCJala9hqbk1OqJroQYIRERERcRGciIjN0 RHN2c6ERERGecRJsCES6EREbQ04iZFKOxdHa1hMEDKqjsTzta5bmcJG8RMgyJPOmRpFRkJksy8ah ggZKclgLkWjuAXRNwwgyMi8asFIXEHmuCnZhEdF4hnZCR0RHRHRehBlRlPF8nDB2t5Cog9MjJVPo 6qzoFwnqmp/Sz2kgQdF80NC86iBDO1AV/QiMtStUzpYW18h1ot2EPVf1dGto19WZyx/ZDDs8Fvw3 TYVcKvCb8c1vtXmgt//Tr33Nnnf03Tb8KED9GlDqg6WlzdRuXJOkb8/0up+0n3nfjCD9bpNo3p6+ nJ0fSpdq6veK23qjWUOU7Gr73ocSJsuFnfeP7mbLhd9X6+lZ2WRgIRPMBf3xv/bCZcL7/7dV3u0I ur9f/Xu4t39Df9f/1TWv3j8d/1/0Lt4xt/frtz6pG5/2eS+0jc/11/fz9dngp4QKwX8+lBClan/9 OrquqrutrHZuhqP/2mraj67wQ316HcVHQimwkUBibudAorsPW0oaU3W0puf2kwwlxoX/fGdqAsV5 DClqVq2tRpNr/1eFq5IcFvxFMbH7FVXsUxU0FZ9rdjWEGmuEOKBmUCmK9rOmxUnBY/waGYahphMI Wmh2tphNCM/5/QtC1N+cwELU7UKA1TTQ4tYYTCFoR2hDCBhCIiIiIiIiIiIiIxERERERERErzzI5 ldzOzTlqKYgQZLwQZ2SiSyKEdk0SbKREhEfK1kJFCM2SnIHna3hSXjsuijRMcMIMqIlCP6JuGQuI OIPWTaMg4g4g9SF6oMiMJoWRrNYprEBDOkYans1CLNBVZ/p6BA6LHenaBByVBMh1o0FNQTLdb/fO xwhF/U9IzwQ6M0ahAoSrTrC9Dd/TaCDdfTa/0Jahdf/X/SbWCtZN6LzPZr6M++bPn1/q9P7q6Ny9 2z2PuvRuXb6TaN61RhzxQIPCcUE3VW+kJ2WRcJF/HV9mcXC/XQmjLhfi/meYCmgLmgYod7/obI+X S19Dj/vfr9P3Xql/+k/X7rW9W/24iP7u+/WN3n5zg2sx7/VTdwre2fTU0FPVUZqC/XO5x80FdZ0X 6Q3ox59V27n0576jpbOYr4IV9rajVghVrajjYIVUtyUMCovQuvDNxEwwtrnOGR0E5zu3447Wln+a Av+f69hhJtK+rCSH9Wey1K1rvX0NqbtheIj99VVhhJ1/fjBm2Y8VG1gzbGhVtYMwMYy3W9rpx8Gc L6Echx8G1xU0FDubrFDvzoi10IhoMIWnDU/oWn+LQ/P6xa5yFYi1QhqnaERdoUaCniIiIiIjP+Ii IiIzkRGhEREREyFE0LRNie+WpWoiKYidqIgxTWMq87FNREZNgplIjuI7SMk2di6IXlPl8jMvkGjv IvkToZBjIPIPhhMIM1OyEyFxoGDUy+FO5xB1BmtKgZUtBoM1o3FS1wthOzpBML5dGfaZ1gmdZBw0 XjRePbIdZKhEuwXOoSix2ENSViTD0WO007vTdX0+6TWdwaNlb1ZTh0HoPX4SmgzwrhEn60E+jW1S bQQb06rRn87+p3aO9/xbq2p3dTuxDDq6un+ccw+qDc78JbzZ03P+m0Ycw+nMVPU8fWu17Xf/fBhl /dL/cMMj6ur90+7ik/4InbEpQL0NX9Xqn/XS8iYYNGXCETi4XV6+v/v419XX4/r69dtf+lpfi3// /696/6+9r/sRQIm9+69cETj9/2v7/8OpnKcztz6upfX/v9+650Jqf7U/969Xr9WyUDf2NJislA3Y 47UEK/v9YzHQj2nurKErr7xHasarj4/aSt6UaV9Bm6gnhhLXCSC12GEqf2wsaU9tfj2FwQq0rbXt LV7/2IqIp02I34WxtbVwuTc4+WOcc72KBmC7HFMeDH6lqFSxHCYp4qdFimFQ447QaGmELVbQtDCr YITihCIdpoaDCDCEOLzdGs+0IXEQ0Ii4gwmEIMIREMEIiIiIiIiIcRHMhCIiIiIvEEUy+UyEEe/M 1RBNgUQ1xNuRrI1MxFRnYhF8uiOkzsSR0yNZCZC87G8hea4vkJBBlSggyIi+QnLczy+QmFQZ2hEK 1Xs1ioREZ2kwmp/NQhqgpKhDsmKSisLZ1CIvGSwdrnT4Tu5gbTIvWZGYiND3CcsdAhT4UIUEgv7r CDgqNbC39X0prfeqTdOi8UKbPqjdX90d+i+ra08737zvunP6T9ujDnjT1cJxq0ZyotvijOd87nej OVH+7aHedzxW/96W5ODx1ZW8wEgiPdf3vir13f/a7dLb/Vdf/r//wl+n7f7f6tv6bobvv/26r/f/ fRjf9frzDlDH6M537f/1dZ71t/s5/v9vghX+co/dv/U0DG+p0NIehxvY7b21bUnBe99Ub8f/760x hTQF+21sLxpNX19z+2vw3e1hpMVsVxvp8fHxQMwQVzOUOU94qI2MGdqFERXxsU109RTFNIyE0LVc 3RaFoXcMKci0Ig4urC7QtK0LiIhoMIWnDBCIiIiIiIiIYUyIiWdVURluU8RERETsXR2t5F8REbQi TYqyuswIEmdqYllUiuBKJA0V/zsTSlRkaRUZ2OMhSCEZpkCIqIKQ6yoi+EGVKJeIOCBlXkJybRkI ioyGdndMheQqJwwRESxl8p5OGp9HVWahEyUQQcJS6M9M1BJMcocKQQgNbTJUEIfnT0zV5Tj2n9nZ r96R1CLhCmDpNcLNHVGr2qNbVAhFhzjhq6Ndd1dGtrYLr2E63TzOTHzD11ncO67muk3U7vPqt6bm 659T2Z4hhoER/pufvv0+//WyXt9WoQbqeGQdO+0b+GG/ukGkn92Lv90hi1dwwy/Xauo99rb6O54y 3WkR8EU8nyOPNM2i46/yJ5iI+pFQmNOvqu9CIe/8f//136buK7/+uvX/ghEWhGmh/b6aEYQ1/+vt Y9Xf/mHCYj/msF+EXHqvdVBFD16Mev3S+Rj7/WuZyY990vvVz6JRhJQQqz38VpC7rZ7ob80wk3+6 2cgQ0I38EK7fMjORFG/1RFAcZ/0IPrGrT9QwnEFN1Y7CWFc+gZ+2kaAvn90qiC2NYaUcJqGF6t19 6+wwo/63WoxqhwqzpbG1UME92Pkh8Y1xTFKQ8M20oRgzA8Vf9rYoGYK3uxtbFcL6RusIdDHYU6KG 1Cwwmpv7q4tRoaHDCxodoWE1P6oRdpoGEOIMIRwwhaERERmREYiIiIiIiIiIiYU80LP6ESMxGWgy RXW0mIiJ3ApkW+yTZJo7PkrMIZCs7UMxHYlmoYUg8lkXyIiZkRxSCZJ5B5CUtzIirR3EYRUshWQv ITOmg0GU7s65hlRnUIE0l87JiJoscqFYXOjTQyLtMjMEUPOnZ1EppppkrFslImp6hhFu100zUIqL hzrOnWfHCEdbq5oWmCEa60a3q4Ja/s44dOu847WYcofTf1aN1XzNc73pGe1Pjqd3W6N2k3oz+SH0 iQ63xBh03O+6w6MOd9CD05LuzCI8RLNxHJehrYzQMf9WKvS6M5UX6HuZo3EdddzunIqyPginzvcn i4W3YZH1dd0l639fiO0Pf///qv3q2/9cOI/1u0IjXb9tY/r+v8W/65GPfu9Gc44U8Ff//767XVW9 r1/77/z9QoIt7ret6/av84Uf9q2c36Ecb9Y+6vS3wQqznehn9t1T+jI/jumdBh7Sfpjr86BLUdVs JIdhc+vvqgrasav+Thja63a//+vN1LtY1pbbpWGErOT7FZOGIv2Iw1xVfGDNWy1NFLclDHxFcb3s b+8FZsMMUO1HNYJioxcMKf64tMIWmhxadnQhpjQaFoaGhx2qtoRaoWEoiIzIzOU8REGCEaEbOiIi IiIjOQhERZ/iNC53TEdCIiIiduJEmeV1GdlCIREsIk0QiKjMiIvkuihEWyWRfITOkVZFGFIPO6ZK 4vlSyD5NoyDyRGJSIRrMxkpytIlGEDIyL5UZF9M1O007NQgXOjCDhknWv0fwnmM/yxzk524gXJYl If7IfhCM6SB1an8lWR0E8/phftV0aHqq3XB+t/zW9VhDquEK/rcsdatO6oRSqjY1v9boPTou87+k CI8G90d796T/59Z0jyRuzvte/8Jnx1O779Xfed79pIz3W7NEqCaXfpwwb/5pmAj9fXFmmYCWEHQr vO5328t1hG0CKdO4pOkul26M5Ub6/ycMNoF/TmgLplwuP/4b9fTW/u261Xrr17rhMIR/3727a0u2 va+oYqv9L//8MGqv9TDlPQ+mI5nKcLmcp+9/vvr/Vfr1Q/bQ+n+Zy77f2rOjU/2z2+uuGwQ/UaEP 3ukIjQvW2c71/NAxGf5ODvTGk9L39r60LkTDHpNpLYqsd9RSgwdX18/2woZubn14ihsaX7XvtdYa zdt9G62lel9xHa+/sRurgzKQj/4quSHf8fGDO1CjwZlAprYr3jd42I9ZyE0xQ0Lo3WENB3YQ9YYQ tIY8/wwha407Q4aacWh2mELQiGEGEItNCI0IiIjiNBhBhDEQYIREQwhEREREWU2PES0DEMtCM7nF ZjuiIRGsjsCi+RVEeI+bjXl8l8q8igYJeITIiO8i+Qma4vlSyFRpSutI7Ssg8hMheQtEKkyB5UcM gWThg65hmrMNMhpUyKmYNdCIwudZNVIfkYlOkmF9bBejCP8rqSs7NYuyQzBlOIQ/yUBVJQFgyM7W GS4umqafdz29NbRMdLem8zq3OoS7W9XJSE9O6eqaprfaV1DXdlOGFng16QIj1TvpXVtqeGgRH3YU 10CI+9Tu+ps11SM+d76BF/S18yT36newp4aN3upu6N1lWHviGHOOYeNN1TdLd/T0r1403Tf7mmYy OlGr7R3PDqtfNAxS87ndkTzBJO066t9tVdIac0zER1+RVHFvYhvycMBhkfVp1f/pzQMPrpV/q+lr 6oR7//9/r1+6aHdpX9Jeq39OIxbCYIULu+qHSt///r////+v6/X39P8zljlP//qWPYi2vXX/2uv+ dMEtZcFDlRCJvu//q/nRCG63/7/70oz/dQQ/4/1xF//sYR/+CHelfwzmCFDP9Rn+uEEQweEIuQxQ ++2lHsaS2ldMa3pWFvWNJe+rumlvr70rursGbo1Y+KCx12RcL2RcLEL1hb62rQWl9k4KEBhaCsRs UxFNbqxQM6ix6sR+xHsdb8Moc25pXSUGYH0F8KEDMnvC+KDFMLDSjg4sUGthNNDi7WOLTCHDCGho Wo0OGtn/Q0zrKnCBOPWLVCIiOwhENBggwQiGUqBCIhhCI8REREREcRERERERERiJ/JsrRNlPk3Ap TIZlSRC87GZdF0mSojVkIzEduMg8jGR8hcQtEUDB2IyBjNWQLOxXlctzKaIPyCxWchWpri+VGQmQ eQkdEXQIoepB2RPKNCI05Dh9M6NNKyVippZhGaVT6OjT+YR/OzWLsljCnUJBsggqf5KOzWKFzWIa hCHXoRHZ0CL9I1uHTo19NXBJ5n6aaLh6en9PVMIaw7u/CJP7SCX/pfzwbO3Lct3V03U70CL/JD+p sfXCbfand/9qd2qNyngOXBnde4SdHe6yT9+f9Tud5Qji7NpRptJ6Dur70t12jOnIrEcKNP+r26Su diAxVr953PHEQ3Cd9/CLiP87nhozrrM2XCeRNlwi9phCoj/6b/X69fVtD7+vdevunpLr+6//pa// Vtv6jevv3//77/+9d8ijmH9RH6FfoyOI+t+3IPV79fh7//fphWpu7U/39qfs6Pv/66x1dbvzkb3d bvSru3r/ZysEF1ghRFAxGY/X9/BCh7OgUbv8V/tbCVpcNKGk0rpr666gzc7SRusa/Bm7HXfHEK/6 nh99d/9el+2v+wwkxsYsUx6xFcV7FVsb7W/raXYpKCYxBnCzjIMbEex7GDMNZGq3ihd6YppoNMIW g0Li7Q0whccavjjzc6rxB2ENDCaGfeqERDCDBBhCDQiIgwQhhCIxEREaBghEOIiIiIiIkFyOhiOQ iKlkoRkCsIQ4moQlIRMjaKhFQiERUIEGS0ipRCIhEQmQvNUXiEzpHZyKiNQwgyF5Us6Z2V8rraO3 I7yL5T5jIXkLRKGYgpCaVkmSaqqLdhSWCBU1JUInmoSj+maxE0X21U9nZgWFTC4T1T3JxzOUMzhQ MjAmQ7IdZDrQRnzQwp0Cbqrr6NbVGx03kpE7CyupiIuGuv9XdDSzDhrXe/pWk3NlL0bM79G7fTo3 fSfX0Rj6wnnfc77eqfz+jdc/tBhzf939/p0hnc7yhG0R/NMjoj4WhS7oX1uhp6siWYyPpTud7dTu now53q2luvkSR5Aih5FEcX4sbtxiG6EnDFfv06/7YTQikIj/fv3+700Itdv/9b1/1vDCEYTBD9R6 r9fX99/3/9bQ3SMd9dVIo6/j//33///5oU8FGMzlFh4tn0jIggUUThgIf/Z7/FG5zI2e76bOf+2c 721Gbr+v39t1fVvSGf4zdtYeK0MQRDChfjpKNtKP//jdVQ5/w10O1tLv+f+37bW6vr1X7bS8+jqF z6hIb3JOEyUJlDmsFwwq22r9KsRX8R7FMdex9vFeKY2IpiKda2KGLQUXBSxyh40DQg0IuM6LFTdG MaF5vhqf76z/DQYQ0NDQtWummhcdrZwfYQmeL+IhhC0whERBhC4izoiIgwQsIRiGEDBCIiM7lRGb oiIiIiIiJ9CSzE71xiJ2GsWmnLQfCZKYKdkiWTfghCZE0IiJCIp2di2dGYjsSzv0asjWdzyVxfIT CGdRoZ2oMxghkJmuL8rqWdnJSeI6BFD7KXksy+VJFRqgyEiEiiNmU4vnZMQmkCan0p2ahFsh+gk0 WOERaJ/ulCrU9pzOUOEhEUpfP5KhAtkqENQhKQgRbs6bmoRNMLTa9um6q93OENbhD7Tow1V/o1tI RmH1qFXVVoP2tTvRN9aNnRn/zZQIj/vn0k/XV/O+/05CJz6pn77ovKBArokOkbs/6v0Yc8aSDcEG ldIartzPN5HQIofT1d/F1bIQUDI4RLYZdEeJ2R8joIoeu99cJkupIdj3/Caped70Kir719fi+/79 oRG9/tf/HbxGhER19v/Qca964967f/r9///6H4vtUmsznr0jOcoMP+F+tD7LrhzDmHC3Yjb63+38 EUOyPpe+vZ5fZ711Gf634IVQ30NFG6oyc6N9VerdhpCOr2cv/85WbbaxEdt9pBKLhhKOKWbvk0Cu mtZ9Nhc/3w0n99c2bSxbc+m6DN2NvX+OO0qfVjXY91f1qIoGYLBhOKkY/2KhkdF72I+8RkKUMjnF O6xFbHqxQM6jFBrRoKewp/jVYvMphPGGoxFpCMdha1GLDQ83Whqf83INYtDuLjVCIiIYVIzmHjji DCiMyKIx4aERERERERERERFxGVPPNDadlTQlmCEIiSkhGV1MxERLdbRWkSzMIjMujLSL5Csg8lkX zpHECZpEazURVMg8EGS2L5UZCZB52J8IM7FMhM1xdHZ87G8lORvIiIyL6phVC2udIwzqs6K14jo/ nTVBrzY1zqFOgUh+dq9YRN2dpBDUIFs7cQimT5KO89GoQ6SYXU9a2trdpp3etshB/7ouL6CDhdJK /fCBtVXVb3XXTW/0CI+6BEf0CI+9Iz91dAiPvPie/4Tfrc77mgofNnvuk6N1G7O9tG6/51zyd0Yc 46qd873fqvrevqt9+vVt3+9yJ5slM4wE3X8Xdun310ND/Q5hF1XphO9Lb91+3Iky4T/9f///66v6 XTQ9a63FsX/X+qX8RH/bavuv/sGF1//f/1Vf/xj/+Z/M5Q+//9QRQ9L+9//7of7+/hDan////rgh QIf96ghuopH8aEPl5W/1BCoj5hdnuz0+sM5znYIdUv8UvpS3OPG+9b1vSil6vSdZ/1aWvxHqEjqF OgWqxHHFX1H6QjN3v0r1oftiKYimI3UGYuZSEcMJeDOoG/+xGkkDPsTO04/YivyL7vsbWxFNONNN NDW7TFD7CFx2UjCmBmB/OfP2f7U/6axxaFpoaEMIMIGCFqgYQYIXEREQYJoXGIiIiIiIiIiIiIiI iIiMs/oyLcshbybKWdiSMisQ7gypolQQ7WkVLNeXyni+QmQqNeYRTkSMgQzs+TkR2p2kI15CMxFP l47MRfldUzs6MI1jCDNWSeYwQM7FMl0SeFNcXyni+E7U6RiTJUIFtc1CEqECaaeXz+p2PqhGmp/8 JunfBO0wmp9BPTzowgynFluUM4XmdkoucILO1YQKuuoVXRra+jW95oSNb1ptcIECT9eaM1vTXRs/ YWEPa2kH753O7SmygRH3R32jZmzO/Sf+m/qfGk79c77q/c77SbSd+d999Iz0s/o73ne6XvZy9yC0 7nekNN/ukNCvff6v2KvXb7pfS3r3p6u396c7Lo2iOuq0ZzvY//+yI62P9fb9f9+vrf/6q+3/99/r /7ukl/goQj+329fX/g/S//361//+oj/+roxof//X//VC//f+v0awT/+9GOGCKcjHU4Slv/Z7331s 92e76vd1KUGPddbW9br7/rdK3r4z/j/6H1fW17iPjUfyJgvarfUZEwXdVbUGf9pVDW65utpN6TEf vSh02s3b6bS9pf8+r6vSjUHkhwrPbr2uxFMRrsRTFexnZrsVEfxTEVW2I2OK9iKj+l2OLYimIqMQ aGMaFipj2mEz/nItNDsLaUXDTQYXpppp2mhxaGtppFjkY/UQ00IMENC9BggwQiIMKZEREYnZ0DBC IiIiM0FDxFhCHFn+IiTCERERETvFEYQuIiJXeCZXUMrmEE5aCnESXyIiUxgirRLEZCpEIEOgUg8i pkJlPkVzpwZB5CZ2NZV5UZ0CSutI7girRVohEQmRQz2dima4vhBkrdhBrZrYTCZfO6elBGoKqnvM I/msVT+5qwRQ81CHahpmpWqCldSVoO1TOoR7O0gidp7ow7qYehrfOgrQ4Q4NToOH1XC6kLwhGumn 8zUF09Gv3rTapOjW4VpA9U2i3oER9/v58//6JD31VG7U7vd8+vdN/o3adG6gRddN71feggaIN1eu rZyhkdEd4b9vf53h7cim87njQ0r+aZuBFD2GRy7q5ojyUnRzBFDonRtAin4r0NLfrq/vQ/WUoMRx xGPH//7pf//vpoRxV99MENMIRhNCKev79331Fb/10phwvjiP7Q4//rVX0CI66//v9/9al//enPr/ Z0Zz5waHnPV/dP+4ZzvwQxn/O1CgrggPqM/xn+KN7s5usM57XdXaVpWsY3rfvufR0C7zdBm72lN2 aDjlD9uo2MJVrZ9eGl/epoC9pHZcMNqra7HYVtU2Ip/7OVp19ddsf0Ih249rBmCdhhcocvcD/2vY pYikIpooDDFTOUOUPa+SBjjRi0kNR2tp/Fqf49C6FxexxoedFqZFpNhWwqEWgwhH1HERERERFxEa tTHiIiIM44QiLOhDOREREZ/s/xFlTxaaERERIViIiVxCEYiVyRGQNKRiMIyLcIMl8qxnaqzEQmVC lckRhHYllRkJkHmR2mVGQvIOUKE7IXnSLmdkxE8/p+dezWgsJ2dqOzUEIYUh/uddSVCZF6wQIjy/ pqjQ/mt034IcL+FSu6vdX3BLQIj99TvReac33pPT7+d97zcps7nYkqf0bv4RN41uvuQWhD+/VkFa /ozlROxq+/0LvWE/7oTTMBX0C0vNcR0UAv+v/f6/9Lwy0gVV/8W/+/09dP/JAf//9D6p9V9uGOv/ 7X66t57hFDy+FYa3qiThzkdLds9xH3vqEK29u3pAhsM5KCFd5OGLOYqHQiKncZffoItAfxqKHz/b UYYSW9Qf/RQGDoFxbCTUf1hi4jhNWrS86PxTFAzBMY2IoGdPQQM0hAoGcLjgzDEDtCIuNT/ERw0G E4tfmRmBprn+00IaDCEXERGhhghERERERFxEm1MYlkLcVIKjsacm+IkZXV5F4qhnUISaJWZJ52ky +W6ykjXF86u4M1xfOuQmdiVK61nahmIg0gyOiOgUyA8iSJzI+R9SE7JiTTVNSFYXCDVO+yLM9a6n 0p7o/yuqCnZrnrc6tA2IjOyXz+a8joKhEZrFYMjJMIuGjTZ0rRob62mgknrCeQrC3p9/VfulkI9f CEczoKg9On/0n9AgV0aBSBF/p5nb3O93f76NneE/O7my73rTPlEY6ZVh1PGm6fcl3VqStLX1Crvu m8in/t7030n/6V687LER5X53PEUm53TYg3+v9fuaRcKRIF9O99f0m9XX7W7v4v/1rYghHf//6r/r /+YXv1Xm/eurb2DI+Rz/Q4pDv///x+3/50wk9b74Ib2qbU/50d/+679viN9dfZzKWGLWNJ6mRX// 8IKNbWOhdLH77VYjdNWGCsNjmHJjgiPX0jdm7P/HTaVLaus/7bVtbb4hatpJsnAKIrV9iK4imITu kI7Ee9f1BmUCnVj39qKimo0CDVMUznQaFMXqmp0QwgaDu+whxxHNz2haYT0Ii0GhaoRaEXmPERBg hEREaaERtCIiIiIiIiIiIxJtTMhUjsPLJqi3BVzs6O4MIMiDJWEITOxvBAyMZHzsIRUESeQiOzEn K6lnaDIjL5Vo1xfITCkJkJqa4vlRpou2E1NQh2rETSu0wpGGE3qfQQYWzWiPhVzWICnTzUIdQgXN YiNDQQbmhzqKz5V0aKNbNQh1CTv+mi4q4QjWwoRN/qq2kk3TpejZRsraBF1kLVWY6ddfvwm0CLrV He8/IhaKkgS+0bs3Z3ujucfTq2kGyXdnKhII6EgrO1h09J6e9rc7nejwVGlvdb1fO54/qKYTCJxH 6Gh/Xf3/2P/v/tP639vX37/6/2v6egr///bX1/Xf68x9U1+6Rj/9v6oa/X7v71t11t//v3T7zhGe 9s9u7aXv8Rf/+/dfdd//1s5O6FmECHDNyZh+r/a2thRyMDAkTDAjDVY1Hhr/3asRVG7dNqttrfUY jM9ajJww3pf2k2Em0rPaqhGxU58R7G8V+2OIrjYjXPEDOErEVsYYpioqOY9nRwwhFRoXDCu00Gha YTP0X5/zItDTCDCDC2hEZ0RmRERiIYIRERBxERERERn+JNwvETslxGOInZaSkYlk3E0J2JRCI1Il whGEdoUg7cznUZCZ2TSRBojCIwjsUpXJEYR2fJdEjKTCI5Fh1ZwhR6apqVPOiTItn6aCh2QvOwWP 4VM6wTIuz0EGkaoINNM7J7wnZ24hDYTUvn9T+mRZnoi0fyJjIRpmsQ6adGoJn9Gm0aw+8IPxdUHY Ik+fH2E+wkqo1tGt/XWk/vVGuE8IO700t5oNFfp6/dAiPO0EE6MO8JUr0jPnhujOITU7unSfujvt G7oz693puZ28zveFO9GHO/sabn9f6tku/4TeIIssKHKHKHKHKekG3CLiNX1at9Ne+3Xv90hqu+r1 em9BNuOldd+k+Lf9eZxcL6t+EIiI6b0v/6b+kv170q///ba+rft/v79fwwX7o2v/2+DkOP2+H9fV t/nO1+jHdGMKXwv9/2IpD/b9vImXr/r+h++rtT/BDdvBFcGzo2/GYV8e7f6sV37+EI76VnuPfdXY 7dU46/BDtYZuRnMPjtcR9KGxphh3sNjnh22tLBscR4VsLwwkrJDhb+OlBn9o3bShu2x7S98JtInB fF04j9lDmwJ3yOF93wY4ppXfa0I0IwaGxFK6/7FO9uLS7GDOrFSxyh77OdKOLi7xI1VNOIOGhYQv OeMJfvN0aHadp3DTi0NbUITPERGbjvGhGWbHiIi0LOjMeMWhEREGEIiIiIiLQiIuIiIxERJs6lMg uRzlda0OV1JYRIeWkCqnlrK1BBx7ZXMIm4rBOh+mQVrffT23s99WuqhrK4ID7iMehHgzNlZPPcR1 GWkpZ+LIfPGVxuldbRXqzzIuj7UINU6ldUEVBphB6M/R79dGjU8XpvW+jd6b1fV33K9UXC0hde6u 37f/2/++revP+76tt1cNK2KH9nKHFNxsRTFfjYpig0DCf4MEGEIiNG6IlqjaiMjaY6IO0kotIzyy COaCh3K62iuBZC1+LyuCaffuEF//EEW0x/1JsLBgsnAv4or1BgiYLrw+uzHs6II+EmklT8VDZ0Zj 678N8e93b/Q979r78hWkZ1+04iIzNPhEREWo////5aQEoyA6KqP///////////////8gKUUf8rhX 4///////8siWoyyLahKOWQk6CpRlkC1GWQEy3NAThnHDhAhLdYIEUjCCEEYdCbQIp3CRbgiCCEvh COElI6MJBGEYKUOccococKEi3E0Xy5RD0GymMSLcDC0jOEKKHCGECLcHkcEI+FEREaRb14QmHLHC bZTA2CCLdGRwpHaKdCIk6MKkW80hTCEQQJIYQRbmqLgwJLtIcIEJC2iBbCGCRXJQ0CVGECcdFdSD OR0RVAinYwgiuVhgjwkwjHwywkVIrigaBIppqIjCCK4EDBHRBcIIKI8rgwYI+JKER8IUNBFfTI4Y LwkaRHzbUMpwVSv2RwIFMuSiNIyNAzkVR5FwpHU6bDoyJYugRQ5BByhoqwSETDmHCEaRkFBnL4mi P5Hy4IFlOWmxTMhaLghHFE0RHRcImCck5Q6ER5kXRvI4EEfBT6Lojsji2zuUOEFggoiI8yIyOgQi RB+EDCC15Q5x04iIiOztKRHyOiOiOGaCEoc4/ncIFEREREZNilGER0fR9E6Lo0TDOxRF0YRcG0js j0ECQiIiMt0uI5GEXyPEcORzCQSyPggYJFyCojHIQcmOWOcc0HSBlXl0czeXyOiPnIvl0XRHiOyO GIiJDMHJuUOEIiMEId4bLo2grBAlQsILKgILCRxwgtIqAkUOd0hERIGLIVyuKHLtwaBwwsYIqNXw kU4lDnHKHOOECEkORjlDkEgp0IjLdUFERERERERERERERERPo2iOjCMZHyOjER2R0XyORHBAQUQY iI42IhBBNhYelYiTHzvidyhygGCkuWBCLgwj6I8RyZQGVBTy+Cw4g7TqlQSKHCEdkdEczCLo2iOh EREMER/I6I+XiOEI4KReI6BUhERsRERGRw5HZHiPkfLxvLouhiIiIkGkcw5Y5hwRHQiIwZQ5oKHK HM53s7mH0saDWMuKbMj5HiPkdFzMIjxPkcUuZHIjguinKcsciDkQc453OOVB6wQiMREREREREGhc PLeCKHSxYQRH0yPEcKR2RxYQWZzjlOCI6SxEREREYiIiIiIjQcMpygEjQREf//////+ACACAAKRz DljmHBEdCIjBlAplbmRzdHJlYW0gCmVuZG9iagoxMCAwIG9iago1NzM2MAplbmRvYmoKOSAwIG9i ago8PCAvTGVuZ3RoIDExIDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAgY20g IDEgZyAvT2JqOCBEbyBRCmVuZHN0cmVhbQoKZW5kb2JqCjExIDAgb2JqCjQyCmVuZG9iagoxMiAw IG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1OTUgODQxXQovQ3JvcEJveCBbMCAw IDU5NSA4NDFdCi9QYXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0 IFsvUERGIC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9iamVjdCA8PAovT2JqMTMgMTMgMCBS ICAgPj4KPj4KL0NvbnRlbnRzIFsgMTQgMCBSICBdCj4+CmVuZG9iagoxMyAwIG9iago8PCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajEzIC9XaWR0aCAyNDgwIC9IZWln aHQgMzUwNyAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEgIHRydWUgL0JpdHNQZXJD b21wb25lbnQgMSAvTGVuZ3RoIDE1IDAgUiAvRmlsdGVyIC9DQ0lUVEZheERlY29kZSAvRGVjb2Rl UGFybXMgPDwgL0sgLTEgL0NvbHVtbnMgMjQ4MCA+PiA+PiBzdHJlYW0K///8suKJbSoo//////// /////yAuDVKP///////////IDg0qeFH/////////8myFHymBPj/////////LMovHkBAFx/////// //////////////////////////////8rkiLo7HzKFK6kHy+fwUvHa3nahU19c7VBEzupZqf4Ij7r R/O3wTMkMvnYkqV/pN8/fBCls7VwTJuJPT/62o36BEfdUybhDh72I/6b53KjXtTu97YSfapu1W// 3gg1hgoZv3+e0P2/0vzfcMQn2I0Pf/9fTqwh2uf//q3X7mQGBERYU//42NKNdpPi7ji1G0l/Ppk2 hCIhhBhDxFdwgZXAkdpMRG9qV0uCZ2SojojxCoIGQnZVxKFOhCJaQorzWwQjJUJ8MINMtycIj0nU KQr4aLHbZkCZ2JhSvaldSRdF0tc/5++dw6DcM/qf6MlppldQcIRH3iokU8oRvyDgw0nu3VGkaDsy Gkfv/rhMIdsMj9ZKDS3em0wg7OjdNn07mNa1Qv2Nvs5TwbINUix3vdU1s9xG1P9oIm69b4xq/oP+ KOwQF48fEi4w9qRQj2h0rleru67u1qjH/C20qvRl4/X8RBhMoiz/fHhWxwhRvu/DI7Ct3xERGnGq YVfZytYjbdYiIiI0hsVBEfiKlkCERCMhRlbQ7U52GFK6mEK/VggZFyTWecMLxhBmSXuynp2QXMMh fBBTKmIi7Wafx0bKNFNfCnSLtAyBZb6oR0/k+9XV0gRHvMQImP02DIjBTtXF2ZCUYSZrzCq33rvu Y6p/TMYKHqd3PAMIaphCNOyurMyF/r+///ZEgxtYROI+46JDpqd3LHQWyunaZkJCXVQlFfr/q78L S8IFO9/dhTZne6E8Qng0gQ/WI/qbynqvD2/SXbS8av9GdaNBnZaRSrEJqaCnKdw0lYrxeI4zC0lD v+vuv0/TuMNAzjEI7Gz04XXnesdBk9P3X//3ttx/aoQ1tOzn4MbSnalr+xr7/7/xEQYIREcREHHQ hbHra+l/aXEkiEOLJq0NMUxHEbHybfmVNeCEWmqa5XU4/ncChBka1ITOmdkniGCBgpzwYQ0HYW1I swpOGLI6I+VLjMg8RFxp6LujQ3CcJYiRRQ/PIOCBlSjuiIVDnu8IPTm1zOKZ4NdtXk/nURMlQRMi QLnZJl0VCK4H1h+PpmmbRHRHKmENPPh4vgw9UbK9BbOqsLw//2hH6Vr/sN53O/ubPNBorp2Fu3tn v65GPWjf9N34NitdOkOKTaBEfb3BAiPbjQ4ixn6/3X+v237ndxcJT1/kFjuiCTlqp1hv6vEetrkC DAJG1/+q/++mEwibxGGg8zlD5qXXYatpNNBAlf7Wz21Nz///QXEaEREXnPYhRQgz7tfa2kRQFx+1 /Jww1/Ea2g1xuxTH+2lelTvHLIYxERHFoNTkR2KYjBm5CM7y9Js7OzLWc8QwQiLTWODFQgzsFDB0 SRCZ3iMIRERacPRbtQQanVWE1KjIVkXxEG6CDzQsIK9KzUISkREEkVHLlVlwbZzlBRstrW1PjRoE JXV1Vh50gg/O7FUgWJaohexSeqfQIv6MOd0jdlwZ/rTYVT+Q2Ezsnnog4i8d6R2DyhD/v/pbrboY T31O7p1de/OoSj+dmsnGZC0XvXW0c////cyVhj3XRvVu1O9XS/W032t+qgh7Vf33qvv0L6STb87n ffU8OZzWl7DStYikr1+89/zDk3v/3a+vr7/4u877sbFWDNugiu6juuhB9Lvc+kP//bh/+K72E1Oe 7ux8MKPxq2EoME+OgQ/0Nf6+IMIRphC1P9itWko0NG+0qT/sVnYjzi9YiIiIMIXHDClj32lBmCbW f+FiNvqVzLERFo+hoWneP2vjWVyVhTuedred3kIjCERGhDCHGFNNsVQ87VBCFQUvhUzUjEVeSvL5 C0VCMiuERFoNNUWOcfqSkIum4TTwuSoQ1CkHna3nQKQmIjhC+jdSQIj9r1etqFIdrSndEQvIcZBC MhT4lbZcJQzud9boz+kZ+gRH3RszX7ecbnY4QlImezsSiDs1sj5Usg+ynM5GQqvS67f9d9WaBivI hpNJB9/0kvOyYTZT1bJWKdO4fp7PfP/f///1/3GhfOy0IFsui8To4lRnO9En+k46WCS8G03IO0li 1H7Pf//19TI//focRhMIfXO/b53O9SdaBF/kh+53BpO3j+P/1v4//3s9ueycMTDlj6fpW12/XycF 0+lud7vgw6uazxr/2sRTGrQX71GOOqE9zjFP/vf0N9uv312/ZH16b7P8an+LFBpimtrYitQyY4X4 r2///zobH9P6qE/XuIiIhphMIQ0O0jQU+Zzj2EOtnJ19f5//+t1/ghQRO1pfyyGMRERERaaEO4vG LvFcf9r8x7Fr/nZqO7X+pCYiIioi4tDuxj/FbGDNuYWw0m1eVyRGEXjv47W9ToFITIREUzupMqcR EWEL4YQ1wtiooaEZNPwWinFCkJ5S8naJFhdZXH2amZVpNNNFpFKpbnamEBEh84SdAnl8/kpE8hII ODuysZC87Usrh4iIjm72kEn9dfWp3ei3/DU6RiKcQ7nIMhIvnZNmMlEVbCmRZnUrt7zud2ETeOek b1N3/Ru1vwm4TbKcMlgTCanY4SRE7vs1svoNDO5x2apMIOPr7oLjcaE0jAR/of9W1xbS4IjyLusz hq+66M7RnPvqYSROGZCFwRTzCCX/1+v+vmbLhKfcGDLqdzvqnQQz+hDc7+FaBEfunoVo/gsINmRA paQuqoRH9xzhJ9N8/Yj8fXX4tdv90hBBJer1/m+z6Rs3hEnpOFGV1UKwvqeJeyM0RR2aSDMQ7h7P b4am53TqCJv/X+0C1t9d+9jSF8ETHjTfQQM+1uw/Y8/oRxH4Z/x2o+/dHZqkE7+6XZ5O3vX16v/e gnXRhzxs+5xjweOWOceiQ//2GEn4YVjQhP/GpOGLOQMno69b910Zyt5j91ry0hdRFhCDrCE/sEUY 48/WKHYpqEvG6qUoFyLr7W6fWI6Gz2sP69sZXUkLsqcRERERDCEMIGCrFoamwq+hTEUxxpLmajmH O+dxmO19aiIiItCGhoWp0ZGITCYpnPgyOa0L7FMNK2/nZfMhTMlTERERZ5AwhGNn7+fNinish95y NZBxCJTISxHoREQ2GhctIXWGFU9EOsh+dOzv4FIPITIPO3KGVhHWO9crgfPIkQiOayookOn/387N QgKQ681Cp2mgZ3Z2QvINHYHKIkJ6ENzvDe+/fpBEo/hUa3B8hdj8lQhD0wQZ1iXlITJXF8p4ujsJ HDUyp7/29/+53O8IER8d+ccw+nIxuyrcJtd5Y7z2mlrrZ3TTwqD/+h/117YQJ3zNlwi062GGRRKN ejd9BB+0IWtrZNPoHBQmWkWrX94Ioet//2v6u91simGXCggSukPdW/PC0CI+6BEff4WESfNEYhbu kWOd6EUCGThj+M6hhqf6294RY/Xrf92/aOuYMLX1/eYeFGrMcEqY6Haqv5nmOh/96CCDhqboYd/0 vdLSof6/v+EXf+kLTTgzgzhD7ntcMbXvranQsfDDdbOQIb6Fvm/mHr/+ltf78RGv3Y2g4M4T8UUo MQvyHBKGEo6tVXxo/vq/pgih/9/8RERDBCD0Li61i8QmKUGfYo0puxH99XpBCPXgiOMwoji4iLOi 00Mns4TP3iq/2I2I6iNQ2qy3M47MsuiWsyLx0YiIiwQiIhoWp0R2mgZxlwY2c/R/WGgzseIPIWEC BmRoxEREQwmFzniD0JaQuvhdGd57kEFUmVEQedqhAgyTzI+IiIuI70CI+6Qeu5xhvZrFOnphEh2R gp2Yi+mVeXybJE9+vpu9mgzvpwvo1uCBsKaRDgvIox2diWTIyFozzpnadKdBR392u+k72e+0Ycw/ tLSdbCrzDg0ntU1z6CkiCp0PqvvpvjV9p/p6uf0yKOFO+xBuCLr4In9VTOzUImkEXz+++h/dV9t7 7e6iDEJLcJJXfXav6EKmzLM6ef9quvrzp2v6hLX8GYcF+EC1zsQD3ulbo3Z7VP/2IqGlP9uq4/wh t1q59CP770rGGJQj0PX3x2mK+MbOW+tWscGE29QYPrmO1eP6OJeOIaDT7Uc1PFAz7JBWh30ShW3r VTHkTDkdBK/X8tIUUREQwlERDWnOjLHsRSFRFd1xDm62bv2MRlkjFn+IszlOceItH01BNP/M5Q5V +0OI+Tb87UwhFEIkMcIRBxEWYmELUkWoRFr1RnK/1TIHF8lmXyoyUJMiIqqETIQoQi4iM/2c9oX8 5ZL5/C4Ts1CKi7DQMqMnDBM4qhHZJgmJG8REREf0qraTrnpJwiY7NYqUHZCYQyVGawh15brWbMLZ 7Jd7873QIj+jd+E3CDhZnyFCpqEQQQaSn0d0zUy+QmU+XypI7BfDQ2P9/6+nt1erRGPqa7Ku4SmC zRmB1VdQtpkHHbxfkI5TVKakY9e1X8jH3eL/q87pxpsVIp845n59JN1+udQiuSkIdQi3Fxn/OB2I pfg+q4av/+rhFlHVrbCdO2e3+d7aSBEf0kldEr/2E2+re/Z7Q9XX7/17bil47ylBhfnc8ab53O9G c70CL+wUL9nsQzdvp21WNFj7rr/UGDj/3+Gt1/3ra99dfhKPG7sRkmoiuj0wwsNbb20r39GCqo4Q czlev/+q96Tb+xCCjjTCFqfruxTFPFMZNILOf/3XJD6HvX73/7f+ggjyz/ERcREMINC0wogt+Nsw iPMMLZ7n99t6X1aq/v91hBLoRERYUsr4tIRTFR9PsR7GxFdr6umqZfWTYcxO0rGEIjYYWIi0wh2t inimIqI4TO0vIVEHlPl+zsaGM80M/xEMIMIaEO0uaHkpCHTsJ3DIFkpZfCDKjITIRHcMi+RVCIiI iIlWqTeq6Tw9bRfOyH6hBmtGKQpNmuL52txklZWkOn5/7oEX+dw9AiP8J/7RbwmnBmoIFzsEBcg8 hM7oiE8qQQ1GdqP52WxcKaAQo/XiGGtbrf9Qm6TnnVbo6hM7fI6TOoSGtyK1QTzC1vf1sOaMjhf/ Jwfs0yPkdqr1PHDc/qd7z2fNaEUsGjBC3aIPUYcm1dbST2fs/FffXejolr/p19CI6v7F1H8UrRhz u9UblO4fCbbW7rjvj2cicH67BBNT//vm4qK1/9ev71uaMjhZ3KjjQYbnrec+p34iv+Pb1iEP+sdD YQ50br8n939f/17oQ8a3V0lcJ1iKgzKBFQtWIr+vdY/WGbvX/tqf/btrXQv/mRHm69QQvU1Pgzp9 2rQWKJwXvptfoff7PIlGCCRgnMZ3Ul+iziitCIiJMLEMIWhaxpig1wtiNsJW3/6mgYiE+umlHjER ERcQwhGYuciwopqN/iuFn1HuXQVpZbmiP5kMQiIiIYQtDi86MEhaGhFa1U7WtSpZCshMlcV1EIiG EL/sEL01O1Ls6hCfJ46BSGy7JwXNAXCZFYimQcCBlWjsVQiM3ZyMpqqtqrr6WnVIw7owj+ahDoEO 55ri+iY7OppnSTFoRGxBEffRvXzZqd89nzNBopBvTtV1tAgbfkHWkTSKuLx2JolZjBofxsjl70li tik3T/o3Zr6uk3Tba0f087VpTpGJO/8Ri3909Ot7XQ0H0CLrp65rM7Z4Nf1dO7TRoctzPUwtX/6/ t+0/dylBilv1encae9Gf10gRHkm6EEXM7BAxZynRWP/roxsRVja91/r6Vv13vVPT6eo9ToFdbW1v 3c9qzo9er737w1///zJYPTnalpelSsNJtJjwzc0M6BPt1bq167VD+tf/MkDg7vzc3amArGxob+q7 Hw1bStd67rBCv/CBrERERERDCYSi1P+bdVimKYqKGGFn+xHxS2oIlgNltVWIs6Ii7TtNMIOxXtBl wUMq2kgQOMmz5hGWqEREREQyt0CF2E0I0xQhqFU7JIvhAyCGdoR3PERFxaGthbQYTISIONcEythA pK8wjWQjQIj7ro10XDNQhqECGhQTTTO6ZCZPk8a4vlRnc0V1jOx3pvggV6eE2Egks0UnRredNYwu axDt3ZKmXyEyDjtbzqEIuKED6XS6t7zDnfO53z/anygRddP764Vdc1inUIdmsXZKUR2qoMJnY+Se YRGZf/99f1t+3iKV1et/z2fM720XlHfoER+wq6cRzghuc3uQQNphb/9d///++t+VsMdjj/Qr3W6M Od1N2p31pOk9pOr7133XX/+z6/fr+tL+t/626H7n7n+nq2aDO4Iv6BF/sRVqtpWlf/2F/6ukbir/ 37/r/+lvtsfe6TuvdfaYimKIqGNj747CtpK644IZP5ufWzl6v/3eljr/1fX63aaax3Y9ioioav1E d9Rt9ev02c70uct1a7+tb8RDBTHbCFqf7QaYqsGcZYiljWNK7zQF2PJSYXjdLW9/qi1FtRaaEREM IMEGEL857U3WKYp2PaChDs93a3W3S3ajERERERERDCDCFqciLsFHNOxTDCjEUxFSbkuRTOqM8lGb iWxCkdojIsQiIiM4S0GmExTTVS+f7TCkHIPCDBAyni+SkIdI3mQeCYz/ESnQYQMIML/39NosdquQ kknZ3PITIhBDMjopKhE4hEdfVr06CDo2NbOok4RZ24prFJzBBwiXReOzXMOwgyrzuiJ8iqEkhL/K f4lPqurq0CI+69OFC9oygUhantTVqnpmuL+EzueQiIT35my4U1wmbLhP33r0ZzvYZzStEY6ShTw3 WZzve0bHv5fPx0CBbZQ7NQp24hqFNAXsR6X///9Jce87pudzw6SezkjDnjXf9/S+quLom7ULVxn+ CZfFG53///3Vr///Hv699P2Upf1P+d+RTwVpF3Rd2eDW4Zv+gQIfutrr67bowPX//9VbfT3WvhMu Ef8f/CJxGEHhBxp7/dNfFNpWlfV61a/f3qqMDf/x+Y+tYj/+q8cUuONVY7UbGxG99ntirbq7qK3f 40lbpQQw1N1/+O/+4iLiIYTCaFio2njpjcJWbfatLNzsLVD4MzlPBFDgzF68Zjs92e+oiDQYJrDC FoaDC0MWKaVrQjBn3P0LhCNjqccsc7tGilGaBVtYiM/xERHYQiLV478mPjxHcGPQ2GlJsPF87Ssg 0VaOudkYiz8hGdF3F4IkYYXiHmcp8mOccocoexULeQ9NNSpMvhAyF5QiOjOJXiIiIiIiIhuEIsEI iHaq/b+eu0WPJSsIRQUvna2js6JsPtCIjnf9W74V0E2nem2dhemduIdzyFRkQZ1lIplIQ1vOwRLu l87+n+ez5nHXuFO3F0GEyESoMj5HQQZ2hEsfrTLhfM2XCt1/tu4pWk3fzZC6Ld4INBMRJhmx2S8E Hd/9dKGv+v7619NEHIw53vCedB0Cph2kG1Ie6Lf1UUb4IUM3MIf/l9V//1FOtyJMuFV/RoVE/Tv6 CbxFP/zDgiPet1gh/tfu//VN2tVV//T31BmB/HYimGF6tb1BDz/X26Nz1j2jiF/KVFwvfwwheh2v QjBmCBhJiKopYLtbuP3/qRT//ry1FtRFxEQwrdinBn3cbtfdKc/VdcvkcdT/BMjj8YjOhCwmFzYU 5Q6eKa794jsuJEY/G2sm00IiIwhFxaFpirrQq9ZIcocFDSqdraNZkPO68REQwoMZj2RBwpzoXBoR Y5bmgRNB2XRmiEyDggZCZ3TMp4uIytmcMKro0aTTIdnT0zrBM7HEOkXZUZqZHrKzkHHSN532ZFCE RHP87mum/+1dGx6aqnq8GRjI5msQ0DF2QiBAyFxpkV0ztaF4hNVff3frqd6Lcoe1O/XnHda9OUEm pKA+Xz+ahIaDOxT+RMF69Lr/f3QQj9878QwegRfCLzPBr1afPjr1Vho3M7LhglaMW/viGR9X//90 lc0DCW2G6roRptXnturzZXdF5BhpOkEPZueZF8xsRQIEmXQSVf//19ZEp/Sf1b6un/hCDDpuaDRC y3WgXGvSwZh6ERghtrFdnldJTI/osf/3vu/uLb/si7Krigm5u/WI89UwkGk4WLY/2+js1QQQfXc+ tddh9rxHr+9DmRF1awZgZ04/6XWNUKeKWLerStjelds9hF31/iIzUiLXYtT9HF2KgldVhhWNhvDC kXDgz/QyaDe6+z6tBxGciO0NNVjU3WKYTuRQMQv6Vtb7CxERERERERDCEWk5hrP+C2KbCUcm3ZS2 YGd2xFnQhGqadqK5bmfd2EGU7L5qRuKjJXF8haITJUyTxEREQYINT/7sJnei3a4TCZrFXU6BSD0G UBg7VTKtGSMhoyxCIj9JXhB0CI/fhVsi1dGoRGd538EyndnZjhl8jojmSCIwzu1D/+t17U7tEh0g RH3+YeqTzOWPOxxEXDXViIwqDC2VKL5FcoRT5hHYFf36dd0t53huv3o9ozlPpuFCBwlCdHffIR80 NGjnuDXi1s7jMQQfWx/r9f/9/ulfcV53O7Vv3ILPPl0m0m+zW1tQnoaLHct1sMa2t/1//qov9/V+ //prv09O9Bho73mg1qcfhYQb02k3T6TGl/6gh/b2pe//0v9d/7b2GXX7Tir3P9Jy1RiluZ8GFsLE dLbfHVHQLbq9d19ut6tP4/0mCKfFr49bqPjwxTFNP8bGGW5Q4JJ/jptfq6frV//QjCJvf/9/0GCD CDCFoWmg4iwVRSFsVbHDCxGPa2trnQUP+RTzf6Vnl8REREMFU5hbQ7FNcUwwkw0puwu9JCNv9O+T eqERGchCGCBhBhO0xTFVwSsR3EVG2FqQvE+hEREMIMINC9O0zTvsVBSJguReI1kHGoZqys5qMlgh To7IhEREQYKEIMFP6agiQ+s9WdAiefRK2qYUEDO3CFDMGZECiIiIwk88Fx/VF30whozuYG0uGQcQ 4g4pIIMlkXRbc1CJvEYTb1zdhX6pB6mtziFO/z1nook0X1bO1qOkVnO540F73ZpmAlDvbo3qrz+k 5CLrf/whBEeoNhc7Ut89kqEIozBFOKdxF8g41xf+vdJr+347sdWE2z3/T71PAT1c77vrC9hVzp6+ N+Nqbv6G//8a+ZsuFur121dd+75s6NFFuUPC3uFvO8x2qj7DOf+fXoxfWk4+k3t3/rX7vku6ahVd CHne/zvfgxthKbn5oC7DCSN2SHdrTe84jtTdCGEKcd6/pb/H3of//Jd3B2K9q+N+NtLPq1HtR7/W 9vXpD/+///4h2hEWpyLVOi3xUWxVnthhL5/c3O6bC+kCHvZ70lc9/qv/cREQwQiwjNBrajYof63W KYjqf4mgL2tFGgYX1BD/eTehiIiM/RwwhFoWhaDCYQMwP7GFQjjSajUYQZ2QjpkSWM/xERDCDCp+ byntKiY5Q5Y9jDMoFS3M4wwibsljL5GIKEGawXJfITOudzQiJCYm0IiIi0IYTBCIcMJwwuE4QNrY IWnR07OivPohWpGshMg8p8vqoiIiI6mek6BEfdKaHM/09UyUBM9EP86iBbBSDzWy+a2XwpKMjSMh C9dXXo3acx1PlX3fS+/VcKQ611wqn0mdUbjs+QmUJMyE+v//Q/Y7b79vOOeN9Xo3UCI+4IlH11wR N+mQ/QaZ24mEM6I/HfwQZAog41xf/7r9/q/++vv7mcbEoa8IER8d0Z9zvsl8Ff96QIjy9J5NJ7Jc IdQi919X9z6+tVVdDq27S1wv+gXXW6W6DCJxF6+qdG7zwbO9aND1W8UsfraxH4IYQ+30O65hzD2/ 1///4W3//QmkbyOlGr/unNpG7NlAiPvaXiKjttJpJG6/2CGNC+e/4PCZfC+vq0nof/9hCNXf39Oh oa+NTotJznsYZgZoKGf1Ru16HbrMOMxoRTfTfXGoIf7df/r7//ERDU/oRYTuNPsU7gzA/sRWDHUa xqMzy/N1KK7OQz/dScMAmR5L1/+IiGENCI0NUPNlqg4M6sUxWDH2ybgnCxS99RHEdnuz3/JvMYiI iIiIg+GE00DtYOIa1fYoGawULjNAXvSpnfTiIi4jiM3R2sQZ94c/2I5NugidhkoggztYMlMVJHEd zjseFxERDCaxGf86LUtzQJCfP6YTgyngTU7HCEKwQZLEQJHeGIiIiIhgqSTbrNbmhyE1IIjaRK8F QZUSYIMl8IGdnRUY0Zzvp/SdJtlW7YTzqQ0XzNYkg5DIcg0XDO3akQlO4zCKcyXRhfb9t6bpx2ez PW8LCcJNzWwhaCB1s6hAnYQYTs7hkeO1vIRFR3/7XVcECSduuz3N3uccw+azxpudy71cER99ee64 V1Ommv+1Q736X92OhV1aem7V921dL0f879W0d9zj87EMobrv/bSV69hvrapddLaW9a/X/il3T+6v cGCW7/tWGs3bW1Bg/fqcKZ7/t/7Xa////X63BiEaZgl8oyOi6W7HFO7FNhIi+la7DC7ax2/fvTit /9/+YT/6hglQ/CERxYQMENNMVEJihYqzkh/q2tQwt1Hetm66ptK/X6HmH/xERYUE0GFHzUvHFCeD DrsaUb2t/fV+NH8nDE5GLBCPP8RFhBpRdnPYrYikI2I2I12vk38QZ/iIizoiItT/a2mnwzWC1pkq yNZrZfNZFXkojedkpiJ2amLiIjOiGCDCHcReje1P+umU4p0jFdnYkrO0kEGd5kdBMWhEaGk+uujW wunudk4LkvEJhBotwyEzpBCKMiiEdW7877SdFuUP0CI9CsIZCZ1E0WO0EDnT5B0EhwjtLyIggzsm jPInkyydHYj+3mcYCLv3CEap1dcLoIN033cEJ2qWdJNFjuGp0i7shQYTO6GgZ2OXe+1r6f/+dzxJ /nc7+nV72fDxc+u9AiPIIN66dGM9K5fP+99UOphyhyh/+uvv/3+5oyOF+un27gwTp6p6eGtTu9ea DR/gg0EXDxqNCLt6V1Z7dL/7y7/uv7/S+P//ggQgiP+/406/3Tfm736trHGthL+I/xn/7+v6LHMO Fr/4tCv7Wk2/5h9PnP36iKtd1Y7b+7r7W1BCr3hCIJl0Ev/6XtMuve/914iOOGgxCRujTCeKmPd1 1bSYYSptabPqI4pbU7UCkfbrYiPWI9rfiIYJppoQYQv9Ri7HFAzBBQpkfWE6tpS3HGk90H9dYiIi IiIYQsIMJpqIsGcmqjp2lDN1sKGf8RUNKTb8RERpxaDC3a32K+ylA8mxqIdqjL5CZCRB5LNlN9Qn ERFoXmok6+dNTWKdPJ8owpfO55CIixnayMREREZvKfRJ4W9wn/rZM7NSI40ySRCsIMqMhIg8hMlZ tC1RvzvftG5XfoER/7QqeGS39F4zUEyGFNQiDIXkLzuMwiMyFMhWQmdnQjcf/xr1rfdVc2t+EHWt UaJKhFCaYUvHSMQQYIMEGEDKETxqLr+/vH/845413+to3LmyjZSbV1ddU7TTsIaZUXP/+r6/9at/ /kSi4WnoSfNiU9DTow5h/O60CBN2kCI8jZnxz4zunU0M1BJbrahq/ghWewQqc/+19u///tMKLf3V OROLhUruv6erV1dZ4NlJtKhHelRQC67+oIU/xGCkeC8/f6mHMP//1/9b/V6uspfjV087nfkY9iMG dPIcbXxpV/oRQ7xtnMaF1bPd17bzwU/6/X//vfdde88hwtnQqF8MUDMDxzHskOF/H51CIett44vf 7VOv/X59Je/7xERdxFqhaacGhrljlDlDlPT9LbSfXV6W9YpXSb7qI/9/iIiIjjQiItT+h5gZ+sdR VPEUxFUlDWwrYXtbS/luZojo4hERERdphC0O04fYpimKnO20mGva4tM7dl8ikRVEJndM7hHZEIiI gwgYIRDCYTC9imKFiu2vl8/kYlOnnZrqamXwgZLCzJYQiIjtMJhNa1ulU6BL01XQaZDMJHVHo7/J Wy+ddBkfKsxERHTzvf/71W0a6NDVBK5NO11PpiQlQZC4hWa4vkJnZ1//d0dzxp2Kne9PQdGgV+69 LIo9GiSnclAQLnXs7cUlTL53TOwIyMyW/1+//8GCX1tb67+d93o3pJv77XCrnbiHYRphS+Qn//Yj +9a/3p9r/Xd9wgqftG9I73d0XAIj6BEftUJ4rnStT/tX1f8EKt//Ws39fX3iEv3of14Q9bo3UZ1o ER9vd1sVGkGbtt9AgRc/V1uvwQ9f0MII4v0v9/Ffoae6/77TG7vGyhzYkuNK0m1iPBDb0tAl8FMJ W//b///33eDCYQ4whoadimKsJckOVt1Gs3QltqhHZy9ScMKe3+/f9eDWIiLu4aaYqZysg0IZlIVW hw0mERUF46opYY9Js5+l+CBgqFSyJMREQYQYTQju0O7FAzlaYoGbcY1Q4j9KKRncm353POxxBERE RnPDC2dENOzOU5UWK9jVk3WepbmYU7HEJUy+pK4wipIqMhSIRHdo7M8RERERhCIcMKf81LFA4v6C royk00zUISqChSDggZIzsXCCIiNOwsWs+ZY5T0CI/er4UIZ1CEPcJqXz6IXmpl8JEHEJkJnYkioQ 4iNQ2ghardz3O/eXdV+a39koCLcwM/zUJnatJmsUhM7miEzrkbzuaTj4r8aXZEs9qgmkb8/r0nr0 kCI+9Xaergp1CE00zp2p9GsQ7cUKSDMRUvv//pghuNCo91f87nfXtnutG5fyY9LdfTUKEnyUhfn9 /Rgr/9//evt/xe9CaRcL3BA1O53+7+i7Sgib6bSluZhSlCkfX176DSN+zyd+umI//6//fFf77bpB PP8FenmzSQjjSz26SjqThiSHNoGbgQ73//RhkuglfO53677fXT+OIROIr72dytmphzjlj2KjiKfV DQqm1DN3/1qI2zmOLghWfX/+hv1vi3EaEQ0GsNC8x92DOpCn+1YirPdIf5OGPwQycMJ57s93/xEZ oKeDCFpqf0z8und2OowZwnWccznD99VN2MEU7WCI4zCteIuIiIiIiIiwgYV8/xcaGayoKHuxgzAz g+mEI8NrYSJSFiIzchERdoRaFqtqpnKf4MbFJS3M4wzueSnIOKfKTJZEUxERERERoRZREQbDCmah nGTStT/nvL5/kEG5Qs7/IWiEzWZlXiItCOdzu/1r/h0Y0yHdkqgmdRAgyFRT5eNTL4IGQmQuOxuH 77v3r7NBn6/dBDWaJKPBDXzr2RMFzv8nBc7Es1GS7O8Rv/1277/Qds1Pf30kbqTe6ro1v6JpXR2k EQYQZUsJ2TLJ8hMnZtGI6f9vbW+/Sv798rUXCTud9PT+jfRn2k+89nz8zlvVGii3ZKhNuNUIpEE2 slNJK1ylERxUNDiP/iKVf9vFf3GvpvxSbdxhBtG7TcIOtPZ0E2Gnililw97u2CHozlR/3//f/7/e nV1tGHO6rns9pZ4NeW5bt7qyQ5Q4U3Z/hm664gzdocb/s96gmFz69ddevXxr3rb8cUZzvGm4QfWN BoR/64ofZMcw4X/x3SFAinDTvpuicMeCKHl0F/vr//9vf3OygF4tC0OLtNYcRa9j2GFaCEbGtq1a oRFOtnt1Mba/f/6638REQwhFoWhqbLFAzp7FMUGZSDSZMdQ0o7ruv7Upfm/91euY+IiIiGFzkIMJ p2KBxYriOwtt0xURv91+/JuZ5CIyKUIiIiLWGp+qxTUbV9qxwwo3yuphAgwQMq8qEQeRmmSeIjQz HhhC0DCnOhYppinahNO7U1CBS/DCDKvO1pC04iIiwmEGEI5ptGto1ujqEVeGgzpqdkiTIPISIPIT OjMRLcwjsTQiIjSenSf0XdAiP2du0a+52pBDp3R01/CqSnMNM7/IzL5TvVrdWaZhEcVHc8YQ1uGD p/VX9+m1tNMlIQmnYXCDKiO55SzORUIhMqF//TQ/9fDZdLfc/3/+nQIj71O9d1tGjnbi7dmoRM7W faT0Y/qW///QvfrHzQMdmcYCfX0to3r0CI+9N0FYWoXuwwt/dDCB/uzyfwib3///tf++nx+vV9Eh 0VCVvmvvYhQwu2v23xfpE0G+kThiz2CKHqjIrVTOcf/16v6/5oy4Sd4bCdOaZhF1pCTrWGojiveK 2I6e1atUIrwhjQvfv/X7/+q/6oRFYTLhDstBeKhoXHRutQlYoGfa0Nr69sJWqx8M3Ah/vmMNTdf/ rfWsyIYIQwmmmFCdrwzJ1gzhPGxFNBY6vW1xr+3vnQ8+g1N2Y+IiIiIiIz/cXxwwmh1BnUCKjC99 0La/Fj29xERERDCFn/tIb07HDCXpffK5lnfxNM7vO6jNeRtCIiDCmsqCh4uLTFDzcx3epNPU9ZfP 5KGXYTyT0yC5Csl0asjedpIWhFxEGELTTQjdX//TRcNT0EMlIpKRDpBB59E4Lkqi+EGVeS6IiL5U kRbNsjoqEIiYQiNffX6nfT+oU6ER2senQW0zWIdGg1yUpNOLTNcXztKSyuFAu+3/0vTb6N6RGPNK IaN2dzw957NFAiP8+V01tN+YedQgXO5xBx0CEJkri+a2Xyni+FNREujCKLX3T/1ft+Mw6dZxyx3Q /t4oJut1bRu0jPQIj7v1TqtnY4jqdLW+wuFTCd52ljzIYKXGEOI/10KevdITn/37/10Nd1/13P6n e4S5nKH9hXV1sECI+jW16Lx6CB3VCrD3063n19jt3/Gv//0//r6ivzud60Ieud+jv53uCT06BEfv 9E872puhn+xS3SM5TyfQYIEn72rnvS1f/vMd//+47/+2aAu/v3f/4ROIr1vtUgQb7gz7nf9WwuLo RG22vocaz9tf39s5xpfgh9f/+Lf9V+v1vaX99cRoaHHYquWOUP4r9pd20mMJQwSVDaW9JK1hm59f 5yKhAoZHQJf/v960bV/EfcREWEIwhM8Wnebo18VFIR7qxGyY4IjptInBe9L/zpkfCoRH6+vrGYTq v73URERERERDQa5/i00DiLFbEVseqEVCjSjq+kaKd1vpAzOUOCI+2FldYR3rncZJEV8QjOiIiGC2 p0WhxeCBnUhsbEeGKiOI6EbYqmdzlCBkWIjwTIPOmVpFOzuxDIrxBFNxcIWUEhhBhMIQfDT7C0EN NCKNQkh9DwWEYQZUanc81GS8S0QlcFMi3IWhEREQ6MewhEeqNmZ6waafM862i7CIXHQKgwgwpBwI ZrjCOspKhHaDjuf6V1NdG6zQWPpGfoJvuhJWJSNFGhzQUMotyhDTz2TmYMqeFIPCnc8RHqO403Qp NN1+r7ufQVGyk2k9CsIVet0yViAp09F7pIOOmbioiCxCsipmzO6LT+r9N/VmcXC/8XO53709Xn1P /M0jP76nhhIIk9bpTqETCZqEJR9+SjMMjMJnayvn1/37/rX/XuLf7xeLHXb6SvO53gkO7n9G6lU7 134IHtMEM7BDh7hpulrnv1voNT83zGqozlDgv////vqtdtF2/jp0Zzva7RhzD/f6nfp/Q4atpRtq 8Uor2lhCsR+//nCUZyhn0P9/XfrH21V6p/ImC+Yf7aN6RodfYpj4YSF1+LWnPr6OgW1tezlQ9V3/ 7aqqM593f+v7+v0voab9M/w01P9ihx0MGYFHbGkwwk2ln80Bez6Y1n+xS/wQIZfBCsbPf96/qsw5 Y72vS7224iIhhCLCEZCD2seZQKio+yPJxX4XvVvpz6KWGP2OrbcEOhOf96T7fEWURGawRHwwmgwg 1zoxFBocNU7G4MZ04te1pfWu4jY+DI52xURaHERGdzvEZIeGCEWELQg+s1lOU92NpXiiUf+qGw3l dLjsdl8pUUuIVlPmEVCESL9CM8iSM3IRERYQiLWNTnjzPdvrdF8/krENInzWKqakLjvuyNYiQmIt iIjQjRmmmroER9+7C+FCbkOvJl8jESCxKovkvlX2SeYR2pikEFO1GJIQiI+v/n76LjOP96vgwuud ZB8MJpndMJlRhVOzRLK4UC/+1Si5fWEKX/fZGHLu63rwaT6L52EW59oNoGQSKzggZTkp3D/9rehH 72+ROLhNwsJrR3vU7vncNAi/9N9Cdx6Dz2StEfVNMlDU6ZuCDzHX7EU/f6qq0qLTxInFwv/uZxgI IN12tPTn/eZwfhCNGujW00EmE0W71fq9nlMe576oFVqbv///+r65WwX80i4WP2m30qbp0ZxTSM+n /GkGbnF/HarFD4IUDJ6M91Py/0vmHMPOmF39fSrxBu+dzv326YW903fYqtfViKrvOizQFxW/WPGh fCC+pkX9ncqKLHBEderf7a6/SW6TxENC1N0Rmy0atrBmBj340sJfEJtJa4xUehEEMhwJBD/f184t LviLTTQcMLFrkYZnKsp9bG1fwoj1Xt6Ygv/V69b/WW5mhERERGZOhFoWgwhhDwQYQvMe1yFMzWCh T+/4aVrEbGk9SusNMrh7QiIiOGFTQi0rigXWxsZOGFpYa07MnyFo6hCKZJwiRGIiMtyn+LjTSs9I 7FQix3DVVIOWDIVl81kRcyESnZo2ELQiIgwTOh0HEMLQNwZ2SCc6vRePUGE7TVSEysRri+SzL9kT yWIIGasRERER1s8Br4S/mgNXRcOCI6z+p/1wncGVAiZfCaDIQq4g2jOVHs9zud/WPO/hPQmfq6uF 0nmHBqFtF84NBnYlGpkeISILkJlQjtIZT5z+tdkSZHCsa/9Akl2t62/8724Ij+0GGixynoER96dn cGjX1c6BSUKzp6nc9Bw7vmMrcEtX/9u7Lrgv94323ImGP0m8QYaCFqvScQ3TboER/03WzqJaLd17 XYhd7Cn+jF/sRG3/rwwRQ+1SX9bDbj/2CBK+l3Nn3denp8awTb4/T+4MmLOqeprKuhGhUznHPDf+ qX/9BedjIuFr6d/0Zyo0k2ldDQXa/Z7/DNzOiSe1taHmHrQj+u+UIIKzy/em//8W/+lytsuEp9zs lWRB9CxQ8dMU1oVEUxX0f5uf31aqmCCi/W1Bk9K0jd+l1Vfb+1vg7Oi00OOLUkCJqSB999iNiKiC 4im0jqltId2/yJhgEO29pG71rcREZ/iLBCGFiItC000wSNBT2mKQgmN1jU6Bar1H320oOTetCIiG CI6EQYIGEgnFw01BMKnYqgZgZgmK7tYw8rqudoi+UsyPkfTJpn86oqSJNnZCERGhERggYQ0wpwu4 40xQYQ1PYXQiKtU1CDJmlIPIRGRQnERERENCwgwva3M/Wj+p6sIZqFOqTJSy+a2XyVEa+SFQZgio RKkQoURG/O96mva3vo16Crra6an/7TVMlTMR2Srf+NNxKe/vTzwa2i87wRH3W0a3qQfU8dT+EXz8 7dl81MxAgZqiSolfbr9XO4hvbVWxSev0vne9O/17utPTraGnIILGcNT6IXkK6H//Ggwv1eP//93m l/rvV1cER90p8bD10yUiEX8yT1fXUmmpfWKdf//X/bf17M4uFb1dJ0vm6rzWd9Tu/W+s3OOm0ogg Q5sr1dOewQ/3/oxoVl0R0CKfjS1a/f+7dXW37vow531frY2Onp5udq6x1br6/rERG+Gp+aG//4/p N/91W+5lgPdoMJhb+1sVFKGW4TEVGkw15ufaiuqG6/7dfr8f+qxEQ1TiItNNTQUPaFpikI/mPYYS fm/w0r1C637Hr9qYSUw5hzPiIiIMIRGmg0ovWxQ781mexTEUdAqDCWr0s3fwhG4jyy4YiIs6Iu7C aGmhcNNUTguxQtLV23VdyuS5knjGQuINFRhAxERERERDCZ64aGnpqMGeWr93kUDFnQaom7ISIvFS Iq0azO+RVY7EsRZ0QwQiItbQ8L/GgQNkMLIOLM1ioMlqLwQMlQU0ioMhNSuS4iIiPnfc8GvyY+vb RoYVGiSkIE4WXRmk0gUyF8wjtwhDijK+vpdxp1ggfebs1nikHmuk2s1udOk057efwUyPF2E7SiyV 53OIOv16tmcXC+tv03dWkHp5/0+fX65v8Ijeqa84RZ24h0CQyFxe3//i30LaX/Q/ivDT2v9vBE3Q tTvnffLg0cKsNN9N66vP9X//q/+47uqb74V12v2e4T/NmZyh53Br79Juh86hLUK3ve57+3oxwTEd rx2+k9bsf5A8wESGhDhtGffiOwuqsMJHQLa7rHaginZu15xGI1QaS6/qtimrvhgyP1voMJiheTHB MVCihilbCQQjhpefQZuejfmcWX46b0pwfqYcw/FtD/iDCDCqCFhM6kmpnOPY+I7T+al+gxuv+9DQ vZ7UIuPpRERERBhNCHYU5FYxaEa3B2lYjs92vlKBc6BSZje/iIiIs6OIiIcXajYr9KtjWV0vKVGX onykyFoRn9FSTiGCVoeY+aCtwCdit5fP5NIu0+yMRQkyNZCZCsRUlTEWfojTTQ1telVU9S+f5B/a cg6D/NQhKRCDjUKQXO6Ip4ulNZggyrhERERH/1O7/2927vU6iBSL9phbJBhJBplALkEyp5B51zta HK4UGNp6//nw8X5rM/wjdReVRMev+mkjRRvdEpkGSoS1Po7nGpl8IMkZCzNkQedMqWVjIzO1W92v uRJlwn6Teh0970MJ0Yc74IHJed9Hfc8CEk3Tc8Fvi1rXXmx5fP/8GR2R0pLxThgIO80FdYj0vViP 7/eu8a3xvyt5xAin+61T7jCDzueKN37dAiP2kHX4IoyHXEQ6P+e1CBEeh6He9Q1P9/5qV10nv//T CEUl+12vtr9CdPf63pv//YIj3/NBY6hNsP2GbrHQ9hmcocofa+7+CHZzc9/dnvCq/f1m/qtevynD F0UqLhV9f/MGu8+J73xhA2k52SH9+lvcRdtJr7Vqo47b4YVoIYo3N9f/vfv74//9/630m22+9K6b DDi0LQ49cUL7FCDMDavpRiwv+ojtY7VivPc6K1P1/fiPadf+1v/VkVpEoiLQiGhFqpuU2Xjwzbn2 I9hpdpYWP5ujv6xv+CFeqGh9XQRY+IiIi0IhhSp3F2pqWKmPYpqvur1jSUGf8R9q8w/vdTsLwQQe IiIiGCaDhoRDQvP8af9jZxzDmH/sm5QgNKqP8/21hpRCeV0uOxxndI7jJYId+hEREREREWgwqEQ4 81IcWMf9iicF4S9M7NQpCoKXyo0yoyXwgZ2PG87E0ZIIRERaFoMIXF2uvSNdLW9F87Okg007JUy+ a4vk4dMmmEGIiIizoi1um5s6BEffhPqqNba114pUXbNbL5KcrOZFBiIyuFAvvT1X/dNTvp0nWwtz Pz0gg2up/zVmI7EuyEyWDIRFQiWPS75FAx+aRcKrmcYCJLa3XO953vU2fp1vXCGdq+81COmoTISN cXzJHmcw5T/Fv+/+/p6ftL/xq29ed7v+uQrUhedQmi3Z03W1PrQi76zo/XP/3RnO7/1vv/1d6q/7 ciaPJUYc8XfRuqlwm/V9P3YSJoH7vUfjHGo0m6en//0O6X21QYIdf5E7oSKbozlR0n7QIv/X2OvY iv+2ltbX0vV1V9/Q6/b//6XNGRwve9dvxphTLKafmpa3VimKjVjStKbtr6qM//wRQ8EUPj84l7b/ rXXviDCadoXacWhaapio2OrYYSjSm77baoRFPZ7iO32FP/+t6jiIiIiIiIYQYTCemKYqn/imp4KH KHKHx7+P2oId1rEQwhEMINDji4M5ZERfnP7X20qbtZuyuSjK5fIzIWjIHkahOxdCIiwt+f+4sUOx gzqxFV1K+XpkUyoWVARREXEemhYW0/RrZkZCZ6y+f6MZ6tSFcGkQcamXyWEFOjN50EERERER067r +vWSkS5wn7C6plREri+d2jCMprtow5n3//XhSVtVC5CoF20b3hcJ2dYuzsCi+iFEEYIT0LTnCztY Neq33/ayfMEpI+Yc7oMNz6m7O+8IjfCenrsLqmF4aZF3afkUyEye/9wYWMwltPTQwh1tsinF0P5E /BEh0Pq3aO9537U71uZyx3NbCEqKNAeXj0pfP51E7Morr7ocRsR8w///Xf0Cb/zSLhV/7S7ne+Ib S5nXWtVXrwz+dqYm0rb5hzDwdxo/zo/YInGcH/za+vr0v0t9XX2np6e9zF/+jdw3rYr1odn+Gbt6 /0RcbrDNz6xFQa3/U3f/Xrrxvv/9/v6EoBwY0Yc8bQxVP73W+2xwtz+ZgvelzOLL+sY++rfV6X5O q69/4jbwRQ/CvXwYTQuOLQ49cK49iKnO6DGxX3fX7Ht6prf9RFPER3M5xynKHom/+IiIiIsKqWci 17g7Ux7WxGxFUFjSyOEdYi8Mscw8PZuxEXKCf7k3W0IjNBTxEdoQ4MEIi01QuxxUVybnHbQuGf8f pdt8rqud1aZLsjaEREXERBghYUsc44Jqc8RBr/2uELxXPZ2aqyZsu7CamuL5CZCZkJYiLCEQYW0I uNT/HafrafpwczyEEC2dQlkvHfRCZB6BkRkEMqzOwiOwpFQhEREREREGF/dqd8w4aVr6WdAhM9zU JbDU9phMqWmUvTUjEYR2pinZGZFqG3XpdtBh7m9G6gQK6N2v0ueCQe0aKLd9GM9kpWRMFzQMAnZ2 7L5CQTNTMQU1ZAsL/9XEPX0NL4lGR8joEUPRhzx7RIfQu/TcJ/W07rXXNQRF89wlkJKdvF8qNTta 8dfWv//oREdf87w2aRcKCCuvMSt/+89nzPBrzv1tab7BAiPWENOzoFBTtSCVBCr1IvhK01v9//r9 aQJ//yJRcLv+KTY069zvdG7TwnBJ9UnwRJ65uex1EKI7N262ckZH2wTI6Bf2kbraH9br2tP+ldb/ 0K/hE3jzfQIuufoS5s/Bm3NLC42LqP7bWI/x8GTDxHq1P9iNL//VfvvtBdUNJ3uETiNPapx4KdHj Se+Khd/ZD1m7baQrhwQr7/393rr//HQVvxGhoRn+GpujTTgzqLG1xXczlQUPbV9m59q9N9etnO1v g/b2qu1G4uIiIiLCcYQiiRhQhEYod8GYLFRxFRpE4L2k2FncZe0GRzv0oRHI2uIiLCEQwqFp2mnY 9jYrBjTjY1OgXbU7Ugkrkudny+dzR2BxC0ZA8TupCIiGEGEDBBhTohhMLBpqRj2KhODGlwvYQZV4 IMyDETERERDBCLbz/anAs0AthcmlosdmsRM7W8KQeQqSIRFSxaEREQdodTvb7QQbCo1vmLm6SgIR ZrZEwXITIPJZF0S3LoqWOP/Jep95u0/XapoI1XXa2FhkTDB3OIPJ4nyl5QjWZEGdiuT3tfX66Fb8 //NlGcV3M5cfC2up2OEIfxxaDTJVktMj4IofGdrX/7176c7AonZcJHT09NbjCb+d7oECuzwa63eq Ldot3n8IRG52piafVoEK674ev4t9V7k4YNIuEX6XGnRu/NBrszmcofQdBN6yx1J/Xf0Pawzc6UG1 N2cQCtfo56+v1/6VuO40IuLVXT27CZ8YYei89iMMtzjhNpE4L2rjXoRS+oJkcfzH0jd//36/FJ+3 xScMMYT6YTQjHsUdjEar8/0SkLEVHa049t679r6/f9r2G8Yhpwwpj2hF+MGYFCtkhzjhNr/31aq9 WcwQyfzmUvzi16Q+u4iIiDCEVamLDYVCDCEYp9rYjYioYUpQLwkI4i20rXvBBG9z3Fn7i0LuGEND TTTFYMyf2raz9bUIFocrhUdiuVmIWiFIWhEREREGCDCnI1MfNxx7FMVvFKXS/KEdmsXefyVChSUN MqEdWYyMy+VGIiIiIwhaDCYQ00hHNnReVU/UlITbOmn2E7NQhF4wztJF86R2lsg4q8lqLmIiIjLH OPaH9tTu/Cp1rwnV1tV5BNqQYQZ1PBDO/2EJ7Htfu3zfm9U+63O/mzSBEeW2Gi3aLHb3CJTGGaxS Ejv87vL5FmciRkwjmI76S/6GhIi7e617QT1To73mgz0E2gg3CdGCoULk08irMGF1eQfR5LIvmuL5 GZfxHa8d8Prrevx//oNtnaSp6fvPqp3aLzS3oNbq/sLp2FzIZ3elVz6bv/v/v9fX1/tXYZHSfvT/ 1PFAiPvCbn/T9pOrZkgSDN2Pn7FkU0DLzDtScMOlfTnv9/97X6+I/6E0ZHCu9K9N++gVaO90CLrQ IutL20luoQjB2Gk1DV9Y4r9X+n/1hf3/rXpfiEu/6vpPRhzu7WPXM5x02LFAzqBURSuFjS1w1a2r 0jBVdz2Gp/qv/+oQXX+v/W8RERaEPOhBrYTU2WtjhhIRbSbSYYVz6iljHwQr//pBHu//r6/4iIiI i0IiwmKjjirLpN1XumNb1tQleu67+/9xEGEGEGEGEhGNTOUPGgZgRBWIphpIUxTapN2rar/K6XnZ jMIREcaEHFw1TTFKGojiKiKth1K6qsKpC4hWa4vncZAs1mTLIWp5oRERDCamPYQYTTTUdO1vIvYW 0yXEQZK2R/IEy+mSeRtHajKkhE7UYiIiIiIYX0CI+9V+6o0MJXl8/rdF8/qelIVEH5GpSTi+diea jyuHD3r/tHe9IvNB9/1+7fslAh0vPT5/C5BEXiLhUHDOymIVqZFiOwXtf5EmRwu//CdLR36/O9+v 9f39VyVCaNGGdjQhKxQkdiWQmQmUIj6a1X/9f/Hv9//3pvNM2i6qcc8au9d532qNipudwaYKCZ2o 7OohqECEfBCv2p/rX/f/x/9r3SYQjSf3fNIuFb/0Zyo7q7hho3TCk4hEnrhQtMh2kZd6j4Q/Xz3d b7H+xGh/q3rJD17VLeltpurEPQ6BCCJjxd5uzdZVnxpwZtiQiu6b6s6hh1vV/V0xn/beCZdJIbz9 Q//cf+xdBP9DQik7PR9ocGdQI6WGEmIoM/40gzdm7dv8RotzjxV1b0rb+6OmCT///72gwQ4YWzHs U/sdb9fatNC7rN29X8lAR1iFZzs9oPX/14iIiIhhMIRDCFxaGhigzhPT7sRXGEoYSgoyKBhncZeB DhnOz3/ybDWIiIiGsRGhpoWpoKEDhJrsbROGDQF7VrldYi6Ozo6hDtSRUYiIiGE0IYKpuUx+fMGe vsUJ4cLaakKyF9wyB5qIq0VCOxLKdCIiItOIfmPmRar52OEnUvIIQRU9M1JOyUI3FRk4YCBlRGkd 6GQaO54iHEREQYTKaZqjvtLXhzuDVGtq+g09JM6haMIzSDCl865GtAyV52Ks7IRKMRGu6M532ckY c7+bDvEPN2n/pAiPcz0a2lqmi3YW1P507Can0dzwgylguaiTI0iLM2f+qtjrcicYCVuCCoVvvqn6 myk82e6oOgRH3dV57enot9BOGmuQma4vlSyDR1ZiKha/V0v7XvQXT+ZsjhfzOMBBq6bd9rS6/d3w /8JuZ81tgzVcIHNQgWyUhCHp/e9bvnCu21N37ftev/tVfxb16v9v9d/V6mzTlOe9awRH396b76Tv 9t419UDJ6M5dAhjP9fqf79/Ee/8NV/vK0y4SrGrSsGG/mD0Yc70vRu/T+I+1s9vr9q5P5oC7a17F Y/q6SvaX6Hr5jitf33kU/663/SH/KIwiOlhhCxUdRT7FDEFsUDOE7hfhpWp0CgzddfVQQp11YU/7 pe8ImP/a/vvf/CERwwmsWhdqFMe1jtb7GxSCrtWIqbr2ks3MfddXSOiCCDngwv/7X//EZ/iIzqoT iIiIYTUw1YqmnDMEEdfw1bStYhdMWFvfVYZuBDtZyMRERERFhBod1dx2KYpjQWyhzOU4Ue2rF1HT aXyuZIyPkKiq4iIzkREQwmmEwsXEZhyoOPaio1BnVivpnY1LBkxggyoyERUkdgSERBhBhC9UIhxa DCZ+7Q/ej/BlOImdezorJQkyFYIGSiI1ncMiDERERERERHXfPYYSmuun25KRE5BNYQaZGRfISIjK oiFRKEVw6VwpHlr48kPSbd6vwkjZYYVFvRoYXNQQ6SaZEgXOiPSZ9Hc41EatIllQYQzsYyOFbwRb pGe9f7/JPq5oLdovMJtJtbXTJSEpPpTtxU1PomjUIMqedufWuDXH2//+533vQfoSURuV6ed7z/qd 3z2fO94TRremqCRY7JSFIvFzCDO1PMOM3Wp/obb//69e6670t1f/4pLow54ildW/NlLd0CI40EG6 jRcU1+PzDwwf9qThgEKBD/ff7v/1/6eu9/vSGnvoNU6N2dzw6bpAi/q9aPxF/9W0q//X9z3Xf7/+ vb/1a/vrX//T1XehfqIWxxgzAzApYLvhpWvGGg09Wl6wzdHVv+CGhveY0Po4vFv//4iIjBDQaemn Y2NjFRGGFjjSjdf7X7Ob/vr///+eQiLQYUKbrFE4LsUrSvGwwlOOZynCn/F2Eln7hNbVYr/XiIiD CFwwpFHMPDTP8WhaYoaEf4j3iNhhIlIXVtYpZXJc7HiKIrg0IjOREREGmE4ijclrRG7IkC8JpYp1 p0mQWO+yTyERUJMqzKkjs6HEREZ0RFnOuclTQa/l49EPyL7nZq0HpkMLIxDJSaZBxBxoMjjITNRF TR1RViGtkHCIjOREQYIRtfq/dJ/waNDpzp5qEjVNUwqYQZNCKwjrG8jI7VoRH9f/U8d5skQaT1e4 WZ+jWyL3ntFhDO07IUIuEGdnpMc5g+py04oVvjta1/f/8nCBTTPa04Wm6f5/1Pnp+/aSbRro0Ve0 Z2djhEJKor+iGAbBM7R3iK//0OwQx0Wn/+oirZojZ0t7v5/p6DdWbSLuk6QbWGnees6ToM7cQ7VI vdwQwRTsukv5hzDlj+Rj2/X/enCaHT13xq2v6cJqrp5szU7/N+rRrhQvsGbmlERxXiLjP9QYO6N/ hV7V5h9rrDC06/vqP+7tNv27oF9NzZQIj719lDljlDgqwv+QwtvraodnPxSPT0CZdBJDRgmjG/9P 19WL++IS3V6GvtNY0Igz7Oqa9aOoWIpioUW2l9rEcjHva9rEdnu+1MYuT6roYQWvkY/b4iL4tDi8 wMjTtoGcHYp+0mFP/P8e2lcbavWvQIegj3aT8P0uIiIjMDOeGFs/2hpigzA/GhxznrFRhSlBJGPp Ggp4JZOGNYdnv/ThoREQYQg00L+whGaCnhpDSQoGbAnHjatIORoF7dZXS0d2Z2qI7PjJN+N9nRFo WhmcqDD5k4Jxp1Bn2cUTC2IqV1VJhM75wyBIk+ypGEGd3iIiI0ItCz7GzH7jMe1TdFwyaNOQdBY4 fIwhQ5qg0XbCBkrGSMpI3lSRC0StHEIiIiIiGF7hPzj26XmHBnUIjRQTadqXR/TslaCkr0wmmQaH 63CVufDxqeHiG1SDdB5raNbq7awhkXD+dGCZ2Jx1Mj52YIqeaiIvlIiIR2XV336dW7/JwqglMOd9 WtpOk+vTrVNvZ2TCJWmSsROQtbTIUZ7JGmU+XzJCpL/9f+hoFW//XV7WlaN9n7TpTu0oIj7o1tUX DQdH+zTewhhc6xc1PqCFa+l//Io5h7/fT1+9370O39Lzud6T9OjZpuab+Hwm6W/77aUfe8Us5EGT D/fr9qxFa2P/Tr3p62kNPh7wbVLZUGyjvfR3f2UObc2rS2ta6nRdt+t9r07dOfX//v/u6423hj3G r/re+OxTSsULXvFPFMUwYSbSbUM3O1gwUlORx2saT/teu/2v+//79oMIRDQsIdEYS0xUbFPsUhob DCTS/3q9WeWpE6kNF31//+GCKHxERFnVAgwQYTVU1MPQJinXtWIq1i79cnJ7rX110I9CIhghEaM0 zqgQtOxTTFK2Eoqf9ba331FLIx8rhUdirMRC8qSEREREWgwmpuxVfCFimKYjaWf/KF5LFqa4vlRn c0dmMmEIiLQYTOK6aaaGv0Xk9sIZKhAuU+C2dvF8IGSAwQeQedzRDzbIeZQiOhEREGCBghER/wnV VsIeF00rOoh2O7Tg5DAM4WctEGdiWVyXEe1Xo30bs73S+5rcz6VfmH5DrJULnZrmIkBg7ciW5jKM 7qa7/6Gh/nc79He6XU2dGxIER/hU83rwpC9NNU09QmFO5o1kS+XWI/9fXbK2C/9ONWaRcIkNd/dB Bb91BEemg0JGtrdGM9It2CpoMLZ2t977Pq39///V1XS3/FL0dzxIpdJOKQbp0CI/66CbBEb9Gutr Bm64VhhWzn6/zI//9Sxzj39VHBBf+9f1rdb7vThIXptAiPu/4pDQ767/9bV1GEL2eX70gj3r9//3 ///YROJ2PkfI8qvX9rDXsR8b7Gk2laXxbfVqEEoIV/HH9PX7EV9YQiN9fOyyLhYiM/5/sIWh4pjY 31iNtUPtv67//vqH///ERERENMJhDzcmmKwZgvFIx24VsLDW9IGbtrO4zHOR1f3n7LIkxERaEMJh TUuLvsLYopYYYj9tLDfe2leo7yuZI7tGEVCJWZBWU4QhedrWIiIiNNCLC2mtjwY6U0DDEV9QndoM JqRVG0p0ys5KRDIqyExEZ0MMIRYQhxe2n5XJBF1Rb0WO5isRqeyEzWKFIcVDL50ioIk0SgKpCIjI g4REQ4zohlNRLVAiP28Jug2lX4WYuj0vn0mtBTWkwgwgyaEdlS3EaMOeKW6q6Tuf57Pn9FxrdfVG tnUIjK4Q0WO07JJEqFK4RnSUi8UiHX15nFwtXTbGKVv8IPn1fO+/p/CJPVBOjXRn4UyM2R5Bx2CD JXnaW/3//6qr3mgL4sW/7vq2jDne56BEx0M/6boN05xPhdGhyQ+DQefSD3verU/f+Zyizx+t6/f9 bxSCtRV11tUkbs490nc9ModouKpozvt79Du2ldULqsyNnucGN/Q9f/f/97IkGKE7G2r9Ngw3EGHC bd0g97WI9bVtc+rqbvsf+u9faMMD399+r1pb9hiGHvfV6imhdimKi2Ov1z/P+NKbtrd+jOMvwzc6 6xFzkbPf/4bkWndd4hoMIWE0rT48zlPj9iq2N26c97fHDStJLWGrW1WpjSCLH+h6xERmcqIYIRGh D400OwhjQ3PmrFMbOf8Yt6t0oII5kowggfVejHaFxEZ+iIgwmsXZ/hphUI/EVHhBcV2lN1teV1XO 5xvISJRnMROgxERn+HERERn+0hoaBKx/GtU7NAXQeVLCZERdFORLTIJCIiLX07TTofPTT01ei8DW 0yEkGEGQvNcXzqzGdqBCIZ2ZwzkKakRDKkUmc8f1c0Gik/Tro0M1CI0UWOyL2nfZ27L6aDKiIPOk pkJkItNDCEHvSuKTdXpOgRH7SDhabQQftXp10XzRnZqCHTvPZFjCCIXHTMRV4QZEZhFPmEdYrOIn YmhG310+5EwxV1v87ndJPV7zv6tAiP8JtINqv90SsImmaxEXbCaadyNTmuL52PkayhJkIjtb6Hf+ q7r9X7fav6Xa6Xe9Ojet/RnFJUgRHgqCDauvIUphbU9nUIEKNYh2F61dfuprO5T/f//6f//et118 X2+mFOOZ9U87ndU879AiP2yrapv2uFTXN20rVtcR4/W6//9frX1f//1pav/2/S7rcam7PHfmzPZ8 zZbX2xTaUV/fTa99raghTdb19e+6rG+b93//X1/wQKh0u9JoUrSaiUPtU0xQaHkbnHsRxV6sMJNp VprDVv0O1hm4EKX/v1/3/pfr++sd3E7JIYiLTC2Ui00LGxUYMwQRTFRH2lHU3Yjf4pf5GOcftb6h kiln19Ruv8RERBggYQYQYQYThoNNM57FKDMDWvauvehG3a30dU2RQUjoLeq2cnWzkdhepflkEQiI iIiwhdqb7Q7OfsU1uxvEUxGmEghGxFTczMF7zQF4ggQ5XS47nmowQMlyERERERFoRFqdENNRBSd3 r2K6eVwoMHbsKEzsU07IRE+TJHcZkUEIiLBBhSysIo2ELUx7Ux6/CHNDO0giN7dPL5/slCNxQcko PUSKjhRy4YiwhEREWCFpp88GvpNrTYP/6ab2ahAmp5KicMhI7nnYmjslhERHVOjA06MOYeuUJ9f9 OFPEJT5q89oEG/O0ghL0GQeVGazO4UVv+qenXNMxl//6nj/rd/076+dOzUIEyFykCipIqSIRHYXG z///+txG/kTZHC/r6M5Uad9/10bLnYl7hUXDJR+fyGaZKezoyOaZ07C39z6/7tbI5L1Edf//3996 2ZxcKVuNiJNf3LjXv7Sa3Set0D3Si7X96iMUbm7z/VfH7e8xxwwr69hcTSLhTsv/whoN931PH6nf 7wnw1VsJW3wwssckP8GeCoj7FK2v7paofTU/akY9//pUvp9f39yhF8EU6/MH2KmHO9inimKod/H1 1tJ9bCrN2Z9qKuM/7Pbz9j97/hr/WvhCIuvpbCoQ00LtU4u+LtbFccR10f2GEtfjHfJwxZ5OoIod l9UN/tf6bXaeIiIiNCIiIhoWl/2Ka311mc45x9E4L2lER8UoIU6XOiUA/rJvWhBlAhyIiIsIWh5n KiLpCLnT21hT/1qNe+01k2Hi+QmRNEdEfLojoKdl8pMgqE5iIiLQtC/zoxQM4ThrBmCJLwZtkgjh dUIiIyl5PyHrggyNYU6ZU2QaO8MRF32gwsaFhUONck5h9beu4anrITsFU+ggwQMlJmMEDJVkayl5 WUIiIiIiIjOhZ3+zwfH80786D6XCJj9NFu0+5ds6xc1Po6rITwgZV5T5fJliNdzOMBBV/pv/8En+ nnxtOgg+umnZ1Ey+f0GdQgW5DqzgzhD7EjhZSkU1aq/Wrihdvv8Im8X6bV0urqd2/uv6NdV7NYhD +ztQslbs1Mvp/+YcqP3wfH6CdvV6urV/e39GHO6X6ebqBEfdGo1u9O11zoH3pDQvfOeT+hX9qhX/ u+l7q/W2/q3Q17ujDndb+6BEf0CI/dW9dXS+wqLHc6JOGI116tL7XQpL/jLr//G623ycH+u63m7i K+K+Ko9e1M8xzOU96tX1MJXrUEP7Yj+///1a13/duGhdrahV3gz7hBjxbhhW1hhYjjWbnV+7pWbt 8pfX2FWZynPFPr18eIhoRmFFBjuD1TFMUxTtJeydgtugz/tScMXrr+EKoRsENvV/4iLiIcRDCYQY U547Tg4jH7FKxFRVt1X19ep1YKWolKWQYyXMXEREREaaF2pj2qajBmT8MsLEcaQQoZbmUQeVnIXh AwgZrRG0dqRiIiIiM42mhoO0GKhc95/JSISsUJhE4ahSIyTRC8IMl0YR1yWYiI0GE1M1VHeqhZvc IOp6OohQwgynFJSIEThhO5GOfUrznlLyUZVkRhEYZBWZC5CIj+3ReUXdJ0m/CqmFWEG14kjvy+fy UiKfSaaYQZC8oMg4IMrjWd07dPwhhDXTvzdYU90SHSNmnR323/66aNbRcNGhot9qyCJRdshIhWQv NQynJTqiTZGBL9/9+30KrzvdIVv+fDx7X0br9PTaTdN8ET9wg2dPslIiaZKGoUINYQ0O//QP+v2+ nXdJu6d/obdbr3Seq2aDO1ffWa6NbTQWepnc7UNPc9tnvptUO//3v//fv9+nV66sjbLhLVJ3q+9G yldOjDin0nXNzn6hocXaUsdMMxOq/2ctX1/OEXQWI7Qq///WOm//IkGKGnXoNfQbc/69/4a0ekON e+OP6tXiKDtnNN1ftTH7zDnHBEf/vr//tavXji0PP+bM50xTXtLsa7EbaQsIM/0ObtpWEm6W6GhH nP17wTLoJTwfP/mE9HFBr9REXoOIhhC1P8aGmfs59RhmB/9hqw1i9te97qrVCPF7Pdq9L6oU6ozU NBERERERERBhAwmhef4uxTFIbFP3sYsMJMLuN+14jlu7p4iIiIsEwphzuUOce0LUGLTFAzlnWKiN aB7XPqW5lFXF8heSsiLZRkrZDyBCEzGI0Ii4i4MEGFi0z/aVmgocp21sVF89rqnZhEeUg4JyFT0G U5lIhEREREQwpj6EWhEMJfa2SgIjXJ86URGdQiLdwc2BELgi8aDKcU7Eka4vlPF8lZFWhEREZuXp AiPuqV/Ig9KE3N+h6Do0Qp2MlW10zW1OxPKkil5QjIshG3187njTfsq0M45nq9BvP71aTczlD/Vw ui4a2dqPJZgsZ1zEVKIVkHmoIdzRUIqF///4x1a6sXYyJo8lV90hf0CI/zvuE8ER57sENU0yWSWd O0juEEyn1Wh//9V93+qYIf/Qx1/uraT+6TM5n1BEeBD10bcxnQKQwv9fvxM/OL36J/mc4t/8wt+7 X/1uudzvrB6Sdd3f/Nzvq29tYi3+1taEUb7q/bZ7nc45Q/qv/3/XbFx+yM5nKiROMEv2ckb0jepu 62I+KhhL7VtYrPrW0rXkh+Ig+++rr1Vq//8Ol9D+PGhq4tMIdiprKHKfsUxVRb7BgsRoa7arfVpX aghX5S/Nr6g+2+Rj/p2xeIhggwqEXHYUxOOxCWZ78RTEbasRVfoQ04+7fGf4IaNuc+viIiIjNkTV zH0fxENNRTQMwVY42gpUP19Jzu9EY7J0EQ9RTnHybE0Li04iIMEDCDVDTLHKcoe1i8V4MwRnNCNC whFSbdBAzsVzs1jeRWNo3CTQxEiaOyXEREYIRDiIuO6FzDlD0SHwpbmQVPIqzDuyE4jOmEGRDJdp 4iIv0JpsEUc7VNdGt6oP+Sfn9FwGEGEHDJiO58Mq8hMhMrSJXDPNCIiObNP1PGE3uf9UEHRcNFvh lPudjiQ1PpVPIKgxE7W/T9nYhLSt/gw+3p6dBNlO/WdwennqrJSECLHZKWRzJkzbMimLoqWdjhIt +mXC1WrmcXChhi+ule7D9GzsH/+tBuL0wtkUDBB51zcv6Mf//e3a1dPVhkWm6ET5vtvfN1J53PHR nfqQ7TCaM1DRb9qf/77U/1Q/tfXrDd06t9D/8KnR32zwa/bE4/luZBWwuPw0lsJD4Ivj6b/6BE7g ih64SjQ4///slSXcafed7bnqkhH7GEmPwlz9jbptSGPiOz2T4QSpLZ9eY/1XBETan9K/S3js4OOG lYQ6HvsMLDCULhEyDGCCm7Nzng49hhXS4pXqiKBiv+vS6izoiLQMKseY+KY4WDPuMQVX+LocML/a qiXh3rdAmRxb9GahoIiIzUiIhhBgqfmRgn2q/QjaVigsEHfp1imNLk2xNNCIiLQwhEREZ/40+IsR w1ZMdUrn1LcyOGd+ipoRIzHEZyIiwmExQcQ1ofyaMJpnY3BAztJndKj6ERYTCaEbwn0yUedqPTsm M6I9BBkpiB8m5GnM5WwImCnNwM3LV0jP33Rd/TdPPZ07rW0wQZkeNkRRND3qvv4VkoR9f3Pjr3qZ 2F0W7QZKIuYXIdZW0VeQmS1GEP/v/3CYTS/V7/qnnfaCbmvrQPntMnRKIIM69nRYTTO5+1+uv+9z UGK63++9d6dJyD6nhwn7Yaen6dhXv1HghhV9/X+7+t+v7ptP/MHvUod9TxV/nH9WGFaVIIdrXzIg iIOukP8f//1/+8QYr9/dX+xWoM2wMJuhH+NvwQ7Sb1+13/YW3//11tlaZcJDCGnBnUh37JjgrCU/ 6bX0rSeniv8IaLv/rr66xHwwtrDQsfgziAYKxG2tqOFtNcoK48nDAIVfTU3YiIiOwh8MQmExTFNc RzdqqWt/GuTbEIi4MIMJhNDXVoIWlBmBmCxFfLcyOGa4vkoMvFTRC8p0YRU0T52KQiYQiIspEWmh p6cf4XpsKSoQJpkJhcqmQfnaJMRERpwwnsJ+6yUhFVzUIdQil8/qfSIIQDKrBBksi+FIPKGYIq0W 5RiIjW0d706SJjlD11Wv02HdIsdrYSNYnakLzuea4vnZ0U5ZkWetf7nc7yDaBC1O9tGHO6n/6vy3 LedXoINpuCBEeC8z/OzUIFztxLNTL4JkKzURV5C0aghCIhPbv/+2uK/W2o3vfCD2GH06M/CTovFC pv/tSDlwlpmpZKUmkU8FOl9f+v3f/931f92RTBb/rsETiND3ro3UCI+6Lu64Ik/Rra2rowQevr1v ++zy9f7iNClvC6961XX5mC5E4uFSFL4Tk/zvsK/T3362thhY0mGEvxi36+7NwdN6ydBE7hqbvW/e 3j/u/4+luEXcSJxcKt71bnqb8dimNjtiliO26jZuzdv0IWP2t1xmFnu0pyLz////61/r+OhKehhM JhDU0HHtNR7v8MKMLrbSdNZ4pmgLut4/DN3rZ7j9YNXmHKHvl/XqviIhpoWgwhYU/xx2KhO+xxFY MUlDX/jvqPb6nHGYQpCD3VghQIaMEZBpOIiIiIiDCaoRYQYQhuZFiEPWrEfMfGqg2n7YWq8jAhHc QRHOWR87EsRERDi4aEXZ+sKZyn1sVhinVCMMstKHLc44TntCqeTY1GVGQrJSEJUREMjBCnikTQiI iLQteGEIOLq0LQihot9N1XSOsXaYQYUINMlJFXnTMishIXGRYhERFxmRf2iQqejW35wlOaGi3cwQ sdmoIgzqEU+iDiDzpELGVGEGVaCRCI7JYiBDtayhOIiM3RERpNr9Tu0noPSCDqi4+mdROj/Z17Rd s69rZColUXggwp25kHFOETU7vLwjpzQMETzGR0CsM3LvTaV2e6bn/CbRs9JfhF2/QQbvNREeOgQl Hpuix3JjlbwMhtBpMZ2ahSER3REIvqqEcdevux+oq6TT6O5399PvT1YSet10E8EKLehOPRhmEmQr OrCpkJ7WbCr8jHpaX/r7+43+2aBh+v/3BEnijud/c77oN5/QTcw6b5P6MERKhAhnSc1CXqhxn/OE er7rOE//H/w179f4X7frv8GCKH06CafPYYe59a9a7X/46sJWl2sM3OtntfudFD61e9f/6r/iP/2L BgxkY7RnKijDnfP/tGHO+xT/2cqVtSijs9tpR2lHNn6/bycMZtJAhUf2CmNfX5hwX/0Hjpet/3re 0LQ8Y7FIccasUu/a/P+GEmoj53l76Qjb6taG/9GUZY4Xt/i3r9wYQjiwpEHKHeGEz/ebrW7HX5Ew wGYYwZhkGPtWr1tLPp1hprhAjnCH1+8EUOy+l7xn+M5Cn+IiDBCIiLCERFXnQqoNOxgzqQimOLhp RG57CC8+rb/yGFiI7bWTZIhERERGZERFxBsWFtMJWK0MIdhN77bpKF/BAyUxC8l4jaJShyVYtCIj M53hhToV6GLFNRyY4IGdQoqnR/SPqQQu1I3lCKWiERGIwjtVFBAyWELQuIjNyZ8Ki7QtQQuLVGz+ nD8/qmaSaYJ2QqCkJoMjIuggyMM7MIROxLEREPKmhERHV327LHJj396/XpGHOOCIhEfVG5raLhhM qemRrUSUYidiWQvq778IHbW/3rnf9CIQjSDhdBA3NAZKhM9qdjcCkHoMqIvnZ0dRCVCX7713NsuE fNIuFjImjiI6yda99ntKrnf06Tr+4W4a6qQmF6oaH/rDBFD18JghFhMuFrcjbI4Vjnc7vde/p0Yc 7r6yGMx0zjhhb0YJmahpdf+GpuoRvP2ZyrKHvT16/+/1v/pbb5pFwuECI+OIbnf9dbCz/n66494q 9CLjN0Ub3fTU/0YH/X//f4f52MZHCoE5DZcIGDLr32z0jDne2e5Nqwx+8NIfn+62ver6j9f3V6X3 /ofO5Uf11jXytxcLFVvHsetjH+nrffiK+z3+2FfWLbCX3jjjP+NqboIm9///85EREMIRocRHHceD C7HFRGpoD7dT/X+d5jGs7NdJ/V5/owP2jNQ0EREREGCGMaDQYTOdJvH7/4MfoQTxpD9XfUZnOPBo QwhGY8WhxcfDvwtj9s971Z7k2NWR4hMhWSoZVohMhEU5nZOhCIi00IiIg4vWwh0NqOOrmsUi+qan VdplR5A0VCOsVBnRHsSpESwURMg9xFwYQ4tdcEt5omoRPOlot2de4MjOzqk6M0g4ORhRxYMq5MjD JXgiI3Wj/Gf+d9/pNr32gm14a2m+qLd+RcKi8ZrEReBoPKzkHpnYPKhF0RJOIvS9Gc7+6dGHPHf6 d3mcPer+E8KeOgm1QTo0c/kpEOno3s7Nc9SMcjoLUlGRrJ8qrMQkGx+/t9d1/0/+IN/96uvz9p0X mnSb9Vum/jaKsRT+dO8wj/uQmn9X/+vbpdf/f9+r/3+EO3T3ok93VyEW8zlvgifXVfX70Z3uq/Im GPvwQoEy+l4IoepM9f6j6/H//353v9YT+mg66N133X6fp7Fr+1DV214jtUIqwQRIBwQ1b3H1tvX4 ///8cXI6I+CKH0Lf/9f2Y7FbGGZSYS42Tcpwmm0qiF8/bW13Loj1Z7uvX29df+IiPvrf+z7LhFft DTsU7QaEQzKBnXhAzAzA7mgPYSJQFQiMnDDYW17dTQHbpwQyfznMPs+kO1iPrXXiIhhC09MLhPX2 xUJtOGEmGEp/99Q1FKLC0T7aqCFPe1P+wmsRERFqnEZhyvhhTlpRCmQgxTFe8UdNigZhg10Ob+DP 9tR9iOIjQuIiIuDOECFxa2nmHKfl0/qDMD8V6I3ybdEPKnF8iuRVFQiKZMkIkJiIiIj0JnsWM/xd /DQ7KRluZhFPadqXRnqmdMw1IrnTTIUiERCIpzUiedhoqDMlLERaERoRERHvaT9rZ1ETTy+fzUJa ksI1JM6K0GQmFkMAzC4YQMq0VLURo3fQIj/W9K87/UJKpFwgQpPRomoQFzqEg0XDTJSi+FO54SKj KWz2S20NvXf5OiOudzvrut5xzPY9atJtQRG+b1zDkaAgbdCM7HECZ1CEFls1sjwQMheQmayJaZrR /KdFWu2l3V+hGtaSvfq+DLdIzlRnc7/p0Yc7wk+kjZEPT9BIESH5KAjWupKezp2mg01ChS9bQ/2I +lb62MugRQ/26Gl1/+63Rsi0EFQhLyQtG5yQ8EmkbtU2jj3mtrro1tGjrhfZzva3nRtvvSiI3+7u /b66/VRS0CWwQ3dGe4ROIpCjud6ur6T77pOk3e8ER55brILo3WNQZ++/seD/kMPu7+CH/3B4IEe/ esf7rf2667q/+rp4giPqr+94rfvtaCs/++XF//7W/mHGY0uz2DJo8yNvvf///77X/muHrvMhDQYV Y1sUGv3Y9+PjBmCBhLbrDGhxkX9D8lIT+CI4zCs9/2v16qmv/v/EREREaERoapxadqmKajoHXjfV f8Npx/tpN13QIUCHdXkPTLr+pN6sREWhEXDCFoQeaCnKfP+R6nPF5IcFx4Ma7a2FiNsLUJtXWJTj VuuTc6UREXaEWqGbYkfYaEPN142KaYoGYGYIKhpb8RybdkHBDIXmkRVFQiEyuDQiIiIhxEWEGEGE wnaDTFU+1Lcy86BEiViUYR/U6mEzVqQeQmQrNREmifKoKdzTQiI1sIMKnDsLes6l086VoUEM6d2S gImqmEfQTO4GRkXzs1yF53REGKJEI7DyHiIiIiOrm7maRs/f6ruqLhnUJraL5pheQ4uy6KlKmCDX 7+yQ+h2q3m7P/dUbsJ+tYTo2V4cSIKFjhqekXjQZKM9AsMgeQqITO1QykXxbQ/Xra8XzSLhcdtGH O/3W6tGfcty3bfvoJtGuuCw8lIQ1wUmkYio0GRiCwRT0uFxHqLf6+vW9/vvX0HdGw8YU7/p6bdwR HGD1BCrQZ1ERbsEOhGs4Wz24IV2eQIoeFefr/9sR1/719fpXf3v4QIj4z2+fvSMPVBOto6hM+owZ u51CwwQJNCKFezk6/v/+u37f7t16/oFiGzSLhVFGcqNU6MOd9PN2DODUGE+rZQ5nOOElEbXkSDFp W3hmcqMd99a39+kh7T///63/W/dD2cKHP96HEZY505h4M4RdsfFOL7hJjW6rXj04vUEOMp8Euf77 b//f8R6oRaYQ0f8XnRaa/mpjYpsKMNJppZu9pJTvMcQh+zl/r/9Nn1n+IiIiIiIMEIMIREQwmmKY oWlfmHKc72MGYZBjhfG+sUtt7alAQLETtbxFghaDQiLVCIaafDwXrxuv1DUIcrpUdhI7K8hedRCF oozIFIREREaEHoeb4tDTUbEKSHyuqbsgmxqSoVSDinSakli6KhGsgmLiIiGEIsJqcjvvTRhqCHl8 9LaaZKjI8i4DIVEJkHnTKTMKhERHVzWZ+jDlP9a8L6NDrQQclQmdRJBNGmd0yVReNcXyFxCkSGbM p2V/+9O2d657VIQ056VG//O+9IOgRH3ptdNhq+uF8lIi2EGQkSuL5KI7mEJ4hD6r9gh4xRpFwuP6 +Txj61b1dG7o3KaDPnf6brbrQOi3nXwvR/JRGGshg7hNJ///ePrcIRXdd/QmkXC0KQdtLvRn879U XeE8Jvdb+1mT4VD/an+59I1ef9nkxV/3Wtf/1f+VuLha7XcieYYIp8JrMNVfud/fSBEeqb8EUeFa 4/F4/DCYbfWdF/a3Wzy5hyot///r/poR4+9X/u/VO2e8IF52s0GfYmKH1c96xs3b0u7VvW6uxoXs 53/01P3en/ZGP9r/pfv/jFKGR8v/2h5oKehjq+xFeaBiIphhY9TQF9Xb1FXuv1Gf9nv/01/Q/8EF ER3ERaFq2pvi7Q6uxXukxQxFPsWsaSrHFgtpAhvr66ODCPcw/lkSIRn9CIiIzIhhBhT/HmRaDQ7F MU/xsNJhRpT/ilwguijqVwrOwaURacREREQwgwqYTQvP2aChzj2MGdSH7rZ7Q7x4Ug4ieFKfMIyq QiIiIiLVCIaDC2FWNR8GJagouXz+djieXz+qaZ27L5rZfBBlEUtEJkMQgqERERER5j7H+uvnY5Ee Cuuug8vnslGmahUwQMqMhMhMhMhMimVTJOITOxaIPn+Ihqvo3evCVTvtbW0a9LfhUb2mdeyH5qEN QiraDCDKvJYjCzqIIjf6E0i4S/CLiK7zved70/+6LcofTz41/VM6BMvn+Qcgw7QZ17CdkNhJSEzu IvlPl8qS3+u/pdf/+re1/Qutq+/aN1F4kq9tINo111tNJGUQuFuyvHiOz6dG7Ef//r+tp19DXX+9 DCGdzv/nw8Unp90CI+6M4hUq6uSkJw7aj28ZhN6/v/sR/7+//+3frf639fTTZ7RhzvnfaBEe0uGf 6H4M/0Z6616+r04Idnv/Vdb/2I6e/3//qOt13p7nc7/9tfuDHEcaUaUNQzc0icMR2oIYIU57bPf/ ++Y/df9za//9ddsyJQxF5/QtDiDhhMUxRFAx5F9dtJhUhk4Y/BljnH2vrupOGP9U0cJ//en/iIiI bYQYQatqtmgpzj5j4wZwZwle1aEO2k1FdpVesWv9vpdf6LHKHNfQiM6EI1QiHEQwvn/Mi7FfGMbF AzBYio7Pdt1eraa/0I8mz50QkJHc8REREXEWhFoRYStO1M5TnHxvGxFRFbavyul4INMkgyVZ6JQF IPOiM86hDpiIizoiJJEIiGsWmmhiq5XJBE8vnpNejW1tVzsqRrMREZ/iDCFoes1ul5rbaowQaaow OegoQZ0z0d/EJkKyEzumdvHYtCIiNGHO9J/pJ010THtq752ECTR9zWLnTzuJSFaBlRlRkoCE/rer 3uthAhKdOeoR9RBEfz16pN74JfhDJSIjDzrZTipSGNS3OEMVFucIeoj2goIdq1f/a/jjHQg0MdvO 530/fJD/tQqQb7CU4z2dPX01NAXMk/+/Yiv6vptff/K1GAk73IpmAno35hzvpv15/SBEffde0XbO zUJRkQJv7p7wTI+jBJ9AinmEjBB//1qu2q741uvToznfZy0Ek3/O+6p1mg117dNhQzc21RNxvHEE XN1+/BD5+v/Ix+k/+//cYhBa367mgYrnc7oUE3OOd942KfiqfPapPn+bt3VrQ7/jP8EOz3+/q+9B BdV9f9+36W8WmELQaadDmy1x17GwwkGXi//6j+9IEKX5wYR6/ULfzudzv6//+IiGCp+g+6i01sU0 P8fgz7ptuoa0/4JduoQ31xF2///uIjPOIiLP0RDBAwscWh9FjlDlD2o2KBmCY7OUbEVCjS7sL92v 8mw8UiO0pCNCIiIiLQi4tNULUe0DOpCvMwxbdNpW3UrqkEGp2J5PBSnzCKcxINiIiIrOewtoWraj Yp49H9Fjs1BFQ000GQkamX0yS5CIlZkq2f4iIiMyIsJoWt6CDauoV0aHrwRHiW+a0EwnZHy6I6Jb GrIPISOxUzskQiQrHER/ujd2eDXnfdB3QIj9pN3hCpocREGRRpqf5BCJ7JRF2EyCylURq1KhHaTW 314nYzNxHSjT/rrW9OYu1SbkIO6TdWHXFouGShoNT+Ey/IfUuJrRHQUhUdRghksy6Kl7/7QjSbS3 qzOLhf/60Yc8aebL1PH5rPG+dzu6bqcfqtwwsIIRkpCXQWyVi0O8xufWuvr66//vT/1v/bpN2/70 9K76BEfeemCLkqo1udS2F7pdqLP29v7pqfr/fWla3/f+2tfevr9XfX7dQp/o3JJ8zSBEfdEY/P+N Y920vSdRV/WIsEPbf/9dD/Q39/6b/xdWsaGm2DI6C16NOQd9DT1iojhq6sRXX9r1xWt/6X/4Q/yd fm/vWI19xWL7PyF2mExQu1OdAzA8bFQ1dws3XV5/xraxX/2r/Z7e9GHCf+4zkREQwgaDCqhGhaaY oWt+KH2km0nCzdvS0k1W1s5vVD/Z7qVyXERERERDCDCERaaHHimF+xHFRHGRMF4YXM1esbUEDOyE U8IiDBCIaFhC7VepoGI2IrGEGdwgoIMheRSIpkJlQifOyrEREGCnCFIz/Z0JdqbNF9BDljslHeXR nmoW1UikEGS3L51ysoyPiIiIiLOjIx4YKE+m9BB16tQv5fPWmFvP5Dz0axSL5Gog8hOGS+S0z2dj ojeIztZLp5+1bv+i811+jW1dV8Ln86BTqIdAsPPrsgkmU4YISGvur/7whJCOL/fSdAi/v7ojH6pJ 844aptZKGnIP86ByCx28XyF5CZCZC/43/3+EIzRlwl+aBjuvt/Rv283UblP0Q2/TdJtot9ZEohwW yL+U8p0CkqEIcYZUZ1zEdrdf39WI7XWI+n1t/3F/uh3DB26vU8ZrPFhT9m7wwsER97sEOgtqagio M7C/xrpEUDDue2dFhT/edDtf4/7xfHZFP6/um7HuvDFJf6z9l3pAiPJaMP3qTQLDVoM3UPsbwZrK H/1tUFBDs8kPuwRMeh/9L6uLZEgwGC/p54Kjtwhqnnc76p/zHwmKDMF/+rx/bVvWbtWR0E9bOeQ9 BB+1//17JVf/rj//t//aGdWnF5ujQ0047FRFPhl4ojRvkMLGdAsQnRuulHvv6zIj/a/d////xERE RERFpprdod+uoS/DVoLa7aR0D0t6ghVv1Z71//9YiIiMqaGmcGf84QLa2Ka4oWKhexFV3kMKRMF4 pf4pQQ5XJUdi6EREREWhEMIRDTUyzwZgmKS3Xb3WtnYG4ZBclsXyEzWZJoljO/QiIiIYKhaZywx4 0MY4M7TxfJRBNfTTNTL6ZGMvhAypZKMREWmhaH8J9MLZ0CI0M67rhFu1wmdYu9I+iEiVRfOkRrOm SZEZF87SkZFuIiP26njBEffSb9AiP3CbW5rap/bhdkEEZBA2udmIvhSniPHSKkRLowiVidf+vRhz x37rfed/TtTu//u+Gi7a4WzqIF5BxZhOwp3PITIWinzCKki1Cxf//6+v/1v3W/yhEdEdLeqO95rM 72ezPp0CI/e6q7aNbXn2eahCUJQqpnapF/u6/r/3eYX/9f06SuEIjbzSLhf6dzcYCK71dbo79G/O +5rM+nR33qFTtbJR62NbqPfX91sEK/fMa/a9axr/r+tN3//3iu9Pa672e0bs3d0CI+6urzspWx0F vq2+0l/Std9eo0pkVDSN3//mcqP/S/3XXru917HQ0P176BF/jtNbEbxURzjmgocJiOPjSbV1+eCn jv+/jQ+u3vrtbn16//+tq//9L3DBC00Oo0ItRsVFNf4u6xhK1/unsLfVqsMLfT/0Y29Z90uq///E RDBBgpj9pExyohoNDQ/1hjYofYxOBhiNiKQ2NbXtL+uzmwzmCFfkUDG1xEWhFghP4iIiItMJodpW mrYqKGI4jz+hofetX8sipiJmhO7QkUxDBCDBTIhlDhMJn5NNK1HqDMEEUyKOmLWV0qJpHdWSjKkI azNeVAQhEp3CxERERERGZEGCWf7P92gYIWKldU3o/6n0FT0kyLpSERrMhuTTkzNlcqxxZ+iIiIYW wv/6cwQ0NT0jKIJhIp8KE7QaDIThkbiXiEyUZ2JhDtahEREfd+/STb+qaQIc0NpnejROlcHkPfRB NhJB5CZCZKQhCI6Z2Lf3ytxgJbsM5b27npG9TwIWk2luk3vPAb/sOcanT7SNYuVbL5K2R4IGdimU +XRV/qHqr8VW/HQq0jDnjXS9P7hg175cGd/fowTnpbXTO0ggWynawRQ8wgqG8w53oaXmFHTfVfvv 9viDDNIuF3M4wEhO+f+m6dF290CI+6vNbVbCHQiPGhdZgbW1Rgl83/fmFY/Xuta6/sZmy4TzTMBb OVBq+vRn6Tou6BEfdE32FP/5v7pKjQU/IxIMuiPf227aSet4KRxQSefq1zDlDlD+9dfTSjoX/67q 4Q16BB4M+5//z3Frjue0IiojfW126dUKIphBCthDGhF+udPm7rzQUPpuGv/v+v48cceNDd4uRjte KQioYLDCTJOCiC+vtfGsEKHF5wk9of/r+/vERHnmceNLOhM54vYYpig0MJrBnCeGo2e767ynBf9b qm6s9/2e8/xFoZuQiIjOhBggwmoIWscMQo2sGdQuzks/2NJi1tTsQGL1jk2HjubO+xE6kIiLiI0I iwsXxajZuKf8UxTFKxFcrkjLwQZUSDIsckoKDDIxmVSMQlPUM/xEVhCGhENNNTHtIsc4/6ZrFZx6 eqLtoMqMhMENTUYnc0RdCLP6EREWnYTCEPQQJvNbCi6NDJj0EGwi3dkO0gVMqIrcRTsqMjowgpDj IpQiIiI0vSeccw8iq6c2vp4Qf7nVkx6NDNYmXz2axcvn8IRHIJtYMEOedl1pbq1adf7J/J19rf+C TpOEqWwq/TDOwSzUJl8/kKjorNTL5CRCoiMqMhedGYioXf+lv/VdBkcL/mbLhN2Gbgibxpudzv30 YdV89nxy3LH7r36et9HRhM69kqE9Sni/+urbeP/L5f/6ev+NBf//1PDvxSeEHbJW+0Rj176tAiPu /2uFpsh1hb3Xf/xGxEbCn//mNpG7qlfr7d9f//79PO6frImv6/4SM/ebNPugRH3sRthX1mcmP1H4 YW1x7BCpxgzCujEvsR/sR9rf6/t9BMuE3/JwwRMMdW+kP/X2mK4qheamY/ttKNfrnjba0/t/b3T1 9pe3Eb//r//+/+dkvYTCF/hD40xSG1gzbGgy6I9hjQj7UM3dvBn/ra4gh7ahxRughX8yM6P0u/// BxEcOLVCGFLHOOUPGuI3B92NruK9ioxq/DN3vvWtePBDs8rycMf3EREWEInMRxDzoiwhaFodpoGY Jiqt8GawTEVr7QWouwlV6sOIz/enEREMIMFQuND0LTu++DMFWNlDmcocExFB5XJcjmTe8ROpiIiI iIuGENDiwnm6GELiLQwhk2MnJBDiwZGGRDIJFVzIVMRERFpoaayQ/sh6kYi8i7YTCDIqcjCGpITN cXyEyKozwgZVoyTwiI0btTxtzqESDcztFu9zUEU1CJ3aYQaLhqQmQmdqwhrehrvtKnSD0HYU8NZo LHSpP6aCBzoFzUESQZUshMhMlcXRUIlPv/53O+urq0l5+0gg2jdQIj/0jXq/WdQYflOM1pVuyDs7 Wrnv6p/b73V99RGnSGvJ0eX1q82dG5aQN4KENc6hDqEz/R/trj6/f6/1/b96YId9105OGKGz3Xqk jvtJLX6HaghX1m19GJ+xV/+tUm7q8dbjWyJMuEnc8Z3O/3nc753O+3v99X8Rt9WvVnK6s9/jN1tt X7m4q77+v67aX/a7b7+edigZgaY+I2wkw1im1jb17YirCnXXHs5zhNGNqbv3/frv+h2sRaoec9Yp ik4riK9ptIIU+hffjX+/vq//6HLOPiIjOeGE1N1qf7Q0LFQq+zlGv23X/1+/o0FPy0gVRN9BxERG hBhCwpxvNyjj94+NiPte1x5/jK6pZMxBE7vERERHRY5Q5URxaFphOxTsbT/o/hSGZjOuf0yo1KfI RGSlz9oRBxEMIMELQsIaH3gvdqi+Z1CEJhQQMEDKcZCI16mtkKxET+IiIiPwRJ7CfWtVBbTTOrCD U+goTIyL4QZU0QmSoS3hLXtUm0a1giUUa6Nma3V6Z2TERbtNsJkqCHUQg4JELzXF8hIhWU+YRULe EXbGriU+ncPhRpvtLpGe+ESjTa81ulecLp2dQhKhAqnVKVGdqkX6HXea4f2zQFwi7q9Ok/XeQVhA iPjToz9J0bKLt6qk6hVtOzqEW/DrrtR6//f+3rQLSuu+0nhBrc/zdQIuufqLygRH33SV8/4IjjL7 50C/zow//Mf/SHr//T44mbLhY6GrtRoa/53O9Hf/UPw1lvbSOgXudxmN0m0lvj14fdfVq9v/rvr7 69/xHBjYqnYqvw2sNbC02FpZuYwRHIxv3/VnNz3U/5wpn11W7+v7/2g4YVO1M5RjhimKQjinX6DH asatrFxj+2tv2cs+vwUji//xDi7jCERBsNWGhpqsHYpimKSXXP5EgXY1NAXImC/pRT/68RFxnRDB CIiDtNNM/OZyn1x7FexGyblDhdqx1K5KyPmRAyWEZGQxJoQiIuIiIwhDiKzkWFORnQmgcRdio4St NNBlWiny+EGRbKmKIjN0RERp2Fi0GFgiPujZRrYRfM1ojoFC2i7Z1i5qXRmkGamYiDjozEVGQedq BDWioRG0QvESKYiIiNW+rpunQjXhBv6TTRufnQLudQp0WQtJppkGaqiLswW1iK73V6sKgRH3V9Ai Pf08J6q9OyKEg0b3nuj/2CkJEvkJSGNDjCRaQTU4KTahprS/7zDnjX11T7urraNzp5+X29P/sJwQ Ij1EOvm7n/ndqQkYkzs0+1//1//f/9Xu7r7e6NDpbfvWwk17vr86Dik+bnrCaNE7WO9+6uv////G XQLv47479N/3v04RN476tBAr9cJfU7ur3sRw0rSj+/7rXYitLX+1Xbunvh/oLIbI4XzSLhRCLB/x I5W/vuYvtMbGtt1esXFKGRR8W3Xa0CFbb+hodrf/r98cJ9L//sJhMKWOYc4942Ir1ZufDCnQKw0j qF2Gxx+9RmEM/ycMNT8gRUA0PYNDv//iDCYTQi47U54YVVzYVFioUUkDMWt+f8/4YWeK/QragwfO eRTBh+lwaa6xERDBBghERFqELQYU6RM4NO8x/+xWDH2GWOUOUOE/bc//wwaN1jWIzstDERERERpx DQiOLhhO40HER+P98uE+kpnKcw9hSulQiIiIg2NC1IgFki0QTWPQi0DO08K6p9CLOFZa+e4iMEPx 9lsqi9JwRQ8joKWYJMtHhKER/ZIcLRuwaHoePHwzdK5ko5XJUXQXoRz/qWYDR/EaN1Qgeh0/zXLR V7Prr7YW++ht9L7YaloeLhc/2Ir4iGueCnxHF+srhUT9P8e+WYKItFoanPVB4juQ7SNHqYcHRjyz C4L0fL9YQX5nLuIIm03a3HQUR7Ye6LRGDJNIzEcMPZcJiFkmng////////////////////////// //////mVS8f////////8tBcUgp4awgd0XxQ7TpCwyI+kGHy30g2Em6pNpUtIMjsp0x0mI2qQYTC0 GSHCGkI1+oS1/suodK4x//5aFISlWi3C0P/8soum63thEfvH2HsMPt8PwnyERBQl00THBSyjBqa0 FBAgSHCzyLgvCHoRBEdDYZsMoj5HQwxILuUAw0ZQ5CjkwG8JzDx6kGtX7/W9V16RLBwkakXGEDpE 4LyNwiP2EEQrgsbjSVvmO5c8bhXDJlbe3dw7fbvtt121tsVSeWVbRcUMKWUKgQoaDCOOrBUTqIj5 aBrqQ8hqgrCfYYSllJDCsVCB01lu2gwVIOIxDB3llU9vT7sgq3rg/7roj34TS1bH/3g0u4JZ5GDI 6sUQedEXDLhlOCsvEcNSIxEgg5MBBmGQccrlEW/ymVC439fzqpZTLdOWVaCDeG8Ik78IN1SB102t dLvXwusgsl6CFVGFyQ2aOjTQYsOWUS1CBOcZKMNwkkI9+qN5HzYvfsIRCCBGNuyFHOOIX9iJDOCx eyGeDkruWUXRHz0LfERd7fLR1ZH17HVSFiUmqklWhllWouLQ6I3BQRxzWC4cEVEhR7e+lDDMCBw4 at7KRDD23eHhvt3YaQYMjo2dvYi7FA8H7BSMcKIIm4Qy0BWYEHdEBA2sTAIFuXUUAgtHI/G7d93r //qtZaCVGOoQhpURjyOPN2rbHhpwxNgdhPGHew724ffllJUsKR0Z1fsmQW0JHUER2VhBKyrNGypg +3iUOyWpERwRdYYu2hMAhV8Ns4CFoNuwxtpuStEdEdmvsk8MMIRDMwS30iNyI7gxQoRItuDCkIOc cjHOjErCENCnFu5aFSba24/u3f323trYf+Wi0eMMNKWUKTKywYJbsIER0DFeKEMLwh2GuNvcPh3t KJ3+y0HiPQzPghuFpMecpKDC5FWDC+P7Y7vu2QnYYTKtXtYbQfuCI6SloNUXRuSDjyyrYaL5ZVIF BfBg1hEF4KFA6yaqGR0uUlDo0onRMhLRsTYYwtSpgxwynIoCFJxZgEEl90t/rr+9WzUxyN1LKpZg M2WUrNCQUQFggWRRz8YBhaIsrVRs7H+vXSCr0glyti2koomAhSa9vcN2t2H7ZAQBdtd1cd6loNB0 paFsWixwqBDH5aCDllS9B4aDsOaHYeDko8EX0nQfHEIO2EkTHeHoIPDaCpuWjKrjt6b39u/29vb5 ZVtQ+IauWVZQvCR1/oMhd7sjxHHf2I0+wYZ3X3EGUVgjC7CHFYsOtgtiFBhSz2o/LP/v++//LQeJ Y7+//b1e79r3rv27Xtr2DCXDFbYXBq5Pj1/6/u9Jft/eWi+73/vw2u/3+wd8O9+HW+7DlU2NYYdQ 3ww/firO+I//+WjzI4yPnEYiPkfxERESCaFeYcoTKwocpNksREg1DiLoschIOOSHEofYn4VKmUgq CnZHy50iPBIKlrFV4iJEHxIQc0HcocqzOW7exESEdCIiIzRXJwUOVxhyY5DO51kehERZVgiPi+xE Wv+usmytGEV+XyupCBOzuiJZl9fhBrnbiBbK2C++b6O/CS/9IN/yQ9AiPuzwa/WtLbRnT140/f/W k2/0r0tr9W///2GEm/f/W6vsVEV+306vRZ1NHZ3DCfjiODS1QedloMRDCFppj+D04iIYKtupg8fD jTybAWnj1K6VnYwMHa3ndowlxH52phATT0jIFXng11V3zIpRHQXjTzdnfrhCLlcFDCV0KXvokPLI aRf//t9I3pbOzWLs7JDzH3X660KuqYTvv2e/p27QIutqd2dllND3wwkdggL3qnufVJ6W9JPa2PYi nSkh3/pfVxFhTItdoe1+v8REGC3mHKHKH/sdfUfoRDTGtd3yuSI7EjJp6iMU4WNZXUhEGpSs7NZ6 DCF2CqEGjQ6MZ6ItXR/8yKmVTERGi/dB9d//CDIqGMIOv173rzO1LIhfq9/330EHZ4LH2dkZfOud ia/9pginX3+t1CB5BDRtyH2XIjTe1umIj1j+nFbteGnYMEnUORQHXgiPfTs+Hdzv5blu0ezw7FQ0 mbm8/bjtfS3S7hB3Vu4YTHWDPud6p6tLb/f+t4hhC1v/DCtr//3/xERG9imK1u9LrbW/QYTVpNPr fxXJsBZ3DfEWMYimMWqldTRnnZNqEGQedinw2EGmgYQwQahDljs6MIM7UBejIKQiGCGm6LHoJ/10 yVReHND6PpJtqd3NinH3puVwbL+m+hp0lem4rpdcrkudzyEXb7/rHgiPvzv0CI/lcKEJp6e29z6t f/8yGowES267S86iW2ON6Y0ri6tf0t0Yc7+1262tKdqAsER/an/6/13vO5UbvNdimumOx9uqb19/ W7iNB2hqYEBEfXuLX6/194iIjG0NMVGv4IU//FhMV31/LJUsRDC2MGcJjlkNezufiLWLXkEMiCCk txiER932SpG/zWZ2zQZ22W9PCYQZXVojsyF0YUm6pmAlO9O/3WVxAQJ2d9HZ8hEdgSMKmv6Tf71O 71zs1aZ2ahUwneps9/3/paN1AiP9J+vGn6/4Ij+vvQ13U8Z+6BEfv9r2tRgmXL10v/3JCMKq3+xQ sUPGx02fV7/jghGvxdprkhwqC2vr+3v8RDBNA0LWV9Qw/UVrOj/EcR4jcKTQL36UrpWdhMyhDKIt NcL2Iy0hJSuSCwy6Lx3+mdzQiGEIzjSaWsRDKXZKQllcvF87E0IiGCGEXlkR3666kLx0M+X7n/q2 dqxMrpIyFI3mVSOq6t9PidutAiP65XGT3Z30EDTOxZeu/zuGCHXow53/1nZq0wnl8/oiDmaRk2c/ wgVhLr/rcicYCVdPVzW61YvHa6EcM3DP//713VukeKT/y3BEeq2kLUf/+7z///6/eEHbzdYoM4X+ 9K28fCZHwl//dqv9p2uf47Eb6XoRul/0xFLvERERENVGPCtYpb3f4i1gzyBBTq2oZuf5aQqpXSs7 gZB53DEdpqop+GFFlCCuqBHNQoQZUZB5S8REO10xQ1O54VFvOv3l8/ldJnajKRGEIiIYWbPLjTfu vlcQIoVSEhLSSlpylegQ032teFo/hNs6bk3p3f/V9zOLhb+bN846/JvAp3EXzs1uLdr169f0L6Tf 2oW6P52tQ1jbPdr1zwU7Yj7/vdGjBEffztTEldUCaG6QIY4u/Hr6SQpfetKY/vpVBn/Z7XqsvrX7 87lRLSLFm3Hm6xQM418r6BibNvk4Yv+9fG1W1sLodadiKac+v0Pu4iIiIiMyPuDObnH677yuFYiI sLVjSn//zuhkaR3DJYhGbMV/a9NQgyo1O6+g4aH2KyCGR4ei3ep/OxxCuTyl5GkYRVo6oRERYXVz a6fdVK6ftShBNNUyukyuaYlpLaznf2To2i60n/Rur0Y7Cv0f7LojowjIWzCO3CD+vCYQjpszjARv od/VGH/8RENO1OxBHY0fv+v7WH7/vvfewRHl59gVP1EYz/tWp+oVf39K5oGG+fE6O/50FbLmjFf3 od1c96sR7rw1W7XvP+nVm1K5KOayr/DX5uaGV9Ad/pGRQ6fr4+t09UIjsV7/hm7evzx/96j+oiIa HFqf4M259iK/P7a96z7Av8m3IRERenaH+0hfS5zuI6iIgwhF2OI8+v6nTO55WUIsIMKL6nPlutmE lVM7chDC5LYHeqVH/PZKAgTLcbMjDIgyDQo3cRo0CFf2s1wmmgwpeK4EmhH1/U3Um5oaNDRohcrg 8joKVVHYLidp/TTe3vdaTaTaTcER90IxU9mXER2vzfHDUX8rqbp6enS9fQjLUFv+qH/r/33aN35n R2CZ01xHP+Yet+/5hdfmRgM9C+0z4/hGP/R/JQEbV/tbb9qvvFJ/F82FRr9BRQ2k2l6382ls+o/j LSKENoWhEXZ9nTDCxGcB2IquGFX9TaiIiLFKm0NIc3bxEYYKamZynKHKe0PW6lqCqI6k2CEdqiGE GmhEXGf78U1TOxPTO5sxCIidMREQ10aGdqPZBDK5XSRLo7s8RpB/urK4gQ6QTQZUcMyU8txo9fc2 Hd066aNDNQkMyKhCFZkL5hBB/+t/Ru1O7oOEpxw1000W7Ox8k4uv+v+djnQ+6XMOd9AwaNnCuggb U/hbLU0W/Sf/BEPKf/utsQ5SwwR0kH536Tb66V1BD/tQRHAfr/+qFuJEmRwq90/zvvw0qtdtJAid 2e+u6/OmEpnKcpyo/1v7evjYoGdQKFimEHjjCuv8QVCIvZ7Gf//2tbwYW00Iq1UMJbfC+P70rVD/ LUIUm2IREWf40xQxwhH99W0tvS9iIhhMKp+jxFWs/71GFINEyjbERoRDQYr2IqFIaTuDITIPFhMI dqW5kRHr+YeahLMiDMgxkZF8lcXRKsjWIiNJ94VOuZYgg011tIjAwdzjsmZK1BE3j/2iTqk5ro2V 18/pHbhAg0zIX6C/953tmkXC9XVo77QIj7fzQa6zRo/5QiZZPndMg/f+K/rXvv71941aN6Sb/L19 nY4h1Exgh9fbz9r/S9ffSehp29a91XPEx1a/ivf+37/H3f3/6okOkbvDGDPvg1tuu4tf9L9en+N/ ip3t48H2ITUY7SUMJRr6U/bWGbvWI/3qIfaFpplOtjYpiPdtKNtZhzvec7/buIiIiLCaYVbGsVQu DP//7OcTsbxEMIRYU/pr//80DFSoRPiIiDCEf2tjWTYRGGFVTurL4iIiNM6O0wU6hKMZ6C5XLI7R mEVGdmGIjqd4IjeuutyCCxnLrpnQakJoM7E0QvK4UtJYRN4z/3zpHNAiPuw9NXjNQiM7TJQEMhfM IERNudqx+gXj9KnXnf00GjU7tAiP8w5Q6SSd1CphOGQL/38Zf7/1oN3703dCDaO5303zDnHSbze0 RKj/66DW2I6//3/16/bVzsYuhbnfpbO4O/FLM4y+T8Muw7tb7r6/1Q/9YTLhdzsEMj5Hi6S7pxD1 d1cMaEbNzEW9Rf3S9//tXx0IiD/8EWOFvFqgfa4irXjStVOgX96Gf9/1tqPxEOyiItNMULSsRVd9 rqSgJPp69X0riIi0O0iwljYr0t71igZM45NxNCDCEGEwhaaF5hzjhCLEVZNPqTYJndiFUQiIiIiL U58QgZ2oWKgyElKeL5KhlcRhhCKBfRvnSc6iBdMmkekGQNEKiDzpjM1Y6bfTXRshPYZBojpMi4U1 CyIOfY2fY2coO2sLdLZh+/aNynfdWjDvlOGCEUkCxDs7Cd2R2R47WYlHX1/x996DbiG+bMu8mOW7 14iGdhQRI/mQz/v9aX+reGGX0Zyo7whhB3rdljlu/ylZ1RMwlp/wRQ8EUPe//b46W2m+rzurMBH4 Qd0bN+qxHQ4iOGYb6Vq7eCJvttx/ftfSbysAwkP9z//CQqNW0obGZT0EH/Wz3rfN3/03b4pR7OeD ODsURQMNuhC31IuEJwxdUNZ2IDH3L8q/HvER2VOGraeF8UqthR7q16F7PajxERnREWsXmrMjFPgz BbCQ1xz/hm6TcaIRERFpwwhp4oRX45NgLCDJaxERoMJn/WsmwMRF20GQeI0Iiz/qgg2jDs6yDLcj JfJmZG0VGZFCERo2adIPrZ0k7TNbU7ngg5brKI6I+R8j5H6Hum6ndvpoxzhIQyaemQuO/iVDIuRl XkYqEREQeur+52sy1O7r0Tfdo1tzscRNUDX/WqS6mUBhLfydcEGq6fVFxntweXz/n02e337r9/jT Lhcd+9G7Cb83s8A/+8drdMaTzcVDTS//1yJRcLQ7r4v/ethhK11GheNKdEZ/2e9Xy/+v+ZEEvxGf 7FMUwvV1/4wQrrGf9//T/oQwg0LT7Xfr02v7ZzfYjdiOIiItC1BiPO5Q5Q8GfYkI9UOwkoMmfEXH EX1F9jmPMj6gz/k2uNRHZqISedM5iIjMiM/2hFCC+W5mIE0yISoOyEyFYiIhgoIes10b2CG1msUl HZMo/mVcRGQtEWyNZhHdwsENGyldNrThV0HZlQIdJMlME1LozQVUGdgRkWzurOxJDSGn3n9LckPd 0Yd66en3a2EWOwg8wjNBAyp5FHJS1MDO1Bf9fGnRnTr0G3Rv1O+p3degRH3hBtFxVVTXsIMIO/v9 9Lb6t+K9+/9erwm61nx9TxRY7Cez3f7brtv9N/S6S9//Xve6u9egg81vG6SGTikcrSvyJg7b79P1 sR///9ZE8wNf6bSesehsU+vDY7OTGkx7/3mNdiyOP04187hL1eb7Ux8znHtcUSjd49dIM3b1dLdW P3ljlD8cmgX/tUDCEaE/sIWt3VpWgruxFQ1W6DM532ooIXfBBv9RERERERm9CwhetpCNjcXbS+1R Z3at8REREMLa+N9hglCD6VrLczGVGdq42iVo5jORBghEMIXYoRYpiqmsRUwg7IKiuTQiIiGCaYVF 2123yUMIMEDKdl8leYRUshM7hibQjhWjZp4T0qa6dkqENYoTMhGvehrW6nho2VwuoVFuGZIEO55C sKd2jCOz9f+n/O/qud9zvtF3RMfTrkX8FCdlLDH/719d1/+EMEDSTou/dgiT1wldbPd7q/69bpb+ NWRMF4T/paBEf2Z+0o9bqK3f///dPErcXC7gibxS7hT9sexTDC4UdW9JvSs92e9ZhyhzDlP/rQXW 47dhT9aYhNVaUa+sZOGG6oREG7PfP+1v/Xg0LQMJhC7FMUxHra/GPghUd6T8RERaYTCn7MexQj68 zsvv+sRGg7TtIw54u4MxZBjjW0pNsztJmEVGQ4m3oRERaFoaoQ7FMVVUzqjCWDOw4rgkCiIiHDCa 4XQjkJseUqCGShH4lJGQNOI9AiPvU9tJA0Zzlb0yolIVEqMyFzGW6xm0R0CKfTfP0ebsHjpTQzpZ 2phCUiIM7nkrIIM7iN9NCIrW9sECfnsHn1apN7pBUaJ2a9phE7adnaj/1Q9C3gwbG6BF0QdTvo3Z spOro1uE208g7UGhRuf9sPwfDFCq/0KQ02/T09b/vU6hAw1xRnKCu+vev62tpXPZof2IpSHKdmoW 8SUBh/CG7v/9Pur8XaRFrEEgtz3Y2qVnOzl4Ip6vRj/Wm+IaZwYKbcOSHzoTDCQZcFOo47VCK/tb r7iMEIoYixQcRTVhhJqGvG2trxO0/MOceGFU/qbrFAzhYj2KempNryEzueStneCNCDiIiIhhazot RjLdLVqdvBTqjcEGQeFK6RCIjMiIiwqedAgQ0GnM81QQctyl62dzRKGYjsURLIhSESLIe6S0gRHk m10ENHeIKdIw/UJggyVRvO8wQP87neQlPPVPTtTvc/zwW87NQmtNnZMRNB3YQMlgwgzs/fXbvH9J tJbjeEH9Hd06o1tGvuqovGd2gU7dl8hOqv//69Pj2jOVGt/Ru09NwrRraNboNhDXNQkEK/qz6/v/ nspcvel/16FK1fenpunCIx66/8SJhiK3pjSx19v/+3/+1dLnnne2jdgzA7GrhYa0ufT/8Vvt6//1 /il9DxqXZV2FTFNLFw0rbXWGErI6Lz06/0Y77//tMJhC4iwhDWxTxTqxoR2tpNhb91dWz6v7iIiI o3WhcaDC2KY4hQwvaUNKN9bN1poREZ/tNNRGxsMJLelHLczIhaKmhErgjERBgh2ExUznHsRXTJTI NMhWQmdreEDJaiOi+M6IYIhXQu1P+jW7TIv/naoIdjWSpl9Ex2CEZri+S1HdGIiIiIjrpGfv6nYO tdAg6CXCZfCZUshaOyTOwM6vVX/o2fXSDcwTa2i3dphAwgZ3iO9V7/8iYYNIwEod533XoER90CI+ 8JutMInFMvqQn6Mf1/a7Wu/bIUNfXq/SNmEGwm2djhO/x4Ic6LU3e+v+v1+rIlmzUiebRfWm6ed+ vsL0qXjXZyOxhEfBW/6RY5Tr9/9MIaaEfpWvo3rxG6snBQ4X/HEV6VrCEf/+nmHuiMf/13QmkYCV FwcRrf2THBEdRqw0rPq9fSbxo/jN39/71zIji4vP0OIsUxtqxFMR2F/u1tfp+ftoRERFoMJhIbTT FPvtpRtpZS0gzcO8REGUCQYJhMIceK4jQj+W5mRqykzCO0pEXFGecRERDU6LCkx/08+gmmdjsvkJ qgzuzOwJiIiIagiiHo1vTSdbzUIjdCDCDJTkYiQiaZTxSYiI6b9AiP6BEffVJuaMztT2msh5y6M1 ndeQrIVkpXdt6b6/Ru06TaQft+HSdqesi/koWFPo7W87U+v+t/mgYofp6t6+XBne6/+nemdqYind WQf9Cv1/+11e+OE7/tuS93e76dH8mlnTu63tU/zot7v+/797v5E4wEp/vn5f3vtJG7ar6+mbo/dQ hznqnsRxp2utb6jfX9j9iKY0vJwx2lda7+6vU/+tUOm/f7CFppiq1mpY2ws3fusM3Uboj4IYIVVx /8MIQYTQuzotNNRVb7GL//Wjc2zmoQK11iIiIiIYIMIXEap2nfBnCjAvQ5oKHoRROGIiIMEIiI/t P0L0wpNgkXzrlURtGrN4iIiM//BnCHahYuiCFDVOyEyDiKI7Bo7SM7gYiI/W2Gt7moQ6b2TyYQZB EXgmVLITNRGVUI0d7ybmdq8K1v95nZFwqNzJUIqZUR1RhkLggypolZ/4J3nf7ow53176QfSdTqER cM1BAmpKd0WOyWIjoKEzukSojtZRhf9v/Xrfbiilo4lq5s02jdShNpNIER74QbBCNFwzscImFU7E v/9/v/64TCGr0/0M7nerzud6W/r9OqNbC2dqO/r/v/96U7nc7t/xb/9v1r6vunRhzxq5/pPBEedc tQNb6tatVtbbwQ8RcUb7qv2v/Vt//9er41ZBEk9u42I2GkLEUxX1WuvWhtnN/db/60rzH7b/unr/ YTFNMJqMGct78MKRcK8f90/x4Ibpe363rB/XwYTCYQNC1iI7FQphzjlD142wve0tWqt63Wcm6va9 YiIiIhhTiAhE4p/i0xTsUwlBnCxHxTDCxVqG71OxAPJuUYiIuIYTCFoR1F4q4oquxFNSbXEvlWiU BCEztJCIiM5EMIGFP6DQtAztQsLczEOoiqCKHnYhyPdCmhKBBrLUBqFCnUJOoHudmqU7UZBY7OR2 NI7FEIiObM2UtaRnadqepBzNnWLmFLxC8lIyVZLM7q6Q0M7nd2cp/Vb7+2jW9Qm5KhLU+lLozQQM qWdgmd0X13Y1H996ms8aep3c4/VGt6dJpp+UJSBxfvv6T9f3dN2t+++jDnek/X6NnUv3l8/hfZzs 9/c4TivsMIodJfX+l3X1bftdX//feMnDH/Bl3dFLDAQjv/X//f/063IlGAn6+jvemuxVnuNtalj3 3bp0v6+/jYjXtSUl+/X+bsx0PGsUDNsaR6tatY1bpf7pf6ljlDgiPgiCJQjv/7Qi4a2f4aetihYp pYiu6bWf2DM53uowhHBEdh7Ef8RGf4iIiLTQ07sbFfjcNL4IoYM0HHv6xE7W0IYIWENNPTWxXsJp xcM/76luZkVGdwZKER8iSTEREREQ0OI/2GI6Z186xhplOy+hahI7NWYhERGoVGtreqNDW6KsQF8y ryEyFZLok0SjEdPvoEX0m0CI/wRPqETd03moTOkEzUlITswjGRfOyrrb9V09b+jdBWqfX01sh1xE PP52ECna1EKyFR3GYR3b7//6/9CEXcV9G71O7v9kR3/kX1JUIqhMhF9V/9/j/8ydlwlCRPNy+++8 +Xvmz7hQtotwzpBB3UEK1//7vf10whpfXWt79O/c2UCI+9PF7S4pbX1nPbN0ERxmFatTduu/11p7 hqNnZZFwnpDXpPO542GoMyiraTGl6Hh0+hrbOYz/dLBCgQ/0N1/++r/LUDViE40xTFKXQ+DFBivQ /jXq19WkbvT9e/4wwqEMJhMXP8Q9P/tJBl2CZMc44IjptIZ/nYQOPgh2eW/a/xERoRDiPP8cdoQ0 IixXwu6i9VeoridnhEREXdoeba0sGcKsRVrhS1NVJtcdWXyXiUsxHXK0giJIpKZAtc3WmKaoeudW nup9FDMEoTO7i+diGiQodlE0LCaF9IER+6Tq3T09F+wv3mEZohMgsamXzWy+VGQeQvIVkoRC8RES 1A/1vU8af6nj069Tx1XIvuuuU6I6VSUBSVCpoM70R2B3LclZcJ/9r29bk6Wud7ddr/6BEftbBCKO oTCyDihE25XsheCDOx+vr69e/raDI4X1/t3/+t53+lPBQ+Te3M4aeSoSYd5/G0jdf/30Prr7f+v8 0ZHC9r67ozlRnc8PEOjzz4eIv2qQPrH/SYrtV+mp/rX+KxHX1X19Lf/4q3YQW6MOd1V7+41wrDSm 7Go+x+t04z/BTCCt+39tv+PdboKuttXb7WxTWxXtBfuNJtQZu/Efr6X/9ue/W2//74iGEIaaFw1Q 850xUVX8KNKNX1tvJQFjbXJSZSgf7dUOIiIiIiGmvHBnUCmK43jSW6aIokvuuuJ2YhEcMJhC0NM4 UbLGKEJlDmCm/DCo35NgJHYKjsMYm0IiINDTsKCGmo2Kfk2vIxJmpl8lcXyni+mXwmpknxERgnFo MIeW6VZ0CdrrsSKaF2zvoKQrO1YQRER92FdbXTQQbKWYQYUlQp3PSNSN5VxEIleVMzsa+8/qd+jv dHe3NR7+CJvCnY4iMDaDNQQhsIOQ5QGQvCDO1Va1Ff//p6bhTwwV5sruq9w0aOmd0kysR2OR2jIR ff7X18b+knCJxFJ0Yc7pz/U7uflCnfLct2k3o1s7HEo/6Z3AiZ2JKEy6C59P0/v5OvX+uhrbjS3S HSuEHen6dfpGtrp0IqGv/r63XX99/1r39bf2RuMBFtGcqN/TovNPhFALxhK+r6y6MEw1tVjMJz39 zg9b///a70u3kSZcJ3CG1gzp7GxGxGhFWEmKSRorH+rH2c4/7ump/v/d/75TgudjAXvOQgwgwmEw TFNBXBjW26c9UEicF2ltKnUf0rbdDaRu6l/qoiIiDClb0CFxDzOU9443+lYYUYaX2v8w8futs9zo s58mxLiIiHEQ4tKNToQtRTFDsU8dH/uwuVgMd9ybDIqxDsRk+4jN0REQwg07T17VRGv3yuFhDs/B hSUjJGhlPmERcIZCpCIiIiIYQiL8x77vTO4FhzYEmpdGawqaJDsIMlhkniM6LQcREaNNhWVZLRCj ZpNNk/ro02jY0GUBggsdzyXRVMhSIpi4jp5xzDxrP9X+G9AiPvTpBtGikSjyaedIIPvKXnZrlZxq 2rTgixg993DBjT/06Qbmg19++/y8e7U+iUEpCv9Lf/6hvT//xq/t9Gf/XWsZF/MkZhkJHYkrr7hh zAvYj/1/q0n7+qyKI2jCVV/+WPvTTOoieGk23hh1a4SMLa3//+q/00IyJRcK/kUB34QP3SMPXsV6 kiC5/tIGboIFd6x5fI6BFPuvBS6XX//jMLW/enqnRnO+oYXFRCjIkGPSViK4iI9bWIwQqPGf7U/4 jmcocz4x/++s7EAvEWpMvsWkNqc/YaTDShVS+Pg9CLrYQKwl/Vt1FhIuCh8x4yx4YQjOexTFAz7m YJX/Z//NBQ8lcEkI/q/Zz5NrxYQuItE+IiGE10LQ4/90Lgh1FK/9y3MhBEREREREXGn4QM8hFe1v ldK1O1WLoqSO0pHYQUyDMREZwqLixTTVUbaVslCTVMlUbwgxEWhG+vbnamERud2amXyWIxIt2VGS zL5FcpaKkh7ntHffqk3WtghoIGynFC+XRmk1IVnc8lClcEBeL9+0b1TpPBEffScEltbsi+5KRLJo Ehl0R0XyCx38dxl8qP0v9YrdWk3o3auSHoER9619aWIiGRYQ7cQJ2dBqdhB2dGfaz/9/9eh3RnT1 /v6N3mi2oVJ4oIHvV9QQ3666/6W/7/6EiYYoHRsPGccw+bMER/Rh6Lx9c9X1UM3X377Z9a+/7Ef+ /T6VPQpN+e0ED3dimIwzOVCjbVtb1tW6tv38EyOgW53OOWPFvu//W2m64im04irFMUxFIcML6tqk SnPSEUwzFiLr/7fvQ/5uQYLn9NNNbFPFRHuyY4IjpD87NQtr232e+vviJKmIiIiGFP8MIXYVYOIz D60E2kPqVsF7VToFbCyuSI7A0CDJTCIiIiPR/HmcFG8VsRSTFUzu5NOGS+RrJpGRWRXG0IiLQhhC 1ORaljlbMBfPTIJQ3u1Po1CEJwZ2HhBlftMRERDCYQj/tJtgiOemp1CSE3Ro2M7pkqi+UIkIipEf BFDzoEIXnaRiPeprPGnFt9F3plQ9IPrdphCIpIlYhCsJlTR2ar303fgwzCuoQow53i/V6uuzPnUp KREW7JWKiEHOCnFzbqPsc40U1BTv9/je+tsEWaHtb6BF1v1PnRdwkgmwsX57OzVaRJwTOxteNf8I t6Ff+mF8rbI4Wk+KHbhkdEdwhnc76fZY4Ij36d5/CFHYM76/tqRfCTq2e/sMN5nKf9fXpbEa+32j DnjCDT/7+mn+f7a1DCUQTzc4/phji+XRHRHStT//nP3Sf/69W7IFFwrf7ejekaH/tihYpL9dtSLw XtCIjH7f+1nC2eX/X3X++/fjTfaEWgwoW01N144gmt9WI+20szUX/f/f8/whqsfttxEl0LiLQiwo IWpzxdrdirC/e2Fbb3XH8EKVz620om8RFghERYIRajRuuxsVxUNIfm7z9i7Y5NjWURDC2mhaYQux /WDNud0mG8rpWCDKdG4KQpEMyoMk0TYJmtDP8RERDCGhd/kx7vVEx4QwqaaDslTI8Vy1FSEIYprh ERERFgjNC94TaR1GXyUBEaKNHVyuIMjyn0FQcMgUdjkSrKlm8RHpPP0JaVWbSTeul9zDDdslxEHh cyGsth+VwUMU2ohF3Gdzv3Tp1Rn8ER99aSbZThpzRz/2drXklZHjumUr66/r3/2ZxcLXaTfb5/px YaNySb+n1L5/V1yhEJDmRvdB/v9df/rb7H2DDL9DT31/6+pfs6iferOTGY/4i72p//W/DC/Ueu/3 187969esNYqe3v+6j7f9Uhoyfgi42/H52Vsjhb9LspSMIvBK/ncqNp2KXDHxzUwwl8RV/MOYfUZ0 Fds5+t17ev4TiL/VeNNT/EHFoRYod2IqhfP9wnjtUW5x7qwp/xH9PTEddxERDiGELCf45oKcofCV Wwk0LwwkPg7dYo3N9t+IhghrhCIahPP9ivYr2f8R+DP1v5XJGTRFVGJKkbhGbIiIiLCEQwn/a/f1 oNSKYQYIZOzAyEyERUkIiIiNMIXrqKoz8vn7RuaC/TJWiOgp3EXztJl8lKKhGScYiIiLCpBv60g8 wxTPzp4QjC4TtTNKVOL5KyJNBBkqZiIXnYQY61/reqb91XV9c/hbCazY/JTAih6DJlnZWjvEdlf7 fzSLhO4Zh96+jfnfc7//+a2dQiQem0I0bHlZy8CBoM7QiXE/d6rvH+ZsjhfoV3S7vvQIj7pOqTdO kkHy+fwQ05F3jL6+jGxG1N1esVr/r/29+vq53PGv2f3Ta+s+WccGtozULL9x9kY9GGOhn+CG3/rU NYa///ev//z/WxB0CI+/Y1DP/43bX0oZdt6W1oaH/de2++P7+o04LXue6H7XM+GXRHrC6soczlQk O9W7Wd/+//rr/EGr+i93+LOwPosczxcXhEjQjYhC4uIzD2IqIrP8/2MJQwttrDStIlORxoij2Oz3 eY7/pB2hPYiI4YQ9H9pr/YyKBh4phhWMIVGGWPtXSwYP9G2UBxFlTiYQiIgwhEaYSjsQmFBM7k3t H+OGFUpSe9eHEUxEWdEQYQs+wKL+qEaGxFOeweV1PO9Y6YSIRFQhERERFn/yPfKMano7NRFPaZD0 0ztSzspxGdGbZASd9fOyZEe91PZ2rEIVkJkKzTMgvJaj0QqI6EuhEZ/W3RuvhJrf7UlIhqE8vn8p eUacHBoWd0RLIlYrjdaG8Im8fX0XlUv79kHG9uduKEGESHDMkY7rvQX5pFwrdQnRhzukccz9eveF PEhWqLHcEHz6O0pULuP//8a21eyJhh/swiPqjYd2v6MOcegg2kG+06tnNYwQ2p/x/77r/ER1vXkT tIXp6/rN9Dm7PEvUPrZ7//mRiP2+636H1s0Be/v9XsUy4KGVm6djAx//4edHXceyOi6BFD7/0G+d loYjU/xao0YcRete/tdQz/169YiI3PfvUw5Y53OPj4iIiG8R5j3Y3Y2n++Grw0uGtra0IjrNhV9C LQiwhYQ0LtNMULGjHobaTaW6NBQ9x5NwKKhiIiIiLTC+YfHFDTiH7ldVjsPJeISsEDKniIvR/DCD Q/18hhTUEhokOyEjWKSqLx3PMhPN5LckiJSZkExERIIhER/rDRps6hAqeTQKdqEek7CBlORIIjsK a4xggyURglIoh/NmfpKzp6RMer6vuoTiNVRN2tkLwsMjowjubKl87NcwEp1EGGYXow53wQoz+bPw rRsc1tFuk3ggbeZ2oKhEGEGSl2dzyFLpqLfH9bfXdP3vVpOwp8c79XS3cERvtFv3OzVWSiCZ2JXq bKuF7//xv/+rFXS77r8JDNRwm4Vp6pnajfjT9nsInfr+zy+n6/fer96f8iUXCo12nV992p3d/8hh UMiw3j/i79QQ/1L+v+v466tjdX/pb1f+uF32uxGTQLVrdd1dfVravP2GkSlV19ev9oecIb8LRjoW KRblD2qBn3QU2F21bVtJY3SHeCI5GNNf+16/iItC1iLTQh2FNsatIRsVFRFcNdaDauXRdBW1tQQq 9QQKy6qIiIiI4MFtBpqdFihfBjQiIUNJitjqIjiM6IsEDCEQwqEPCY2gZgtBaldbjsHEbyC5C0VC KkjueJ9CIiIdlbqCDCoXBnahbyDiJF1p2FKUMusriBDIZuIiIvdt07IteSgJEZlTMQUlUYRUYUie VQYkXFHz4eP7vqi3qnMFtPCShBpncZvlcFB9vPZgwXf1m6wp+6BEepJ8E8vn9F80bmFzsvlIzESz MI7Jo7EqmvaaHX5pFwtCK9U+f0CL/hEo1rCdJvvL5/9OzumneY6r6ljmH6//V/x12T5dF0oIm8f1 unp1+nC52OEz3B+78aFwQwQ6n7d//roRGgv33+v+rnfaXsod621a1pIfhmL/5gW9L8ZdLWv/6uu8 7nf4gw/xQ1gzAhY5xwRHXkSBdtKK665kYexH7/v/167beGGXUWmheg4iIvsU4XP8a/O4y8DMPjtb 4j//+9C4gwhfqci0wuNin8Meeu0nV3VvV/Qwi3xEREQYQjhofB3ealgwlFAz/hpfX+dqBQ5aQuoz uUOUPERBxpp2Ka9imI++f8LGV1uO+iDztyKn0IjQiIMIGCHDChOx/C+TPfTNWYZTinfx3GYR2JZK EJkDxOycIiINC0L1/9GummFJp4TTOyYqlRmIqWQ4jWayKvBAyqYIGIiI3/SvnHotyh+6uFz+qayC aUzWIESHDVMi2T52ScrgoY7M8wE3hbcIWvnfonH9N4ao1tYIGyUhEXzQzsEOSKiMYZzlJXn2YLag ul0mvek+Pr3BPfU8dmgz0bqWicUnWE31aYXTUJnaTzWVn6mcp/Rtf/1+L/5EowESDbdDTcE1XP6V 5oNekaM117VFjtT3xsEMaF31vWzy1/4a/61/6j6jWNDXpNzvv4Qb/9faWx1FlKDDfVntD1+dyo/3 0/b/f9fvEEXSv+sGcH4jpdq9WOYfFYqL+7ntvs8v763/S8lcNW3xax1Hmc48GfdBFLR/cK6trSHa xccM3NqRTznY////ERmPGhaw1M5Q/6/ihycMfHaSEbrfepF9MuvjiIiIwhDQ0Ii01P9Z+znWxXDS bCt6USoG2kpaRYpXJcyBYREQwQjMjTQjP8NM9LFRTEdd8/xhAzumaRFIlAQg0RCKSFoRERERaDCY W7FfT6MI/moIlYUvk4LnbxfJQZjO0hid6mW4aEGE07CHo2fT1RgZ/hegvVoMlcXynRuO/iDyoRCI IMlrJWMTeIiI6v60bvegRH7mcuPbTo0QthDOzUTVMInDQYQZ2FI9L3K1GAn+LZt1dbjCdHe66TaB EfdVzqE4QbRY7RuZFWYODgwp2tZ2aopKva39R7/7f9XT18/pG7pOk6CD0H0+wumXQQZ2Kf6mHPFi O61/////UaEnzCI+Fnc8MnS03VrdTw4U8SUEYyaMjouuJCILHZ2YFtqND7Z7Rhgr//7r/300I/0y 4X9663XwtFK0IkwS6CcLtLwZuxv3ra+r9//df/Xr7ql/hF3FO+bDw8NyQ6sV9a2c5GOUOCYim0o6 tXX1hm5z2M//tqfnav//j/zoZAmRwtfWjum4aHHm6hgwhFqKY2KsJMRUaH/dCrulax//Dx3/b//i Ii1bsJoNMJinX+2/WGtpbGrazjjMK1YU/1X1Mf3FlehEREMJhM/qf44xjsUxUzlQU9oK2lg2nuPv W3S/xEhUIiIiIaEMJqhF2uKwx/3avDC1bdFpFildTzvRFXmsZLMgSOoQ7G0QVCIiIiGhB6xpihQj eMan8mbQZqEVMvqkQkTRpggzIoyFGVLFxEWrF7rpqjW1+ca7pmVcEDhkHnUIdI78QliN5kW7QzkR /SM9G7TaO+/erRrZlP030qPoJhO1IuKIjb6q6FXXfs5KSjPdOk6ujZIX84Tc3vwqZLYvmsiLZ2DR T26//rzNkcKxmgLphfr+rX/S4TYKjc1087rSYQZ2KdD+r//0vv+31cifmmYNWGbm+n8ERvptbRre Xj0CGix2dqwtY9s5ut6TU3Z050dr//91Q47/Vwk6ToER96bWqVBP5ubSx2k/jX7tdrdAih5hK/H6 SH2+i4j3Xq/8/9ufl91VjiPuz3qItpNrERVrjP+cJ69L/+t/Uafbi0LU/4TQ1G/FRVWlMOZyh/8/ 47WD//viP8eIiIYQYIVFoNBoGdQKoRf4Zz+2GEphxmOK/dJ38x2WkVqIs/xEMFhrx4/nOmKwx23p WoM3YZdEebSWh0IiIiOIi7CoHmgpyh8Rk4YrQjtaOxAWV1WOw86jJNCbRMIlnP8REPQiGgwk/0I4 XO+EtMKX0yJnJKDi59lR9hZQkUbKIiMyIjPPczSVChGqNbwudQr2ahLPZ2MDBKovkJBBlPl0YQU6 ZG8ojZlvRCSliIjOiI9G6k7raUKeK1pL6YQiPPo6hVTMk8QrBAwgZU0I+h8nRxF0CKHzvebq+jdv mg0Qt88P7+Z5kQISkQINMiuR8vgmaiIJmEdii/VoMIRH+7ddpC+KTc73dJzans1/ngofW2qo3tF8 0IjTVM7nKdiWWkWL31X+P9PfT/mkXCemKCe/EPXo3UbNOgnpGthN8hhTsmIPc9t4z+v+x+P19b/7 b//SGmlurns+aed++vQ7Xb9TrhXWGbl9/efl/8Y3juo/uKVra9rP1G7+K1Yighw6jn/a+orxFdL2 u9P+9PXlaZcLvQ6n+0O1BMf7aTGl3bao3ToFbqzlZ711/X/ofiIkYhYUwKFP19io2uc+Kd6sLHHH de3X0RiaRu3cREqiERFoMIWhFquaATFL7DC2trfiPaTnuJvERDCEYQhhTdn7NSxTFMbEfkMLGWkW KVwSOxGQzMZUZ2qtSukzuaERERGE0GE0wmEPCUeXz6Xs6eSiLshIg9Bqa4vkrMyDETOxLERDCYTT U+xI/9aZNAjC+1TOm9pkrFXQZ2TZfCkHkoSkHmuMI64UhaJZmRQYiIiI/9Xvanf3o1wiT1tGitzO UMP0INI1iqnBl0R4KpFGiMLOVE9jhkrH90dzxq6dLv+mwS0d7pNoER96FbUIIKvEQwRMeSkJ6hNE 3DCDJWM7fO5otQLW9L//19zQMK6LiP9PX59bo0CkXlAiPuyI7CTrU8PmhoEHRupqfVkCxsR/3WvT 6r6Wv/+xb9QoQ16NlwRN4o3qrfSbptJtFxpVPRDYTOwJGK//ghV6gih2CKHUx78Pf/ML9f//pvQX Q/kSzCMLpzpG2r09N/9WCHDNz+2wqsdREddrGY/W1T/mL12jn//f3tacR+n1/T3v0jPSv2xTFAyw pBYX2lPD76br3WgQrTVs97/8PfFX///Xb7frnc79UNMJoNODONWKwY2I4imIrP9RGh2q2vO4y/DM V0KN/V+/t+Ntf/biIYQuI7QacHaTajBmLOxFNpDhjQ211umEGm0pIc7r1CFf/xEREQ4zHTSvOfP9 qKwbtin2GFEbCxHYSmcp/H/9oRZ+iI7hhBoQef00LsUxUsdsdC83Npe+V1vJpFZR3aINlIiUDEaE REaEREMIMKEUJr66W2OV1NdH9MgsEyPJppmvMk6EmEZJ0J2JoREQwQuLi0PTvyUiUrozs1hAi8DU /qVnCBneZhFQiUCJiIiP7110m1hO656JUKmE0zokyEwmVLCmQkM7UZRlrJSu/ow546M+6ef0rf+E ka2l383uwSOxuOkXYQcZrzCJYZktw/b68iTLhKV1tRp23t0SH06BEfffSfCJu/tF49NNM7yL/VY/ b13V9/1fRnuvTf/XQK0+gRH4Tsv4V0aGF8vl1BCl72p//XRj/Q4a+3+t+aRcL5FIuECJxFaq1dhv O/SbW2Ig9T/t8b7+17OUeh/vmPr/+1Ws7CRcJ71YMGKXdPO904M2//a1bGthc4C+jdV//3oEOp/9 VNBT79Nf8N/+aAQvs9Hxxihpioj5Y5xyo+z//hhLvVIfjGh4zG0z9dL3r3/r1e0IYTsJEQfOjCEX af+OI2IoMm4X388NRXjWMJetqY59N/8REWURERERGhaVoNCPOe/gxT+lggjk3pPS9vq1ybCERuEz QiMyIYVCIi4g44YXNBTlPCXEVH9XpCsrkkXylkmQgU7UBCZiCIiLYiLQi1G0hiLEUdkpFpFqhdKR p0d9pEGrIyL5LUW6UbQjhhSMe1j+CJ+Quht+WOHMDLHDCL5hcEyPHahF0YiL5VkVNEszCKMEGdkx RnRGciI0d91kYdfVLTfpaEan0mmQ4wwq8uGmdiaNSERH73hJs9Qp356qd2k6O+0CBXSdNGtkpE01 tS+f0EG0bmdq1dnZVmQxEpRCDr7GgUelcfvX71fN3enXRh6BEfevSdJu7U9HZMUmkYaphB/16/pf 9f+3bvVudyo1T1/9N0674TIlEh2mdjiSDzLx31ZzwYNG3/qcJ+9/1odtL//v///3vRuUMJVO9W6f fSXdR/FJOvrtehfrbf1+xkeX+yWt/8QxCpbRuzWZ2k3YiryGEs9tBc+tYaV9N6qrpf//xHa9X7dU GF10NP76gxgotri2timI4ijtQEm7av8Ut6gyxyh7pRwYKRxUOx99d64MK5gcWEo0000l7H2rqxFU IPDS3QpWzn6Tdf5amiiMKf0LP0RBggYTOsphCxQ7T7FTDnHOOCI8VNMkOdObnHGsM3X8YxEaEREQ aaFhDQaoRGhBoX1a0KbX5XW87Jka0J3QYiIiI0LU3RXihmcoc45Q/aaZJYhWgyiKWjtQhEXGf4aa ERfo189EWuwi8eXRmiVNNBlYztZiEyQIdpBCVDERER0lf0/Cek009kEKCrnZYC5rRHSw0wg5XBM2 i66f+6V/53TwwhVBCNG6jc0XjIVGpl8hUQrOwTIHHdIjqmhH237kSi4Sr3dK86qazPWaDRVJtJ4T kpCLkpCZ3PwgyVSFlqaL/UVr+966407ozneKCbn/T02raSBEf+yaBFL5/TkHqnaiMMYo3b1BFPS5 8+xFdff974+QX+nnHM+u0bNdfNbbIztfuszlPiMVey6I6I6W9v/ff/09/2rXdISJ5tEf0Yc7/0nm szs8ukCL/uGlQvXcREYM3bpev/7Pr4PX1t/9MIR1vf90+vVcaYrsGcLXvsRVq/9rZHwsbDurS/f3 /9jMJadLe/+IYQtY1OjTtMUPG2lEeHbCtq/+lZzGf/3Edrf5HRH1/iIiIiIYTQtRSLHOPnPFioME u1iOL/8Hev4iPXiIhpoQ4u0GK42v7bpn/atrzD4pZXVc7F0U5lTRGQiIiDCEMIMJG5DtR+xUUOT7 qWkWLdoMlcoQZLcxndowibmIREREWh2mvGh+i3abaaeE7JTmGdjcSkirzuMwiWGCBkqIRERodcIO vPjC66a6ZTiBVTTCDO0pDvW0Z+rzvbQIj91BF90a2FW0Z2jc0XbIrk+ShH+yFZ2EMk2QSO1Hzs8U BinrurX63pL6ebEgRH3SDaToIN9p2Q7tMp2mEGVGQvsujsWRhah/////+dp4wEXSGvp6en6/vRoo SoafcSLsw78GjI2v11+v/695JL/1v/336uYe6Nj+1vYf+r+1fV/19G69GN4f/v/G/5EowE3MST9P 1OdoER9+DvsMKxq3316UVj/9nOH//S/9apf/+aZgIRTMEu9eWkWrQjsUxUUxFMRuF+GF4271tbVy 7Wc7BSPgoQKzCXkx/1X+mqaGP+MRYTCDCaaYW/Eag0xFNpNpRH6EUhEUMEG7CHf/Uw5V6mHMPKF/ xERDCERaWbotRUd+yQ4VLx4UFtRocaF1XflulkIzIi4YQaDCnOtoNCDMCrknOO4jbS/7I6BK1WV1 tBBlQijOyoioQiIiIiItUNMpCknx/3EUxFSupq0XbtSt5CeSEXRdJk0xERFlIhhDjUJqnoIN+Xz8 RZhM6sJsodhCIpT6MrjsujueSnOIqEZIMRERn2VBe6//uLFr0yJRDsvn9MlbIzBFDzojkmma3YQM qaMhQYj3V1r4U753M8oXPBs/DC0q0RQECEcGntrkVyfRN2SuBTWy+EzIWFtfZmGL60r6tbGrb2IW /oiO1pOtddAgbQtdE4Z2J5KIJnZPpr1sWR8IF//9K5KCfBgvcrebQIp88IPP+p40877+nVeEGztR +fSLx59QQp9GPiI/r6j8IHGSqvVNCPfx/XS3bI5r6NynfaT/pwg/fsJbg8fH7qCI4BhIWI9f9ff/ iNfFd6vvpW9bKHNYJhr7P7aCtBZhyb7pFnc2Whm7j2e3S/9ZxyMe99edgT39+u3i4sUP01tdC2xU IGtsM3P7UEGCxra30ov059XrD1+/3y0ixdhCLiwha9xFrfq3wh6sMJN6/HDCv0w7rpDvhgih4xER ERDBCIuNdS3hqmKYin9C41ttTsQGN1Qjk2vEREYRIxaYTQvOd7FHYrWEmp/dpTucfK4JKQtHYSER EREWVNMIWKBnC9MGCWL8KQemd/hMqCJVkuYiIYW+xW+i8ejs1EOoh1Cdpogh2ZBIi+ZKqJQMyBcR EQYIR/hEohJdGho1tho0TKsRT6OxuITVBlSztTEO1YyL5QjqQ96BAiPjMOd83enMdPLct9Nm0F0z sJ6kpERsZKxTsmyPKE7I4QIM75f0C626EpYRftbhB79ObL67qkHCkTzpq6NBWyZduNE3ZC8IGVNF GUeI71/CH/v7/pDdHfzuqN2rReV18UEG5PqBBslHYTJTpxnY3Xh7/f9et/+/fmkXC0O9O/O+8+qd t0g+8+d/LSLFBmzM4zH+wzDmRiN1euIp0P//6GNd2MgiWwYN/XW+57Pdx7dMfehX9pX/ZzXBFD15 +tr31/D8NjV/T7jtLesHdj2uc9jsKM03Fzc2EhGKvZycjkrnsW9UYkBvvdP/+J2Ii4WIiDjU/xxF hMVQaXxYWpEwwhHH9d9BX9fMLX+4iIhggwhGbotAzhE6yx6xq57btQQI5WpFAdtJMEKJ/N1T/luZ oTKvEREcaZ0Wifmgp7FRlT2DCQSphhLta4jH5brYmIiIjCFwwlFio4olWhGDOMqsrremVLIUiozo lISIUihmDKniIzOU8MJMMLvm4p48rqgiN7yL6ZrRHShBhIpxSVCcMlkpF8qREtzCJCJ4mwSoRJWh ZzoRnREREa03e4QjVIKvMPBDU9pp2hkUR3VF8hM7EkdkwgggYiI53KivXpI0CFNjRswqbX0a2F9E tn50+0iEwgyuOq/TkSi4Xudzu6pJpJrt5//TzvueDXhrd5FM6ejKyx6LyRbJ8paKMgqCBmRS+t// +/44/4t+37jTzwR7g73q1/CGgg2unkoggwmTIzBoPtv/P/r/o377Xt66XpXhh/72c/c+ur+vTmt6 aM7/xiuRMMf/tnKz3ithD+/vzRr+rEZA2XCRaMOeO//U8UnanikHLSLV7Xfa/iOKjugRTs3bq+v4 d/69ar/jj/rSSbrG7FTo1gzhLHqrDChCObtpfWlj6ghiM/0YH71fX+6/uNOI+POfN2a7FdbGxGw0 k76r/vukY+c9/6/+IiIi7TtCGFORHYTCDFOxGDPsS+e23ptf3iu+1+jHEREREQwgwmthY7HxsMjo JffhW1bpb+V1POwMQrjUIiIiKi7EU11tVFRhJjWqZ2fUtzLm6IYIRER2g1ofPRWs66N7O3EO1qCR CoguShmIhWRiMI7pnUIU8IiJEIWEiK8tIoX/p1wTIv/5KhQmmqhMmwyEWdHvWq2jdcERul+nCaud moRGUBmRXEqZHjpAgZ2OIIjvj+hVRd+rmxI4/V0a5kJ7q+eyJxPpplTzs1zJ1j6fO1VlwgRd/IlF wiukKvc/8/036/vo3tG9qkfztS06jfff+q/10oxq/c7//punf01zOVGNs5hpG5Rgih4IofU3X3+3 3917b82tXJRG5bW/UtIsXG9DHbneYSERjXpZ9X1owT61/xH63TkTzZ77GOqmp9VDFsL4akTBd/hm G9qCIQdfofX/pod4Mtp2LtDP8dwcGcF7FVEcef7Sjb65z7/90Z8dREREQfHDUx7CWM0DEk4KNZur cYaGMc/qCKdl1oRGE4aZ+rYNCxVb1j6z9QgiOUrredpCO1edpcIiIjN2cjsIenmPmPf3oPK4IGLI OJVF+yp5hAg2mhoRERF2sf6+djUdN07QMhEXgnZCsIMqWQXOxtHZ0IiIiIi754Li/pOwwQ1yL1ov pKxCVDO1Cs65hqdMjUReMkiO1NiMYTnYhfaBF1kYazv/oNpAqemmSkRT0dQkggsaC9pChzjyFZCY IHW0/ek7DZhIw54rt71okPXup3q+rDtNCPNeCom7O0iMR2hEJkrIq0dqEcP+uv8XX1/9zveYc8ae l0bu8/qazvpGeuENAgciudMJoNM6iJmsUE7/H1vQX79a+vbr/6uhvUa3qtG79Wv+qNDXBr1k4Y6z ogieLd2+gQ/X/9f9tdJu/yWuhImGEdzx3+p3ejdSDou3BdhhZqatViF3a/1G//YIV9NoU//9/+vH SuUsyPdPWgmsw27FedMMRSCt4qI2EvfbdbHwzEnZyv9dg2z6nR+/fpQhHj3j6lpFqsJp+oWLtBmG HO9jeMMuChiCoc3TQF3S4pewv/vj9f77WMRERFoMIM5ahEaFpoR934xdSpSH9t1Gx85Gz31Z5fxE REcZ/jzotDj+8a0usbax/ybRGjLojaJQjtOhEREQYIZ/ji7Oe0v8MJJxFS3MhIkidMjWpC87cyWG J2NQiIiIiPP1ipJ91h9H81CEpEJXgih4TTJYy+SoZUZKiIyLoq0SDI1ggYiIYTKmp0Ki7zUf6hQh FI1tGhrhdNbOqVSrwpF5BnaQyIMRERoIacnR5d6JOpuruk2vNb0a2tp3BE6Q2QcSN0liLtBpmU0Y RtEeOzDIvkay1Bi46YIb877oZxzxrp533T6ToER9/pNdJsENGijQyKIIRGE1CDG5GLXkh676vffr utmcYCVdfT+jdZ8PDp1ptJ7OnRS4hyLd5fP6D2e1UZ/ob+3Vv/19Pa7r/yLehS9bmHPFX212eD44 YSQTdejXx2El5h/9nO/6Md5e/tamcp+r/8V7f9fXWxjuxVP/T1in6P/eRMMP9rult6T0NC91+CHM O2z6/ev//SsjIML7/bzdhD/sa8cRxhKNbX219aonoZHPW7X7tTHal4iaI6ML4ZK739e0M+yxM6It aGxTFfYSYimTHO63Q7SabStvbpXrERvhj8R6xEREUZGZyrKHbCaHYpoOIyXrYxj4qI4unSbtQ71J sMGdi210IhoQYQhhBhNYz/YQYQ6ocMJEnNqzftS1NVLcyJBnaQIIiIiItCIkEQMKY+WOUOU7YoWI T7FDTCLxnWMMhep1RvKvJURkU5kGhEWmoQiew00O9Fw6D6ZKRJi7CZ11TNUXZ2TZeBAzumQrTI2i WMqmJ/ERERHTdXow9a7t0a2qd+dmv8NMkZthB5CkQtEqELZKlp1eqbRhzus/tTvq6dqd6OOnRrf8 HhNBot5KghE6yL6YU7JMvkLyny6Gv/9bcaXfraStq/Tf8zh9TD0E3/vNtK+Fs7pnc////+k/7/1d r9kTRxK0GHVIIN7o//+lvW+77r9fzF3rdf161v0EwQxDmbLha+rxsjhO2z2gRH30CI+/7CVpRX/T HQIbrGlvuv1nRBLS/64/jryKIj5hAin1/VtWGk4Xvz/S1aT919AhtT/TCTU///uRj+v9CIjXytxc KVuMZHlsUxQ7scbWDOpDoKxFQwtD8QQ92ktrZunRBDRtrX1/+4jhhBhCLWNbQu5FAwDOFer2MJNr HetfzIv/PZQ/RhwRH4iM/REMEIYV48EO1sV+Rfs93r/qOLjj9oRnQhHEdhT/GuNiKfiK/5NrRQij ITJUxEqEIiIiIvtDhrWrpoZrFQandEQiKkiUIZ/gwQsIXGvhUZ2SgKmQ+yVCJnZTnSKwjWRryMzs yGIiIj5oPFEnpP/rR/89koSaayFJnCziwZ2SjlusI4trGf9NzZrtF3/rXmh56h6hF4yUMuyF7kqi +dgWXzplbUJhDHUd6cmkR1/Cav790n+eb3oPSeDrZKIuYW5G5Q5wSQeQpFX+t/HKUGN1FvOxgYf9 Jt/Df1ejP3Tf1diIZFghD7JQwgzp8NI3M084rPepfv1e/v7ruhc0DBE4uFV6ryhaM/pAiPQRH+Qg 9V6TvjvEXG3VrOiCFWeSHMOTjH1fHr//ZG2RwqfXfTpN8/W0b071PHvr8MLREwvfF6QuoIbqpRrM jz9/6////v3x/+njzQVdG6hHC8GcKz/fn/V1MOUOUO1S8d8jhdcNT/j+v9aW///4tCGne591rmg4 //8MuwrWhF2P/jilH+69L2vrc+tf9YiIzoQi7QtCI47QsV8Jr1ljkx7r8x7qsa3q/wyOlJweKwQq IiIiOGEIzikXaEOOP8RTqxFQwoxF+F5NrRkMQiIiIiLWGhppilIe1gzNQIUILdKSlDMGVed/qQmR PIsiFI7AsySkIiIMJhTz4tUNO1TNQQmnZ1EOmuYR/UlTsEGVLNcXyUxvOmSZ2bzDERERH7U8VXXf TvXTCrarDMIvoOIohMhedjeTO7pK3O537o3fWvQIj9zWyUBE324iDRbuSdnURSJokoiDJJnYmju2 dx36r936Ht+ut6dZx107IQfTueldTrqjOyW9kKrIOCDKhQyBqq/r///mjI4VfW53PFJ+ufrdNhh0 jDndd6LvTw8lITOoSZ2ahERFGCFX79qrfUR+/0/+nffuk4MMa2yKg+XyOlhNLm+3S0knVncGdAnb SX8EKTOZOGHGf/9r/9XS/e/4WIjx74Ij3O53kUSzud6Tow53Qh+ybn1GEu6ycMNAzd/1evva//1C /czngp7X17evaZcKqV7aXgkjDnjDiGt2MGauDOFK/iKtbb21VsK/vQQI5fVCLi2e+1333+t6320C r7QtC07OjvQ7TFPFRFRVqMNQQVXfehxHsf7z/2+1/f7iIiIiIiGE0LtBhMUxUbTHS/Df8fv3r8GT D7xFghFhBhWLQvNlnPp+11e1tfyULtvk2tEoyCZuERnOhGE0IiIsUL1FMVsaFPFU9ODIqRG0draM hLERFoRaaGpGMXLdLEU/9k+TyRJ5HM7C5MguQrIvWVPMIlGdi+ZBWIiLOBhVfhTx+CJ8IZE4kXqR f89w1Wy+bQQM7MGQU1K5IhHO533qvu+sGC2Ff64YW4iGmg0yHKQrJXF8imdi4QlqLUBFWv6fj+dz vYhP/d87hoER92CI8jXRokL00FrqUI65hlS1BAyoQ+22SH3Xx+5KBQxKFu74gw6+fE3QbSb0CI49 by/ad3MFs6d/0PHmcw5T/8WvW9/9v+nIp9MLR3v/SBEfqp7f/0WOce2tCLox/2dlrCZHSMj1GdUF 7139ddWiU5gwq/+9N+f0g/d7WhD2lq/d0hF+CGqhBbXX++/5tKh//peRPMBI//TFPsV/uxzDmHKd 61P+IVqrf2vx13yxzj39iPS011/iwh2hGDEehEHacGcK8ExFWtWlaraqMIX/e/qbs7lDlFn6iI4i I1jwmmKE7qDDDCUx8R/6QZoKexpDXiOoIcm0R2N4iI7CYVsV/7Ebi9L3n1dVLdLCEGlERnIhhNc6 I7Xtb1FsYM7UBEjW1ISCnc87cyCGIiIiIhhDQiLq10YILIdgp2OIgwmQvO0mXyhmEbjtzJNFQhEW fov0TH7hE4qjQ0XDJSIFtCMijNsJqpB5UshWRRnslDpobnpAga8FpG7T06SvLHWE0W7s6BDp2SgK SkTsJnaziOPHwicRoUnStGHO+CI/sJnzzw4Qf90lq5nZ2OZglPo7Nc3ELjplaRCen+v73rtJuxSb hbrdI3fm6jdp6c2nXTTCZKN1PaZ1EowOfQIp4WH3/+//qvuaBih97SpXXuFPDfed9/breOI4IjkY 3Pd06//X9df+LuNb+u9ul3Vv6N3nu2FQbUpQYdbr/r9/tUZFvX//pd1pX3bcigyPrQ0LRY5x4M5Z BjWGErC97ara2qvT5QkzbNAwtnttVBNbrQ+vW1Qj+whDWIeZFimKdjiKYqKCwwvYQimESoLHaURv 6X/SFd5/QiIcRDCDCFoNNBrYoawZwoLhhZCj4pZucaQIazkXPcRxERDCFoMJ2dHmCj9YplIuF9pa m5+hy3SkSbO3FERERERESUsRDCprDSgzg/r0wg0Gd0yF5CIlKIWjmdq8REREcXF5+89TO0bmdmvZ KhTok00DsgvZGkdqaI6N5GRCs7MZWcRFx+k9B/C2+eqclDThpnf5CaF4QYQZU0mpOhvVNre6Lz/1 enBlOEJnZqEq0WO0GmwyWQSTOxZmMlOUiMI7zt6vX8J/eqeFO+d2lVrToINo1+GE6y+f+0yPkdF8 J2QvCDKoinzCob+/49t3+lYnqdzv3Rhzvq66bclZwRHKtadiIhhclYqDTCp11/76h1//7f1v6urq DDpr+rkIP8KjXdfM533UYIbnsEMIf/RF8Jf6/e7/kbZcLIoHavdXmyG0Z9ow5h9OsECb8bbXqOpn 2sfhL8EU7BFDr3tL33182n1+vr6p1bIpl8utLy1NVaqKmpDMFWTgLPbDCTSxC/iI/3W11Gf4Inn7 iP+/3/9CI9cYiGFTTzdDQtWxTrC7WFbawwk2laS4ILdVDuv/r96/8RERfEQwhaghYoGdQooMVGxu qC0Iwz9tK62+v35yO1ybjTERHYWLTCDCYQ7X7sVajGtt1aWrestzNkFQIM7VUIiIiIwtlIjTTFMU 8bFfEUWpUoQZCaZfTTO0MgmIiIiGEGELTQu0NFu7C2je5HvAwgZKYqeXzumdmMloyL5RiIiI6D6B Efem4NFu0WO6P4WzuJTueEDCcZF43neIyC8qSpXVerkHkIjvjhB0EH9XBD0WO0XgfdhEakcKOFn0 kqEJ0dl7TmcXCL9aYTVbq70CI/okP0EHhPJ/201JUKSuVVTJmjoE2v//4Re4T7v1fP/q1cMN4WjZ cJhDmCjVy6P5LEFS/SN1/tf7X7/vErcYCb1gw/er5d1qqTwhU7UBG6H/VumnBk9muvQ+q7VfsNiv uRMIqCGf1Z6z/9r7C9x1aiJNE99r79nlU/3/t9dDrFimPa0ZyotnItTVWKHDGxUUTKjbSn/arFj9 rDI4gII2tX5h7f9p9K3GMMJphBhQSHH7EV+2lFhBXda0SOzys8kYKM5Woirb0oiIzbgnBh4YQ7U1 34qRRyh4QSsbDStY4uqF/52oCNQQuIgwVBxw1OhRsKOtPs95mgzdf+W5LFLyLCkHlIhERERERxDC F5rKHU7lD442r47LovaIpkZqgyQ0RoKHP7O3Iq+dCEWhfEGv8Woj5ePRIsENG74QjOkXNMpxTsai VRfJojOOzCIEhEREZ/z/EQwv/2tN1PDljq7RrYXTsi8YZOC5BYjGFL6nTKznYliLuM//Vbo30nq3 aZ8cJGfTot7pPadOQ2qdnUIp/sgsSkQhWdjjxEe/+Pf4pP1pcIH0CLrqd89nvxaOOnV19SUiJkVy fIVKRrO8WI63/a//7xOxgYpPpLFINrPB3q/N36dF3CSNlfz+dRAUvXCYX3x///X//yJRcLpXV3Qt uRXLwIp2qCanHMPq3t/VeGW53oUUaDN0drfH3VnuY63///31+1CERREwXxV336W9G6gQK9oekI9t J1pXWDXvrv/ef/pdU2h9O+2vGRJlwr9DV/sh6JD5qYqKaWKjrY1iltRXY+30zdzozodnv9/6vvXi 1sESOmg00NNIse/FOrDCTrSsWpoC8/e/j/1Rj2p+aG/XERERKdAwQgwmj6FpoaYoXDSsV7//2tpe Kv2c9+JxCIiIiGEIhphM6I446NBT9jY3t1n/Hesm0ZCJRERERFoWhhMLof02IqW5lKmQcEzXl8qM 7diIhoRaHm5NUM6iHSwULZqEQMlbL52NZ3TJoiF4iIiDBVXcIm9dUZ652E7OxxEyNcGd6ohaLcDI aN+dyn+CtIECujdSDaBEf91o/8ibsocp2mQWO/yUZC0fiL4QZBLQrv4ROI0npDT1/ou/88BoRRKR CUhCZ2p9LojqLthBkhFVyNrdLbXC+t/S2/hDfjqqXbp2lIVAQbTsnpBxDufXuTpNYfv/+v7eThgI vcGHPGdyozud//qyr08+PpvyQ+21iKjMLXs9/9L8jH/Xr6+729qP2r/NBo9Df9Git6Udq34Q7PaG jI37em37ft4MSgQvT1yIOC6bvzD+KBm3cGNiPbSjWo5hyhyh/gwf7v/hVQ3v+4jV3NgvozQtUIdh T/YpigZ9z0Iv50+2/9/CFJEUDkdMN66ng4+vy1NVERENiIhhBhaN3x4hPHx9rU3NCwYdrfic7+ci NoRFpoX4IWhadigZgXszlYyLQSbCThV3++TclGIiIzyHQtOLwhBqIJiop+GCjSybRkvHcRfCZqyr GdpaERERGCYTQuxQvyHOF0bnn+yURhkJErRHQUgsSqL53REKinRMZLMlkQWYIREMEP9bSb1Ro2m4 IRkpgq2mRIFwpeOnkUNEZRysQj+53vT3pN1O/VClzs1CUvrXBwZKAwduy+QrIXkrOW5JGAlOv+70 9JfN1Eh6BEfdKaDRQIj73tM7uHeuShZKxQmSEUZFM7KT2uv/3/9mcXC0KM6evIIp3O8UE2rfhUle eA5nBzwa66dhZoaepfP537Cdqf4TSf/Q/+v3u/0121eltiC/EG2g2NPO+95J6T1152ahJ7cfQ/Sy ONfXXan+2fXv/Bv//hhbXi6tktl39G/V3/6v+FesRz9uopR8EUOwv+/D/f2qJCuxUlCCr9/v0KvH +jDnjVxwZ9nEVMOd+7G66ghH62qh/7W/BCRRTphBEpgl8H+q/7f1+93aoT6HaHp/jYiiqfatpMWs hB7aUQogm1t9QQps+vmPiP29YiIiIMEIizoi0whFiopimURYqChWEipONLjdKt/+jFJutIRERYQa YQi1UIMULFAzBVhreDP229tak2MI7UClvViInfKqYTTzZiq93jQjldSR+OyeFJeILoM65G8hSMhb UyrxOIREaacMIRGha94Qzo0yLtBo3c/qRfTIOILBDILHasQ1I4kxERFgp0e66bqkG9X3IdkX3QRK xDsdl8KE7CRKchWVnK4KhH+jdanjU7ur3/3+cLrzA9gmp7U+iVCEqRHRHZ1RuIXlSRMxDIvD/FJd Lf28nS+/3o2UCI/dU4RN13pqEIpNSViKQqTKnmvL5U0dQn///e1CZcL/7yFF0Nb2e6wV+vRsp6ak pE0b2SsQLapQQ3PrrtL1Q3//Sf/Y+yMwicRfbpJqf9Tu0bK1TYVN7nagIlBgrGrGldYz/BDBSPKC Bgih6MOYcLX/qDrv/FRXdIUYc79Xm6jP67KHLcocJD11bCo3V1QiojoRs9v6MD8O+OP6X63ImGK6 GlslK7OR2N8WhGYcw9hU1sU+6kX2SHUkOs/x+lVq3BEcZjVXPpz663///yJAuxp+hcYQ00Lj4NCD QwyOWxHZ7YYSB8NpT/m7Fw1Y0rOftzo3+9aXERERERrjRu1GxQ4Mf1axdLHdr3HDN11zIz7KsRk3 tNBhYYQhsd6mHKHKHq6p71/G9r/UrgmdlqIhELjWOVNCIz/EOIi0IjPNCM3IYxqdFWIqrs5DyhHf xqaYTL4TQZEZfITIWhERaERF2hd2ftDUfL9kz3XXQIjtG5hc6rshM7CZWUSoirRUkdqBREREREev +gQK62gnSddO9VPZLECBJp2pCZCZL6ZBMwiWowipIlkdmXP//6XzvenptAiPt779ghHNDOl350YT RuYTTCdkoCAgzuCUR/91tpelf17676ST9v9JpNq4XWWO0yUNSFR3PINEV7EfXr/b//5EouFM2XC3 U7nfTe6X1PGnnfzv5cUEHRrahBZnnXUh6eXzNEHHY3cEy6C/X////+3rtrvkSi4Uzi4U0i4X/0u/ boPV06PAhV77+nvBm6hG3W3q6UfqCFDP9qf6G/vqq1///+l7Tautq12v69P32FFpRpWq30viuv+o IUGp+vP/n////qP9O9EpDEZG0bCf+v3BnUDYpimYcocw9iMGYK7rNz/usVx8fiuO+r6V1v83+E17 /M2XCHYgF4jsJhNQhEOwscXf2NhhWUOYF3+rhd6V/JQF6dJfRkRedyo9MR/xEREREaGhpihxx6eu ajYimIpKGtrEfiouCG4z85yMmyTEQwgwmhcaFhU1VTOU4TFMNLf1oM31f5NhAhCQiIiIiIME0Ihh MVNSO1gzhe3XWV1qO/1JwXILkUykZiO6ZC0W6xiIsJp3F96F3eV1MJo1aJSIpfP/lKBclWRzJSy+ SjKyjWRFsqqKhAiJIuU2gtLqaC3p+tN0hr5/TTUicqplSyFJc7nftnsYQdG5V9c9nuFX10a3RjPR D/P+f0b2SjUlCsiYYIVnSJYZyJYZBH9srUXCxpXj77ik3N2d9+9Pr7/qk+6etyCCW0wgzsT//+9X qvvQr7bkTS7fX/71f1c0GvTDhOjQ0W7O1AUyLL+8/0YG9tiN9fre9MuEX3+29v32/Gn5rPHbSbhP mQsJ/H61TOTWr7Z7b9D7+IMEurW1113WyJRcJV9dOrz8gl219s9tpETDAZucNK1TX0lFG+6sYIoe XSoaH/WtOqpPe/1e3OOZ94odDYrfYq0o41m/raQMw5noRFLt0CGCFWrU3f9f3H34tDtToi4aYrYp 1fYa421N9G/YWt6H7+61LzaX7cZ/iIiIan+whcXYhNYM4TvsUDOFHCwwvtpNOrdeuvxERERENCON DsL2KHjGDBKLWGp2oCv8rqWZFUIiIi4YThoMUhTFQu153PMRTsj5UUMiMk4uirRC0VGStkqQiIhg p/KdhhTyLbHz0mgwlfIlRBNNhMi+maAuE0ys5Bc1kVNHagUcQ0IjC/SMPgiPvU8BsNc1CfSLdyDl RTyLrTUhWU8X0yp5CsliKqhESzTNbeqdJvsXmg0Ud9qrz2aKCbbIqInaNbsi/YW0bmSsQlIgTI9Z Bx2kMi2RSO4xv/6WaRcKCLHCSf953Ki+KCenms8V3p/ddJtVCuRfzUInkGC5K4voGRcykLH/3/jT ba+t3/f03ozne+t0vO96dG7Nmd/eqNDy+f6C4TXr/v8/7/f/f1f12/b+nI2y4R//6FBP99o3Um/5 4Litz5nIKBujdj7pR8GD9fV/ImGH/rV/Xv19f/xS3p6GnXxhNzvdW9X+0FYiuyLe2rV9f1a2rf/g hurU3VV//v1/9/3/r8n0ruNNDxCihYj4wZgjSYaVq1/VpD4IV6xsM5ue/oJgk38Rrr/x9xEQ01BN MIWnYpjYodjBmUBr21fWhxt+h2c/d9//6iM8gaDCaGnYocGdQI58KjrEVCQ7UGaCh9r62s6Mcrqk dkmIiI0wTWwhEPP+brgzhLDSoXbSvptL+CBnZ/ERERERcGCef7FPsUxFR/Od0W7O4lIPhneudM7n mRWhERENCLTTCkhnoIGwh8Gd4Ip7z6ISJRmIlECDKwjrkKjeVyWERHFrTrw17WzqEVOQcSaan1dm uL5C9ItzTEa8/rlYGjdfdUtAiPNo0P1rC2RespUT5FMnyLNSFZCZCsimUZ3NLpvEnDAhuht7eccz 6p58PGnNr+nQIj7/66aC8lIkij0yFZ0SkzP/1urerX/t/pkTRtF1T63X7v+jOIXrHkX8INBJnY0j /tKz6nROmCVoUh1bf69/hNCNv3/fTI6I8r9V6LzNBnvdppI0U7xbGvEJs5r//1/76H//xEce5F2X CGkYCQhGg0u6NAhU2bX9fhIc3NG7fxW38RQo3VdL9VmHLHr0b9bXxKUC9fXp750ZnOPHgt/3tXC2 Favubtr6ghTic5j19qbtT/b/6f9+I0LjU/6aaemKa4oZz/rYpjSaX9iMax+zmRTznORtfN/18RER EREWhEMIRGh2mKDNu///kTDER+CFXrEZ2XIjixERFhNCLXPS+/+tRHcVK6pnY2ZLs7G0dUIiNBxE edGbyh44MyfOdMoczlOFs7D0wgyWZfKjBBplkUsRERaFxqY8RHEed4ERoaLdhO9PLo/kKjueQXOy 6I6OIvHcIwioQIGSoUlYxERFr0k8J1fRrdJ2SgJ4QiKCdpmpl8p4vmuL6aYTKlnTJtRD0dzv7Vud /0/6X67rhdbRuaNzReMigYklQwWcrKgoQUSlbEn/bp6dLs0zBKvtaM53/PB8o7/QIj9oER+03SbS bQTfDJV5KhAnDCZfU7iL6R2JL//+uqH9p17ZW4uFIlFwg7f31vW87+np6eeDWp4B7qrrkoCrZIaR 2Yd/+0jH+9cm98woj/9VXS8zBf9fS7XXWxpsX9FjlPgiP6O+9dNJf/uvaV1jBB9bDv9T/qbu/vr/ /v/+lgiyvcIWkm/3m6gRH3RnEJAiP37b49sK3a/DrDN38Vxrdb0p0X9/9J9967+lHXX66+mq37Ua GxTEV8RtXxuv2k/7+vq3Xa2v3/v114t///EWFM5XWE0OvQtC77DWI9Y0o0otW0nqGvQMmKDs977f /+0cSXxhC4iMyIiIjsQmELsUxTFRUbDCTYSOuFqO9fVf9Vv4meIiIYQYQhoMJhBppimOIQM4XYio iiUBb1iN9KV1rOzXIQQ6orOd4hERESWwMEwpMtz2UPaahMRXEfSPoJKSwKpB4IMqSKtErZkXRGI7 NMRGCERcMIMKbZ1Oe1K4XXpzhJ+Qzp2mSlWaxUDIvHZhqUNEismTOEKqkIhEREaEMLvv/NC3Rrad po0aP6H2mdZU0lK8ZTwjfvbPd01Pz+n3RoKHST3zPqeKND1OoRGUSKRPkTifIpk+RMMBBlSyFohe QiJZfb43xS/W/SF6bfqa9ek36uF/11RY7VMlQqhBlXkL/xpSQ/v92uh+8af73bSn9Z/m7XXWzwaF CDZKAjhbmHZqCEqElcEDCzhB//p9+3pX/WGIJIY6GO+8aDaTpaLjpBvC6n7zDlD7oEN0gQpz14Q7 8a9puvY2NL+dzwyKJYQ6To/5uwZt/ez3Qg22tWvFWv97amM5kdLowRzOXFfv/0y4XNbLhKbUaG/x 9RQM6kKBmB2wlP9tLXpUIkRAMjm5GJBmKhedFGP6///X/4jiIa2ubGxXxTBhKPkxzxCHn0EI77/v tftqf7Z7an92r8Z/iItCIYQuGmKQ4IQeWOVBx8X//thW0ruhXImGB96hm6GboiIiGEDCmgqDjxGE Ih1Z0RFra2KY3Y3Vb7WMiYLyuSZdEyMqZkEhEwhEWhGbkIiIiwmELQvMeOxS8LakDkwgyryIzI5k tSi0IiItOLCZ+zI14InTo0NFuyngp0ggylmYMqJMIGdlSCnZrGMTugyVjJYQiIiI0CI/dXpN02EP 9Pnh0oUlGYa2QmVGS8g0GEztURBMoR2t52JrW/rTpOjDmHVTu4U8aV4InztWIdSL6adOdKzqEIe4 ReMIvGi7DIXkJhA4sihlPKv+RB5nFwv1dVdb0k31m9chWq9Tvq/S+EHoOgnJUJrrRVdSERFSX/H/ /7r/5my4T9zCVNGcqIInEaW995xzv9bq6bS57cn+CKFl49BNJPBfrNBQ53tT/8x9f2l/6/xH0vC+ nXrS37333Rhzv/N4YfS9aBEcfOg+pN++qEXH7S7/2NLVRm7Ecw/9uH+v/7fVa69bZOGFvDDa1+qa /BXsR/qxathe+liqq9In2v4r6fBFOwtt6r9f/rTWDYx/q0dMwE8InEbCkhqhxWxurhfmHKHKv422 qM7L7H2Eoivwhx2RzBFD82l/mRtP+I+jiTuOFnYpQYWKLHOOUOUPDCGhEMJRpoRDTu8Vgx0FY2TH T/C4iOI//iMEpoKy/q845Vrh6cRaERBxERERkti0QcdhBx4oGctNTLHOP7tfwgR/oXBmsER9/FR5 0YIjjMJg4jQhxFoWtpphCe5j2mMVmPCS/Q3EffqHVuV1qMipEZDiIiIiIiwhEY5IHrf/DGdivK6m JYQZB5V5bgRCPi6MeLUkMQcdmQmIix2dZBnTyuDYQZ2dEpU6JF0IiOIPRsQVBB9bwmi7aaYiI9IZ u03U76srh8ztBB/PRXVcfQ/976Cbq3/JuTV/0kn/33V/TPrZ5X/+l+uVplwt1647Loj1qxpAh/v9 NhAsrlIY+nEbaVLX+XRfVhI3QhGr+blsbSgzrhBaoRGPcw+ZG+Iz/YQsLaSljmH/R++DWIiIi0wh OY7taocRFoceaCnyupZZQJCI0PU+ivGa4jxT5fBEVm6fp4Vwm2W5Ggzs1RGZVYRv665b4IjdJTmG nkV7K50Rluud/O/VJtNPPWXj0dRIMrmogQd8yJQwl2l2Vyejdp6nf/WpTtUaGTcaVDX31cJ0K3SW 7/ow53hhomOUPScEyPVmP9LdJ/r7b96rdhkfghem983adv7r23/pDiP248fR3/u1jVu1as52v6T/ gicf17tULsUxFChtpMUs3MGbtt5DG9nv6+I001x611b6wrgwtr9REZ/hhDT071FQuNtL+TcWxERE REWqqeDj2KuuV1WLo7g1J8RGhFpiOFsJhcimQaJYR3hktjskIqmIsKvNDBVL5/zowTTCYQMhaCDC kHlOyIMl2QRkLQMLO/SbBEb61+0a2i4aLeRZpkUyfCLxhcINMJoMlYyWGTPH7dOETHQ+/U76em4T aDdeg4Im8h1o1tGho0NGdphBkUyjUkgyWES0zvmd+q+ugT35OD0k2laTpOjQ9+rCX9PTaTdB0bKL jfl89JphMJhAztLX/1V9V9d/+m+NXBE4jTq2r06TfdN/Xz5Rrc0NFu0Gdqau+k/D4jnwq/1f/7fv wv66/+np/90rp0m0E2jXX39pQRHIxuovHulr+/PBxynr2v//+uux3+63T09N/YimGFoNqGbvtLat 1a234i+XwRQ+MEKtW8x/776xZdL9P/av3aYqwY3d/WKYYVtJhsa8RGjOy/tpaW2lrr8x7Ef//17x YIQ444tBpimKd/kh+GMMuwV8ee4YWGldWuoZY+1bX+r9KIcREGEwmhaEWUi0aNoWISGEItimNiq3 PVpWlaVq6QIfERERF3DUw5Y+Ycw5Y9phNO7uxw0mGFbStaldaxcRoT20IuIMIMIRGgwgxTEJimKB naaCupLERERERYQaaa6eIiP7G76yyaxaQ0qa2WkDEghWuqRd4MzIrwg+hxvcXPeOV1rWV1QWbsKW S88cIc/VCY1F57f97/lpAfs53/jbtLqxH5usItIYyOFiIMFXEZ//lcEyf/4/yyV4/y0q7HyEaf/I O04nPLJYYm5/+vzoiXL7egUR/i7BxLSrz57vFZEac5mnoP//////////////yA6YUf5bQ3xkBoLx ///////////JvrWo/+QHVf4/LMVUbcECUEYfLMGsuiPl4EkoQUZZh8jxjI+R4JsIFoREZZyRGER2 RwcjtRERGWcWRvI6I4qFIw53O4QjLPXkfI4ZRenwIRGWfmXDQR8jojowhEZaArMRHBuR4xiIjLQB I+ZHDBHMjkR8EqGWg6I6MRHAuR8j5HYJSnQiIybi+ZBo4i+XiODBHMjsj5HRfERER0RdG0XRhEdG EfyOjGRCPI9mEXy+XRHMuLBoREjHOOcdSgGBBKRG0oW0lUu7BAqLovEeI6L+X0yPoIECT9YIjgkI ITOaChyoQiIybiiLhCPEcZfwQdIJxFIRY9qF/QY7iEqW7KHP8WCERGTdXkdoTjiJxxHOOlouhLoI I4gaXWDTCKHC6hJJCIiMm9WXdIJFWmcckOkccoc46SpUoMK4KR8j5H8JJtg9DQiIjJvTI+sIKLSQ iI0IiKSBcJ9rd3DtCIjJuaoubiIiIiIiIiIiIiNJFAJghNkpCMf/////kB1Io/lmCnH8AEAEZN1e R2hOOInHEc46CmVuZHN0cmVhbSAKZW5kb2JqCjE1IDAgb2JqCjU5NzYwCmVuZG9iagoxNCAwIG9i ago8PCAvTGVuZ3RoIDE2IDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAgY20g IDEgZyAvT2JqMTMgRG8gUQplbmRzdHJlYW0KCmVuZG9iagoxNiAwIG9iago0MwplbmRvYmoKMTcg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0Nyb3BCb3ggWzAg MCA1OTUgODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jlc291cmNlcyA8PAovUHJvY1Nl dCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmplY3QgPDwKL09iajE4IDE4IDAg UiAgID4+Cj4+Ci9Db250ZW50cyBbIDE5IDAgUiAgXQo+PgplbmRvYmoKMTggMCBvYmoKPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmoxOCAvV2lkdGggMjQ4MCAvSGVp Z2h0IDM1MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9CaXRzUGVy Q29tcG9uZW50IDEgL0xlbmd0aCAyMCAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29k ZVBhcm1zIDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCvk25S3U1xH///////// //87Sl487S1H///////////yC94//////////+WxUi0IVIZBcdR/////////yyrSLWULjH////8p lZUf///////////////////////////////lspFJuDzCKXFnFYvnfyyuJBAmnl8/hc7NWEztwlBq 9arbGtGm533/O/nc8NG9add/f3/xLc1Air196r6+//1Yjf3X59PW+n9YpYZu+wwr6hm7cVpRX2IU RTuxTVqI2E1W0MKbnEGCERERjLXxGVVJukjtzLOIRHRdBMhMheE5XLcyFxAgwhEUU6I6UlSI40CI 7LcciOW1mjhCNCkE8fRupNzwbKSJD6bRoNb1vTjVzud2jOnV6rlcDBeh8ssNXXftv/+38P////sx +e9WDdX9/dbTX2ZDQLt73X/9pMRX+KLKhMfHxsbLhXpF+U6aFoXFphCMRYQuGEwQiMREcm6RFoT5 kXR2fO6ZbuJK4mIZFKvTOxwihOEGvevM5n0X7u65s6CdvCfctBC9ISlZgf3dXrLRAYMvi4R04rd/ /6e87nH2v8EKnRGb9nIVENtpXbC6+pSgX1j7FTjmwJ7f2sMKFYQ4ji8x4uIxaEREYy1irNfLTWUY yEzWQQaknmM7SuVy3K4Uj8E869p3DTs7U/lcSad636NbO0qg11ug33R36vT8zhoECvvRof/v62dg vi3Se/Sb/X36fcG+v+3+/r36nRBL9V7eCH6ghusdhL8EKtsUlfVXWhCt18NsGXAJiMGZQOc+ExFA zNcw7tC09bwTXaaEGFQMKqcMEMRERERGWx5SbmEWUbyUZ2tMkzKuCDO4ZiLeeY5Ny4h2a5hlk1EI OU+kGEygF0TgPwn1TUK+mjRRcOoIPTa3RMfSBEemz/TZtU3PZ8q9c7/BA1VPTW/6dOKV1e/vUf8T Rlwt0u6++66X//+N/f79+/ufWvZ7DSN9Yj16zCW1fXDI+nFZZJhgfmc7+6tYj6vqhG4VXWhuZyus MKw0timIrtcm5hyh9b9C7FMVOe09lTQjBCLQiIiLCDQiIMFERERGWsWXOmRtFRnYEjCLfKVy2Mi2 O55ZCEfzrGI1I/nakwl2ahCfKMJ3IO03K4uJ93pp6aSnrX1tuFfV9AiPdoziF+jZ9AiPvNZndG6v 9U+9NNv09rX078TIDZcKVuMBCvUBD6/X0+aRcKoxr6//1X/79zag11ff/+6N3n/NpBDfwQ/tDdn/ Z5To/v9s9j4/6UUtWqow8fkY7+9deh/77JuccLVkxwojz/8fsRRXW1GPa3xEHEQ1hx330WOcf7Qt Zvi0I4i1OiNCLCENCIYQYK0IiIiIiIxLTC+WZyMjQZ3RFQjLV5BI2ybJFK5bFdYyuEyOgrncNM1M JoOGQKTgzs1R+OxuTlcUD4QjK94Q0NGHwyICNd52rEMhQJr9VSDcGlU8VdUs2dH+ZLK5/o36bnhz jmev+jDnjO5UdBsrlYYJwIO6wIxT8cdxBtXuvfp9U7v6//6/v1/re7x0ZGbTPo7js9ufXRjJ8Ev7 HBDu3f//a7Zu7WGna8Qn9tUnf/lcVC/09Icx8aGxrBdraTKHNBTrte1pNYiI/+hwnY2KFxHihYrM 3NVP/5/zzSIg7oWEGsQ01aERERERZ0JxERGIiJWuVxvMlvLcTjIzjsWZkWyk2DfMi0FztIy+diUE GgypZiITCDO1lGIIGFO3ZfOsXaD9FL1U7JhE0Z2hmoRFjsENFjwVb00aHkEkJGfDJ2rrNbpwoWgd UEGwRG9AiP9Iz6fdTY4YLO+0bkk62Y5/yTqrn/uEhrdXvzFnOxpwYgkt8avfxne2rqNWEXf+t/fv 4YL+v///f//0v+v4+rfWq///UH/3rEd/W+rOd8Rwzd9usM53zDjMe6sdcVtJvWLbC3H3UNKNsLQY 2Iqlm8ofK5STGxFKxUx17GxrFYO0GloWqsJqf0whGf4tBhM/wwhB2hDQjZx0DCEREREREXEYiJZF RFuZIaZLEV/RJMEDOw+TcHF87VmYzswM7E8yW4JGkCBmrIMzEdpeCBmqNYLhBkzDBDjtGXdftdNL L5/Tz+/p0f6RfNLPYQzIxnXhbadGt6aCr0bP03o2P5oM+E8zlx7Xws73q6fngV61d9P097SQdW2q bfRvWr/pOrZ2MzARWr33fXOwTMBffGm/GnusY3/fWmvT/9/p/3/X7e//++phyo+boj9Dfedyhyh/ of/4Q8+h/urqNC/72vajiL698drw13pQwlaXxFAz/bSn/YSXYaU/7CW2lN0pQL2I2KYr7+PwxT8f sctyhyox19ppoeY6HDQ7CHDCHDTCERaF5yFBghYQiIiIiwhERERiInf0IHJuXI7FY7G87EsrgxkW GZKuaxkZF8ImOGdmGXzufQZ2YEs7CenRkCd2F0EDrk0rzRC/zXnQeQrwi7q3Ta/0m5rv2lf71c79 J533vpyZZcyPpCdiEbRhBfp7+6f+r9/+EIkkIJoRW68f//dJfX9b10n/rzH/9/YX82ls8hm5gh3z Hghtpf7avpAhW1fQv61rq1W8LaUa1YYSp+sGdcDFeGYII2IpjYoGZqrTFCM3RfakpAnaDCaeGE00 IhhW86J1QiMREm6EIiIjTIUi3oR3nJuYzueRmXR2J52kIJEVRhAgSZCo7pkLzueEDhkCzunJuDFO 3FC2dq1qFCERkpCHbiZ2a9ovHDIxawUJrp2jWwRN3Sr/QeU4af5d0XaQIj9+lYWmeD5myjZ1erEN 9vhNUNb77gicRFW0hoSUIjojpX1cMGXW5W4uF40vv111vksBf/i2ta916S+Y1//+sIt6avM5T7Z7 c+m9QQ2/Y/s92e5yJSwxZc1OzXCQaBCmkhbk31DEX9VYSVGeXrUiYLx/URxC6HWqURgzQVswI8GK Yr/BmGYVgzbmvMfNkNY7QO1MfP8d2c+FWLVp2g7CamPENhppqqEREXEYiIiIjQiIiMTs6MjMyuTU m4jNx3BlPnYoZ2BkVxpEZmEFIPO7IqiITCBmpmI7JsxEJoOnoPhplcukwqZoC50WmprFRcPfbNQs itVV20aGp6CNFGt3r0naNElQQKggbq6wnB6eg/03T7wRH3mg1vdJtJFjlPrp6ebJ3h61t/db7S8U nfp0ZzvhCO/+kIJe923W6ztOGfru6v1v29f+9FtUk69D+3/+v99///p73uqT0Y3WbSCHtd0CH192 e/vvs5gwd10pnBEete0q6b11Stf447CthKLJovFQ1x41tX5IcKIphpMngTDS7S8MUxqh2mKa4wxQ iDQtMUDixTsczlPZz2EwpuUjapIDBBhCKJuU5x7CwwmsNC1QuIiLTsFEWCEQ4iIiIiIiMRJsjloA jK/o7JMwrJPMIyDjEU5kGRT5hEZl87PkHSbg4vHc8p4vhMyNGFCpw1TITO6aug8KqdncCnQJXsLz QwhrwwrnUJ9o0So1sK4Xq9LaTrBEfcpzgiPaXCdJvQIj7zjrRd0Zyn0d/zvem55ztXG2k3gw0nud zv/pyj69JvhDi/uytMuEX1yJgwd1gRin62yM9ddspUXC9//31e03/1/fu//oJ///12v3Wn4/apqb r/6MHmD2fTXtYROO9f8/77qPa96bPf9Rr9bXenkY8WFaqdBvdb+P66vet0sZ0C2IruNJtJ/4xYuo WxFd/sU2kjHsRTEUqV3piooREZY9jhbuxjtMftPP2ZrwwhcNBqEf2FWGELTgwTCfaDBOHaiIiIiI iIiIiIiIy1A+WRURkN5C0QvJUeSbMjVFQijKXnd5hFOZ33LIL6ZkkShSWJUGdqmYir4aDOzyrIVW ZOceqhMKX5ZAK6Lx/MjhCUiAhot6aDNQkNGdnY//DOvghraLhrfv101QTdIw9YIjtIOr+jTe6hXp 0CI+/ffRuo3qf9PVOjDndUwdW9/hv5vzx6uvv+9Djj2djAI/rbEHV/IlFwppFwo/0Onauv671/+/ v9X+v9/969/pqxHbn1fSNp+vzphLUv68/3myTygihwYVs99br/BCg8MxQYWGYr/j/uIVpWVgMCuN PpIRRQICKH2q3V6WmbsaFxtq+0FtvhMdNP+xskOkI2I21YjgzBP+xQiwtqKgkMGdajoIGhkxynsJ imrQvP9lTU/2EIaFqk93mJ2EJ/DTCYURERERERdnIQiIiIiIxETITcsgkzIriCsghmQNGRbggZEI gSOybMZ3SpkRF87EoIMINMqWmQrITO1bUhcQcibtMv2dzuylAvRh2FzsmERY7RY7RY7zsmE/bJR5 09BA2Fs6edmv09Ug2trQboOgg3r9PvvT7/vVzOW/Tzvef6T03T6N/6v+6tHh/f+MINy3LCLkR8iQ EEsS/+NWr+RKLhcSJhg0jAT+/V9b/vfehEO0D7/+v+/9f691+v//6LHJDlOUPhvRj/7/+p+ujOVP zdutdLrawRTsJAinZHQS1/NpoRHb1/Wzlq62o7wzdjjW6kUDAIdresRxEd1a/94aXfUbdWk2l8b/ w0mqbViKqmO0rQiIxGxGrGxUb61vsUDOEODFODPuh1aYqKtM/2mgwh5ui4uGF7CYXgwg1Z0RERER ERERERERGIyyCiO1uLcXiCxXCIiuZGjluqZjJZF8lkR8EGa8IMqWQrIXkKwgyni8EGRjI+dgUXyp ZCaZPk4YOxvQcJ4XC2g1P6feRf003RY7W07zWLFqdq2E0WO/rpOjXfnv/6Nleg2rpPhXmgsdVaCD 0d9zvuCLrpv1Df/dXO+0tGfoEXXow5h1PZ8QwgbpGfV1390rvdvrInmAhE8wEInGAm6ul9PXZEKr siUYCVTY4pfVq+vS/XXtfTW/XX/f/0Hr2v/3+/v7/a/Q/qYc79GHPHRnKHKH9f63mP+H9VMOd/39 fX31fX6dfUaFxxsXEXBDdbqnS76YdtY0L+5P5uvj7XfV6TaraSN26//q0m7WGq3qHY1+21iKbVoL aWI2IqIpindj9r8GfYoKiKQjDEUMV7xSbFNbFQ00GnHaHFofaDW0GhxdnOmhYQagwQiDBCIiIiM5 ERERERGIiMsiUi3KcyC0VwRS3CshcQrQM7FchSIXkKwgzsVRCZLo1mpTxfOz5KMjaU7B5ri+dzpN FIILEHFSCbUNSL6ZKPJR2mmdRDo0G9rZ2a65/OmmUGXLL5/wudjhOw220a2/re6Nd100E6vv+9X/ 9rGW5buaC3c0Gd0/vv6Tao3and9oER/7v7pGiv6O95/4Qd6DvTv2dk9e/+s7LoxEddDS9df7+9U2 /lKjARfxr6+k3e52Mgh+1/4TiP6f+/79f/7X/9//+pha9Jr/mFq3/f19IfX8R1MOVF/v1/+90ozf BDBCgQ21sZvpnONLrfKWGMEPSSDjQv62br+67a7rutdWkupoGGlYa2qtT/qNQz/+9KPGMUMMJChH 4M4UYKOFiN9XVimIoGcL4M5dBffYiltOxSi++ovMiLQaax8NYuO0z/hhBggwmdEREZjxEREGCERE RERGIjTiIxEyOiyE0V58m4EjumdraCDKoiVmS0jsUyEyEynzCOrMR3mXyUuyoyC5V53NEgyO1lus xCpTtxDtSSaDTCDTOyfnT8J3thbuzUIShp52asE0IqW6kEJSISoRU9GiSoSaKNbW/1603ha6f3M+ koVGy7pNqk2k+/fO+6dGf06N2p39TvpnzRnKijDnjMOd6TXe87lRp+/3NaVL/rvuhpKzTOIjpaSx Sv379buP1rbf07/mbI4X37///TBCP731t1bf39XmFr+YWv6X/9f9X9V/X7+/97PYIbpW77aS3R2X DAIYz/vSv+r3PceM/4/W/v9trGlar/ftrX76trftrG0vtLf7Xte6UGYLEfGhGxQMwMwPcRTFMRTF Lr3qxXY3YpqObrqLV09DQaYTTCm6LQ0LtRYQsIQ00IzHQanQgYVOIYIQYIREREGCiIi0404iIiMR ESuOjtLUsgkZJ5kQZK8qZnYoiWEp1yNaneIwioyoR2J5CI7OpbhcYiVRdkqzDCZQC52NyDU+kGdq 1aZFQwp9GoQpQLgnZrEKdBTtIImdxgtQnp2nNDo7SCI0PTRoraNbXVdcKdAi4Id4Ij3O7Snek3PZ 8hKnfSDd9Ozwa/aLzPZrzv5sqjddLVPW9LdOK3O53q9vXutjTvwsadLtJqdzvoSdHsEUPnc76//0 /0/t9uvb+6t3WKV+9D74TBCNdv+v////ofpb9LH/63/b7/0t0u///t67oEPSMV6tnu++mzn9uexn //Y1jVjStbX6tUbrrVrT1NBT0Pp/i7b49f+utKw0m0u1hpPwwkyhzQUWiNhglQ3sMEoil4pf44YV BhU1sUxuxsdOxQ4px/NljebrXN0XFqIiIiGEwhYQMIRDCamQgwhGEHDCBlCE0IYQiIxEREWnERER ES2C1REr15G8yFcZZTXO1aOyvOxvJWZBDNedkdkIEKcyrzswSy3UkbiVZuJVmGd0jXBVM0dqAp2T FCYQan0FL0GoTKcVODhNO0008IetBNFw5o6r3MELhhUa23dAiPaBEeane6Ix/ozlPlwqdJvtAiPu drDqE6LzTzuD1T1T/fP+9xdBB0m6d6pvDDbPatwnINrYhs6sw/6+krlbi4TF/bofXv+5EOOvHrDa ///r0+GCKHj378jH6197/hX+u6X+0z/s+kI9z6dfQ9rBE7owOtnvujphBU+KWNWNIfsLMPO1YSO6 tZnOPvztTH7dE4YFtUIQj11oLrHR/CS2rDSxdiKhPnuwqxUFaoNbW//Cmc47Ypiq3hcbFS/KHuwo iIiIjP8RZWxNCGgwgwhEMKuwwmEIcMFxERERERm5CIiMRK5LS0CmQtEoRWslbIIzshFQijIsju2Z aZ2eN5TmdwElupsvkrZfJWyPHc8qM7VwIoeSoWTHOOYphBhBnduzW7zCM0dQgTKnGpkeISkEM3YQ Zqy5pe11c7NezUIhGsRDCot3Ldrr6aaot3Svw2uaK87VWgrra2rrokPkIO+EHQToER+0CI//zDlD 4TegRH/ZEek6TegRHvO/ne8799EnU/Ub82XRuraV19bfXQg6vpd8+Nurp6p7Pf/9d/ne3vjW9Dvu lul//1kUDFeZsuEV33X/Y6+v1//j6t/r//92R/H9ffWvtJ/9K/v7fqC/dufTrtn17963qxEVd5jm R9Wpud//687VWvX19IEK/BFD4NeuGrdWr9P051graX7fQ+/traxS+IqNKNWrbo7UBUOGoodhbSjW Iwzc0Ki17iP4YUWKYaTrDN12KYoGdQo4WxWxTFMU01wkNqmh2KaYphVHDCDCYWLU4UecNT/DCDQY QYQjPuhfREMIQwhDCEeIiIiIiIiIiMIkYiM/5brWQvIXiIjLdTEJUISoQrhbOxqOwJFbRCIp2S7N eSMmjK4ojplIiFHChQkd0ztSggyFwQMhcpVMjoKaxhBhBxhBkpiNZCZqMjx2YFwmX0HmcotMCm2j IOLGHbosfqeghGCot3LHei357zpXuFz0to0dClgraQPwg3+skO4QdBB2aDRpvu/QIj/Jv9AiPuk3 z+5/c+pIdTWeNer0/P9G5LaVpO6Tb9bpdkvIE9vX0+Nji53uk3a2RKLhabI2y4Rt8cd96b6e6Jwx XX3Quv/9a9uv3/XW19//H7//fuD//zQUWHCz7n/915/3TU3UOzyc+tXX7VDnRCZgvS3PpD//Q//a vdD/j62nDW0rq1etdCm/YUMjoKjD7dbXn/P+fXe2kNhdWwtXN2M0Bcn47VtYYWf721EYoRuf2Iph hLDI6CxxexxsU7sU/uuhsVFMV3WGZQv2mPEeowmEGhphC0NM/5yFJDljsNBhBhCItNBhTziLCDC8 7nfLiIiIiIiIzkIREREREc4WhFhA0d0xGIiJ24hXqRXDjItzumVXOyWO44U1xfOxPIVWUvIVhBlR ncReBAypYIMq40DBrZfO6YQZUWfWWOU4Sd+pfP+RetFjs6Wnyx5LBbKcRV7Rnb94Qik/Xr+gg32r oJsKjWwlNBb0CI/0kH/5/QIv/1v717oz9JtEY9J5IeMIPW3199jrs7GZgIROLhL8iUYCfv9d087p 60Z062l5W2XCbZpFwr/901XfW1a1uv//u+rbp/9f+GCKH0aCk/WpsujdiNqbqavSZdL/r7+Y7+1v Vqf+pf5/oR6G6oacfcawQq8IRV1TdW3uu/9P0P3WP/P7pr32DP/6bC0xa2vrDCS+rYWNe411n/gw WIrpr97Bm2KCgZtnFMU8VEfFMUxQ1G7/jDCHFoaFp2E0wg0LSIg8XYQYTyxyh40I5GPERERHERnI iIjCE/jJuIGIkJiRJCfxEaZ3CKgIdiMpaKlkKR2DjBHfIwkynRhGQNGoIQiNZGQbMRFOW6my+Stl 8InAarkhEoVkqEshUnDIXhOycMBOzrF2dnkwkdNU9vL5/ra3CD5/m2Yl9U9SL+SkJTO/C+F1T+YG 7RcOv1oER90CI+6Tf0v9ou/aVK/O+57Ped7dTv/3QT0676+vp77Pf+8Jrecc8a/9xSb/pbqnPf9/ ///99jf68fV/fInFwqXq6/1lKDBEwXi/p/////DC8WFb/XtvHXv///V6ftfYj//2qGjbAhghVnsE K/tRn/6uv8dM6M6KMMH1e+9fVuug6x7+9Lv1e+r/rfTatqGb9iKY0rCz/s9s/wy7BYZcAu1hhX4j YYSiKoKt/nplDmsFHFP+KYr43txmHKHKHtC7FMUO1FBoNY48UOLQaHhhBoMIRxFqhF8WgwhBhBhB hCIjbQYQjERn+IiIiIjNyEZNwLESbBIRqdwzszR2kM7Sed0R3GZOipIqEdiaKMivLdSRuJWjcChM q87SCEFkGQuU+gUhUahCDjpGJM7WQpBxqENQp2TV2TAhXSVNNNMKix3hIlIiNElQmmCko9dQnSWq p8Mz1r3oER4ESjCDfJj1SbXwiUd0XfeCI9zOUP0W5Q9F37h6Lz6R41ThRSfQIHnHO+nRhzvfCj2g muqd6EPwhdBPWQ2sLK+qMRHX+/wi7nQCOzOLhaFXf63bwi7/iThhf+zSLhFGhJe3DHihEf6/++v9 W/+5If/T9LqL/3D1///w+fT/P9s+nb/9whUHgh5/nQ7rfaRutntz3DBCgjdbPc6OPiuccZj+1H7C /2tt8w5h87jMak+gyOgvsaqdrQUe7BY28nLQ2+0FcLgx9MNL0P1bSe1xbwxsm5xwkIj/XSrQ0yrg Zk4X/ra8OIsb/sUxVRX4ODiMjHLHvhhVwn5FHyx41QzDlDlD3eIiIg4YQuypxaDQhoREH5yEIiLT KUipqEZp2oQiHEbiIiIi4iIiIiIiIxEsijk3GCk0RlEdgaOI7FERcQ7eI2jtKyUxvMgpLK4uZ3pk L0Ga0YdkVwgZKcJpkoiFmEwmVPkYxkHGoUpYYTslbL5C87HCgpqZeK6TggZ3gpKxUXjTvL5/Onos ep6289hCpvZKxIOjUECa1rkorSBV7hMKFQQfX++g39P304Wew1SSmg0Wm0CI/fzRCJRQIj71mnRI eiQ6+p3a/VpO31vU3VuYc7oam7OOZ83RoOvW+9A4QIj41/QQbneHneG6v3/3pt67vabp62wQKm1e 6Fbp1+t3CBfdkoMyEgx///dL2//7+rx//x/f39/8bv+gQP/9/62vEdhK1Qu9D/+ww/+z6+1/BDWP awRFHBzH21//jYpQ4Ib0rrhY/wwzrEdBX8EU4aurdetHY4WYeY71l0b+SHXdd/SQZ/1YWbsVN0i4 XtuiHAkEIrtUI4aTFMRTKHM5xwksGNiKhA/dim2PY5nKHKi/4M+xQU1tNcKalqOIULY02KdocRhU HcReoMENDTQiIiI7CEQYIXZy1CLUmXOBBM5CDQYJhNTjUMEIxERERERFhCIiIiIuMtJOZJMS3HzL 1ybC8V1pFTQQZLRCWRLsyLSNQQhedw0zDU7nyuCo7gYQZ3bL5Co1svnag4ZKkmdk0bZFpFuGFBBo MhI7xGIhVpGtkeKcUIOIyDiVCmQ0F2mmuSoResIUCFSDiSB5gssdosdnTcEK2U+dRcKi3clE6eFT 6NjRsa6rtOu3CbpBBtBBu7TxtUCI/a0HDn/dEx6NP99532jdnfrc3Z/zWZ2r2e66etG7k/uf69G/ Vhg/uCB6blcVRdEdAih9dX70KXdb33TvWx7r70JEmXCfGu+KuDDHrHeVxsF/9f/fcXF1v/Xf+9f6 /////7/f9rr/aowL9QRQ7I6I6CvU3YqcG9XP+oSBBkdBWz3a5kW1bS9Wznek9LvW3VNrdRERVnMa u9+oat0gR7iOGFbC37ShpXpIbesMFIuFO1AWGtWFs9tpFChhai75z8/xqh2oJLJDgkNiFvKUGCKA uxHsRTFVTFCxUcUhGDPulr+NitikMGh2Fer2FP9oMJn2NnU0GsNXs/IR3UMJn9BhfP8YjMjMiIiI iIjN0ZyIiIjN0REZqREYiIi4iIiMswfMtBiVwWMlEdpOVyiMgSL50itInzIHEtcjFzLBhUMlUS8R qITIPO6RCsJlQy+S6I8amR4EGSpG6SkLH8zTvXkHEjn5fP7IIJeQctovHR/kHDmoQ1CHcCkX+CI8 tnUIromO0GnISQ0H8Lba/fcKeLbwg37ahIJAldpNq6oER+4T1BEenhpt+d7zWZ361zWZ3/NZ4698 1mdz/kh6Ix8kP3pzFO/Ru1uk3SuPNDr/07sf3Tuv03ZAouFp36d8UZ7zunRnT1//4r+/VhFyG039 fX9+v/13X+H9/7f3S3///+//u3ff+9Gg7lD4jX3Hr+fvoa159P/vtva6/7n0/6/QYe3X9XrcRd3+ 1b8VePf4af9t9+CFRH62vpWlHsO2P3pWuuDN2120rWtef9q5wF//V9a40jQGI1JkkNoKRfCsN+xG xj9bGMcULXLHMOcf7GPxvFcYMww50x7FIbXEE79phCI7CDCDQtQhER2FORFoXFqhEMJnIQasRghG IhhCIMIGEIiIiIiIiIzkKCk2FsRMYk3rxEZbhYoIGVyRZkaZ2JpTsdGQVSuC4QYQZC4hM7nnZc0R hRi2QvIlBAyoiIiowQM7JMg8JEJEHqd15GIvEJhA+i+zdJSFKdL14VcvnpM1BDpJnStNT0EGlkP1 PR24oIei3+m0m0gQ7qeHgiT+vmtrp/Pj/Se78KF4Tfp6ebKVVu4S390nn/U791f0aBC/d5IfN3Se q2tu3O53lLzcCKH95EowECLtiRPMBf6tR93+23qjUGN70Z09CaRcL3K42C/+LrtphCPr1rTW/91/ +m/1rbWlb7//T1//ivPBx8NJqbkxH166r5jQ9o3TOVZT7VDtvs+qn/1mRb/38Zu3Q48ERyNoe3vs 5MVghuuun0I4IUr+2o+3lqia12FhhSUBf+219Qw18M321jwtQwks3Yj3qbvqh/YX+w0mDCSXHXFf hja32KVrBmCCOv8GYJ+K34ob7FMQmcwhoNC0IONDTTP8WnUWp0R6FoXn+LhhREGCBhCGEIYQhxER ERnIiIiIiIiMRETCcRk3EIhpM7UEJZE+ZDM7D5XKTsvmzJpl8qMKRPBBkVilRKovkVyKRC87Goqe EDKnhAyEyKhiEyZ5RkUifiMni5hO7CqXz/NjowjNEqEW1L5/yV4KdqGmSxEdBVJaKmdWE1zQ7/ZC D9VfBEh/qkG9NNV/3CG6ghFI2MEp8dXNBo0m/9GtPU7ud/hJ6+n/CLygRH3/0qnd9XJD1ekZ7VPp 8wtzCLrp/3S7J8ui6SBE4j7/tPQ13+aZsJO53+6M5UV53vX1ik5kU9eI0Ij7f/9CI629V7tfun9M Ku2l9Xb67ff32g7/7j//3xFPsRv1xG7O5h/9r6v5f/6+vYPqY5j5j9dLvpGRjbsj5HG8M577ji7+ xXb91f98fdXuvv7SjV9e54l4GfqEYZux2qgz/1/wk+rrT+2FpWwpkWvGF6+GrSxFP4Y95Cj/ViK/ 9ja+NCPjinVihxtOLsUNBoaEHGmc8Xm60OLjQ4tJi0GEIaaoscw5Y8REGEIYIQ4iIiIMEIhhCLOh CIjaEWhFo7SQiIxEmbIKyuqEIIMsgMiWqCBggZU87nhBlSkGQuJSMqWQvOmQNEMyOiPEeNcXzu4v krIk86BSIwQZ2iIPITK5hSuLSJjtEx2p0i7JUtE4ZKxEbpKxEyVCEqEU/nSCDQiNddNaOjQaZ3AT NQiej8gRnoEZ76a8EG1SbCo2Qqv6csdBcLaNbNQk4SqNbXWv1dX1O7u1dGzTzZq5eUbv1O+FNjnf c73SdczVTu6dG7o3fdbq5K0vvXVpCtpDvCGhv9xp13/7RnO+GC+63iZxgJQlfQF7f/kSYIf+/u// 7a//Xr//caS/+vWwRQ9Lrf/1/9/7Q/1v9/6MfvCuvoxvzZs+pj6Ed94z/0sEK6s92lZ5X2e2zmuu 9N6+r+/zhB792chp7V/MPjj+Nai421i7SImC6HN2KW1vq9Kwv/mawlDC1H8fej//tKGW5Q4XwYSV j93aVimI2I4j44MFa4jX//zHzojjTQjOjP0MQputTIzdrGE0wmlFqMdNn5Dz/EYuIiIi4iIkrQtA wmnaEREMIQYKZFhYzIiIiMREREREREZ2yoLQkGdmDEriak3Asp8uipZCYQZLDCBksIlTMRCs7PkJ kKzs+diea4vnZgZCRqGCByuURkWiBbJSENYiLxhNFw0/JQrIrk+dApqEJSEXXU6+nfVbULCDzQ0E DaLh03brpKvhdGt7zW0a30WOU9AiPvLfJvW0m6eE3T/7PlGzP353t036TpP4Qh6+EDoENPT+r/3l 8jpcNpCondoIoediM5Aih/6v3V1fxX36////iIx3zuGXCWEI1///f7+Lbf///1+/f/v9fr7Pf659 Nrr7reCHMftnvPYan6M/310icMXV1470iUBSgMWldR2k2Eq7IYVDImC4rr3pWtNq2v2I6VhhWGF2 OMM1gukv99iNjOkxUV0aCntTJzcU9iExU57CDCcWtnCH/OiLjsJhU0GruLhhNUIaDBBhCIaFxGhE WhEGEGEIYQYKIiIiIiIiIiIybkuZCrJsqIrikU6JsIpbraIXkLzqEJWZJoEDJUzEdq2YjIUyrHJA z7HLg2xzhcncls5QQ+hcGCzyEg5XBc7jI6CkrFJQNVCaom7/5D6POivyUxc1PqrVM1rtsi/3tCML GjBZoZ0rggb26eHNEqNPp1XTRhCZ3eCHC/ZTg+skPkx09P6vCerZhybtJv+randvuglfS37EN6Rv o/4IN2clb3q/V0gd6cn/dX97ey6I7/KWjelO531fhgyPyuJBihxp2Onf//r/+t9L34j300P2/3jr 2Ol6+/vq3/ZhLa/focKx1/7rSBE35nKHKHKu2fTn1c4W1BS49b9XW7WIwQ9XS1RhlRn5/fghmQkK /ER4uMlITtKKjbCVpXVf1DSjCzddtJe29sLUJ/aSrZ7tYWxsU2FFhhKY8GaCt8Nr+zkwwV94pigZ pFQXrmHzDlRkacbFAzbAjosJpimK+hDCGmnQ2IQ0Owqri1RmqF5wcMJoREWEGFW4iI4YQhhCIjER ERZ/iIiIjN6EwhiJCsRupXAs7LswRC8haKhFQiGZ2V5C81ES4wp3PIRFRlcZyuC53TIXnYW1ISMj IVbJWO7tM7ExFTcg4KdmqzppmoRT636aWE2p3gpKL+eGrzQyo86kR5O91InEi0/egRHJ0ThVuiQ/ v9zejZ0m9wk+/o3YYK/quE0sEK/PPTqTpV8grSElKVJyf1CJvH+6EMQreVxIMFKjAQibI4Xo6MuF 6/HzOLhUy4WvvJW0P/M2XCoLf/BgnSra/0cX3Y/qv/9P79r96r1YoeYckOU9qbrU3fVpG659fZ9A hQan+8/4jezyDSN34xRuxghQIbntPiONY94IodqPxbax4+P4xY/a+88Mv6Uc3ff1xEfpQ0uSHKHK T/WWOVZQ9fbCUx+uGMGYGcJrvvY1JjseboYqZyh4NCI4uwhEZsi7FVjuDvzdF40LTwRPi07VCHcR FoOLC8RD07TjERERERERERFxERk3KsoybKWZFuVwsxlcrzJS7UmkdleRWMEVJEVjBBSVGTTIqlOw LLomeVZkDwQZ2QiEyoRXMcEGZFhayPY2d62qdhUGVKUpEmSGkSmMMLapkutE4aZ1EUrqEFoMyFgl hKDCHU77aZ3YKi3fl8/3phLVboxnqeGncINnbhFyuMCZrq2gmVYa1vSW4RG+E9V6vO4haBEeQIj/ 7q5tek6SLz9Juf4bQQ0jev+lwRIdCk/++rRGRt1T1v/971c7nfCHRnO/T4sUCBYr5EmXCb6BN9kS i4W/7ppPX1+//f3X8p2Rwtbf8jNo5/j649pfexH15v9//Yj/VffbuvX/e+G2zyfan/ax3TU3cEP9 /Xf+IwQ//c9jP+39qCKcMjncNQwcXaje3zOy+6j2DLc49KIxGKX1Bmsof1H+h+/20ghHEZNILsMJ VdhLY4a1tC7IxytbqxFY8znc49lDmcocF9r/x4r4glYoaYpozNihrwYQzOV1hU009CIi4jOiLFT9 HFqGpkWUjJ7Gj/YQhhCHYTiO0LiLQiNCLCcOIYURERYQiIuIiIiIiIxMkmdiWSrEmyrkoGdkUm5f OZIZ7MgVKpFhDsyzWZVM7olCDO4CGvMI7pmRXSuL6araYKCpnaTMMpxUyWNTpGGpKYxEpkkTtpJp k0SmQmFqett9wUFRvaaYVGhodqSnuIYTCUIOjBPbpfrhN4RKIRKNO1O9Eh6TrSBEeV5hzD53FJNv OPfubP6dXUIER8QQIj4q2vc89Wjeqp/qnVhd2clf/e+d9kL+/IJnYVFwqBNwX9b474/b/+1VR13u Le6hoP64a6aS9el/mE/16/Wb/r/Xxw4d1fDan/D4Pvv7Pdqnf4UuN0v+1nB+gQpacNhurpQxXmcW X53GY42NKN65C6CsIVGsWFbS26WjIUC5ug4PFQwpU267Hgx9LoWquFadY2GFs5xGGXiS+ItBihF3 Pnh5jx5h8czlPHDMsKZyhyhzj2Ki2E0MzTIpwwmqFxBxEaP8w54uIcXGhEXDCUMJ2oiIiHcRhCZo RERFlTiIybkuJ2kxJQRK8RLfkIkH1OzVGScQ7JiBB2VpGsyIMl8qSOxNExAiJuDhJ0yqZhGRZSuU 52eL5LIvkLwpK4jyaaaJu4ZUhpoMKXiDgpfJUjcmXycFyF6etkcVOzIVEphcLkqEBQryDys3tG9o EDcMJo0NFvXwtoNMLdEqCI3tT/MDEGF10trqESeu3TdPTkrNUm0E3u8ER96QIjyBEf5oNFKndaZE f6Nnc7+d9ow53RIEGd9zWZ3utrgw0b1T06PD1S+qetxSbnc71bvbPc+W0Z9pDaS3S3rbl213p3XI J11dl/H+/szi4X7X1+nX63eNJvrf///6XXrf8HvdIf3/0q/X//+36FL/++///uGk37vvw/fRcX66 0tqbu+/v/v/3MDf+lZ77ek3r/BEcjH6WlobcdqRcYeRjm0a2t6j9qsUvra/xo3WnV29Y6V6xpW3W GHxravg+wwlC0O0mGkxdexFaxFNpdr+me7SqI1tsRTFNRtAxsUxQs54zHsVCXYpimMXaDCw0xTsc x7TxsULCm72mhaEO00IiIYVPPNNNBhbQi00LQiNbQYTTUREQ4iIiIiIiIiIz/ERHlcuRLCJaZNyv EYkoQQaDCBkoEOySN5UslKU7JDJdExyuJZ2HkLyqReNUmRqROGETdouGmVLIXrkE1ITUrMQqNcXw oTCl41ikozDMiy5hGfIOKkHF38g4dAm4QNoIOje7JSE7JSEOoTP7uFsFmhhNwqFmQoE6attq+2tO k9N03SVOqX+rhEnpPOP0SezDnHpVrmszuazw0Z/zWZ3P/bq1dX0Ycz65uoznffrO/BEx0NNq9wQd BYbnc7/vTvTb13074nYHr711kTDFV90P75E4uFInFwv6CbXreh1/u+q+l+v/8G9ff6+31+3DCr/+ lT/rfWu+I/7/qtf4f2r98yO332fX4Q3n/z9/g1/6c+r0n+/7/b+/wzc3atpWFj+/tSKIIocGCv7M PFcVf1mHFl+1b1jY/+DN1te12LXtXjB2GErVhpb2+rFIRH30f3V1Y0sMbaURS0F49cUMULFbFCos UGITFTHjXFNSY5Q/Y/pxeKaB2KeYcw8NYtXdoNMJppn+GE0whFxaBgoQn8WhEaoNCDtBhUIcRYUR O8QiIiIiIiIiIiLiIiMTtajIrbk2MuTctCHf4IGSkU7JiHYqiUoraIRFSzsmjmVeJPnYnkyXK4Ln Z8hemVJAg0TdhMiyJCTVMkiC2QeTguQSQdk4LqRXUimtyuLrO7gpKhEX0lYiaBB5udpo3s7JiZ6J QEOmpDryUNPbrL56NQmXz/8gjTxOwhQShNpI1um0m/p0/XfeaCx1EER6FzOTfW4SrX77qiMerokP oOr0/S2jen5v9+1CBud0+4wm/5hzv/+c7+jOVGZ0/c7p/q/j3ob6H3xS/16e/rbvzQMGjLhN9dLd Lf9t/1/XbDr6X7/f+MuP+JIf6/f7f3el/7/nP9wh2fQIoeoRQ8wgv//7H+xoyLU3flcTDFv232r/ atrH3HZHRj2GRzQjQiKuopbW1B/sGWOYf4+K0v/20v7SsJL+hHNzQ2mmwrqxTaTP/uqHfrK4QrKH L3TG8bFcbGGKZz95j7p8GcIdWKa2mKrdjaesfi4tC00LQaaFxFoZ/Q1P/2hYQYTi4tDQu87Tm0Ii IiIiIiIiIiIiIiMSvr1LfBTsVyVslUQkVZnZGVJELyEyVmdi2ajNdK5Xl0dreVPCkERSZ2JIIPCY ThplSicMEEQUliVQmdgYqcGVXhbOx4uZKZBko1CkokDzsRXNzOyYiBEdpSJWW7JUEUlIQEM6hJnY VGhyEKD/rcce4Ik/XrScLCdgiengOE2szkx1qqQbWm2Vbu6O953O7nc7vsEnqd3/TzdSb8dXRviw gbRuz/n/Tz+lcVp6/7+/ou4+5OGI+6Gn8ItOrxS0hUcfxrCLK//X0l/Sv9ff+K/ft3//9f//X1D/ 5nKHNGZyhzx0mz6tbvr6u7+7zGwwQKyOO/sVsaQIbGX4paEXoReLhhXqc8GDbWGXRHrWzdZHRHdm HayF0pYYOI/pa6dI0fS+/Q7XyHraURt8cRxtpcWppJQsRtJNYM4yDG1b9c5+xVkdNRCY1ilVWKkx 6HEEDO1VpocaxDjQ4i7U/2osZMIEz/DTP9n+z/aggeWOUOU5Q+CeDKHCERDiIiIi8EIiIiIiIiLC ERDsEMRcRE/iMm4IKJkKClTzsSRkUM75nc2ZVmdgQhTuVwpHa3lTQTIWiTwnpkKwmVegyrwmS2L5 TxfTO0ahBkLjISjDpnZrFzJQwmSsVF8yUwQZTiovmSoQiiOqIsE0WO9FuzWIi3YWwnaLd6MELd+t 9WMLTeoWE6qn8IN6CbWE3uk6Cb+nrQIj3qd3O53aIx9PU8NJbRu+jd1frRhzvSdHfzxyDqdXPaTf VPVd/ed0//zud+9DHQkSi4WrM4wEJfV63//XT8pUXCx05G2XCL8rjbLha9L/tf9duu67/tUG//// f9/66v/9fr9/X3/3DKHKHKwoqdTd6qf8P///6365+owN7U3dLtI32K2Nf2Nil/js5iIjDMQ13j7d r92vrv1air70Ncax/XSttV/v0OP2wvg22lbe2kxdMai2k6ue4YW7dftJNXxUscqDj2ktjmgrP+xQ 4xvFRxsVGLobFDjVrHGhdhCLjQ7QvP+f4u04YQtBhBphBhVsJoYiIiIiIiIiIiIiIiIzdEZa/YjL SJxkjOI7OjuxCUorzZkVIwpXKkdnzCJbmM7JIvmRbnYlnYwi4p3PIONcX00zsdpkLgpL6kajsSyE ggwndNOwnhc7BUdf0Kzpad77ZF7mBljtT+dP9Fu1vhb7W0/2Z/Tq9XT71Fv79QnQIj7+d7o73ne/ /Cn79oz7p6t/P88Hff32rdf///4yNZgIdjIuFFbIJkgMb16/Xset/52njAQnDG//X0v/01+nhrr+ //r07DXq1/X+/t/+dheR0R0R0XRHVTZ5+3wbPBUFR0vr/1ngoZ1Q9Wpuzouk//19fUREREacd9bU RwQ7+1tSKBjGOsnDA192t6++r6vr/bSB/pjVhhJhhKrPbSo32r/hqxFdiNiNiN/2KFqwZ1YpimKJ VxtK+DPsrjREww12mE0LjtC1tBhMLxaH3eSHLHtWhEREREREZ/iIiM6IxK5mibgTHEZbkqLxK8uy FohIlIgIMrqghkQi3D5bqYQEMieXRjCZoMj4SCkHle8yDi+iY7KjITIiKnkLyC4UhM1xfUrPyuCy CgoiKQjmHMnPzMkrsLoEDeahDo0GSjUlQhKGE5hphbz1eepXFrnCjFhY+W6od/XSb1/dYuq3+v77 n1Cnywp8efXavO+6fRhzvqd32jdnc8c/6PD7ft/2coYJjtirsME/87A9d/NAxW9L/Q/bGThjW3yJ hh+/HGk9Wh9PoOv//6f/616q14/1C1+F+rDv70ayhyo/fr1f6M5WhnKHKcqP6HOisENGCjBT75xg zJYB7fW1xF/46BDbN0V0OIj+uui3OPpO7pNpZ9Vhu9JsJP23tKkhuFzNdsaU/3tofJQFDN0hSkUx UkOzpgzSGCKYqt4ppSUe1xtcf108ri+Ma1Ue7TCHFoQ1z/FrFoMIcWhHSyx4MEDCmHiIiIiIiM2R ERiz/aP4jR/LdZZ2UZC1CDlcKOIiIiCBqSkQlkJtCU8QcdrZFOwgzIEUriWZEmYRUZ3TOxpHYpJk pwpB6lQggyryF5C8EDCDCDKiO6eEGESHd7KEE7NQh24h2oYQZ2TCIv2p6BTqIjKKZrE9NBosdnXc 7cQg5Ex3BA36Mdrqva0/giMeuqNjX5raLugg36VQnSf/zvtG6jdpGfP+rfCTSIx7ntEY+nRu+k9P T9ow53lHpN1a/13xoaqyWpRIJ724ROIzunjndOvQkTi4UicYCVdX/pdr77mRhkcL/r6/0D0Hra1/ /2//r+/++7//XiP+7+mG8PqKh/2jA+/t8zlP5nOP61/S/j1tan/dvVs557j4cM3MO1TncZjvfu+1 s5jQuNC9q3Tak4Y/3p0hXhkxzD/SjjaCh42m1m7t+2ufW6tqh/7faw0mu+fyh9rDV1tC7EUn1ios VXnyeKjeKiv/YpiicFwZ9nsai2xTFC9+puU/xaZ/sIXEOL4u1P8cdprxaemmE8RERERETtIhcZui IiIiMyIiIiIyz652NsXFx5bqQpKhDtVFBETasGdjWSsURNSOZkCIl8iBDUjmdqGRiK4odNMqWVCC ZEZfO1eiY7KlplSQINBkq0HZL5GRfOxLNTTCBhQg87PpppyuFYRfNF4yUea8jmi8YW5BxIEDZKhE X8ikmmjc1Pa50YTTs7VsIPbCzA1aoER6i8ekaHK5QEpuEG70Og2vaWlV9IuKQf4T0mrx1zW6p3p/ 0n6Tq/YVLQIFdms8abRIfTvwm6v+6mfO/ncz6dJ7PdfTZj/q6O53Vde8w5409Ldd7zvdbjV/b6+t Lvr7q2PspQY+963rt/9df/ek3/7b/+9+/37/f/+v1a//7/19tv3r/X/qcck//Q7X69frr0aCk7qY /XYj1L/71bUEKtv1679tL+1UXdY96j76j21uqF13Qje6u/tpWl+sNJu1dXhr3tr9pc3YYWgrerSw 0m1s9wwl7hm5x/bpgwrFAzBMUxURUULFbGxCfY5vKH1bFBrYimlY2KjYprnPa4/GxTVC7QaaaGmh dhULi0GELTQtMJrDQuIi1xaBggYIQwiW4iIktQiIiIiIjN0RGchREREYTna3CMs0bFO1UUl2drWS VCJ2KJTuaMizlcoRkSZ2rjsqzsb0ypaaZU86RLDklKa4vlRkJmuL4UkOlMhPWp3mUZFMoyVCFKif o/nZMQimTxF+yJxPo3MlPZE86pG5hB+enslQi2dLOgVOzs1CphI7cImtT//hf9elf0m1+0m5r/VT xVN+9XpCErf//mzXejd9/6ff6dJv9LtG6jP/n5Iz+fs9pG/Hb/tUhs4lfoY/j7+P/ImGG/+hrun2 6W9vrEGW0/b44+I7//6r1unX//X8ffH93x++h3O5h/zOcc44Ij/2rM5hyhwT1azDnHO5Q9Dxq/q1 v/6N2fRkJpazozo2cpj9s54nMigYcRHjBDERGN0sRF91s521ghSV1S91BpoQiOdf+P5/ofbXrS3/ N2Hxt2tHUKxanZqFiMpQLwnzf/1//oGcs7M54YM28O5TlRYprq2KViKBmLhMVCvae//zda35/iOL 0INPiIdocaaZ/tUzk1OMOdTo/EREREREREREREREREREREREREZaqWpbqZkEI7gUlYzIXGdmBTIr IKSyO9EU8dh5FMrmGbKVwrCDCZBMwkGgyTR2JaDIVhM7E7J4iWVeVCUIM1ShBqpSteVxIF0W4YRO AwnaLxou2F0XjJS0HNzIojUtlO6Lx7OjCDNYprFBU6P5KQiLHZ24SjGeiLXRp9BA8IOugnQTmoJa Cbi0m7Vxr78KFBEnzW/0E2uv3C80Guk2k877pum1redzxp+1KWrWqandpKEtJ70buHm7v75g+0k+ 9X77q87nedl0cfX/8ZA82Eun9Ledzu53PEInDGrfoa6H//41de6/9fuEwQ//+k1W7v1/f9Bf3/9q CKf+wv//X63/f//7LHBEdaJD2KYj6//u19Du8x2xEVrv/1sui+Fb1vzaI+v4z/jjVDERGCB941+7 d4zCuts3Ol2bg4IVYIMLuo4iP6bSiI7b/tpfWdyxyh4Zuuld12sz1bWf6HDC8bNzqI9hfYjit4ru Zyhyx9bP4Ij7+It1bW0xvFUfKK/Qj6wZpC5Icoc4+xU6M6LCDTOeLjVCLQtYuL+LQ0OLuHDQ8/+f 4tOykYaEREQYIRERERERERERDiIjORESEQiIxMgrE2i0GW4ism4MImdxFeeZJ8heaMieVCJWZKhB JQzeSnMsSmsipqkCQQZ2KR2TFMiBSVishxjTTQenZHZHiUZhqCppy3Lc65Gs66MrZE86aM7yJZ0w pE86YULaWjQ0afeIg00zscIE0XD//hEnS6QbrtEY9dURj56NEh9U3VwnZCD6nHpAiN8Jt9/uegr/ uSiOX88/z+p/W2jfKFaur9z8m6VudzvCJvFciaPa444wi7jHWmpEwxFYsaioi+ITLhP/1t+v20F7 pgh/r3///cjF+vm1/1/v/7+lZQ5TnHOOUOU6KkkYYHjeY350Rs9i2e7Pdq59NTdfX7q/vS+49Rm7 EREREXncZjdJWEGluOONUose7XjtXXY/6niXrS75/2OLxF/9jX4wuxVqNBbY8MUw1+h58kMeYcqK LHO+eCh8Kbo6HMeGmKHHoOxQ/EPtULsIXxDzpE0M1lOU8RDBMIQ0INhhDm61OQhERERERaEQ4iON oRESbgyESKDEmiiQgpkVs7AzOxrLolhkEMIMqeQmEyp5Us15hEZmEdjyDk3CMvpnZJmIIMJhbCYT RdskZPmsQ0DCJwyWCmpGGU4oTTCadH1B10bg1TRbuaGvNDmh0G+wqoEGwoTTVLV+5CtULW0n0CI9 CdJtAiP2k2k2k38kPmg0KnWpx6JDtAiPvOP72VjzvenqnVunrenp6f0b0KQbW556VtG9U3avfiEv /a/T+vr9/FY1/j09Dr1u3hFtVVX////3+td+3r/vf/j//Trtr76/9859nl/2fXpOfX16SgybVC31 jiltJtfq1tW0uzQF7StY4+LvW/mzeNK9SKcdpRG2kw0oYX1YaTDCVtBVYimI6c7UBLFTnhqkNig1 FMUGIW0zOVBT2NipoKHQ8zne7C9EbVVWhaEUQ47aYQMINMIRoRDTCDCoQ40LQYINCMFEWchCIiIi IiIiIjESuSZXVqW4JkyyUo7rzqipIrSIWiKs9ktzCOyYQqSJ8oRUkQuIsEKnkJlQiEzrnc8hfkKO YoP8KCKempUmCkrFu07JRGJVi1ITNAXT9M1CqfUggtxquejTOuRUJnpT+EMLCbC+E0Za5F6/Rp+8 LranrM54tr//uuiQ+nnffBEefmcz/2eDXq+qRY5x/bLHLdv8UFq76o3erebs/r1+qezl04Nb403v 9whDvUIO9+ggm0csfHQt79aivW6/GROLhRxrNAwrrkTZHCmjI4U0ZcLjek3u8QkGKYa12qDCi2// /0v3r//+lx/aFUEc9DFs+kOPs8n71dLnLVP8n84gTI45kdfan+1P9qbrZ9L+nCCyJgusGC6LHkoC xdhX6jXH4i4r3qMfHx7NAxN215uwpcfN1Dm7R/SW0ojdKz3+yY4L4YX//WrYaQv45yNP1vwmdzD2 KaHjHmwp4OI7FTHjjjUvyh70xVeZzuceIjU/xcXZQXFoGEGEKvQhrdoRF3YQuIhhCNoRDiIiIiIj N8RERERERiJN3xGTcGjmd4zuaIUyqKyuQiF5C8hMyIyNIyqRjJWjdLdYRVJB2EyMZfBS+EGnDKrE KjtQkyhmDNSyUhDWIqYTyJgvLcEMIGSoJ6LdrraLd8MldkpCXqmnqueiHOt1dPhNwm11eE+Ss7dL ep496Ix/+gRH+eDX1PdG7uroz7nfq3hhw+dzv7pJvef6N6fqztZdbjTdLuhXq63X/IlFwrIgkd3/ /X1/jb/r6v19//3+n6S312+v7UW+P///Xf3Xr/avP0InHY/zsQGNcENXPpIEKd/f/Vm611b69Xoe yLjbtt/4dBaJSEjmcqHjela2MLGxTfGrEVDVeF212rIQcJjSZMcococJVoecc0FSqEbDCVpdpimK aYoeFhp3YoGcusOIjM5Q4KWOUO3oaFpioNc/wwTTTQaGmhEWsdqhFhCDQi4YTCiIiIiIiIiIiIiI yz0yhS3UkdludmGdpBIZHCEojEdgSMIludlCISNRnamzBFQiMMqed3mEdEZxqIgmXUtwQZWdTUy+ QvCZUsJxq2QqCdhS8QvTNQiDKiIV9nTTCZLRhNM0DCYW9FTEJSEX0WOyUVzc5Kyh/665KhNUaGah CVCcw/dFwwVX0XDXwRPqqBEfvhBvdJ3F6ekCI+2gRH3C6JD0nVYVN3dOicOd/PBrwm0CI+3rRhzv n/W+rv04MHVfX18w536N63nHPFGHO/3p6bhBpLsafev31uor5EowE/vsNj2Rtlwn/fW5EmXC402v 1uv+vQ/q3/+P9/7X+vb601/r//127+8V19v6f///f/U/fMYKCKH9BK9qbk///bSN1s8rr373wQp1 z669df8x/8M3PqO7a6EVFhAj22o/63r+Pxbr/e9pd0RQMXa32lelr70ONL7Cq1hJYrtiKYituvWG r2rurDVk3CsKrEUwwkThhiPe7FbFehGDOWnPQw0O008Y8scw9itjqKYhBoWKmRairawYjTP8NC/i 1hghaaFhCwhaDCGELTThhO4YQam8p4YVxERFlERGakREREREREREaFoYiIiVyTK4HimRflupCnZI jI1RkEztRlTMlgQhM7npkIiEzpkbzsfJPLo1hOmSrJblGmViCl8hcQWJUKRWNvTU1CHSMRIyjNYw kp1XBkfI8Q/U9hbSQcIvnn/5DAofoW/CpoNT0jQ51FQnqCggRHrTuIg7utdGBQem/97dX/qeL6Te iT2p3e6JjwlVeyEH13oER+3Z3DpPf81md1c7/0b9JN29PZ7RvXvrCPo7CiL43vPifd+t7OQhv78d O/92RIFyJAvQ17/seP8dDCyGyOF9W2/vX4w3+11v/quv+P1df3X/611jf6JQgl9DnP/tL+dCnIbZ 711+cIzydLnPs+o2p/gh/ghS+s4Kwlj93rBDvXu1jtJJGi2vFxr5oGJnl4fq1fmzfWxC8/9bV6Yi v9WMLn8ieEKs9q0vrhiu4TDSGcczlbxOxHZyQWW5Tnf+7FCDPs6rF5hzD2t9C45rtVvLHKcocp7g 40DMoFDQvtRwVhCOOItYaFoaFxxGRjlj9waERFhCIuIbdppxFhK8REREREZyM/xERaEREWf0Msqp iIiV1GIjLKWBCuCRiOyaJMyTzu0YRKkQoIVREJkJncEVEQmQpSbrGQrNSNykKiFZCtdMJlOISjMM J2iKOUOUKtM1C2mThg6hU5NwsQlIgQac6lJSISkSm6P6LhqmmvEQaNN4XRoelwkrS6QSWu+m0W+k YegRH7ZCD6+WOUPqnng15nKe+ccz0SfU7uz2jDnjO53ow537/ToIGqduvnxN7kVWghD6uNN4tkTS 1fne6W7Hv/dbrt/46v7q2/YTLhaE0ZHC1e7ThMuF+3/+tW37/vx+/Sr9f1pX/+P//7tLnCn//3qu tnu+v7/2pubntqbt1rhqft/v2Nf/+74fNBQ+6jY99J10Md4x7bW86BRX9+36Vnt7Xv3piqF2wvQV iO1G9V+1sJJP+N4phcfFOxtRtfFIvI7TFTHQ8w53jhiEGKluUq4tC0MLEOLQtHY0hENMJxYTCERa FxYTTCEYiM/xERERERETCEZZCpCJKEQvK8ZkSR2rGssgkInlZyFohfZUzJNHaQIQqCZVMhEdI7oE IRFRkry6luqxeJXF476U1svkL7hkqDCZKhUGg0yDkiViou2aouyMFWR7umahAt03Tzs1aaMo5KhI OGuFYaNHOoRGUqCDapheQuzUwHVbrpPSeuFmHDncNng19Ex5Kzpt0tEx3TdIztdlX9FjnHoER96M +0CL9kXjlU8XPc77mHO6aDDoMGNPwQNAw1dZ3O9s5IEDW++jejUsVc4zRcIRr9K9emv8a71tiGxd KyJBhRZFE1Z9lwq9x4r0r4mkEMIFFBMuF1/v6v////1+4X/963Xre//3/67q/+jA//kXwSJRgt86 HZ5BE43TSN1/nC59XV659MKf4MGjVqftnv/fVpVTUV76/cQUQXXxZFxu2o7/8dqx1Fj90K8d62NW LURcK57jSu6hQmGF/hdq69rZyVsJUq+dAtnt/YirFMU1obFNMcEgTFDoscofC2IQ7scc0FDtih5r KHjyPdjHn61aYQjhoWtwwhaEHpw0IsJaENBhC0LQwW1TQYURm6IiIiIiIzfEREWFP8RES1RNRcRO 0iEROncmwIhKhEpyFZC0VnJURlPIqjrlaR2pBCrjWZV6nc2Yjqj8Mt1uUlcXyXiUxByrqVMVMiuU ZCvXKmKQkQrTNQUJmpbD9PluqCEpCBbOjTz3p0f1P+fws0PyUiKXj0SK89Be0abSmhp6B7esJqr0 n3a/rqiQ4Ij6Tfr1X/Jjv6eWPSbq2dw4Xa5uU3Z39TxfiCI/e/bwQ9eqMOd/+9uQcgQNdfR7p96D e+loaH/+6Kdi3279Crx1v+/qtCaMuEImy4RerX8Q2uDEpqpP/X7WrCsMFkh9//sR/H3rp9i7+p2p IJPvbb/f0O0MIaG57dZqfvJxkce7Zzam5tTcnr8EKsJXmgYpnIiiTN3rFLnQyOUw5h8zmHzxjvp/ wZY5Q5Q+KRutRY+PcZ1C2vEJsJJy3BAwEI40nWbtPQvj5/VtL7bpoRbYT4q/6aTaU45nKHBQo2Zy rKH07DG110/tP80FD4r2o+gZwieZzjocdnPkhwUUNCKBBhUIhrMizoUIRF3ccaEaFw0Ii0I41Qu0 0IzpAncRGIiIiLQiIiIiIiIiIxJsoybPEX5Nweczu2drSMIlqJJkoyFIzyUBCF5UIoMjaNZHcZ3X HUIdOGdozCKcyXy+SuL5CUt1vIXpqU8XwgyoiFYTtMvkpCLaqSsUKqaZUan0d2KElhpphMLrmsSW 6lZKP2wui3eSkRcLa56+YLnUJBFCIdouGdK9MFmBz1DCvNDW1tffda3T6oER+4Ij7/2tS3pUu8L/ 0Rj38p3O/SbQIj7oER90aCh+venne9N6MOd1W6V8/23tbPaCB53O/X1b3fm9WcnoMGYS909fXpCP f//VzNlwtba/1++GJRYOh+436f7rFjvY69f/////19fv/4tobS2u+ve/G6UYX9//99rr/9q0jc// 99ciZpl1OFz6f5blDlRBD1JxSOS59IwOETvfWv/9nlBCiKBi19Xof+/W1UlAVGc70IvY/4Qj03UV M5Q4IjxSgXebp0G7633relHppimNK1+26iKYikseRjlD7Pa9+7JuFYWSHWI62cquFxFMMJMRTEac GYKOppimKa2ow01MOUOUWLnIUcznH7FSQSLFGrGtm4ofG/Cw7FNNTZ1hhNNC4tNNNCIiI9C4v4YW I0INKItbBMJhBhNBqIiIiIiM/xEWUOEIiIzfEREREZN1jERERk3A81CEURUZJTOxVELiFIhedraJ YZJojEQsyLZVmVMjWzGdoR0yN5F8jak3VpQqqmVKTImGFJUIdiMo0wmmEy+E8kJU1tPKsTPpOCHM Vy8e6MZ6RnZKLIv+RetbyHc0PXRcPLycER0ZpFw2nrPS9nUStf66Qb33ng190SH/uk3oER+61+hT hPV/oscof65u2e+r36d/xp/n2Bd9J6reg31+tq53a7eEIavRnO+kLHv+//62+sf+ZsuEX136iqfy lBhvxb/7rFpRl0v//ru/v6v/xH/6x6HW3uctGxHqXiBkXGClx+CHZ7RjwQ/am7+6tzDkh3ausyK2 e1v9m7Dh264qKeqj9K1Gr9boGbtC7aUNJ9G6aAvN1/x5/ZubN2L2THUkOFDCsocw5hwv2TcocER0 2lfEVYX/tWK9/d+1rG1u6GDiDQsULiM0FD6wcRFihw0xVckpCmh6eY+sWKs/8Wh5hzP9roXEdhNN BoRwwhERaaEWojP8RoT+IiIiIiItCIjqhEZbgqIXiJUkdpWQrJYjCKlnY2js+QcazItHZSRBUYzW ZSZ25FORJo7NeVwrXKxF9M1xfOzEpKtQnZKxSFZF0mdwKaAuEyEspemE9BlOInZq01PqVxevMZ6y +fgtnY4QLhDCGuFJQEtwtTQzpN0Yz0RetFw1tGiqNbCLh/p/1/91W1VAiP2teiMfM5cUm/1/hOgR H3ptGcofT0+/919fR36N6ne6N+f6Xz+kYc7+5/jCDdPvu+6tperpCK3V+3mVT+7W/Xd4/uOPuo1t 74+t1/v///T/7/rtPv/9f+vf/X961iNV9/8xva+YXofvYjiPqnf8+mz23rZ7/BFDsuVnv/BDcFI4 uv/9nt6ulBDS4Ibg9vwzF6xaH9R/oRx2trQMznfFN16trx2ra6U3MaQZus/tjCxcaXxGtt7C2wkw 0mTHOOCI6cdkxwrCsRURqUoMIRhlDncpwvlcXq/ilDFIjHzOUPaluU9qMGfczQcexTFBxEfBxYql m744i1XFxaDCm9NM/6EOGE0LiwtxdoNNCOGEGFNZTlPaanspyozT4jaERERERES6ERERERERoRcR oRGEDjErwijTOxvEREZbkuQplVSedjpIlZqQtELRGZhEZl865G0VCKkjsURGIwiMi6O0Itw+VxOC BhBrhSKZPqVNkeIplGRTJ8izUJkXMJLYVQvn0mmmmE7W0zsJGHfLoz05Y7JQFsJdqegvqumgpoap ErEJRa2t9nUI+dqLXXrC+rVGugn20F/77+jOKSbggQpe0CI+6BEff0v3QIj9o72/giPV1em0m5+h tBe3oz7/6ap0oSMOd9PX196M53r/W/52OuqcyAzI6I+tX96fdiop3r44+l9qt/7/tvpLNGXCkSZc K+vr5W2h/oRHf1/GwRUI58Nf9+jm/5v+9ev6Q+2/6///X+CI/iP7XTfnwqGh/U6M5/r//4IVv/9v tI3Wkbmdlwx6vq1N3XRkbur4Xhri63/rxFWsR9/ares8FD/x8fp+vofil7gzdtK0iUBYj+brGt/7 aXb8kOExFMRWId7X/ZMcJiOI63V/uxsVC+ndiq35ptipeHHtRQOLTX0xQuODjQaHGhq+wmpxhjxE dhCIjQaahC4tUGEwhEWhHDCDCERiIiIiIiIiIiIiIjLQBESwiWDK43nTKzSbl8oj6M87xhBhBhMi 7PZLDKnnY4TIWFO6ZCo7NcjWdgWXzrlZR1zJJyuFqMIO0GVLRcNF20XYa2mS3CkLlh0QkSoQlYpC 9T6OqzseLsLyCCpXtT6CyuWpOn0Yd6CBtBBug7Vo0MEPnCA0YaqFJSE007VNbu/TMqBJXKQjLHLh wm0g+l06TdOk2vow4e6ql+9TvQIj7ssct3u/0kEH96b9/p1enm/VnITjbOSo3pG9EG53O9/37r0E Hfu9GcqNGc7um3W1ciYYq1v6/oSJsuEY3jNAXxx1223fSV/6v6fpf7+PTqt09a/5heqnRBa3/9DX 9f979Cu2///0Y5kX/urW1TbPpqf84RhJGTnI2eTn/f0gQ7qv9cEP//2rra/2Fhq2raT1kCDA/xBf xcY/zc6Y+9bqkkbnb9/bShpR/w0mwlDC2saS3dntBOetVXv8GaATQViKbCiDNgXvH2ONioxwxTFM QmKQ5dlDgiPDxsJDd5nKjN3Y2vEXainFrFrVMJpXYQYQaDCmcococ47aEaa6xpoXpxYQi0IYQYWI sFENCLOiIiI0IiGhEZ/jP8RERERERiV/xERERGp2t5XCjO1lECRIZgjrnZBkEMqmZBmSeSvL5Txf lcozsiL5K2XyVxfCkri+dmvkUyjIpk+RTKEgyUo/kpi7CZetbVMJmrN2SiLs7eLtMpxAtr1P664T sFC9rf+mjRT1TX2p356Roc0O0/TVNGhqut/C2t04RJ63rX/pN1bU7vfrf0m0m9AiPdTu2p3pNom9 AiPugRH3vzved7oEX7BJ53va3/+/r6PD9fbenS6p19yXa908ED19fv/X63RdsfwxBRxxVXvSvrZn Fwv3qvuvmbLhV/rf8e7/t6/X6qlr7X/6/9VfjUV//x/3r/9Uv0P+/3qGr+Utc6M5853dAih2XS3X vtT/9X33XDKg/3Xabpb7Pf7/31fW64IjjL/pBCRRTr+6xEUxraqPtrM5x3a2sUorxStR02FjvW9K jfvqNJi1wxxrd7/w0oVJMRXwwli7aTYSdXXUaUnB9iKYj+xGxUVQOxTOQq/2mMGdZtDhiqdiooaF xodOfrTV9hNBoQdoRERERDCxaFoaYQaERGXTuGEGFEREXEREREWE0IiPMhZELiCxbl87L5RiMrlJ HZohO1ON4IiFIMIiKZxM6D7EjhDpzucHNREnoMjhCF50RnnTITI3kHEqIqaJRn8hMyr4JnaJMlkR kSTJ44SdpoNMljWDI4h2kFwthUyMFY9NdT6U0BdNPU1imVF0TsM7HCkXDkUaDyW16bWje0X1G9hD jCeuCBEfmhhZKyh66560+kXDfwVO8J0q0CI9/SNenpuE2k6Jj5Mcw5Q+WP0CI+4S0m0Rj3H7Xf3n s+YT9hZJ/0m5uzdqE/vfaVq+9cEDsJxDoI+ihLV4IkOhS5/QMG1ugRH73zqlFJtbW9GlWn073t13 /0///eI44of2gTe+IYYkTZcKGKF+6NGh/uRKLhQxKT/+Ljqru+22tvX+/69d/7+1HH/f+16/96VV Ct9aV/62eyKLN7n1Mj9Q1fs9hJpG6Tg6q1P3p1ef5EwSz2CFc8lULrWCFRFNrHHGRMMIRxf26zOM v2pOGAQI9jumi8zcxV7W0h9Bk4Y8RnZqFIuFjC9Bpj/XX2IrDG2ElCCXWWOUOUOU+v9W0mGvzYVF QZmmjQUJpcgmDOFhTHznznzYUOcfM54KHzZHaoHYqXZTlD4x4QiIaadrF2Kih2hB5qazozBRiWOL CF6ERoRdxF3DThhCHYUIRfERERaFoMIRGg0MRERERERERERcRGdERERk3CMl2d4iyBIXqCBggZU+ yuZohedqplPGIEDJEIlSR1yTMl8uiWxfJWRURCIlDMR0jIvF+VyqO9chUiY7RIdrZWNMlQpF4wyp Saug8uiNyahMLZ1jEumTgunvIJKn66CPyNNkoCoHZkt+FiyVBEaH2jfpM9HTztReekXDW8JraNej r/bDX79PTpMOt1Z3OPSSbp6b/V936dAiPvwRHkCI+9XNB7708mOWPnff+r+bs8B/zdXDc7nfXWr7 7/29XX1T16uKt/Vwg7a787cMEUDCutu2IbIky4T6Gl1S9+//999XX//v6fvqt6/quvjvr99dbfmF 18RXrob5hfr/1/9ft9/5hzDmfOi9PWdMEmpughufV/bfap3+5QGAQ10k311/3zH4Id+l+voRf7W1 JYgVCENaUcaT+9baxgzOUOCI9VSxzD7WvpilvW1W1SbW/fS/+2raRKQsLtkhwlaC9rEcV4jsiDpk hzuqF4vYjdWIqI2GEmUOZyhwUU2osR/WuITFIEwT4NDM5Tw07sUoamPacGfYmhFri6GmlYoXEQwo phcXFoNNTBELXQuIi1M5XRERroRRblOU8MIQwpjw1iGEDCiIiIiIiIwhDQiLQiDQiLQiIybgeQmJ niRQYiNVJZGtkKRXNESxGESrIQIU+YSDKvO1NmIpzIgyTRUZ0zuvOkVlEIpXC0dnyF6qEGE0yuRq E7VQqaLtlOKQn4TQamsSQTfaP6pyuUaZ24hKhCVCGoVFjuZ3nsyMhNfPU6joINhTUJtzQ0aJ0rW/ yUBPuoSCJOgiT0EHr7C6BEfv+CI+9OiY8JQnSbSb9Fxkxy3fer/RIdSQ8FEFerVze9TDnfpbv2e0 m9bQIGp3O9enp94Qwg7r8w53r7ne6M6dF3RdxV6++tyJRcLXtux63+K7fr9+tXklBd+tzSLhfrt0 raWl//f/f+hr1/v/v9Ur73x/rXp/tvh8Pfu9D/qf96pThPT02eX7/+CHZ7/mRX7an5yuKBj9/YIj jL8ERxl+1iP/H36mgod962Fi/7StbWo7X+bv476//UN+G9tLm522t8R4vZ7YimDSXbVjbSbSZNzj hbDCQ/Xbda2UObdMfHgxuDHFTo1QxjtNcbTFS8vG1FMUDiKN2KHrGMXi4tC0IOIOGhEXaEMIR2EG CacWhDCa2mgwhEQ0PO+QkVxdxERn+IiIiIiIjFd3IXluqIo3Ela3lUFE6CipS4jorw0DI4hC8ipi QkS4hBDOxtEZEJEDjWZJ5CshM1mSgyNcrlmYUODCaZKZShFHFkFyFZC8JxkoZHQVSNegyjKEmEy/ IxiPo1iBMpxCVCEMKg0yEEhNODg5uYRfMJhBJ9eYXM7ZPqEVBEddH9G/po0NbkPptZoaro0Z4YWr zuHO4aTdNoVXBE9l9tcj9ObTb9Cfu+m90nQIj7sq/osc49JtF3RszQkm9zak40Z+4MOgYOnp5oC/ 4qONbsGHzd//fWrIVV41eghap0EKTVA3Tr3BCZa+uxBgxBv/6j6ImKSsZKxa8MMabkKPM2RwrevH uv4IE/j74/3/w/7369Ob9D/v8eP4/9df43/cf3v4f9IJf/81NkWIlpktOwih2q87ljlD2p/r8590 Yt/DDWzy+z3Z5X0hHZ7h/opebIi+ECjjtVp5j5x6BEfgiPREYIvjlHEXH5sx/rhr1DDmcp8XaxxZ 0CNrk4YD71wgohLxHe9Y44yxzDwlpf9P+xdCxFHSBaF9sJelDSmcrKg9iKiChTHzWVn9S6frhCc0 OEiMa/MfuhbUS0/RusVP1G7MoFNCM3FRG1BQTTtDzniMWIiIjzglxdpxGRjlD2FBCLTsLdpqg0NC 8GCqEIiIi8x4hoREZyELCEREREREY1iLiIjERJs6KhFOZJ50ZiKjJYiDMiDK4PlcLy0FUVwJJppm oL6hMvppqfUrlQmV05wyL2Q7RodbZ1CLo0NGh6ddB+/pNozlD4T0gRH7SbSbfovOjR33evEOujDn fW9PXfQTloMAvQYb/+7tv1tr/7u5IVxrfXX8wh////zCQx3Oh3eCGEyOO1T/+3++0k157XsMdIU6 WaBYYX/0tXXm7j9vZNzjpkx1HpMVsOojYYSiH/2tw4OIg4octwQYQxhpikNrzdFoWvmcococ49oQ aaDCDU3FDxHCEREYQiIaEREYQjERGWsVIqEbRTmRBknkJkKyEynRtFcJF+VyjLQpwTL4TVMJkYKa xSVCGoVNNfZ9FoEwi2to0NFwwoUKFC6300kCI+6BEfdJum0WPROMkPRY5T0CI+6O/9Iw5nlcDq+v p6dBDBDP6hC1Td+9/a1///31HHXX99W3a//5hL+/vX9Dv6f/7W37PbZ7s8mz3++v/DXrer0trGTh gigYNAxaS31n+9qLEUxFRatpaqrEUxH74pppDYpG7MjN5T5Y5VlPaYXoWgwmkXBTlD2E7tdC0whF 2E1ES0AWIi0Ig0IiIiIiI8twiETsrcmxRELjv47nFccyWnZJTK4QQk8lDMRUZ0ZikOVnUicgQ7Tg rlqMI7gaBggwgwg0Gg4YTMippkZgpCf+8w4Z1zDVBmQouE7TT0WO0WO0W9Fu0DmhmQkaaN7CGahN v7o+aa0f0aKdwui7aNjRraCDaCDoJuEHZ4DSbQndpOoWF8J8LSBEevSb3zv6enSbp6unW6DB06NC bq5/zDndK69iCJjFT/v9e61/9X73EGGvW+6jW35my4X0F9t9W/rdb7p1/+v/r9/33/Yf8fX/3p6v f1urUIJ+3X7Pf3rU/7oimGD+lvMgMMfX7XW1brVuiKYIK1x44ML/aQrtrgwbGs0FD3Wt9Q1tJtJt K1YaVhYhWEm0uO26Y3WKy4WloXhpAzNNDEbFMcVGxTGxUExXznzDmHtRsIcNRQ/sU9pphBoMJphM KCDQtCNC4tCIyS1DCqDBBghEREUhERFlNcDEXGJZhOlcLRbKqJK5SrWujZ9lpTkh7r/t/tWe4IU1 HUVsk2Vk3YNC1xjLVCkZ5ZFPldS0wg1lcrE03ro1vhF4vcsgkjyXTv4TBD0Nur+27ppG/c+ojHXF hp+paUYvmgoeIxES2S2yI05yGGm5XFUSEWkfn/TT9L+4IFfLNMkR0R0R0R9RCLaZ0KCEREd28IqC Np4jOUOccoezoqDD4iL33f/ivtDIjTm0IztPUR///////////+QHRdR//5AdKO8f//////////// ///////////////////////////////////////////yAw1Uf/wQUf////////////////////// ///kB0C7x//////////////////LNEZ0zsWzClctRHRZRoXPoKp2ri5yuUhQqpretOfr6BEfep3d Go1G+v9yyloMaen//069oV//MH+2c//XrtrGjc71il3sGRxr7EU0ojYqf400NQwTuIMIYiIybGiw ybKMrOa4vkXRnELzsxl/aIIC1yJguSoQLllLXK6pQ2Hr0FW5Fac8yDcty3ejvbng2ZsoER953D4Y ZC6EHyB5zX8auhr8GRWmOVyxGOmGR9P3TBDX9//BuVxYF0P7/f//8GrhE411jP/1+z3/jmOzKg3D Vr/fVqRMF71/wsWMe2I2GEtiKu9QrYQ0wmKmRa+9YYQgwmE1QMEMREREREZbCWpZVZFeI7HIqeQt HatmKy3FhJN55K4v5kZCJkrEJQk95BG6tyuUhVC2diWqNbW+rYaM5ndN99GzTaLvvTzQaKTt0ajV HfnZf0h3hD/pP02+nMuDH67//9N3/XX/////tbvzH/x2e7Wz2CHa3u2l7Xf149KNK0nWmPsGRxdW IqY/K2GMGbYmOKFhNWITT18/7n+4YQaEYYQ0GqxqY6EaEMFERERFxGWaXScm5hlIjsIyuRkURHzC CnQKQtGQzLerk3+CapqhEdBct6CSuUs/mR/RbvRnb84X1p3ugm+n54NfS0btGcP+n1sxmSxmMjjG nhm4l3O53mXo5rQ6Ddf2aBj8KhpXH+2mEP7f/q/v3wv/77tginr1MioRQ/Gf/zjX8Z/tnPtrEVa1 xEftpY/+h4bFU2lfIxyh/sNKy6L2x/28GdQNrZREdiojHHn/d8MIXERaVhCIxEREWf0JTT0t1iK4 plcCQidLggZ2hEtamRnF8oyPl0R0pTxdFR2d/nZWi3ry3EovvTTIOCZ2rlXQiI1s6BYefztRp4XG jezscIdN0W7QaCW8L0w//W6Tf6CbRnFI73ng1536NkjD/fne+nRu909Qvxpte9wYZfv8t4zAT/9D /q1+r1u03G3+qr//r/N///jhFj4/5oKe/77PLX3/91vSzogkHUEMaH9dpMNMnDDaqCHet0+p0CoQ nn+l8aVsKhtEhQwlGxFMbEUlC/O1H7HYrBnTiLZoKcoe0wmmcIFj47CtT/+hEOIaDCqqGhGIiLKI iIiIiMtzPESbqeTcjqTcwMqIl0VEQeQegyry+dq2YjtK4MtxSldUgp28XypaZrEOkEzWJZDVthb3 O1RXByDtIzK4IIdjiLZKhEbKqmvbwRHNftPngG3VE3q6VWjYmp3aNn8Q2gRH3hPuLzWZ3RsgrSBF 1ow537pD7pCT5HRHRHQRQ/sMMwq/3wgVO9IQi7jX1t/pe6EREV8fd/6S3/9f/30v+gix/Vf9u/eH //2tnONKz3OhmgYSB9+87BQwDB6Xs5zuMx3r92lFusf0dS7VWwtGSPtXxe2rGld0W6sMbS/gzA1b EUxQM0hgpihrnyYppjtG5C1P0adgtphPJNxZZuiHaFqZFpxFoRFoGEIwQ2hDiIiIiIjES0fkbRNg iluqinZhFWjsCyuV5BxBc6Z/OnkYyPhM7ojtTZiIRBAy3KuV1TQZ2fhrkhKdAhKF6yCEA0IpfOsC aZbiWR9ZXLAqN75B0T/l9SuXEVO7W4OWPOxwlN+jW0I6ST7fr6zZ3tWZy3c7uFNdKnpAiPJOiQ6z dr58PG/+dzvp/iCLpIO4gwxpudzu1+nq53h/7ZSgwre+/r27bWa4ab3V/d9f9e7Tf9dw1iP3HTX+ zRBL//f/f4/zuVP+hu/qCGQxSP69hJ/+/S7r+saj38w8GYcq/qdAlS3HdVEFYS/bCUatr/K5YF3V tJqj/Q/GkDMDTsMKMJhrbHG6sVsdBTDlQVEXjH/FqYK07FQmKHDCGmhrNu0ItUGENCIYQ1uGFsIM IREYiIiIiIiIjKZFaVyjMlnKhHZgyvmdxF8hI15fNYyMIqImkdmUXyoztbwg+ZDWU6U1IKEzJL7X NQQJ3aZqCUf1v/ZHRHMy1ECGENGt7rek6NdGt/r+jW8RDULVP6BEfdGygRH9K0nRs3oER9/rN+0Y c7qb8/tb+vSGm+nrSF+vJ0bRHwp2CBj/Od13Q/X/763329/6aEf/398fdf//6/Q//RnKHKcqNqv/ 2z6u1CH/Zy2qvurPf+M/8RHiMtIKX/4MFOsR0EnSq9KO1VtXWOf96rv4xW29DQjhqDPugjViKioY S/Yiv+dGVwomo+CYraZ+tNMUjfraHHEdC1P+fYsEIMIRDCDCDCEREGCES1wnEREREREak3NUMt1J KQvLcLyXRERfIOIREJkJkLzscjskyN52t9OGQPsugRQ86QQa5qECZD11tT+ahMtyv5fP8PiRG5ge q2FOoTfJSIjQ3ULlur/XwRHe2lU7tHfzZS/VJu3m7//oMPnw8Z3PH396Gdzv7J0R0RzWdzvp36E7 BAwZDQMRlpAi/iGzSMBEm/7/X9dvcIRH7f3+uK3r6/f//+/6X/5hIfPZQ5V5hzjnHKHKhi2IyaYJ c3f/4rfVs9/ghzIr9pJ9ntRHoREfxCGu1/9L0jQF/0vf21pG+Thh/4M34XtpDsbSsRXxgzJ18aEb 6+IlqC6vwVcY0O8yItOOLV1zIj5xR6FwwhEGCGgwqFgp0RFoREYuIiIiIiMSy9k2WlLdajsNFOzs yRXzJdEYRUZ1ZiITNZQyuYiMM7SxmRTEehBqEyrztWrMjIQ6MINM69+ahE4dH9Uwr0WO9Fu9cLSo 1tem1RrcP50H2pmtr0EG+E33c3and0271ou6WRh/9PO+9Pq/T0Pur/vCGnBhl+/1v3rlbjASs0i4 X9f//+42+OnS/9r///v//0CJvQ+/++83bzG8/wTI8EoZzYrtInDFq2e7zokE/Me6TeltRrdJR+Iz JYDGutNpIbaxCdG/Xa3rbS+L/YJWlNAwdNiuKhK/7FMRWMdDfDPI0MiNXtTdDULHktmSatDi7iIz HuLQsJ2hxGM5EREREREYiWlWpN55FM7K0YRXvKeL53TOoyryEzXF87ojskGpkFVSEsJpmSV2utms TXOzXTTy+f5B2oUFVk2NAvl8/q+626NbXW95rf7Y+l9AiP66BEffSdF50d7+lkLS/NZ4ebv+ltvd eUpGwlXCEoyPEfX/unTf6by1BdaycMf1/X6a74QiNf/tO/XcY3sZfC///zDmH63/9dUxH/50WI71 BD9Roe6bOcyL+CHe7/ybmuR0CKHS4MjHv1V9K7aof3pU6iGbra1QiN7n/EYM6gRusNLfYjBn2liq 2KHCqva2hdip/jsLaHasoSiIYTiIMLERcGCEGEWoCokURERERERy3JEd0yiKdFWibGuahkGiHkmz eVGQmQ47rztTZiKllvr7jJDTKdEdBTtXmGqnWCDUvn1dmoTZD7Ne2SjUt6IjoKEqIYMquEI7t0a3 d+nC14a17ghFDeaDRXC6O/pukZ9b7aLzy3Ldo3af8tQrWbDu6fRn3N1BbZX1iOiOiPrvVd/XCEoI jywg70PfZkNAuRIOR5GcqI63Vt63oddCIjX/9d8IR//XQTCF0t9vrH/6//2I9bljnH99/8k5xyhy nzPfctQqX7v9bPq/nRdY97ps50J/62zneCHBCIvnTTbx606t9MkPY0vtJpQZ+thScMd2uhthUq6/ XdPaURodL7HruxSvTGOxRKcREXirGLG1M8cXaGh2FMiO1P9hYvYTCYVH8RDCERaEQwncXGIiIiIi I5bmiO5oq0U7JskyEyDiLmYyoyDjt4vmRajsDZfO4i+SuL5Bep28mFCDJtX5TpfvNQi2ZCsg11tP JTIOW6wIm51Cot62CG7WdQiq9prrq3rCr9Nu6Wk+jZQIj/U7532jvdGddTu83Z36N6SbLcCZhfO5 4ZOjZLVow54pDV5knOkrS3/r0t9Cl3Q16D/9ND+vfe////T//++/DVf/v+/+vr1/67S931drtgh/ Yz/6/hnO+nv2+v99jXZufyjQZHRHbpCHruvYYW2+NilFjX1b1tVpLHGqERw1BwZgdj9iuKWKpWIq IpiKf7FIkPYoXGhwwhdn+GhaaDCDQtZ/sJgiQmEIiIYQiwQiIjEREREcm6nG87V5XRkZF87pmvMI jMwjqZjKjJpHZnl8oyNZfOxPJpEKyS8tzPTuy6N5ktya524gTtO6tc9hbUvn8LZ2TEZBBUggsZw/ XEQemtquF9zqJWr/pund69p2Qg/negRH3Rsow/Rn9Wt6BEf69Gfo3KazO5cGd1O76Vz9bpbr6Gnu u6edzvfp7v67oad4TvW8twuMBP9+v/9/fX279P//+/vVeq7r/1/+vrf/H9MR/Te97913ncocofaX 8f/Z7vq+uv12t7+zn/9/xxF21f2lY0o31fVhr/N21UGf76nYgF7CTTaVMYS/FWousfEVEUxWx1sR XxFJMYxi16w0xQtNT/DQaDCGn2hw0zosJoajhhBhCDBCIYQMIWCEQYQhghEGEDBDEREREREZZpdS 3M87nmQhFe86Z/J2R0R0R0mQedMjUQeQmQcdmuZRkJnSOyrO6ZCslcX5bqQVSlBg1I3HZKL6oREZ 1EkEDR0+zqIp7O1UTz2dqLO8SkrSheh6YTC+szpbW/C+F6/OxwgIa3mcmOp4LHrBEfRIf31NlG6z QZ2i81dTd+bvfVpJTv7UIGxhA9U2jejJYMjiWECI+NN0KTvCHc0zbWhfoShEfI5q/vO53zud37xr 7pfGMGKH+r/0wh9+EIjv/2/df9r/8w5ONff7elXx/Hr/+/+vutz6SFycH9z3/ZzBDGf9ntbPcyKg hX//pb3pjSi/TsJE4YbrOAvXk4Yn+dgoY+f9f98a7W1pVfmPY1jFIGYHtfWvwZ90sexsVYpig/M5 TxxFqZFqZGhqZEeZEcfGhpq00I0IaEMJoQwQuItCIiIiIjERERERLKD5bZaJLc0R2Jo7SkZGZFXm uL50MvFRkHkLzozEd0ztbjXF8jMvmRXEKQShTueakR0mamX001Xp1Ifko/bJoFO1P1sJtmQpJkoY Qc0AiOpbrAmEIpfRrZ1CLdW/31+6uvp1aQjC+u6TpIER96f7q6ebPaBEf0Z/U8ed7n1m6S9zdnfa 1c7nfX+T5uBFD99/p/ruu/6S4vQ2RMMVaW52nZcJ/t/+oQj//f67/f///i/////f+uvjf9V6//zt W7PrnR/UNI3O6/9fGf4IUCFWudggY3/qPj12Fa865HgrfQ+2t/fTYS+qtI7NQtWqtqtK0rn/GPaE VEfsVTGxGx+DMFHUCqBmUCKiKDS6yMf3qE0LtDTTCHrDU21u00LCGo8/xdnJhCykgQMEIu4i4MIG CEUZzjqIiIiIiIiLQh5ZiVHa2hGTYGipoqEU7O0kV4MxmoIQeQmS6IuyOwpUI7UGYzIYiTzsSzv8 hSlusxfNbslSVMIORyNNpHXshhTo0GEI0+zJDQZ187UedmsEyUMIOFtdDOoVFu5CySgnnB/086hG n0/v06vbra8IOyrf+8+KkZ7PBr9dIz/7qeNIz6M/ne83Ub12NVckOXp8N1WNNow54pXVX3T/9eu1 9rxVwQL2P3/0nr9///7++v+Lb/9IjHXj/6+3f9dWv19d6f/dIGG3zjB3H33e6UeCGCFR8fuv0iVZ dBSfgyOdqw4YXM1R0C0raW/DC0tVQVpbFreoQikI4anaiBJioYU6dOrFPGxTqDPsSNui9cUxFQWa BiIIMKPnA00LQYQtbQtC1DTUyc5CuWukiItCIiIjEREZyEwp/iUiiIiITK4jk3hmVZlc1IlTMRBo qWU8XRqCGoaDIGiozsSjt4vkri+SyL8t0vKiCDKjCafnSCZKxVtU2GRiTNYp2oCra2F5bkjCfM7O lc0NGt03aYTC8wQ0OccO3C6um/ft0n9J0np6nei8zv9JxDfovM2UCI/ozrR3vhTvWn3pvtekroV7 YZc6cGDLruENPX0nf/SzQMK369b/9VvFdoX+Lf/6/+/Wv//6b/kh10ETH9X/71/+p8Kx/ZdK/dXx +e71RgbzJLSCDR4MNnNf+t9ceo70CEVatq2EnUiYYfSc+m1iFbUZ2oCsaTarGlpX4a02lFRVKnEd rFQsMwTUcRTFWlrYo1cUGg0LTOhBhIYahbzdm2gJpqLQuGsNBhCNOGFbBO0LTiIjERERERnmhERE yLchalmKmdzxEm62lCybVsqqIrnYKivfDKiL8MgWQmVCIRHdM7BciuQmdpBnbhCUBCCdBhbTMlv4 a8Mp/Oq0yHpnZqvLoz/VBJEpkHRY7JUImab3zjhrcP086hN09b/Rrc4UcLrQQbTYa/YtoER9yVnd 9/9//T+Zqp3etG9A3rWDBl1XgwzC3p0Zyo90/5Pm0R1k+YiOlVtkhzFA/eruIYo7EAvvH/HX9LfX v6hCNNCOuPS+/9ahFv/CLfrr7r6xH9bejDgkaCitr/0XechghR0QSDf5F0kHBCgQr8IYIU4z/Gf+ lQ0LFe0iKpBm4ihXrUQu9YhfTbfVAz//7XM1mawtsKhFQv2UOcIFsRUKwyy5YTGGbcz7Sv/sVBkd BYZdBWqk2oC90IuPCoNVTTQtPjjjtRHEYwvOhUIi4YIXd2E7iIjMPxzkIRERERERhGfKpiJ2J5aX IREaZbjZEmjURKojSKhHXOyhHZnggzIF5brWXiEyUo3KdjcmFs6su6P6aan0dq5B6ZkUoLC5qETT BdGtnUIEa3p/nUTT09GtghVNwlqCJOnp0t2p336v1O76bWjPuSH1O7BAiPidhEq3O54dNpLb5pnE qM5Ub0lzsERzI6Cq6M5369Ge67kRIFgh0/+vXemCFUv/ugwhH/t//bpeH/r/5hfx/23Fddbr/+v2 64cPnI3X3dLHSjP+31b0mp/9P+63+NJudxmF7a23TrtLP+7/m5xqPwwv97X/UPhtPViuNCN1+t46 2l8y4MceIrY2Eo4MYu0NYtDji09C49i1aGhDQh6DBA1OiIiwhERnIjERDQiIiIjJuTM6rJsa52oR W0VChA4ZgU7MGZGeQgQ6IzyGzeVaQZA8h5dF0EyfOIKdxF0dqkQefjTOwWO3i+SuL5Kxy3M86aJv i01PaUNbsLB2CERSEa3nvSy+fztIiPqtp2nLdYEU/oEG5KCh6ND+cJVrOoSQoTpBev/whFLpOjXr qk24uk3/apN5GFU8GvNB8zvu+1X9AiPugRH+m6N13pwYbVO+yQ5tAgQlRrR3PEJFCI6I+XQUabFW 19+0CLp/RnKjX03avobXwwxXvjFx/9F6CIj3q63vBih/pW//f+w/3fjRMcLuv/X6/j4j2/b/V+2h 2oX1ghNQpH3/sGToZHW9vSUnDD3/XdVrTOavQQI92s3dE3HDC3dHRW9tpa+s/0wZuv7aq6aw0pbq QYm7DCggltKrhm5p2KdjQr2GrFMR/MhV8cRURRFAxV3YqKYoajp2EPI0iimmE+Iji001dnRHDCsN D7iGFBCGEGEGEIiIjMfERGc8Z/iIsIRERk3E8WhEmmNROy+VzkS2L5CdlTi+SzL53BHazmEdckyM i1ELUtzPIOIVhVLpNb4a4W0wmnn9MyFZBkoaDluSedApKQgL2f0a6vwYXV0a2r+jW7T096SgiUa1 StAiP/O7nfaBEe6bRh/ek9Iz6nfq5uz+go++9XmiOIjoEU8QYfvT69O2/3VdJX328Qi7//1oMIRG 6/97/30/3/1HX2Mji+Y//OqC/60/6of/X/reHxv/4z/UIL12vS+ttKPjqCGRiWGbp3GYwZY532El vX4hP1arDWHSz/tWlaXR1Cx7a0LxGxFXwmI2IopYYYiu4ql1gzgwXnya1aHhNNYaqg0NC15gs/oQ 4jMeGCGgwQYU6GGEIsIRiIiHERERFoRLcPiJ2p5NjUSTeGaxSMRNvRUkSyL51yDiNKyrI7S47nkK 05NtNBoNS3NGEyUaa6n1IIQfnDCZ2SCLovnRBxcsdo3tT1p24X02HvBzWwp2ahCUBITdtBOk/1O/ ud9/Lct387tJ0bqSq+azO6bq36W6/dvhB37EGHV0M7ndzueNendX3v690vel/3/9//97/3/Wt+h9 /RkZILu3//a/v/ir8EKfVXrBDUJWlZy+/t/1VpRqxrX1Nz16iCbWPutvhpbV215udKDMFCP4aiDO vgVqtsdxTFWKGKmpaxqg0OxXCYhTzjjtWmmmhaEWEIYT0GhoGEGEDBRERERERERGWk8diiK4TOzN nfxBaW5JkbRUkSzMZ2Yi+ZGiI5GpkfNaMM1I3AgzpFZiGdncMvyQgqy9pAwgYQZFso9nkR9NNPXC GthNQmE1kHF9WvBoNNFu0WPRbvXEQ31tbVXq3giPzW21p1uew36DoINoJveyEH+jvdAiPujckZ/S M+qtJ5rM7Rv1zvx6ndpN0+/58TrX9fQ131aS9XTvj2u4IElv/dXHVuzcXCkTi4Rf/v/66f1/+vrS /6/1uv7/+59fX/r13ufV038P1db26nP+rCn61Pz9f7Tb+PY6b3rtN19IGGx1dOuv73FcV/q9Y41a C0sNbV44qNTJGtK2FJkooiqQr7YUX32I2IpWKa32KYoVaYqITrFBC0L3sUOOwmp/QYQiIsJpn+DC DCk9pQUjHojHiNhCIYQiIiIiIwQs6LOjETCLKFIRERJX00zs0y3ShJbmeT5S8jMvnUKdiWV4jqjk QmQcS8U6I6I8QqNUXrBBlRHSOyqTO0rlutSalV8L0dpBMIfkPcEI9PhpnXfPeje+EKoxn/tbRtiX +vV1eDmt/3pP19fQIj7vNmp+/3P809Gfzw0n7eur6N/33r7NuhMiWLhNzSMBDNlwm6jItRb67EGH V73nYiLhfOywF9Df//Hrjdrrr//1v7etbvtiPVfraRu9T/am6qT08/fo7NcLa4SCGGkbn8x9z6wQ p/n2JM9j9D4+EOzlMT9+hC6BDx+P8YMscqK3rnZgF+yGF/uox9jWCbC1Nz/fptC7KHM5xwmIqz3t cJ9qgZwdrYqExQM4RUPNT+Z9YuItRzHi1ONoX5vi0wqaxcRER0fxGgwlEOIiIiIi0IjERFn9CTYp Qk2MES04imUmEGEHJsEyFoqMhEdiaK4FkXis51RusEGdoztbzWy+a2R47EtF2wibsyLeVywZ2Rms VM1i2dqEn57JUIE04aanal66udqK0m0EG7hA7CkpEBVT/sJawc+e9df4Qeg9UTvosc49ZcXd9/an dsqA1berRn3O+9+6voEG6hC1O53whJ0vlfUMXSM53+4g3WUqLhd69Ld9dcyAgX05W2XCY/6ZcL+3 +2v/rX+//vT6VfX9v/50UP/8h4SvMbU/VC+t6nYgi4/6Z0b7U3bPf9ntqfoIa6v7FKxCdLFbCFX0 /UVa2t+GFGuP8nDA7pfNz/1QKNfpjWNWRBwmGEmGk92Ku/tVVQZl1C6+NrhIbWDOrFMUGbfCmPqw h0Xl2KmPHccWhaEaxrYTTQMIMEIlpAnK4ImmnFqnEREWpyIiIiI8RERERERlpdkUylostFJtWZVE VCKhFuNo3FRkHGpkeJwwQdIOoOGf2djo3mQPITOxKKWiQiKIoyVoj6Z2FCS3M9NUzolTTNYp09Xz qEtbVNBmQYQh+dpBE1T0Iwg5XVYmdaNDJT2Q7u9Qu68zkx6zentdVuwk/4VGn/pNq+6vU7tfnfcK CdG/SC7Wp3aNy+ccz1/n/Tet6d999d53PHtdxV8cJHQMGu96GnV+Njx3lcoBev//6//r+rcQgl// /b1/1//69r/evrfhBHubCrqqXZ9Wv7Oezn2eX5nKgqIIp2CXghk4YBDYpLvBDfp+zkguhwRC7NRq 2oIU/rr2mwwvEbiO1SqtO36jW0jQFwh/LjpIXXf/xxCvtNpBljhMm5UJlDmcE1TxQM6gUxX707V4 M2xOxvv4a3hmUCg4g4iLiLQtbTU5GakesWFP6oWEIiM/xiLTX0IiIiNNCIcREREYiIiIiTYnSzFS OyhEuZLoriiMiAhNBSVCyuFI7Go3lSzI+V/i/kayDyniPHRw4YIGU7I8dzjsEDBLIvpBMJlTzta6 Z2HKpLBc+l4MgxSHYV93TVzscIoXRt4XzRfPOwU1/thewtwwva9WQmjZXWaK/CbhN4Tf8J0SH/O9 54DWtGf061c7+frU/Z325/335of/5/V/4g3O542/trk+6ul2oitrvH/kTi4Wm/nZrFwv4t//+/X/ /+70/+uv+3fWv4/yHhftV9X4r/X/9G3nf5/7f2p+32eS+thBfghTfVrb99WcrV9LjjH7Yrit6xc/ 40ogrbqo1bCUzlDlDlPhhWNY20r1c/qurDf+xX7HCeMGZQKiqER2KYpWKYio5oKyzn7u/HamcofW wqGnaDC3DCaZ/tMJREPWNCOhBgqENCItCIi4iIiIs/RERiIiIluS4jLczjtTImyojviOkW6cSW6w EO4REYIM7AjK/RCs6OGQnedisXzskZfNbI8EjtXyuqySZfsjouiPInbQZklhSUiedPZx8Guurons Dn/o26biIhwnRoaQWE94vBhbXXha392RB3TaTzdm732rO4c73nfc77c+n6uekd+jZDq9O1dDvuRP cQb/S3S3i75XKAXj/r6+xfXr91//+m/Vf7f/W39pRnTBJ/9f0bYkPM5xzPn3P/22t62c20gQ9Qgv W+r0tdCLa3ra1aTqZJQQigYYYWpnKHKHOPiFekxq6q56m71c+mIptIWGsUkrFAzFiER2CYjYpiKR GOnf8W1FMU0zlh0Qwq3SYTTUY1FpWEGmCDCERERpxEZnKHYxm5CIiItCNoTumQvJvNCdi8dmalcK YkwiCBCEwp2IyvVEHkHEJnRwzUMlsXzWy+dzztTiNRCIIM7pLTOz4UvqU4wuUeQ/Om5rQIof6a6q dmqvPZqEKdAmix2duISkSg7C3Oogql/77wQiqdGxhbV0/tMEKQQdVo19AiPvqESj+/dXpXXO9535 Ce/o3LptG6jd0/t9nKf4IER8fzJYDG+87lR33/S7Tfb6FGcqK9DQkFztaq2VuLha7Y8UC/1r1W7/ //f/rpW/9O/rWul+xHM5Q5Q536XXu6//66rG3t79twcHejG0jd3qcIz6g96ERwQwQ3/q/9vqgQ1s 5t/atnOzm3e/Hu6XjmHGYwZ7KH/SXrDC2FvWNRqbmaAv62khoYc7WXsL+xFWe+gx4v4MwM4TGxTF MRTFAzbW1/FMV4jiNrajmHKHuZnWLVYtBhMJhNOLU6ELhqf8/6i010IOIcREREQaEaERERERzIiM /xFxGIiJKsSzhaMkKTZOzsNAiI3KzgzlByZhzAz7HOBHKj8baqDKjOumdl8hWSuL52lKVy3O6oJk ti+qZbiqC6ntXOitT2dGg11Ovqe8vnq9bTqf9Fuwt6N7BCvsLp/ethUa3d90vWv9XQTe/Trvzvt3 6andt9N1v7/o737606O/1udzvJwxf/5LpvSXggQlOlfe/3KVmAhE8wE/Oy0F9uVsF//NIuFp129u l39Bv9OND/t96pqmv/bWv///5nJD0P9Vhof9/qhTEdTDlRqZzj/5jqhz4U5Tu//n/e/0LpvpAhsN Y0gUvuoIUrjQuNC++9/EXdb1H4//m7etPNzaVFwO0qm5gz9/4wl9G7rDCTEV/x/7EYMwoqp13YwZ wn399j/9ZmC7Q8x4tDi0wnEcWmnYWNDQ44YQjdxa2nGhEQYVCNODCcRERiIzkREREREYidq8txeM kilutI7Ke3I1kJkJmoiL5HRHRHwmQmQedIqcXztKypZ2BIvGQnyuCyZ2HGgLwzsazDgyMC6phCIj NQhr1z2udqfksSnasJII1CorX34aaaB+dAiNbpQh+t3YQpYY/5oNCIw6nHs7ubPpPPBso2V7R3vu s/2aDP+o0Gww6VsQYdOUMj5HKdyo+NXQozlRevyXdaM5UVFBO/zscMJW2R/rcbQj+/36Xv//7v2/ 6+h/mS2gSdVTd8x/+3H/6+7/f5j+gicfpNBLMjv//Z7tvX9wQr+zlr/3tToN49iEU4V9/hhJbWN9 ZuxpDT/HaTX3VtUFbQWFX8cRsUvFVsYMwXjVjH9bFMLF0FMNRaVpn+LjtULTP9r0LTVULiLBTIhh VQYQhgnERBgoiIiIiIiIiIidkqlpF4t1NJybIRWGTCOyVGEVwNGsiojpnqyri+U8XyF53EXzsTyh EdF4jpM1EdikZFnDLSJFK5JnbxfTQYUhMKmV1aCpmoIqsNdcliVe0IiKTzIWwRQ+GNQvDM9Fjs1i GoQK5XLiI1tbSg1tbBDW/RrbhCM7VTut3oJ1CwRHtaeft2azQIj7oER99AiPu88HzT6Qb873ZTh9 No3Zhzukn0ZyoraiwQISnQMMwq+vRhzxrzsRmMj4IoeO2udiIuFO+RC+dzuwwZH5XKhr+LHvQ1t6 3/W40MWt/9f+mhEav68O/eOENffX//7bv7Cu1/+3/175jefqBwf4InHv6Lv5fs+v96/erOYKXR0Q RPFr///jN378V27/OwsXzkfU0Ht1cML/aW+tqaAui4FoQu9b1bbW9LtsLa/hsN/wn63pQuGF4+9i K4pivahWxFMRXGxHWxURu4NA1scL+xFQhQj9jcXamPq2FtNC00NQlHERqFxdr5/i0GEwgwmmha2j UgYTBBhCDCmRERGIjOQhEREREREREREZNgmJ/EtBJ1JUIZDMrxk8SZmI6MxFPF8hMp8vlPF8l8iI vkL1OyuIOMjTL5LIuiFI7VKVyTO/wqmuLxCZ2YSmSUry6M1/rqFtc6yYXJUIwZ2JCGoQJ2FslEEH nupNOwqMofnagKn0mrT02F3XW1TXWGFCpOv33dcESfST/v9pXXO+9AgV0CI+7U7532jZncObM2YI j1zv6Rnv/cFez2gRf+f7+/T7+5OjCI6Wl6/213SGgYaQpCk+vfXfK5Ui6X0XcWOuzQMf99euvhCI 1v/SXr8X/3rf9uoQjfS/XUbXYjtX6/ev/r/chEEv9fX9C/rD0YHepkcEPerVvWZHf/vW9Kz2mEmz 22eV9N9R65yJSgeCI4y/V/52rRHa0DNzhq2lfVdqt6saTrxsQUcW+v9LN3/hvs9sa+hFAzBOxUVE fsRTEVXEfCVYimIp1r+TToGONimuCcaDQaDCHaaGgwp+wpuzdDTQtC1HxD7CHnXtCIgwhDCDBCGF T7TTTQYIMIRiIefoiIiIiIiIiIj8SygtJsexMgJFe815jNZHeZfJCPovGsiMi6shZEnnaQiTyHFY RLYvnZrkKiS52l8rhRnaOMheS+RkX1VPTC2EIwmtw0GqayCC5na8ggqQQWLdnZILCDO3yOTqdGEG t7hdGtr1NDC7Dmi6LhmoRhqmtw2Hpglmihyf39X+d906BEfeez5Sed9lOaTfCbWW5bup3o73Zbmj NBY+EjP6TaJDoMP4U70CLrzJZRdEdL7rdeKTdP+DDMKnJ0cSrozlRhB3pb/hPdB360Zyo6ed7gwx InGAmldJ2djAwhEa/X3/6W8fphD3pb/6f9Jt12/6W/+2G9f+q1/3//78L//26/6/+vr/2/19eZzj /rfRkZyL6Vrtf3vpHVBF59qf/2+/31///H2/9/BBG8aF4+1/vv20r1tW1/QhPYUfbS9bXY1vStXd XpX/a/hBftKxpfqxHGxFMMJE4YYjhbDS1YYV77UaViNhhIYoXXjLSBVYrjCkcftKxji7CDCaYq2F WxQuxVMUxQtMJimhoWhtC1GOLCYTiGE0GE1MeGmsMIQwQtBhCDCDCDCEYYQzQUOVERERERacRERE REYtCIcm4qhErgUZDFETtWKVxBHdWUI2kyDzpno1xfOmfyEyFo7E0dkwpColGSxl0R9M7oiFolmX ztbpXLc7nhM7FPO/ChCKOq/X1NYqZ2oSdErEU+kIjVMLZ2Fh+f89IvmdpBEY5zTp2qrrhe9GUtJz Do7HCEpEV6r/CdX0XCng1/tUCI/baou9bui730zZ1QIj/Nm/vtow53+0HGm6dta3tYTRFUbV92ck E09DVow54ozlRpvp97evW6HTav4Ynr+GJSeITQrqPG/evpfWxbt9r/+P+rT+/r6Tx/9339eNDr9t ncqyh+6ghROD+poD2e2FN0EOYLZ5L/vtvta14+/EXJoFv076TjHtJ4ubtrba/2qnYWHz9Ru9uq9M MJBlucM0FXYjmc/fwZtibOS1sU972kxFVV3eal4qR78zlFxTQ0INMJoXn6NOhzdfaqKFjDUzTm/W 04tPCFrEWEI7j7TQiGEIYTQjERERERERERm+IiIlTUsoNCIWTdXKdksdmhGrITI1kszCOmQkSxFE VCO0pFQiWZhFSzIUCHa1SuFZ2KoqndnYGzBsg+5nKXn0p9ZPlGFTkEIIINjVNMJpqdmsXZKYu0jt VEqdgTCBkqEg4PTzs1CIuGqen+vDh0agnq7qmqc+1v/Wcdw+eGjekoTvv/oER92WOW7Zblj57Ndd 5331O9qd/P3tTvRuiDDngHC3wgp3O9bt71tab4QNvCDtigrnc7o7JVk6VfIlnMjpa7+2GblHpLdC GGXQg6riEvbp33czi4WPW/dd9/bOwQMBMuFrdMIR66SvH//Qv6tAv740K/61///7/1f6frSf9PYR N52W4S+gke/9Vt5/zH/X///zohqft9DP+9K9Z9rbPfjSbOZ0FeITaqEF/tpT9Ruj/3q67r2v3uK7 6qrGrHXH2lQ4XCigse2tqv/+xHDUYai2ltpa/EU/S0Fs9r3XhcIPqMYYp9rHa2ExTFMUMY44aFxc NPHN3i1N2uENM57CYQiIiItBhBhNNCLQiI4jERERcRxERERGf8crludreV1jEZaCVmCUoZsiJ5Vc qzJNEIsqyKuJX52L5fNZGvKz5bheWkCqVynOy6OkVnKhFPl/wq+XRmlCadw0ynECl+GF01IWuGd8 y7JTF2ZFGo1MI/k0089krwRQ815HMJ3UER46iUaa2nnqaGagnBouGq2ga2i4eek+D01TCH1/8IRh DSeqcIjfC339JtLncOE6M5T0CI+7O4aBEf6bf7ncNqd7U70ter+qoEXWvhEx0OYNV9+nnc7/DD20 har6YdbpPb04gw0u17ncqO/fb53PGdzxq7+0Cb6f8iJuvXzQFxDr4/iDr/v++r0rrbf////18av2 tiOGh++3r/+v/x6kXQS6/6+xH8f/3vT8Nf3hr6/MiSjBJ1bPL86YSf31BCkwleldd/ylBhfv+67W dxl+GhgzZbmgod2v9cQV1F3rEF6VqjOVHYgmPY0n+DM531N277b3VW0lY46wfF20ntb4TaqxFQoj bSx2TClQWl47i5NOt2K4qIpinPnJwVGnFqorYoeFFTQU9qEGop3DUEOKi1/fGhw00IdghcREQwha egwmhaYVMIMIRfEWojQiIiLiIiIiIiIiIjESzdSO1LloJIg8j52QjGSwzVHZWiERUI7Hys5KzNbM ZGGQTMIlZHfZhEszCCD5bkuSeYR2fITOxLkMHFkYzbTwqBqmmReMSR9EsFCfaaaaDTTTtF2+V1Wz +E7zUIdqL6M1hMLaLdshdq/2g+ws0PdGhhXmirroINyCNMcrlv/+vzfgl54aBEfeE3PH+kYf6pNw rSbnfpNo79AiP3T339Hfejd70C+FvV6uNI7nf9U96N9J1etdunXut15zv23r5S0R0R4j609OISy5 Kq/2ZgR4IF7mgYNGXC/b+P+r1/1uv97+r63QiI8fCCiPr6q//70vqGCu/7//+v71/0P129UEe1/3 59L5jDD+50Wpu/odnlq/rev/vr/wQ++kZFT2CFBBbOe2q2q/aqGH/49xSzDnHyMd3VpXT9WrfX1D CitUbr/5OGKQ/igrEVvHmmFtuv91oQ8YI442NtYjYYSjWI20jslKyQ4J3iN7UGbYFgxDVNCKGhNs CUY4416LHhDYTFNMUxQaYqoND4YQ0zo1NTi0GFsELTQiLtH+RjsGE0DBBhBhMIMJguIhhCIiI4iy iMIRERnIQiIiIjERI3iImSSETsTztbiC9SFZOjNFVRLUSTNZlOEO4RCzO+Mk0SoIRfO6BCUhJbrR lWjvIuiQZ2V52DRRkhHGFImGEwgampG4KXyWoEUPTSIXpl9NNUvSIqijlcFMjyDOqsLa6eEGmaxE tMlHaDTWwQjRoaMFwtozsIuGdK0YKn9GBTFj6ujRT12CJ/+kZ2ESjNBo6Nfek03VJv1dIN03v6/+ cdaTfaM+0v+FThAiPiKTfV/U8UZ9kvTz1uekYc7qePT0/uerdz056+rfT0/u3nZdEdkfCx/aC6d/ /+l08VeOtvTv1343444y1Cta//Ja69DQiP11+7br///+v+q//qOqcf/6w/V5h81PVX9N6qXwuvtU 1b6MFf3/fBS6CowVRgUxac//eCFMO+pz6KPe/giORjtYigQiopbvoEU4Zd2v92q2tqhFaNZQ/191 uu2/+t/GFwxtpBpp1Y1EIRtpOf+6Yim0rSpz24u57c9/YioYSBmSlEUu++GlaB2Mp0DOoCpipIfF RuxtRTFGrj9C4truxVC1I9lSERcQ7CHEWEwRRhpRaaDQa0xHURhggwnBhOIhxEREZviIiM/qf1N0 tUwoiIiLQiIiIkphk3NRSkRXJkT5CRwjtQiqoiEdp0JdkEZ2ZxkGYIHLdaMl0YSana3LIOh5MxUz aIiL6ZfTKuL5LECBJhBoMg4qeRMFyDyEiFaaDO1OLuVyTTBNNG5lAYO1MIdifqZ4QcSMjYXo/J2E I5oaLHZ1afR0ryUiIztG/30aGr02q8/4Wi8be630rqk6CDdJ8zlx91SD03SO76TzvtXZ4NmbJ2DX oFRh8IHnwztHfzve9Gfz+qunqeKwoTe6oznfV7+/q1+rGunT8JXel7//7fXair/+ROLhR38zZcLS Xuul8rlDI4Xf39Wxb8Qgtru13/X7X9//7XXf/2/+/LSCl/6/69jQR763//39D+rf/6efr4UK8/e/ Uv+6WOp/2kYr1tK1VQl9rDSf719e/hl3atrHjvahChV7fbS2ONY+/T9N7dHamEm8oehxGxVq7F0x pT/Y1jtKGEmguulTq+qGquv4wsRwwSjSxf2ExQscV7FKxRFAXa6digZhrxUcx7Cr6FtMU1NsD858 x4tMJoXYU32sWEO07QtTDme0IjGpsKHKHQMEDBBghEaEREREREZyIiIiMIT6GNCIcRETbJjIujIY hERJkZLTiJTxCsruZLYIGsMrKIRFO7K0jrG87OjslZSIlSCDBBmRVl1LdaMpwimQhEVOyLpBosdn SW000yr7Tu0yFZUtBphQibtEh2FuVwWTSBTINAgSe4Q0Efk0FBkMirCHQIgRHZqEgyCBPO3EIvXo sdmoJnqEDcEDZFM6a30aGjKdCKQIOiLDSdCmU7hroJ1hrCbXfQQbX0nSddAiPuWkCq6TeCI3q5hv PF654CEMOeCOs3pG7Tow+eA5/7o3X1p5/vVXV/XjWnc9BE3ijDnjqq/2rTDI/hh40PdTxEG8V6Hy Jguuo3e+8a//jQXXq/v/5vi8GG/v/nQJ//+7YIodf7//6/23ad/6fwi44NdnvUv/ZDwoQefT9qsx 79hCPW1F/9qXkYtGYVt/rr2uqkXG1jDN1raX7xBAiUw4YIEnatm4EKp7Wy6I9tpOl696+d6/xGhG w0kI6u447XttYUIOeBdhhJD9bSiObnDShqxFeNJz3hjeP2PhdrxG8VCEdislHuxS1sbFNdDQvBxa nPZz2Eznwt2fs/8XhTkWFP/HaZ/i0GEwmFeZyhynKHeIbDCEREREREREZ0RxERERERERGNCIhqbk 0NCJN9VERElTErp8hMiSITIskzspzsDZ2SopGdkxC3EstJZUmxqggyXM7CoraI6UuRdIhdCeMkO1 I1lJMMkuS+anZ3OCZU8hUoTKlJkzyhEURIWMrkmdmpgpBwRMcMJ0YRmiKwQhsRcHTf5fP4QPh50Y QfnZr6ZKxCUBVP6ZKhEb3p2mp/lctlQzqEhA2i4emmm6I4yxzjuum18003nHD/hN7zW1S1Rsqk/+ 695Y6SSDwn/YZ/m4KhPdN0/9o2VEGHwp3e/pOiQ6m6703OOd/fX2+rhA2jDnfWtkvbXOO9pJq/9/ ryfNhGGXRAwxpa/dWjPfbv9Xenjjf777v+6etYYeIQQ/S969WmFjX3f//bHbX6u/ukPqN1d//Eat 4QRzKF/8R7e7O5UQi3yQ5Y/1/rp/0P9X+eyrU5+WkFLpVq/6tPhjCCtNK1dQ9rQqORcYeCEPHVqU oMNr+q2tvx4v2jOYeMrlIYOx0XQW3426aBm5sG6ginTZHCNpWkGf8a/X7SsMJNX95KAs3W0n1+/x 7QQjfXYYUa8OhGhUbFe9NcFtbSsUDOrFbGgt4+KmP693gzb8FxU58U7iwuRjlJwmhxxarHENMLaG phuGELtOIiI1qcwhEMIRFlEWUBAiEQiIiIiIiIiIiMRERERKMSyEnLQtCqbzuaNEdrOdrWUiOxqJ dkQIStkFGTQUlQpVOVypHYsiudGEg9EHCznB2VGa4vkJkGggzVFXF8p4vhAzU0yU4QaYVPQaZFgw drVU7DzFZ3XnWLsE7Irk8T5PI3e97Ola2dOyGwg089BcLp7ef005gsw7Klo3Ubg1+Xz+mmp6Jp2q f+tJN83eE/q6+qNbqu1ua21+jZRrdIIN6TaTy3LHv7+/vanejvtf6f4Xt7oEXXvU7tJ70d7zvdJ0 n+rp8/7kU+np2FCB1rXCRnvW6S37v5dEdKt7SCIvmAi79J79L1b//9fbfutsa3/+KWdlsXC/+rbv +nX44iP8Qkmv///T/D/1/v7Vfder/77Xt/+mCKfX61671hBHOpN+qrtev/of7/1dIb7qX5nOV8xx 97+6N3Ef0hFAgyOP6b1Z0Zj7XCCxgg70CFfk4PGldfr63vra6XQuvxUd0O94+4pj/r/bXUuP7WmL V2lbWf99R02sMKz/tKH+f4a81lXvbXWDP9oLN2RRwqCsR6/FaH7FAzBBQM4SrFdsRscUxXscRxxH i83FPmwqLFNP9rrBhCwutppw1sw5Y8dpw1i7T0wmEGmEO0utdC1QtND3xERaEQYIRER4QnEJrQiI gwhERERGZGYcqM5ERERERiIi4iUuERehcRk3VCOxdFLifOgxOzVJkSR2oy3HQiJ2Ii3BHCDTjQZI ztBp0mQ4qeXrKuMIhMqMhWdxF9ZCyCj7VA5XJM7G4hUi7Z2XDBFTMG6NjsnRPE/TcIpAtH8J8Gmm dOzqEJSIFslISDKWjUiNo6rRncrhYzsmISkRIN+nJ+0g3DX683Jerw1f1XdZsKH2mqek8FCSwnng 14U8MN9cPfp9Mxzdvnfc8BzvtXm6jdQIj/N2hDf/035IfOOd62NN0rhg2tzoYVSONe9pXbfS8Q2l /pDQ16Qi6ZHDEg48jQYXozlRRnTru7q/WGx9jiP+nHv/f3ff73tiord9L93Xev//okPe6v9D9yHh fXXvrzLXplDljlOUOUOgyh1O5nKH6l/9+7e9/64SNrLmFJydGPfiNe9LCCvonDFnLPf9nK1ERERE VEQ9pWWkVrbbv6t+k2sOlCBLEdf2FzoFn++sQnVaJwXjvUiYLxXx0P17V9WGErCTGFCS8IfYqY9B exFQURR1/Yiun47xXHxTFMU1oc5+1sIRmCeqDXMjP9qY+aSxTi4hoWgwg0I4iIiIiIMFQiIi4tCI s6FDCERErSZzziKhEKzt8RETJJiMSv1YimnakYjskjIKzIRkrELcr5bmma3X5gzlkUzCwQMp4vkG irjXl+yS53eXwgypI1RTxC2iMWDMijL52p6yuWx3AYTBf+8JpkgwkmnZ0YQZ0ChO4ZLewnaDJSwg 5B/l8/+i+hNtNee1TC77CeldUEi4pP3q8NXSdGvSbf9Tw4Ta+vuaCx6NbBEn66t2jP0aBUJtAi64 SM+bM78jD9Ai/7dTxlwZ3X1bq87+P01CB0nBR/r6/rer+unS7Bhl0/XdP/Cd//+0u2U5bThvFL7O 40Xf//7pr9b/G/eL//19b712vr3Fr/fgiIR9/r/83/9fv6hV/rUwn/7YjxV/1Tx+9GMrILw117+6 q9ddrj1vo6YInkEP+6T136e+1voEQrSNFur9E5udxl/9td01iOGk3rSkMO+sQnpvVteKW6wzdbSt J9UXHN1tY1hA+GPfgwS4itjiKaWExFQlInxFIRTSxi7sUxTEVvrioxHD/sVtTUtNDUytU+1Y00O0 1TT3w0og3a4MFiIiS6EQYQ0IzoQgwQgwQiIxEMFMi1W4kx4iIiIm1ERJkZLoTKrEkYkNF0JtEJ4k 2WxTsSSZFEW4WZaQWpXJUZJ8IMERZJyNOSGC01UlRkryNZT5fITKkiEzuMvlOQTO0YQYVMnzs1yC xWc7BDsZXKojovggSnc8pQYCJwGEGdk4u/5BzsKEGUJT+dRAt2StBM6BAthObmdwIEGCxqf5BwTg 9CIj+EHm6qZUsg8hPbQU0VOvqq+CFKm80NJtZohE3+rfBPXngt6TaTbwRHv5/QbQSTd7ujdQIE3r m7O60g6To2UmwVqez5+azP8w1zQfPwnp6eqcinmnk94QTFU+cS309fow540KV3V+k1ThE4iOLfT2 QPNmv8dsrYYHb/0v+/xCTXxG2uOuaBiv9X/8e67/3TCHu9dVf/v/99BHEUbRz8wmkO+tfb916ffq +opb/6+82Hu/a/rxscYQJVvbSTHz3vzI99nLqm/Wz3axmERSzcr1jP/164+vUbFL+F2I7XRumgYt V7t8zBdtVtYaUfzw04jm53/xHbS+Gkwwt6zoox6MfGsR+rEU+8fEUUBhhgqsVgx9bGP+K9imKmgr EGFX/+znq08yLQ0NTHtKxU3WsPMe+0POfaHaDChCIj4u0854jOiIiIiDCaEGCmRBm2KBCHEREMpq qYaERETiFRUd2hEWnESCbQxOxVHdIyExNcoxEpURrO1ebyryUYiCIm1kras7VmW5ppkK1O1XMaYU KFkHKSoNscM1Bgg8hMhNOynRHSqZGsVeEyLRxhMvkL+W6wENAXJUKCp6N7BQoLhNByEOjUE72whH R/O1OT5vaYTXJSEUvn6tJhEx66TYIk8ESeCJPRv/PDmg0UvrX9PSd5na2k/WYcp89nujYgSaR3t0 4VwrhRdBQp3i402iMf1Tz/vqeK1wqed7yb1/QuKTaThE3j/4RdxCLuIRd6CC1sECSed05OGCcMfi 3/mkXC9quvoECv/3V8UFr/pf+IQXT1/2v/YIp6+v/V1/bbEMj6xb9//+Hp8PQR79Jv/eWfOj9n0h G/vP3r6vV/Yjq/ZzjMJ9bVgiOMxsERxl+ccZeCXHhg7W7617WGR0F4pR3i21V+vw8t1gltY533fT aShtLD+G9DaCk01bS3X3tiojn+6/xQWNe1Z/0ITYSTwY2I2KcGPBjwYpWuITG8U1jtL7XXOeH2K2 K/CipnOPwdpoQ2IbEHZzxGTCIXHaDCZ/jiwhpxGmhxfOTCaENCHDBEKQcNPTwQiIiIiIiIiMREXE TmaTRPO4qJNxc5N0hiuLiQxRU7mju41x3XnZhkFIlSCDO1hy3W2S6MIgiMIIMiMwjsURKUrDhphU yEwg8jWpCZCsJ2pGshMInDQZC6EGE7CdhE4adpgg0FByLWbmCnZqENQiLHcHZFwuSkRFjsqWp/On Z07hBsImO+i3a2vCDYX9JGHDncNJsIk/CSCDcOq1oN7qrq6TcJ8tUwqQdAiP6BEftJ5326NApoGD oGHThRRuyT6eeAfP1URj0nIqu39+npvHXW9b1+52IS1QgwxDD8Iu9DO+/EHJwxtmkXCzunq099// VyJAvptf/7XwmXCdO/1/v/j///2v///V/X/r9Pc3qvw+//IeFkblR+fv38aGqqtq6zoW/99fb1Gb +qk+YI6YIKNAiOMvtm7+1iCnQ1Hf9utQQwQptK679ev1H9fEahBYIF4b0PvbSpaJQFVbb7WaCrzf p7Wwv2GFYimI+I9diCiCmHKHNFwY/Y2KmTrhC7xTFYh3zpgzgohHYUGPsVTU57Q8x8JBUIuIef4t NY843Fprx/DWLUMIMIMIRBghEUFCEQ4iI0IiIiIiIzkRiIi5PuT+I3JurhsbNPJZmQWjITjtPk0E KmjtwhE8qbk2NVkaR2XiFkp0SUhBz6nyCDKvIJlREKzppkZHYpoMqUX1NcX0yWJNJU5brUCkHEoi 7gyIVkojDy+f8iDCCBBhKIYTQVqRdhM1BO8htM7V+mE7OgVbRvaGiyqXz0jO4QyHemw0/TpVnQc7 SVBSUJNJGtv3+lSfc96dJXScLVL03kh/1O7Kc+9Gfv/PAhT2Kn8KeBST9TvRu9hOp4+ub0d/N1Hj 1zdc9b/mKjd39ww96r9/2usJbVNmcXC0ldCRPMBG53X+//27en90Mfv9aF/9kWi/u0lj6WjiEILo 3//+moYof/r1uh+v+ozCVf/r6/+xH+b31QRz/teeCn/TfJRf/W7+v7/s+pywRv9s+gUuN0lCLuCF a086K9/hBf70OLx9m4Z/k4YjwQqI39drjsFUPEct1RJqhUdHQb8Vhmgp/sRxGFI6I9oR2vtKh3p0 FrvSOgdjXjc+mbqwhHTS1soc0FFsK4/rcRF7Fe0vVs6E1gzlp0WI4UVNTxbWzn8GZTXBY0I9PJDD nU51JDlD2c9ocWp/jQiLWItM5MKmp/qLiJahWrORaEWtxEcRERE4hERERERERERGayh4jERERESB 5XM0ZXtC0dk3LQURLso1MlStTu47WmOEDlkKckiIrnEazTKDuRBOSnILkJkL4ZAtBlVzt9SFYQZB wTTCJjuW6xmGQkdziDgpeTiRafeQQDka8lDCZ0rIv8iJ7DJYwmE0iU9pnVpot2dmoWEfqaZqEO3E NQq/wQOgQeSHf9J73czhpynD7TQW6Nj7QTek+px4SCQVAgTd5/CzD8xc5/d1PGrrF0bohh1O7RoF fXCRn083av7c7nHzjmfOOeNeul9vd9vX/+4SoQwyP0v12r9X/76X9tX1f1siUXCiEE9f0Lrv//oF cfT7XT39di3r6dd/bpNvfXCCV/a/1/6tbcETf61m/+v+vrev7/b+lQaRvhBH9+vyfSwQqPBDBCiX OzkRcYeOr1IoGLWPtVtcdP/7/bqOoSWI4jj+gtUakkhSW0sRtX0FbyaB20rS9/a9qxFPx3dYM6ks GcKMDFWwVuuDOoFNbFQmO0uxux8U0L851OdSQ4Lxa6gpu1i1MftCwmptjYUWENCwhDQYQzoi4jOV RERmTJmIiIiIi4lMgqlomM7gZrxOx8haITOxLOxLJs6IsjmSnJ8ZN7ZLEVrJQzEgyQRGEEwgztzI +R0pCZD1KGXRHIg8heURHRHakJkry+SBQU7MRfOudp8hWoQaIxUcmwSCDKvQZHiOyLhPCLx+i8do RH2oQjuwhEeE7Q1tT+duJnY4Sv8ztYi13oNzoKOY50BNo0ZY67WWOvljrV0W9XfCWtM7uT93SDuw RHpnwrSfTe1es3sJnx9q0z4/hM+PnfbU/UCLr+SH8/aVww69Xz5boH3r/qvvFJzSMBIIISoirk4y OMiebKhScnDCXit0t3oz3InGAij+DBjJscF1c0Bfd91/io+9/vUcawhSYQ/X3r7pvrbtfaw//Xxt ////rkY/7Zh/M/5nNBQ/1360O/qfr2OuY9+cj//aznznwZHOojvGf5DFI/dUUY56vxF7qrXfX8d7 OWoIEc9PaX/kUCWraXfcRq2q8uBtr39rq3atpNqs3X/420ggvra6sMKKsUwYL/UijtnPin64r62K adiKYqIp34/VjQ77FPsVBNMVJDCSc6EItD7tDjTQ9NNVi0PN1hLFoMIRYU+xQuriIiLiIiIiIiIi Is8FQUPiIiIiVLEmzrEQ8tBLkaYIGVRGVI7IjtTRJRBGWUDRFjPZIzys4jCKDtBkVRHwma8vksy+ VGQdZGkQmEGVLKfL6hSVxfOxKluZxri+QvNbL5rZfIXkqcPuJI4iHto3UIoLYTs1CHQJBpnURMlA UJ2pfP8sc46WztRvLdZCBbIvWuvrtN21BBpJuYerq6q3qjY9X/hCK/1V/VtAiP3oER90nn8Kfws3 dPTP1Ai/zv0bs2SIejdp5+zv6/M0gQK/dG5Tv3ed/W/X14QWEtb7H69Luh3DDLo+KCKdUP7pd37J j6W/0P///kTDC/4hBCEF9elf3r4txaEf7t+/6H39b//9L1/9I4kji2r+31rfvCLfMO78V9WI4Ijr qvufX4KR0C/37Oi/2oQSYQSf9pa21t1TZzU6YQT0UecrXvp5wu+diAxtfVCK9X0l/VuglQSqIpvb SdVu1QzoFQhP3G2kSgK3qDP/M1aq1Q40moio19iKhlyQ47imKiKiK0FCX80DFMRXxsRQM7XUtjBn UJih6Yq7mog1QaDU/5gacef9zK0+rXm6GFhhBhODCBgmdCnQmhKfBhCIiI0IjMiIiLM8RLXElERE REREREShCIiNGaGWgJJnZIZbiqETtWpbpaOzAh2sPSKMnyV5hEGkyDRUZCZDis5CIhedIIGVRGuL 5UaZWc7nEqi+SzL8EDOumdYrOg8xk+UZPFBrGE0zo0GzjyH2U+FNaCyDlBQ5Q81tPz2mSzI6CrZq EkHKJ2OEXCd1U/o3vPRKREZ3XfqgtXixe8EMIVYQjCH9o1sIRrhWwqravRrbqk/qkH1+kaBCns95 33MOZ5QvtJWXB4pJfpOkgQK83ZrM7Smyjved96b3q30Yc767fzauqHFfqteudzu0Zyowm7nc7udz uyKIuiPkdK3VWjOd3S3Q07zud2kP6/V7/vrfb44iv63+//3q7Xf390IiP/9/9f99frfXa7t1961/ Ru//qy6I7Xr+1f//9Y+n7+vv/d/9d8eqH/0Y7nOpz/yfzdelHxEYIf3v//f7Oit/1/DOb1/2cv76 ulxp/2vXa3EUhFP7S9W3T+2v3XevN1te+9ScMWvd8d6Teu1Ru83bbqNf37diK1mPBmB4+OKG2PY3 uritjYilihpjViOIqxTvNT7Ucd7W1NTOfQtfQ4tNDT409NDtTIhoXm60GrQ4iLQtI0FQUPxERaER JahapxEGEGEIiIgwQMIRERaEGCGIiRVC4iHyDyEQmvIRCIiIiIjTER09MlSJQiymik3VFnYllHv6 hBkDyJxAiO3ztEXzsnkbyDyF5CsEGVPIVy3NMmkYRtJl0R0X2SCjQYWH+5SBg6MjmmQYlGEZ6efy VZhpt5/OoQ6dkpCEX7QZKQhKRNxEM/HTiIhoPT9dfueGumqNb8IUv67+6NdV7DhgrBEemgPQIj0z lx/54Nep37m9F5/p/53/zd9GxfTc2UbuprM9gwSmu2IYdU9NPvuNPSWv0O17bejDnivd9D2kP7pD Qy3U8wEp3BiCp3Bh/jj/rf3X1p65EO+vrdv+v136a94MEt+v/67/V/cRX2h/frH//+35nKj+L1gk /kU85/+sfEbnt3WD/e+ls9k4YbOREww62crOccfr/I1hBRXEGv7tpNLoYM3O0nn/be/o3ycMVG1a REwXImGPdq9q6EFhY/XYrWY/rYykXvFMRvqdNQZ9nHplqFa1sULFCwmuScofq/jiM3X2ENYvCrmR 5u7Ux7OhDGmmkCEZ0d9QYIWhEQYQiGEQaERFxEQYIREYiNCP7iVXERERudmYxMxifGJvFSuMyJKT c6JShOxMwgwgwg8pWQmpqI1Z/KfL5UIjEYRLcv2mRfK1kHndMhedzyFZC+W5pmuL6aaou2i8aLxy DlTIYUkGknqF0wTs6MuwtwzUGJBCkocp507slIlkX8lK5bkvrZKQjIJKwRHRmoQdJ6eRjwuqSNbv X/014fYQjX11tO9663Q2rdNpNz+psU1qeBCrwqO+9HfdIz0CI+87g54P1mgztd9G77/7R3vPymsz v6enp8IJIaDa0rd/vXvVde4Nj2k7zud72VvMZHwih1QlLRtEdf79/8ad4/18QgsfarBiVX80DC/9 /Yul03fv0nER4TQin69f+v//6CPJ+s331X//19Lb//f6d6f69f8+v5sKja3tqEls5/r0ThhvWchv rH75F4EFr/+aBgZuuexm+RMMAhUEK9bTf6F20m0rSCXGdAsRtqv1r9Ut6xCbStX7qvQ9a9R1Hav8 MEoMEmDBKNOtipkWI/YjdWIqCYpih2M6dfWRfBmasAzBBqxQwYsUxTFc3Zk5qaadodoWmqdp/Fqf 4/WmEz/asGES7BgpzxaaEQYQiGCEGCEMFTCDCEGFiIjT3ERFxEREREREREREYify3DzsS5ZARKZE ZhHVmIlLMZUamojXkHlWs7oiF5KzOzGVTL8mxrkvEKjpkaiUKyFQKT5PE+Txpk8T5PBO7bWzUIaB hPPrP5oC6ZKRAmSpl2p/C2TRlzlulIKdAnno1CLko8FX/112trXRcNU/rWaHF6r6wQpX8JerhEb3 /96nfaTpOi8zwa8J/vns+OkXlJuZzvfQIFdqd3Wbq7yQ/t8ESHT/1//1dXCcabW298UnKWja4T09 Jd9J/vRnKikJE4wEb53vv6BWMccVGl/74q+79/hNDx/7b/1/XvpXrt6/tV/79Wt/6FR96/mF9IfX S/Tb+eCnaH/pAih5dAih8c58586HOd3pXvTnvV1TXoZ/2e7STj/fbpdv2exx1fwQ0IiKndl/vvX3 9tbVDb7qbs/7W+N16VG7arHV/MwX9n/601gx//9RFMUxWwwkx/7FVehFOvsRTQXx//xgzhZy2H2t rap2mmpusU00/tDU/7HacNC8WpyItDi14g4iIiIiS1CIuwgwQiIhghHnREREYYQuIiIuIiIjTRlU oiJ1ZLmU5HXJ8hUW+iETsmiCRHQWWj4IGEGg7I4QlAU7G8heQiIXqdnRS8imCDQjOzXJXEK5bmmT kVmNcXzumSxEdEeCDCJDsIm7RcOOjoy7yVCJkvZEwwdYu1Uvn86doNBKfWXz6zCP8tyX/W8IRzw4 IG4QNoINyf0YHT1OoQ6BPQv9d0XGfc6daene7nQcLhXwquk6TpOGHvU79GxJVzwa7O53fX/Cbz// /Vf9Z3/P+s3111hhvZypb0nRhzxR3O8oWNOluRP/ftXhkdK2/v/31IoD/lKDGP/f9gwxiusrTI4X Gv9tBkcKleumRwt//sRut6/640////vev699tv+u/rrYj69JCojiPrzcVH9GRs92CDX+tQSNpGBj xn/Z7v/sZ//erU/3Jww6z7pd4Ic6ND//axHHHGgSbtL8b/3XvTHQ+GbrVpaNzBm6DNzwv+MJfHI3 OP7wSqy6I719eO2P4qgvu4ZlIcGRz9+uDMn77G1rOjOfOdTUxaEUOPN0Wmsdxx63YUbXTvWpJahh Ds/xERERHxEWmEIYQhhCIjgwpIeIiIjexERE71RUIqFOdHEyviIiIz/iJ3XmSnXaiNjmQoiuKIwh E7JUQtSbmBCHf6kSEITInkVynRhFWkyTy+d3mEVGSjQs1mdoyWZfO7i6BBhA5XJUdzzucsMgqLo3 EpZf9d0vMI/4Ts1iSKM2dIuYTTNYuf3CDOsYZKfCdhbTTlcESZ2OITQKjDlDA0Irv39GGun64WDX i1cJ+Qvmjaa2k/ouGjW6eFqhZTh4V//8hF/oER+5sREGgQK8w5nzv5sV+k3U790CLrNSR33Cbpzt au8/JG7n8Q3P2d//7Zy0+vrdJ+k+q120nfIp9PSW/V4TN3urq331F7YwwZH9//9Yo0ZHCr+Thhfx BAvv+vob7+//1vVffrT/i6xjf/+/9xH/v71//cf9fr7VfX/rVd+YmTj/1/owM/2nnRf7OZLvr171 c9rH8eCFf7t663TwQ7Oa0Qmgn91v1V/EGbq96ROGLbVYpX6jm7trS9qoj9XTajqLJoFz/ELImFY0 vV+zl9b7EdkMLEU0sRp1zHxTqDMFiKYjY2Ksoc3JYUaC6j/+KHfHqY+RiEOGpuX1tD7TTVRcZuU4 TXOqBe/qIiIMIWpkgIQYIXEXoMIRBggwQYIGFxEZhyoiIj/vP8RaERERE7HxEYwhE7W8REaESoQm iIfybnxOzIQi8RDIgyIMjDEipqU+XzWR27MYWyNZ25EtIlBlZRC8hfZXKeVyrO9YvlLIjtSEyEyF YUFCdrYTJwXC6ZKYu+ycF4MlxCURdppp3edIw5GuK6l0ZpdCKVSVCzFlqoIjozU7ozSLd6do0PTp 0rVU0a2jRnh/2nD/aa8se+FqdBzgiegieobxThB2eDXndPQep3dWzwa5GNG61O7p0g3ub/6nfPYP 16O+2FNndEY+z2dI5//Wv9jTpXrfurjTYYdOl63Wt+RRG0R0CKeRNm0tJYgwyvWZcf39xps0i4Un DE7p2O07LkuR2RxxxUUrrevul/q8iUjpPT91WRNkcKE0IikI/w2EPfr/+l+q8RxH/9fXrrv+v/f/ fX3MP/SkOPsR//zZmwq37c4TyFHzDk4z8VGZyuc+FXdbrfem69fOiCLzZ7vSdbqIxn+M/8o48iqB KZHvr409C//QanRofG6Hxu6fvW1jStJtUIXGx902v6r7SqEC+DN2+rCX622ufxH//+mGFhgkxFMV SbFMMJQvoKwwsVMf/10sQq77EbH/vFR2R97I6GDGSGEgsUxTWNNRVc/xeKaaEcXHGoIfuwmENCIt cYxd+GEGgYQMIRDCpoREGCDCEREYQxEGEGEIzOU96dhMER0IiIiIiSRVEwhhCIiInkIm0plUqpiS QZTkRhBA0SKC4PtbKEFQVUdTJFhNOXB1IoLkJkIiF4JmvErlalclR2ahTt4vkJEHETysojovnXMX fd9kpzDO3dgnefQTQfZKNMixhI1iWSoQJ2eztRFzJTF2drCCe0lzr/l8/koCqmVGQcQcS8QfTppr +qc0NGt0+6aS4VGt0uqpnamElcFCTbptX/utAiPfv1dTvQIj9o779IPT1fo0CEjd5s7dvU7up3oj HVJ0d7+69I3apyfyfyfon1J+1ekut/dt61bX76r0mqf/eu53V53O+GR0R2RD/fJww/u3/+/e61X9 ksa+vuvde/7WJoC+Pt/+lrvXbiP/9b8f/9ftX7/q//0Pq/+qzf7+YUf/u/3+Ff+sx8R/8ccVFRus ewb++qV+rpAh/2e5kbOVpJrpcaX3/nA16k4Ypw6xS9d9pa96X1NjdW0rVYjj+Ntefsatfdf8+hY6 rUM/si4V1mPnO5zuc+c9imlKnsRsR7xTGxRKf61Qj3aSwux9tYYIEnGdf+oTXWv/+0OLTTTtQmua yrz9Hm7+Hxx/FIRsLFoect7vtbVYiGEGCEQwgYQ7QjQiIzoQiIiMWsREREREREREREREReLKmi06 kQWLwnZqoiVwJEWyEyEyDyEiSowipZ0ysohESmINmIlZmVZggwhlPl8irRJSOFHaiUVwTO0RdEGi pxC8lTI8Shpmtl+Q4ZDhkOQQ4ZDljs6xdmsRT6OsXZrEOishKRp7aDOz4QaDRY6C/ZKApKAnWzpB BkrEJUIr7rw7hw7XVNdVTCp2dQkHWjR5oo14QrdTPSWp6W7sKkvV7c03PQOemabno0CI/dTvRee2 p3y7+kRB06Tek3TeZpAgV6pubM2bujv4SM+bKJD0Z906O/oPvt0+3W9Lwhb0u0E1vO5UV736dXsL V/fvT71366Gd71v/42Li4uLr/V/Wr4vrthFp/5SmRwq37Hr/i2/b//9dv////r/+PpX/T/rzCren 0uvFcW8f/+/+v/k/RPqT6mmpPq3rfTZ7X6s9k4Pvgyej37an/+s4S/frV9Y9s5ft9WvrrpaVpYS+ mPQ5usamgL7+Q1traWP2tpberdEoCkoCUbt9UpFAx/GrFMRUVHFRUUxHQXq6XlDlhNrFMVEfsMJM cMj5HoioYJJJd2I3VeNimqqFCqFQ8zlD+h5rKgoeLvFQTSjsU1EbTFTBRmrDWwhqZEWmEGEGFOEO EODOEOsAhhCIiMIRaaEMKbfmPEMIZh4MEDCFqIsIREREXERERERGmmho/iIxEoyDiDiXiDhESvpk 8Inc6VwpmQNHZMUguTCX9IlGVVF8jEYREIvlQipIp8wjuCIjMIqWQtFQio4yFJSCoqSO1vggztCN cXyUtMqMhNMIHYUFBIFBc+iEwWwmmCdnTTJSECppp2SoS7NYvZ0z0CkXUMlCs7Uu6Ju01vynFVG5 p4KCgmChAiPKmdAi6urrqui4YXXwrL/+FT196BBvV6bCuk2jY8ERvBEcQRHEIlEEq/ggV0d9zv/m zBAm8J532i8+i7sP9wRHHe7XpPoER/p0SHS09OoSFRCBEfEECI+IRN4t0jDnelf+l+6TSXra7wn+ EHDDaIojNL4RN4v1vfbKUKCKHVf873J4uF/zQFwidsIu6BaBaC3ut9bXf7/HW6evxIoGDSLhcQYY plwvoL/+voR//7a//1X//xX/1X/vv9X/6/1////rmH//+8/f+ZGDWD44zCjMIL97Xet9E4Ys97W6 TerZ7mRGf7Z7BI2hn+CHGYyJhgEKOwQMb6KLftfxV47WudxZfncZjneY533O9Zu233av0+tEVDDe tr9If+hhAk/qePXWP7VW0u9+20tcMeGPDHgx4MffdMRURURQZcFFGIqGsR9euF/BnLYYwZgQoc21 kzTn+xFRWx6zuUOd8bvg+D4NYfDtYxtO04zUtBig1NkcXmcp8Y/h8afMeLQYQYQ0L4iDQYQiIOIO INiDiDYiGEGEDBAwmqDQsEGChBxFoQ8w8aEHaeoiIYQiIiL/0IiIiIiIiNFGLiIxK4WxJzEnMTQx JzEyGIRO1Ihluloriea2v+dmRqQpEVyNZhEpyEypmdkIpzO1nL4QZU0ZFGX5XC8EGaskuVPOy4YQ cKCgoUEdi0XYTKAwSp3mEfwqan0p9IMhcdNNBhdF20yWovhbqnIILGcMlPaSLd19apot2q+uvp6a NElQRXRoatwg2SkISkQK/RrcPv5ooJvMHmGbWYPMGYWYZtVO+EHZ4NdAiPt/oECv76QbV9IOgRda uksEXX6dmgz6R4q7SNjp/Mfp9GLpP06S1saevX67erqudzv7rq+udyoozlRr+uk7f/jT/te0+17X tf+6V//6fe/37/3r9rd0vp33um/9//6///f6/19fYj+o0P/+uuv33+/r9GP/9V/7CDCw0wWI4jiP Xerp9X2tVuvsEO/fzaBFOv932v/68VghV7aURxH/Gtq2v0Gbt6zdm66/pa3rERf932q+1W6a1qwk SEhyTmHzDmHO+Ycocpyh83FPmo2lNAxFMRu7EVV1cMJbFAzKBTEV8bxTEV4jYYUWlJRsYQudGhF6 ERDVC1TTC1aa9rp6Yp92mpz3aHa+xQ1hhSHHiIiIiIiIsx4NAwQiIiIhghDCoGEIiIaEYox4YIRG cjTiIiIjERERUyPnaxk+Vx0R0RCMMlA5bmkW954yRnDJEcMoZsyQzZnamIazKorKkaGSjK1oQYQw gyF5C1K5Kjs1CEJnc4g47W8J4TtO1tbIvF2qDJWJDQZUXn8g7dJF4yULJSrlcESdKdmvmoQ7VBMH oHoGqB4QPpowQ0MLDRomsRk/+dQmdiXOCBOnafvnCdwoSguE8LhPVVO70g82Z3DoNqG/0v1b/vvp fP2Yc78w/MNcw7zDXMP92zlVpNEGxDDXRnKiwffO53lCzsR7Zyp96f9l0R3O53/jW33////aXkY4 ryMscP9Lkshb/bQZHC3x+//4j9v//YXtPte0+12vD/hvkXS/7ax/15dKlr+v5GOF+q///r9f/XWw 0YG6g7OT2CCfMe3hI2l+xn/Ec4I8iYYBCoIaMD+CHZy/u/ULEcRxGxpe2rngXGIVpd+ECWfv18w/ tKuk5/u9hR98RxHfdKSe2c7CRJ3BRG8YS99j/J+GXRHmDBIGYKM1YZQ5tzDSpjBnB3Y5G+THKHMP m4p81M50OKFsUMzlfhKNIdb4/xGxXUXjGtn+LCnIwQi1QtNC7jQMKELXMeDCljxEQwhGph4M+xr0 WOxERERERERGboiItNDRPiNH8RiwjNFvSIPINkQZEGIiIiZJWIkoKIggYIiVAwgwmVREJkLRCZCk dYjSKjMijMI65G0gwg5XUsvndES+VKOkVcXzsmjcVEgwmixyh2i3YRcBpmgYOsXZ1CGoQ6Rc7kEI K94VPP5000yBSLtkVMwZFmYKumQ4JkrEo/roNPRvze0EIbQQNwgb1VNfzpWw7fTf/nhkuEhBvTuy yq1C33a+Furem0nSdJ1fZ4Nep3zXCLzSBEe+W5b/0Z1/uQpK5vSV2p4cJGiNAiPPwkeKNm+d7kK6 R46vXX3XjT0l4eE/T7wg7fa0vf2g6vnc760Ek9U2drC1WVvMD/6F/9P80i4WvvuvsjbLhUr+2rxX 3//NAx3bf19ft9//oH/Tiv+////9//rr/oXv/1v6Xqo/7///9Lh9v5hzj/9D//+f/69f4aRu3/q5 7dLJww9YIcyO+oIbxH/mMjoIodWv636xSFuPs5L6tRWPxxxxxj26UedAsca1/X3ao3Uh/4iItult Ugfar9LGz/jSFwuv33XBpNBUErSQMwQGFEGdOtiKdwZezBj9j4wkxSjYin2l/Y2t3mPnOpz5z5zx 2KGpgZ/j7FY7XtCI8500rraFxan+OGEIjQiLi0IiLQaERcRBgnEGCERERERGGEIiIiIiIiIiZKOJ ZpNHavWWaC5C87SES3MJVKTLo1MxZ0y305XJc7A8lsXyoyDzsSjpFdEdMwzWIRcKTRl2mE7JwwwY WHuQuIqYSz/n+VwoQ7CMJrlPBTp2RNvR/pNNJLTRra/DTfvVL/rVrYQ15FWOvU70bM2anek877ng 10Zw0Z10/PAhX30XekZ6BEfdLedw+3MlhdLpPtkFdJXX+NNiDDperJQtaffwh6uvnc8N9QyKKGe+ Ey4Tq8Rf/7S3V37/IkGNq+//X//5mfw11+v/r//Xr6us3xof///VXB+f6GM3dds5//dXpanYSBBb 98x7fr7Pcf6/ghWI/MPriljJQFFildX9tJiFeraT6Ec/5/42gsdbfX9H/3VNLWKiNioJiKY7//9b HxgzFbr8cam7M5Q4IXaYXTTCaamPHHz9FphDTuNCIiItCIiQVAwVAwQiIiI6ERERERERiWYRybrK LctRLMvkUiKZLEYRVqysoqEdgWXynMl8vk37L8rgmd1Rqi+QuIOBAzsDRHRHiEzITSkJhO6MI/mo Q6RdhOwsMhQhqEC2EwudrTC3z6O3ETslIQ6emCEZqETzUIk+uF01zUJDChJXRra2dqYRX9hUnXdG yqXaUEX/+bNTu0d7aU7g5sU2UCLr3QIE3IUkkCLr/PyQIuubv02QWn+jDnfujDnil/6Q+/6O53Yg 2k6TkKqu6br0HO530n71Gk+h/7xrbfrvW////3ehoU9f//2/u3//////3vURuvr/50Sttv9fr/+1 WN9+9f7Pr8yAwf/rez26W+v3YIKznnqtr0jFtdf/1s59ecicMatWF/7b29QZumgLxr9XfEIi4Yih vVte9R/tUqN+LtVImC7ChpCRMF7vBmCYqIqvaSYitioJVYikIpiKdjYjvqxFYM6gVtMbjtPzTKHj u1wpkObrSbXTX5vQYU5HDU5EWhDCBhCMIREMEI7QiIs6IMEIjERERERERERERpoTsXUmxqiEyK5k FYjdM1CyNTPtIU5QSVxbIRGsiGZ2gyXy+RUzIIYU1EQQyWmS0jtK5XUswgoVEHLmThhDhmQtk8Q2 XemmpGpBhbsjWRaMGRdmDCDOsYZFowQLYTCaZ2p9wqYVFuUOFNzOkmgRHiLs9cP9POoiNbnQVVNI hyNFXRkFVU01TmvaoYRN4RraNbRcNGtq9cESfCEetNBNoNudBwzOD+p360/aUGeJJuCLrdNUCBCe LU9tJukCL6M5cMEvem4TdO/QIFcJVZ7oEFUz6dGjXu31S3ozlPW9Z3O8MQqdK/0Zyo01dfV1XTTh FxGm91db71eCJxFjEIsvrW6YfZdF8KINx9ZoGNXrjXwYX68VS67pLr/f6T+v+/XXr6//b4iNf362 //bHzC6/2/+vr6/tdTC/6/796MWlQST/ejHu3IUedMJTncaSMjt91Of/aV7859/j37fr2PGY7pPV 1tI7BAx64zCpMGDj7+2OdGIL2v79tff29b1729tW1XWKXWZ3utN1dNrW1WeGnn/boKwwuw2vhfhf eKj344jYivePSYoKwwk6v0DGhGxscUdqfYisMcjHxTWhHvdQtoXHF2FJetpWkRhE0+1TFDT0Ie6p rtCDxyESBJi8GNCIiwgYWIsER1MeDBYsEIiGgwhEQ86EDKCwQMIYMIPMOUOUPmVDoQvQiDQjCaEl qERcXERi9CLjQiIiIiMRES1krlclRbKkJK4Ik13lqASRu9yuSZaNYJ0PtNP/W13/3z3BDaEY6Q9l OdsrB/xxG8ZaqVGVM+ybJOVyXK5TnjLRcEHhPlcLFVPRn6Ld8K6ND6DfCfovPTv9+TYhGwmEN/fv 6a//+2/mHO/ttqw4phxQ0L2z2w4pimK/GxQYQYX1DLa3c/xGLlslbLSW1GQrTgtU0RkXUw5CtI0K 5WijK5JWnR8q/+lv/EuP9FogMGXBiCxlcpDC9/Z0ZjybEYMHZz5j73vDB13t++y6C//3qIr7tCIj JjlNPxERYIY////////////////////////////////+QHRP8f////////////yA6JLx4AIAIJbU ZCtOC1TRCmVuZHN0cmVhbSAKZW5kb2JqCjIwIDAgb2JqCjUwODY0CmVuZG9iagoxOSAwIG9iago8 PCAvTGVuZ3RoIDIxIDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAgY20gIDEg ZyAvT2JqMTggRG8gUQplbmRzdHJlYW0KCmVuZG9iagoyMSAwIG9iago0MwplbmRvYmoKMjIgMCBv YmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0Nyb3BCb3ggWzAgMCA1 OTUgODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jlc291cmNlcyA8PAovUHJvY1NldCBb L1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmplY3QgPDwKL09iajIzIDIzIDAgUiAg ID4+Cj4+Ci9Db250ZW50cyBbIDI0IDAgUiAgXQo+PgplbmRvYmoKMjMgMCBvYmoKPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmoyMyAvV2lkdGggMjQ4MCAvSGVpZ2h0 IDM1MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9CaXRzUGVyQ29t cG9uZW50IDEgL0xlbmd0aCAyNSAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29kZVBh cm1zIDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCv///IDqT8f///////////IC 4NWVJR0vH///////////KYJVEtIq60FH//////////5NjCjLTKVGUwqKP////////+WdXxymwr1H ///y0gJbvH////yA6BqP//////////8gOgaj8gOgaj///kB0DUfkB0DUeQHQNR/kB0DUcgOgaj5A dA1HyA6BqPkB0DUfIDoGo+QHQNR8gOgaj//yA6BqPIDoGo/IDoGoyuSZHRbz4ISbe9NS+eqNR+5A botPXj7vyA3RemMvhR2sR2DI4wZFHlqqwYsUz/WDBfOHiPtlpCij0MRllpEr5XMoIPJOL5AZi6Ld yCacegntbldVRHRHSVNzWZ2jvctROMtIsUrhYY+nf8IMf+3r6JO8x3+u/o1GWkUK/a9frTjvbStX vr7QsbGLEfxYTCatS0ihREWKG1LISZaqwi0gpSuqBCuWBg7nkHCMJqdmoQ6hKLm2eC3WuE9Qg2jd myWoMMtItXxS0hoQQNlVd9vojHY7r/RqOwwW6hm6zlT2ITaxmgL/DCYr/i1P+Y+1LSKFEREWKG0W kVqWVKQMtpGhXVUZ5XC4vkZl8EDKjEtIEUEHa2C6Z17Gnq/aNdfPbqCL+gQK+3uWkWcyWlt2l3S9 O+pfPo7E+OG3//X+tO/f9fv//4bHdfrqThj87LsjyRaRQrbsWt9N1V+hGN2mKYjjOuxFTD4h2mmt 8ny0ilREQYIQzc3sYv3UsouqaEZZCTIjIbMdkJkXxGWQt1OjQYQj5Dsgg7aLlV7/LHXDLJgYH8KC L7CZ8aszlu1Ju4/elirnTBFPSDvNCX/9WZgvTe1PzRrfr//8UunLUQoIcfdTI/fe2OqV1rta9eDO rSxWrYSG6f400LsU2upaiFEQYIWExVpDEaY5XM0LCldZRH0yuSZCIp8vlSyDwwi1NVCEZXCxmvTC 2QcahDqII1BQhq51CKpZKsv0b1pIER/SRsotyh4TsshRmFxRhzxnc76b53O9JqELpOnfr/b1v28c UCL+vc+vv/6/frtAiP5aRQsGCf/+1/2e7Peul2NDtuv27X+OP6r8mOUPePY4iuP7a/fCENC700LS LHKfMOYe9relEQwhEGCDQiGoQtRFP8RERENRGWkUKVzNCwhplckzozEQmDCldVC+5qEIVEHiWkWL /a+WQuhzd4Wi7vlkI0yb2jCOyf2yuVIj5f94QdfcJ3JOW0lkdCI/xInFwpnFwvrxD6///aO/ZEdl pCildZQLMja2e2kb7z/69ufLjK6qFfbSYx8f/9W7wvildfLJMMf1+ZczhqZynjirXr7xEYQhxEGc 3p6bXLSE1K6liOxHaQjUWmPlcyzCDCYRaRWrIddSaZCs6RhkKjt4viI7Sf1JR62Td/PRwRf/QIj2 6vn/tpd9U/o7/ybzzsTy0ihVf8jbI4X/++8mxpF/O0gg/+q//63/tbrdbU/9dS6C/39OjDnfGntR +KwhFb8bj1uWkUKV1kbEV7habVJdfsdUOwqBn3QRz/Jslg/8QYIRHYX9tuWkLqIneifZNwn1GIiD jUVLICZJowsWi0ilVPoJ2QmdEfjrmIhI7nlcuhEdKtnUS9UzoFOzUImZAp70CI+6q+gRHqVkEkJB lkFHfr0SdP1Tz9m7c0Sb009/872/X9uhmw7tINk3HERneP///x+t61pstItVf/sFI+Fdf+/udzv8 xDmzet9IRUVS2e+vrr+tOxpbeyQ6wmQwpSgx/623v/YpqMGhDXCW121//iLCFrGCn3BkWKGGEn+I y0ihRERERaYr1xiGE8VOfLLojsCxFoRll80yXjXkdEeIOBBndMrjSGhkPwhGahEzs17UyFzokP3V JGx+VwYRPP/5/okPp91RoZN6fH8Z3v/z/Scm4/nYui0hVf9dv/xptbOxko7PIFWzyf///d+Cacdp /2pSgx+/HCHCj/bSqGbrUx/8GcJ2OMGZcDG9KoVlOUOU5UFNIpKrZRHn+NBhOsRQIUIiIjERERDC pn6tRERmoybJXJsCVBr5dGedheYZCZBxri+a2XzpiI6tbU69nUQL/n8tyldXSgiPeq2Fv0zIVZfL aCLv0r7o3Z3vO97XWyb9j/6v6H/934Ij7k3NYIPEf1/+v3lukRtEfpJv+/4IoeFv9/QwmhHrdTu4 ZfWPQimzn6+u8w76r3u9BWkONKNJG+KR9b6X2trBnB2Nin9O9bS4iI8/wwg0O+xFMaUREREXfUtR CiwmFjJsSGI1CDO1mIVnTITOxvK4GhouJ2F/5/U959IMyLEW0BrTe/q99yLIXjSf//1g8//7I3GA jb29uV0j//Wt7avhby2i6vqCKH8zlPQ0KjCLkU8dqEIxoX01uGuwlC+fs3UaCnldI0OxQM4V1f3F yuXXltF1DCxxoX+Of4xERERRHIo+aSqrQyyKSLxBxB5CZri6KjO3MYIZ1CAih4VbNQiZXJmUzirn QIdRAuFRoYTGjdRspLO+5spNouGWVSzHoUhnc753O/3oaenCf39tdv/+m/tn1/v//66O+y1Drawz d//+2e/f9xocf/96ROGLXVL/2x8bEatpXV/n/P8aFphTHsUwwr6URGhDCDTTTTFXrERERDCYipZR JGIWpNlvO1SL5IRQgQzURJ5BoZNlKtbTTSTKcQhpM7/K40u6vvOENbC3k07TMiz+gRHuv3l3V98y FRCbz/18GXFZNzaK0EL/0pNxxC1EK173FR+//aN1RgmXwv1MO0ujH/5XqDFDNmhFN10T04T9nkCG FX0h1qt+2ucBdJCp0by1BigzbWxFV2ckI9kxzjgiOq7z246aEY1mPBxEQZ11fjs5xHmPaa8fK5ln aWGJZCVT/EOIiIz/+WQKyOgoiJOhEZjstQ6k2VWXwhGgxEswqQ10CI6gykzuelQIj9z7GyFB1K4F GQtF8db2fTKtu+tk3mq+wYKKS+rk3NVZaiF/jCLDM8rcYCUgRH9PG/oscFf6leoMV/f1hCDB1P3n sof/740rbHccXnR/ay1Dqxtm47CQJKv/+qjDCQ4ghevu9QQqPBCO+xFefYkCERaBmagsIgwVSbLM dkmYRS2bMlOIybKTTCpkXjFdoGd6ZXUO6q9ptTu2Qmx4QZkURfLaBrU8OCL/SBEepXlW1mdrY19L 6p0vHn+kHX/6//4InuI1aBEff/v/2P6vX4r6/9Qw9/+4VtNYpW6DDhm7X+1xFOthSUYWPr+LCDQ7 FIQWwwt6xYQhhMFP+KYiojBCIYTUsppiIMFLISanZKh5CsFO1MZXGL4KmmZKRfCJRRr0Yz3DJvRS yFmbWS7UECI+NBvW0aJNx1cEI8zi4VAtf9Jtev/lOEf2qp7vMjtT9g8IH9p//8R3ncZjCJzdqxH9 Pf/DHCB+g9r8cfBxFjZubpAmXQJRcQdroyGgeI4uIumyIOFLKtIRmPDM1BYmxJF87VcwiaCFTzsf MMWmq4VNMp2XycMIYjW1dG9rpIIpsVVHe8ER/p1uZyY+dNmS+k3rzvdqEG8/lmh5HyOiP//sp1X+ NPaoRGWohf/ohhdtf+PH/1gg//+ps29JvVE6BxvpWs7NBp7EcRUINca/i3aaEZqWKYhWclgwQaaE NPGsRERyzSAssqwc/4UmyVmRVhBmqEZ2oLk2VRDLSIhKibuyoi+WQPGFMptM6hECDbBhctxSL95s 0gRHlSdNbXhk3P0hqnm7tz2Dne4Xhgg//Q1iH/nfZkLuYd3X/7/9wYNIN7Pb/dqdEEv0vkU2Sk8m wIC8Utm5ukIXrfr33SjsLCb6fSCLvT0ZFr2KgojvUyFCe1uIjP8NU0xFJb1ERFoWoLsLEX2Kk2Sk drWStmsZCYiGFJsppTtUlNTL4TCYJlRncGNOwhrosdo3BoM6dhBlcDjIUXfW0EG0nRrrzRK4QRSb h/0bs73p96bd0m01P4IO10P/1e/06Nydbp///r/+NujW4Ibf/7//u+k+oZi9bWN1BD/gwtXZQ5oK 2qjjSbrtJK0rOaH8cdio5hynPFigZt0DUr1hiYcw9urU/w0GE0ItNOxVpD6xERERGgwp0J3hpRER GibJYYlkC2SeKwmSAwQeSoir2dGi3aWmaxDv4rgWI4Tczkx+jW1Jp5XLrMizq4wg/TaNlXTsyE+y bz9dNmcYCb0L/rk3iX/6rr+7uCH/+Ycw99/r/LUQt9qNC+lZyBD19Hc8RthLS+1jSBClCk21H/Y2 K8iYYwy3CwQoED+7TQ9z9DiDNyaBEeB38RGdERqhBnNk4IkTt1ERfYTXHJspoyB4iIjVBkeO0vCB kJk8RVFOjCGxITZJTOneXz+EwnZZAiyEH6LivWp1EWwpbRdZ+t8JvfXVAiPuWQMITaohrudi8YCK 7++jOVGvVPt9r/3//8/0a316mgoe/7EVSbf6jT3rGhfU0DDtv/v3tX+Gk0Gbn/evvYoa2KBnCfjY ioZu1L9odrpxaajuuIiIiwgYJXXiLP9COTZKRXVImiEVk2JEmdrGQkSoyVhE2dGEM7CuzUIU6LwT SgxGu4U6BEXDn3NlcnF2ZFEX6N/5sSUJ87IaphcmyjIV8foZ3O9W7OTDaRna2TbQKSoX+q7fxhhk f353ukFv7v79RpK/82UXnDLmdlgYs5/6z7IJx6/3eENDai/7rO5jdvX+m/gzg+xsdnJBcdeo9559 n6NNRwtpb0tz3ERERDBbWOxFE2qCxyyi+Mr4iLSSybJSMhMIQvxFnCjdpnazqRQMWd1qhHnakJMV qQQyPzK4FjdKpn2uVwYhZTWIV1Rhzvz/U/ZrM73UIMEGWprybFrLha22Me6f9G6ix2mPS/Vf3fxQ QefHGbn/MC37/6bV+/9OvWVgMOvV9bb8/2lf1Zz/4uMcbFMYgzLgY37qLC2mnXV+M/RGpusNKwss hJi0IjGxUmynna0EOiEMJhVPrTIPI1lPF8hM7mhH2jAyCIn86eFzoFTK4F3Wr1W10nzIVzFt2z3N ZndvvO+5urqEyba5We/HTu++u7/8ER5T1nYn0KX+1/8WytxcKV6s2a1Tv/TnCfQ1V//TCH/v+bv/ ghXpK1P15Y9fbyJMuEOy4Y12e7Xn7UedAorjCP/Xa6rd42KHcGZQKhP3saoVU3WZzwUPiO0O7SNu vW6pjXQi+foiIiI7Cqbv3xERH335NiQzIohaHEZXVBAmdqUQPCDIyL5CZCIRhBouHR/OoRMLmoQ1 pM7+K4Gs3un9Z8raYQrUyLImyfoIPTd6N6Vud7o3JcrgxMmxzkgo2xMppLfa7+Nf+M7nfSv5KPv/ w1/X9asrYLozlRVhIzvf3T6G//v2/S5kBMuFS377DNlaXDN9q+lZzf50fv//OxGR0R4jlYptZ/xb dX8X/v+0jd2vqIjhgmK9Y2I0uPW28d7H1kKPi0Ls/2mFNzFod7rXUEOdGIiIiIg0IsY7aVXxYTTF Az7GvLIFxF8Ra3qVzNHaVneQQZUeRLIwi0o3EaZ2pVkzaaLHdqXz+dJNBnY3GRZkLzItQjf6TQQb 6100a+ZCfkpWnXep47171O7p37XMhUITeedk+VwsMf/WaRgT/3Vtfu1BFDwRCNJLuv/9b9L6ztPF wu9c/om44QIPMdAgVl0F//nc72I7+9f91FKae9xEVH2oqNu6SuoaRv66TzueHT/ZMdNBW0vDN2NK 0h8EKBD/1b7QcWuNrd2titUqhkdF7/WItCGgwhaHHaHBlhRpC4j/eoiIiIYIWqkh93sm+IvORdjY qV1lFf0ShCIjQYKmZGsFL9lJkayFo7SMRrreXz+p7OoRMhxc0GZAmQvLKsK7q6/3+oRbsyFhCVim RZk3hF0F6oEX/99G7VTu6DphTIU8mwTCEfO1NlwlL/t0kJKV+9WjckXdbJtotBHZPP/7631vclbQ /1ehod07n2NB3ppG7vxGh//v9fvp+x3/DrZyFG7pett11skObZc9t/qxas35ucfcaV057z3a/Gk3 8eKf/raTKVxoXGCFWqLHCtvtNBhDi6N0aGkOloEKhDvxEREREZIcoc47n/N0GY2GdtjzkXenwZgo M3NvJslIREREajd5XMpM7/IVmoirRUIhE+I87VAmSkRBppnRWQcd/GQvmESwhK13XVGvnURPzscR O0xqjetG7Tbr3hILo1ssoJSuFgviVuNiUO5qRHSow547845h87+nLIlxd0f6XYXXPsEI99rM4uF2 nXv9P7Oi9TOU+33+21VaW263Sup3d9bhm4aF896jP/8EKFG7//fW7/0P47SXf/v/16X77X/sU68Y Mxfvq2qTa68cWmf48/3FxaoX44jtK61iIiIgwQhhOIhphBjYwlP+IiINMJr+V1lna0xEd+mEGdmu VnIPO6IRGEW7md5/zp524hb5kLjfptIPrraqfSdmRWqTpXb+6NipNrMhSCDJsoRKy97vkTRyX0nu qdVTT9faoMIb+L621O7JtqIjR+Y/jr1e+ut1Sbuu6qM/ycHs8o71XRnKjT4pYaU/9eLV666X87Gq hsV+4M2/zdtWNfb+H2hx+Zyh1WxWlbffDzkRERaEX2mlf3UNxE7WMREMEIftYYSB5NlQIIixTFDK 5JpHf52IyBmS6JhMIMKp6Rt+fmTSLtS6M0EwmR41CnbsviP/9Ok00XDV01zItyuBq7uf96nd79Og RH9FjlPWzIVEK6iCZNtGYiKe+P/f3StLuELU73UIV6lCOxTwwl//f71uo/ow54rTuX0/Gjb/rWxH /q6/XozlRq/fq4Ibqrut9WeT/90v6+ubnn1UdBm7aT/YT9fe9tX/Oy4Y1oWDPuiV+wsRocaV37f7 Eaxa8enYpqRR7FO6T+6uznxm6IiIMIGEypoNVHx2kDP/e00IiIi0LTFe2sRK6SEWh9otIpUrrEVz 5CkSsyWBDUy3FEIiI8rwImEzUj+kEGd0jIWNPrzQ09GBluzscInDMlNE2RlC0jddJvvoOqNDhmRS EiyFfoSWLp93PdWjdSbJYa0SsXeSsF1/jV8acMNG/J/C/32v/8NkexbtFx7DOcyPk4OjA6v5hIdA wbUIeh/a/dWc7WwROLYNj9aVhhIMtyhE92pSgXelImN7OS5aghaZ+i7FNChsUsawsyVhgK2exiIi GE9hhM6EhwvCL4wuOIzchEZnKHKHMPp50MJVyyD4i0Ii0Ii1HNmVzLO1TO7aBk0QiN0+1P6uQWs+ jsbjv+dERvrCByUBFXJn5XA8RMjqr+bWl/d6DlcLBe3wg+dzve/8spJXptar9tujsZFwm+8Hncw5 VtCtr/Q/8r1Bgt+zlnZg+Iut/+tI3ddNVBh1WbnEf8zlPHsEKRkey3CRcKyK0iR+v48W/r9r1i0L Ux4u1TWDMur7TVT9CJxiIiGEIi1Q4iO52rG8RF/QXJsS4jwXK5nhBnankmZUoX6oPPoJkJk4YNSM MhMrlcbMR6NfTRbs6d4TTIf3DIX+m/oP88Gv93zD8yFIuzsSiuW5kIUrqSI8RxVe3rVxp4U7veFT 6pnaj1WEI/b1bfW9f/vand756U9ZY5Mcof8Guv79PWvkTDFb/79oRDuoQ3wQ9f0139f96+qdpM+b pJ6Y0ghTjSMjpf3tvfY97CyTlDgoa0rVr8aQIoeYSx2R0Fi0wqdijriLFNKGZdUavusRGqEVEREM Kg0ItMQq64U0FD1iIi0LjgzrqqFubnK62hEd6aeCDOwvOyMqiNWRRE2NcREap5hGakOUMvqQIU1M jxCZBx28X1GjW9NOGt0Xj2FVzUIahQuFIXnc47G1pv9mct2gRH/9EY9dQq4KSsU7HCHahWdjcVwU 6vtOkHet+tG9TvtEnzjmHzvsIk8LrZ2oCIMlkXzsU/nY49Uq//b8Ut53urT+4ImOhRhzukbt+i3Y WztIJ8EDiPb/2IYV//6W0vQTdbdDTo3YT+ErqCI8BhvX/js8r1+7bf9f/+hVtHe845h+0piIZu3X bqDMOYfBpv1be/t6tr9+vT/7T2KaGthhRYisW44j/9b0kCI4y//ZyBCrPr/1tu0IuxTTVIkPaeK4 2I8N9t1H2Ftf/4iGEGEIsqaDCFoWEwnBjeNQZtjY3S9X+IiIiIiDi0z9rhqxpesshbmT7iIvP9im K2Klckzu8y/U7mj2SsQ7mhERDCaHqf8xn87UxGGQVkc4OwkUtEfLoJmQkIVVHeIRHrqqwzpEPCH6 LHKHBIRFJqCBnYn/90XedwcMFqE9CMw9G9kpCqdmBTtJF8tyjOxNW/a4TVBtipupW59Uz5puka2F Wy3UAunftfEQ2DBNN/Fjt7z8zpHOm5sq9HasPQpiPU1w99K6++nuk6PHmgt9Vez2RfBBD9I2/9Y6 f9Drigm5u5uYZvxxCJYjCCt+633/3/Tvf/4QQio3P91GkGmtXPf/i9px5nKfBQgwo2GEslAURbSj 3/4iMIR2dIEscx8KNNjCVqsREZoKHhhNPPtAU0FOmNtI7Vh5NlNCIiIiIi7CYqCldY0GdpSIUyC5 bkMRaZ2m9ndER0XpF2cxSy+gzWi6MZQ5HofdZUhMGI8IRwbrosdhCP1PaaJjshednR2BIwukQU9A iP2gg/Uz+9BH4lHaYTs7G8m6F0Zyogktb1c3apt+oXvhc7UdlcERiKlJ67bQImTI4X9Xr9bopWcW rffO/3CaDzsmE9L9f/j77emEP/K3m8EU6Xv63XdvgwYz//fvGkPX+joJaEdb+0jPWf13/+9bS71G f714IPv/1qyJRcKo/jIuF1Yim1OgVsLN27tSKBgIl4Yz/vSVff34tQQ9RUJiqt9tJqCBvV/CH9c/ eIzbSwgwpwgQtDTFAz7p4jqNR3s5xERJhCLWLtAzrkiXWLllFoTGIiDBYaUdZXC87ri6JYRkKhCD 8p0d3iIi0z95jPpbTOzVH4lGYjVmGkThgKER7NWZFYhBY1wiPVMLaLh3qndoyeCrDTCDsrGdq8m8 1353vCffQIjyoER954LeCJPRrcGje1gyW+p9HY3X6/1b+qdqrz/UJwr03M7ptGxsp2t0mdqxCuCI 3pnZWunSX1/+krxirYRdxXEMNX7EMN3ugoTCDgzsbExHf////v+7/ThhmF783a2GErvragh691zg 6w18miWv4/voaRnc8ByQ+DNz+m6SikmNLepxxmE6SYSvvMIIt+sf04h0Z0/2I2Mmm6dLn1aqDHax BRukmaDDkaB1zNf3St2naa2FTSxbFYdioXYXS+bNhfSIvBK2+IiGCxERVoQdqFMehHBWDNsbTxx7 EL+Is/Rcaafap39pYT/ERERnREaEZ/hpUC45XMs7OipI7nmUxRERERoWpXJPtMmgQ7HZHiEzUyPB MojvQhGt+Elc1CK6L50YR/TK6uL5UZC0VzXJuOv/NdAiP4SXpvT0a2nahM7G8EGW4pX3WnD13JD5 33T/dOk7kpEOyYiZXCovBB98pQLkTDG37ozp0t/6pbQIuvVUbIT0WO5CtIyS+x0v02/Ve/3q8nyO ZH1ncqKMOd9N7oIPDghSMRnQu9d/99iOvXQiNbut/Rn9Nzc++udmoR+n9vqN212uWOSH+//139A3 Bm3dXtKNfWNVDN20r+EId/9v9f9+LjzDn3grY2KZxynKcofVsNXVL/7bW13r/0IwhDCGEGFQiIcW mKYj143um0rrtaWIiIiIhgmhcWqjjYtW0hqWjUxEREMIMJioo7AxyutIwiuamgxFhBpqE7O0qTJT m4qIi+ESHDITOzXMiREKR3yMQiML6NDtOlPcEHNQRT6UlDTKjBDOwbzvvSb0CI99pBtdTIVCbZ1C IJM7MGciuCKu9U9U/1Wjcu1rWfYEZ3WmQr/nYIGP/NIuEb1bxbqbtPN3PqnhN57U9f19fVW91/of SG01sx/799Wcj7pbU3UPp4/+PfV/v30qdrGkPrfZyW/eE/+3u+I32wk6dc/2wlHN2zna2cp9gQjf +1hodimqf9jSqzICBdtKPXVDQqIsIRERdhTdetilhl0R5nHKwofaXxERcRmRam7EdCIdip/o3OWS IRERFRFr65XM1kKRC0SgbKmjIzxcWqZ2axcyFxS2EiVoj6ZDjWC4QZUZ25GQIiqIjEIiI9VJUImk EI890i+emZCrtQQZK+7U7tZ3EJfmct8Ju0aPZKhEGp9E3W8lbqu6MOeKtT/fahB96punVGu6ZNy0 MJnYnyuFMuEr6/rG8e1zTMBFetG7TfqjOzsm0H1/7bpza29X9Pr7oVe+aCx0k262FNzbS9/7s8gh +/ozlD7//ehhBunqd2WkUqPxrfwwmFsjpPdUMcQ7qY+r9DSddLcftK8cRxHN20v7rbVs5uq9velx xoWpIcw9a2KZhyxyh7VxHDCSHaU3f6Mf5aRSoiwmUhM/oXahCIcaVitj7urXY0hiIiIiIjMeGFP9 pp21bS9ZZSVNBxEREWKQjaWV1jO6tMRaUWFs74KZFUS8amX4ZNkiMigU7AmLOiPXIc69luW4QM7s kwgxHzYn9cpzLcTECaaLxhMrkvrfq5322s0Ua2gm0XzK5SGDLSLrbTZkYi4Xf3Bhl9EnSQbp6eE2 oW+P16+hzvutW1tXmgsev+p+aZHQS/CLj7//1jCB533zvgo7hCN9I6Cv9++/elrv0lWo1hf9rr06 91/luVIXWDMEFQvum6tK1v/+IiI0GoW7HGxsGEm0rpvSiIiLQaaYqKbW9ZNlQzuBiIMEGEGExTEV K5lgg0yuFMRBhNNSuSLOx4uaJu0bAyF5rRhkvkJmtl0QaBAyuNIyBMTeI07VUCBtJyVCBCjp+qZ0 gmiY7MiiL5KWmUuVSuq/2p3dPTYSVb1dU0CM5b2zpFzy6M0FCqRcXv7+rzjmejd30Z+1O+tXr1pN QUKFTOzHrS/uvfofNAxXaS3ugRf6ep3e9giN4Ik8FRuDU9/11q/27a1/6f6q+0t/wiY8QlhEnpP8 EO6/df3PpMulZ+Kv9f/p/X99IE4RcRBJ6d/TGrHdf2oIRWPdcaX9V+lsRrpaLiPf2UObdEqbDBe1 jr2LVpY/7WPdjh6Tf3xx2c6YrjUGZP4p1tvVtJwkGbmjPL8ZhQ/qO0IiGCEMKedxw0LU51EUxTW/ hjntpwRHGX41iIiIiIiLTQ9U4Phjw383ZZLxEREQcQfBjmo6uVwuOw8qpLuIdpp60YRmlPrBSC5r ZHiDiXiEyDzuyJvDFoOIiPTT0yFQUi/avkPc6hLyupRfIXhAztIMX/70CJRXX7/O/wuSsRBhBiSw u7t5FPCBEfF3nffVo3a11RvovOdif1X1sIF+vmcXC/QmmYHlL+d9o2Km4QbLcX7xFR9f9brW+mh+ dwvdJ91+rqxweCmEvq0jd0r5hzD/JoFS/FerLdX3wZuczlR5hxmNCKvoewQ7OY0LxhB/v/+diM2f /HRjugxtMa/RQGLvCJ0Db1s5v79JhDtO0/4ODOoFNYM6e1zncINfUaHHH8REWmhB6DCEeZEa6EWI pP8Z/xFxEREd+bsx8w5J8zlQU/5NzLE7G8REREWhaoRvuTa8uiLYIibMRHxqVzKCw5DmjJZmIJEv lXkHFKyuJZG0IjK5KIF0GjewhouARraZ11OoiIJs59qzhQadZ3vNTTrQ6e6bDJpef2GdAwRXJ8sg 1nZWqM5Uf3bW5/Tn1U7/RuU9Pfzjh/k3UuQmxsH/Xxf1GLrvuh297xDc8Gz3n+DT93/071r/i9b4 YZhDV9fM5Q5TtGv9/yKa2tnkjA9V02d4v7WLV476EQ2lf99dKO03jwQ7OYVQmCoYRMdfvv097WIp CuPP7S0ThhwkhWSjCCDus58PF/7FNVNTxuoM9biqRvxC7rtDIpreY4tAyhwmfc0M/pRDWzoUIGbY l4VsV/pOvERERGZyhyh4iIz7IQ8Ld6n/HaXLc0iFjMg20IiIiIhghH4URyuSeEwgYkwjslGI82xX U+oaLwM7WYIm7ITBAypYTOz52BQjOR6cNBPwg3dko9F2zu1YQZKsqyMgaJvGI/mcHTbpB6Rrd2gg 2ENPP6ZloKdjIrpcSsS3tN7kRLV6T/TqjY9UXDC5fP4QaZ2kR/viDa9naeLhfM4uFq6ftG9b28Jt En1qix2je01oUrrrXql+u+NW+rz//hBtJ7Wp2awIK62p+fTUzlRuutf7X8fpXq7XNziFqwh9tRxt 8EO6c+ukP++692CBCVH8JgwkK8NL7Wm1kh9rutntiPvUXG1wTFNbG1sUDNvAwkhbdI3bSBFDja6u uI0DCFoMIaaoMVMPjd2MIYZudq6nasLEREREMKj+0OwpOCx77aw1lxlczRb6ZCsRERBhMELQuxTF U9M7BcoRToknkpEERFhBhfK4WGIwTI8RMFyC4KQcpPnYlk+ZDaERD1T3olQgXRY5xwsvn+LOx2Xw pS8hMlOdiebxzQa80GtI77ns0QkCJP4QivpL5fP5KOzqIp9Bc7SDLcpR2NZHUabad18UE845h4V6 s9/y3NdAiP9f6evaluklOwZxdXHGt1b2nCLuJODsf4uKW3/ujd+nRrZXKI6ce///+2613/r//oW7 q6bsLwQfqdgvnF6vr8HzoaMnEf/f/vX7siup7PfMPt8Rt9Wr/OOMv/TnYjzferEf2h9LhiEOKr4Y STiO0vXBv+z2DP9CN+nIoGGzkt75XBXu12Kl+mmK2Kwx/H/GoM/2o5ubrpD78MIQcMEGhoQcWsdn PYrwZweuKhqW5OU3qvEREXGYcp41hhD83XppjiNiOTemdimbjoQtCIiI0IiIsK+TY1ySKys6GExJ MxBhTnU59T+RQwgcGQURJFwGgzsDzuMyMZ3DEREetXDVGGBA6LedlzCDU9mWiI+qDOxP70jRngNG 69Wgm6T7CEYRbvLcX7fVNiDaQ2ct6ep7+tPqdl2YO2q/vH/ZGVdvU/qn9U4Q3XJGF6/0Hq9+Ktna fOCdIz/0sQrOU4yt030qH/DCluryPl/hUG8340oKPjdYf12fTrUjHhCIr/W0FhLDLnw0irows3ZG P6Gf7/3xeFN2Oc9ihaWrjhr85D1WIjiKiIaFxamHOPYr9YpKLP8RGhDhof3WTcOERERGg0sm0RfC DKmhEMKF7JYiOkzsajpF2SmLsyEZK8wiW5hEWZsjoiqsa2jWwhFHasRU1TCQTTCqumbQQZ2J+d7p Oq1O+px5kcIrrcIHiRixbzsmEO1CP5kZESpGfX6tGc70Zyo0t0rZ2ozy536BEfenbptU7Ttdfv96 /X1phBozlRXur8wfPh4dNzd9Fw013/vvW39e/0vW/Xdatur0PwnbW+raX+33/rv7fr/TXX67vtwg QlP31a/t/HsdPV331/v371fri42I2K4+1aC0FEd1fW9Yjf9c9gh/2E0LTsUGtreOIpiK7XhhTsQG EnUi4pH4iItCIiLQaaljlOcexQkDDChlwVI0aUtxxEMJhMIRDsLmRDixpPJvpiIiM5ERqE08m08h eEGdiiKfMIREGE7y3NKyUiBBnZMQJpkKzrF2ajI8dziIyWEStmMqWd0RUkdqMRH6c1wqvqu52OId GE01slAU7iVYZ2UrujcknmzO/6QIvrr2jW2vCFkoCyLsCZkt5WchX+hpuhXvqtGfaN2kZ6TpOjOc dLU7g1U+slQuv1WvI2y4T7rehqrrq8XRvSN0Q6Ljp4Xat3T/Wv16//7tN0OIIJBBrrk3y3SgxZyf s5/jP//6bPr6vMeo9vCxbsiaNpUCD3Q4YWLh6/Grf2se/3W59e76aHjBmCp8F1DEV7SxFIbQWGEt tSUBZIdkU0GYYMntQzyQr31P6bZ+tDhrfa0I2KpDQijtR8Woz/s5xEZ0KhEREMKf4jsJF78w/ilm 5/HERERmRFhUZqdGS2YM5Q+vVZNqIlkIiIiM+xJCDQ0LzdphAyoRK4vkqIq87Nc5kJndoRERaeW5 oHU1irpmsRBqThgERdTbKygs5YVZSgopKTAiprYVbRcNabXo/rhNVTK/ows3Unkh6O94TaLzTs8G ujW/O1YTW7kHktuzsmyPHYlkUySlq6bR3T/7whrGnSe/0CI++2urnatal0ZpOL/+vr5ArtK6t9GH PFa+prPFHfa6f3aNb+v2/vtoPr/vryJgv+ZsuEpu/ed9919PW69/XXPbDvv9D//9V9fS33/W5bmg dtbbW+rSJww22vTdf3OR/an////Xf74TFPFMRseVfFMMLYWf9t/3qP6u+vrqxH+ZTQuwmp/KeLTF MV7xXsRXbfX030CFbrEREGCEREMJhDjjtDsULEca4M3bSiIiGELCFppigZgq9pSbQxEQwTCqsMVC DKlnf5C0QiIxGERCMIlZmVaEREWt3aZ0SYTTBNMhNBndM1sj5FWiMUOZFKRWp5AzNotRsdPq4V0v RbvSv8wj/dqVnCDOxREKRCuk+tfO+4Ijz8J9XqeOuSkIuetNMlLsi52SuL5C8lcXyF5aiL5EowEK WRHQUiaOf2vpP6voEX+ttfSf9Gx69a5KxV//ahCKCYQv6/WzNkcLVlaZcJX9/87ner10+gRH9pwt hMLe1+poKfIUdvXXvvX/rr7Sv/tkTBe8ibLhPqu1ud7zYoIj743UaHnRGf4Id6/sKf91U3drx4jX +PXs7ThhLev9Ia8ii8NLv1Tp+m6UfdRru+6d/mRVqbvX6+v1+Ey4SxX++DOoEcRXw19iNtQZ///M 5Tx+1nRvq6/v/W0LQuNdNDsU+1Ff2tLQt+2vb+++rZz/DU3YiIiDKUBCGELsINDuxTv0PFfEcVfU d6j8RERBhCLQiLuGEO00xGrEU/JsOjurJajsWQmMRERDCDCYU3Wh4UrOaBgEGVLUhEQvU7UYiIuG EPPRF/0GSjyJhizoj8ahTv4g4JEosqhkQybkYj/0W9Gut/epNNzp4XPcNMIMljI8djeZHzmVJEqE 79sKftN/PBr+4RMcof+5KCL9aBo0NFu1c7UdnY3IOyWIKEiVkSrKyrfuKVq+40/8IQ/+Fe9ncNJu E6+52rEawQ5nKBGpC1dtf3ffWzQMd0PfYRdxfEMOnVud9+tNqkKNbc9J8Ietr+u69X/Vd4f6df7n cqK6N1z/T//ImGPtIigPrMiCG570lVB8ZKEF/6/pfroY1u3q83Wm0m13r6hgih4IYQ2CI4zCVMIL W1vr9Nu36p3/04M4QURQMAzBQ/DLcEhHULDrP9iE2k6T+diAw77pNn1M5RZ0P41hq3aHaGYeDOEO Wwx/CJUDw1iNr+1tUhbVQQqIjOhUGENNGa8Qd9Ak2KaBn2JbVikNz6tKbtREREREQ2IvM5TlDlPD CYXxTXFsU7hl2FLKHtDQiLQiIhoZ/q1W0MmyUjVF8qSIWiQs1ERhmRkMRERGYcw8MIReW6VnXIsI m2SpEfCZKoJhDTQZ1ZdnYlmuL4QZBMwjtKRFsr9NCIjhhVXQighSSLho0PTO1Yi3NjCpnYn3IPKh wqVlDkWEiMfO+1Vng+OE6Qep3qrpBtNzsmEId+f4ZChSVMjxC0RUzkRcysqDEKd06XoznfO5UR3W 66XRJ0gRf6ed+lVz/1hqrp7aaybOf37+2vpdP31c726W10u53O/fQLeZwaJD1+Fo0Mgoke39f+2+ 7Xr6/6p/9e/EJN7QbRuoz76b3N69++n9/un2/X+9//r31CCvFuhryJRcJvXozlR3q3r/+62laxS/ 36IUf+/ghSCPaGlf66/9L3imIrj44piigHdbbpi0o29f8EtSLwSc9/WjddL/+LsIWhaadMd42NmH JDuIrtYUbP2IUMLfj/xH9xERBhBgpkRFphQhDQaFigZwTvBIbGvcML23xFrEREGE08548LYprYYS mpeKiJknyVYiIiOypwwhpimhHk2W8l4ihFYyEyDyaZ2KCAgYiIiDBCGFJspeQ/yFeahDUKQmQnIr n359YQZUkdhDMisQR37znOL9QpqE4hlL1Ri03MlGmSiLmpCZhnY3Jksi+ZDFpvvb7RuovK7Ijvek g++sEXR/TTO1bTRva5C4lLI8FIVmQz/vrvQ06MOd/Pl+7PdX9Tu6Hqd9J1rdBXIuFIv5kfXr8U/0 NbmjI4VW/dj3799aW6niraBEffgiP/d2/rS9bv+uu9fX1+Pp0vp6/S7n7/ybAgYBDnOyJg7ntz39 tT//BFPSRy3XX//r/+ROLhK/fertV/HHbdD7a8R95FAw6XM5o+ldf/qv43X8GcGcttAzA6fH9pDC s9thWo1oXj2NY/xm79dr1+SBc3ZuQ47GDOEHFAzqVfaCul3r7fqCFAhxFxEWnDCEMLwwsakgLC5q WIp7iKJQFqoiIiM/REcRFp2hp4QM0qy4BSbJSoTJLQiIhhThSaGTbtSIzsTzv865Gs7ohIWMREXl uaNBkqCEhhBnasQjER2RfvP51EO3QUhNBlTyUMxHanj00vzqE39UM1io3MlYn2QrNxFkUIhaIXkL RF8kdqeKN2p3aNjr/ROKhUm1puQcVDTWyL6ZKAhKAkZFWXyF5CohXS+hpdIUYc8Pu+CdG6jDnHVO jdp26X11WlyVCEqEJUL1/p+v6b8aGsN/Q/Ph41PD13mzLHs0GhrqoXdd+r//H/6+urdr8b9PCP9P zvtG6jZRebGrDN8dWcvwQ1bPbf79v1vX/vfpN170KQ0PVDaWKu+p4KegwWzn/G57+9W0ueCoKf4u Lfil/1YXbSp7GDOEi8aHd6ocMJOvGuIuRMMKv3q29xYU/oWFNyH/mH7sbMOccw/Y7prStWiUhSLm FtX6z3Z7c9xEREQYTiNGan+LUIRDz/DCYxYXTgzhSQptKNSKBiOOIiIiIi7iwhER5YIYcFGxSqsm 1MRERaEMJqZGbs3akqZfIPIvFTi6JRlVRMIRERFpp5bmgde5BxbcghQGR6zt4vHSMkmSjITKzmSU iQhEdL02uw0vT6P5E0akRuJ9ZFHOHKolJUy+diWmmRLKI71WbqM++azPnfc0GegRH30d7/Bgn7xB 0fwhrnZMSOMijLyZS8lREEy/putz8YCU9+9O9fr98MJfyY5Y+9UCI/YV3vowj+Sj007j/2vuvq3f eZsjhaW28GIJsjsEUPIolhBw2+jdrebs1nvNZ4pPp3ejWwk/9WpoKH/v9b9f/+GCiIwmXC199Cvp DTel6BF/+qum4Ij/Js6W+hoX/9b1/Gf+9IYow/1vjv916ptqu+r9XVvLUDUENjX7XvSde3X7r8nx n+9aufT/+Pj/fW/12OCYr2KFiKg0hYivY1n/69/NBQ+DBfWzl9/0xHpP/WZTCHppimh2K/3Wwo0L aHGlG6ut1uCH91lqEKIiIgwgwhYQ0IjsV1LHsVw0oaTEYZu1YSdVGTZKR2tIRERDCEWEfw1P9jY2 qsGdSHEVJsqBDv0SkIa8yCsREREMEGEwhraDUm09Ig9UihyQQ+hwo+zxERcMEGFLc0rRgOSkJM4X ZqFkEIPxg5/CkJmR8rMajOwJCImF+taGp4hbX+ZRU+iViIMqWFKnF8heSxGEQtL3s9c/c+q9F5Zo M7d76XtUaH56C5KAoJ2Sk0yKRxlSyF5C8lATWxRoGFGSH/cJ0nf37PaMOcdOqLik++rdL/adksWq X/416xpv7vY6w3bwhpv+d+jdnfo730Z3koCczUEFV2qNWfiruix049/9R/767kSZcJbX739r8Knr 8YIVSj2cmhvbOf2CGqMD+hv+rYTXxdLeu/siUXCI7niRPMHTZuLUDWrPp+PbWO16mc4+v1s8rVqb oQp//X9V1X9OLjGDMFC61khy0BkclYYSEMwNC9nu2+bsW6Q1/r319PVVN32/S1jzckKYqbrFP8bx 7rDX5ucaRKAr+39+P/ijfnahQM3IRGW8GCaEMKhHFprm6xQ7VBikExHEVGC922ut2hYRmhNoRGbo iLTQYTi7TOphO1tU8V9nMtQhREVERERERDCDBC0Li48YyuZZ2fJUy+d/kri6CkHkJnRmI1mdjUQX KkhERDCHldVs7gRewtguahL0GdxF8IMIGCDKoipInzsFiUo4hnnLUDXsJL64RN+tNo0QnaLHadkq SaeUIlaMMigLhNMlQyuamSlCI953O9GffO+wS9F5hPTdOgg8+NHxp/l+wmml6Z2XMwyV0MIGSXJZ mFrWutytRcJ+ETdisJ/V0eH1aut7/9Tj2eC3wm0XGk9nHSZBFqn+k2//XeE5IZHC4/V6+9dO/r9K 4wg+8IN6M7x57p2E32F/9edzvf7///7//8iTLhX/q1bX+FT5Kl+b95x1lqBqVwsMW/fQqN+khRjG f7Z7tbrarUvXmPzCX6iP///771v9JvOxtjae9jX71md/aG3Trft1ultpWCGGp+v9av+q7/v/98Gb dLGxTWxFODH/HDSYio6hqtqtCtgzdj37XV6pY9f/rtC00LTVBxqfoaY3Q0I0IwZgv1tBbSYYSbSt V1iMEO/eIiIiDi4iGCYV+4/hrYpio2MLs5/TpKPERnQpyM6NCIiLTCaa/tnPBmCxFSuF5bpxiIiI iIiIhhNdCOGudg8heRGVLIVpmvI0hERFguXj0TSuyQwgyL/aNganuyDiHno7nnY4yWkS2L5C87W4 7A0Nf+o7ukn/OoT9MJrkpWd0yJhgheRM7KlkqySr1788Hfv03+lvzW5ra2nZpkO8lQj3qQpEfCmQ zIVnYmrvVZEwxpX5Ewt7vlCWdzv70nS0CI+/oGvPBbwlCb8IRrp4tP1930KXvCZHC+35WwxV03Xu 4YhdQg8w53r7qZHCb2KCBWsyPqqyMcw/46/+v/X/BhEUZcIK3X0/z//LSKVYIj6EV8dAhU6LkdEf I+qjP/8ENGR/r/Udd12/ImGFxncqJFUR8joj6qMM3OvaC18REc3f/r26vfUigO1N3/799ewhERnZ cMXwZlm1gzFe1r/jBn5fatrfWNbq/6U6K2e+31i004sJxpnPfHF8WtiopiMGbAvtL9tfwRTtf5kZ 0YiIiIiIiGFi7QaYTiOxXGxX4Qj//eIiIYIGFu0LTQ77x/eWkVKTYkZrR2KxTiiJjERElaEWdEWh xxlcyzv4JplYkGEynIq0dc7FYp9TIsxEWFQyuShCaMJot3R/JQETm5pnXTz+dMwwg7JZk+RSJ8lA UhUdzVkTzIuM7AmQViNLuE32qNbSbRrf+mmjO5BxocdEpCpgkqDCDCDow5ntTxV7qbtPTpPva0jP SD384Wjs1nBcvno7GpF2yUo9BE3DRMcMhcSkjsXXa0vrf9f6v3eq+2fDvZ4NeaD50a9YRJ3S52rE QQbXQQbCBByVBLX3ev8PFv19/v/p0txcRxs28P2CJjx3dafeg9NqjQztIE+913mND3zG/a+h//37 cbTfoJ/VGHPFf6unmyk2l/Y1dL117XoEP17Ux731CH6+1BFPr3vvdbSGnnc7/rrDVZ/koCWltpNr U/YpXpbXIFKbyKSZvRlqCZHGg9iI/vrrX//buxQYVIR+gojjYoGcJd1Q9tIYjiNz6JSFjZ3GXg/v agpfC9PT6l/+OIfHZwWGFX48cf2mlJDgiOsMUzdttfQjb7Wzk3V/xGchCM5ESDQiIzOVkMKY+Y9D m3NCODvvFMGEmFDCtpR2v/EzQiI0IcRER2sQ2LQuxQM4KKjVCK21lckztLCHbxLRDoQn8Wf4i0LB AwWwgwpuWMdUjUyPhBhIIMqEVGdqYhUIRc7UIREQZWxo6LC56Rgm00XAJGxnTTOgUg5SnRHQUyMy O4xJSrOyrOxvE5i4/pXRr0KQfejUERlAjTOsYankqDIKzGvnY3DerPaM+6bc/1fc/UqCzQ7Tq1PU NbBSFYKFIVkpCbtjpdeSH7/3O53kFdnuf6T1O+99lOG1gpKRAoLaCx+/vFL70/t7HjTdLb+4hunC I3pAiTwRJ/O1ChJGL+n5hwT+kP/+v13t4YZhLYIkPFGHO8K4SfvLHKH1aXpJDGCH/6OEZ9f/HDWP eE9bYRdxCLtiRPNsIodNl0R7Qhuz2xa2rn0udAv7XYV1+lQwi36r/1paYQi4j1xsUxUbMOWOUPBn CLYxs9x2lFLM5T0YeRfCCDvTFfwfDXmHSCi1sJpaEX51Hj2GrrQvnqK7VGdl/9GHGX4IjkYxz3O1 CgZ/iMznHYi4iDC5/sUP/oFsVhjttcG/Df3n1K6xuJ3PaENCM/xFhCIi1W04O1G4Y8Mfw04Iib8r ZnERES6EREQ4tCDiDjUcJhMvkLyXiL6RCs7cirzTTcXDj0X7XyHuEGEslEXYTNYmYR9HWMRUshMh WQrIXKQaJbkpRXmYi8/rTrf8VqnNEKq3hPyL+SjslIQizSTUvKeIlkXyUZWcIMlLIKKSsYiOud7/ aNAXU70m5sv/O7/91TQRq3C+FC+f9FwGEwmEGVLIXnYmi0ql9LyJRcL9USjMD6W6eml+t/7+bKM4 r4Ij780NbVdBB5nc3NF4yUfnatJ/v//6OJOPr/H9fIkyOFNIuF/0hprtJv6ed7v9NpOb0m6D3feP pv3n/peroz/r9iP////r9e//tyKL3/p6b/Vy0jHj9R8EPvHPcffZ7d0thT/ef+l77Ru6/f19tQmR wq9f6+5E8wiPK+NONL6iL9pXUnDAZoKfGo+PghkUDFnv8EPa7bV/Qr/31661Qj8tIpWY6Yp8Gctt esUri7pfrVEUBeIpJtVYivVMZ//ENX79f8bThoX5zocXam8p/jv7gzhZyzs45rCiKajSm78ccchB 4IUM/wQ4iIiIiIME0IiIi4186M1I0LRLUxX/yxz3WOvSiIiI000+GhDQuOznsIQ7PTLHOOYeDMFV BmacFdYR3VCIiIiIiIiIsIRD4u9M7cFzseL52qxfJREGzEazKtHY+W+uQrEWhy0lJW0gna3R/9Bm t3JFh/OUH84UfdDlGxEdM8Fv3V/20aK8Ha2pKFZ24sOyS5CslHsYQbRn8ER/vhOk2gRH7nsO11Tw sHBkrrIv3IIupFSrO52klavXaV7/09bj2truixynzuHMOH69lcpYTC/r//v/tfBFgolFgIEJUfhC NBh0GHvuzQZ3prer/rrQ/9/8XGvEOIf/p3andoER9+63+/2t16sNV/XffSbtLevLSKVu0mNW1Sn6 3Tr9BhgiFKGR8EKbPZKMEiUYJKqr/r/j2KYqI944YSYjOzXCy4y4HocQUQgQoEKv+v/TTCDVYaYp qIKnrBm3PChNbrxr/EREREMIMKWCLp3n/CggZwUwWKF0r1LSKlJunxGELi9b17tNKxFDK5kjvGQo joEOzBiIiIiIiDBC01tB/ZCZB5kGRGRXNRiIYUrqthFuyF6NsWmoQ6iHY3NhBksi+SyL5UsIMjMv lSyLMrKH3QfoHVcHRY7W1tUXkLZFAwmmSqL5KyLcVXerIndns7ELRuo3d0EG03XJSEhNpukjOyCh AuEyuFxfRG1AOtJ/Y76GnyJ/Toz9AiPukraMOtng16bVbmthd/3//4nYyLhP+luvRnKjT1eKTfmK f1O96dchfBArC/GjbMEY+7Xv///u/+696Uf0rne3lqBrEU69RucnPYaRvbH+1X9b6/Xf+v+vkTsd Q0pj7Pcw5N5OGIx1W1v/7+62u6UEUP3f+q/4M2zivjoXVfmPbSYtb0n9tb11iI4Mxerf/kfI6I6X TX/zIzdH9jYpiPjYYSYim0njvq1b1iIjiIjP8REREa2Ewg0LTFNMVOerEUxV6UsfcRERFgiOgwgw mhFn61TEVRPy3S8qbE7G8REwhEREGCarldYZfRDAsyBYQZAs1kRGXyozWiIyCs7vIVpkHkLzJPiL 1XbRnZLiJkR2mFs1CBMvZ9JkCkQwKEI5xcmSo6hFURoER/nmqdZ77o1tcKuqaM7+LTCpBSKZPkUy hEoSksIrlpa7wglsxow53RC/sx+k6BEfebKBEff6d5vzfRoZBSI9Op19MEGEFkWyFZC0QtBBkoKl vQSr6209/6uvpqvfXN/oLQVObQSawiUX/0ip/raNjX+IQK3///9/8ftuq8nDDQQVBBemETeLZyBA iPj/o0CFsmWSPZfy+kG57Zaidb9BH/X+//9f/6i79RCCFL9BcaBNxx1RKvSimOOnXNofpAksR/tR GThi637Pe+EsJrMigj2ECPf96TaS1/kSFJUKSsZKxf+7GsfbdDtNq3qaAvarM5TuI/CWEuIqOcEG znzn7m/V//rzsarFc6LUc54M4QVEVsRWLyIPpQhhSOLc8S9ozsv/3qqGDDJYQMMG/vWHYU54iLQj hpqY9prZSLvxo0FdwxVnvDGv8RvO+cftyJGI4cRERDBAwTQhghEREZqZnOOYe0LVA8dA7/XOfjjO FnfHhuTZbztZxERaehFxEW8Q4iIznr/4okPmpBy0hdSuZrOiyvGIiIan+4i1QiIsEUIREYIEp2pQ VMqmSxKQrITIPIUlK4NiIiIiMrkoiaVH8irQMEwkSoQ1CHTshxhnVWReUg4EDIjMIsoH00CI4/Q4 pQv2qeE0FouGFVaN6SavRnLho0BI3Zuq9IEX+4IjjdBA2tllEanav47T9U9VQ1T9V7pML9AiPuE0 s+i0ipeqOKH7/Xj//7RqDFPXaaCVMbn16of/m6//2us3r/ejQKfwYW1+x/pz3DOYIeuThj+ZH/rq 3oXEc/7WI0M0BdKKWrCr/7XtPlpFSzD/2v8GYJVlDmgooEdLHarWb0MdGanRFxqc+f8x7jQ4yQ93 tiK9aiIiIiIi0Ii1OiNTnTURo3OIiIiIYX8rkmW6dDNS09TJJhAypIqMhSO7hER56MkCBMlGmpLx qECDK42imCxfWaK7nURUWO1G9Iw53RCpJt3wkjOUPQQby0JeXy0itbutu6f1nc70hDVPhccMJf/+ ZsuF9vH1Xof3/7/7+V9QXQIj7eYcER/9q1ImGBn//Z5f1/G7boW6rX+LtZkV/W1HGSjX7VW0vf4t C0GsXdjmc74/9S0ilREREWE0LQYQ99DJst52s4iIixHJtDzW87UI7K8rgaaldYZfCDBQmFIPKhQy XZiIxGEpPlZyFpQwq8zsFRoZLcxgp07Coi18J2FUEGCBksJSnzCJYZLTIIyC5NjGNAiP6QcERvSb ImGAib/OgQ0iHQe2uC5fP6aaYKFTTQYQYQZLSWltpWETHj+CvulBniZWOFoER+wRG/1RsaNlGtgg RHldGhot3M7QaZXBRhTsTX/cIJ6eXh3hF3H53O7DEIV3rwkNfv3TYSaQIj+k3CdIOjXRrpquvrr8 Nv//uDCBE6+u6Nm966dXCJvGr6dXSum0m5rZKSL52or3rawa3mNh29//j/+qt69r1oL6v6un3rSc Je/6ephxl90lYoYIjjMInDH2S07X1g+I+n7/+v+9furCJvH7EcNcMcdB8OrV3RKF3T9TDjMYe+1d Y//utf63QW12mKozNCw+DGDODTGhTHEeGMM/2wtpWlO8vXq2rq9Ot+t99hMIQ+HF9+CaaoH1imOP DFMRUNK1hraTa3UZhHYMMRF0ZEQehDBS1IIQ4tBhNNYO0xTFMUxUU2s8O6uI4i0IcRBggwQh2E0w mmmmKwxgzWCiIiIuIiIhgmhNG4yuZYiGCepXVbFx9j8rvFrBXp7LWKBP67C6NmCFNUOhWDM2VXqz yjF1lczU3ZXWkpksRw2moIXpiNaRodG9dOWsFLjfp9/722tYZHNiKuhbRawmy4XIx4MF1n9CGkbs RHu/K6mh4UnyveN7y1hP/yK0x8uiPhLkHaSVERmSwGJ+//OdzH0CBV3sQi2m/9dprwyTSMxERLWE 8GD7eKyI0zWZp8P////////lfVR////////////////8s5Z+P/////////////////////////// //////////////////////////////////////////kB0CW4//kB0DUf////////////+u////yA 7i8ZbmnK6mFzNU9S0TiP0aj8K3p7167fO+/xrvbVa+wwlP/1LOREfI7L+K9vpCIhwwn71RhzjkUf ERYisRe18RGTaMui3JeVzLCw0y3CLrw16BArspwy3QITdJmF6vFhqmmVwUpXCwxrYMMvo3VcEH+q jxR32ixzO8x/4Rb/+EGw3ft1CTulv/9iKLdVJ7Ofqtt92oWVzIMX09cRBgmvf4a8aGdGI2K5bmmI iGEGF7DQjK6mFkZsOcBBQnBqW+nRqOVjLckELfvJuN+nFVvJuTFK4KVcETbrJ3Kj2FBB33Xunmui xwRHtqDJt1Tb6pDCDt2GCR2Ot/uq97FR/ghtnZKltuGFI26zjrPe9cZjYdAzG6QYw1XCFrYriM6I YTybOZbrCFxGV1Nn9BluLaBkRnYFjTVGhluBCQcgm0+jO3SdWccHeXz+WUkWm+nRuiG2Zy3aXllB Ffb/oQgkEHe/T+396Bbf/V9v62/tiPfDY21YZzDB60/23ii3UBg6LusM39bTtKhTGL4IVEQwUyME 1XURGZICEQZmsZCNSbTy3SJ+W/RfsrEdpDIedpSHryCC9B68LdqjRy+f8vn/zvdnsztG6k2l/5Zx kX5brYL/q70NPf/rf/q///9Xzkf9/9iRj79Ai69/rr2e72NiOk/XGkw0nj1DM5Q4Ij4frjscY7DS cR2bu/EMJhT/Yr6/4gwhENCIu2qxEYipXMsMKVyUQmwOIPIREJnaqZ2sw1JtqEzWgQJVQYQdG6uE I3Ro2TdX6Gf+iQ/SbRran0VwX+JpmAiM6cnRxhadJ9ZBGkt3qtLphD7q/u57+fvt8k/932fDu6HZ yHe28Z/9WlelvybUBf31+1fj2/N3/ivbStV/whnIjQuOxTFTd14iIiIaYVd1xEdjGVzLFhSuqhTu cW6Mg4gudk8edjhC3js6iEX7SPrNlJcKv2WUKLTzud+83Xf0yus8ddv6H70a2VwsS2/v/t9Otf1X VY1tKV1UL+CFQzmENa53PHWx0Tgugp//95t04M1ci/7dfxEMJ5kd+1/LSK+IiIiMV3jK4XBrY+wh rl8vk36I8dGYiDR32YR1zK0I4iDCv51ggwq59HanrbXpvVb71JuMyut1GPnfdPU7tAiPv9+YR/T9 /r+9X32FVdAiPfS3f/6324L+g3+///+MGKf1zfGn0rXS99f+vldZHGrYSjW1Wf52CBiI/9MVFNKx Fer3rENAwhpqtnRBn/EcREGEIiP8tAaF+dGTafZWUIiMmw4iDJiJwgU1xfKjO3Mg0XzvEVVQsMjA iGuqDBbCl4lB3m6W/tZnLHrZ1CI0V03auk7c3ahA6O90km0CI+6OP0nuIYMj9CPf87nfT16vdZZy EdV49XX12/+637W9nsEXf9/f/+vX7WW62C5bwN4ZzdfX9tf/q6j6CzYL2lfX91et+6+Y+F7FMRXG UoHYimNYYSDKgpymm7Qtc5FoNC0m0xTFCIxEREGEIzIhgmEGEUzRRHER5Nvy3n4y3NOwgZCZCZCZ 2rCGszshVdM6d2qSDUhffRsr086g0clQhNxpfq3f9JvUm4RhP6v5pFwhOGLOVPow53Wn9/1VWPyl BittpGfLdKDGoIp6tTdmcoct6Xr+lXq6Qih+hF5wj5kf/uW5pginDCtV67hf+/rhCMGcH/s5E4P7 bdX+rxxajTH42KWM6EIjzIiLWsRJQp/TWI1JtNJiI47LcV81x2C51CHbn1g8uj+dqwqSDJTd4Oru p90LfR/JuTi/LdKRtF0vPD10a+gm71uE0Iy3BxcKIN77g3Zypt9X//fRqHXHvfBF/jP+p+kPBJiM kA49a2FS7rj8U2ER4Hz7o6Q9avrwQM/ZiGUsL6/WWsKKO1wW4hpKz2UtIVP/fGItY0MwQYQv21WL QjyQ5Q5h4vEVLc0xn+yg4hrDLcZkPKTEREGFREbvgwQZGRfIPOz5CY5nBpQdrnWCZ24h1CHc8hVE PPZnzwDRra3qoU7HEJR5NwnBKkEHF0nR3vU7tGzNiS3kEayogQq2CLr3/70LhtGHO7+Hf0q1//rr ftmgz4Mm3jsO/9V8f76Sd5bmi9QYN6fViuz3+4IFhab6EKGkdNbWNLCxnQL6xFfeCYqIJimNr0rb qv8zfVQTCDCGFP1n3RRgzm4k0qiMEIjTVC1xjERERagwUtGrL5F4g8hM7K8mTGuT50We1P6n87Ji BaBEftBgv6uqwRHyyJPW7BlxX3/Rs0J/WvgxBX329CS7vLIcJ/Bgr2919hkeBFD0r+KGhSFehEc7 nh/S9Oz3s7kx/+I5uo3ObsYpCH/tV+7//wwhcWhqfskyJ98REaG7Y4hlDhC1Js8Xy3WYhaERhct4 ggwQM7uMIlqMI7Aj956tNVCdp0d7+j5Rrra6M7JuNL++t02gRH3R36Qcm6iCD/306vX+3V9/26// 0v3pHj/Q7zG+v///vSV0vV/vStS//Yjm5wwqw0r0n96v+01oRsbEbEcdR8RHYTCYSG0uciIMINTD mHMO6WTaeIiNCIaGpbpTLoulJsMxEaERlvjL5B5KHZrGd0iny+VGdgSzOlzp36Z24gXOoQKX9TZX XhNo2Qq2q2TcDUabne3vvVzZR3vNdAiPuTcJBB/X311eh/w6T/dev/3/9qyVru6R4329QRQ8K6// i5Fg+tf7X6QirrSs9/4Qe//YqNWmGFhhSlhi9ToFCLQ7r/tMUDOFiigMKxFJNOxFR8QwsGFcx7U2 xRUFiIzkWhDK2tprk2tFvNCIiItQQNMgoo07ITMNMqIg47/KjIREVZgiCKjXg0NG551CE0VmoRew pf0G5hw1SbpU8LdTvC2TcnF+vQYc/6fn5O82areCI+6/xDqPmkXCqP0JIRtaXpPrd/f1r/BCP709 AiPv1Ld4Es+vdG6/62Nddfh1FQ04x+zkUoMWe5kX//7HBR/ZoC9E4Lv2tuv9hQSznv4Myf22kxdf x2f0Ii1OReY8aYpir0rQiIiIiLCaYjiIhhSbTy35kFMrgeMmw4gQZrZfs6ZBx2VoqEpC8m42qzDt cHU9yD7Ble0wUlHk3JoE4RfUgdAiP2/baedRARMfqCHoUrrcnW/NZ4e6hXtZMcF9/0+6pt/RnKiE THQ2sEN/X327X36XCBYYlG6SfWz3q/xoV+v9+0xeN69dX8EP3g++sMLGkjHzdterbWZxmMiYLo2B ZusUxT9bFCDNYJ7qmORvobQhhBheLtOIxuZmyiOf4iIiI0GhDiMjHxF45aNM3kVzIFypwzwUPhOz pyFVnCH2anCmCB4h7Wp6hnT7RBBYNMm4HiOn9Gm7vYcNG9k3LmiNrlC2+4fepcGdzuHTdenbxus0 i4SE7iDDV2p7e+H/r/vWlf0kKKOrVpG73r/9tUYeqghQ1fWRPCC/a7FZ6Yqr7XiFHYrafoGYIuGo wvqGEIzk0LQYhQp0WGsaEQ1QixUTZiLCk2nhBjJs+CKHlvGYZCQRds1svmtl87nFCJ47JGTZTyU0 EI00zUJQddc7cQIYTSCB6eCI+EkrXXWilRDkaGChPO53pVc45h9PO+532jZng2YYWmwmi+ddut1a ftd13SEasMQknBEnUJv/pfbf19f7hheFFXv9+6/Xr+64+EXev+xpb9q303pWe///8dL6sMJRrGsb aVrD74tML4pimKYpWGFbSncZjdKIiIaDCYTTP1imKw2lDCxERoWE1hjYqWcDxERB2paClnRECEbJ UpaC8E4ZdF0XgkQmd0yEyQjTOxNE2KkI+YdxEaNBQiuCGoIitcrpIN+KeqLHnavtBkWRQuk88Hy5 9I3J3aZ87o3VTlo9lwnY2MXQlKzbBFDyiI6MJR39Jvfq+9WmhFBCI0r+n+1N3oxnlowS6f/9xxrt dBqYuzmM35yN0CDI6C9e7jViNz1F/q6oRXzuU54xqPil1+GEmTdR4i8UTHOPnPWf0Li4YoHH1k2n sIT2IzZERFrnO/k2HEEWhERERhS3RjmsItzUMEVRHRuO0vISNeYRUsm6s6Q6GgztTWdQqdkrFCDJ UO59TwXHQIjydpBcKi4YQeLGE8KE+82Z36JD0EG0Xnrf/7pdzm4EnhN5nOOFXpb7Tf/Vq5awstCN /6qP/71Y96vwQ++rPf/kK3gNYwtHUK+pFAxr9WKaUGYGoilbSsjj83Q0NNTKFNxQ5Q+GlEdpoRxB hUItMchB8REREMFKIUmw5CIlrCqoMtxWJSyPGtl87NcqyO8MqcNGuW4GKrrqfSZCSZFQXJsLC6bC rr6aNbOj0aHSD7yQ+d9zvt+m90nmg0UbtdGdOvpffvCI91YpNpN/pbrf3fX396enLXBq63vet6oV +3+YX+O0nb36frdePST/7H6xrGqNztKw7a9r5a4hWFxTFMV7HbxaTaUYxF2EGhaYQihsVxERDSLc rARH2pqS1walnA8WEIuIvy3NMmwQUREan8t8ZHiWIvBSEjsciriD+quCGjQUISZrCZC8lcXybiFf XXFUa2uSkIF07bzvtG659I3aebOlBEfbowj/tUt6GOhVtISdG1zud6X6d0P1//CYQ12//6/VzhG+ 9b//tebrftm5bOeufxn//v3dfjVDz6JwxaROC//2qsRxditj2Nf7ViKeIYU/1nRYTOiO7FNBm5xE ZuiI0Ii00/LdKy3VpoRERaqW5GprzCKcxLsk0d5DovHpDCdoMIM1KwQZrRuOsQrKz/69GijW0+Z4 TTo/5/JR2TYrRhEsffng+NHfaTdP2k3r+vgmmEH9x3/p1unSdqd3fvurzO8ZHFStLf6f/S3fb/nf oJ7H//66/r33/97cGZzj7pvSvboEKfMfWhoeqW6vxd1/dbX/Y0tQQr1ftcUxFRUNJlDm3Ma0s/5v rfWsRaaaYxpDf98lG/3UGEIMIGCeRR4tCI/EU2FiIiyiIiLUVLQUI2xEsiWgwpaNSCFEIjIpyFYj TqzpF2dmGXwQZFjRGUlwZMqEa2jDVU106fybBXSd9qd63Nbanh02TYpF1dnLXud+k6S9OFLcp/xR oyOFpJ0t6v/0Xn9VX//1v/CH3owM/70r1+x/y3KkXS21/Y9+r3W1bLcUDGKbOX0FjVsLaTaWeuGk KHDWxTFMkPiibCgYmPLSLVDBYiIYTCYhBhb4xZXxEGCGY/4iMIaeV1QQmyvNRFWiKYiMJk2rETOu nkhHZrlYjsxF+i/ao1v8vqp7JUIuTYKRKVhNo3aff77Crk2KFaDI6I6I9VzuFQrf/T83Ud9rsREM rqv8mgX3/+8iOh9+4Ij3dQg71+I26h6/8+JvwwkEWcNz29Ahuhwbb/vt5XKEXRdLYqg1Ha0GW5T1 tM5/6S7ghEcMIRVigzBSF5uZUM4C96QIf7xmy0/tUOxHv86JaRZxEGEIiLzkWEGYLDCVXjEREXYx fk2HIQwupXMvLcDjeVJFOzsWxEeEW7uyDjUKEGdlwXJeIuZiJWXhN1nUIFRodHT30ybiaLTMl1em 0pr088Fv3ptGtk3JiFdSQkdSuFAv2lzud6QdXqEH+np1K5YEH/b+3Q1Yrfa/aSDs6L0Y9f/6fp/0 b6NPvtd6/bPd1fr/RjxoN/jW1/NAw6upoGLX9/vobFbHw0rSabStfPr4jNBhzj2hqayrsbFAzqQq I4YW1tCIcQ1CEOGE1hhKhsMwglERERERZz5h7EVK6wjupCNGaDBUzv0R9MtxpGEVCER4Qii3RBNM 6aZ0R6O1EVbL5BxColGevlvggV/V89rnQL6k2FvzdWd/v/a+6fIICGaxJtNo7nevf9vzvbn5dpXl ctz9x/ev/7pf2yJ5gasECEEXTLczugg////9N9eOnGNDCd9N+d+E+2+gQwQwh+t8w5Q+1byBMuEn t/CVt1+l7fVCkIOCl1Xeqt/ljguNiMGYGfYkf3Gp0C6ouBf7U3Xb4sIR4T/TFQmvdtca9viDCBhV i7CnWtPFDdw2OIiIiItU7VNvK5kibheIhghFp9ldTR2SGSeQasRHlcsYQaDNYlwzubI8dIjWQvJX F/9o0NeGr57NYqrk2CshX4SPFIOi75Tmv2FdcmxUKRMMSuFAv/3CawYaM++kSHWjvbCr/68TRlwk iLa3b53hsigY/Rd2eDXzI/3Xr/vf6/wg9U/49+z2M/wRO/qEK/mHJDlD1/EVvW0trH50Ht9f9CO+ t1x2lOywMfwuNZ/3f99Oe79C1z2UPHhbFd0x+xHG9RGdGhaGsMIWhaF2lhrpxEREREGCmgoexUrr BnfMRGhEMKmEGZC0XzIPLo6x2Z4jRocztc7URhhbkZM25nrBnY7MVJ0nW7TW4M67k08L5N0hlUWr ptAgV6negRH3nt/fNbp0GSzBe6vS9JdeP3VpPVo0Qh/r///BFp/vTavTa9S/f///9f/q6N3aW6Xr r/gwYIhB4TC6v1dDj4at9RS3rcaFN1r1lcysbFRG6sRR0CyThQrWGle2fUHljlDlDw0GEO1BA0IM 6sUxTrDWHhCJ5CIgwUsvdhBhQ0kMHiIwhERYrDyuSImwLkahMjGGFPONTuvO/yFZKMqeYRUlZCBD IVEIvCI8/k0smnZF+8/p3cNIhed/EJLf+199Qvw51mdjiGoIi3KKwyCRdk2C1v3d/t533ms/VKEL KHD07JUyPX6/9/3wYdnvRuo3c+hDDqd3rldY8Gt//apeRJkcLIlBkSZcJQ0LFgwy/76T9Dwqr6Hf 1r6/xpfwRfvzDwQoEKBD31Gf4ReZywKf7doyqW/XJsJBhLyuVpS0ixaP9NVP368hj8fs5tnOiFoJ O3Wv4Qx+DNvzhRwq7EV8Ls5ehoef0IJ4wlMj9cdrx3HhcY98jHwtr+62dEtItUREREaaxnmp/x1j +xHeMRn+IiMw5Q8cR2n5XWEIwhERDC+mZJ4vkri+QvIvndSERHnY+dMLa2RcKp9WamXzqj0Qmdwj edIjWRczEVJFM+vDC+r1p62vk0CyDovpj2RR0jvdAiP8/f0CI++/tpU+TYEiUZi4Yhf1f2/1/82Z 8PFn7V0TYpEtMtYWXO5v/rF4dFKDH/ZoGKdW721ciiNrSWx4//8f/0o3W4/hNDR3O+EjP/rvqqMj +CZHHMj+v/+31Zawqvek2qkXCzd+9Y/733UUbn//9iKiKhVb7EVIxwvJoFdaJwsNL//obTQYU4Vo doGEI9RQpMVX/HxERERDBYzq0zqiGttWgsREREXjay1hZSzVTIWhYQiMrmWZVZCkVLIWiuoyCipj zKkEyUMIMlHkoCEoR+IPIOOmYirwQMqMKEvp99rf6af6LHBJlmD9anjCRn7zZ33qCI9o1u4QksIj 1yuFAv/1/T/rST6T1n8JNQ///435oGDQF/szi4WrNMwEjCLiMPMf//7//1+6aullmHfeK48iYYUE OdGZH95/61MOVdGcocFeDB68K0FaJQFSX+PH26Gh6EYzCkVpLT7XWDOChAy6/StBftfz6niqxoWE LXMFIcdrrYruSd4YsIu8RERoRERpoajoHLMNRvERGYeIevCF2Cy0ilSuZZ3PMhJmIhSOzDIKzs6E fHk0/yUKyU5hkJoMqMJnY52VLOxKEfd02nqpqECLd6Ld1edpBfvX3oER5aD6CbafUmxRmIljI+Vw rlcKBevenqnRhzuq+nW9GymmleWkSL///1t9mcXC/WRKLhUhqCI8r5/HOjr+v///+/9JOgRf/24I VaghWv/0Y3n/faXM5Q//ru/rTaXFf234+6vjQh2zy/137TgzSLBQMwXC23SGvlHDCUML8X/tVGWk WqNU1Q7Ucb4Qi2K9KKW/UYiIiLCRjxGRjwwh5uurFqjdi07KIiLTtcU7yussT8IiIiIYVcJndsvn f5CsheReN52TCFcCQiNFjtcmnZF+yLhU7IXkHpEJkJnYlEPPRFUmSoqCDa6+9NP841NQh2TE8IUm TYLy1wa087739GzX/qtqqLhk2EwwQrH67/7ut/Zy0Yc7pG7as8GvCdIlQhXWOvXv/TdORKLhTNlw kZoGK7oYQISnQ033NBohSuFBL/rr49/60vvi4pOrjTc3Utq30UoHBDV0nn+1P+esyP9r/pPQzud+ 0r1eiUBbUfH//3PYJkftXX/2y0i1WKYigZwo4UExWv2cvu9C0XA20rS+z6Xxhpr51JC48bW0x+9q 2latq/xERoRFREWp/TThio20iJgv/Fn6IjTsIMKK+1lckQiIiIanIuxRaRaqneudnRC8i+VlCIi4 89E0aDTXP5FwhC8l4hMgsdzyni6KjJYjCKmh7676rkP1Iv53GoSTIxKE7UmxQt7U7v/mv7+4Iaud QgX1KxFdYy0i1X0tytZjI4pE0cRdK29B/v70CL+lO+/P5F/K4Ua+10u4pBhCO1HImC/mcXCdI7nj S3O53r/ruhQ0P/giPeht/X///7dbkSZcJb+ix9Y1Gf4z/pZkQQMFqfmCKHr97//rq/20e833SVfR uZFwvoYroR+/Vf301N2GvW3fYSv/6CpWSHCfYV2rar++o+hqo8cWhcdrmgELg0I4M+6WKiK2OI6t Fjwh8RERERrHFw0NMIaaP9FcLCRERDBCGEPgzrrCk3IxEa0CLSClK5LHc2R4IMlpELRKc7rRkZo3 CLO0iQqrV0GEyUcNT6O3yOgpF8qMxHYHl8IZCsheI9dGvPbXpUI8/qmFtL/O+6bV/vC/pq84Uf5K LJsFZblOWkWrrur07u/P++p4oER/7vsmxQIW4pKPr3/9vxf/q7hl0R6unCQIf9f/0DXh/+/Ee/zj mevb60m1ImGEOz2h//1rrvc//GsNbqpnKHtrxX1U5aKBMjyXuo9iilBgigODMCoQ6HP9wrar8R/n Y0nu1ab/+1xFWcmTc44UkOUOF/3EZj5kaEZ/jQiGow0Ig4j3jDI6I9ERERER3a2OI5XC+f4iLUw8 tIrVTsiLchFUIp4RGj/fL5/z2ZCUXZKUelKtkfsIM7AovlOR27MZU0IjrX9NXU/pWQcix2thNbUm wv/fvnd9vq+gg2rzW2nJUIiNUM1hYqr9uq3+9Ai6yf90CI9pOlasGSsQrrGO9f/3fpO/rp+r9Gcp 88BqVwsSxHH/rDXquv1v6elcXRuhK664IUh/x/v9f+TYpOhnc74Zuz/ikvt/tbqm+1+/X7v7Syhy 4KHCn+xFTUbaTqtq2lbe3ft6xxxaEfetjiKKAxG/gwbnt/iIjjTC3YQaUMKoomwvhUP+TfkIiIiD CmREWkIL74QZWYREWCn/scrpf5kREqikzsXUEIjUrqvcEVIwkdl42wgyEggwQZIzumR0XQUlmXRB EYQjX1SVBosdnT5h6al8/oRGFsJ2QqJsVxbjSu+YZtTwIWjPQQb3SbRsf6S2uSjcJkqrr+mtQqen +nMdPXs8HxoER90cf3ow7o/9/a9r7//v78Unr1e6tIN/Idpmv+9ZvVf////v+t96e+5XCwxEV6vX 6rrXsR///r2/PR6uI76tQhxHavdf+qZHQIodfftwZpaGp2MK2lCsEU7CQM/3W9JvoIRH0Y0Pe7TU 0FZaWKBnGHOkI/imI4jkY6v/y0i1aEWhaFoNYimO000DCFhhef44xEREZkRDCDCDC0I/K6oglLPk IiIio6HK6xF87plv8S9ksTOiNQudmvmRVBBhBnWSIOBAzs+QvJRlaQiNb8yEwiLHaLHaYSNYiedI wzWIpVEud79pIINwg2hCCz57TC0fghk2BYlUX//zud9Oro0Kbq30jPmzepNhcKtlrCq/7r/11VDT lKzaI6Wq0mukb6S4/9J9v+9/1CEf24t9DN1AiPv/BD//rSOf//XHbt1+9L/tK17Wz3e1P/Xs8lc+ h/7EYM8ivaginDCtpRFGgLuFH4pTQF5hzjgiPwwv/a3YoIRx3xXuvQjoa/lrCyiItWGFOhTkQwhx 5j/ybCwVvSGM5ERERERaaF5/1EcREREWdSClcyzuedwjCIIi6MhfJYjsTxGuE7BbJQj+QrJYjEED vIkjui+ut3kpEBDTkE2DBqQepK2R8m6jLWBFfQIj9oER91tVRs3DIwIQ69W1GVwtG2CKHlLXW9fu jDnfN2rlwZ3O4aX67Bldb4TQjCZHCr/79b0O8J3EGHO53bvzvzpHKGV1NoPyMf7/////e/v5EmRw qW3azuHSlpFqjP8Z/+v4If3n1qX987EJf//1XEGHU8Ma//V6pfw0269LsEF9mgYqf/17//7YjYim UOW4Vt0RMF4YXteIX1Q+37CDRNjRBJfjjTTQtC8ehGxjC21ZNzjhfGojYS64iGCDBULU5G2FBPGD iI7FIQTGpaRYoiIiM6EDCxYW7CYWoxEjEIiIjCaqVyWO5kdnRC9Mt9PFrpnbiEpEILEEiLwSITNc XzuCKvJmIS0QR6NbCqSkQi27IIU1XTKcVNSIibKF0nmxIt4S+yKEXnW0aGFRvaMDM7JscMEpH6tJ 4QNTjmH9zWZ2rWgRH3SdEn036aSZXU4v/8cdp/p3CLiJPmAlfTz7y7nup4zPmiFy0gRe99bvrvS1 Vf7/j/amyk2uPes9We33Vf7+SHv/6+vjV0872/alKDAIMF/CH1xmEM/f+rPfowP6uuv87HDChD7W Fa88Nd70m1JwxHUUr7//WazxmgkPdigZ1IY4MerEcNJds966+/lpFijMi0IaaFoWthOHF2mKl0zH obVWlYX1GLiIiIiIbEGCDTCcXxFimGlelFoRERm60xTEVK6XldVxaEGgwmpXVezKiP5KEfiJAuQX IXnUZLIvlPF87NcREa6d30SoVU118+iVZiOwKL5Txf7/vPBbwrzXWwt9hQmnYXJtXF8lGV1lX9/G EHRGP0rQIj7zvf3giPK62uiCLgn7/9zunInGAlPX/31Toz+d7rsNT19L9X/Vf//b0vrv9Hfcty3/ K4WGATI4wUjiuv7zwU///47/9f94Qdt6LSLVqNCrr7FRe//9XS/r9f/uxgzSqJlhIcJtbbrVsJXp XpT9jW631f9vb7tA0MU8b8bEbEe7pMWsaXpa6FFpAi01hoWhaDTCa9hbFMVf3WoxEREWCBoGEIiL TTEbDCjNzluZiiIiLCiq5XCpMrjBhhAwha5fP6LxhBkti+QeQqOmdoMp0RqIVndEIjrVBNovGudO yUiaalOGCKBghen96eg4W11U9I0NT/rkMOTYP/903O93dGy+k788Fxmgsf0p7LcqW9V//9IbervG E7UIH5u9p4j9f/3f3f2xSyKBirf7vX/66H8a/eL3WWkWqDN21j9TQMWe+1Ly/6M5Q5V98t0mbNIb uwYJcaTUaN10tGcocoe63WIh1QtND+xUtynKexgzhV+OnEXhpNr5DDpaMPiIMEIiHDC5/06F1sUx TXCm6Oe4iIiIjO5Q5TxENNDzGxfffET6ERFpquTetHZghERGpXS4yQISrLvOxuOwcdipkujsTxlc kCKEMgudkxJBNq2mXyVxeCBlX0kTeuFYaNDC6b6luKZLIvkrMrknnc70CDU/yJrmzLHJj0m0CI/a Wj28tzEE1wmEHXvHG9ISCOEDhs1unrdAi/q36rzQ0/u/////13TlBEeqp3aO+0m0a2WkCK/59Z9R v9+uv6/hCP3/p6cf4IocWg0+znXXvv/XeYUhR3+luuv7UIURMF5qYsb8bX1t6dJOdH+/f7uxUjHM O+rWwotpRpOmtr/Fb6X9GFENTkKcj1N0MVFMUxFIR/hK/tJ1uIiIiItMINMJrF2rYjYYW64iIjOQ hFphMVEcrqud15kNxkOhEQwmEtT6O4FJoj+QrCDJbHdoj5HSZKovkZl0TNEDM7WBRGZHphVyUd9H 8IRGuFs6xdppkZF8hUFIRCP0Sfdro0P6W1+4ZnozsLko9FjgiIgmW4rkTilq28/996cx3zQfKBEf dAiP3oER69INre8IQQotwJXl0f1K4Uj/fx9/7fFK6+t6pyLtaed795/76TyL1prQ+v/q/c6l+vr4 Y//9k3ozner/e9r2z2Ey5Aih5hLrofgga/+/r6/8dJNv7Vfd0Zyhyh5SwdDQiKiP8IlYN9X/XRd9 f+kCI62/9PfYlOuI4VhNXP+1QIor69YpSJk7dPpEUDE4N+qxH4NDaeWOUOWPDMCmLDnXsVCdiNiK dKtBhb1a38EKcigY4iwhEO04iO0ItNDwhNAXYigZwshdMeDN2iuCh4iIiGEGEGENYa8WgZgVYZbl DqXClkU4REZyIjMOUOUPF3w4jTyul1FuHiNCLVCPtyuFAud/Hf5Coi0pKiJbF81xfKfMIhMoRRHR mNSUZzKmhE6QiNaOzXe8JhIJrrhOzotD7CkYi9DtSF+JaQIs9nv9cERymthbW107qnJUIdQnkqE4 MrrUQWIlFup4xSb73SaSed+gRH3nf/PBr1YRKKwnXhlcK8lImT5bmDQffytRcIROLhaqv3r173Gm 9wQIj4z/W0bvPAe60Xuuv0v116//W7+68F409CRRHER9RBv0bP3CB74IbSN3n75u9///9d9fv0GE I/6Hqsx+1UfFb7q/19W9InDH6w/dbrOiX13+H7CTJOCq/iNsLelfWq02tpTuMxk/DMO6z2M/0wQQ IoerxH/YoGhemvimI2I4jBmwJtJirDGhG2Fj+IUR2c32uGsXFqc8NMJphYsU1QPsV/ChRYM3f4iI iIhggwiETTQMIQeciwp/jwgZwr2hHJvNCIiIuIiIjWjdap5Nv0GQWOxIzsTR2FeIiIjOf5FKiLsw GQvIOOjhkJkL4zpkIj+S1GFQ+Dg0aJKK/zWKuiCEOwVMtzTO0mVVCWktrndmQRpN+8Jwlsn1h2ku W60KSll8IMixkdhMZbreYyPqoWn31tEh7tvLct3awRH3CroER5CKOzWMOmhGEWCF7SfzOLha53Tk UzYQGDGEHeIIj6T6LugRH7QTcz9dff/9uttppBvvIcOncJqt6ep86BEejP8GTLQd4RQ8wgvP10v3 RnKH+//4/rY7dU3/d1QiKFfV/HENhIwtbM9Mutqv+nV/r5MwhKAp2MkKhPx/+CL93VRBAhdqtnv+ 1/+PBQSFgzA1tcb4VbCjVMRTH6vTrrxmCjbVk+KHtC0GCFoajYqm2ljShrdRSxpghaEREcGE001M OU9imKY3WW5niIspEREaEOGE0whrDMi1EkRSkTLERERDBEdDkWQuyPEqFIVJkTicMGuL51zuvNeY R2BjINCOdwauFJUJl89HURJfPpU7IX5qdmR87KlEOgRH9EY8JV6zOTHhdU3XyF66nqyL52KRfLWF 1BKu5/zjmH/o3agg87239HffrfWp6XOzVH4aBLvirT3vQj3/eUpKu+RVc73e99e+9a/d+urr7dJl wteRKLhU9L7pfR32rwZOQ2/s9+7Ebfv6H////52Mi4Vv93uW5n79AinZH1f3s5uvqm0jfvS5/x3r H96/1iojCER+oM/UO0o0puj7+P79K1P9Cn/8E1Ix/FfsUx+6xH81N6zcx9fUEPNIECnIi4tT/aYQ tDtD7sRVes3O+qwhERERDBCIgwhraFoXfYjk3KdREREREWmEDiMsioiL5WkIMLk3nF2SmLslYtkd EdF0RQFyXjVF8hIg4g8heU+XzsdEKYjVPTCxESY0tO86hDoslQgXVMgUZERfO0h2p3dTu5Y5Q95n Lfq+qdqt5/RneF0yFxLc7S8s5C1/ughdGw7uFCD1O/efvo2UCI+/09Lo0MlQpF2gyURdndijVJ/8 a3Hszi4VLszzAVR3SGvvXN/O+0nC6qmF+qpb7er6XunW1uvv15ODrvTc45h7U72p3okPLVSLfT/n v7/Z+fq873TX/jv1r/2nSW/uecbHxpEUCLpU6j91Qqe7OYIVZ7f1750f/W76dLdRtBaVDYavaS7p r2aAvx3pIsc74jXb0v9/XS3i4a5nMPjFimtiKrwZgWxG0L73etq/x1f2e4iMITyDCaFphC1OjTP1 r50a2IphperSsYSjiIiIiLT00GEIiItNMVxTq18m34iIiIhhC4sIeYc4+W6UlO/RXVchEZGRFVxE RoQ8IZNFZKEfyFZCshUS8aDI4ycyPAmQeU8XyVEVcEGprYjpPTyL3/GhFHT10GaxDpF2i4ZKJQgz IMjtWyCWez46vv/eZyY6mfdhdFxXtBA2mgkW7TCYTIXF8hcdwopPvv30tQTdT5+d902jDlRpHfWg RHHCdGtzw4IjydkoCBMv+/fpyNxcKRJlwpoGB3Hbp/enoWl7SdJhK3T7m0k2rqt+tV9f6SStX9fX UaV+9qnW17pzHO/mugRH33ghQIUCZHkuf7SN2Y//tf3367qs2vp//tLug9f1+Ix8fq7rUEKfS+zy vSf+21tKv//f/sUDMWlDmLSKOFr/tq2lV/axbH2tquk/Bphda+hb/tUOGdZtX7FMYMygRTYSWlbC URw1tYjiO/X+DCdp6FoWmmFTTFTOVEVYrNAwZYGJY53OPtjUlAT1lusoREREQwQYTiGE0LQsKdFP YQi850xSTEVsREiSERERmIU6IiItTbOomeYR3GYRC0ZJ9MRHFpqE0wmmSp2dk4vkUDBCZB5BxKAp CkSnLeoURpe663muC5qEpNTJ8LQIFdHH6BEfsIER95nLHhCsKaRIkZY56O1MRFuUOEZJWfztS9Lq 91vX1CB10blBgrv0tCNr/63X/x7RnKiT5gJiGIVnIiaV9GHO/Pq1z17/X/9X7tNcGCjTLhb63YZH S2u/a/p9f/ffmy4wvj/iMyMq/erdf1urqvjT2c0YsSN9fbrfsRURURsaVpP/xbjrNfvR1+w1tOGo 2K4/Wzm/Qe3WyuOKR9DgwQMEwQYTQtDzcosX94pkJJaLgaMPiIiIi0KiIi6156luZ4zzQzDmH07v TO9chaInkKxGhDu4jYZ3fkXl5Bwsxc1DipWxMoYVBScmqHTR4drrl492SkQ6BMvn9NQnaDUheQeZ J8yDWdw9dP+bkq/nUQ7UVrot2SkISoQh+ZHCHZNl8ijRGFHa5TQMO1tLrqEjdmyvrugRH7hOq9qv +SiLs7PxcGJQIJQv8Qljtv6M5UfrdW5/SJDr5soER+6nj6Z24ktzNBfvwgsX/pd9frxne+9PW9W3 pTvCVMIIpYYIo4NiMII9vxH7a///t+P/+RLMBKW53O+xC0LDoJbOavd4Ib/df+lf+1pr0694KaCs zDmgp2zdCGhnQIDP93WvV1hmH+CH/4rUjH+vvQUIXoRaa/S/imUOZyhwUaUNKPvoyOF9K6Gf99P9 xEREZqZ/zjcXFxEMUx+xgzyTqNW19j/4i4iIsFTCDCn+Nc2xIUxX0F74iIiIiIhhMIcfY5N5xvJT G8lkdqqJGIMocIRFqTb9O07CDOxPREHlPnRmMjMwiMzCKkiWMgjOyQU7CYibQ9ra0WOzsxhWMoE7 Cdp2mQeEGg01MIjo2jsSl6T09BsEOWOXFadcLkpCEOtGijOwi+bERZ2MBcFInlVztDlutrq1tJ+g 26N2rnfc79L6bSD08jH0uXz+p9J0y4X96tGcqNP0K6+vc7lR3Vurq0bgpnLiCJv/1Rnf+v+l1sen ret1vfp993SGE4K6/6TcZ/t7pXX31dr//7deq6WIQXYROI/v09e1tX+3fc9vV6t6X5OGG6fvCCOe 9b/et32KYqGErdbVDhhX0v3+rW1jCC174jjfj00xvFMVsVEUxFdqyblDhEPim0tdtYzCdejHERDC F2p/hhBpoWKDiIQtipqUO0p4agz/n/a8RBhCIgwgwTTUjc49pp2YexWGP/sLxETaEZw4iMIkINCa Q/oRybOjCLchKIiIuIjwnDO/yFR2ri+Sg7JWRKmYzUEIWipIhaO73ZRGudmohKhQv2n3SkJGvC2U tyMVKQVsSPswYrJNgCQIj7qFW2E6NetGBTczqICGvp2dqxAQYIMlkXyWZhavRhzvnHO+d7raTaT/ qrwp4+szubmtqmWsLr11uu/9ddW2be87nfN9fvVG6kHSbXCbj//rtf373iq1roSJxcKQVLvHT1dO gRH3nH/f//f7S6ta+lb10H6+Kv9PpPe1X7bbf1fv6RiwMjj29s+nn7Dcamcpzvv/0/+xFW3XaxpQ wratrxV+T6Ix4q8O1xF3Pb6/X9Wmo+KYpiopinPYZY5Q4T2oQj1Dt+sdpMf/8GELCENBoMINMJDc R2Kk7MPacYqnW129W9YiIiwQ7Q0whcaYQ1P9iphynOOCI/EVEVGecREREXEMKhEXDTUtzNmI7cyC MlWZOhErgWIiIYIGF9MJ2XRVMpYgKdGYinzCKjNZFTyDiHnYv5bgcI6bRoaNDiRRU/UPcJpmsVMl gpoC9lYyKmiMRJXF87SEdqEZ4QM7FM7HPTpN02w1uZ9WrhUa2FqQcUNzpwq6YQaoMlGQsIEH+nV5 8O/ep+087+ftOi3KHzwW9kQd+1O7BEnraNbdtG55/VFwHX/138f9e1FbQQtDCDz5D7pK4JOgQK6T wnSD/NvAg9//pv9W/req8VbSb//RdxpetK676SffamPzH966/63f/917XV/979vtnKm+r0raW2tA hT999Oe3pz61/tbHQfv9f98f2Ki0otbSerSbCT6x2sX9rghWsUY9VvtLqNL7CQuOMQZt0FMbEUsN JWwk2k1TaU0Pb6bXW1WfeNYzDlYceiLEMJ2mFU3QxUw53sVGIMwKKoGOI4phq2lP/dLQi1OREQwQ i07CaENNBhNNCHDCaYpj+z3DWIiIiIiIiJVUHEGCYTCHjYqTaEXQnNxERwwoLZkKojovEKyVRfIT IVGvMI7xGEpDGJClP8a2hGSoVOzqISkQKmdYuwnZCZCZC8JBBkqaZ2JZlQhE7oqBEfdQSV1VN1TX vJUICc3PfCDJWRVEnr0bskPnfo3Ubs4/qd634SCJvSer0XjTUL/oZ3ul3jQpPddzvf5xzDwVqm6f QTz287cT/r3//+lpeZsuFM4uFVp0XEV/6bVvCJR/t+/07f//+l9Jtpf+dp2Rwv05E0ZrCBEfHesM 3v912c89/V9N+1P95/2/fX9f+mXChAuxFIf7prGRMMNpKx/pD2P/wRHGY47UZ//qYX/a+KiKVYiq CxHf7/htdtL7I4S6Vqf8Phgp/i4am6zohodocfjz5zQVlivQ3XH53GY4iIiI0IYIQwhEWhdoQ7Q7 Ixyh6Ef4bWIiIcREZSOPgxUtzPO4yFo7BMrpJzXiM6IiG+fWmUrImGCFZB5CZB5QiOjOOzUKQcU6 JIiUCiCBlUQi9U8vn+i+f9IlQhrSqQ9UI6JwwFL6aYQdjf//5nLeoIb7pIyeFslIRG5o3yViHYRl 2dpGR4yrR2ai7f//qE6N3/Z4Pj54NGCI+6pN7YWk1cyokwnf//IlFwo7dCjDniThV7FXc9DQdW9G 9U6Tz/0Z6BEf15uDxxl5btb9+vQ96uNJulvHvvGq6290nqxGxHU3V7+5hzDlD9L6/6/6///p6NBT wyMeHGt1bOdu+InMEO6RgbXa33f/0tf/i7P9n/9pEUDHa/Tq796wzdFWrZy17//tf++xSvFNKDME DCWe7SYio+0kOKV+gQ+4iIiIi1MiLi9MUhbFNLNZUWKV1jVKKiIiIhraannoQ4aZ+jTFAzbzGeaE REREREMJ5z5XS0ZBmQRlv2ImQcOIyuqq0wgyURJYhWQrIV2VRECRCYIGahlcLQ09Fu0W/PeRfVeG Ey+U8mCKHkKkTHYQZU87CaftBNwm663JQE4NcIUdQmgQNovmSyC5/slWQr706ve/pZGNAiP2vpcJ whWsPL5/UujNa/q3yJRcL3O53kURxKGHW6N9G70G1tbeCI5r/afX/vWuvbQYQ2RRJfQ0JE8wE+nn c732m/6+CFfdIbSN3/6wv/pp/67d4g2/+5blC7auuPkUDH4z/CLxXq2fVtTd1/9D/2/QdlDmknaU NKf/bX/nQrfqOGR0R4a7qN/zsJglEcR8aYpj9rBnCrH8LiNOI72wv/P2IQd+4aDCGhaxoetqaCh8 w9rYqazx2PeEGf4M/WoiIiIi00GFQhqj+LTTQtDQ8F/jERERERERHHFqVwrK6XFUTQjzCM0dmsXY QZFAwd8jWzEdcp8gZFTRkcU7VRj009NFjvOzWQfqe8wk1ITO56Z2fTIJl8y0VeqndoINzwW/Tpuv U/o1uzqITT0bmdj+EXgYXOxLBAyVkQTMIpf6/en4QdKd9PevpdLdpNrcJ1vTTCrmS33//x7pb9/+ n0Yc796fdXQIj78+NGtreXj2uI//V+n+//siQYrev/q6/V9tAiPv1b30v/9L42I+v//f3/O07LhK 6ev+lhl9jW1dY+1V2+dH71/X/9f//8yG0R0XwRQ+1tJNpWk0raU/wZ/2vd7ghUZSweyOYL+1N3// uyP6ERFE2EK+OxsU6xX+Tg/u2tfEd6Q13/+xEdjERYTQtBp+tMaqKBnBDnnZryFHsR+2FsJXpB50 YiIiIjMiIte/Oi0+xTGxGz/+LiIiIiIuwmE0/8rmSO6ISbCuIhhAwhcXqdmqUmmQqJLEqRuIVkHm oZrGVeduZT5zIzsREZXVQid5/o/kX8IZKRDqItmsRNO1L5Bc7HiSq///uqqjW0aKo0N8LZKIINkE FjODIpk9BnZRGVaO7dGHPHe+/0bkjdRu02k2jdSbSfde9d5hwZ2YnTCDMgVFpAq1777f+NDQ709D vVo8ep3bPh3dTu/oGH7ot5kUwTH91wwtr//99e+n1ulv72R0R0XQUQw6+E2EK+5SgwhoYIoeYSuf V3/X5ha9eut6/ERGG+zK0c1V1231O5h/ERVq57bOf32e2+7r/rd9/kIPXoIR1c7lR8UDNv4vP+o0 OOwk2seluvrGlrcUs6JFECBAmvutt2n/8GcFerHFcWsUxFNLdNaWqYQUc5HX+LCaERHnmp/z/YQa n+htNNbGLX8QTC9uv4iIiIiIMIMKuakGE0LTCGnahBnkRW1f4iItBoREREYWOxXHK6rnZCMIT+NC LCFqp9BOzsdl8lbI+QvILkLyDyEyXzWMhoniUiFufE9iPVdbStSUi5rSqQ+7CGFIVkrZHiF5CZCo ikiMVNBHsmVh2yj0CI/aBEfdAiPu4XBD1dGjUwUfmrkqEOoQlIierhB5CshWShGeURs79b16t/JD 9LfSbZ4Net11VOFM7ed21ZF+yLrtVT3r/9JZEouFR4TkUzASdzwygiPfdOKCbbPfzvtG7P+flW9K 9Punars78b///+uq/hCK67+P0t6FRUf0vX/21rbr6//vP/2+dyhyh/8scsf/X//2/te/X7vaBEdU vm79XrbqP23jiL/cIQbBDvvRwSR5fV97Hsf/8MQh/1sRsRTEVr6/bdX1rroRTfUM32crOeut+qq+ P9pp3d4r3jrBnUBhJhhKz2yQ6jUigYji20m0nUiYYBCiJhi1iIYIMIMENC0OLQ1sUxUYNCxSqkxU GCxTVW3URERFhCIYQYXhpnRZ/s/aDEJoGcFMVmgrrYWV1UhEZ/iIiIiJK8GCHcRFioQZ26M0QmSo yCR2JYiJtCbQiwqLtppkPVMIMlqLsiZ2d3l8hedGYiMy+ZHFJajmmmNBBvX0aGjOwh02Fv8LkLyE yEwmEHlRkVQVSLo/ldJae1sKk2kGwiMfTq/Ta3moQ1CIvm1aqT4UFTslTI8SqL5K4vkoZizsv/dK +np5/1aBF19OgRH31CVN079gibwRIfpLhbX8EiF8g+1s7SNFwxKLiUV/8d6TsiWYRHgv1+jDnfO5 306/4K0EmrVHHT+F6bBSUfnal996//X6VCP/yJRcLW/t/TZnmAsUi4iEXEXVW9He877rBEcP0b/d QRTylBgnB9b763+Ycw//7///1v0tLDEosX/++4RN496BX4jtNunSs3WvWNC9++wp//f691z9ncoc pyn33vr/r/oL9oJb+dGY8iYORSjjbSbVfbCVqo//+xt4q+IjcZjjMIiYY2v9//+hCCa7OfTTTSoX scRXsbEV9t13rYXX54azw72/9fW1g8EU7BFD0Ee1WIiIjMdyUGfP6YQYQ7CaHajdimc9iE0/4MVg xzHcRTHV6WlO4y9ERhLBCrTsoiIiIiGCcWELQuGhoWhDbh2mnjYimKwxUJDqOOZFWIiIiIhxDiIY IMJoNZmwZy2DM0/K5LnfMxlRkoCEpEJXHZJBXcRERDfMfVezUIkFCDOzEX0Mg8hMlGdlUdqWVUiU DEi5DQiL+nWcKMFGdrosc7o1iHUTPo7EAudiWg8JhBlTRXEMRvVo2ekg63CEQq6dHZgWQgKU9G5o vGSsU7Vo3EFypoEDqrpNWe7PdNoER98zU/JGzvPZohZnDHSbhNpppkok00TdkrRiIKztYzH63FjY /r2PGhvFBNzjndCGiKrp1dGxEpD66egQNhNBkUNMJ979L//Xb90tsECv+tJyJydTw6ndvvU490Z2 v3Wz2jBRwr/owPxr/r/fdDznf/uRNHER0tdJPCp533W0o37X1qznZ7V/7ePrat9/0vCYQiv+/137 FdnKzk2kx1n80BeOf9r3gyYpjgyOI56H/9L//pUuv7U2Y44qORj/9tK3yRrO5UFP44r4rb0hRu// //ERHwwgwo50Kf47FPFRBYi3PBTlQ5hzuU9e3CxS9xxW+t6Wf8/xGZ4iIi0LUF+ItUIhqbvVb79u Filb1JuMURESKIoVH8RYIREREXFxYQ0NTnQ7rEUMrpaMhiTMaZ2N4iJ2KohaERERERaDUrqnZ3OJ eIuNMlCI7I9EUdiAqkWioGVeQmSwiFo7JYlcQUQlIgj87HEOoSKQjZNyh2hUggbzoFzqjdZ2YiPh BhNNM7AoyFh/VKe8zpxB5nJj2GjZ6IXoNB4VtGd2je0b2QqCDMj4QZ2oRH/c7lRnc78PQOGHtQg3 NZ498+epx6rpB0e6TpOSkRGhqfSLyVLCH3SX9um9sGGI09N3Tk5EfXbIp9JPSM/q+zFTdWqTemgm +ul7f449rrv6EYuv7ZnFwlbavvX7ozlPp36fhE/BDtv/8JPv/yxyMf/6/6//r9b/ft9ev/yUBCUR HIIEeX//CF9j+qn5/T+v9rrfvXkSi4Wza4Zt0x8YSQoIJOGErXhpedAvFKK7f6xHdPXu3oevxHcW naZoBQSGxxQsetIx7q/esNLbC2rbfpLdPP9+GEIYUIZyywg0whecs40LsRTFTnsUxXFEUB5ubaj6 MfEREZzxDBCItYiwg0IsJoXT+GEvriIkxiIiIsFLpGgxQ9l0MrrGYRNDJfJZEKyuNpSbGuLCcQYI Y4VNPPqQwJkMSORpzOcIfUZCIg0SlkmjGQkpFxSVjKnCbISFZBcWi1CRU3Ro6fprZ0CIEmdJBphP JwwdrcRf0wmkEGudjsejP6s2vnmFN6RsrrOo4VHtrfhBhJG5o3Mi7CSLthQUihAgZBBkoFHX+nb4 QVII7EqrQIFebOlU7tc2kCI+89nu6EJJtJtOkEHBV0Td4T/e9OohIQQSq9L07ITQ7nf7/deKTZBZ Z7VPujOIVWCJRIuRfnQUgEDZC9G9/r+MIJK3/xbX2/6/73TK2C/X100rhaCvp19N+uI1CCP4QI/t f/zOUOC//v/pd/o4v//CLuIROI/uRT1faa6N1JQkr2u+tCP8VxH+/U6F6//Rv/4XFf9diKnPd0KQ xtJjCR0C59f6962r7f8cX+6w+H//52sHap672OOoZHSfG6s9LEU2Eh1iPqI7qCI5GFBEcZhTn/H8 OIiIzHzohhBhTAxGLQ1QtMVXzOUOVbmHJv2GFoMXh17j42HERERFFjxEWEwhGc+EItULznsVhrDH 0s1ODy0FuwjPOxNCIiIiNODCEG6B5IYc/eY8ZXS8mxQIRiEVITERcQ+I1iMrkghbiyIVKdRSUsxF RqdQhCZ2TTWIjVSVCI0FDPqRUwkkaxApA4Ro3daFGt02dRFQU6iRQjlR/9Do/8/09Os8CtFxX9y0 Ety3Gwwosa387netWckEM9hveue9/7/7e0xure+aBiu57nRdGB1/+s3pe3w176HfZyrq1//nCM8t 9DnQ3+/Hn+wraX8R8W2xzOcfvfn/6xsVFbH2e1t6F9UOIiLP/YQaGpj45uh3+viKN0RFp9poWhEW p/xERn+IiPyuqRNlNCIvo/ggZCRqIjCIiL5XNWRDH6LHZqEQaDXO5xB4TQe+EHVGyjXW3OoiLdoz u+V1OILJXP2rptHe+sJtIOWhbi/vu90h3V/1nHPEhUk6Vpt0PX7X/8rcXCq+n9Ol/a933//q2//Q Iv+f4ae1s566+rU/79r767+ItpR2lDSvoff2rV0ta/FKxsUxHr2otpWu/EQ1P8MINMIXpimKYq64 iIhhCItNMJ1WWgRiTCIWhEYigQUrrGXzuCO7MlpqdqZp2Zewwk4W0wmmCR1RuKeL5CZUYQwpCI6s x5EIrLILkLQtVdGtzQ0aGS1F8lmXwmmmm2dP5hynBBU+0EoTCDJWMlhEtMgkQXGgRf0nSdJsiQYI mGARKOmutqkIgiY8h3Tkty/5fP0w7CdpphBggyWEd4ZBD19XTdP4UanjO+99z6BJ96siQL0YP9IN zW0a2jXRoaM7tMJhM7Srr7r+zcU+Xh3hF3/S98nC1FhE3i+r/mNfSdJ0nSbSbSDo1tGtzQ5oZ2p7 9r//Ye2G////0PQX9cnh37C36q6um66dK0np0nSb/r2k6WobUWHjD//pVmHKHOOcfNYV/3hv9+7I ///9/vWldN0/29Jtb7pjDHO4zCiqb8EKoRFuhjOoYdIMPG09iI+v16/+911+8RxTGxh3wxbhONa/ PqeGX6hqxxGyb77pur/detX3+rTTCacPhprYoGZP4YIEnhjBmUCg+Gj+2k2tq2tpXV91//EGE0GE IiDYiwnF4jwd2g7KR9jYpiopsLatq2tpWkdgoYiItCIow5h4h8RERdhMJoNMUxTFMU2rasK7Qhpx EREMEwgwmmmKYoGdpzK6WhEREREMJhMLldU0xER7/LZUl7K6lEFr9WpbmcWZAn/VYIe9o3aQtNUM rqmLXxuLZzofldLyuFqf8rkghXF4IGRTOEW6qjRCNaRh6ppgg6N3SDfPfQIj2h63SbpBOWYj9//d X9v7bV9/DNzbYVu0rbXxxFMRTdpFnMowE4YTURWuf4gym5kuf8RER/8eVwrKP+V1SILluaIs5oh/ XaD3/yHHKaZrGVygHIsyOgvMOL6kSBct1MMUfLOfNBUFPZhyxzj1wgu7iPQi82HuIIm08/u9x4V/ p1tYOIiIj5ZzLPHFrYcbI4XEjacS2mdhR//////////////////////////////////////////+ ACACAHVIguW5oizmCmVuZHN0cmVhbSAKZW5kb2JqCjI1IDAgb2JqCjM1MzEyCmVuZG9iagoyNCAw IG9iago8PCAvTGVuZ3RoIDI2IDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAg Y20gIDEgZyAvT2JqMjMgRG8gUQplbmRzdHJlYW0KCmVuZG9iagoyNiAwIG9iago0MwplbmRvYmoK MjcgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0Nyb3BCb3gg WzAgMCA1OTUgODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jlc291cmNlcyA8PAovUHJv Y1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmplY3QgPDwKL09iajI4IDI4 IDAgUiAgID4+Cj4+Ci9Db250ZW50cyBbIDI5IDAgUiAgXQo+PgplbmRvYmoKMjggMCBvYmoKPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmoyOCAvV2lkdGggMjQ4MCAv SGVpZ2h0IDM1MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9CaXRz UGVyQ29tcG9uZW50IDEgL0xlbmd0aCAzMCAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0Rl Y29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCvnYRFlMlEeQHSa8 f///////////O1vj52lKP///////////5U1H//////////yA4UqWg0RaA0MleI6j/////////lkJ UWsT/xH5AdA1H/////////////////yzBdQlH/////////////5AdA1H/kB0DUf+VyhloLYvlcKy N52qxfITLXVqCIVoKPIJrWzqIMJrcMEldaLnR3uzQZ8kPO56O/Ru6Df9Btud7p/0JbmDI4XWvpf7 f/oX9////7mHMOUOaO19b3/ffbOdCI9knV9OtfjaFIe9imI4odjY8ahgmE0NMKf4xBhAwhERiMtL ETZVUs1YIvhSEyusZCZSjLikKiD5XCtCM1CFcLEVDJR+W4HH8tIKW2Z4VXljq+wg7HVTXmyjd4TP jt6mHfK5WlGm6GhNIuFFJ0ER/NMwiOKkG3lcSBdX9f3b00Om/69vO5h/7fUkP2/Mi/Z7c9ji/rGM EHt+/aRoC6HrYVsP2w2PfH37Fb1u93DCmPn9C7QiNO1EWE0LiIMIRGIiMsyeTcxyuVoslQQKdxF8 p4vlQiDyW5fK/aZ2eL5Ust1rI6lcVCIa2F0yGrC9sNbwQg4QczpdfvW9A1fCDzTdTZQIj7zvuldA iPvs7tAi6+aekHGm69fKDI/v15kso4i6SEGHSdkSzZqk5aQV61/63CEf/aYQjf6tDpsf////9edE Ev/v2r/7es6JOGPxn+mCW1jP9tbDBK1vX0u6vXtiCtV+GXHYpimIpiK8MtSEV1CYivDFWE0040Ha HhNDhgohhBggwQ0GEOGCES0lRRERERGWaJ8s4vknF87P2RrO3IrzzsSyCqVxdH5T6X4ZLhIZkZed kxCUSDJs/BB26a3w1CLh+tp5aQKqb+gRH35hw5r0/aLvSMPxo1urevKXm0ogw8PT7whqmyMy3Gku m91/Qjdpv//7Q+3aGv5D1H/X+oNS0gVbbrf5kbBLtQQqz3H2zoj2NG7etcQRGBXrjpW77Db3Yivh JFLBwy3KcLdSr37tNbQ8KbcNoRmyNC/EOIgwhaamgrrtBxES0gVRERaFoREYjLPVF8jMvkJndkVe aiJGW9xBo7Nc7IzCrhe01TUrpYS7PJO62tkO0aHouHl89L1YXLXVqgRH3QIj77pPwnr5Y5Q/+d9j q+v+nJ0eVbfvCEOrf7+r/f8Jghr37tmYL3pf+v//X2Mjij8f5a6hd/8nDFq1N11jWZFb1HaretPj 3dAy3KHlcKC1zdfqxFMRQZblOETQH+wrQulfXEZa6tWmg4imOGK3mcox8NDDCYVTDngocoeLCEaE RFhREWhEQ4iMRlcLRNyIg8hM6Z2Voq0azKpmRoZEGdrOYR1R2UIwiuOqZNjMMGoQ1i59HZ+yMQJp ktwqDTOz6pojHKcraSmmXy0gpSuUBdQVbOxwhDrBDRbsIaLdo0M7HCBeIg03C2Png10TjJPfX1QT awg6TegRH3ZY5Mejj/ejehp4IOjer5hzv3RvVPP9bp0Yc76b4QO2r6PH0Kt4uL9bv4/jT91vrfvX f//4/1V//6/61//X26tnuz2v2CZHHn19n1a/9/X/1/hkdEd3mgYJwwjd/iigQJ2sGCvVr/er/et6 4jbSVd9upIdIbaUcMKw1tumIq1FiKYui0gpdipfFPm4p7W8YOMscofHMPYpiE1G7FOxQ552mEL0I cRFp4QmeGFR/DQaFphNMJqIiIiIiIiIiIiIjIDoGpaDNEIiWGdgWby3SkdkZJUdreZJeMrhUTfoJ pnRH5BndJOzrm47PmSXKmR4liCkHGpl/5XFw4QyH96Ledj/8NM7cTPefwlghnUIudjhJB2kZUu6u gm94TdIER9f/dUltW8/0b179P3vVNow53T3egRf5vzjmHzvcl6b8+Hj7x7779dL627367oVadfWh SvLSK1F36666fv/7BFOo9fpW/797H2eQKR5QUwgvhTCX3X+0I13ps+rb39pv+sjHcRoRVqEI7CUU v/MOcfdZFUgYK/+k0gzFa8ri4eOSHCabSYTHpW3U3OhDsWoQj9YjEioYbprCUGhBnVigZ1aDW1HX 7FfG0sYlpFizm4Z/+1hhC0LQiLsJnRFoNM6LCGIiIiIiIiIiIiMriiplkxG0U7O/M7Fc1I4ibzZa 8Lk3V6aoNMjIvkri+UBgJ2VwOO55Co6o3IMhIheV8xyHN5wtoztGdhdbXsrl/yUbhC0WOzp5KLMj MTDSQIj7pB0g2tq8zqvf9mHoIPvWuZzu5hzvr6unne6BF1tM+On/7qeHV/2iMdcT1X/7//SeKv32 VsMevq/e87pvuu3///9XV9ev0u/1r///f8x6mP/evv0pkerr9NdL/q/6rYSVuv1te61BDfIoGGNb SCGCH/Gv2NJhrw1WNJjVtWGtLtaVhaq7y0gVSuVj42NCNCNimKYpigZ91wZ1CycMAzhZl8TGOhaY XtU0GF+LV9C1ERnIU5ERERERnIiIxEREZZ6ZFkU8TcrRkMRbjf1CDO8i+QuIPKfL5XGsKmS2CD5f P51CIsdrZKQh1ECdlcv5qEMjhSLtNP+qCDq50Cqqvdql3PctJVVfm7VkHIEX7M6Dm6jdRn9Ojdm7 U7/N43+h3WvWdyoKHpDQ139D3SX371/vX8RBt//8X+1fxG35frfH+/rW/614dM3WlbV1S3DNzZzv wQps5rHxGWkCqGf5oC7YXF1XqNDfXQzKgdpcf6EcRXrsRQMwPCaWY+PMjtPs/Z/1U/5lhC8RGciI iIuIiIiIxEZZxfK1kKRBohEW5VkwpaEtFXwZAs0BclDs1jBBkYRXWsINSny+S+VPIVkJkUy1nUtB Iwg9AzWFrtNBpmqI5nVkczI0CBM1iBc6NMlOpKO/MI/jpdncHzPp0a2i4o1vvvmtqrenuv62ZEsd MtItWp4eIdG6LPjq6eE3TpTvqd4ReUnRuoER/qd/e/9eP80zYgJO6T/vuvS3SV0NXQ19Le/miNhP 7I6I6Ly/0wsEP+//V9fv//9f+g1/iIj/1Jj+/1//9/V+r//1dfiNrFKMEDgyYTfdWut1GlHVnK9z 3usdAhRFAwM/3Hr5086BdWwraV02rrSxtqh2tNLVeDN21/FQmKYonDDHFVuqsVsR6gzApgfrLVJV FoeSGHVphW0Ghx5utT/aFqnHf4jBCIzIgwQYQiIiIiI0IiMRERGTYWRNy1HUQmwFnTOxuplvpnYr F8lLtMq0VJEJlc1i6NTMYXO06sqzKvJWWQdu8/k0Zdhb7RfNNTUIFtbBYMhEXacMIPTLVJVbddPf dBNvr7CwRJ8MEOmGi46NbHNZne9TvR48L39F5R3tpOEudwa5GOE3pPp3vpK+/usnS8J/+wibxEG5 hzxIqjdhhmFuSER0R0CKf3X2//X39MuFIkyOFxX/hO9eEwhx+CERHT/0P/r1v/7/uk7KdJe34RY/ ++/8df3TqKN8Z/ue31+KMdgl+M/zogggf50XS36N2lvVtYaWvx302szviFba+hXar2uKHd1YimKY YK/2rEbFUDHBcV3Ctin4q7WLTTTFC41Nlppw9DjUKmhw1BghEREGCEaDhghEHoMIWnBghDURERxE REZZwxRJQiqow5NgVFufLpBnXKznawiYRTmdkZ2p53WkwQyHkb5NigQLaNzz+SjshTIuj8Cl46q0 Gd2Kp/uRlgSn81CQq2k/7kpCJ6brot2uvIUoMXqubKBEfenvXV3nH93CDhE4/kYe+jZpNV/b73MO d/q9+twQd31c926TXH/7/rf6+np8bytsjhQiy0briWvyuv+h9ff/667HXrG47Pb/dZFAx7gh9UCF XTZ7UZ/gyZQcJs9471bWf9W3pN37rDBUaCn++jQU+OrEVDBLwZgvagzQU6iNkxyhyhgYVDx/IYVs 94vlrmqzdaYp9xinEWg0IsVIx7TjwSG1zDlDlDxtCDCBghGgwqDCcMFPOIjLBWIwhEYiIiIiIiwp /QxEZZyoyHlJndMqIxHdEV1ZmVRkrUmwJFviPxPk8g8wjNZ/z6XOsXZ1oZ3OO1Rl9BkLjueE0z6J Wy/71pGhqqf6e2qee+ltGhko+5oeq91d9J/r/hPU7+60CI/0H3pJv0CI/1f+n/vt/pbevrdfvp/r uTYaZcL3H3+3v/1t5oy4QpTLhF+r6K2y4RdvXf11+xHHH/vD9df//X4Na+1P7BDnP6dVvjSCG1P+ p/v90CG1N11Q/UtVVUVVL21DM53z9RnMP1/Hx/1dUhrvkY9vofhk4BfDCTi+7i7FNBZu/7GlDSZQ 5Y53XbDSn/GsXDQ+x//tP1jjxTGLQiOxT7FRoRDCEREaBghEd3DQYVCGEIhhREREREREZNhZFuVM tAXHTphBkFMjDIvk2fOwRHbhFJN5G3ILc5BMcMJoPJCITITIPNbL5CakTiFRqdkL0oMIMhdkK3/a CB0W7Rb8vpqahNc6fRjP5DnJUIvaMEDRbyU3ZWNAiPvTcIOgm191179V9JAiP9OUjhN28UjrG6vp 1unf9GHO6533V7vVkvIw53135/DDV74IEqff9P39GkXC1tmbLhF33/9OttLciYYjZForgi96/r/X 4sjoEU//9a/4y6X///1/fgwe1v/f0xEdT//qbrfhBkdBWIwQpr79Z0ZyZO9/HYYae9Y3SbVsf/Gv 0kIoPtfTfS+CTvVh5NhUKIsRXDWGkGf/3f8a0zdhDt8avef0FcMLb4TznsUx/W0xjsUDOvycGdSx sVXHCpin8m3qBCIaDCEREWnDCxrFoMIRVrDCEbCEREREREWfoiMS3CZF8r8hGTYpZqRvLorqQllT ZC5M7K87BUTLMhehBhOIYWGgwQZrZfIVZBmYilhhMhQYOkQPO3ZfKjCBlSssd/MChoztEx2tkX3g 3+jGf1z2Q/XNYiLHfQQep40VQ0g3CD73wcJ54Lfqs0Fuq7tWwlCD1puvs9hutK0d/Vzw1vhPvtQm 76538kPV//2xhkUTvT93uIN04q37ik2//8726sicXCV8a1/+v/6e1/v3X/e9e/ejKZON5jv+sKdE FtbViO6Q0y6Cv//VI3drrRChu6W6W+CFIQnrw/4QivX91H7aTDWz3CeNYYViKqChgraTN1sLP+oi u+GF7xTFR0qGxWDOETFMU7sV4M+z9jNAw1w0GFwnmHhoMLhBhNDTQ04YQtJi1EZsiNEjERaEGEIi IizoQyb9whEREt0IjeQmI8Ss5LYyUJMqBDUJJsC4KVyXNTL50OyEwgzs8QcdMjDI4pUI7uL52lZq ZfNbI8QcS7hhQpB5BaoUrhYq/nT0WOztwh09T2hlO0wvrq508hhbmgpOZzjJKGtwRJ4VAiP8J+0E G137RbwQpfXX32U4OhoVdPhJ0SHVd1e9c3ffamzzvvnfc7/5ui3n/P6N2p3cmwkGAi7YzvDa7/+9 D3dDVow54rudlsXCrul33WDDL8cdClvX/6///6fV6+vXr/+hbj+/8x8Nf/W6wt5jzNaof+36ujOd /r9a4Im+ZyhhgfS9PGX/tvp1BCnS4ak4YV1tvb6HF2+m6wQ1IvhBB6GrOcaX579t1GsdQwqklBdq btpPrqvxrFrR0CxC8/5/NAw6/2N42KYQM4QR4M4PbHxTEU+xTFAzg1CWOPa40JpC00GF85HGmELt DTCa5wtP86I1FxERnRERENBhBghERERRblD5Y8RG4iIiwhGCGTYyGJZmqOwNCMmwLoMrhUQOIPJe KjIXkHEJmuL5UI7E87BTLojoJkHnSIFmsUqeTO6Njo/nUJZDaZ0Cko86eU6ULkYk7QiO89nRhOyW 6yDtYl0g/pcfd7ghrghVTOqr7RrkpCN+m70btTOd3P2v0px9r1Nnvqd9N81njJsJBj38SeLhKV99 +53PDV9GcqJ2DRs1GmzQMP0lrow5403dfvdV/Fv//rfvCYQ/7/967X80FOd/ofU0FP6116/vX2+C I/6Lcpyoof/+9b6EXj7OY0PGlghQIf2/X4z/9oRfj3W2+/2vP80DHbSnQLVXf6v/dr3P9pbSf3Xt PLH/fT9AzFzBLFMRXH7Ff+rHxxQx4IkIedCHGpwtOO0LQ00LQ4tMIWg1EREREREQYQYTBEdCwhEQ YQsKTc1QiIiJJEMERWTUxvUUO5NigaDMq87Fcg8hMhMl8gmYyF+VMiZxkrIjCKvOmQsKaovkGiry WRdU0bpkdhM7GtSH92Q2mE8lQkNOiQkwnqfSCWzpBB2t5rpNxZ2TCX/prawaNby8mjW5rfpzBPp0 uWqSqldPM53r3XSM7nfo3ZnDp+um6f90CI+9TP0d9jp+6Sudzx3NAwT5iBFD6rXehEGGrf0ulZOj jVvgy7r+rM84iOl9/f//16aEV71/Vf++4TBD6j/+kwQjX/XX1/aotyQ+oIj//+F+I9da44X//1+9 vj/sEKaFxn/Gk3q2eyHJWrvV0M/1Rgf48Z/t69YYV1u+lu7aW9IigYiCbSBm7DVtfm5ufV6TS/9W KYYSaV2KBmT+vViNYTHVmWBhiv+yOk2I9e2I7TFC0LVDQtC0wmdGE0NK0ONIRtDQ01BhEuhYQiIh hCOGCFmOwwhGgYQiGFERERERn+IybGjJuN5CZ3RFfSIviMmwlggZkIzswZLSKvh2RCNIp8wkGd1o 7VAhCKyNZ2JZ0yTzCKlcujNIm7Mj+mnZ2axc7kYYoKsGmksMgxDsmJn9OyViVtNAge9Gho1vVYIj nIWleQu6Z1GDUL4XC/furSbSfandiGyDOeDXQIj9sq36zuGi7y7/OP0Tv/p/p+ydG0q7hhhIaetx SqzkjOVEQboYQ373CG//v9OEIqvkQgEra+EWaFvjpd629LfxH+l5j99df/71r7C3x/vfwQ7S7VGR ushoIvIMHq/gwbU/5wbbch4QTnuz2t6WfUGf8dNqraXbGsQs0Vt16R1TY9/8QozsQGJ+v5FQx/DL 2JiNsK/SULjbCsRpglfZ7eOEq7xGuuc9pWIQ0PC5GMFNRBDxi1CmzMfWwpj4iIvOiGhF2oINMKWv cMKmg7QcRDVNRcREWEIjP8RERERGIiMspPOySL5rIqedwR2hEgzukbzslM15G0QmU+XR2dFOZVxC uWUQKumSn0yFxrk1u0Gp9LhbJTF2mEGaxeFXRrfaNbJSICHBE6rRo6Z1E11TOm80UyL3Rd0d9pfp a9J02k366O+6ndrpNouF3hCu+/087lRn9er070jDnivu+73ToId/X1e/arqNkc0q17uvNGRwq+kv 13v7b+6MLXqu3iO9+K+//uv+tVufXq/YIU322+fUkOYduvr7hqbr6/gh+57BQuP6sJfa/k4YnPtK 1m7bajX9MaSVrHFVYjQjZQ5sCJoDvqvsbaXb3XsR0rJjmHCYaSbCzZaxoQvFTOUOYfJbQExTWMY9 Dg4ixUzlQgZ2tq0HDCmg93mcpyhyni9CINYtCLQhhDhqheoiLQhxaERERFlDoRERERiIiJbq+TYq zCMi1HYGjCOuVTNo1kQVGEVLMhiO1VEbRPkCEIRFSRKzhVITUJpqfSaphOyKBghWdmHap6moQlbT QdbOomFfTXRcNbUlHa6n/y8ekYHCGjRLXHVAiPOvBEf/QIj906BEf5oLdLrb//6pNjqucc79Ltvr dJutxhBt3nf30tU57RvSN6p/2ruZWy4SvekvrX0v/d8zZcI/xuOP+61vX9D///v0vgwvcR1/9rdt 2p//Vt62r/eRPVW/Q2kbk6MDn059X71/G9vVG5fTaXrpRFelIx4+DMOUPojAxJDt1sRXa1cR9xHa xpN01es/+6EHbPaoZFAS0MUNMJraYoMUxgz7FBFeNehzDlOdyh+E7TQhoRDCDCaa2ELuL7QiLsqe Sg4+IiIiIiIjP8REWU1xoRGTYFy3EjJNFQioRUsg8qEZaM7Us7L53DJPITKdGEVNSbFSBFDzIrjs mjDTTIxBM1ikrQKaBgp0FIiTyYRhkVDBB4QZQGFCdpwQjMhQQJpo0POgUKCGoIZ0aYRbtS+f0HeQ 60W7U6hFyVBKr6T+lzQaPS03X0jj54Lf9B5oM6VbXPOjDnjCnd1ejekb6N8aDo3anh0/9YbGEH3q xSBuf873RvXGn9LVzQF8aHFK6H9e/S9b9XrxX8frfu/T2/3/7Gt/XS/3172z6970vnRz6c+s/3vp b5jj0u8Jl0r/V3rn1JsJSDI6C23x9r2TiggScGCZFEgwRQ96hmKNdcOxpdIRVrahFDhl2/UNaERv q0FbS9CNDQiO1Q9Ya4Z/6tq1aTaghHGsXkh9RTXFD8jHyMexWGqiPwwtigZ1IUxUmPYpbBFGLQho NNTkZ/U5FqbotKOItbTTCKNpn/ERERERERERFlERERERERiMm/oyOjK0V06JuTR1R2HSbAkqZ2Ks jxTpMg4g87pmuLxCZ00zsEzLWL5rZfITO5wVSNYQcmwtudQme1cEM6hCHWTStc1iqesvn87VwTC6 5qEzqJIOc3UWO/r2uqW/puF+lXVbXV1vtBP7n9Pzvuf1OOYf+6M/RhzD393IPqeHO/nfaIx6o3Wf Dx+g39RukvxVp63626p7f9Nf913ndOUqLhKFf3X9Pf79Lfr+v7a3r16/X//03b/9dD9e23TXX/7Q piPbrf29fb0bnf6q/BDhm6Ye31DLn+EKBCm+rt1DvGvpfV3j7ZutcEK11HnqNY31+NXdZubN0db1 jV3X0N6aq0oM4PWxS8UDNuZlArivd2qYimK4pr4xBmUhXZ+QtNM/xdp2hdpqsdhNC0LU/2naiIiI iIiIiIiIiIiIiOTf0ZJ87E4h5CMxEKR27N5KyKnFfMg41EVKIVkJlQiEVTI6zswKiCB8lME7uyoj QFzI0FNAwmSsQlCzqEVPadhWHTqm1hFw+gujWwt2udQn9F5kxyx9XU7tJ6t54NdFjlD54LjTzXV5 oWl6ehhBw2r+9XQcnWNNwhEYTraQ/QN6M5UZNlqLhPqv+l910y4VXXb3evzSLhf69q2t/9dq//uv /eP/bcNT9BCs+nrdb/rWp/v2fWrpWeQJkcdtT//j+dgwe/tJjVtbof1jb7UiYLxR1CD7/7ZQ5nKH BBOwosdJRTa6w0uwkThjYS/2scaEZZ0xTCHDTFU4YqaCh7Fc3lPBnBmcoxdiouwnDCEQYTQ01QuG kTo2haqhEaiIiIiIiLCaEREZZzTEZNhbJMy3To1FDI0iU5GslZldVM7RnRmM7siXRSRKPIo59WZI zDOxOCpw01LouzU1CZLGXzsfMNBndy9kLkwmR40DClfRYg5oaaZ2rn0XDh7EQYQ0W7W4do0Qh7kq CI0Ql+ek7BEeSd53fb02U58hB30G0CI+9IER5JtYVpU3BEfeeC4v+fE9XW+604MMwufodG/XX1T0 6N/edzvSdJuxhPv1bvevrM4uF+M2y4X+hJf3/S/uhXXvvX228yWAxr/VL19ddJW+0H///2/7/vr2 CKH//W/BCqn66hF3YU3X7c+mD1/bS+nPev/X06oRzH21e6Y0sV7o6DcavS427r1jW1g1vf7W670W Pe9pC2rSsm53T7YWrvhqKh42Ip1bVC2K720mI7SaP99imKHDiIvFQWOxUw7E4GKYVMVLHTCdjYph MVXVWmhaEMJqhaozVhoRYTCP4MIaaaaERGIiIiIjOQhEREREYjJsC5kWIyBEdnynRhEOMGVaNSK6 UiYjtUMk87g5XKBna3gpkLIjpMyT1ncIEUPCaaw01I1nZ87W8Jl8nBcg8g4hWmRGpByZX9QgYQwh H4QjV/OoTP507O3E16NQjkXrRoDBD0Z2nCJDlD86AivqvU8NdVcJa3PBcV/Sf0n8EJzRumlaN6VU YId918/7f5xzD+d7jCdEY9d6dG/VBuqXQ85+JlwLmgL6W/b4vv7udgkXC/9zwnNIuFf7oTSLhPMl gMdu/v//x+Gvrt+vq+v/9a//Vz6Hdz6nRnRbPK9dKzyQwoIoe/8/X/X7pG+RTVb7aRu/Md2GlDC/ BhPfeGE36tbTUIRX47+r1bbj8RTqwzEPdq/ikP0PXWONW1NAXZ+v/8aUNX11aJCikP20r4YX8w8c XVimK9wZ90xjsUxXFDhmrFzDx4qqs7gp/i7n01TP9hMKciNYtOGE0LQv0f2g0IxERERERERERERE RFlERERln0R3xnZZiMspdnYEkGVnzs/ZK4m2IqSO5xa0+TYFwg021giZagkdMIM1ZXDiIiok0ytg uQrMksUZXC7mdyDoBktCfnoFkEDLHan8yS/OjTyUBCUhKJRWE76Qds6Ncw/wiT7QQd13pPVZnLj6 J269XPhnYYc//MW9AozWZ3Tdv9TxpG+jfhQnd0CDcriqI4IdgkYCK+7siicdrInFwt6LvTv7+3+a Au44j39PCHa+vq//tr/f9rqv1ur/9mHIx7U3X/wice16n6EOH/+h9P86N76rfxDjXav5oN4ZuiMV e53GX+u1UEOKXyKdm6GbtQQptevdpWtQtD/m7t3au2lN+te0I47Spiru9MUxQwvnRa6rPmxjFPgz q1VerFAzLwF6Fw01Wz/ERcXEOwg0Pi0LU5Fn+04xERERERFxEREREREZNhdE2VDemVbMtEczsVR3 cEGdpBRO7iulI6ohM7IZVFK5X2g0HakHGuL4QYRJ2SrKtl9Mq8IM7yL52lZCapwZC4vhMjGR9Mhf Tg0WO9ztIEcLaLdwQbz+ujc1RY7C52SCmoQhh5Bzgwui3a2dQhKhDJaM4+dpbQQeFa6BEf0E2k36 6TboJtbCpU3NANbptJ1STfhh1e6N663p6f533TrQed7ojHokPm7NZ4jzvdJ0CL/P9Eh6ND7sMv7r 4k4Y/X9vS380jAT/53Toz3rpuwgv6uu1FGe9N1qP/1X+/tf/wvr/77Ytrugl///29u9hFx91c+pj /3q1Q71/Z3O/3/7//3f/+nf9t+drIoe1uoadO+tq6q/UY4vf6//q/gyZR1ur+Gbv7YrwttJjjtY0 rShpTfjW1Vwt9bf+Qwtrmmt9NqxrH+w26wSsVStOxTGxT7FTnTvFMRvFbHCYoYgmI2KYpeN3vTtB hTdHaDCDCHa3HaYQtDUytQmE01N0WmmoiIiIiIiIiIiIiIztgyLNNMtwiErXJsJotwqMjVE6BETf Fb1PtUZ0ziIyOxoQ7WlK6klIplclggyolTTKeL4QM7NUR8EUPSTTQMqIKS8QcQmShp08vn86d6LH ZqCHasLRePSN7XTCERSLcpP0zUJMXP86eahN7/f0gnVL9Jwto1uWPhDTaNda/cJVf+t7p5/zc+ur ne9Nwpsdnuum0buf++5IfTyuVIwgv/lcpzYTbUd/9/yXW407ZH13V8WP90Z7/K4oC9/6aXuPd//o NdeI//X9fb+rEeujOVHUv9sRWv8N1MJ9AiOv/mHKHBddP/5iLghQ423XDNyTw69WHdJ/OEaurDN1 CIIYIf9r8M/v+GucBc7VhQzc2wt9Pa1a5mmGErSjz6qv20v+DOuSrQj4VbFMRlJxGxUbFMUsWDOE MDxsVHFrFq50UYaTTQ7WwmpuS9C01ERGchCIiIzogwU0FDxERluU8REYiIi0Ic7EtoRllSZ2TRVi mQqM7mhE7JiDK5WR2Z5kNER0qgpB5PEDi+SnJOL4TKvBBneEdquVmIPCkri+VJHRmIqXTsIRSnqY Gfnl8/ryCB9F4zUEOjI5poOz2SkJczlDhLkrgX1o1upY/6Xrwtw1tBN/aNbRcOtaoRWwh070n4Kb G/n/f+d7zWZ87+nRu0jPpuE96Ny8/oER9+r/Z2C5glGnvY3//6d/f6Gq9938SfNoju4YIofXo7ni rkTzyI+pXhd00P29ftVX9vX///XvdMIRTEa/++mCEaD6mFUznHroVMOUOCXYjf17///1MJ+P9GHC f/v34d6TGhd1ToRBDf1dd9KRR9nuPuk/WzkM3aH/+1Gf8MtJSW17u+buZqgzfvq6avWOOl1q1n+R MF++9K2+wl4ccRtbFbxnTfYjYxYjmHJjgiPbrEbFd9chSkR8UxWpXmqjTQ/jsJphUI1P0WlaGp0R raFw0LjmQhBghmcoeIiGCERoRZ0QYIREZhyoiwQjFxoQ0I040LQxMvxERLd4ROxRHZ1K5SjtLMx2 ZE87E8g8heQmQvOmd15CZ3TO1UrIQZU8hxEZhKFpmae4My1CHasL51Cano7HEOgU7cRM6sjmdYuc NPz2EIylAuV7uFp2UO9L1/VVRrcesOaPWlX3SsQw0bM3fm7vovM3JGyk87nh1O7Kc0m+9ng+Oez5 79YYZhJD5pmyUiebwRQ+hIolvhO90NX/7hhmFTkpRHSvirilZkldW+3jcW7Q00I9BkcL1iL//17H 5EwXvq9zJYDFD1CLf/Lf/XF3//p+EWP/j/+r0dMJB7OSjCBxn/ZyGf6ue+z3daWxSnRBIPrORW/2 c7LSBVmcw+GsQuM7Vhf80BdebqGdAsbaxrpIQnv+f7pWvjxdioWqC/9+vSWKaVrhbFa+xTFX6w1C 2fsw1HmPHF5ss25n60NDwtoX+mmmoiIiIiIiIi0MIWgYIREQytigQYQjERERHK5YjsyzCKMrreVn IWiK5MkU+XRGEVxmRXInEnlTIiMwioyny+VLphO8vn8yqaIOgscnXJRpqXz+S1JhYYTOsYeUa0YR nqf0wmnguSsTr+pkcI32FX/JSIvNHCal+/TV9Gtq/6+d9rulLgzup3zdd/1QIj7pBvmf9f/7aM/0 d7aLv1/+dzvhO9JdCv/O5Ua+uq/wRT9rvSeu/+E163fVdv//f/W//v/8zZcLd03v+5myOFX8f/Eb +v//sR+3/1+xG/EaH/r7/9vV/3+Ps5EUDDv/9+u4z/D+kYuqGf/rZ7/0DP3+16UnDFBm//eraxSg zd1DNBTufra02mv31H2I/42MXVSUb/GxFRTrV/Q+6EcRXsRr2hcWqHmP3xaaaHehd6rsNDtM/YiI gwQiIiIaDCDCEREREUZCDCEGCEYiIi4iWsCKWwWQkYioRb/jJsUmW6dELRGZfOz52JI7B5l+QmU+ XRVonySBFUhMhaTlcLkGdYw0yL6YTs7cQmiP1mcphH87VRTUIFtPKEkThgnDBqETh3RoeF10nW/h 64UKFvUv3PXUK7DLSU16D8EX/dAi60XnfYdei8zZgiPv1+zwfLPBrzZyuamPXqve6XhP3gw/4T0N fX9nsVcaemlDcrigL9/lcoZcJ/fidS8zZHChg7/HXzNlwl/HVpXiRNlwrIrSSl6/76/wRBBfXhtj I7X3/2I6/99cxF1MceM/yJhja7PYRKwwQ2FP8MOI2z3Z79Q0jc3nBvvs9tT/CLz+62lVau1jQIG0 h8MGDLHKehk4YvofDN3bronDA+ZJQ8tIrX4j1fIvsRXCBoMtyhwXhtoQ+rEdbvZyhhJjX4WN9RoX 2p/iIcRHD1zOU+aCutD1xsbU2HiOwuIzIiIgwQjiIjQiIiGCERwwgwmhaGntUIiM/xEREYiTYGjs uYjLQp5FEVCUg4lZ5EkQtFRlcDRKY3nZNEby3/ldSztUi7ISMqRhqXRmjpp2aAuaAug4IgQhB51S ZOGDumdrcQ0mdEfrs7nJn0axSDlPrqm8dWnv1SNDwp0CK6nbid9+/qpDt0+1O/ncER7/+ez457Pl IPmDMKXevmg0QlSuvCt/CLu7+WaCr+39P794pOKTdfScJpGHO/sUg845n7+6vv0HXtxlcUBdLzNk cL/f+Zsjhf772tRrb+vds7LWRwv/5W4uFvoX3S+l/+xH1Wt//7/9d//77/x36F5yN+M/9fBDGf71 11Ednv7BEIP6/Gf5OGCcMatT/Vz6BD/saXxSgzOVGvtbVteP6jv/+quh+ZynxaSM5Q5Q+u0urq44 MwPsMJMMJQwlNSttrJDgmGEu17BmwJlDmUCtaFtIGbAnEe+OLj09DsUxTFNNSxzj2owaFjdjGsRd xfqZyn47xcREREQ0Gg0IsIQ0LC2ELCF6ERFoQ7QjERERERERERLWUlLOUo7ShjK5bFuKMxHYokyr Mk8lDMSDKlmpHMjGZHZgzsVyFI7gzsWUIMy0R687MCHSLtEUQGaxNsIvGQkaBgIPCDO4Zf4Z2rCm pl+0GVEduKV7qLHa+2qpsGjQ1+n0qtGet1MPSX0W7NQgUyMxKCDe9aLvU7yINIOi806TbzQaNOkG 4Ij71Ty4oER++EHVEnhLT/TwmqS1rQT1dOopN106Xr3Qet9bRhzvn/O531v/UfsETT7cf80i4Wn7 7//abXzMF6et1H8tJQv/7/T/9f/fX/40P//9v7Y3oEO1s934MH1Z7vtWp+/f1/++syNr72e/99Px sedFbax2raQq9pWra26tqdk8jj+vbq21hgv+wrJuUOFFdBY4YSVimGF1YaQYq0mIqGEghUR/YXvj 7WxQaEQ1O5Tx5GIGzPaYoPsbTG0GKkY4TQ7FNRW7FQwnGhDQzEwhPoQwQiwgYQYQYQaZ0gQhhC1P 6FqIiMIRERERERERGJNjLLfSk2E8ty5kmiF52SGVRFO1JRlUMiGS7IKMlEbzUEK6wpXKJShEJmSf TNQQlYpBwTKjKeChBnZ8LZHiOiPmoUJoMIPTtIqWZGQTn+i8mdRNGhqFOoQpUQ6Z3hDRb8FiIhhU XDRnaLeVLrnU6//S0m5ronFYYKkG8Kgm8ERvYIjyJxp0nQTfT6SV/d0Yc7+noPBB53O6YhJPzdp8 JDPltAnptJ6cin1dntEns/bf61tmVxcKSu/8V2wYLzNkcLQ9lKDCNjV3cf7/940Z97e+LI5frkXC +Pv53G/X+q9frvX3/+48IbF/hqf4Iijg/ts9/Y/z/s+upkYNfWzyf8x/G2s4X/4ZY5xyh/4+idHa nQKh/2o/YW1+Zxl+94YIEnaVr2vaX+ZGSI8FzfDiO22urCB2wkgvtK0vjYa14Y2woxG2FjCsNKY9 is/94Qiv/UYuIsVBEdSxyh7sbFP7FPtA8VxUbH7UbscK1iIsIWFOFghBxaDCEZ/sIREOGFP6DCRI cpzjwwqxxaZTToIiIiIiIi4iIsoiIjP8RlnBxN+QiIjJsVMyF0diqN5rEIRHZPO68yShCqolGQvO ZKGRpEsiulKVyuCDNWYlKlmGE7CnVJyRpNSI6MRByZBMKQdn0dc3J4TIQUIMrqmCBJ9Fu008/prt zA7yESoQjOm6N7BD9O0+5naosdhCP0HagiPfUER6uvnhkoBJoLdf03v+gRHqdJ0SHaCDr6tJJ76V 6ez345E5MYTc/e90b/b1T1+b0blTc/+r/v9fsfYRYvZztJ9/XoTNlwr//dfQ/j//j//6/+xvqv+w RQ9f6v7X+6/r/ejDBhgx3/Cgih97Z9NT/Qjev7TVz6fs9+6j5GPj9aUN/dJBCOOGEx9Y1tYjhp2t r2wrQWf7QVirPbJDlQEdpIFXbCnQKwtD+brpMVobaUfimvw1tRg0IxBexUIGeWpj69+tplI1FLcM IREREepaXYTKCRGecaERERGecNM/4jN0YQiIiIiIiMRE7A2ZApFenLOpInzutnZCTCDMqpZXFIt1 WJXF47JsFwgzrGIlkFgiYRiO0aLhlSggyUNSDzWyPHTKpF8r98vn8txr0+NS+f0W/CaG4TTO7FQQ N6LdpoK1dT0FsyMxNfurhEY/9BBvgiPKph1YWvQTcERx676BEf0v/oz+f9f3VOjd1MdIz0Sdb1uk wtGfdvW6JD//0t435EVP/Qu19XO9tbIky4Sr8hsuFrd/+d77/9/YzCWHr/q///+v00bWl/a/+3Yj CZHH9NnuI4P9ez6df6+3pqbvX21N29UP//obdaGDLHtt1FK2sRx/9qPdra49v17r/Bm9yIOCiK2j +VdDC6oatLd0wwlWw0ojrjWf7EV33oGdTyQ/xYoNezntLTGxvse+xX7scXwwp/iIYQjP8RERaDCF oMKdERYQiDCFqIiIiIiIiIiIymRRS0aIlGZEiIyK6gUt8RM9ZXUs7VcxEJGRDI+SqLoLJFyxzBDh D6ngtSNUUOU7CDKjJRBMqeakYiojpkDjsSrIWGOVyn1TOnpWhHBq5qENQia0EI0WOzWLR/RfMlPh NM1BFPRD/Uvn9KQ7TdfQIj1ur88BrqtXqgg4W+E33Vq/vXrNBb4fuqetHfz9HRn2jDndIw530jP5 /1aJP/fekeM/9/63aQTc17//e3e4Rda+tut+rImGMd53u///4t/Z2MBe/Gnoo+//WtDr7/////8P /X/tetvX/6Wl2u12GH6X39/U6Nnv/tDXTBFP/s8kNQs6FEf3yuKhiNQQ78lSI6CQYbf//x69ra/8 YQio+01BD8Pe161hMRQQjJRhY126tumgvxtpW3U/+mgpoC83WF2Gf7YSEEoM2zJUDPIRhRBMU8bU bW1rG8fzYVcGdWvdwZ9gS/jC3EdhThYIMIWhaERdn+GELQ4i+IzkRrFoRDVaERghEREREREREREY lup4yyiBDsCiTzLWLcERBciIg87EuVyxl87Ss65iCkLwgygMEJmtkeIOIXhAyEiGZiNbI+U7I8d9 JkHnR2EGCDJbF4g8EDOz9c7U607mWaLHfq50+0WPOv1q2Fzs1aZ2phV3TRY7XIfprX/TrQQbRoLf r70gg2r069PV71aNmEG1e7mu9Gfe9Iz2z304wg+jPvvp3/Rn6BF+6Rnzd6erSdAiP/pN+t36q4yK Bj1szZHC1/kTDHf1ft1/V1mkYCfv3V3T7lbi4Xr/9f9f+///9a6/4t6//9V//3VQRQ/9GLDo/e1P /1CBZhJTo9Aih63X1v/Xz//+v1CuvPBT/0CEUx9L2vQ/fQQiNe1Qjfb9uqj1H7W1vt8IVdDi+1Wq Wz37aTDX2I2F3aTChhKNYtWgp2pBdWGEm0mwkxaVEhWC/YigZlFY2uNin2gZy1bGDOoGxTFNdO7F RsbGDOMEf2nEcXDCaFwwsWgwsMJphCMw0gwgwmEwuxqDCGf4iIiIiIgwhERERGdEYiJNk6EmyxiM s6eTI1lcfMqhDueSjldSztaiEiveQvCBlRkJlOi5kKiD8pwwd0zt4vBAypZpEnBSIirROGLK/Ixb O1OCZ0CmRmLyx32EKJUJwancCp6LHfl89Uf5i5bs1sJpQYTT/eF0E/Srw5oLHhVdBB+v+tQhU0Yd J6qeM/USfpN+jdRJ/PAbUIOiQ9GfpX+9+f2p3e0jY54DqeMriuYJf954uRQMU5oGCcMUM73NIuFE GxVud4eu6ciUXC/vsaS6M5URpxBv+FQ/x9dfVf7/r//9e9b166W///69/cyNrMjMjZ7/5/k0wv+3 9XvP1iNDmLvft/JRgl/DU/uK62/3r/bXtx+IV/rfuo7v1Gk2/foKPivhSGFvquGv9oduusE2l3sa 2l4M/Z/5/dfVwlEJoLfa4Tx+xTW1W8VvCim2KYpitd/ja+OOFXGhgp1zoaDCFxef4uPQaFppoXGh 8WhaahCwoiIiIiIiLQiIiIzQUPERxk3/GEIjJuOKZJWdi0TZZRlpDK5ZmT4UypWVnNeXggyp53ON cXyIiryE0yLxA4l2EGSwZUZCZri+SsZXHi/XRoBSDioPCFp52a+tkNp2dRDIgTPRD86hEWO07tbT X/i3B6o2PV13uk1/dUEHmt+rzXW/ue58PGe3o3Kn/QIj7pTv0bkjdf7m72k9aBEf0m0d787VYuFj V7ENkUDGPkTi4V+vpWzSLhKGhv+hp6zTMBCeLha+v+6/V+v9//9ap/ddf9ppql//9Xngp6NKv5E8 EpsKy59Wpjqf6r/61M5Tq24vW7zH1U3Wpu///xUX7XiFj2r1j4Ie/HQ4u2c7OamgYs5ukt41Q979 +/9XPbaTUL0LjX2mNJpfQzLAXm60TgvDC02Fu/jCthWLS78cYwTXSG+DOoG6tf04M6ehFxVbWxUV HxaUMLGp/4vhhCGh5/s6I1zI4YQtC0GEGgwojM5x40IjOiIiIiIiIiM6IiIgwhtCIiCKaBQprkxL crFO1YpVoq8y0zIpyE05XUs7WoyLc7E8Ka2R4hMIM6uygMEKyEyZOR7mcyKQVqDQM7RFRZUDJVFe +VynztUkzIVEOzAqMouaxUX3tSL+dAvk09O4ODO3k+DWj/n/3pqFpcLTdc0K76nj/zwDZ4BxfDRr f6lpBS/U8UbqIx1Z7Rn2iQ+nptqfGaL5+1334uPO5n8zh03fbj3/oZ3VsXXzvD/4pPIwd9//jBAg gXVmYYEGH77///3r3/W+vTrFtf30kvr977+v9/owP/29f72u4+s0FDlXbf+ZynKidMJamNDQ4IVF bZz+6b1/i7W1mCClugQqhHBgwZM0HpCLdhBXS60sKh3dNn1GlberDCTeNHULYWrzpqdNWgr8Qmwv P9n7ZQ5tmS92NDYp4pnHOOU5Q9jigZgaYoGfeeKiE1/BRH+8XFhT/Fq2haoREQwg1U+6BYiiQwls MIWqCjj3ERGbkIiIMIRBhCwTCEWpkIRiIiJtCIiMtF5laO8I7G0pXEIyNVK4rmU41xHzIZhBndGR 41DTIdZLxqGU8XjocMFO1uOxxwwQZBCK/9S6NEdqoQLemrpmoLntnHnQImnvqdqgROQTYWGE/w09 X57a81vrH0XbV6c7JkX1Rrw0a6Nn1Wjdnf+5jnfaTaNyvIqtG7TzvtKwro3abZoNHb79/Q/ZleYC frvT0Len0NWu/hE4jjukHuunMliMBP+l6a///3v/Vfugv+r9/tbEV31U/1XfW1bPpC47/11Ye//6 mPzHUznH+Gc38fYj+nq1rbN1q37dQRHGYVnu1v7pW0lGheDL5xxr9xrYUnDE/0aCoKdIba3pWFUO qG2lpNMNasL/a1Yr5zpimKT9xG+KYimKwx8bGKEWhFf9n+0OIhppnIi/z/DTQYQg832mF2PERERE RERERDBBghDYiIMKdGdEYi0IiIybFmUiK752Jo7UZ2XR2pjGV1PBBkgQFMk+RU7IsRA4hnDITITk KrMDNSU8XyE0GdniUZU4vlRkHnZrknF81DK6mVU0Myp+2pCBHzp50+GdQpqEwudPCJ2ztxFP4W1O oinoLppyuVBEa8z74TzHPphPd9otynarM9e7hBtdfdfW5ro1utN1Pnurrn6t7+0J6Z+o3anzO+66 dG6+gRH30bpKkeT873SvbzOVHcd6fe9Rp696fehHb9918beuzQMUITCDuv6en0t+t66x//qOPq6/ 79N/6/t6//+3/9Lre1tfIprd//r9of1M5hyhyh97hC//1L/ftXoEO1mPs5t0CFE4Y/bOer6QIUpt q2c138RHbOb1T633V7+0rWm1rNAXhhaaijoFQ20o1qI45usWvoYjNzjSbCthe9qxsUDOCir9igZg ZwRVsUxgzbyn8VT9bHFIR6igwmsMKR1nQgYVcw5QQ4Q/2mFU6M/oWgwh5/i0wg1xDQhghFxERGhE RBhAwnEREREREQwU6FESvEIm81sRE7IhEYIGCIhEEGZAqlcqztKZiNZGQjTIJFXnf4ThEkIlpIM7 plSyLnZUZB5Bc1ikHmrJbFeeeqn1tpmRwqN7Iq0GdPOzVpze9NNG52SrBFD6tclDTs6yDz/af060 a3pOt3emk3lzRrZqCI1tIPSEdb+mjX1+Gf3X9PTzZq2Ej33qd3T+Y6bNNBpPV6RCdP9Iz6bqd3e3 kIrW/63T7/f0rr7WumiY77Vyt5gIjOd4XycMGcYCVVq/u+SkIE4IEJTTi3/cW9V/+t/r32ET1O6p rXd+tr7+l97qL4/1/0vX1tf/He/6kn+7XzDkhyh9TDmH+v2uhomPda2r0t0/QIcddRG6Sq63Qz/b /tcRxoXjp1YryKoIEHwTI/m6w0rUyoFYYWMLCaVhhe1+0mwt3+LDS/2lhpYWf6FYy4HrYpiqYppQ ZtnqxUx7HuxsVXxx0/erG0l8J674aanUghpxaaEWFWwmENC0DCGhoWmELj0NPERDCEREQZQ4IMEI hhCIYQiIiIiLxERES3rxloVEZCEVzkZDDK+eV35XUoyGRkgkQ6mcuZQYUDNIhWQcaiKuCDO7IgkX 7IOITIPJXGM1DKiNMjxHFCkHmQkaByuKAwZBipkVUMlHnRpmoRDJVhTqETNYRF2wmF81CGuCkPVV XQjBTotJ9BUa3Bk7l2UO7vVNwhqjW1QQbmtrZB6hD3TdGt8t0ETencIHzQa52fmzTwYLQh66ndo3 Z7PdJG5U2jdp6ed76N1Lucf027U+MFf6N3FJsJpCk2DEE03vSvQjjO54eKvj62vml0M7nd7pPaua ZsIKThE4jvafp/8GCH///9/7p///fX/0wl8Lf2v+9qJKP162z6/39+r/2O/+vp1eRu+0HqtNe9qz m9aQIUxrakV83fdnO0rOdkdEfBFPdX9c9/gh3/jN26jL4IVafbUY7VCq0kOI7bqPWLiIjtKMJTOU OWPj/pvWGl7rM/4j2ElYrBmULveNM0DC2xseIv7GDOpiKJww/FODGDNIp2Km60zuVBRYhan9Toi8 3Vm7OhMJhPz/GtqxoNCD8x8NCIMKhEREREMIRZyG0IiGEGCEREGhGdEWEHFoYjlGImzERERESUrG WUZoMjhDqiTMghnfoIMrhTO6slKI2jpJmPk2KMw1PqNT6CZUQTIsZgwUvBE4ZXGpMhDI8SgImfRq YTkezURnTMOmnqyfVTRcM1BEW701eEG3RnaWtKhwbJxtPU7/bf4TpIIPU8OCI9pOZCgP05xQRH3m H3aIx7KsOz3wRHtJb4Ybtutow5n9wldJ+mzICdqtql9HrpG+ODD6p5brF/eDDF1p9+n6/v+dEjQL 7/du7fiCJ74MV+CIQp9w10KvpW7///a7//oW433peCB60hhJdbf11/q1HecjEfWq5/BsK3XCJ0cf M8IEe5blDtuv26ulbrbS/V7dSUsLIx5PoMjlBhAjnGlhA7QXPQS6F7Cva2FYwsRw1/0WOU5Q5Q9i KCFT/QjOmEgQXSxFhbXG7sVsUxTSTTFf7QiIdqRjhfoQkMPxERURDCFoMIWgwgYQiIiLU+7OQpPb xGzniIiIiIiwmc+ImQpk2PkqhIPEZbqjOyCK+I7tECRKWY8qEZKEp1QIGRDKqiH3CZCzI9mRmKEy +axe4NMgcSnLsJkeMqMKmeSYQZKgsGR8jojo6cM70sztLIPTXTrh57OoQLaunCq0b2i3pREQanqH 6eCI+9oscoegRH7RcUm53D9LQIjyBEftGcV9PTcw5Q9/NZ9c3peT9IIQ1W6CDX4Yb845h7VOl9MK 9bSehB5rM7bcN/u+/8f8acQ3erTpfW67fvV/TvqyISmdfrq79f70oYXVvS/3o32C1+La3sP1+EUO Peo3Pp/c+nUmmEkPb7/1X0O+6X9DBE4tT9xHevJDv0ou0ohTDmHv7GrfWhzDnfG+StEdJPWjDyGN xW8ij2IqalDYjVioKhftdKNY6F+GFBCOGFHP8L/Oj1yY+pntQv4oMLYpkxyh/zHsVCYp1hbXEQYX sEZoGCaM0NC4hoRDClERERDCnJhC1TiMRERERERERERERllMIsqny3U0Z52PJkrMqiIRFSR2fJWz IIlKqiEGdEZEqhA7KlhBmSAXCZLBTUISoQ7cQg4IMlbL5CR24h3/BhS9plZyDjUy+QmSzCkHWm+e NIuGmqrSLevhSZ12FyDs9EX/W8Ifp9bNqeDXp0kW5Q9E3omOUP6DaBEfv/JYaBEfd+rt0CI/6+r6 dRp6tG+ghaQINIELWl1vo3acN03k/v1rW+jdquRMMfatq+OOOJoyOFq/zSLhaH2RROt337n2XC/m gYoTQMel+v/ff//VJv1/+wuvS+vf5kYtdX3Pef3P9ntqf91+1N3PoEMIu+9RoYIU1Pzf5kbPc6Nt fjerShgpOGJGPjH3/UewQYTolI3ul/FX9fYa9bCXzDnhsMKwwqFqhr3DCxFeEOSHBEdILYipj5/y McocFqxFeh92NraE+oqKkY6k7KH8ij3pimmuTHg4jBW/+DCEWva9+GCEREMIMJlTwQg0ypplTiIY QaEYIkKnoME1i+LQYIRn+IxEREREREREREREREREZbkpnZFBBlUSmVaOwNnYrErZF8g4rkM7tEZk JHZGcypIp4hTou2SogpIaRkQ7IXBBmpHo6RdlRGgLhAzqj15QiEjtWj+EGVKREHPSSFIJscOzUy+ U4oQYQdINoaaS+i3YXi+pnq+Xj3ReT09FuyViRDy+tta4Kix2i34T1O4hIER+3hB/nc7t0aDRSDf fX/90HCTa/NN06BEfb0EG4TfufmrVbqt7++NBun9f38i7N29XJPnw8f6dK6+f/q9X3ql8icXCbvp eZsuFXX3f/zQF+/V53tq3f4t+v409X8b3Mf6p6//rv+sWRx2v/X6/XsWRx1b///df/1DU3fBDtLa m/74IUxsRzo+EGR8K//fxk96T/n+1Md0WqSZdbSJThK136H26SY0h9tbXDh/aaQirV/dXBlj9W19 QQNXpX/sMJIcRxH9hWUOaAqT1bCTYSlDkxwmf7N3xGSHCbCXaw0haP8UxURQQ4+GEhGxwphzD2h2 KFxDVC8UxQsIX3d8HGKdjY/qmpIc49DY7BTjEJzDCEMLEaDCYWLiItNBhCwgwhGbZQFOQpnKuGFE RERERERERERERoTPGWsozs1IT+MmxQi3LMuiWspMhaOsbyWxLsyC0SoIQiCDO0IhESoSmZFaP5C4 hUFshIIMpxLTsINBlRmtkeO1WBNIpxmuLyLtmtl8lJgprFIOCkLzp6P6dko/W+aGqtaM7RnZ0rV0 OdRC6CbXQwp0+ZZqev+voER/0m0Rj3p0g6Qb9dVRN8ER56DoER/1Xr/fvvVb6To39K6uvdGfaN6c /oE6v/Xc/0b7u2e9t7fW+RJlwi+ZsuF/EiTLhd99/rfGOhrtbS37x+MibLhHXa3/r//v9qv7X+/e v1+Lv/rfQwhkUDFTdfw0jf1s9tT96f1BMj4LeufSMEnvap+9JbPYKRxUYsU/0KzD0qH71HVvgwor trat0hFP1BhN4MLdrav5KgkGqFUPp6P8EyMcosVsRXsMJIfsU2kUSHURoeekNiKYYSjUJRtWe/m7 8GYKCF+h4qZ7T1FIYMyhce7FMVBKDODG+/EWmhEGEIMJozQiRiDCt2Ez+ln+GCDCDCnCH/4uLURE RERnIiIjN0RERERGbojLdVxEREdlcxkLRHRvKkioRlUjsoRXCkRmUZCIlKKozsbsM70uLuzWKdzi UI/AmR47nGuCZ1RhkrRhmQiTknmoRNBlRkKgg8M74RT1uSiwU7HCJ6uduIEMJphO6o/xpZ7RY7yU bosd5UBhL4V9y3KHkoBEt534SV53ugRHu+WPCIx32gg3+gg8Qw5xzD3ff4QuRJ3OOZ769zDnejfS 7qv9hM1qbk9U/3VwyKlWnbSXp8ec7Vr+tzVV+NbpK5lbLhG8XGhvXM2XCfvXtuN/9pXpNv/wRCFH b9L/1hrtwav6+vBE7/hPUEOz2P2+CH6ggb+59XrdbU3UMo1N+fSH7U/wTLk/LdVG/8znH3VE4gX3 9JvpF0f8Gmx0xqPzD1UKThAssfaj8drhfa4uxyQ4IjpD77VkUcFEcIH7VDpaS7o/xGELo9tpfVpY W7FNbQOIyY/xYwwQtCLse1tY18kPZMcofXFPgzqBWsWhEWmCJCEWE4YQtMqcREREWUjBCfQiGhHD UREREREREREREZNhfOz0t1l2CBnYGyqomkREYIyM87LEdguRTNZldVoQcNBhBktFIVSLo7OxOJRF 2a2X0RpDAzFZQ5Q7OzXMUhilMhs2zUj+QvNTL5KcwypYIOi3cNF9mdhSUiMHUw7OyYTTXg81ChCN C9UW7007Iva2mmSoSZ3hBslZ02kHRd1lY6w6R0B6nHoER+2eA3CrMOCI9PNTQa6CfRnf9oER/5x6 pB64MOnpuE6MOYePXzud5o7XbrcdUYcw9G/VPhBDT7cKn3+t4Stow5303p2RVjr41Tgi9L/t81HS v+EWGZ9U+P4hJbr166f/p63/4Vd/9tev9qn6VfVf719BV+v/6/6//bUInd/Wz3beRjsV/He/fwYb SN/3c+tLCCPd9qY+sEMEyON/1r712kSgfHfBhX+26/vY69WGP23wYTY1CCXp629aQ/WPtvupbhYY hOrDCUfakPBYYXtfpWNI64XV9UPVDYYWIaxqyQ5xwmExFNL9E/H4WznxSLHOPdikIJinY/a4pCCa +PBqtikMNKGhEGdQmleNDlcVSLHJDusRBhQhDQtMwMIWEIiIaZYGhYTKmhGY8MKazvGE04MIRFqC I9FoQcRERGhEYQiItCNCDiIiM5GIiRqERERk2KI3mQuyqrITOzDNTI1lPEtRzMioZB9NMg8iuT4Q ZKgpKEfwU0Bc6RcyFwQaDISUIGQkEHZC47HZfzoEOwVm2VEamXzuma4ju05079Fv08FryUWi3aM8 IaLHmoI/rZCpbQZ09bJp4IdJ/+g2i4XYIjjPBcdAiPbwg9Nqgg2lCd0CI/v0jPV0CI+/+r3XroPu gRHxGE3VO/3uY5/087nHra1uRT5u1Tf1/c//+xrbt+EC1f/1f7UV1w3uRJlwv/11u//vj/98ev/X //6d9//1+8W//X9e3QKXQLOf0Y8EON91yKBVdY1s9//q0jdf410lBEQe/hArLoJWe9qhFL2uRXI4 6neY7WKWKtKO1tf20h39c6RHHfSFeoQiNMjpcUwvjCoVIg4WDG2k6socIkBiYc45Q7jbS72K1Yip qUKYwrJuFEUwigF7QZi3xoIGCHDxTCoWdPoRBpWKdjcdqnhNKHFoGaskPk2LU4ijeU8WhBw0I0ix ypsRZ/tC0GVtbC+eQ6cGFU5GItC4uItC0IiIiIiIiIjESNGd0yoYiYISyBXLczyuDeVtWEDJNHWN 5U9BnRF0cinZLM7IZ3zIUMhSKjOqOxMIQeVJHRS3CwXIVkHEqZHgg4IkokMIkO7uyWChF2Gh6DKv 0GU5hB5BxqaZrFCn0d01NAwSyC2R0R0XqVnUQK8z9YcEDfuFSD02jO1U9BEx2nM7Kl0rrpnZqEnr hDiIh2eC40lBEf0g3mDU1mk/Ctabp0g278IOaSNDSD+gRH9Fj/S2eDRW9Qm9GHO9LuvzGjeg3V+8 /6em6ft6b6bpsin6XaCB3qdzvz/VOjfmszuKuRJlwlfW63sJcWReuaAuvj/+Thh1X91/NAxX0N2u 3GKTdDTvr19v1/31/f9dV1h/v///8Pf/7797U3f/p6McRtnkCJ31nI/Z7v6fmRQ3/3450fps9oV/ ODe59LX1Gv9v7X4sEnj+1hgraVra1rara2uu38Nf/6sK/2Gl32sRxhZhynM/hfqxUcMKw0m0tZvt hKNJtKY97iNDm59rZ7YYVDhqNinp2NqOhF0Rj4XOeLtTD2KY4p3fimuKrHa69jjYrYq0IiwgwkZy rKeIsqarERGj6DCDBBoaEQ0LQa8Qwp5xEWFsKecNREXEXERERERERERERFG6IiMRMuGZakW6XiMm 80SmN52Jo7BdBlXoMq8r5nZrG+yTZEGdoynikUt1hl8hea8ECTuztWEO0jL+i7Z1CkHEqMjwRds1 4IoeQcdEfjpmGdgoLp3YQYTKlGYLhBkYiOZK2R4g6vYQjrVdS+ekE66XQbQj09NOmuDRb0W7JUJS LHYQ1foER+9abSQIj9+6Qbljp1dJ1fd4Ij5KQSezRpuYcOE3QdZnLigg2qBEf31vU/0ubtb/10el nfdXP/+qsicmU9SCbXoMNW6tGHM9qE3To3Uu1r5Ewxju02v/+7mbLhf98TQF313VnO0x33EPWr1W O/0NeZxcLr17x/2LLl4/91r/177uv//+3//v1v2dGzy0t9Y212p/7XfZ7mRBSOLaWK++6R0wSun+ //bPq9Kp+d9fhptqdqAv0DI33RqYKKreraUML6FMaXtWt8QnW0rftbWGFfxXxFdmYLsVTEbP9hhQ hXsRUMJR0rVJ+NpMcFDSsK+raTaSHGr9ofaRY4VexUscELux7uDOoVeGKahMbFcVFMVsV8NCzogw mhDCEQwTQiGCDCn+NYiLtDQYQMIQ0Gmp5wwhaiIiIiIiIiIi4iIiIiMtBpEpjspxK4vSbFbOyEZG QQEDJdlOipBCDi3KchEUvMlISW5lBBkJkrFO1eYiWMvpEHImOGCDCmaU0Bc7nnSMRURkL4U1CEHk JqUIlKP5Bx1zEVEpqZf6LdnTtVCa2jDVAgeW/Czp0TxDyLiWnlKMIaX0Xk090LNYqME94QddeCI8 gRH3fSdBNv88GvDCpUgRHtA1RMf//fMOCI8F0CI+3Vbd0b9U9fnr7p7ez2NOxSMOd9U9M7g0b6BB /39+qdEnue6+W4Uy4Wn+h//jM2RwtOt+x7YMKtv8zZcLgyLtXHE0i4U0jAT/zOLhfud7xf/X/v/+ q/emSHquDLLP/+oP99rFgjjqtf6+6/tTftQUugVz3r/oydT/19DnB8fvXaRuWNntz21N1qf7EYIM jjan7r+6MD/H26iKhgsUturj8dqjP21+orH3hgih8GFGsbwbihV4rttf162FpC3ViKz1+w1z1Z7b CVtq4Xu4jQvuubsJ1cL+57Yio7FAzhRY6YW1G/NSxCd44pqNhbWqzD3odrBmBp2t4pDq0GFwjNCI YSiIiGhFQ0LCERF2f9GaEREWhERFrDURERGbos/xEREREZujLRmIiIjLdSRWDzubMRUshEdguTLI RFcDRUI7E87W1K6nppnZ6GQtl+8lkFOiTJUZHjUy+pQiWCmtEciVMvnbsvkLiDjorTO5xmC52kZH jXgnK5VrRePSLdnbiQ1umwh3pa+X7Cghra2SoTTzpudjiUrhDq/8JtZ3BoER96dVdAgV0CI/deug RH9AiPuv36zQaKBEf1ve+rzjnft19c//q+t/0b8/63r0SfVfc453tJN13P8yLLvq9aW4g2v/i962 v37ior6/O9zNlwm/ruNOu+N/vW/7X//r/9vMa7/v/+uv+33Wv1ViN8x7bmVMEn++z2Thjqn+Ijs9 59P//7U3QQZHIEyOPv6v7PfBCntLv4gvVtSKCAih9Xr6h7UEU4YT9bdfse40N37V+rBWtBm7Fq+s JiKikI2UOZwmIqIoM/4whHGlEV3XyQ4QYLtW0ojjGVyr3Q9ioVBqYcoeOLteuxQa2NrBoQz7PimK aXjUw5hyh41QYQ0JpuwQYQ0z/nIQYTCFoRdxDTTCZ/xGhE5iIiIiIiIiIiIiIiMROwRlmGnJutII Mi+TJHeImM7E0dc7rynZ2RkIiF4IGSeQrlcVjsHHZrmKwg1shUEyPGgLnXMM1svWp9HWLsqMnDAQ ZCZFAXNSLmRMFzsSyEzUy+EGU7U1Mvk4YIXlfLl8/6aZKLRfcvnrwl0mq/p96SLedK6Q6O0ghqEX m5hDW1utdvSBEe7oN1+9vNBr0gRHkCI+/+gRH+aDRQTfzQaKJD57NFVQIj9pB1QIj7s8Fvr/9U/1 ++qPHaSuqev36q9qm6fcUm0b7oJtGHO9En1vXP+vqEH/9FKZcL/T/fkTi4UiYL/Y0/39kSBdvXcz i4UUnXfp8R3red7r/aj+K2RMMGSyGN//9/sWR8Lf/X/X1oNf7/e/W9f7//9/6f7EbSN38EK+I2p/ zkf///mRjdLqf/9ApdBXpz//v9v/Vnv+1nRnRuO8UvGDMOWPH/tJbWK719GHxqP2tqhFWsMJNrba 23+lHDW3V9deGb+rrOOTHBW4/6sRTDScKxFfnrXVtJtKFaSG2k9/8R3GxFQwk/3e2trGEM51u++7 FNbTW+Gq3Y2MGZSFTDuK4pqKanPmHuxXtVqhERaEREREQwTQiGEIiIiIsJhOGqM0GhDQtBhCNH8M IMIXF4iIiIiIiIiIiIiIyzBTlusI3nZ0ZBmdjTIgzuwhKzNediaOZ3jJdkEZVclCIXG8yKXK6nAn ZC814Jkoi7Irk+mStHpBplOZHlTz6OqP5K4voHYQYQYQZLRTqjDTIRHpOzucdcxFOyPBMp2XzIEy 0gpSuWtJ2yL2ENU+0aGujO0aGvOpGdradp3Tcsdot3M7Cpp57V3c7HCJpq6LHa2ZC4owhwvtEY95 3+k3ukHSbRh0+kG9fRx7wnQQboOkG1539/Cvq1uEG4Ij+FrvvP+u+qfuuuvs907fur/06V08/67e u1dGHO6pGejP1dLdGHO8tIKWdzxXrxSV4/67372P3/pb9fdfFd7/9Lb663//3/39/////+vw1f+v /3/9j99//9f/rsfu+EKs9t0s5/gh9GO1L3WjBbUxoYJkdAu/e+6/Z7dLCgmRx/96/75j/7f32qtg ih8dfara7126u9KjPQirrbW1urWGsazOCI/HaX1FbfWvetv7dWKkhwkI6XtsJBk3CjCxaTEVZ7iP PTCYioptKwraUbpY3Io4TH3uFjWMKxFPr4poHHDX0xQaGNC3jV8GdStRsUx9dYMELWxtbFIbXFRc MJqf4iIsLRdM3lDwwSzOV0R2EDBBhBhMKecREcRYQiwpMc92haiIiIi09C0LP2hDiIiIiIiLBCHE S0gtRPQiIiJ/ET+IybxFVRFYwZ2YzcSoIZECFOiBIhM6orSKkjumdiSKjIRHY+cyU5UhJXKo7Qy+ SpGGEGSwVYaDdI6xdnWMM1mR4KEy+axDVBUzVEagmStEfTIOJVhSF5Bx0SZramphMhUmpUan0pB2 j+thNNFjtPmHtXODp2q8wTahDo/wwhhCOgh+m6Gh+2ahNUYGfv0CI+7wRHoQbWttJ+p30gRHkZ70 gRH9VvYaIx66/2qvCdf993X1Wro3qt67PdL1T/2e63Rvzd8MOf8/+f/W6N+f6+jDndPue+7/6W9e P/bH1f3XbGv40LeGGoqJmy4TEicXCmgYroVEiYL91t3cX1ul/X/xXpf/rX/37ww99f/W3rr+0q+h v913ufV984P1/vSMD/Z7s9oYMNs95/am7Z7ef86IIU57z6nId/6GjDChwyOgv9WNXWGCfTa8fH39 esMEUPhrhh2sNR+Go/3w1kneuv3MP0Ijz+40qStJDYYVirOTQVoKxFWemIqI45/hhxx1cf/JOEho fsVd1npz2wvsYa2OWPYqow1sLeKpfw676vvg48sfW00xvxYM7VJRoMEIsJhGaDCHEREMFhhM/5/i Is/5/iLP8XEWp52EZ4iDBC0IrxEREZ+jP8REREREREREREZuQlqi6lkK4RoWhGVysZ37JaqOwNHZ QiEzpiRGdg0V1IzIoRzIRDCaDUgcRTJ4EyLo/BS8QvU0BdEUcsKPSUIhI1ReOpBTrmGQkdzwmasw ynZHjUy+QuCDzW7IXkJmRb0bmjO1PT+C3hPX2IfReTwuhquTS5naaauuSoJVr2dRDIU+Em0g//hE o70780GuyIO/9960CI99pB3giPoER/QIj9pU6BEf9K709W/9AgRHx9Hh/tU6NkP7uqBEf5+dU/vV pVaX1vOOYfXXdIw53/7V28zZHCxaBf65E4uFI2ZHCildXkDi4X80i4Wrvf7PsuErV63rv9Wn7S3I ky4Wu6fVeg0vr/3tdr/e74sjoFX+h/+//X/X+2+v9L3/e6l5Dan/OfB4IfVNT/an//7U/2I2p/9d /TU/wQZHQK63S/v/996tTd/CZdAlyOFuuYeP9zuMvrd4+P3Vrj4ZEHjrbqdcjyUeKrEVdMdN9er/ q/Q1/oR4uOs9f+GLZIcxaIrX2GFbSHwz9XYikI2gvzjpsLSxGxFdqxUR3d3wsij43398GgaF6cdi or92t4TW1jPtLFB9quKaaa2mMGZp/OQkRR2IjQiIPhghEWEGhERFoMFPtKhhCLCBhCGgYIMIWhaa iLORGxERERERERERGImQ1CZCrLKHybkhAgYIMk0RjJPOzDJPOiKtHM7MZvO1XN5Vo1CHVFaR3PO6 ZkWqVy3O5o3FSiXsIkOyVZhoM1JMIM1iHbsvhBnXWGXRjQOzuGXwnZKjI+SxkeTtNVKoiOR1ZfIo GClhgyF3dNNPIfkKoIG01RfV0W9VtE3fxEHTa21pWk/6MXnoIa3pL/QIjz76T0gRHiUAkJvdBNom PQIj7wm7VunQIj702gRH3C8Jut9EY+CI+88Fxmg0UCI/2qp18in/VOROh7908ED19Paz4eNdevTf PDtX3PW6N6S8YTtJN13/yJMuE/er/udH/7x/XDEErf3/vr6/mbLhIpvx/Wxp13p/9/r/7Xr9fr/s Ku////9/Xhr9+/1+v2kboTI6BYrr8e/BDvs9v75pkdJ/3X7rte1WrU3UYGNs99ev3ruKx3QjuOK/ Y1dJhgih/raoRImjXdfW6vW/uhr0Z9kdLbq/av13C6yQ4U59uFvVkhyhyhwoaSEbEU2EttIYpiKY piKYimO7c956QjYioaVpRr62sGh+c6YXWzng0IixzD6YpnRY2mmndpqkNp9pimNirQiI+0IiIiI4 YVGaBphCLCFhBhMEGEIjjTKmg0GgwgwoiIiIiIiIiM3RERERlkExiMmwpnaJM7GmQUiMI6ZEkQiJ aM6ok2diyKmiDRUshea2UiOyaI2iEzuyldT1IphBhF4GQvCDvyTFt1M0EGVGQmQma0R0EyVojkan ZK0RyIoGAgynFNbI8amXwpVilPKQfkJlqgSlcq7KVnXovHrnjT6LdkKiD8/hcheoWZ2ahPCEYQ1w hrNDVXW8/hQQ7IVY74MF/1tJvQTv+iY5Q/30g6+qoER/RJ80Gik6BEeQIj+gRH91VevTsGXF3fpz fT9ORTydd8EL5FV29aMOd18/5/1tz/aSD1aNyS7rf5/zdyKL/gxBepmy4T18iTI4Xv09vxNGRwqe /3W2aMuENGRwqjiv4jV7416+340Jmy4S7M4uF+DBRYIp+v/19X/Hdfwwv/61//+u/7+gf+vX9RYj am7Fra8/2+NjVz6qf7Gh9GL7qbvP9s92fT62e/dbOV//HZ9We2puxvP+VxYMBxrjbSH7X5hzD4MF H1Rn2tfjWP2CKHgih2F+gRTg1urqKfr1UEU4YKT1qPeP6Zv/MPhr5FAxOejH0LofzH5/jW26/4jC EcRhCNsK2FWI2IqboQjQj+c71lcq3V+ihMUOu/v4/vxvH767WxTFTO2qa/a/d+LQ0IgwQyz/fEZ/ i+Iotyoi0LiLP+ciGFORYTCozQYQYQjORZRER6GriItOIiIiItCfxERERERERERERERiV9ITZiIy bz1IsIQUgQZKYjMjSOwJlWyaZMI7/O6ZJGdhM7BEdjxGuVy1l8y8MEWaSaou2EGiCDJeIVJhBlOy +Qnpn0amXwgZTxxgmEGQmQkQcpJWXyDjoaDOqMMIM1BivSaSN7IXpBuZ3YTyUejO0W7WyHLl8/0q 3UNB6LdkOvqi8elzp9OE00WPSrc8GjO4hJPwnSdno0Ye+9N0HQIj/Tr/oER950HOph86DlAT/++g RH73p+CI/Tc0GjRnvVNq12RP+/N+9P9rmKrrfv++v+km/p96/637q2qunMTSTevFJ6qu9evG/v96 V///b/5CD6p4ZdEdAih+2+ZsuEJwxe6//pb/jTmRXf/837+9f+v7+//0xa3/x/xER6/3xgih7/11 pL/9/7911j+Iak/W9ApHFQNNdIxfgmR0Cxof8z/XuicMNI3Z0WI/wRQ7I8t97618Hv3WwvH2set+ hxHfXqhGHmH+tFHaVTo/Q/4f1QiN1Y0ojtbt4StKI+Y9hhKYc7lDlD4piKZIcxQYcw5Q7i1YimCD P+j+xFexhfYYVkxzDr+wz9Y0mFFUttpGQU8RsfNT7FUIi9ODQtCJxRtAzhP7Vl1tLdMUHER6reMG dWmuc6jGGEwp0IRrDCEZwMLEUZzw2FiIu1GItSNUCcREaDBYiIiGFBhCIiIiIuJ/ERFxaERERiTf WOgzXnZZCIidlcVzFJvNYTytpIhUQtELRkCo1mU4Q1syBrINSupx3EXyVsvmvCZXLDCSLwODIRke OpBSLtSKBglaI5kHEOTMihEdBQmkEynZfIXkLzWgTIswka0R0EzIV5XLAgW1tDVJJ7V0NUkghnTf whHM7RlBh2tkXrwhp0EI1Pdd0CI/rBEcqedwaO/mHoEXKaDRX7UKkH0g2gRH/9UZxCXui8o7+t0b qTVXhte6PVUKTaN3t1n/VueknrffRuW1P96wh+/6Ha8Q3W+6tU9DuGJUiiKvH/75EouFoarG7/dL 91m//1G+jf/7W/XmF//35tbdb639z3/dHTBL63/2z6BMuROiOls9+jA/f5FNSPgrz/c+uk7PJDtn Lf9bW1V1iE351yOLYTW1hhUNCJEkKB9q7aX6xEUPw17q01obEVGkhxHBhKCiNCkI2wkhsLjbCWeo sKxFMkOF8cRxzc/sV7FQmoKRj48GdOcjsVGh0Gh9O+vN8MINT/nRBhUGFOCFEQwp/4jPOGEsw5Xw wnEZ5qdCn+IxEREREREREREREZuTQhxERERGLifxk2C0U7LfESEQmVCKdndok2QqK6l5qEOqK0if IsjW5XKo71iCIECTCDQMwiOZOGCngmEGp9IMp2R4EGU7I8QnlOGFU+iWYJ5A8joKEGdnzIXZf5/O zVpkpCosexGoIUi3a2i3a6LeEs1CZ6VGL7CGpfP4QjmdnbiL9aQIj3QbmHJj5oNdYTvoJtJ6b3CX zQXHdV/VIOkgRH7/VPP9J6DQO1TzdV76dAi/pOgRf5hzvt2oTue7dG//N2rRhzj63tv9qNWOIpXQ 02/9d1dbdbbqO3G64/0KvWG1++vv1/6w1/X/1/kh6/B7sZdf//8Ib9Z/vLd/OL2z6ukP/q//9CtU YGPPqI2z61/9fFcNX4aYW6KEmR0C6oz7W2t6vr9FjlDt60YfDCYMseUJMK3X79Zu4UiYLwwlEbYU IRGw1c/tpMRwwrEffQh4aue8/xtH8IR2u3xHra9jkh7FSQ9ivY2mKa2N9io31/Yp42u4jORDCnPY TBEhBhDTCDCDCDCFoRaTEWf0Ls6IaFoMKIiIiIiIiIiIjNyEREREZZzXMhkdrWV8xEr3S3NERdEm jmSxkEZBWQVqdq1RrM6Ij57IyJdG81iHds75qa2d8zv4p8qEc8l1K4JF87dG0FBBhB4QaDCDCDBS iNsq86o/pn0S0gmhdhAwTwpBwQYTCoMqIg5BkWyjCByQwOwUhmmZAnC2EI9q0THaLHaLei3hU0Ga hF6UJy3bWix33MXN1Fj0W7BNGeaxKRneqLfD8LTZkK/X50H0Twg6CDoJuE2CJRpGevfYIjdIJuE3 CDsJ6d0EG0E2CI3SQbXSD7wm57BwnBEoVa3Rnuz99erq91cKMKm0Yc7/ugo06urrdnv6enCjVzjm H9X6uOrYXp9/+9l0YS1e6vV02EXj/rfdvRd/rputj/vsInddXc0ZcIrx1YIutYRdx/9eNxEd6//r /v/9//frev/9f+37//f/v7/mH9Pv3V1Bpar9gmXQSQ4amF+rddTDCh5guuoNXox/tI3dS/Oj0w9Y feCKHmEF/pUTza2trq3zDjMd1XehHozj7VurW+kIq1tZhxl+138fuv7UMNupxxmPVCIq3hI7HC/F Wk2kw0rC4Y2MLb0wp/4YttKwpQkwrFWe6bSbSwY419e2NdW0jrhY8GKYqrEaCt2mKimNiqB2leMG cJ8NRsUEI2ozpxseHj4prQ/Y4hBrDtAzNP2EzloMQwg0GmEwhBxaFrHEGwwmsMLwwmEINosc7xaE UWOUOcc48RYUtWCEGwwTURcRERcREWhGZEZsiItNCfxaERcYQuIxpxGg9CIiLUREREr8pXVMtklQ Tlcq1BCt6ZaQUu6N8f46/7n1BDhp6jgzNlb6m/cRjldTi2VulcsCdei8+hLZBIuF61dqfns9ivj+ rXm6LURLZBccHkEaZqVxfKOZw/0fKvggXxBArHC7DzolsguDJNM1/Df4/wojLadGFH///+QHRtb1 H///////8yA1H///////////////////////////////////////IDoRR/////////////////// ///////////////+CV4/////////////////////////////+WwZoyMKVy0aZ9EJHao04QemdRAv RdvpZ3vQQNlpCTe0Yc70u6T99O+uZcBHvitNvfX067/VTabatTQU+/bv+xQ0NvaxFNdhP0xTQjER FoMKI5bLowiv3K5KgnZ2TzESrMMlYh2J9MLqmmmv533oER6p3ou/r+qeluE1yuUhgtIwaW//Xidg wxUED////LsrIIjgHev+tWe50bQ2izt+opY+O/fCBqI3VoLv3xFphUPO53/cQYIRGhERiIy2Qilp jcbMyEkZ5kFJMyVVK5aNNNMIMyFxYM7DiFdnYQJCDqZ3SMOwm3+nCJ4HW+kHmHKhEY39Gm8IPX3V kFkhcMNfpvT777p4sikpnkSZHCkTi4VXrePbaW6/X/3q1bhq1Z5Aid2p/vP8Z/trtW6YihOy0MHQ biuP+2ErFQwUMLhbr/sVYQYoZuKdwsccdhRDChCGmsREYiIjLTLKWTXK6pmULJsoRGM7MlK5Kgpe U+jtT0wUyPF2dvmGdqasIM7VFZkI5XK2mvprgvaaa6Ldr9B8ER9/dwRHGkd3U77uEG/6ND0m7f8I m8fcg6kvffvpN5kVWk9/oL/X7rX3MuDHbeH6UV9//9f+q3b4e+mdggYjMLXfXBDdIEKZ0dsbt6zd qd9xSixS1a9+G5kC8RVZ2pZhYMbS6socycc45oKkR7uLT+ODjQuNWND8NNAwhGhDiLzHuIxERcaa GWmKmIjJuTyFM3ldURhHZKYQZ2ZIiqPxBcvna2jsJGzJVlZ8Mji9hO0Gi4Z2qJMp0Yk0GFs7UztO 1PZKxcW+ujRQQbvBDpGdpv7zu6wtkR2k6O+0m0nV0rSbnfoER+4W96LHKH58vV+9PV/O539aX1uv vwhD1bvdf/3123t9bS+vvx++k//v/9uv1/Y8Gv9b/X9TsEDD+3DStrb99Ds93V21+rWOv2IrtfSt KZyh8eGkLFMRsMJYMwTahpiKiNhhaEP2OmmKnR3YoWg1FfMOUOUPsIQwQYQi0IaBhBggwhGhEYiI iIiMtMUGZaotwvk3FMhaK5KjslMIM7S0md/mUIhJSFIlhnYki6lckjIWFJUKVwVWmi8aaIqQ4uQT akzQFwUlTTQYWHK4KEUKto0Ondg+wtAoV0aGFeqLvNe9JtJvIg9mgzuXeeDXCI3zj9IPBF/o3UE6 CD709OqWk7oJoabCJjoVe60u+OOP/52WMuFBAiGC9N3iroF1v3/+////9/V/X9fn02c3PYIftqGp /kQ2dH+z3rH9dbVW040OrW0hVb9tc7KAXb5nZfb+1bvoa4M20oMJMGEnyGFvhpDthKgxxFMMJRFe Ycp80FD6YpiheCfYqbCoxTg7sU+edoQehDuGEDBCzbQFCENBhCHDBBhAwURERERERERcRGWmKsmw NHYoYkX5NxVFcCR2fO1LCBlcSSYQeVpHZPlckkyC5kKaZ2ahc/hExyh2VzCWRRBbnMyY7g7kQczS SiuWh8lAm6WsIQ2VwgkGugQNw+L1S9zZ3SdTtYNAiP3TzuHsscER7N3Rhzv33vq0Yc70q3W3DD4Q ab02ZATLhK31abb/rcEWn/TiHImyOFVvj6/+PH/9/+tdb9pn79ghSr19gwf9qRfBBPP+/qK9t+dm oWfsXd7b6UcUPuvK5aF7eKBn3Nb7sUdhYWI+C+GkOh6+aCtkvmPrgmpj4Q8VnNyLQiIiIYUsmCEa EGFERFhCIyuVIrleJ2KFsyWUSkIZFudwZNgiMIq0VGEGVLIWqmQWroyKBQmE7OumahCURdmSIu0X bIoGCUJM7E/IJIWejSLaLhleqIctrqqemgg2t52kE33U2abgwVAiPu7ou9Tvqd3Ts8Gvutncpyoe 7Z7QT04YhV/wnpf3XJeGn7Rhzv4i2+RjjxXBgv/x6b/+0r+t6v8PvyuoS//6pL/79ffzIaB4aNIt nt1F/BDs9303W61agh/38PUd1eqUbGsa3Qfpbb4hZJyhqwzmrGxFAzBNLSsGFFhhQZtimKlcLGDi KHM53tNOjdFw1TFMU49pq2hEMEDBU00IiDBBhYYURZXoREREREYiTYFRZQOk3A2SedEZBeXzsfO1 hyS6wUnJyKioK2rBnaRmI7VuEHpn0E7U/9lcRFztBkpi7CdkJIt2VL20HRcPpVfWp3x6NFU1vQQN kqE9Gjpvvnfv1vO4Iv6TdTvR3706wnqzHS99e7/+s1Lp6W/dVtGHO/tf7mgYvr31/80gh99OvmbL hac6lW/u//j/Q8f/+vX/W8IP7//pIyK30rrpYz/++n1DU3/BEbg/e6iO3/NBT3+bt8a/asf9D8aB Gju1bVbDCv0PEV7Bgk66sVQViPXgg7vxTNTih/aadihoXaHoeakR4pqnhhCIgwhEMIRBhCDCEREN CIxEREZaVM7AkWROcm4GZGGRhkGi+ZEYUIM7MsheSvMI7SshEEGdo4TQaDC2dmsYansKmdqgXCdn aoIdEoRMdncCUXDRoaLdhXj8ETHo9utdU7hH5TsvnT09PCDwRf53O78EnV0bPO/Rr+k6Lut6tXW1 /3fCJvGr21XtINb1wg79Xq66W1++n3dyJxcLW+Nf4xX+t96f419TCH/1dv/7rfa/6WsZtXSeM/76 s9k4Y9s9jum1bSbpY1m7M7V1o7BAvvrHUaHhhbCUNKIppa8GNCNL4ilZQ5tgT7FMUGNoafaD81gh 2pnKiPOdTDlDlD4MIGEwQYQiIh50WhEGCaFpoRoRGIiL04iIiMtIcxETKpHfxXMUm4qjrG8nyK53 eXRlVl0EGdgZnZmgpB5KhDI/kqMk4g+TcCETvMIzRqEC2d0wthE4DQYU0Bc6KwkdrdgpPk+gygFz oEha9U1WzscRbhB0aJ2qBKTeaQ9T0F7RbtJcu9P+ixyooER91QIj702kG0p7Pn6M1+CJR6QQdng1 0W5T6Caq/qEPXow54169c7neKTb2w13cIER8f7Gm2hctQYrj/+K/X/0/r3/UZ2WMuFbVAm461fx9 1Edv/3/f/v/16Gtf+N7OT757/9/8ul9/8nDCPtaN3jnPv/k3CA9qDNknDF6tt96UR2v9rV+jOU+Y dl/t0m1OgSrFU3sRXGxHsVsbFHXbOb+L4Mfw0rCSWW5TlO2up/Ke0NNM57T7WhYu1tA/TGxUmOCL UCLCEQ0IjQhwYQhghEMEIYINVQiIhxEGEGEIjERERERGf7iMtI1FETtahKdHbnJusGas7K0dwZ2R pnYpnakzEVGdGYjIVCFOjCOwkiSgpWUdSbpIuwmp9HVHpNBncCI3M7SCeaxN0gna2dVZrEhe0XD1 Td0aKpNrtrVoyjfMPT1otQbXQIj0L7r0m0btOjdhOjdp3QIj/CpurRY5T7LmY/VOrv9rukP0P063 Zyrft/QQtb41+ruvK2C9brf+L1Gv9e+PX/+PrvMLev/6f8V19rul3SghzkX7s962e77Pd6ME/dAh Tn+I8aTazQU/+0skoLw6Oy4YsJRtq/q68f1hpUNhluVs18R7BgqsfFWcoioMKydglmphhbFPTQjr N5T2KmPYU/Q1G0xQaGaDj2g8RBhCLjMeIidqu0I0IqDBAwnaFoRiLTQiLK9CIiMRMqslLETrnZVS bjSMIqERiOxIzIvqCDK6TL5LcvkoztKSpQnZ1VhMjwQZkjspQYRcBhcl0R4LcgmwWfUGCkLi1CxV 11eaK+ggdbOoRXvuwmSkINAiPt3aO+0m954NmrQIj7pIEXWzWd26zODBEcJLX1/0741e9Xzud9J9 bd7QbCJvFGHM8tQtX/dLdf9/6/b31b3xbQXtNjX9L9/11//9evQqvq++oIbeuplwY113/+u/shwJ RmFf76/puqbqO1X+9XV0aCnsQp3q/2I2TgpOIzsuDgzbOGF2IrY2IqKHHgsGPtbQaFhJvFM57T7T TToLDuxUME4MFMjQMIRBghDCBggYQi4g2LURFpxERERoYid2iziSOyZiVCk3WDKczXmVTRKVRUFS EFbJCewMltYKgpQwg0yWIwpNxSCaDkE3xkvYJ2ZH0wgyLMwSYTsnBcIm7KAwCafRbtGjZMwnM9b+ aHpo1tekEDapPeEHptljlu0oVXO990nqe9OgRH7ng16dng14Iv5agxVW1eEHedzv7df+nr1brcab O/qxp0lsZNwYYp6tW7Xb66//SW61/dfSb6y1Bi3a3RhV7/it//9ev6//7elnIvT93/90+plgYtb6 un99/tfoetraW6v+6/VN0xq2vpWrUfTf/YaURwwkPHBgkxGDNskG0FimI2GEhthhYirvGrG7sVT2 1tVFTnTFPEQwpkQwQhggYRkI6mREQYQMEGhEMIMEWoEUWqEREWsRERGImRTCJCZbrAzuOTcDM15W M7okjumdmuVTMI7Voz87ojtazsHGyCZLowrpqfRKhTs1SYKduIp9BU4amWAumdhasg67ReBhOzrF 3DLUJqjQ9VTwgRHgumvrWnnUJU76cLrcMaTfo2XcEmps/BEfe1ns+f0q3Sed9tIER6dw9O+k/hE3 jQvpPxKeKTdbzud/9Wu/T4Yf76H0F9/dnaSHsrYYfXtf3r18Q/47/+PWv//ff1/r16q57KWGIzCs 5L1nagUj91OidggYf3Hur1tch4IK2lM5T46nflKBebtustx6/X9q2r9MUsQpNwgPi2oM28gxf7EV QdivBmcoRtWGEoMJRHSwqbVTZfBqY9p2q2h3F2NimKaGoWY8RaD0IbFoRBhC4YQ0LCDCBggwQ1oR EXERERERGJXEyEswWzq5NxXNbJNIM7dmI7zL5C87AkXR2FZAzJfMIyKEY1CBkrZjKtSbpAoQZ0ky Dgi7fhclQgLDUujPCDCaYTwUIm7NUXfaekaOtQg3trar980UnWwsIG1TpuqLvTeuk8J0d+i8oER9 69INoEXWgRH8ERvSdqd9fp1dtL//eE9N/9dX1uETHQ1pLav2m/DEoMt/fr+Ovf962voE/+/mbI4W P5hPr///WxH1/+n/1//dbOA4z/6tX1bPf737VP7F/erqwp/ybmAl1r8d/0RQMW6hm62t63pI7y/G x1dD8JRHNR92xTEasRTvFMRTEdgx3SsfeW4JaDQ1OdBhNTHtVtNNODznQ7CGrQzHiIiIhhNCGCEQ YIGCDCEOIiIxaaEREReIktRkgZZ/R2rYybgZkq1OzXCDOzo7NcrSOxPMgzJfMIlOFKI2wgZVFCef ROGJBEovHcg4qfmdkxDtaggwqan0dloLpoNE3DJSFIOOiPWaGqfcJ9vdTtTCTRV9aqYdoEHS1ek3 88GuzOW7VvluW79G6kkG0CL/3PBr1h6ea796d6GnSDvTrCDv3Tzud9ddvjTdet0HXf7drdN/laZc L/+Pt9/t6vv7u2ZsuF/6FU/3q+t/X/19IV+PWP+v+1/uhn+9YIbZ7+7/1ftb1aRvghW0kbG9WlTa r39If1q3rN21bqMlAUdewwu7DCthRYMEn4YUQZ9iW2NioiquGErBdJ8MtqFTFNVFRTFDsVzZHaae gxTFM58twQ7UMIRDCBhHfoQYTwmgYQMIMocIRDCDCEWEIvERERERERERGWhbIs41HZqUm6TKRGEU 5kmjumgztGTTLcZl8qEdwWEGduiojfz6CdhNM7HECLtncCSDt82dNM6Mu0wVF20z6W+mui4dLCDY VtffTRrYKgg3p/3QIj9wn0bKvMOVeW5btAgV16Rn04IjjW/T76/b6D10NQg7173VWtot4771d1S9 czZcJj3j+V6y0//6cILXIib/x+/6/Wt4IH19f/79of1b0nVqbtnvNoEU7s9vWERuD3wQ9abWP4Nb rO53/3Q1xxEZWwX/RZ3etMV2lO8x2k3M5Q9tai7EbYL/8YwgaYigZ1ELFYMbDCknYg7FX6YoeZyn zozHtCLWwtrB2KFraiIMEGELQiItCGEGCERBhCHBghEYiIiIuMshCITK40jtbyyA2J2PEucm6Xp2 d1pOzsUM7QipZ2rztLMIGCBhBkujCKtEYjCk3SI/GoSRaw7keyDC4NBnY6h51i7JhKfQQYRN2i3D CJwwnZ1SYTunhKDh8H2jRT9UyeC6c0YQNoIHgg2unhe7y4z45nD5VtyWNJv+p3wwV9JtJ6bV0d/v O/+gg4pNMM6xux1DDp3fpLYhfT1f1/fr3/EEWTrZEmRwoImZlvkTYz+RIF/sGCbpfdX9d363+//W 76//9Ch/7/df/rBDs5gyeh4XQz/DJGhvhF58pYYmR11f1/q9ScMfVIoB24hBoffyLj21r2KWbtrG hxv1V/ZIcrWdAkEPmRwmsFxQMxWvXthhL+I2UOYII4NDNhTgiPIFCHQIXraccaapip0Wc+c7aHYW oQi1LLoWba0mgYVCIiwhEREQYJoGFERaGEIiIiIxEtCccm6WiWM7IR2dGSMqZnYrndEdmud00Gdq mRpSbqqs6I/hBmqLslKTTz+gztIIduJmaU+jtSz0jYzsvk8p9Gt3T07RbvTtzscIqo0NV10/Sf9N b9/CDpTv9J3SDo2UbN/q6Tf+gRH3IYP337fvudyo3/QpNe+S99P0/XmddrrV0lf19+r8W9uk3/jv /udGnt+vX09tofW8cb//BpL7C7ghQIb96QIf+32e7PahaOxAYtZz0N/HfpXTHr+jdtY45/zDlXGm 0u5ofrrZQ5hBagMLQUlFx+RMH1+hsGYuGF+gdiKt47xQvQtNOnP2aCnvu+xC2n6rtNAwhcMIRln4 tC0IiLQYQiIgwhGIiIsJxEREYiWTTMifJuYRVEYRqyNIqWZHztOiurRhHeZhEZmES1GECImxoqCi uajqfQTtSEVkoC5/OzVJhOyFQVMJphOzrF2i3Z3DLwTshJJB9NfPSf+nrkqETdXC6poIG09c1CIw Q0PugRH7f7nz+6BEftZ387+d9tTvp53ugRH7V0g++t+t8O3/W6O53pdpd+69raX1ujDnjZ77vr7e 1/e//76/ul9JdP+v18dPkh7/BqqjaH//3v+v//6//t+tD/CGCFeUsMev/VfTet9a77696MEdZhyn +lNBT8lISbNfXdN2t/9MfHev1b72uhDsR42GXgSVODM5S6QR2xxFMRsR0F2IqI3tbORoGC1BC/TW 4zOVLX4tNbTCoXnRaa441GIgwQi1QiLQYIQwgYQMIGCERDRB4hhLLPiIiIiIiIzdaeWkdFdYQiJg hk3AzIeRRFOykRKzO+M7w1OxLOzXU7EkdiedqUbwgy1AaoNShGoQIMpxEGE0GdgoYOxAYz6KUC51 i7Ox1Z2TEOxLu0XgY0W+i+mqLekjRRcNGjpKnqmnr7oJ6Cb70WOcfCbRbtINwm0m54NeaDXfmg16 nfVotyh/Cun0++ghaV0EDVe9ONONN2409Le8IX/2//WP49r+laW6pX0/qJ2IDCvr+I3/9/v/iv9X V1f/72e3zG2eV191dXp330UsHs9zI63RaghbUGZyhwRH47Xi3W0tX9UbulH8f2lajYYSxG+MKsMJ MbFQwkxT7BpNBQZnK2BfYphhKxT6LHO9DmgodMU00xtU7GL0KLgoeO0xUMIRYQtTOeyh7QhwwmEG EGEGEIhghdhC0IhhREWhFxEREREREYjJuEyBs7QiVZlpmXo7E8yGZ3NFWjtIZTo7nkbRKflCCDO4 dpH87NUflMI/nZrFzJUaZ2TEO5xKIuzWIQmShWmEGFPqQ+rOmblI6I6LupfTmhr+n0v+6nY4RU1N QifU0e4aphOIiH90nQIj/+/+gRHkd+i7pVO9F5XvSbdWWOW7Rb3ne/+rru9/+qde4Qzud9LwnRhz v36e3hB3QQNV3Px4f/dd2/7/+t9e+rxrd80DC76t+KSv+WoUqxZHl+vj9iP/133+r+//g1rt+vbx xHreqlLDHr302e/49z37kTB50X0P/Pq/1uDIx90/U/6BlucfFK9Kh/1od2v9qjOYe2vJDtjXqrP9 sLEfhluVvELtLEV8bhfYoGZPthhJx7SFCqShhR/FNe4vtU8znHu0PMOVFroaYreOYdtbFREGEDBC LQiIhgqERDCGEIiGE4hhCIYTn0IhhREwhERERERES1AtSyC2VeRyLIVZ3oiDR2hDLJ8gwhRb1ZF4 7KsIMqep0OyC6nYlkJnc8hEU8XyozXl7l8/wcmOCI6LdGC57OyYiZLBToFqyLtBnUJmvU7HENeCY XNQQJ+tZhwaBCIQr1RrYXafVcIahCl9X+4g259L6Ix9OiTqfq21O7myqSN1Z32jdRn39QSi53O7b 53Trc7296f3pzsZFyWdzvoZ3Kiu6Q1vv0WMXv/7/4t6pLjfGu3rd1/+WoMViO53KHX6H99GP7W6u t+dzj3+/f9/xuRDUR//7//fY0lFRD/57f29YZuvShm6dFbn1/N22+wvbdHQLDC6nQK6/x/3pRvrd 0Ki9jreKiOo4TEJrr+P42IpWIotQuo8jToaHFrF50iFqbZVF5/i083aGMwM2MRGdEREREREMIREY tBoRGTcVyV5UIRK+ZDEJXlnMlJurRxKQcEGCDIiLo7SspYyPKnDKlmMmw6KhHY3lRnc8g86RG9YI RmoRBoMLZ2p9oRo3NEIVvLdbENQh2E786fIOXnUIdiUWkFLSo10XH15oVPM4a4SCS/rbeuOez40b FTcJ0d9kK92p8auIdGf/v/zWeHo3LirpDurfur4pPTYIKu53KijOVF8p0CKHlLQXem3OZuI6C0J2 DZHYS1/+vp/36C/XtpfzQFwpcK+vpoR6Ef39/99f9/+3T29f9e/kY9uYd77OWur60UsHuowZMofT /t52MB5yIz/JwfrFG+p6cnrrHdWlfQ7a5KNb19X1//bX80DF9ilY2NiKO1TipoKHoQmIriuKO1H/ gzBBQ6p/qbrCYTWGmhPcE0Li+OPtC7OiLUGCERERERZ2gqQMIaEYiIjLTLcmaOZCs7VFJuNZfNZF SzpEKzuuO3i+SEUI7Vx2BMwMIOSFCcElBwZRaZznZ2CIqM7W0QmQnK5YECdoO5BxUg5pTtU5B91D 7ezp50YTC9GM9nZPI6CZ0CnZrEczrFzIhJnTsh+didQaTouO3YVJ925oTCnfU8f019bQjpb1NQRe 76L9oEXXCb5rPDZ8PGbqBF/+azxanxqrpbf1O+d7fVJI2anfU7tLf3wg9X7krXTb7d0Ndx03Yq9P /90tr+/O53u3SX7ozlR+nOwaI6L5HQWvr+RIMfpb+vpb1f/r/T19p67Yv91+tv+EIiP++v/+v1Uw 53Kjev2O411+37Eb//Sf02/6/7rdZyH/fwzdv0I/vdOtqCGxper/8e6Xfk4YBCmc+wwrqtpa2u6v G2mu7rtraV9Ut6QZuf50CtLGEn+v7FRFMV8UMUPEV8ULFMUxQM6urEVXx06tfGDMDPsafYTTjTtT 9DQi0001i00LQtT7qQ7tPi1EREGUyAoIheIiIiIiNCMSuOhN4mMdrkZybiaJPJdFWioR2SRfsq4v ksi+SiOxuUKEGVeQrO1rOrMR2J5Lok87VOV1jMhNoNSHw0yMQVeDW1uQfZdH87gUFCfZ2F9+dpBD pBBnUKdhQeunr51EW4a6u34RIeETfNbv+mwutL6nf76kL0CI+88Bo73QIuuaDRvBJoFdJ6dXp5s1 O7Rsz0fpLJ0eVPlCPLRnKiteIb/pent9FxEInEas0zBZFQf/SFd8NpPK5UC/6YIfhCK/T/f/7Vvv S4X6aGEn13rx+9f9/vbb/k0wv/1/Heg/6ljnHwRH/f9fvzox4o3zQMTkP+vXBBev77rGY4IjjMJu hhC86GdloYtbOUUu6W7aXWtfxvqIK+r1tef88Pw62vf02lG+dAsjHlpBa/q+Q/+NiOExGxFRQ/gx 4McV/nYXsUrQSSYhDehaF8cWmoTCaafEHEOGhoX2pui820oFEREREcRIKhFw4iIiIiIxFrlmCyLe YxJQMSbivK4WjJUyDyEyERUIlmXzIRnRpkpys52JoJoMq8hM7nnYlkIjIMjqlwzIpCnTs6iFOkzU IE2zs1i5/5/ztIiOgqLwNGxmsQ1CHY4Q7ViWd/E+Tx0i5oMEKOwjP9LXUEKVfXpvXCEdOkHVNVU7 HE/VFxVB3ebFujdVGzO/qeH0+/pPTaN1G5I3JG66X1O7ptng/Zh31pv6qdzvSFLb/K3nER8L7eRP Noj+jueNN/Q0OKQmrVGHO7s2gRT/enHtIN/rfx+//+GEI/vTQj/9f9zWwh1vERpf6T029x9dd39f 6/Q3X7/7bff/rX+/b65OD2e3+znfUVjP+1xm7/HZHCNnNM52c7PYz/+5zuK/1t15kVBeP+LfXX7S Rv/bdcaGThgpQLxr23XuFtW6bY7dAzF/GsRTS+GKfat45nKHMPkxzjnH96v8f1TFMU2+pgdn+LU3 Q0NDtDjQ7QiHYIRef86FOhM/xx3aHa3a40IiIiIiIiIiIiIiNCIYQiIYQMIRiJZUtELxERlpimdz EBAybKMjqTcyRT5fKkiua5fKjIXkXoaYTKnkKzoZiOzGXyE0LIzL51yNcrksmF0yKI6oLZ1CEoC5 7kXZqXzm4MlHkoVvhc69uC+fzUJzJLCLZKQiYVX/5hwcJ0nu0+nW/BvtVC9JAiPulBgqBF/Ruz8u xDq3T171aBEffd0d7u6Lxedzvr53O8MQq7SHbboJVre/q9f52I1/vp5XKgXXb/WsGC13HfQL/9// /9L2+hpP//bY7/ofe9aqr6/99+h3mQ///+qs5agyZlW1BCgQrSfycMRT67nr/96T+3axkoCzdO1C 4aTa/DW9av6n7H/jYj44itBVcUxUUDMCmUCmIoGbYEc9iNXW1u007Qan+zhepLdoNU4aafdprm7E RDCDBCIiIiMEIiIjXQMEIiMREREZZBYiERiK8I7RlcQMlYyuNxknpXUmZBSOuRrQYIZ2SZfOx3ZV oiqUhWdqJNBlXndMg47UBDpndeSDIMKQtQgzIV08/nUQInDSC6VmtEdAoQyULJRFzz2EXgaNjOvn cIjpToESz+duKnSZaifot++qwg3PtK3WEI5Y6T9a6dIN3YQilnCcKjQ0ZSVYTf+jZp1QIj77pQmf H3U7u+np/WbP6LvTm/Ppbq/bb0K22cq+rnc7xSff3fW16edzv3hm6+EPq2mjDniJ5Agvf69cf/rt /X/fT/69i2xv/8dedjbEf9IfvX/v/dr/H/6++kh3/Xtw/RjBD7OVl0YSz7W/2l99AhWkq2RyXLxH 1BCn9Zwlz3EUjBW+HdekbscRH3pNr9WtR1P+I4iOvzoE5+x29vvjUGcJ/swiPMRsVsbFAzBaX/Bm 3PGlDNyus1MM3PGdivQ/ebM6FEbTCHaccedFnPoWptjY35stDHVDkQe4jCERUREMIREREREcRaEV EMItQv5yIiz9Gf4kbU3xSiJXBUIiKYiMm4rlPl81mEDO7zCO7M77L5UIluXzsCy6JYRkXiDzv0dg eYR2J6ksy6lcEjIFFC4QdhOwgwnZ00wthbTOw8mYQ6hCaQQYVMg7JBpBYZ2t3PQVbmiQkui4q/q6 2jWylNUl1XOoTVBLv+a6BEfdJt533CDc79XQIj+gRH3p2DBJG7P2p3aBEfdeeBSBEffvpB6+nJ/X f0u3uvr1tisVH3r53O61qvW30K/39f+r/9/1nZqLVL//tlbZcJVfZ2Wgvh1b/1a//v9d1/43br// 67m/64Q3Pf98d6tr0kThja/W6bOTnvpf/thT/9f2dHcd6Trv1aTdrVqt9NrFRxpXr9D8R3rrm+rE cMJTUsRRMgeIo67EUxGxSptbEVsf7EVb9ZnKe0xVPptbTTU2ZujtPjzTtNcWmhEMEGENHfKZEGEI MEGCDCEREQwhDCFoNBhCMRERERERERERltjBybjaJciMMhxE8yS87ozEdq8lmZTRCZCZC0draKcz tGEGVeTswUrhcFL1pyCVH6SmLuz2dIw9slEXaIONzCP52SILdhO0zuxUXjNYndU9Gho0O+1T/Cf6 bengh+SgJo0MKaRIqcLzPujvdJ0nnO12p3f1M+E9Tu5cGdrX1paTou8GFSbluUPhU317q6v3dLd/ r7/p/9GHO/KFzud61dOGKp4Qv3+v33F/17/v63rd/rc0ZHChMjhV2zssBfehBgvx69fWpheYX/XH 9dKl/xH9///+Ui/xXd/0tpJnNScMXpLH2saX7+4z/Gbr/MjaRibPY2tnu67+2u/2lTGs3aVvfvwZ u2391/1uuVgHbSJwXf8RSEcRUUDMFrraWKaVhhRq3iv749UIpYMJcMF7WtOO+OGEOxT0ONDQuL6J OVEMc2FDnHsQtBhTozozE0IiIiwhEMIREZ6NlBwwTQi0GojvTiIjhoRERGIifhJxiJkUR2r5NxXN ZmsIgyrRUs7mjsTyVmVyZmQNEJnaQ1TlcljIWFCDSRsaZKApNNM7JiIMhcQWCZ2es6LCZ2JxFMnj oj8CUPrNGcQn0vVGiSoQlISe2djhFTtFwztX/p4QIjzDui4pN6QbebO6N1INqkr/vT777gk52BGW kpLoJ6ez360/09aMOeM7nfVow54/1f6vYRN4hhjK5UC9D7HWaAu7f497/3vXlbZcK/v3H0gtkRpL Hfrfj/9ffvr7f/r1/6WfCsue/nEVnIqCHZ7/t/7oxfjP8nDHRiBDnRBDjMIETyWkWLi8dr2l5KAq Ubav/7rVtqq1a1+lO+wS+qqwwlDObBrqgjsf4rj40I3vfBm2NiOSHKcFqGW5x1gxoFY35hyhyh7F RsULzbnn60NO11FC/YNCO7iOGmuLVCIcMLDBC0IuGEDCEMKdEQwhGdHEWhBuE1ERGf4iIiO400Iu IlpFiiJNitCJLUdq8T8Jl7IIQ8m4GZLTIeUZCZC0dwZ2jOx9BnYmR3hqdcpEYSkJnYkEOyVF0EDQ Z2YxlclkGg4zqETQZ24hPE+kf5FKzQYraDImC6n0CdsHn0kVGdzwW0wiY7z66Ldo0dIlQiNFf+Dw mjW0aPp+g1TnUddG9wRnad6DpNzQaKNdUm5r1+QR8ER6nSbZ4Nf0d9s7hv66BEftJ1ffnfyXTtU+ HRhzxp0EHvvC1TrdONO+u9Bu+z3O53XW9XV3lpBSlcqBe6vxxduv/GNvCLLP0/pXdV4ht9j+ytsu EX/98a/94/398d//+8f4SQpffV/3+OzwbPddE/nPtt73Pc6Kgweva32qt6kXwlc4T7U//9el4u06 2sNDOoT91i/mvxStpat1M5UfpCEjQU//H/WOLng4+uMNJhhKMJdrFJX0HJQEdYasMJWC0NxGwsez l2vxFeo5aQUrqxscm5TlD5blFqimpstfoENMUxTFPtIE08bsb4anPnPdxi0GEGEwQi00IhhBhNBx ERl7FAQYQYQiDBOI4tCLCERERiIiIiIiwhERGf4jLME0Jbq8RMkscrqiMixkPKSMR2TZjOz53aLp EZWTkXK2c5YVBSgpRO3MyMoJwQM7hG4J5hH0rkhmDKi7O3EBOG6Z2kzDJSrO3EBNM6qycMBM7E+R kzFBoLILwM7E6mEwmi3aqn2qZqCU6q5CaNDTVPXdO1mh8H2tOdmBKNngiPwm/enamd1VovM7/Sbp AiPdonFHf+zwbKTfPbekCI8k2FLSClq6q1f+rqnR3O9Xha9mn09U9PBOvdONXT4r1T087ndD3ret /9V/v8a3v//8a39XXO08XChFh/v/br6992R9eqr9//X//1/XX//161//1+Y2Ijvv/3Vs931Hal7X BCrPd9AhWrq1P8MHMe69/5aQKrasaTaSh21bX/tKN/3rilylhh/2+6H26eK20vx6VLEOmf8VFAva sUsRUx8RTqDNBRpiMMsIwkwwvnaiC6uFhhLtbG1oX7T7sbU2WvTGqGXhh7TTFMUPEE+1sbsdhCMz ldERFoWENBwYTXMOU5VxdhC4YJwwgwhl7GwQsKLQhxERERoRDiIiIjCES0lJRP4iIjJuBCFOyZ5X DRhHRnYllYRkColhneM7Ms7SM7gQ7FuVwXO0MvqE8E7CefRKnZkLBDpF2EyUxdhBnZI1QZU8JnZg JU/rowQt2pfPS88NU1vVNFu+0aGENGeSwSb2F6oER/0E3W879XOJ+CI+6Niqd3CD6BEew6pBsKk9 FpBa71257p/177W6SfSf9W6p65/kvJck6rZ+jb13j+/req39ehrf/1vFN7Iine33t2+v/Yy8v93x f96//vl1/w1/ceh384PxH64IYS/c93W66/V2e36McN/1y0grq+ktqDIx7fUc0FD7dYtjSuopbXg1 av7/jOyYQc341c9sNJn7EcufFtiKWk2wrrGFjGNSIfa6X2KjYrdphO1tTDmHQ1FMKkOWPjF2Oc+F aw0rQiGCERaDCoQ4hhCM3lPhH9EY5Q5x4tUM7TwRGboiIiIuLiLOiIjESL5bqMyTwiIybjTsjWdz R2fO4akpR2JhCviKjIUjslM7FEQiMgXlcLjvTCDhkJKdu7KWGAgyGapnshUkSmLs7dHohUahDUIR dJmpl9MhM6Zhktgp1RHFNTL5lqLzvO5h8NDXSRbtUFXzhVNfVU9c7EvTTCGhrr70g2SswqBEfuaD XhB54Ff7U799EY9Fv3QIj9/wRH1pAiP2F+6Thuf9bjVrawr+z39/SN6QQNP1udjP4VWjdRu1vP8t IKX/tkSkV9J6fabyJMuFY0lfyJMjhaHH//NIuF16F2/8R9f/X92vm+16Xr/7//v/p7HX/5hL0CJw rPd/0/XobU/Zwt6gmRxtTdc+nP5Ewx/Hz99XPr/s9lpBS4IRT5Fxt2r6V9pWEOYeK3x0hjXIx3HX rjvHVhTXq+sNR9QwsLjjVhhIpbjjo/v2cqCsLtDVkhyhwo0pj/aWMEKjSj4M2xMVC9imOOSHKH+P GGsGcL8sfg0Ihiv9pVQTFfoMKqn+GEwkWOccq2yiIiOI4iwjNTzWwqxoRn+zkwp/lpBSiIiIiIsI RDQjP8RERERERERERiIiWUGpNwJHM7uINlURNzLJWyXZ2BI7GmScdzkyJKVyqOy8EHlOyPmtkeCD CZLURyO55kMyFR2oR/OzXUIMIM7pKfSYQZTsjwIM6o/MMqER0FNTL52KfLozzuBvYSsJaLHaLdgh +SoVe1RbtFu3VNGdosdq8senoMIRrnZgQtIKWrwWE8ER990EG0E3Ix/hbu1p4QffSdBBtdBN/MOG qBEftIeqyQ9bV9Ai/706N6+ccz/iCI+k2tr/m+nnfaT7uGHN2t0Yc7+7ozp/q+luv8SlhgyyLhVf 3O4hp9ytgvfX9pb1b4huhX68tILW/pW99f//f/26+/9h1//////tjiO291696/8+kZF5/v4IFZHR HM7NdTC11mRQu0169bwRQ8FOmCVn1//f+6t+67W1hp+P/xEcQiObdN1WsR3t9PSEUhCtX1/gzffW GFYimLVtJtIigL/361CewthdZu9hY1hhWoR0BeNLv/xsU7FMbHjvWxgz7p2KYp3d50WKYpigZwYL Yp2O1i0GCYTCYTCnIiIjC6DhhBoRGhEMJhNdTkWhotILURERERERERERERFoRERls/iZJ1JuZZCI yLc7UZ2LMqmQpGRCPZIRMtTLSIhHMq0srrGdzzsEDBD1ITIOIVnY+XSnY6MOGR0R8j5CtBkUBclT s7iL6B2mUIlMR9TsKlIvFZggwmoW5XBUpNPXXOnkXrQjCdxEQyLiIw+lwtv0Xk0IwmgpBwRJ7Z1C SHaRon3c0Fjq19/3VtUg3NBooER/giPuSgEhN/1BEcZrBG9GzTrDLSC133ahBu1/3n6lO7nw8NGH O+naputtW8iTTX60bmkwjpXPh49XXP+bCnje/FJ3QIkRgJ3XvW6V9b9ik6X0vzH0+3u+/PZ4e3ZA 4uE3W1GhDf6+wxWvTePpe//1//7VN32oIp49Ub/EOu6qu+/+rXqufoIp6qXwt//+35j+9drH3ViI /8f/qbL/X8rlYYBCrzMFx3QjBCKO4RHSsaVq/rf2r9XrfdOReC2q9/jva2tnJ8tIKWqbC/sKgQiq W0qtvjVtKNWIr2MM3YqI12167SYYSJwXE+go2UObczbShTOj4M4UbcwmtjF4qNjYp/aa4W/FD7Gx WhUXpoRH2p9ioQtKwgwmE1hghan2SHR2g0OwgwpyNaEREREWdERERERERERERES0lJRERk3WkV7Z 2LIlkZBEV1OK4REDUrqeYR38dieCBkLggzumRiUIMljL5K4vko0zuER0R4rURaIVhBmQzIXplWMq Ig8tQuoVTseT0yUep3AoIaLHa63dAhHDIEISkRMyIFJR7IIGzqFIffW9bmt7z4wqoINravhPDDCS SNkLfaNlbxoER96nd0k/q6MOYejd3ne6BEf70brDnHMPRhzvq/uazO6tn7vr/c7GBiv6vaehr/q8 No+4Qgw1aetvdGHPGundX3+t2l///S3//+xWw+2//r9+98br9Va8k5V/167e7zH/tZFVtnkDD1// 9vX/Xtb+xXOjeRMMN9v2c3S/W9QhIux2mGG7/9rbeCFdd9Ah71wvbatWFfWONY0mIpNDDB+t3tpe tWvaR1Cwi1C6sRTVdRQM8i4rj0NimmcjhriqY4p4oGYIMTgYSBmahU0NDhrYQsKf+GE0Iz/EXFoN C9MK2cJsIRERERnIiIiIiIjORGoleeInZjERk3JRDuedrSK4WEIUjIZlcmpXWUZFmpCIhMnCqQqJ odndIg8lbI8SjyLmmdqiNx1OzWy+ROIpnYlggZB5U8g4hMiI7W4tJSVTIoSojdGthTW1QyUhGrOx wmrqekYK4TTfXy+fzp2dqxEzo0yWymoQ1oEUPOjs7VGmPMhQJOEGEOZyY6VJ1136hO6wnW61XWa3 pghhQhHSdX+z3pNQg3P+rRuWjP/s991O77nf+7uiQ6Sdqd/N1KkZ9I8fO5UWNHc8Z3PDGnUfoTSM BK7b2NXS3V/e/+d4brS7RnKjQzud/V/yuVRcKq3////dr/D/9f1/1//vV6X12//69NuiSf3/73Tn 1U3f0NGCq3W/+xGCKHhf/6X73/6/tT/v5wf/u+zk62o130tXTGlaT6uhFfd1HV28M3fx8eWkFKP+ tnu2+26sKRMF4opYL+xrN2z2wwusMLGkGb7V3TatK7rH/StKNd4qGCKHvFcbFbr7FPxsU1himN8M 2xJMcU68UvG0uscXiMccNTkQwTOQh2ha2EIhhMIacaDQtC1N8WhaFqIyx4iGCEREREZhyoiIiIhg hERERwj6ERaGW61iJblOJTJQpXUtM7G2Yjv41xfIXmQ0GCUR2NxWI7+IVEHEHFd4iMleRrO3Gdgc XxrD8mnrZKFa57o/kqEJp5KhPMlvzpJqe1TTvsHT7q6fNBY//CW4S/dU/dGuk/OznV+gRde7UIP9 /30/1O/+m0CLrLSC1wYZhK/dJ74pNvvozlR9Gc7yfMBCgMd123mmbMKr0tj4/6+19776W+qStNNf 1f7Q/+uEWPdf2q11Q0Pt9dt3m7Mf11x8jH/+WkFLhIP0CH+CHf7b5Sgxfj9ZkShi9JRn+67487wb w1pjWm0p/z/9Wn1/6Y1m56w0rVfC2KDMoFAzSBBXf8YM4Xja/Mlvpar2NiK8LDCcNO0NPi1i0LQv i0OLtBq7TiIMKgYQiIiIiIiIMEMRERES1FClpLKIUiul52EztbxldYR2PnZVkHmsiryDiF53PO55 CR2JZKRhAzs8QqOmd1ZQRHFhlSzGSyLpBkCyDyozsn01PqyH2maxDp6k01Jp5qCLaZ2OFJSEU9nZ r2hwwmq3BlOrOjTOq8/yuC/p+6NbX/e7S0a2jW9e95nU44auF2ccihv007+r/XpOjd3fvdG66TpP P1G5P/U2RDc7+d+IPvSM/e+9tudjM2iPp990PkTzYT/oTsuGK/3xt/GrDBl9e/sEn6q/f/6aEV9P 9pr9evfY+6/vFVulugX/v3+o9etb6f6tbmc7lR6ejHboar4Rb//V1X9VQ4IoeXHjN0EO6c9k4YGf oIYIU2c6Ee//s5qCHqdhMJB71voGTOOOgQ8tILVCKRu/TaobSvWh+2FhgqlKCkTBebtXxCt9J1U6 Lqlqf463ewZwgrBnC6gzb8wP8VEdLWTTYqFsRURSFAzKKgzbE/K4LtY1hqf+L1U/xcNLOWHQha2F CpoNMkMjTjlpBa4iLsE7uIiIiGFMiNCIhhO4YIMFBY0IxERERERERE2hERllC0W5mjK0W5ak5XK8 7Bo7Es6GYyDREZfKjgzs8XR3cXzUMqeQvUyNRnZ8qMi+ScXztIRDy6LoKdAhKyKcZV50ZvO0vqdh pM7UL7OkEwtgih6BhU108leuXz+mdjrKfC5/XCYQiOk0zqFu/l8/p6d1qmrnUIzjkXZrcLc1uwhS 6zXTsIV63NDpGCzRRcUoX6/f6ekZ6BF/oQed/O/Sel90m91vR3uk8zmx9N03Nmm//+9XXdejueGC SXa71ZEzI4k7nf/V+jOd7/9ONO2bavTu352CI2a799/+n1v9Av6/eNdt///u//vuP/p/TQy0gpdB kfVfW69d/7f+/1mH/xH1r7of/XwvNrx+vGxEYIZ2IB/vrqvwZPZq+n1ukijf3vBCn/9W+6Rguq/3 jP+9bYVjVtNbuiUJdVvSbXv8Gf7a1/P+OrC659XS2p0CsML8Gf7JjlbAzKBVLEVscVEUxFRT1x/F AzBMfsZ2MDDFNrEbFJRXlpBS+DjsIXaHRHv00GhxaHDVC0OwraQ1aZyYQ4xemhEGCDCZ5BYIRFhO whYUyIa5jwwqEYiIm0IiIiIuM/2hEYURETssUmz52N5T5fKhHUIQmdqWfzs1z0aiKoiVDKlkKjue SuL5TxfO3GQiO1jL53BFWjWMq8kIjpM7MHK6xnbiWnaa/rphU1JUIdjiLrpnWCYXTtcEI05XCxFw r8w1tdUa2SkIjXcKoWwtzW9BraNb5ofSNDqiT6nf1XYW1S/b5+o3Z3vO90up3oECvT6TfPBrpN0Y c7pG9HZdWvZQlYZuKMujCV4IunQIjqnRhzxpyJxHyPqo0K//T+9etlCMIvrTk6N4Ip40G6fW3iEy 4SvBDjQiMMUIYhD9f6ERv/r//endYIRGuEGhGv/99frSXfzH7f+3///19X/1/5hFpFi/dnkM3b+d GdOZE7BAwUoMWv/azI2c89vq+t+l7W9TkXw1P/7Ssf8X2+v/pptpLbatpeRMMFLDF9X02FjW1W1v sKPtq6ru634iu7Pfs6EzoxG8ZEwf7ViNiOKdJiKtdWGl7YSiPTGjZGmhqMcREVGkx50WdFphNDux CHYodili04cQwnxmRBhTHjQ04MIGEDBCGCDQhhCwpnK/EREZ/iIiIiIiYQiIjCEYiWVaSZXtEoIZ XCkdhowjsnkJkaRT5hEZl8lEd0ZjOx2Yjs1MxErIqWQrO6ZFEcRHSZ0CkuiWmVcdl0R0FOkEGdoy FoqEdpEf6hO8+lPJU007ZBDPfnWLvwqkoWdmuqERSR1gg0zUFBCOR6l29NNNef1tU+zqIFcJPdPT aptPNDJSETvdZgm0aGlUhThBvIvPqv1f/Wd/BEf5blu0uup3aVpN1v7PBrvSO9Jua7PBrcrO++7a 7537e+jDnivat8IO9Wr1+9OjDnh/2NNwy6I9707hsUnFateydLCBCCI+WkFK//99fX0t9+/6vX9e /0rxGv/T1gielytgv4QxaEcMEU/+Kj+/96V+1/r1/9V/4X+phD9v/19CP9V9/rrdd6dY1uv+wQoE N1nCUu6X6DB2syJFAxOidq9S+WkFr+s3OZzvtvtJW1W67Cw0nSbCw1tuurrjV1ycLattpfXxBAhj n/Gl9D9qxFRFMMKLFMVSsU2EnjBm3M6kGFhm5pUI6YaR1Cwwl7KHM5xwvp/sU1+1FNNMUwg0O0xV fsUhjXPsTFSOoUOLiIvvHaEREWgwgwmEIiIYQi07CxmP2oIMIcWniIiIiIjPPCcRhCIiWkFKWklY iIiMrrGZCjMZqyso65Wc7ojuiKfMIlhFTyUBCFo7pkqIqiJZl87JMwinM7AyKiIWjsIzZSuVhjtT yVTyJWImmmmmqp6aYXCpoMoyfJTF2EycFzpGGmrlpBSrv31anY4h2OECujW+ZY6LhkqCLa6NFb05 o1ab0DjmckOoV/3ou6pTvunevhNpIER90CI+6Tb0lO9JuZy41OP69ME37/6CFGcqM7lRX1siqOJW GXRHiKI4spaOaq87nfTfTfT+/dOMJulbWjB8Um1e8iYYb3pdbut6cEI4jCYQoJgh+u3r633Glv+/ WfZcL/9+NY/79//6///6//9f+/9bDWWkFL+qs6K2e/3+9bWdFGKwkbmM///39qupz7pf6+mmfr1j urSmcp683Y7b/36bSt6H72wk/2q3a2vbHVrax4rqCHtWOhd+ve/tYjtaWz39bDXtWIpiKYaX0rDS bSaC/HYphfX8/aYoWKDTEIXjHHYp2Nppiug1sVFDi8m5T7QYQiIiNCIYQaYQaHEWELCDCDTQiIho NCLBCDwYIRERGf4iIiIiJaQWolclzumd/Hfx2SoRJRnc8mxqMZbpcXztVIg8EGCDCDQM6xWZBoHB lSRiIOJpFXF87Jo3lXhMgkXyfIHF8qMg6uEzrJpp2ue9kE2XBwYIZ1CUelwmE9F4wupfP69kMLW5 rapzXRso+NGt/Vz2DngGq7hbi9BNr163SRaghUCI+9O1O7SurV6f+azOxxefkjdvne87mf7zv/0d 782R162lvur/23ZEwXp3BE98CUcX/+rNAxWvd/+aZsJt/69et+te6rb6re//9f/f1+1F6//XeY/v Mb5fjnsruu22+fSH/9SY5If/8Rv/LH9/bpj3S7V17rXH6wyW8BwzdDT/WPhC9kfI736f1GEf13pW uFtVtKGEuGF5ua9rnYjyaaxmgLz/Y0mgvxEcagz/vrzoFsRsVSURscRxHW1bGKFRS/x112xXsR+l aaFpQwlUWhphSW8JFhuU5EcMIWh50JododnahUGUOEDCGdEMKZGZERGCghERERERBhCRCEYiIgig EjUshUgUm6OTZ87EshmYyEwQyEyF5kJxloGCveRCLx2OM7E8hM7nkKzrFQPnZhL3aCKcRc9qZJVY IaZ2oC9kX7o/p8EKYXzBL9y3XhUbHXS/o2MtQYuu9Z9I3f2FPj3n/8/f3vrGW5KiOiOjCWdzvWzR GzVi6EigYboVf1Gn2ycy8pSs3Ar2+rllWVCERGvdYTCHWvdX/46EaaH1f6X97rmHow5TgrljlOZ8 V1q/36rob45kX98aP9CLZzhCLreCHZ7tamRGf4Ifa6/4a3dn1H83W1hR2EjtQF++kb9pde1YquGC r9XFAzA5Sgen2rBmCc0DEXFimENRc/xxoNc305xuNOPZaghRYQjQiIhhNCMyIiNDMeMZ5xERERiJ XVETcVRbKRS3SzKnna1msip53PO6YIMqeQvJXEfILndMqeQmQmCBmQjNMhcQKL5UZri+NBko/TJb qdwgRQ87iCoMlqUleCKHhKyUSDOx5MlaI8q6fmEZqjCP62ahFuEXDv0a2CGCEYQ0a5KQgIRq+qph CK9F2zI4TTT09dU309XpOlpJN9QRf6nd1O/fp1X+tAgTdGyjP9PudlqMZHQIof3O53ozlRnc76dG cqM7nel370tozlRJ8wFNMwFq53O92v+l0hrv/hNCI6/bpddv6W/b11/r7tPT/97Wu/r9f+v+v93/ f2/+9a//u8w5x088FP6+2I4j/ff3ghTU/7p/t3f3W3/7rYrjr8UhDYqL3/779nv6643tr++v9pev 72uFdX/XVtbvBm6DN200o21WW6qGAZ9rS2K2PiuNjeK2NiKaql4334rYqrrYj4ii1AVbx2hoXFph C41Q0LQtDi4aHen2kb7Q5oK64sEIiGEGEIiIYQiGCDCEREGCacMLQiIiIiRiEREYmQ2ivmd+jIjK 0js6OzVECVybKmQVERmEUJMhWZcRHak0OHZLCI6I5FKCBUDBAyFyDOxPL5KyKnkHEJkJmocmw8So UlEE07QrQivhoRUcGmSj2GFtOzqIp09OW62ECxYX+W9p4OZ6LHUzkehs7zjhpujW6Cv6LjSROM7n dzv54NfhI2UrncOpstM+MQ9X4toz+n5d/umy1BCzud8IP7r2NNkTzaLpRq6cT0NWO4ILfwYZfr1s lOCKfCEnRxEfX6cft0K/W6umEI97/dK0C/uPW6ciTQjwmEI/Xr9v/r9f+ZUwkvfa/QRb96v13+n7 +59aW3+ozd90sJOvneN8iYYOiCT9eoan/Z7Gf5OGP/xxrek3X2sMLEFdNpE007CtRCe1VtIfJwwv 2F96bpMRTYLWxTFQmOKimKDMEC2Iphrer7KHMoDSixzdHaYodoNU0GpGXCeFtRCHmRHF2KtNNCGE whDBDTCYUyQJ6wYQaFqhwwi1FCiIiIiIiIiIiIiIyyhaluSmVTMIqSISJeNYyE4M7DyryCR3PIWi p5Co7nkFR2ZZ2TI7SMxlQjWM1GYyE6p2mahTUI2dEqBndyakokzs1aZKYIPJUIdjiEogg1CZ1jD7 OiTTqzorwRdH8L4VSD1dncj2a031048KupKhCOiaBJoenT3zR9P0PO+3Rd0bP9B6nd9Tu6ndzDnd 8/UXmp3ZFEhDSSfRn17pN0+/18iaWhSaKP7EEvczzZL71vW5E83Kowh9wnzud9N1Wt/T1f463CZc LWP7oEkvaGv6/6YQ30v5zv2/+9//3/++32XXq/X7/1/192uO//X+v//5hzOUPvVqfue2z3EYIUDJ mg1Gf8V3pR4z/s9tnN61/2/6egQ/uicMaEQ79CuaAvH0SlbpfqxrS/Ghxhf/tY1hqlatrX4jfpUY 8GcLG0urStK0vrtV/GdjAw0rFBl4EwwkxTKHNYLJKQQvMfN175HtEXGhaGh5uzdH8WlGmg4sU0Lj wwhp2munmNlJCLiIhhTIiOGEPcRERERhCJ3CEXERiVmEsvindkS6NwybFgU79FQiGZGkSsjvIuio yVxfKhEsiPEri+SzL5KyO8IlsX0GEGEM7Ws7jMIlZUjs1VppqmtqumrrYTtBphdF40XbSzpF2naZ V+bfvOoiNEgxEaIXdbOgQLa6ujXRrf0HQQeeT9NdGtmoJr1qzaVJud96BEffnfoER9539N06O+0r q/qd6O+91tnrbncqPqjOVGn9yeI+R5a9GcqPvXr3ut+9PvDN2va/Vzud+OtV97pfzUaXhCI/67S/ +vXrX/XYzssi4WlevV/fWvt/X35IBL/X9N///3///0v6/3zC/o27FbfEf/hEcBvrORf7+9f761bp 9W1zaWfZJn/et9Wkv36f+2+GqLQ70r70t1fpvV9bStb6tKI8fY6f9b7+e2TsLtZhyhysvdMUwnYj pWI3jYjiKiKY2KYjYMEuzl9LEcRVvWLDQuxUIRcY2hFhC7CFphMINMKmmKZz4xw1hhJtR9xoRDCD CBhCDCYQMIWEGEDCDKBghHERaZjxaz+hEq0IiYQm0ImEQtCIibQz/GE0MRUhNM7dBU00zsDxErjM RlutZVUp1CELzscQhMIZ2ahSUBCLsxEpZiOzVmIlQQlZEWNAztayFZKzsheS6M7ZHRhEdBMjxCom TVdVSpK2/ttIoyeCq52piEqEThqfRoC+IiDVyUemgplmjBM+5mCjha6ba0YZ0a3BA6qjQ4dLW0CI /a6M4r9L+nrSf3pv0XdE3VNlOfz2aObDxS93ppzkRVG0pLtsjou53O+y6LzZtsM3JWr1bZdEd2u+ XPhCgQdXBh3igm9fW/9RhCPiP24jjj/94jjW9r8fkQUfv2//+jf/S/UJK6fta+qr/0o1y1BC/d6g mRx/oxWci6MD/PuZgo4V9XqcYdF+32z259PmMInFXx2u/SFRH3i//n1trDShhfW1iNDi7SU0J54K fa7SajVgts512c9tbPbadnJimNirOXsV6UWtXi7aVihYoGfdmHK+hjoWMcaHGwgwg1HTTUx8/5oK HocKvYqGgwuh8dhL4iKiIYTT70IeWOWOUPrEWoiIjP+eaFn9TzU/55xERERhCIaERiIidMRERERO rO+MRk2fIvlazSOyES3OwaytIp4vlSRC0SzL5Lcvnd5hFSQQMq8IGdpaKfMI7MGVVFOjClul4Wy+ YyVC0SEmpdGaWGmunadhdNOwiQ7NStF2zrGJVTIPJTmGmaoxKE7LULqEOIgwuXlz13fB6/hXWwrr BA2noIPpnasIFzqJaaNDtBnUItjVkIPRMf99V9zuG6O+/nfo73nH+k+9XoER7QIj7rzj0m6Rh+gR H3z/nxNwQNdU/+QcRRG0R0CKdCDDIojiVdyJ55KRNHEXS/f+9kTRtF11fq9U6O531fO5Ua26eqdG HO+vqKtvj+RE336hNCI3CYQ69MEKTCEaXr6XhNCPd///f7X0t//rdfvX8Rw0NiP1OiCX/6/+//// //9/0t6X//2/7/s8nhruM3bCQz/b1DU3Rn+31/fQan/qThj//9qu3b1/X9/7DI5trxYMw54tzZJR mEYx7iEv9D3/rer6iqx1HFLf3rb8dWlFL6+tDtX8cHpvH9BexHXqxFMRURX7Jucdbrt0xFPrSgjj jddumNItQQqsUMw5h7WPXjTBCrQ4vTTQvOiDiM6I01G1xQqELGnjYobP9hULi4iIjiGEIhhBggwh EcREWmhaGTHO5x4i0woiIiIiIiIiMEIuIyyAuVwTEZNxtEIZVpTWRKs7rzuisrOQrJTmSpnZePop M7URiKjNeYR2KohOTZ8hUmXwmazTCp59HY6zs1ScMgqyUdqeRKYuZ2asu+JMHVygMJ2prEIcYuSk IFtFu0MFRofadp8Gnf9x6ZF69+1XOyYQJafSQIj70HUERvoP/7zDh/v87nd1O/eb1wnmg0JAiP6S JP0CI90Yc8a9K0b0ETHit3kHbvtA3T+/70t/QQJfGg2l3O53zz1Ty3VYuFr/6fFBPTt61+Lf/f/+ +IUhgv2l+67eP3/2/7/7WO9V0tfjX+nXCBHP67r//6LUSfn//+6tnlD3paBCgQyHBIEKBDV0u9IE NLnI3/er9tn1rlqCEMftvvW6hgnO4y9fP0NdRC0puxrGtBBLfa2k/X0ThQsUo/9WIqwseGKsLuLK HNvChzAwgZnKLThS2laUMvYEPVim1jXvQ3XW8U0xS4OxVY4vBUP40Lh8XDTEJinY5dlD2FUXFphB hMqcQcMIRaqnxERqY8RdhC1CE5iMRERHEREREREREZNxbctKfJsqolIQi6Enys5hFlmiQieIozZG szslI1iELRCRKY3lRybDxK0CBJqmXRHRf1TO1EYZ3STCGm6arZoC651JZbrXhCOcFERB5ePQXtTt xCbJwlQQOjQ0aA0YKN2u4+67IQf9IER96QIjypTwXH0m0n/mg0adL6N6s5TXb/r6p0Zyozud4wm8 ufT07nrsUg3Vs/v9DHTvtfd/0v/v//cVT1//7pfiPqv/bXbXphf/2v+PCq59Tgv3//tv/f3/6Ri0 p5HkvurhCoZH09/BmH3rFK/v9rEdra8RHa2p0MEl0I7Pdq+emIp17XtW0thpNpOe5GOE2kxSFMt1 r42KFqnGhYp2KYqalimOMGhig1BeeaVoXYIWhaaaFphJtBoMJnahUIiz/ERERERm5CIjoTKmWjRF GIybPiRJEIiped5kURFIiuROIVkKyF53OILFZzCQZHCHRmI7W87n1IVEqi+a0E0yVyw1vIEJRIWX RmsoSl1RhGawqx+dq8xEYiPqd2s1xflutBSUhAuhWEKg6MZ6OgSi8fwuXk1u8vXVnrVaMZ6W2S7t poMIRghhbpJLa6zuHrpbrLj/X9ev/roER9/hdIw9VQIj72fmjDnfO90b9I36DD353O/3QQa67//d /9+vJQfvVPP9G/X963/xNIuExEORF9e3f4/X////uvhsf+8ce8iKP7f+qesOIv+I3iNiOI4jiOI3 ///+uHvv/c+nZ+ufRKMEobX72e23d3f8JGFf9WfTn1/DlutpK3/WGR0FFeOIJhgzd/Bm6ThgGboZ ugzZBmgp4M3QZu3qECt1j4MFjvVuhvqxFIR+sIjV3tq7rW/T49fsRQS4poLHsXRJ2FUU1Y8zuELW 8dcw5X3rf2nfadqNoNeix2xQ5yRMJlTTVGaoRFhCNCGhEaEREREWEoiM/4RmmoiIiIiIiIizniIi MmxQqzITUtzJoMjoj5HReIuikZ2QiVma4qZneGd4RLTJaZBDO8IlplXHTQzWZ2Bo2kyqowiCI1Mw UrrGE2IiKtBnXNyaDgwmEGmg0GE0wmUAup9aaawwmmS8Cl9bOqNxagNSuC+i3ckO5ByDO7CejRkI VGhzRRcNGii3zQ0W7mh12yf0aGFuGrnSbW2ph6DTH3Cbc9Ok/BEfpJue2k2k3Cem4TaTcJ0m54Nd 9vSbgiPuSs0CI/3oER96p6QIj31cMNpGw8Om6psl7pxWunVtJ1enV6cabvBh9Ok3hh12m9Xr3VOd iV3rBhjXq6/Zmy4TsIsruvX9WvVr7vhhj+thhkfXdgi/9f/6f+37//9fX37/9//Xj/+kOte9e9/9 +vQX/V0vam70GG6+6/dat0++oS/awi43+3v1jWvwQq1BAjldbdRq0P2oYd1a3Vq2t1a2tqixzDwg R7tb1IuMO/Vsfq2sUrVW9Km1e1pIfbSOuFbVtKwrDStJsLaTDCTaVC4S20mIquNd4im1dRlcFooI cULFB8diogmKimKYpimKY2Kin0NingtiqdqITCrQYVtNCLtQTQaDCDCDTCDCYQaEdpheGEIhoNCM RZzxERghEREREZ0RERERk2fpoRNmJNMySZ3TlcsSiJ2YREI7F2dnjuiJsXRhFXggyo7KyiMRBslo hKUpCI7FOp2RKdiWQcmX0wmUsFzs1ShOzqNUXbOquGoUvhBqQcoVP5hH5NI7SCYXkH2ENAdJ2txo IN3w8LaLdow1z+CkO/p6aCSpbbSeezR9AiP6JDqn3JWfvCf/BEb9+taNApGHO/ne8/Hd04pBvet4 IP34MPR4eruelvBEh0P/62q7NIuFX137r8rhJfdtf5FA+t7cUaRcK+gTb52XDH7qjf7rT//19KVx gX8fr01+v/hhb1+xH/+0jd///wQKMEG/74KRxQicKZHa3VGro3UOGoRQ8wlRkbTev49+r/DW1ikW cP1OgWwqFEoG/3raWO6LHzOMvoRFfBm6hH3/Gla7asNJkxwVB4ikmGkyQ4IjqF+xdR57faP9N7T+ r9ihpimKFiExQaERDUtwTFA0IwrHYycMR0v4MYM+yzepjxcQ0wg007TCEMF1TsK8WhoQfeIiIiIi IiIiIjOQpuiLiMsoXll9CLQncJ5NxZEKiER1VkaRKck8giJMyV5CsheQrO6ZCtMhEQRnsjDJXGIh eQmJmjqikZqEEhOV1lHa3ksSZB5oC5rQVMvF+HeFL6n0E11yNarDTI+Yd2muSlZTpVUJpkYiOlOx PldVSZ2F2CGQ7oIcRDh6npbW0XDz1n/Panoh157z1DYiHCbRoe2hghk0C56RnaN7CEZ2kElcKCVa 9zOW9NgiPEoP9AiPu/Cf/9/f/mHByEfTpN0+v6QbptV/z/3qEG0b1PicGHv196tv3v2777u0DDmy 39PVz/n/N23p1dG+jDnfRnKjvj4747dsj62/79d797/3t4h69f//Gt9evGt9Lf9KvruE1Qr+O+OO ONeONJW//6G8W4+///umFu0vc+vwicZkb31fSVVBDVSHAk/b/39n0qvV7n197bwhVl0R4EN1hkc3 XImN/Ru2qoznH2lM53c2ZnKejdqZynozlRiFpVYW1bUlCI4oIpwwU7HRcck+1jhggSf/+ojq0ou9 4X/sRWL2Fx6ehf2TcKhfHhQ1GGk2lFIYQjCFT/bS0I7b7xgzBUGYIKWKGFjtbTuGKp/9pwcfa4Ji gxTFBqFwvipj9qKi1U/3an9BqtxEMIRYQiIiI1iItOGmE0GFOMOjONoNNCz/FqIiIiIiIiIiIiIi IiIiIiIy3SmWsBZ1KCBlfkSlEZlZRhHXK0ioyWIwiW5hEtRhEty6KvJYjCJajCKtFRkVjZHTKyiU ohaKmjmSoIEGValcK1KlEKyDyFZGarhO7I4pKWprgRQ8J2FUJphbKeChNMJ2npv2mQOTCDs1xfVE 3adT6RvDyUiHUSwQ8/qXz+vENbQjXW1dcIauv6CB89dH86fntrC3OIBA2/Tp9JaT/9bZEHaBEfdU CI/cER90cfoER9tV0CI/fwvf/funV+n/70jDnfO5x9o3q/+d7o2Xr0b9bpPq/Xo3pGfdb62XPvIm u/+lud/n9ft0tkSDFdrTkTi4Whb39frf/FL9etv/Gt18zZcKaRcL1t6ZcK39t9f8fZnFwv+v37ta uOI/9v////Vff//SXoPx/DX7BFD7f//8fzo/+7SN1z6V31+/2zyvX/6f7PfpP7TPzan/1q1P1D0o j0v5xGqn/Vtf/fx+SHzDmHhljnf9WtesW/V6t/6xt/6Qrj9ghzwceO+CGra+vaj+bm2l33+vcdC7 Quxq2kLEVxGxFRGxFcRTGv/Hj/P+puxsaWf2wkq62KGtj4prT/4qKaRotNMJpGcp7sUL0sty37j+ DODWGExUbFC8WmnFhC0LU/oXGg0GmmjPDCaDTCcQ4YTCoRhCHEXF8XYJpWFURERERERERERERERE RERERm+IybPnYllmC2IyuCiqQtEqEOkbyoRqR2QynypmasqhnfGS0yCMghkvl0S0yWmS6MIkamsz LVkFZLEQYlNU1uzppqRrCDUJ2R4vJhNMIMJhbCYTCdqUIi7VMqWEGgyE1TKvOxKovGd2KRcOjA+q qerRbuj+i4cRDRoDRcNGho0OaGujW0XDW6L1hQgkZ3zPCLede1P6N7NQQ7V70E2ESfVQn/6hP8Jt kR2k8JtJunSbQIj7aTwm0CI/+sECEJJ9Jum1d1ptL9OEhn/Z77tX9J7/RsvT706vT1/e9b7ulVN6 TdP+6vO539/CLt+xq7EpO6NGXCdt6vX+v9X/9P6//teRIF6dK32+v7/2li3vg1DvX4YV/b//7r/9 V39jI4vm/zC/3+yOl9d/rsOtGB1J1obU3ekPX/V1b3//bp1/j/6WZG1tQRQ9UI738EU7SuXyPhJA iOMvkoyOlq6CEihoftZnOPtK0uHVpaVrYS9bW69QZY5h9hDbX96dJCKWP+Iy0gtUIj30IrP7DC83 PthrQuRTjbUSNJDKW4yKghFaKIo42IoigORXjY0qF441+1veb/30O6PlCjYhTka2tiF6GxSFxhMI XG1aGxTXIxzvQx2KYoGcH5j3YwZ2nkyIh5wuGEIi0LQaF5KCobUnZ3ydlRmsocqMscqzvmHKgq2w kWOU57yWAiPsIRZSMw5Q5x9NMLERca4iHGfoiIjOQhgheCF2hF2EI8IRaFhCPORERoRPIREREYiJ knxUccccUxxsROxmWuKqW60KZBok2a4qQhT5BAh2ahCDiUhCUBCUBCUhDpkLCEpCHRmMq87VDsqb KpnVHM7fGV1LCZUo7+UIORllS+kQmpoC6SWln1pdmsRNMgWEGRUMIOyni/nYtF/aL5kqCanqZ3Bz qNowSjJ0jBRwowUcHTRgUwRNqjQ2DKftFu13C2p6W/CbSp9J57fBEffp54Nf/f+tExyh6TZK3vCd ngt9WgRH3fV/6MOYf/TY9ntJ9z0jud+ehp3PTZ7c92crdz22cldAhapwwfavUIPT19ugRfvSvVOU qLhG3VwQJj07j9uNW4444344/x8MjP6sVv/36//9rwYX6X+v6+l6j69/CfW9f/yQ//1+7SN1D1Yc 4S1SMD/OD6MFHCjApgiRgo4Stnl4ROIKraV//of147bx9Fj3oGH3r/7r9PPAIj33UXakXG0h2r1a +qLH3X99e6PUNTpBbPbEU562+z3DCTnqz22e7OSjue7PbHsNKFbCJCsLasVGlR6YitzH8UO7sVEF G8bxxsUhxocbTocbCRrKHsVCwZ04jYpoMU7v2hFpoaDUFhhKLWGv1GtQwnFw1Ve0GE0IsKIiIiwp /jN6FG9DN6n/P+b0M/5vQiIiIzkRERk2KGIidMRERERERERERHZ3mQJkFeVrO553TIVkKyFo7OiF ojMuiMM7hEEMhUbynMk0diedVK6xwRSpUGVGEGSyL0MhZqQeSkIQcSgKSgISlEdAih5KBpkHEoIK SkIFsJkqzDW1VNTumqZA+VwX8qn0Yz2jOzpcztPhghWukoQiOKNQRDCS80NNPPSM720W7NQh24h1 CUfyHXu1Ln+tpB+0nRx0844ckP0WOnmfPapEx6XMOUPR32k3SMP3SenQTapL//dzFvvVX9NpN+DD gg60elo/4ef3CB53O+f+IP709U9/m+unRvow53o379++1/+r7q+rYhurNAw7mbLhHb2/abXv2m1/ /t+r+/oUvxb39f/xl0v1/0qi6j9jjjY/uNj//9SQ/r67/be1X/rWrEb9l0uu3R0wlzI20jd/3/3/ /0OSHa39Nn0/59IYRQ8LBCoiyJg4YIj1qCEU3V1xBEsC1kpCD5KApFwpKAhKAv5KApFwvraxSz5i PW1QYX8n0GCcw9CK+0zdbSq1YiqSvCXpJJJdqklEUwwk67zDlj2KbSJwx3oR0f6gzbJToQM4RcUD MoFNQUsDyxzpMznLDDlFpnBSwlipnOVlqExTCrcROYaY/Y5Y/wZmoVUI4tBpphNU0LQi0NC0LCFq hYTCYQiNCwTCnRFqESMd7iIiIiIiIiIiIiIiIiIjEtzJEhFetSyB6ZcIU7IvkHkLyKVkKiCxCogT JRkKiTyEZiO7RhHaVnRHZ0SRSupxfO6Z2NxB6BkxkJRhOQc+QxTIOKEMCZDAoQesNEMChB9fkLwn Z2JaplSRiUjUFL51zdC52OEe5CKHsnZT0W78vn/r3sIt36nrb1vOoSQcVaDz+dPC3YTrr7PAftjw m5/r881PBro35vU/qeaoPN6n/8L0CI+/t1OP9Xt+877m6uNdBh6voFX4QIad0CoILQWECr0FoJt9 1r9H/Ph4+9/o8bqeNd6E7EBg0i4QECIcXCE4YBhjWISvxSVsQkIQQhIQktiEhCC9ciUXC/naeLhV FW26W339f87GrX6r0v/YQTEYQXhBHEgggggji8wggggjiiv//3r+uGF/9fh/25kWp+sNpG7OildI I9YSPfoKwgj+gj2grelCCPaCu3+fv/P+/X6Q1Xap14PeqZz8VsGDH/CBHt1CWQ82iPBBK2oJKElB LCS2uEsElRoKH2Eh3vUfs3WrsfIx4IVfxSt2+ilhjXyHhe+wS7SQrF0O0o0ONDjWOPF2P2Ir42+q Wf7TFrqditiNacaQmJxpDYq/2KXXjVadhVtV7FC1+DOrFBrGGpkRp4Jp9qc8RmPDTOdTHs5850jY UOUPmPZzxoRFhDz/hCI1sIRiIiLCEZjxERERERERFoRBxcRERERERiIiIybDo7FM6orKLOSZXBER JEJnZNSusRNHaqQPIxJkHlnBinY3kKyF5CaknkdKqcrhYTs7UBVPZDrBCrC/moRT0EIzqEo/+nrv dOl/CT6r8IvNc/X/RvXPsq/OOZ9vPOjer9D+23X4k4YzswGCJRgIROMBN2/xxb/48NX/1tbVfYNd 7W9+hqFedGz3Me1N2puv6G2fVnkh7OWp2rRHwqLHBEfBCoZi7LPoGNxrGv9GHLHlCCBgtggScjH4 2GkhFUNsKL9f/+/FwhHEc/6sVCawZwZY+qmcrI777sb8sc71/N0MKcK0fQi0INOLiIsIRhCf2f4v EREREREREREcm60jCIxEIyXZZ+RUI7SGU6I0ipZCZCZKzOxZSuFZ3XnYlhO0y+EGEGWhKSZ0SpqV cnlOlOspByZ2BydT2dwKdkxFwvM7Rbu+7Roef03JSEBDQyHaNDT/YVJAiP6BEftIPQffdJv0CI/q qMOndJ0CBX+jDnHRCpGHO+tut0ur/yC1PfXc3Z/We+6bS7v1hu67X/9tX/0+30t6HF2916Xw//9/ ////+oML+3j6v7+K//30v33UEMENr0P0u8Ewl/1X9r//1tLSSSatZ435FUgy7J9AyOzqEQ7W683O 28e+NYim1hqyhzOccJkhyhwhbSz+xqhGhGrJjhWkxa66j2MMU1FMULiINCLFexSJuCI/LcqDj0WO CBxYpiFdoWhaYQYQYQYW7QuwmEPQi7Q4YTURERERERERERERGTdWyoRWkWcEIrlp1TIWEJ8kpnfG d4Z3xktMlpEtM74yWmEGRXP5KmVZkmiLRURvykM1s3yupxdHeZfJY4VlXl5JUGE0wmmmmEwmdg8o 0XbUIMJphUHdwSep2J1bC2EHUGCGjJ0Xj2jRRcNGhouGjQ0W8IuGjW0XDvQQfRncztFuzUIlvo0O nOye8LabkSkaNlzmHDX+0m6dJuE2k3CbptLp66vSbp0E2rBE/CvMM2km6v873Rn/Qb6N9Bho33Pe /T03Tq9Or09PTdqr+65vp0b6+/3Tq/dfpd/prEPjF9fa69f1a/a8fv9f3Q55Kvtff76/f+//qIZH 6/////f/7df/tiN///1///V2pDwSbRhgj6dX21+6ftLWY/Vu0rTXpz6nH/dr0+CKdhLev6/EcQoZ d4Mw+1urW6tXW0nVuvbSYiojtYZHQXJ+wlEdraoR2+o0mLXhRufVH5tJtWGlYVtKGk2FhpWF1hq1 Io5Q9tJCP2OWOSHtpMUwViNjpKdGCRFHxfTFRUUxTFMVFMUxVOGKGdGKkY9dqELsbQM7TxhBoWhH m6ouGgwgwgwmEGgwg0GEIsEIhqf8jVghFhM+xrERERm5CIiIiIiIiLQiI2hGJayOV1jLZJNZXBfB D3a9ztZi0huRmnf2ta//73BCg00yEaSXQisGZsrJnO/VC9xGMmyki0giM+V1iOy3BNMIMmxjldSE VB6M74V0a9U/n/12k31G/e8mxDLhO/260vttW7Sef9s5MRTEUP42mvqIj5ujES2S3yNpwWwDSIO0 jIrlmUZ2tdzY6rfvd/aBAup2W5HIEU8tIYGBCLacIcRFL6mc4+W5UFPYOzneJ6aEXJsHAwf37XDf /d2PtO0IyI0xxERRbT8f//////////////IDop/3j//////////////kB0WUf//////9d///IDos o/////5AdFlHyA6LKOACACAKZW5kc3RyZWFtIAplbmRvYmoKMzAgMCBvYmoKNTA0MTYKZW5kb2Jq CjI5IDAgb2JqCjw8IC9MZW5ndGggMzEgMCBSID4+CnN0cmVhbQpxIDU5NSAwIDAgODQxIDAuMDAg MC4wMCBjbSAgMSBnIC9PYmoyOCBEbyBRCmVuZHN0cmVhbQoKZW5kb2JqCjMxIDAgb2JqCjQzCmVu ZG9iagozMiAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1OTUgODQxXQovQ3Jv cEJveCBbMCAwIDU5NSA4NDFdCi9QYXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8 Ci9Qcm9jU2V0IFsvUERGIC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9iamVjdCA8PAovT2Jq MzMgMzMgMCBSICAgPj4KPj4KL0NvbnRlbnRzIFsgMzQgMCBSICBdCj4+CmVuZG9iagozMyAwIG9i ago8PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajMzIC9XaWR0aCAy NDgwIC9IZWlnaHQgMzUwNyAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEgIHRydWUg L0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDM1IDAgUiAvRmlsdGVyIC9DQ0lUVEZheERlY29k ZSAvRGVjb2RlUGFybXMgPDwgL0sgLTEgL0NvbHVtbnMgMjQ4MCA+PiA+PiBzdHJlYW0K//+TdWo+ QHSajIDpNR//IDqv1H/////////IC4NbjkBcGvH///////////5AcElBKgo//////////k2A1HlM EqLRNRH////////+WgCXjLCl6j//5AdFV4////8gOpFH//////////////////////////////K6 mJCDzfoIN1/3XDSLZLEbRmrGEIuGC4z6f94jK6X/+VwoMctlSiPZjy2SkMf77Ls7v7btREN2Njhq HldUGMEHl46CDenLZLBK6D+jfsMKkG7FV2F8b7DCVjhhRlcLI5U3zQ/TeWySdW/7/bj8MOWyUhi7 8NPMfEX936iP/8rmSqUrlckEUvn+v9G7X6G/LYF4j3/CvtiNe2c3nfdDDN9d+//m6O+sRH6xrYqV 0vOxxtSuqBUx81vNlJy2BRaetPX3IO0lkb6b981njK6qE1pu6TFLvm3ResQYT7xteVwvih7XPItl YVCDHDs55bJJ1y2QtAvsEO/xpGcqMrrA9fX3ZTZUrbxfXxUXluZRhjtPSM8tgUWqsIP+n+kaPXps x4pf7r/F/4xH5Nu5z5bmYSnqI5wFFL2e7HUtgDzp52wUb/Wz3Hj+OfsRluZqno//338NaHmHMP0L /iPk2NYv1uFfPH6d+q7//FrYqGFHk2yluZf3/2+vqW60GNQZgFFJ4///Jt3Lc0ErRu0hv9nvHXN+ I8m3f/lutI+lplwv7U/4/+PH//5brXXl8/6//v7Efhk4KHw0L/iPJvrSbdlbBf15nLH8YQPLdZBd W/+Y/9PrvbStbFRdqI5NnUKXzuIvwthegRH3W9fO//fvXpL7/f/31sRV9diKhhNRHJv1JtFy3Mmn B4uHnc8Z4B/xB6/d/JoglitMILhYhQ1wURq1HJtmd0UtzLtPv//ZWs2i6/SYQiv/LdaDAz+9Xy3M t/i8R5Nuzt8wuE76/nfct1nNmFXfDQ6/Usc4/+MIXb1/9fYjjwojk3mjyhBp2vTdfT/3212EoYqw o5NnKp28X5Nuwv1uW6187/67lriX+v8f/29Jc1N6lrlwx3YivW1MfER+/LdLvldUGmd/iMINAiO1 PcIlDp+8EDaub39PX3lriXX//v38fhhYjSWxXNzLXEBiwp0a+DKkkzHxH5Nu36/LcySiMrpeCDQX iujQFK4UGKaLYKBf5xBB5nKHKHKf6ovnxEX/hB78Rq3/fuMx+sRGGErFSb6wYUrkuZEWNQhXmH3p n7Ue+k5a5cjle9f6z2G9W639sUrD7W/xMhCsMcYby3Mt3ldL0zupC/YM7wIPnHa8Qw0XmVwpEdkd EcgwzChDiI4/IUeETHt0ZEmiBBB7Of4hcX9ArWO1zcoiIjldZUIGdwOmmdzqNFFxOxxKQbhNrr3R hzx/9f8wv9vaV2u321V6vy1wOxGSQMPHdbpqDzkZkRYTcRHEHiMrqlz3r3395bKrUN/5ulslIY1r fZnOOYfEaEX2t3lclzvTO/QjU78Qmivqv0bPfod7r/f/Z7BDrHXwyxygExbRutDFoXLKFqIjldLR 3BnaFsIM7cXzRC9JuXbLXUfp0E1DlcKDH0MPr3OOHRkX3PoQ3+1kh4Yd9hpIXIrSWB2KmHOPCLfE MKhBotdXhIPERiF4XK5koXU7+Ox2XxHuv9AiP/0uy11HK4UGCtxcLW+f6//rZ0Wp/+tvXH76f+qs R2trF2kOIiGFxn73ldYb8IM7NUfiaZhiNFvvTToINq7U79fr2WuJr2/SuF//WWurE3QKR4L+vVCK Y0p3O+w0mScER1S+3YwaEWv+GFiP8R/7HK6rnZ29VCDEee5nf0g/6stgs7erlsCYXDC6pUN6MbNn LHOPv68IXj6b/GPEUW589hC5bAGFiZ4wpbmYSZpwVySU7NUYY9G37T71BEf+f6SstcbrsfuTY1y0 lAnXr18+/+KMOVGuxpE2dUI/P9Kq+NpXeOIjZyo3Y4idFyuFac/ed6ojovQyFMj1DUvn8EI4auP9 IpzX/zdDaM+y01P/u2GDI6rcSuW1jMJR0L/LXVhLEeEXH1SudjoKQxu31O53wz/CFQuNfb+goWxX 8RZwaphfxER/8d2pXSommbjrEFhYUrqm8XR/kHATMfMOCI9e2WvX+6p/nw8b/+3q3f6/vr5BGkZA ih5eVfQ/e6ERsV9/Od2FhZ/trW8GfZ1/FDfxEXDXxERWUyClJsrqlclZHjvmEGVLgqudmoRMlYg0 CI/rNbCVL0b6TojH67xq53T////02eXXt7+02177EVHa263VinirCm+whaiIiMmwHybDxGCSul4Q akEuix2jApY76CD1/q7PqFO+VwVlwiux6tlrqIxdf+vCep/vowL/giPR+1qNKqf9pWe2lX/scbSv 8aDCxHS4jN0s1bUaVod1k2xCI8rkud40zWyPkFxrtrZF2neFq+nXdGf0jOy1zCMLr13XhO///Tr9 /6/QIj7ftbrjSr+xTFq0v/aYp/+4YJhC16xERvqTYD2I5NgglSulSkqZHgYUrqm6MF8f0r/bPaM+ y11H7jr1Pr66u6cEUPCUwLf/EdXpX4Vnt1V6gz7GxsRSH9hcZsijOd3aDkK8eVwrESUmrXztPIYj y+fyZsJow5xwVf7oR/tTvs+i1xNf13YtO39fXiO10ZrlW7FdVBn/hbPZa4iLhPtca8XEdqfsZhyr Y/aEVuTYDxHldLzsdl8nDAyuSCLrVAiP3NBY6okOq3ahBstgM87w2vik4T//9ot///6Df7fW6rLS JPbdRpNqt1eNjYp6GLQYTXmOIi2vQjrK6pHfsxGtkfIXzH6P/pXbT/ptXoR306BF/y1xLvr12RIM FrqK8P/X7Sob+9TuVBV7T9rdaiOxKHWbsMJMa+DQ62KYp74iDCaGi11ApfiIwRHLQaldLzIPa5XC gwTTIOCD3qp/o/hMRzQW61+a3eE273pOWuDZs4q979Wt6ttb96Br0hoesL3r3WYfbWbs/21/sVv7 FbV2hodr6iIjFhccm3ZBolKmHKHKHOPluZBbTPqhEQ9LpMRzZ/791abM2RwrfH+Ooz/WW5kF+dzD 6X4vmsEO92hERjk2NTKvIUoTOoUlCui4evhNz4u6vhv//v8b164IVbo6hOxpMuCgExWpoBBxgwoQ 8RGTYUUmxfUlqluZRdxkVEqm62p3c1nhou/3S6hB6/Tb4//H6X7Z7sa2qHpWGEuNMVM5T4hhQhGI 5Nh8uiMyCnC2FLyDhdXRoed9oEXWkH+9X/X9bpv/vWv1/ur9N6uuI4ioNKGmmOGCBhBgoiOW5lkI iFxvqpmlvnrX/3wnu/929v+hx/VbrN2f7ay3FF/sVFp/aiIiP//y3WYimSsejCM8zBd+mtEL/80H z9px2yKftVS/sR9r+6jgzd1fWxSMeQE9fu1/EQ0+MRHJsamVeRZwmaxAnRcNZneE2jdpziq9Utr/ F3/2v3Vz2xHukNbHzH2pstPDBQg4jERk31qUmwFEVMJSbAwl1pGcQqO53pNfb6/vm////Qj7H35j 4hhC8Ry3S4gKASyDgKC7eXBneE/96//v+MSApUrXBghjIDoEpNuyDyJ4y3NBDqJl8/wq/5uo3V+l VP/xxf78R7OVntyAmhYzQMAz/Gq/m7Mf8RERHldLR3REIiVlK6pppkPTT7/o0P77pB/ZW0fS/V+g mXCfv/v9YIYo3zQMXRa43UtadVldU6yHwwk3x9iuIuGE1ERlcKzsE+dkfy+f1P5mC9f1r/7PB8f9 vFJy2E//ev7EaF/3S/gz/m5tqWxgY/XFd93an4q8REQwsctIpUV++MrmSOxyKvIvi8rrEFT8/jBD Rrf9Km+/O53aur5a4l/fzNkcLeWuTE//8a/t1Gf6ow53W26uvn/W342P//jtD/9xBghEbb4v1JsX XHK6pHeugyp5fFrnsmnsjLdjrW5ClF9/kYaBEe79OlVXv8EC76Hq/1wQoGTF7Xn/nRd2vwZgYpiK v1JAiiLwQMFFoZXVBiZqgzs6KEFJUcIvGmEMIPQfqa3pumeD5SctcSVc7dWKTdafytMEK/stcJv/ /++5cIKN79uu6Hra2teRB9bFEUDHVnPF2lVYiIYUyIQ4tcKODO08K5LnYcQeSgJ1O+CHURIfrOAm U6NlGzlrla6Q0LZ7LXSS/WNNv7qv2zk2e52uJnf+ND0v68M3f3m7P2P+IiLW38Z/xFRF5XS0duRJ ohWwpXVNNMjEFIuFHujWwQ/9NpT8vavO53e36r96/3/jcrhQYdf+1aX5FwsGfdB7HXYQ84CZS4MI GE8RESAmIUt1rJ4pSGV1jL6GajThbcIOQwAmNJvJ/nv0Z+GG6hubwteGHVeEuuDDHxCC79eEEcW6 wSN7aoK/ahAl6CWWuNdiKCSRODoaDtRafDjM5MfMjMe3oWhxEG4iIyul8rkglaN0tkt9Cvz3v7nv 6G3+wRQ/P9COIzDmH6F/yuqQvo/j/ffLZBYv707oaT9Ai/5/1//7/8RulsRVqV1jL525Hdk1Cdph MaTo1uaNAi/06Qb16t1lrjd1uvstcJv3q/r916/97VtK1/EVGxX2gwmlWIYIjoMIIVER4M7Twrpf yuqeP/lsqv9flsggnwsEObtKhldU/tnv2CxQ8jHyul8/5XJBBGtG7oS2VX/vtnPoZbIvGAntc/6n gqMRHH/HlcLyfGuWyUr6JNPNZB2kZRzO/nis57QQXxBE2m69fhxEtkojhcN3I4WhI2may2n4//// ///////ICS0o////////////////////////////////////////////////////kB0V7x////// //////5AdGuP///kB1J71H////////8rhFH///yA6YVbx/////////////lmA1H/////////5XUx TslZHiIztChBrnSTXNzV9OyzKKkHRn2lO7oswdJkpzFSbretylIuiOgRT7dU//66ERH9IER66/9f 30+0r0o0kZD/+xTGrSv9L5NiAItRTr4IbpaxDQtDSUazB4iIM0FAiSp7iO9cRGV0vO1mIPO5oedq QiplutRf61S2TeiJYja6N31dU1lcKDFCaRcIUtEdEdEdKgRdZNzUIFybaxg6/oREdLqgRH20OzH3 SM53wRH/53O6r0YcnD+2cxoedH/2/6a/off+v6+vd+3+2+v3/+Iz+hoaYj/vXGoiIwtjYim+I7Ws MJhNcrqYp2lxL53RHd5hCIjCDo6iKFUrkudxl8jMuqL56etlcFEJRFzC4WztXmGZFmQmShmMiEYW EH0bloER91VVtdNTIWFNQnad9s7K4wEoSlo2iP9ejdandoER90CI/bUEXwoWnC5bkoSvrhNCP+hX evrdfReZoKH1aBEfbT683W9f+v/X6S4Q0I716NN2GkNdnMZ//+l/v//r/09ivNAXvvVhm5j9/1/v fX1btf1bEUh4SbVb6Y9z22e/f9YjzoQ01tcRTEdBUMnDFhL1dKIiIYKf47TTXqxsRUGsRERBghGf 8yLCaDFSbFaMgrFxaxYTBSulpSKZCZCvK61Ff8RERldSaal8/kPzUIRf4YQZU0QmQiO7I1CFuHQn /+t8GmSoIdRDUJamSdFPl8qEVJGoJngN/+0bvc7ho2cKFO/0aStp2dEmmkZFa4b/96GnEN1YRuzd mxfQV79GkWmcMyGVX3//w3vjQpOUvtz3ow/3303vfEet6r/uPUZlggQLp78iiqzklO79sbghTZzB Cjs1wQXv/6Eev4TLhI6V1w3Bn/SHUQrWznZys5Ro0kFjlDnH7/v11mWBi7+DOEgz7oE2lGThg0Bf poROd1QIbSNzRpFn0ohx+f/CjTXnO2z37qqQ+8aTOhxEREaDCm7MjMf6H7EUDMFfPppbWIiIiI01 jtOPFuu8Rn+I0Ki01UmwWyPkLztbxEZ5xEat5FDMHluNkVGQmTNluHiNfpPQZ07IfoMl8wzJAyIy +SzMJSTdGffSNHRr/do0U1sLadwwgzIE9eRLMBKrWn33ps2qgi+jW1deDmhmQp/V019srcXCq3/+ nS9PBF/Rx/M4aT/3WpOPr9fv/9a2l3u2IbpvvdUME+lTU/7//6/r1dLw2v9i1+NR91BDJweI//3X 8JfvivaC62kl7Ht1dU3qQ4JOulDCHHF2KOuDNuzn0FtXVfSYgroEOIiLW7uPFRFMRSTa1EaERDQa qCigZ2qkJssIyQxBhCDCwwuV1hEdEeOywMAgZV5NxKEREYIRqibtSuSZC0pBctsUXmjBA25XBREz sFaRCZqwQLOwszGU5FSiny6Gjdan6dM8kn100FoRvYTJWKFs6xiMhGQmZaZdUhFK00H5qSo3dGcV rCea2FXUJmR/wt33/zQF6EiebgRTqmFo31tJ0XdAiP21/rezy1//TCEfnRkcLQ11ZDZuoa354f6B Ef7ad01XzkfmH9HF9/+tJel/Zpm2FrehtqIxfwzcNH/0xn+59XXXt3/+6YQ/6xXrH3EV8jHvt+9n k+raXrUw5Q5Q/+z/anQhf+/Q4YWwoiaAv9RqCFDQi/rEQYIRGf4tTOViHknsUUA9MR0lX31ERERE Z5wwScx7Q4M4TsRxEWdGE4YIcdqV1VF8vGR2XzWyPnYOI6I6LomETbSEREREaEa6VoREMKVyRELy E7OypGt6XV2GdQhXBRCL+ahIZ2NihBnaqRLCKvISMhez9nfaBF/npSW7VgiOwqLdhNM1LJwwEGZC t213rvbnc70Yc46rRuiGGi7wg81tGtp/bII0koev/F12633oQwy/TrpPT1c8GujW7/pfR2DW/+3/ HQ03VrfjTpOzQZ8K391qv/+uEWP9fd91bq0nuV1QJGrFrl0R0R0Ev/wQqz2dEEEHbPd1+pha/vW+ mKYqIiK7XvqNCnkh77ddJghTrr/nkMCYSBCxWxgzA8FocMLa2tVdXX8RFnG0NVP2uW9imKiMGZQG FbW/lcKzIEQiIiIiIhhNXTFRTFDuyExBhToTsINPzK8h1wyC5GRtHEa8REREMFkPtTP/PcHDU9xG pXW4i5mIp8vmshw/+HOOH8jH5XVAj4XQZ2NxlXmuL5CR3RGQIs03388BiGyoXz+tYTraNc7JiGU/ WzoFOzVKZDNeH3fEGwwZdINvwguf62jvem0vV6TsyQIahDING7/w/j/EILxp/1c7xIw539oEXWjd 3VQhX1CUZ0wSCLjxhBHl//vw62/q779G6jdW1ghraCNaCT0qCX7X/4f/64vXQ0M7nfE8Nqf8Qogs ZuYVcEChm56/tKH99b16+vegZwfhVdVHhCOGFb0tW7ugQ7rwQq79y0ipaxeFCof9iojJwwdo91p1 U6Bds5tnN/FREcRGc8ZyIYTCsWowZ1AikmTcEhof5aRImIiIiM6IhhYam3ND/GMmynu0IiLz/n+L RaSkoIMp0R0YyEzplUzCJWR2qYiIiIiWkVIaYIR+fwnd5dG0dreS+VcaovnatH8hMpyOyVFP3Rsf 6rhGtxEnsFPzOkgzUIunmsXO1MdlQRqiTzCNWTY1Q95+9ujP95CD99U1vUKQenDQcgmrtTJVwg9X uaRgI/XdXNkN+lO7RuSBEffVF35rcGjXYYXz1p/Fu1tTqP/ev+t6GvbWE0Uek87h7c0GfO+3+eH/ qbKGUA/+pf7/0u/wxKTxXqxPVPQdtd/1c2t0FGnwiOw766/1X//d3//St6+6MhrMBK07YUhhfRvz EX1Ya91ghTGk2cvU7GBiz3H0dMEv9b+NNf8VCffhNRFIRtqLWsVfWThjb9LW/fSWp4Kf9QYU43HE Q1xQM6gLTYjnRWc+1iChpOr/zQU8cXiOIiIzohrGp/TCd5plD/YqExxQsR4396ERERERaEa2oTCa YTT/OdRERHBhAwgwQiOIybKSMRBxEZGRfNcXzrkaREZfO1vMkrI2hERGCHR0YTXTuQQMzsLnaqKZ J8hKGU6I6NpTs1yEjEQ3Xq1bSeGqa2FzoFkUgRGp9K6Z2sRGs6ZGshM1kZF/P/pGejv4Iv7NBn1O 7QIj7ot/zuHLH69ozuj+CKHqfRrFNYqZlMItRNAx1/pd0HelevhA1zZENwp+9wnpzi86hHTChNFw wh3///0rvr/xMsjASnBAiOh7evW1vX0bs2KE8t5kB509n1Oj//9e///ajaQq7f7vvzueNvQpCtkO OTCn73tfj/W6/W9L+z3UzlRd/Q//v/b+qe1IJil2R0XReCKHWP2grHTFq2rsa3pRjQ6gyelVvQjQ /0O27/g+4iIjr7XGxUULSsR/nQKdF3U3W1/7Vz3n06W8P2QQfZ/i4sIMJhNC01P1+kITFVsUz4Ve f93U3YycF7URbuhGIiIiDCEdoXnBgmn2sX9pj9Um1B21iIiLOYCERERcaF5us6MQhYqWTXEREWhp w01JvpkHEH2RrKhGuL52toyG0ZLGIiI81CHTuDJcRV0ztVi+pFMp8wjuCJdF0p2qxCl1+Gp1CLbh fLx7OnYTtMFhkhhIIMq8nNEYQ4Q9ZOszXCtG7vPAaN3QIj76BEfvq110a2m6dIsdmoI0+dVpoGQV l87pnSk3Hi4Sh8QboUYc8a9a3/3nfdOjDrRnEJBB10Z3p6NYbIQq/R/qv/1/52WRcL/9Prut0/TX c3Ut/uuVbQIj9/2p/3qdECV+3//9//9Pr9U9DXmiOQLTq41W/fH2zmCGqTZz9f2p+/sR6v9/eub/ 99BhD+sEC/KUGH/ocKIJDtvvSHf1cnB/SdLa/7zH2P+t+l6338GcGFvFMR+xpBn99/at6sRul2e3 UZ/ghT5jDB380Hyhxef/Cn+LsIVYro6bEUxURSwwqmwXtL6tLDb64vxERxESIQsIX2mmpnKgp6Ee wYL4MwQRmmCUaXz/iJdCIiDCBgmhEPs6LEIelQgmKa/llB6YiIzoiIMIXmplqYQuPJsC5iKjNcXy EyEzWV52tI7VEZFiI1CIiIaYQiNUzUItnTvTwkmpGslcXyE0GQYQR6aq6+jW4YSO1P1PRD8LmoJB pFcZFTIjDJVnYvamejDnegRdbvpOHQSu//aUhdDrpJ7UJ2d14Qfq63pP80zASrDEJ+320d7z9O8P rRrDmhyDmVFjv///6a/Xv/+opNnK9LSbbqEG/17e1qtTZ8ieHOfw11X8IFG/vTz8d3P1Xx/rfghj T3XqCGh6T+9pX1r++3XoLbdMWsL21iNJQQ/WzkDBzrmB3mN9fH+Gt44oGYH2KwZrBM/ajqKfV1// v4iLQYTjtTnuNODOpClJoEs5T/ultX9K+IiIYIWsaw1Nzgo/iNsJWuUoK2sRERERmB31YpihhRUm 7ojW1P8RmPDCanJhSbBRkeUIGVeQeQmQmZJ0dksVVFPiIiIiI68vn9MjJfNQihBlRqEDNWd1ZE+F f9GydQnqZU7RneahE1PZ2arzCP52tZBxDiri+VGQmQmdkkQdnfr9XJD/ReVdJ9UbPp+udqjU6fIO Hs1inUIpC8IMIP3b/vO9ycME4YhC/Qb0btW/2vhDV21cKuSkIix2ix3/v/9v//M4wEod76/0n5rM 7QIv6LzNfSoNwg36piO1L388yh87k4t/9rfv7v87nh/TvXcIaD845npOk/fd6/8XUXz2ZYGPam6/ oelEf///75oGFrr/EUGf8MLXev5OGKtRrs5NqoIb/qvf9WLd1t9/f0I9jfa1DL2lNL0KTSm7QMzl P+wQ+vrbOazkdv6+GCF5FHYtDjs6Idin80DFWDMCoX26hWuxaxnULrf2raxGdCEREdoXn/YtV/GD MoGMUqC97VurCUREREZyIiIi07CDU3ZhrTFRlAYk2Uo7/JsBYiIgwhaGhHDCWEDJRnoIGVGSgzGT xlyO1QISuEREZkaLfema9Wry6M0mkgyWxfO4zCKcyMMr+hGgm7Co2Qh09WnowWGFwnaDQZkQjEVE TsjxHQU1kQTLolSOzo8tPfVql6781110aKNELZrECERpmqLsLaaDsqP2Sq3nc8dvd1c/pPO+536T aTeEwrM6Rremt567OoSv//rfnZWy4WOr917p6ep4z/qfGk9TvQIj7/Trel1/vYjfrdL63/v7URSe rS7r3qubu8EERzuvt6dpG7OFVvX1/r6+99J/7b7obYSrhhbbqGFDN0d9un6b6vv/f//X4YIodddj oOaBjjYp3dc+rW9fV1dY+zldNpXpP6EX/YVPY0GFWLUWxTEUxFRUGlQWNtbVjX0pnOPtYZuiNTkR ERFWmqaYprWKYqlYjoXYYSJwXk3zERZ+iIgwQMIRm6GmhdrpiuTYl7LcvCIiIsIMIQwQuGpkZNik F4ZCRfO4Iq81EdqoQyW4g4REREfDWwmagiaRkW953VkIjLlmg0IpzV5rao1tGkq4ODO+EOmmpA4v lRkHncGQVGEdk1aSbDaO/SeftNvspw4Nfy+fwtrhMJ3cacMjP+r33s5Yhhz20bu6//ouGvIO1de0 /9x14zKrKIwEDZhCG6H/0d7vwm0CI//oETv/pW/SD1j/3/80zAU0zATetubDw95DHVv3+s8lYfN0 ETeToLf//p0mq6X1+wsK2IpsKdAtpcMazoMOhCbOYIcR/ujOd3Uw5nv/7fYqF7FUx2cwa9BcFHQf 8ccaH19fuGFThhNTqwosX4XCUGeVZ/sYS/7Sb614iIiIMJRdrqf/8bX5SgxGt01Gb4iLQiIuwhaH timMZN/zed4hEyT4iIjMeGEwoXIXAgZV5L5lrl0p3fCER9kqETNYh0aYWzski+dNSEyDwgZXC4SS enSnytJrhcINBGrzp2p2po9BBmrIPPxEZF+9aJD0rRu870CI/aBEftGHFeujW108/3kOCZqi7Ts7 0yr/aM996Glut63oNbe6T7o2NV1u0Lhn+DO7YT/T7f/Tr/6wvfq+93e1hIz5hzPb5hw6T9//mO/S f1/zi1/fqrb3R69dVZ0a0GHU8fr+2krnuP9X/16Vb/+8MV9+7GIf80i4WxXfYXQ2lvr0nVQQwQp0 gQ+kN/r1//7WxoR+rEcaxHVWtXqaBiPvooQReSaYL/z9gwQwuf4sJhMUiMeDODMoFAzbWmEpv3Ss UsQuIKKx3iM6IiIaDCZz92qY350Wl1hcLC/ETu0IiIiIsIcRFoWkhgg11ybKREsjtYwTEREaER9m rI5hBksi+EMrluUkUiJuJoRUmxLhDRY7KEdUtwsl9BqQedI7RmEShmJX6CDaDBNXnXVZ6QnHnULc g5m0zpFz3Mg4vnXI1lPl8KSEaUmxV6P+nYMEkCI/59PpBvdtX17W1PZqECdhQQohedxF8p4v/x8G IKm+L6njz/5rPGd/zu6cK/apOCBEfyVCBbC3/XDC1+3/80i4Sm7S7rernfvo3UCL+EueDXXdXxtn 0+PXNBS6kDCe+La2lv///99DXYInERptGHPFHjzx/DC2u/Qoa/vO53+v1/1+3X7wtXr9fXzoobaT GFz6RY5Q6dcKKi9738ff+h36w//b///scVDBAk6ENoRnQLq2u+rStr6q57+o9f///z/YQYURtcjH wmtihYiqVio0puaG3qjPL7dW3+u6xEREVEWUjONppoaaY/4isMbYV9WOmOpZRRCIiIiIYQtT/DQm bYqopio5Ni2KpCIiIh2ELVBhQgyEi8EGSyL5B5CZqzIfMtSKexERzwwuix2tnRpmqTU+jtSWdqrL +EGVGdiWdEZ5kaI7H+rwRH3QQdXpNJPTTtcHRY4dnasS1JeO1mIPBAzWM1GY0Mp0YR2lIk1rN6/T aO/0Z+jPf9AiP26CDuvnQIdhfnTtU6twnZ2ptNf9Xf/1XVXb71uTr3VG7YX3XRrc1uuT+uRTOntn UJ/6r+/7/bV9fT6bMwxQ3BEfR3O693ptJ6dvR33Bha12Ca7/9f19IUq//reDFD7frr19gwde7FU8 /8R37a78fHqCFP8d1NB8t1/79P/hsV8ML8cscocoexFWkxpNK0s3P9LdaF7OZOD/YIoeYSqt/9de SpEdf4Qic3YqPVpfZQ5trYjmPhrqdjAwnfSERghTrfeEjab1Ef4iwmgwhERFoXDXmgL+sx9MbCat JsKw1BAl+rWGboiI0wn8WmdFpocGcGZQKimKS2I2GEo5NiXOxvIXiIjOREREQwW7QYQYSGwmK6nV HMlEU9krgoiIiINDLHtBhT/k2LZIJ5CUPCkJhDNQztTzKETZLxaJ8REYTS7OnsO0tFuCXOzLUheQ ca8vndEVGdSOyRHFI2yngi50+5TtsILhCjW1PQQvwm2TTTNQlhOyEpB9C4NqZYO1ylKq/YYbS8zV O+vr+qND7OoSeyh+9H8lCztK9V34YZH2IR1jARjVu+f187/dGyk8LXHq/Tte5tdfG1r++okTjAQ0 i4RLvuhq95/4QKnv9/3ephKCLucnOfPBT0Zz19Cn1X9+vf1EQRZfv7+wq6ghFHUb944vQuqfz/ef vr/5he/3e1nZbFwuI2KaQXEf5mrSm5HYLohxfiu30CHDOdpL+yOvUaar9oGcGF/wyOgVj7Qr+71q N+7WzkT547VQQp5+50R2uY8eI2E1yxybusdiKBnCYimDSj4baU/8VeIiIiIzDxEYQhodprn6rFLF MfhlufZL9CIiIiIzogwmf8iBAn2hpYlueFxEZtisWpN9Mi8d65RGXKQhaUkMDK2ZGbawTfxGQQyL d5dH9OQcIfRhBhAztUCE3HRao2q3SdJ2dqQk/zUJR/RY7CZ2BIxJHarF8qM7nkJ2NEnU1md0jP/X SX0E81sEOfaVtSaBTUIdIuyVZh2VcX8726d+r353KiJckYc7q+m0nSwr+qpppoGF/6//fS3oFW23 q9XO53tnKd+8/JF3andtTvhrf7/+mI/bv+1ft/bj7zSLhduEPuktsqw53v/f49/wRWEqvaH7r+l1 rj6S/TiG/93Vq7Shm5v9hh/9paX8+1r7o37+v//tMbFDS/2v23U/7Cw0v/dR+rPd/+TRBL+LTQtC 0LFRtR+aBgnDHHZyYinUmgWNjCTGkhBesREWpGkQveLUdfW10rUaUZ9+chTog1hoWpwh/jhpUCYy 1TVSyBEIiIjP8RF3ERaDCGTcSi+dcg2mdYjWZV4iI0MLqe9uj/5kWRCI7EshEQiOySOzVDJvgJ33 X+ZTsyFPNQh2rENQlhBohBzVkacjVlBZ2sSk3Na0d7v09/3uElC6MO4tO0yJhg7iL5Ucmypc53/b ++T5gJv3JD0bs2dIHmgp81tGt6hfw33/bS+9Vf3RnT0NNLXjCSdLpng0e/Bj/6H6HzDmHpLpe34m kXC90EFXTmnjQdHe6379U7XGhcEKBFPXvv/yUCiEF32mRwqVr5OGJNlm9jSm6wwlP/+I/3PdnsZ/ 9GMEDSOfXX+/rH4r2K/wZsCp/QycMffhEuDCC77xn//8x8RDQtBhDj4gzhMVr7DC8EDhSOiOTatr d3XrTxERFrF5/zHjoRtB4jirSrbVjS1iIiIiKiM1niGmKGmKin5N9Mp47mmdFoWgwQYQtBoWpNgX MRQGAgyMi+QmCBlXmuLomw6OgoiIiIiNU0kWOwvpmsQLZ2pRdmQaMRCapncDKjMhpEJk8U90CI9N BooINr811X0wmmdWEzUERudnXzI6NwVCkDJdEnkIiF53TKe1Tik3XO+9K0bM77qd3V1apOjW+006 MZ9O51wg9MlepSwqhB1+n39zOMBKeh9/ekeNIz0b1TaT/p6psv2Qet9AhoUjO//+v6/pel//Xj9e 9Tx32HXoz/5nLekG7r/7/z9/vXS//t////cGDEnuqydLo3xhBuvFd7a+kO97Z7f2//+v/9ftVD1/ aZcKaBih9XuFbClCQqNVWwqH9RpR8embcd4Ib+xGFj+v9Xf1xQQ2KfYrYimlaCtBTQMbapR7oI38 eM/50Wz6/4iGFIx2GhcMKf7Q7W12jOV+KOu0FDN0ECuYcpzxpf9EY91tKM5EREREREWFOhNC7W1u 6ZcsRd1/uOGk2FiJ2toRERO8QiI1HWLQ41M9iigMSyKEdwgQJMRmgocp4iIjR/auTYkiDyFZOGDU Mq8IRRbrKOZEHCEQ4iM5G51EJSEVNaLfXITQd2dquXRlriJGMR6rNCRsZ1CIzfX+DhbO1vCBkMkG U+XyoR3b6MOd1PyaRs1pZ9LwndbO1QVO3C2dNMIM7FOTYqDFbaiNN7zueGyQ7K6pIw53Xtk60CI+ 4JI2UaJAtf0W87SBK////FXW2aRgIvfXyQ+rqzHoER990E3Wcj+59f/8w4X/r//zvbV/s0uv7p0d zj//2vtr+kP/z/fj/Xf96r//vp/98XDC2l+59ML8ftf9/f/j/WvW247sasUThi2OGR9Mbb/bCU8F Ocfel/rEf+EPp/0LU3oMKxpCNqOuKxF2I++GkszljlD29av/iIiM5EZcIWhcML2nY2KZz6EXiKDN YJhhfy1DNSbgeIsIREREMIaDQj7TixWxjJsFEmQNFOZSIqEJjERcRcMIaoNhkG7CZGCmtEfCggZ2 t52tIi6I6M4icdkZzNWbyrQiI0XGGvNDChCOZ2dhfnanBMIRkHMh9jvTsKZDbIWsJsljQIj9pNou 6pB7vTo1CX3udQiakbzUy+Shm87FPuGHW9PCeeer+p3c9nxqjUdPCtUZ3n81CL9nc41CV5Fp/8cU n3S3FXRnO93r3n/T+q9Z2OEC/C//99evXSWN9/j2Y70SHU77p0ps3yLoInn1+z3Z71tevv2ydfX+ +/O8Npb7c7lRodrELfq1JwqginavQIUxpdW33V/3/DX//Ve1sUgtiNhhJDCEcMLWtr64K62lZuQj Q//Xrt3tMLpipY5TlDlD5IexQM20pKw0nviopjNAXf+2+r3+z3BgqcGCDCYQiIOyhoKhaYoYpBNN cw58z/tuo1bC/mgLxERERERENBhM+6ggwU5GhD+1GxTFdrxEREREREWmEwhYqY+TYEZiOmd1o6ok 0cRNishEWha/IIIMFORBzhtM6xdnaUjtKRCZT5hEYjCCDEdN2SAixD29M7VRpnUQKmE7Rds7pkJk vmRm9bNBnaTyEHdPU7wWlXXQQb1IfZ2Fo/HSLskZPoMqeQ4qcXzsmzFV0nedzv5sh60u5Ifo2UCI +6OPun9dPVNdGdkp1z0t+ZDP9N67ZEouFp/vV0Z052C5HyOiOloavV/13fdqd76Qff1en7/2/qvf 110toREf1db9lai4U0i4T/+/pv+kCI/1f11/w0z/1v71u3giP+3///+/W8a/t9N2r+GldNfj/VWr HW/Oi2e+qb1unn/z919NL3///zKwXsUxjx6sMKLFUr6+Thi1X6dR8ezQHOwQMfzn+qoetPvDTTtC 8U018fqxFRHDCX+1TGEvtQQ/r1nRiGCERDCERFhDzItBpih6wZ9rJlC/YaTU/2NbSviIi1gwmEGE Itbj/FBmB+KYp+TcSRuIcIiIiIiIgwnHDTXyuqmdkpFXgh5B4iIiIyuFh0GahKg8+iEjXF8yTx2q EamYjrkJkZk+UrITojHzRWcGGqbhbMjhE/z6VEb9TIDR1ZjJki2BizUaCbRu5SN/giPukjW6b7z1 GpfP+Xz0ZHE7IVJkaRiIPO0rGlq9PZyDDt9L0btPT/7M5n/1605PnTKPy+eghmrBSURhncCEHGSf 03+MbIp+aRcL/it/e/CaH/8gujZrgwVXrcKEPTCnUJ7V/pY//en9vboU3/3TSFbYp/+f/SM+bKXb S1s9zkyd1aRv/9/xob3l0sZhJfuDBff4o7nj1aQzuVHwZHHfHkGN0Zyoj962c9K9VKFm+IjYj381 /sa//+vmXBiGITFdnKFuLurGkZYGG1bCU/5uoRg4O1Z7dRBSOLHZ9ff09W3wy9rKn6hwvUXYrYpj +r2f83MY7SQoPr73+fV/OjEGCEdrERDCnRaYVb0z+UP9rVimTHMOEGf8dtrFKUoF/74s/xEREGEI iI4uIi1NloOI/vFOu9q/ETsSxERaEXEZ/i0NTHixXyulo7WkQiO7RBQhCIRERGmmhGmdhSTshUEy +a2X1NaI6Cna1nanG8qMyzITKWhEbp/ra3OoEZ2F/dnQKUtm3qRvIZmEEzIzvv0gRH3QIj76309Y Ty+esvnohtBoRR2NxB4QZGRfMkMxkZmFK4Vkca+vX19ntG7Vpc+eZ3719JzPO1YS0WO11tOzKglC N8zZHCkTDH6+x0NvV4bhU6//U8an6lUINhAiPttOuE8sc45x/1/7+t171/f9/+Pc7nfpPX1aO+0X ztCIOdlgYGf86P/84SfWtqPpbGX1dQRTpfV17M2XCL/q/vCD7Wl/vW3XhqCFPX9RHER//76vf/r6 t3wZgde2IpiKz+h1anQLaqDJDw7FK6/jN3r///iLi4001HMPBn2liqYoKwQOzc3W0n/7XdXV9XXQ iGEwujNYYU2+X79UxXHVtpMaVpfTDCURGfoiIiLCFxaFpoWh4qNimI4qTcSRuERERENCGgwQaaDC lckjtYIq0EMg0U7ERFhD0GdNNI6qwgyMiOyVReK4URKshMm9ePRr/ODfM7CGm6Z1jDRBCJ2VZCIg 41xfOxJHXINHZAnptX+0g6ro1vVh56O1YhqEIYULnahKp9QZHiOzoy+FJeIXndEdfq79nLern/O+ 6fQIvyY5bvpIJUunesRa8xc/yVCJqZJ0Zr/8de6ilut1XCDu+jDnfJD5+zvvftkR2gRH7r189Ag0 //1+r+tP/TffW3OOn21396ny9b5/7Rs0+n98EOcYK6MVnv6tf/uP9W2x6+u9Ju/2P6G/ntv7Wvvq wRQ9v3qP/X9/71vhhfdfX87uLhb9v7FAzhGcmTgFGFiONbWltKpoKf/+r9Ahofq/zg9apRSv9rjD QxqxTFOrYUaH7/Uhhb1qZwRH7X9cpwxZ7am6rt5aRJxBgqV54KgoeypwwmhqK92PYpBMRQMwNDba QxFZ/ajHubHbHxFn+OIhxEQwhDCERaHZ1a+mNqMGcL17tuMRESlYiIiIiLBBhfP8eqd5XS0dheRr IWjs1WIz9EXERFqmp9HQKdIuynFsujCI6hnZnnaXkLzWZV52aoqEIiP0+LTiIhwzslkztUWSsUJl OKqkDiDztRkaRVrvo2Kdzu0XChwemnhUXDC5/U9nUIQ/U+jqrNYpBx1RuIyL5ERU87nyuFIj5hAt vt+6CDzYd89tKd2Qa7RblD4Wvva36a4XTTXOjvO3EoRFOouv41uIbpXCDrQQirz/v+f/b92iQ99M LdJ4XMPQ9/+/6X3em8X7rH7enn+tTxne9Iz+XC0SNfS3PrfNMEvp9f+Grf07r+JoC///WRPNojoj pUEH2s3SGFjWPS4hR9AhVnu1s8kND9UK19f/+7QiOh1+k0knDV4TSjUbpMXrDNwIUoIU2fU6E6// 17cXaeZWumKGCfBmCsNVn/N00Bfm56YL3FfrHjP/PqIiIiypw1QwqRusQpnOP9/Bm2NdlDmc6cfu FjSaXylhiIi4u00GqFxoXnRppxod+tjpfSldYxERERERERF5/i0IhhCI8x8IM7VSIwztGIiIjT00 wgyEiDzQFyDjXl2amR47UsgaOwIjVkbRPkDMmxPEaNbRraLjnUSjWIENXU9nSCaefV6DO55CZORG s7SGd4yIE09PCbdZ7PcJa/2mjQ9Py8e0aJ2a9nT/CZTsjxCYQYUhM1RfO1OIxV+90kYc7xSbnHM9 H+jP/hIz6D7/V03v86CgjRcNX5h3MB1uR6fa/mkXCVvur2o12/1a96r0k/rfdQm0CI/6QPTq8hTy 8er0YXmF//a/u/9/9NvmbLhX/v99TTNwIp6ul31ef9AiPbKv1/t6XVpG7277/Z5fUf1rG/Ef/XFJ hCP68zi4VXjJwxT4/0WrNbS7XvHu3W1/tNv1j7pWkb79Aih62tv//7+utgi9L5lVDiOI2GEn3vtL vjjWbrStqjdF8GZyh9rEYIVOeM/3X65/6zpzeU/quI4dVYoeooMVsasVXrFf9CG20oTX33Tfj910 L74MG8PMjMiGEIhpoWEz+mEOLQaFx3pigZwZk7aathhYj8n4YXP+raq2DM5UQ3EWnERERERYQiIt bwYi1FNDoRxvxFHamFobB4iIiLiDBBhDIo7UWgwoLoZXVMyqyNohaERnIs/RGW1VRT+pmjUIdEfz UwmQvMkERkXzsnknl8qEVJGR4jkdrMIi0wurhVXQ9NbU+gudUmqFHaRkYEEiEN/0Xe7RGP0a2vqt 36BBBpHSIHHTBBmqIVnYse3t0E1Tz/6dAgV/QIj7q/NsbNDRgaP5qEU9J0f1PoJmQjtq34+okTi4 VK6W36/9z6p/wk+jW/e0XD6HG+r/v33/vkSi4WyOgmrue75xzD96e/6fpLZ5AhWfXP/Xeo//+Iqu Lb9p29bfvStc3NGgp8XwaY+3XWv5OGHn+ix1fVqkndq/e/TmWBj+Os45hyhwUaratqs/71ofoXzG jAx27ofRjQ4/W1TTyxyh40Iose+xURXsRTJuCI697X/9b/W0mdGIiLCEGthGaEWg0+0DiNckOXsI MK57n++s3bC8/0b7a/ERERERDCxFCkND/Yp+I/dbVtYjMOUOCI/MfYiNC0o9OxW8rkmdkmd06EXa ebkIs6IiIYQjuQQEMHKhl8hM1I3HWO0oirR2YMk0VGQ4jSKXiIn4RET6EewyKiZ7XOlaaee0zrpp pnXI+sGnkUyFZ2rCEqMqMlovluW9fQIj9/p1o1vdGhnS0I5Can6pfP/pIM6HZrZfBTVF8qSOzX8I Pc453v1vvU8b0n9JvdGHU9vf1vRgst768w5Q5QzadkfI+XXXdXe9f/9vq+9389j/W9egm4TrdCKu 8REP9/dw1f31//+v3bBFp/fmgYIojfue6fud759IER/2y1S6/X7of4IoeXwrrod115heP/quEwhx fav+xddkTR5LPh4Y9/f5Y/0kIior3wQ21s4GNhgih6sRz2UOVH669fXvCYIat/hgo9rCP8atYWf9 haulo6hQw4igfEXGf6MFd1/mgqvVP1v2Kdj9igzKFXnZaGAZ9iYtWUOZyhwRHSR0wtM/f97W6fWh 3xRv/xDBCwhEMJxEXXQxcRGW5ScQQM+53r7z02lHGln+1V9teIiIs6LzTKH7Qyy8ccaQ2KDTHGxF a3jERaERGEIiO0GCDC2hdii1SaldLRM8rWQaKhFOzsbxGbkIiix4iwhpyCFEhpM1CBBmrMRV5Tox AgztKyoR2t5rMiGUiO4iDhFhGaH2FTwqLdqmaxDoFTO1QQKdqZKmEGa0XQUIMJlSxEt1n7NBnc2d 5Y5Q+g+gRHglU+NTqEQpGhot4QjRY7TzsbiDyDiDiDyoyDR2loqFyusLpttJr4QhpK6p5xzPRuq6 N1JFj0m4TdIJ0a3+dPzorUh6ZCo7iCnTWHK4KGFfxfUfX1f7q6Gdzw6PdOrz9oN05B/Xvp/5KQgQ 7WH6/96//bF//3bXq9v1tMnRHy67/rd90guplo86He7Z7NAxZ7unS//pv8d/x/30IjO07LhCcMea RcJ5pmAvc7nfN+1DD/rx0UCkdBJ+P/W+zn9/3X7r+v69af0vdCGJUi4ZH/sMJCoMycRwwrQV9ToE bCnZaGO6O1ILaup1NbXp50WpuoyIIoeYStI3bV53O6/3t0OOxzWUPeXBY7YrrY0mKXY6bStUNtK1 Hxr+IjHwQoVGwQ39z6KER1hE4xDCoWqghaDCERqZWEzojSLgFFMVBRsV/b8LuvS/jQiRZHCcJRER ERERERaENMKfZwmhx6wZwizpvkP7VORR3CxiIiIiIvi1i+LFTOcfOQoXK6Wjv8mkbzXm8jGIiIiG qENCNdMmghCq7TsJkFReMhLITOxPKszXlTMRER69P6LHZKgkghE+lTUjWmdk/zZ6uE3CDaw+6P4R cPP+jQ1PZkV5CZBx3PJUR2YjfK6oqQT+/ro32aDP++nddJvzIUE87HEs7Pp2ZH5XBQXxIky4VdXp 8ad29+m7fp319QjW9rz1q9X/vdJu7713zQMfejDnf0jZ30n/Oi57Gburr5j/0ON+SH/+dBa3NIuF NAxQpX1dv7j3urp0uGbr/X0NGR+MIH//7lbjAT3/rSsbHFhSBAu6tT/m7aosf7aqCJcH98/Zj91M K1+GsebI7CYSHxQ/W2lR/fhhKbsIHvx3rbPfStT/ukOLQcRGS7ORaH9imsc0DFbCDu3X9odrj7a8 RnIiIYQiLCEXscRqOv+I/Yqf8T+JSkIiyiIi0NC1P/Ha1lckIyMhCnrERERFG473DCFqmdziLo/m pl81svqCDKjQZkozslRhHXK6SaEOIjRcOk7XXRghY7OlcPCaeVnIOO+RV9nZSjqiqRC8joRwm/0C I/aBEf9BB/NZ6up63Jowgzp5Qy5QzsaFTKtF0R4IMq6IMg8lmd59/et623PdXuGHo463/pb0OGnn tCOzWEaUKX1I1mQzrlZZHC1r6/Gr+GGR8yNc41Sbu3+p4faMOThkYaJD/Co+NQd16Px1EMiBP/7/ //8ZOKmCHrvkTDBpFwv9PQacNo3r5/q8/70CI/fSpXUZ/gh/vqjA+EUPMJQROIIHUjH71JD1/91+ 2Rdp0Lfj6iT+aZhEdEdLW7ejDnejDnH7r69fqtJCIo66CcIlwYz//Q5kefv6dfhFj7v//VCI1++t 63sfbJwUMEVGrZ7hrSELggf26VGv47xSgh2NHVAgg7n0h2fXmN7I4/3+D//b0NBoaYpDYoGYGFiP xFYf/1rVCnhgn2FdLs5xFDP/9D9v+DBC4MIMLDTTWO007WKtUDMnfBKhU/44a8XIo/X0ph/a/xER m6IiIhhCIu0LVNVX/xGs53uxHR/t69ZNxeERERERFqecXn+s3/Hr2o9jldUzv8rKJSEOwJE3NEIi IjORERaEGELi41U+lPolAUl9IhMg8EDISO1XMIp4vnYnmQqIIiIiPTpUiHXONSHWmahAmmtnaQUh WQmdNSDyFZkHEHlsCi/fLf6/o2VSdcKRes6iZ/RgnOxuNTI8EGEGVeQzO/zuvG3vwgfdz371aN2C L+gRH3ROPr9LnZMVdNO01Ow1kJmSev37b8WZsuE9XoSXNL6+CfdGHO+/P8/cKk6NjRrejQ89E0C5 kcLQqMf61ff///H63fkh6iS70Yc70CL/Wk705tP/RaRaqqoIaMnU3QRQ8L9v9/7/8NY/NAxW9d71 k+YCenbz/5+jm5zOU8lLCpONaEVaTnuuq/bPpV+0OZzjhP/3r93p3+/5OGNv9C2EKDLgLPXtWqGL arep2IDAIV/0I2c3Rkfff68x8/f0Mbx7v1BOMU+GYsHxFMRW1bdT/z6jH7b7qrV1xWoivnR4iIzh EmLtXP9ppG4p4M4RR/Fq++rEbaUNJe7RunZrkdAih66xGbojOREQYIMJoQ+LQ/N0fimo4jrnP9CI rzI4SIiIiIiIz9ERFphBhKLQi08E1oKVyTO5sgjpoRGciI0yhuztP7CDCDNbL52JZKyKvOxvITMk IRIxGQvkQhElqERHot6LdrnajsJnXzsmLnY3EJhSsZ2a4QMluYWmaSfhNwg6BEfu+a34XO1HnUJn 8i/an9MnYTThxkHEoSRPmX/V1ut90n7RefdJ1V3VGtw0uHmtAkE1UujNHYKGDIsvV06/9fwhJCXu dzv3f+nkIIBAm8ERzZP4IaYQXaamQsIWkVr/f/X3vgh//f7brc8A17psMP0ZxVbzQW8KPuvf7XrS v6XbbBFD/tKvPlS4g2DDFGcqNNfjCDz/06uvpAhV5OGHPc6IIFZHG/oR6of4PvW3S/V+l47hpQwl EdNq0h7xFfqRMHTbrHrOwvBJfb6ObEff2NimgZgsUDPsb2tes3Wpu2u3axCCBHO2/dX/iGEGEGFT XP8XBnCWNpwZ9z7FXEVCBBL6xGGbt1DN0REQYJ+hxoaxdrahRvFbu2scRERERERBhQlF5z62KWVw WMgLO5oqWLzWU5Q8RaEWmf/KETRHoi8awXIONTI+UBg6MxFBkdhSDyEztUM7GmQRkvHaWipYtCLi IjovJq+eqNYq2l6EVmoQJhNBhBkJndxfOrslIQR//8zlxCpPM+nmH6zQGi3aLdosdnVhNdbSO1eY ZTsjx32S0yCH3+3xhPOOd6BF/qftXTP3RupPCbQTwg3Sa2082xpppZ2ayYTCZ2KZkMW/+/bV3rse 1cezRG4j60NOk9Wr1PEg9He9dVq+nNDRcM7SCGRAmIrqHr1d/q/q6aEf/avX+n+tsM51O7QIv9Tu 0m6dUrghoV9q/0+//JD7/r+1/X649eu63p6bRhzukSHwZoKfyY91d+/1tXUZ/ue7/f6f9/uvp9df 9etud78bZNwoIG4aXqxraVhK69DcJWut8Vv6vo2xrr1Vpf/+u3aoND7FcVFMUGKY/zstB20oaTa4 Ub6tajq32P1f/f4jiIaFoMJqEwh5/psUxsU1sRsVZyaVi11vtfv+IiIYQhhCLzHtBhMIYTCajaVi mkmGErStv/iItCIiIjiLCHYpimorjjP8RYQaFoWpXVEfzv87C4g8k4vmtl8hERmYR2Yy+ZCERkdv CJ2oQiI0/z2p7X86JMJprlRphMqMqOyS5C0md/e+vsLhbT1cLZ1CHamERh2de1gyWeSoQ6mR6GU6 PRERfsg2YjsTR2dGQ1/73533O93dGHXBEfdJUg3vsp2tpJdoNBrw11X7lZZcI/eu//03pN87nfP6 p/cQw90bMECbyoB6BEeW2U4bTnais7HEkK03f1vfr1/9b1v21Fb7M4wYUMMwn0nS8Q3UJ0d7iw6v 1hlpFilcKB2p/oaFX////S//+hx/j9hhkerv8MMvq5LrdG7M5Q7Hj+r6vqCHtVtb+70Y+udzDwi3 6+tIapa+x+m/Q0J6yVhfN2bnHV6SVqtqv8M3X4IY4udMIIOQMHbOe1gicX6fwRN/waX7wcX662Ni MGZQIpiK7WOwvXoQvjvU7CCv/6kPQTulYIodmErf2hEcWmEwnDTQsaxGDOE8LBmBWxFQTxhb6iE8 NQ3ERVnPWIiI0GEGEwpvrj1vNyeErSsRwlYoGqQxqWU+ImEIiMyIiIi04YKnGgwqcNCDNucyFxyu lI7ojuIhWqiIiIiIYQiLU/2pXJHZ2PBSLwIMqIEGU4yozqFOkYjUEOxvIRHYoiniDiqYiIjXQ89S x2ahLU6/CXSO0gqYUIMJkXZHyOgp0ZiO7RhFOZrVAiP2voIOqNbRrd2jA7c+xKQ7O1YRFjtAiPBC IrwTTCaZ9HY3koZiITKhFQjLSOq1ujd6q0bqT037wn0THKH76CdBNzPp1dFw6U7Ji/aaZDzDCDUt UNV+hb1ehq1feGR0R37DN0EI+jdpunqbNXO/hPeFpuvu08vn8f/d/f/XEfx79CrrY03uva2+iMfX 1WgRHpra//bPaFPufX/awvS/3/9evp753T7mhkc1J8wiOiOskI2uqdJ/76UP9bW6dQQpGBvn2Ns9 giIPv3ox+/9fH9/EacRGEI/6t/xGhzc4aROGG1tL2wlxoUwy71/1tW/tV/+Ycsf///ra62K2KYoG YIzlHZ72THCQ4aUML32l+3Uz+3taE5sJG7Oj/1EcGFP8Wg1Oi01SGGFHNkHHYqI2KYqIqGFo/26t hLx77ilvDxERERERx6fn+0rQYTsV7xUV/+6tqGf8m5psqannERERnIiIMoGEIi0GEONDjUV8tzRn YmiMaiIiIiIiIiIYQ8rpUEGStkeIPOhwwhmkQOL51yTy+VGdqhnY1CPRb1ch1voscFl0f11PoLnU KdjeEyVoxBBlSiIRERfKhELRCZlP0gm1/hPCGk7C+mt+i4YTQaLHZKQpDYQa6ZKRDqIQcdEepJVM coc7lOUObU42VoeQQ7VUe6M+9+8zX1O+30CI+8+evnH0G0u1vVdeDJYIhERqfS5VIvndNA5XBGXC Vdb1pOx7Vrv1X4dabhbaCebsJGejvd0bKLzW88BhZh+t56C+EzJEXP3//2vd1Xt3/52ni4X9J//q /zTN601T/YvP2mfPdet81vW0jcuv7X0aATEf6Ffjfq/r2Lf1+mhSjQmbLhPBAsRV3+3ne+k9Tu4/ fekCFN1Q7eq/7U/XUv/XX/++7evVdXdE4YfS8pWYCV+/thhWNabBc/gzdvqbnep0CjvaXH2qx/qK Nzs957YU3QTI+Fv+Pj/Ve1+1sUxQMygVJD+2I/Yiq+PaVtIlAdpb63jNAwNaEYMHZ7ulnRW/5hyh yh/TrxEMJhOGFGLTCadqbZTjYSscKlYjaVV7ZCDhHavWNtZuraLHOPfSGhF74pYiIyMeIMIRDCoU RHiLCmA00PN1msoc496Bn2Niliqt+he9fbXqW6yiQp/iIs5EREREYQi4jyZab4a6GmnYivimlLSK 1TUREREYIRaERGmh2hxlckoyFRBYiUQbMI5GoirR1ZiOxJGQyERERHsmPJSIRcLRhH+IpM6pPdM1 MvkLyliBFDyXRV50yNohaIUioy3KF3P6fp+jW7+zsJ63oRR1gg/P6aZ0R6Ois6SnY3kLzpkaRVop 0QUJwwejdmz9zwa9PvCfdAiPvzP19fV1/1U9nVWmEy+kd0RkUZhcGGNDT7WNNrf/9f1P2p3f//fa 5KQlafS6NuZ+ad98e7pJ9/7/8iYYHtdyeI+X1tyGi6/6uPIRJX1egRH791+FbbYjv/+vX1V68IRG 2poGCJMuE/c1x2EDATnc73/63c/+jvvhAjnZzX1dQQ7wTI43+ZH9eSHod/+v67d+5myOF/j7Xfgg siQMEWCgzdbStJJtUK9fdYrgijWdCGfoIYJkcYIoeYU2Gff8ev/1/5aRWuh9dsNW1ZOChAphMRX2 k4S+bva3xoQiOaQ7T+oIU1P/9G3PT+OtnQplhRUUDiGgZ1Ca2Ka2t3/wZnPoFCfx/n/jd+lndhj1 jNSIiIYQYWOGELtDj1jj0IM4S7/H7JjlQFXGrn01fVoRERERERER+scWqw0IjTFIWDPIEEVERERE RcWF7UrpWdrOdUbyEyryERFIgaNopzOxTOubyWs7W0IzcnBhSup2dhXhNBnWTNYi4TVBnZjCp2mV LKeL4IMlhHZNEdG8yLJoRH3duqpqdAlF49LaNEEPcIt2SnsLhNNC7NcXyFRCsg46BSERT5hFQioQ /rqd3U70Xn/QIj7pNrCum915rzQ2sLZF/JUiOgpqEpU07Uhed0yny+ZI++9b13CFGcqKtdfTz/3S f532laCen33CEaowSrnSyHXZ2+ChbU9/9V9X6Xe6/7xXq/96dbW0CLr9JGy+jv+/whq/cIoeX11u vrv24j/6//0v/eul+53PDobI6MSMOd69176SBF1/QiKBCmPjSc97e//269a3///f1/xHW9b7vkSj ASdzvpO26LSK1qsJOqHfgzc71tYZHO+8igYfW91v61X7uv/9ftfb/fGDNtYOoW17x1sRTDSjYYSb CtX062k2lbqEP/Pc4P36ggVkdJAih4Wps/7VIesRHn+LT00xUkPYpigZ1AiopjYpi6q2+Pu9vpCI 0Ioaf//iIuLCEQwg1P8MJhbTTTTGDOF4rs5bdRGwmv721VG5yb6YiIiIiIiGCDBMLFqf8YxtAzhD he9jiK+VwpHYjOxxDJGIiIaF1YQYT40O01VM74MEpGEiWZfJWRrwREJn2Fnw5WVhSkUbjlTQiIiI iOjGe1tEhwQW01TKAXOxvh2E7JS0zrlWRqZiKjNRlTQiQv680FjpGtwQrouHnpG952rE/vdT6T81 iIOzqj0amR47hGI7HGasjWahPV1CDaTufSBArwnfp5nLhJQm6er00a3tqjRJRa6uENPPo1iqSER0 bZGRfIXnZrmRIv4pPTcXV6362MINow5371079NwnRs0G+911muqYVGGC0GFyUfn86Mu13df/9099 P9dr9/dK/pCvv6M/RupX6Jj6pGet3f0ndiPvWYcxXWr4r/93/9+vt//uu6Gnb4QtnuFTzvev6Rn1 e6ukh2vVb//+69Dv6/MJr6//fqP7/3v6vhm52raufTeraUzlPjtf7X7VXW1s5v2QMHBBkcvq/Q/9 1/21+jK2XCapimKjiKbSoW9te9hhJhhWGlNzum0igMWvxt+571SbPaMMpf+sf/x2mk2mPqdFiFsb FMQmKrjY1iNlDmsJkxwUaobD5uZoGKvSfSBCljxRuxBggYUznHgwTCERFoWmEGg0NBphTHqOIaFi uK9Wz2xhY1pG/S/EWhDQiIiIiGCFoZj2sMKf7TVS4KgoehtKxQM+6d17iJKMRaDiIiIYIRYQi+Ls LrGhqV0rO+jvMiMwrIGioynzCMkI7IYiIjP8REREZXJBTs1EJpJhNOGRCTOq07UjemVNFQiEzWZr ZjOx43iJC+FXTV4abrr5/NQgRbslgqZ0WEH3dkJlEbZGRfJXF8guVeaiOzATJD0btTu5387h93a3 qEqbC6dzRpuvVMLa2RdpqmkdpWQmZEGWkCqjOnoUldexBh09aM/t5Iek6X6TddN+jDuCI+6vpujW 59rc6BUGOlv663f963fne9XO53k+bqp6fffhUHV9AiP8JGf0+ui37b7/9SGguuv8NV2/9tMIf9rr mbI4X7pbpv6szzeu3npnxI3KE397Ocat9WEECFAhV6SH/1//9P/+v9a/9oa8e29q/1jdL1iF7//3 /jN0EK/V1an/1X//1/0L0/3iuliKhBliChzOUIEc/39sL//a2laQ/f7+1x4z/1nlEfzCi8/xaDUE 0NC1/GxWx1YMwQUxTFfGFYimNaVdtLvdbiIiGFu4YQ4tNDQ9NBpp9peKdXVtc/nakFOgW64iIiIi IuGCEREaDCDCGh2KjpKI5ZVeIiIiLCWYGeSfK6nHeuQrIPJZl81kS00zImjsCyvPOxvGbrVTH89n Y8t2dIuwumnDJfMR2J6ZCsIMq8haKhEYjCO3EJYiC4Ioe0IiLXsIdapraNDRobDTTOyYh1CEX1TO oUlGmdAoTshUFBAwhGQrIRE8QPMIiEYQlbR2dD6S6anegRH3oPTYN1BEeSXdGt66S5KRJqz6HIaJ DhZ009UwmmQtEVIjojpMKZFnb53PDInkcammYJNLur1tXBg6SdEh8//3my7zZR361DCo2OdZ/ReP QXVyUhAhEUUoFynRiMqXb/0I04rS/6/ZFP+d7qPdN0/7/aMOd7Z7gzA6fM1q/8ER910pb6BDtaH/ ujDgiP/X+/r/7f+ot+02u/vGDEL4yJ5hq/1pPoz+ccw9hT9ns+Uta/cyI0Pf7XaXmMInH/9+vL/4 9fXeDBfpof7fp3XatOK2KTc7nfEEXWbvdfexraq2raqaDeK/4ZuBDutQQ9vXt0YF8scKteIrqv67 p/9syDh92x91dKxFWsegtwvfHTrmgejqF+m36bWEIz/BDff+rTe//+LQ0NDQ00xSHBW17GoM4WI4 QZgaiPtbPaDSz/9AzOd9qt/v6/9mUxS6iGEIiDCDCmHKHKu9CItTd+YKy3KELYqMiQYhkdBfBmBx tiKY1f20rX6giOZaRYoiNCIOIiIjOiNMIQwha7iMd2tpiuKYpiuOg4yuloRFxERn/MjMPGhENMIX aaF65XBRSOR2s5BxB5Cs7ojIYiW5BYjsSdEjERGjNCIiGEwmCafHnUQ6hCVCnXMMlKUqM7GpMEGE NNTojCKczsDYiIiI5nnYWEVQqad3nYQKdAiaBRgnYQZIZgyowmVedk4vnbka8qzO4Wpr6LxzXlx5 3/0s1ucJ+aOnaLd63aplOjFZWY7UMxGU2bONOjueNDQdBB67V+fs3Unz6ms90d9pN1PGoTeuEa3n pGgMJpqeyVCevW/6foaV3zSLhdvurhhOm9d6dJb1fQIj77+k9X2tN0D9/uxu+v1xxf2Neq/6pzQM VmkYCU31b9PzvIOfRu08L6+7Zz3Pq9IKFan//SC8f//77XX3v+km076H8ufbSttYzqEjY8IUPnZN Kt84P3r+vOi+Y6n/16mFH/r3X+/Yrik0loK0qghnQI2u2r9WrDpL7Sx/fulSv+njb/a7Q83KYFNk XBnCJ0ElFSMc2gaURsMJRhfi1+NJ15oBEfdY9pc96/2CI6BhC7VOONM4Mymo2NpimsdD9jQjxsn0 KaCjNzQ4fEcRERESoQiIjgwQMIMIWE80yh44aWsIW117ELk2tHa3kqFn9CIiLQuIs/lPFqSHLeIi 1P9qYcoc45Q+W5mKReIHEHGgYClPmMhMhM7BxRlLxElSOw0JfI7GhDiyiIiIwhEQ9aP51ENQiSJj hBNVNQjGkVrNTL4QZiOmCDCGQiIXkXQiIiMIjH+qzOTfCFXcL5/Vdrz+miQ4VnSLsnBeGXRjILGu L5rZfJZl8qMhEdpXn/fOOd6MOYdNMJvPqd982WezR916fVGtow1VOoiGRXwuuE7NQiZCspYVTXF/ i3rvVNik7Fr5nm4j60Kv36M+1u3pvPrqd80HvBEdq62urqdRCVCIUFy1DRf67/+q3tCPq3byJxcL W9O+u2R8JnRdLirc2Xfne877nHWi7qsz+x2e0P3+/ROAvXkh/uMf//a08RROGOrp63//3SbuhRhz xRhzvamxo73w1+1/vghvoZ+2e9V5++t6G2sER0v1+3+vpf71X1uNP/jn/b9t1rZ9OqrmgL3Uw53j vfTpL0jVmRj/1woIoe/3+q/t/r/194p42KhkdBWIp/bC0L6sawws3bXPr2u16whH/67VNnu2/7f/ s/xcWhaYURtDU6MV4uxTFO5EwwwyOgm64VhpQ1dhRhJvStVJwx/dvr6xEREcRdoMIXoNMKvQjFx2 KYoQZ1A2IpiKV7Xdb70s84iIiIiM6NCLQawwmmpkRimopimIqW5ozIuhERn+IiIgwTWGhaaDUJks ZHjWjcQzLxCRoGCXyMIq8g87W0RYzuaKriIiIiI0Z2uEN2zqEzo001Ois7C0qaZGsIMqiIWiUZkO iER1VINpOsJ+Z1po1t70+Z3nq0yWIugqqeyDiFYIFZ0aYQMgeQmQiNZmSf06BF/RuS6N2p8dTvpv V+0n60a2hH15KRCUifeahDqk0ztLggfuluhq6EVeu0s0RHRHRHRdBX9/N/1Tr3ukFptGjqro0M7V Qifr//q9X3QiIj+uvbzSMBO0Yc8SKI2v9Enz/rqzHou/02qNj/vtn1dX/S2uv//2v14TQ28nDCM+ 8VfeycyPBYQftXm7Xtb6tX893V9PU5EEMEOwgVqh1M5UfL/3rGr7//hCPHqtId7aUamgLwYSjbVj W11qoiPGh7r9xm6sx/9n0/rX/e/4wxWx7FUpOGPBmcraoUOZwubvba9tr8zlP/+wtrEcyNnsEN8x /wwmFOhBgp/0LSi7iOM6Nb6EbxVdC9ffGwwlfk4Y9Ls5NpRERERDCFnRGmhEXFpRcfxfY1ipzrVQ y4KTiwsdrGhERFnRERERaZ/gwhEXmPaFDU0DEmxbkDQiIiIi0H5nKsoez9uTa+yXOGa2R8qMg8hM haO1UzsyyLwiLQiHEZyPg2tKyn19MJlRHYwF87nnZzKnkLQiI+HTq4If80M1CVBqfSDNRkeOg1JX BSVRfOueiFZCIqPzwGtoEX9L3SbWaDPh6o0UuMENbVVOiTNAXOx0YjtHLcli4UQbrrudzwycHJ8x kdAih5FEeRH1p0ZyoikHngMhf6TaBEfdFjpQr2r29BNM7iBf+/1+qoRGEwQj/+mxBtN+npvo9z/n ft/7PBrfBEeQrz/Ivgla//zDljgiP/69K2v9/67t498ECEooOOWOU/xSeFuiQ+P4QT1df6QjjP8N T/f73yL4Xj/8f6xoIRH3V6VzveqxCimLXvf8V7St+1sILX9r7PL+/r/127vCaYrY//VtX1bSiEM/ 7W9TqYW0/UEDmRBD6+v4jCDCYQ0OONMVUVFQXsMJMRSFRsdIuH6VrHv/ERERYQtBqE+xToscLjp6 wZrBNpNL/ERFxEMIME0M/wwtx3Fiml44iIiIi47QtC1JtESqL5ri8ahlSyEyEzURIil5Ckdjotwe drWIiIy3SvW09MlAU1imsVPKESsVVKpF8l8iMwjrlZyV5hFQjUIa2dgQndXSea3hQqNbovWFIv3n 8LnRoMJ3IIQZyesJpnTTCoMqWFNcXyGZA8haOuQtfQIuuCL9pPNlF5RcAiP036omOUPX9bdV71VX +dQZ2SoSZyhwS6faqdlf+rtLeunhDCEVfd4IWt753ulO9Gfc1md1O7mzO/30g2lQiF0aH+es/nav v+vqvY//f4vv/0t19O/vTpd+2e6dEh+f53t1m1/+vBFDy6BFD963q6u7fYj14YKv9fv+l4/v8fzv bjX/TM8213q/ehER9d1v+e3PevZ7CZckN//9e/S2/X19d//erQyJxcLe/9pi1YtYYSJQFjjtIGbs aFTD/Vjq+utjSW+gQ5wn/mL//5h/xwwRT34M4WKYooB61NAxvsmOccKj/GlSvrf6nQO/12r/T6xG NH+p/qhH/DCYScwM/5s21ozlRBxH2KaWIpjFrhRFBmBs9thLvz/Gl+PzOd+dlweIjMiL7QeY8RcX xoNCwg1CHmC08cVscbHOfr9Dz/5Nw8RERGhEREREGCFoGC8MIWFsIRFx3/Bmapgmz524QRERn+Io 0FDxEREflulOyC6RCo1ESaKhEJmsyWmdrKOxfESlpoREe2RdhNFuUCU1VQmmdujcFL5C8hMoIush Mg86ZWc7mkzSE7oipLXVwhCo1s6hDUIdRJoaNDCYTC2Sj8IRnUIdRJBBeQrNTCcZKovoMg+GVeYW npGfZ9TZSdVVJtJvnH7rfLfptroetkUyfkVOyOLBppkLzsxF+v1bF0Nc7nijDnijOd9PTsLbR3++ wp+o2Z+U0GdovOixzj2T+F/ZC6CHISq+dmsXML//r7/r+rX9Vf/zTMBBXSFXp24T8IXDD53v5EGy xyx3Kxo4/9Vu/9IwV///t31+v99NavxSb8SJRcKogwx/y+R9Qkgg4cUle+p3c732sfVnu6+/t/9+ 9f1Wphzv93/u921+IjCBV4IFXkSi4X3/sVQVs9kUDDa233f/a2rHXqCFDQvdWe7Od+57hT/z+k// t7+/pel9prQ1iuK3rtWGEm0qVjSa9tY4t1cgQYHwRThkdKEEc/Wc8iH9hg/S5s39/DBCGuZENDjG LFMUxTC2KDMD8UqwwkP4QiMEEt9dkNXaWaJtulGndJX1iMscp4iwgwmE0wmEItY7U3ZuTFIx9ehs R9RTajDCxf8aV9YQhxEREREQYIREQwmg41OQthVojEComGCq2rYioiW/oREREZqREWCDUEwhxpqW 5nF87Ws6sxlRnWN5CYIibQUbEJqEMEIiNc7UlaVmoROzWKd/JlOy+mQrO6IqEdzRCQiIwtp9a1gu je1yUhLTUhMi+mThg6I9HXMR2ryNR3PIOIRZ3vvTou9PJvdLXX790l1TRB9J24pOGDXKQvO4zCNS P/87A1/whq0CFaed9z/+u+ez330CI82FCpAhkqETtO6+g3+/87iLhe0t8SJxcIUtAink6PL6sVb+ q5cGdzZRGPmg0VChfW/wa/X0/7/64TLhQmRwpoyOF+n/3hO6Qz+hQQbm7MOd1O+7X6thDvbPd+fT z919d5+8kPf/r/X1v8foa7920CI6xpB0mwpOGG1JwwKvFN9EUSDI6I7FbFG5DP8Z/gh+Cl0Culv7 /2u6+DEIbGDgzKBSsUrrcaoRH/d/9rEVGvXZys9+59P//DCF2FMi1NSPOdMVtddX4MwQMJVS2vHH ak+h/vqaBiNC040GhcQwpyItC40PTFAzq9MYrtpBD7u+riIiIiIiIi7CxFhTdmHKexTLH7FMRzoy zVaERDBEdCMIQ7UIoxppxk2jIXkER0iOi6Lsi7MRKWYyIRtHZdmzOmdigQREREREZbpXZKRCLtBh CI9+wmpCtbsrGpB5T5hEJlQifLcq/haTrunXIvXQNSDip+aLA4TTOnkQlzCM0djsvnaSL5C8hM15 fTI0iozt2d8i6I7INd5u6M+ez5hPVoER+/hba7WrrZ1E1VdclqVQtw7NcFJeTCEZ0aZT5hfoTQdV ilfr1vvmHc+Hh759aM/9V9AiPthbJQEOgRN2HhDIc6DheE7/3/v3uvv/q278WaBVrb3RnKi/1873 S5x+U56Ix9aNlGCJ16rdfr9f/+1Vf9R6rXS//6/O53ozlRSewYZhKjeu6tz6q533BCs9zEx7re6v 4IoeXwv/+s8FBmcococw/fv+4j//Xbpb14zkXCuP72mk676IoC40t7a2l6SERVphbXIGDqOIi/0C H7v+//+++F/6+O+vlule6sVFMUxG1EbdVTn17f1beDP+9fSf7b+qCJ3Gf9nsECsul1MKF96+ciNN BhNNAzlhblDlDgiPRiRTi2uIoGYJivYio1/9W9QQT/HER3SaMEq/UREWEIsLhCItBhdDtOLvtMex vHEUgvXhWF+GlfxERERRsiIiIhhBhDQtBqFi8w53gzhYimyOi8xTEUWoqcs4RHc3QcRDCDCYTvVC /aEWGq5bmcXyFZri+RmXyozXmERmYR3SOwYgIMRKfO55diIiIiIzoWIjXJR2thbUKmqZ1zDISNAX ILJlRom7KmkDKvITBCiEyVGSaEZ5qFv1dXdcJummdRKJUIjezUIgQbTCZrEOgVI1iIM1iHVl865u JSzEQqIVmuL51yqMRzvdXQIv6BEf1QIj7ow66nHrPBcQklqk3zW1SmCUaKrdp+SkISoVfI3hMlsX zs6KhEJ/+67q80zeCOPpvpu6V0ZyojCbnHM+nRhzvp6SdG7NnReaDaLjBEffQIj0JtQq+ejUIi3Y W0zWgt/3rX600I9b+ur11dWv638ieYCVdDTtnOFpcIOl9V7zZReUd9+Ekm98IdV///3+q1/qrb/t v/v0/8W48e8f/ddIYQ+9vO5306PH176kTDG1X4z//6/7f9//3v5xzP6+r//X//99duvTylo8qncq JIRdGPxpUxq3rq3rerFL+6/x9q6QqPfDOaowSe7qzy/0t99fj/76wmRwqS4QiOxgzKBURXxFMRWv aw0u1u34YXttScMHQK6G6xd6sa2tnJs9v6/3X/9t8MJ2E0LtNDTTFBitipz2opimuKVBQzfwaWxp awwlGRMMXpTDlPf9fxm7b86MRERBhAwhFqhoRFoMIaDUyMwMc/WOW5Q+KDCoMUqsR0L97fevb/8R ERERERHoQYKCFoMIRDCm7Lpa3djYpiKr4/lulDO3yForXP8RERERYQcMEIiwmE0OLQ8IMqXZAkgy XZvNQQhMp0YR2C5kBoRERERERovHwyIkHItdUsJ2QkQWkHLn2KH0LhlQinMjCIwypo65GlhB+DtW ccHtzjdf86MIO9s6dhBpoMlKTTI8R3ZBxBYhWQeQiITKcyIMyK0VCr87h0gRfEG4T+gRH7+ef+v0 a6NbRorsRa5KAinRZ00zUImmdj53WggYQPVkSzYQT1VYS+zktbk6/CBQp3dU/dPTpN7yY4Ijz6ko ET9wqNDRoefyadpp901/wi0/YzRkcKvhMuEImC7hLSc7EERx9+ra3T/CdvpG5L382UnSbXvRro1v q8w53kPC/t+lXX60IQXqh/1XT9907nAwaBjFGcqO/aTVN07/aTdPjGhfCC1wwd84xT9vVqbnMegj 19TDljnH9ffr11+v93X+P+37+rf+IKKU6J2wuO79D9WEqj6EXvJww63V4If8yM6L+9r06/2rXXXm cpyhyh/wnWNirPfxr/obS+2Faum1da/r+zn+CFAh2c3/Q1W8x2uhEWh4Q0iMuFGOxQ7+Gl7YoGdQ OKhhJl8oYUde4t/qigMWthLBCnXeoiOLBDiGEIjOdiI0GFsJpig4sU7+vGDMXMntpAjjjRv912sR n+IiIiGEDCDCcMIaFqf0LVPMfFBC3wZggjOBiTYtxEREREREXdpoNSTnePS9AyYyERDRxGIg8hed M7QyU5wzLVHeiK6qhERGchC8yM6OHpghHkrFUhM3IMJ5ERUoIGSrU6MxHYkinZ2BZH0xERqhs7kY OdQlYXPSaaM7oHOjQZKQgTU+icMbnc4h6YQZC4IRmoipZUIheIxD6U8Gzok/2kCI8kHhXWs1vTrv XRbsldwkyUrUigYggijMBJ3O8as0RtF0s4TXT1eYPpGfP9J354NbhO9rQcEKRghradnTtIyKcvUE mvt7oNCPvS9X6rq1Gu6Gn9XWr3p/3mcm8EO9TDnevr18ev+1+79+lfZWWXChiVXdGcqMMjojtb3X FhN8GTDQu/vjP+z2t1v/fpfUf9PTX1dxHTv+k6M5UZNi3X/7CXkUDEw53saVpagjjpj4ZuvW6van 6UIjpXW1eFeu/3S9Cv42Gvri3StrER0FjtZuuraithCJE01vowSoIZPqYQXr7yRiLTFDzHtUPFSQ 5h21qxVXBpMU/Io+GFfVz6tKoiKtfewQg0whaDiIhhTnQiz/DT0xVDzkWK44ZHScUDNYJptK21iI iIiIiIiGELQiGELCQjDWIM6kKeKlk0yuaoREcMJrcXk2Hzs+dGYiEsrSKhQy4Q7iJXFuCqeaEREZ bpUg/zWJBkRGJM1MJkHkpRhxRri8EHZAs65kVo9mpHslYgiSj69NhUHaZ19Cjp4TuTg49N04Mp+8 /nalmGdcw4O0DsJHc+zuqIP1O76ebLO4dIER7dFj7t1bF10bLKHe/prd7votyt9hkkjQFynSkTju eTJfcreRw/pCIYdU/oI+t6nhhh6M/qxBh/9IEX9HdwrhN0IWD6OoTL5/zCM0U6MR07/x/h1/6GtL wYY13uwzC9vquv3Xc/o3SnN57NFaVdVBD//MORj/cg0k//f67668f3/+/08eIMNRQTc/rf//xWkL 32e7BL8ENz6BAoMEm6wu9PhE3+h/r/31UiGC3W+Puvow5498L7YWOIUUqUcRxpBAjndepFxXOBj1 3S/dZ4K3bXtftVOgj/X72qfiEsJ1DLtKyY6pQgtjWGlCdqfsUsaVrdKOewRPLSN37YjCDiP70owh w1N2CGg4zQUOw0Ia0NimKhKDOEu6urFMbn9DBBY+2sMu3BEvDftwQ4iIjjtCGsRthNV9Y0wtpqO4 X9pRhm7CDYM/7daiIiM50IiIiIiIMEGCSn/Cx2K2sR7eKBnat7kJiM0FDtx2hDU/xd6H5XW47uIX kJkLzVF0RGYRFciqzmFNQh2SoyUIREREREREaldT8mcmShWU6CqthVRBE5Q5UMieT8RhTtRAgZGE RmYR1yoSncQ99U3OgQlIi2tthCK7k7zbG57TCadyCET6IoGDUy+QcCDJTlTi+SsipojEd0v1O79E h0qBEfdAiPvPR/tg9fNea2F700l9FjtT2umSxEfTTL5CYQZGRfJWX/d+d7c7nfX1+8/+gw+z36Ta XO/ZoM73ns+V3oH7C6NEIRhc1CJrp/S//dab/Xxb+MGGLG/XTr3Tu3itzvtUrep32k2qBEfsJI2Q to1v7aWv/3/v+Le/f/dbpN99P7mcXCb3pb08/qt5hzvq53uk8EOPBD////IprznhUbYkP+v/uP19 bpW//yIlH+ttX/qzIqeFha/f71vXCRqML4RuPolv+9L9ffVqft6Hf+g9f///fgz7mqBmB2PjYimI qKCFdhLs9zdbW1fW1eeyh9r9D70vpXsN3/9//X4wnGhaaahQXSHHXFMVEUxQ4uwwlGq8MLN1v3CT cGRz9L/X+6eIiIYQYTCnJn2BcdpoNNVsUxTWxVWxGRQHBpDjXvtK9JtRiIiM58/xEGCEMIRDQYQt BhDTCTGZzj2K2NimI4qVwXo5C7iIiIiMuloQ0GELTTCa53pF8gmU8TGayIaI6M46Z2QxBAxEQ4iI iIMLl8/hclEg8iO0whGp9BBouGd0yWZeOmRmRVEJlPksyN52kxH+t6f6NbrtFu0EGyaWE3U/qXz+ dRDUIFL+fROC5Dz6IOCBkpZiJdFTynM1o7K0doVfne9Tx1em57Pd+g6T9rv1qut90qZD3Xzo0GRQ MBNM7Emmp0zKF///31cUg3edGbkrq953/+6LyEbqBEfe+ez3/0a3T6fM7z/5SwxIJtYdv19L//9v 1p/9Ltv/hPT1/ik7/dOldTvng10g7rTpW+I3+//f9D//r977/HH99bbfdbp6Wxpur+m2eD42aDO+ H9J0vNQY0vXe1619UNiO7/j+Gv0/9a6vb+O9O6wz/jWML1a2s3RF6hqCFN9buenPf6voUCBWXQJa 3/7/DCrpWk3nZSC/2Ka8GZONhhJ+GFbSq9Ub4ZvmgLx3rPBT+k4iNunW+tXWKf/7qO0NU+xVOxTF AzKQin36ViKx4YWbrCtYaTGrpXSLHOPtbr+dGIiIzHYYQiwgwmmh350Z/tbsU+GdSFMVSw1taFtt J1tKu4iIiIiI0NODCEQwha2gwhaYhMU1xUUxj8REREREQ0GELQaaad5XSs76IVnUioR2hEZl0as7 qRFkR0eyryFIlOTCEREGEDBCMrqohNAhLEqZqgg0wtraF2UBgi5p2CDKmjKiJhkXRkNYjVSUBEa3 q63nsml02r8GmSnshM6RhkKgQYQalLyEyDiERqCUSdT8kqep3egRH3/unmgzqE8NGt/6kpCaLd5f P5KRM0BdUiEiZxG0SjISI153tqM7lR79ylI4gRQ+vfrqxoG+54Dp++kCI8lOg+if9PrRhrn86hM/ 0fzUIdrV/1tvf8JhCP+/ddLVxBvb3+nnc79UnX0Xi57Pn/Vf9TtTE/v/qYX7/8er13/+pmyOF/+7 I+R0COPq3+EJPmMjyilZOtz1T8/b70bq/7Ob/dJ6WKN/9bLpL+vIvhdS///+8REe9/qhHuEy4SM0 zAQiK9Rffp53O/bfH+2tRhdb1myCEdre2lYQV1ghQz/0v+rViO+WOcevrSaw/778V/UafGhG1T7E VTwm0m1bCxBNr18a/znvTtnMYQu+Gp/oydTdhxTxx77cWpuQtY4u14M4KKYpioSEYMwPuva9wwoZ /x/aj+Pba2clVs9/xERnREQwhHYTCDCpaHGnY7aYr19hhL3Pfg83OOf8/0P+IiIiNM6IiIhhQYhh Dz/HYoeLGhrX/+1iIi4iIiwhVxebr48/3YqV1OO6RfJRlXF81kSIhER0ZxCZCI1mQaMI7Lx4zItQ jN6EREREXFrR/C6n0unRIQQjOgVNBhNMhXDzXF8qSOwecSZCkVGRdESQiI/X01ue3l5OknRoq/QO FslQoQjIvpnQKiCamHkXiCxWUSxGEVaKkt877fR3uk39TwbM2em19Be4Wv2Gh57z2oTtSVoukzVF 8lkXyoRLMvlWiE7/vb/77WNXuqToz/cw9HfzjmHz2fO8+KQj0WP+slARbOogIRQXC5ryOQWyMQL4 ape2v6+vuLZoC/dbZEgx/9rTik3+8/bQQP96oER910CI/a6FK51CdD/Q/34j//9fa+6p7X+m/fFv fngqNejDnjN2t53tokPQIv6X29Jf9X/nI3X1Oiv7Xpu/4/f336/9e1/r6M6evnc71z/jWbt4StIG btqdAvurfruFC2q2/4If+59IaH9//Yt/19L6V+2aMjhfsV7EbH2wwklrDWI34jYun1taNQTrjmH/ v/7//9tt/X9caYQuwmENMVMN2ITQ6IxzD2PimKBnBpgworR/n/ba3rbakpiOXq3pP+/+M/4iIgwh DCEQ0GE7OiwhdrZ8CipN/+8UxFPdBCmNK9f712/5XJUd2hMIRERERBghoQYTBA4uLi00McExTEVx sRXHrK6mKmmV1XITEREREQYIMJlE00LTQ4vCeVjNcXzqFNREZF86RPEMyMMp0VpKdQhK2TchCIiI iI0b3BktVrwk14001KoiOgpFpVTIXnWJOL5CZCZ3CMIqESyOwPI6CkZl1p4aetzhDW1twi4aNAdn si4VNBTBRbslLTkH05qEOgUJ2a2mdIuwgyWRfCEaFkIiKZSRRk0jsx+54D3R3v06O95rNGm0n/QI jjqE3ptra0tq/aLHadoscJ0zpF3xk6NwTKvJWVkaR2tqriDdf8Mjkt/0/T0/z/phZ/V6nfNZnaO9 0bs/UCI+6O/0CI/CDavCEq91Ty8enTTCBEd2E5FrPzO1JX//+OnX1t/9v9XY/pLp3/oduv+6q1dG f2fX1O/+azx0CI9Cfnxwfp38mWErX+R1tX/x/4xt6N61/ff/j/rulvXXbFmnmiOJaW1qqbeqem6X Ig998dhIEK9ZwmvV61b1/5wp5j+t/+/+tdf/er4aFdbvpf+k5pmGCKfThL/8QVX1n1a31a2lazDn eSgJgih2F3Xj9L9XPf+303XamP1RsCyPkeC9/xH4/+nEfhAvfzHwgZggjsECTYpiO1JwwTg9C6oR Hn+DS2lte+ozoFvX+NJ6W6qhiIxn/fT369rSMP9/+0NbCQjaaDFWn8znFyxynOPjQjaWKFiNaYio jpYumLXM1rsUoM3XWKV6HPbeDJoGdggPFoQYWGCBgmFMfL4p4jQsIRD8iDxaDTU3Zt0TQa0NipGP mPdda7SdKwvdqdFpcRZ/QiMIREREZ/zkRERERDBCMzlQUO2FH44v7FMLIoGGsiYPFHXZQ5mnMREX EzQjQiDjMOceNCIu0IqNJwWNSuqx2RkKiHno7/IzL5Vog8SUhDuaEREREZiIzIzyGfZKAnk0WFwp rGQmQrJppEL7IPKfMIpyJGVTI0jsJDjiPpVVO1zUICmoQlImf0ZSnUIdOwqYTUvn0p9GtpkHIMgk RBGqKwZVojEQUIduiPr9G62u6O+1RblD1XXXXV5r1pumrnURGHdH9cujNBMp3aZfSOuEIzpkbzsk RhcmkXC42j7j+87lRhCHRhzukYc8bdz2jDndI/LeCL+lf/o79aD/PbpNNGtrhdGBz2iQ6z+dAoTv rWDFev93jW3Xvx12o+l3T+9v9zjnj5vvXNr+nR36BEfv7nCVpftI3X//Xf//kh/77Xr93q6pbq+t 7/3vr/dbufT1ma3n6jv+NdnIzDBSww+v7Z7+/0NGCvva/XTEcfrS2/319/TaW6/F+wwW/v2/8d1f T+Tg/fbdotzj/+GbicH2vVpK+u3X0Nv2Ir/X+r0NvF1/+sx4MygR9qF3p+mhdz3bfHt6t0Gbmjc3 +34j0I27X6f0YIORuo/+0LzfEXYTsVLPGOo/jajUGYIIqN3fiN9ef+GbraTf+lSzhO+sRERDCFoX aFoaUXm/tNUu7XFM5/zHv2lGsatn1P/n+dAv1ERERn+IiIiIiIYIQ0IjiIuGNigxUX3IXT1EctzQ yWorgpiIiIsEGE0kNY8+0tSut1hEYWcudWVqcbOGfeI7IZZAeIjN0UXkRDBSup+ynqSsU6yaan0U 4siuZbCKzIMqaIVEIjqzEU+XzrkmZ3jJWjsWStO00PcdGthNUzqJpgsWpU2g0aGRSUlIRPwt5/CY QaYIGakpCI6ZUkRvEREgi/02aKfk1O9X5d2RHblzqcek369Nq+qLhot3R/TCDSTkEFmVcpCsqEQv NQwg/lb9J5GXiktzuVG3QQz5fcx0k9P83enQIv+8J4T/NbVBd57BDIuFNeRzJQFTCD//r9Ovb7pX rX/7HQk6MEkvXt+2r3pOjQIWy3M7+TH4Q6nyi4wUEUPjv39e3Qr39r//wnH+var1b9X50zeCKHwn d+CBqf8kPRurdN0IrdWdIznfT+tnl9sWCKH/+jH3zud2/1xv3UNf2k0I0m7vUfRnT909PanPtIYt jX+bmTg9pVEca2v2bhUXtd8Lq+h9Vm90v43FuvF/Xgz7fbFK18fptqMznHKe0raXkTBfVtJvWbt1 azD7/Vqbv659erf7/emFN6GhaGpjpioQiHHYp/a4qIp3YylA9H9tYjHttKpsk+hZK0F/XXWIiIiI NDCdhCItCLOiLhhNDtX7Fb8MKNOhRKAttqRcLdXUm5ohEREREREGCRZ4i1MeLsU/Lg45TuE8UgmN jk2VEd4iOgotYiIhhCMIRanAsytNFqFSlcki+dhbhkLQIRnTIWzGVCMuzIKxERERERGF100CI6z6 7sg47G9TLsp4vwzspRC1QIj7bCb5i9Onzpv0Yz0dhdYXkXYFJWM1xeOxmVVmIhMhEdg8k8gi169Z 9P1f//63O4MJgoT8vn/zUJZCtEH1aDI6I+XyRlJ/6ciWYCMdurr/77zvcQ82JE4ow6f+nU6WRe7g 4iIeXz/n//6fuvmcXC9ndcXC3/r4JJPCen1+rRu1fc34cjdLrr/vedzvngEhT/9exkcVrr4LGh1t /V6H93QU8Bz+FW+/1dIcdIfVqf4IdT/jTW/3b+v/9/oIIQbwl/fiKjW7PpG5w0h9IfBl3BCn1Bk9 qGc8+t+I/9axCWIQV6tqdrFaaa4YK+xXsm5xwvaer6OizsYGCJ4Q29XdWz2CFAgUjHSBHs6YVI4m I0KhwwgYIWoxaDQ4OIj1gzKBFRVxxFAz/hhKOojCXhBBBW9w4iMseIj0LTTUltQY+ZyhzuCI+17F KDOCE3CQ4ggkYQIoeGbqN17CM0IiIz7MBDQiLhhDhhT/w4rCiI3fztL5XSkZTxElqERERF6dqayo 1MOSH1i4yuSSaDILlXF9EYQpOVBUhBWwMmWnCymTQKhDiIwhw1Pa7phOyo7TIOCDKjBBkujCIWiU xvKhHa3iI1Mjn64NGoRbNQmdjcdAiZ17QYTslCs6xdp2akRxnYTIwyOIa4vkJkL8/oN+jvb1QIj7 hLdUa3vPddPVNrQ8/oUF865hlAYLdZ6iGDI++vmlzuVGvnc7tTsuubqT+raO++2p306Lv8zkx6+m mqn1eO//1//3OywF16+/p/enSS0rhOQXvahB5331O9ng19dnsETfG/uR0CKfW3//3i3X/r7/3+KD fGm13NM4iOgtLjT/g1Mv0EHX1iI7v//nIx90Y/+vTX6v+/69QQj6tK38aELn/elMPfW9f/1fzgY1 b1BCo/qz20h+3/Ix//30TfC/YiqJ7vYitv1mpIYWwu02lfW0raggwWvX1Gf/1dR4IGmsdroWKaGM feFEYM6gbEYMwTsUEMZ/w0r0vil1WIiIiLsIGCYQ+zg+wmsVak3KHKHKH+xsRXurDSm7ERERGciI i0IsEIiHEQwmhxaYquV1RHaxCIiIYQiIafrDJiIjIyL5rI6EVeYRREUzsbR2pMq2UiJRiIjU9QyM CENpradp3IYrpkJpoM66lPl9BneqIWr52pmrppujW0aIXwp2E86hEZ6M7tMLyJWZywtkvHQIdUei LCkEi+QkaiIjL5TkVeae3O+w2jeqndzv6erNqd/N4SLvulTaQe1VtncPTzqIq4Qa2dQiYXTKcWy3 Cswr4TDBkfxXdLtfdP26CChCQW+dzvIVLm+rukCI/iHqd3pTX3RfNX0a2to1wtF49J3hhXjekv/v 9LxCWvrtp16ua6vBL3ImjipGHO7oP8IOjx0fqToER90rRY5T/oL0OgRcf1+nox//hBHF39e///6B JeEwh1v/q3p2o119PCEdrnf0RR7kXFD2co6uv+Iq9UFdntoEGRyv6u9+/27S+cf+Lf1/T3/9/695 vjBcbSumsMJLv0ElJwwKFP7UR6R0Mjl+DJ6fFT39qCHa7X+Y//4jre6wtXWIqI5z2I0NWTcocF2o 9rTV6nRLGl9t0dAlMNL+zk//3TZ7f+I1s/xENKIsLmPBxEWKZSLFU2xFIQmlq+NKUOZyioUxpR2C XerqhgzdvSiIiMyIYKdFpraEWtwwpJJGh5oBC4tMaxGxFRXW9LESMQiIiIiIiwQiGE0NCwmf6sJq f78RUmylpleM7EsTu8RERGZEQYW4i1K5JF87CsIMqMg8hM1EakkdcrKO1MISlKd2pGmFILlbMIWa hM6aphBpKfRKEmSzJQijSIsISvUhxJxfBAyoyE5CkzlRPasza9AiP3Bow5dwl7o1u0tMziHW5FA6 fOWhoNBZ6C6Z17OgSewZqEOkXaDIXoMgeRGU4zUzEVaNRkEZ3P1vO4dPzjmH/06PAr4YKugRHq1R oPFCvXRsa6qDqqaNHRh5VoFOkne6oNBhBmQKv6gyMVvq05PmAna2rCegxBPz2E3q56SbbRoC6nfd PvNlwQJF3qd6TfQbIgIqYRs1Z1CIuGi3aBEdmQp3/wbX6VtP63+8ML/eOP72m9d/fpxBAoQelun/ N8kPqd/dPUJ0E2gn/+4O//ujd/3o5xj6/1713df/i3WPX5EgXS+d09d0/o7ndrdPQb7+ljr23j4I bpekpFAx6Ux6MWV/N8V/+uwb/X/63ek//70/a+9iNUI31+rWI5udNhNa+NbCqt6Tak4OpE88dnv/ 2dHtff////r9LTd8VWDOoFJ1QMxYI9XPbXEc/tvW0qNQTbKAdj7X4j/jSbW/+0vf+DC2UhC4+0zn T7hmsLeLDKopGP9iKJwwDMDWRwoWgrDCVrIx7+0tpNhf3W/UEOIiIi4YVOI4iIqIzoi01bzFgkYZ sKuOxTuykeN1JweK2OGk2FtKoiIjN0REZkaamLoWhYQiIi0LSYaemKimKBmacxaERERERGY8RDQa DCaqV1vEREREZXUq/3c77LYKv4UtxaO1mLSNRf2uTYHhYKRxWu00btCmnrobJWEIj8GhDV6Fz3FD 8rpSn/K5IKVrOEW6RGcdhSM4RhVTTCaYTou7z30Z3ow7JseOFQTWrek9UH0yyAvx33pu1b0a/7/9 /6vtnk3aVtpW6vv4YJsRt2rd1balkF0R0uNhMRTEbdpFkG2EI8w53nY6YTCiKqYcw/CFoRFoaF4i DOOC+I/HlcFjSO+y3F0Ovs7Wss1av/k2CchWndkfL1FKRHyOiPr6yGGmaxEaERGW6sMHZaGOb+Zz Rmcw5x6qTZCI+X/CWhehF2dGaynKeEIjEETaed3+4i8zmHMPQX37W9xF7i1Qu/2oIqwcRERr0z5x aawsRiFkbTnO0wx//kB0VUf/////8gOmFH/////yA6BKP/////////////////yA6BKP/kB0DVY/ //kB0CUf///5AdMKPIDphRwAQAQAkIj5f8JaF6EKZW5kc3RyZWFtIAplbmRvYmoKMzUgMCBvYmoK MzIyNDAKZW5kb2JqCjM0IDAgb2JqCjw8IC9MZW5ndGggMzYgMCBSID4+CnN0cmVhbQpxIDU5NSAw IDAgODQxIDAuMDAgMC4wMCBjbSAgMSBnIC9PYmozMyBEbyBRCmVuZHN0cmVhbQoKZW5kb2JqCjM2 IDAgb2JqCjQzCmVuZG9iagozNyAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1 OTUgODQxXQovQ3JvcEJveCBbMCAwIDU5NSA4NDFdCi9QYXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAv UmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERGIC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9i amVjdCA8PAovT2JqMzggMzggMCBSICAgPj4KPj4KL0NvbnRlbnRzIFsgMzkgMCBSICBdCj4+CmVu ZG9iagozOCAwIG9iago8PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09i ajM4IC9XaWR0aCAyNDgwIC9IZWlnaHQgMzUwNyAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxh Y2tJczEgIHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDQwIDAgUiAvRmlsdGVyIC9D Q0lUVEZheERlY29kZSAvRGVjb2RlUGFybXMgPDwgL0sgLTEgL0NvbHVtbnMgMjQ4MCA+PiA+PiBz dHJlYW0K8m5dRLRRR8gOq1H///////////O0peM7NFCCHx/////67/8gOlC3H///ySLx//////// ///lYRAXWvloT5aNEWhCGIiP/////////lkH4lrE1H////////////////////////////////// /yzQ8mxYpXEwgQNM7CuEwiY7ovmedpBM03CftVpPTf6N3Tavu9CRGW4EZHC9ftV7Qvf7EdwcschB 9hhJ1fPcOh7FQ0gzdjD09hMU/kmhGIaFqf4xER5XBMsonmRnGRaMg87IzXF8t0mefLKTV6Z1kGoX UJ9P0bOmdjhP5ndd+rqeKSO+9JuVxoF/9/53O7Xd6fv66/7/3fZ0VX9//r3dfghW6xX9t63YS3/a WvdfTEVfBmX6xtLbexGwoi7sIaGNhDEQaEMIMKIjLNFuVxMIV1DLsyKUYjtKggZkLZCZlaJZF8qW dGbyoy3G0R1T0wqZ2qBFz+p/OyVKuvmsQtzASi/bU7vTU0ZQ0a3/namEW37Cp4T+9TvmzDBLbvdd He/ToscqKNN1bS/3SEGIVP9ujOVH8imXyOlroRSf+v+7Be3t9Lr6ER9+31uv/HzHGh/b/9brbSY1 j7OVpartv/ORvbPfViqSaCxtqs/5u3revtrGwZfC2h61Qj/d42Ir2KViKiIsKbuOOLTQ7U3QwotD OiIsEDBCLTQxERERlmfyuCIrjUZaRfKjKURHgpC8lIzsCIlsXyMy+U8XztKzrkbyF5KilcSNPC51 CoRrarhbXvPo6hSUBUy3Kug/XqiVBEa2jQ1tXW9U1pFw+jW353to2Z7PjSSdJtAiPugRHtAiPvT8 1pGvT/fK9TLhF/DYq87nfV09fT3XnYKjaLrt3BvBtK19+tePWu3//66+EwhG/W/uW5MMcN4zzd/9 v/+YX/Vf1oY4//jtX17r+6tb/339qf/786Nhv96R1Cuv7q2kt62q3qN2jdOgUlAW0r7bjsR1FccM JRFMRTEUxFV+klYV+LQsKfZ0LTFJtNNDTTs4WZygUUPEMEIYTCDCmPDCDCDBCI1QsIYiIi0IiIjE r18smRdmReIPIKiXy+SlmIhediWQvKfL5GIxWSZmqJ2QPIr9MyICnTsi8gwt+dYuzWIdqwhKxQtm gLwwnGpdGaIyUg7UER5L7TV6bi1UKr1BzQ3q0wQ/082VekZ6BEf6edzu0XeaKLHKegRH+ez3ndpN zWaPur6/d+qurv/eENA8IRpvFINuDDp6f/m+tP2m+//11//1vxdfbe/oTQF+lj6X+9P/4t+/6v+M R62NVJwxHXX7r2fS2e+q87UsJeu9n0zo6UyQFqltVhhKKUzBc7VhCJgvaraxBWragzOd7HvDVIIG YLqxFMbrrsRTaUJsJWEnF11iMwSNNBhDUyMxWY9pioUUxXyx9PaEQwQi09NOGmsGg0Iwj+NRERER EREREcrgmVwOJRHZXkIipIhM7vLop87EiO8Mk0ZF0VaNWVeTZXyuLiFcIEo/qmuFvTIXJpqtqXyo yE1L9UvzqEJQE1tUaGRe0aHnYJEPKK/C2ahDqEW6N2ccz79JdAiPv07uk29hd/QIj7qkr6HffOy+ YXO53zDniQ0XS1+r/T7Ff9Xow53ow5noEXX1Vu9CP2yIq8EI/+r780i4UGCfNIuF/ut9q6T90+h0 voP9f/frzCXOyREdf9dV/2/XbOd/zob+w/uZH97UKR4La21P8RBS46n7f/3/v0N7Wf3v+3bf96q6 QQinrFdChV+3X9/vX7H+uxlXvFexFcNWSHCi1faf2Iq2/9iKz/FhC0NDQjjtOxQNChjgzjfaaitj a0IiLQYQsKgwuWOUOU9+mmhaGmoiIiIwhE9iIiIiMsk2QtGRUjumIletSuCaDIyL4IGdiqKhFPmE gyB6ZGkVCO1aLcnplbRC8t85XFQqLHa6aZ0SYW4PhpqmdiaNxTxkPgih8Mg0bgvfQQbCtzWzsmEv vkKEsN/PSF52tBDqEhoNM1BCUhJB2kZzZrnfpOkro4/ZV8lj/qYcER7SU1nSa7enV++m53O99XsQ uDDKEv9U/MOd8/wYdTxm6jdnw8b7/X69/W6L0yLjLhTOLhW//S7UWGR/+hoV+N//r7/66r/2F//d 0P7+m79r/dfgh30GDmRCJx5/8/0P/f7CJx+m7/lcVCxTGEm1f0n9vyUDcfH+KX/s3HQbxWmcrOdp eiunDEcV2rJuU6iM6BfQVqvc/t1++NBbhTQF432sy6thoNCxQOItQQ7Cx3rphe7Hwra/jGM5EQYT WGFL36oRcXEWhan+1QsKZGf7CiIiIsIREREREREREZXG4t6kdlCEmxP5bx2mQtmM7VGYztIiDzs6 TO6IraKhEL+V0rTy+f4ZLxiWyF5CZCfZCYWySSZA5sKQKChTXF/ITIiKvLfTyDrhYb/sPTayVCGo Q6hNsh/nqQcVLHDo/nT4PP5DCmoIdQgXOoU6WdGnlvMX7r844enTqEkqfv2/9XKdurMO1Vbquk8L mO4RHv+gw6nitow53zDnfMOd9f9T4eMJGfe+GHvU8Z/z/ne6N3up46MOYde99/EG/vet0u621929 W76t/2GXV6XqOK+7f/mkbEqm/7fEYX6/99/3/vr/4f8Ww1/f/H9fwv/+NztXhBfuv3//4KEkP3+k NVCLhIdpfv99f8w53/xSsODN1CFFLaVt//9qh9rx+CFHUbqxrDN0M3eqQIbFY0L/crlI964TrFfX f3sU1N1utoLP+qub+sZoC8aR1C1hftutCI8EGsNDHsbsbQM+5rjFr86cFtbCr2KhAzqF1vHZQ4Qu IgwmhoWgwscNCIv1ji1P2ZFqcJFoceIiIiIiIiIiIiIiIiIjLdaUtyyI8R0CBKZDMqMrjoiI3nZ8 yrRJojMpM7Ao75HETe1QiIzJHeSiMM7SsJkeWyF5TpSDzuIvkoaagg81xfCDKdl8qMJpnXPR3EXw geTHq/a2r/gh2FyfOnudQqZ1ChbRY7XXbXC64U+f6QIj2vT/S9rV81tLdBB13r1W57cVb80zcR0t U+jPuvR/877kd6efqTs/UCL/Tc72+ntZ3v5v079oR/nZay4St+yJhhRMwXXcMQS+9N7deuvmkXCr baBF1/3/Vf///dX686k+P4+t/XrvQMQhX1a9qCGKN/XaRu+trM5TlDlPuayu3qP3r9U/fvO5h/// fbSp+KUfb6dLEReGR0R7Hfq1W0l39X1HF7U0Bd/Yj2FBmCd17jWDSriPu9WwkdQredAtqsNK9JVb XvSWxCccaHYpin1apiKYqmKhBiKY2Ip3iFORYjZz4aERaYQYQ7P8XaYU5NTq000OGhFoXiZKSERE REREREREQYIYUyFUMt1SLoy1i+aghCZCI7HSZG0dpSMhtEbyYRXWlC2ukUBi0yTi/amvISL5TxfK eL6ncRfIXkvqCDNWp2JR0yTi+SyL5UanTrrc6fsgge4MpwqhbW1shhQup0aeXz+mqnasKiD6bWzU IdAuf6M+0d780Gv3ve/rr676a+i7bapNq6uteW5rHT+/7DMMafmw7tHjz2Dn+qO90d7o73n7O++p 3/0+s3ZsO7QIj2gRdaLyjdv/Xr8aVmcXC1vriH///+9/ciWcEpK3+tuCLr63ruk+EPb7mER5f7+l v/f34t///0La/YX//wxQi3t/X94vfER71/nCNXn/vfWQ8Kr//////xH9f39dVehtfq9d6H9L34hL +u/+r6jP+Og95OGF19/fc9rjYjYirOUML9q0w4qCIwKt9Nqt6R0D3pe0oZ/tqp2oD3Ttqt6xnQLP +GE1GxQ7FDHCrYjiKYjhMRWuvxUyMJjGIpiKVL7QMLDTuGFU5O001Ns6FxafaEZlaaamzMN4jP8R EWhERERERERBghEREYiZCMTuiOxiGW6yjIhGeVJHYmjWIdxWRvJUIW5TnRENGXohqW4V2mpCZrap hTXF8hMINMpzLpSDwp2ORFspMyrR5KmFIxEJksMiCTTJBb9cIWdqwkwT2nDQjOnaJDlbtmqLmpdG fn8IRx2dOyMReQacUn7tfWl+a2w6V4IUaGq9r9MhB+rnUIjQ0aG6NHTtwRH9G9Tdz/O+6SedwbKs +X8+qDtTu63vng2Zrh99JIPQeazQ0g38GKE0i4WhoWP80C9WINik322R0n6SvfvjTdPnkvc7nfWt 0/X1r7XS3j3fvqIpb//vXW6CZcL67fdOttdwQzLgdqf7n06MOU4K/mHJj9SGgvXpdGPrYjQ3/F/r /rV3H6SY/BgtnKhF9aEHurBArycMTbn+NX/ehn+Thh/tb9bqyQ6luVZQ/0LjzNX17aoQtaz6tLdI M3Z/2t/1+3TpXTrBxhCIceYfxsRXsUwmKOvDCxG0rv7FQwvgzBMZODwwlYWGloRGjPn/tDtQmuLU XffaYod3dNjYpjiIiMzlPERwYQ8yIiIiGEDCERYUyIYQYQYLQhxGf004iLWIjJu8dmrMRUZC0IkJ iIidgaEZbhaP5SgX8pxSoRGJM7pmsiQzaUhEV1GYRUIjMwkyDRGZfO8y6JV0+tsKagh0CYTQijWi OR0ZczXkdEeIVBO0wmmThg6aYWwsMg7P52JxL3uaD3hOiMekvNDwh6hCMlIRd1dd1df+nLXCL4q3 83JEY+bukHlWbK1O9JKd9879ng2fgiPaBEfd/8e9P9DO6ehKVm4jlVjVzDnjS3O53zud/+l2NX6T 3Xa3/r//77Q/V676/b9tLczZHC/q/euvn2XCt52IZHCmbLhYIp2XQL/2fXvfIx/X+////9f9fW9P 1rH/0IirW1YYW2+zcM/73Xvjr/+9Rn/9WoIf/4zfVhTdDSN+02kxSH6x+2t1b7S/379e3q9JN0t6 6oscw8ax+DNs4pqYe1H/FMbxTrx0xxHrEVGDLCCKYivaF+39NAwVH8Wp/jtMIXF3cdoXaaaaaH8a HiIiIiIgwTQiIYQYIGEIMIMJwYQYIRERiIiIiIjJu6Mq4y0y31y3r5brMdvWdnyEwgzs/ZWcp0bR UZ2kM1sxmrN1lIjCKlnYnmsyTyEVlZ+Fs7HCaZ2P2dGXcGQUQINPIOCfafDCdnXMM1iHZrGGaxEG UBg1CQyBZrF6BEff58f6cMKl51ERcOn24a6FrqqNFVhlP4X16O53Wr71O+eA5d0CBX1p6uFzuGjv 5hzPRedAiPIm9JuaDXRblDynO9EY+W5Wy4T9ds0i4Wv6XcNwhq/Rhzxq1fdww17quE9U6BB6cUuE Lhh1c/+v7//f9WL+tmYL16v/iHrf7x/x+m1EMi0uokv6m7/98/+v+l+q/b9/1/+v9+/cL7oOPfr9 D95SwxHkXwQVnvfmR73XW86YIL0v2z3r5/6+z2EXkECsvhKz3B/Yiu/21p1iESgMXr9v3VpNrFX8 eThiKWDC2tpQwU6D4iOGFbtbTsdcUdj9LCViK97VsKxUVBMRtBVdUNtJtKOF0hlXRaaFoRDWNQpn KgqLQ9MVFNNQmmFy4LHsLmHsbGiKPhYMxeMRERGmhEQYQi0GEI0GCEWEIiLRmgwmEz/p2mf8t1pG QJiIiIiIiIiIiIjLdSCGQbIgQt9akdz0GpC87Us7FAh2pZlGQiOxRUbcz80Z2jLM7nSCbCJEaQ1R nOVGctOYemd0zUISoyPEJkJkJGpEdEd/0g9Z2OEYc+1oHhO1TCGdNztxFS81CGoQEI7n/cg6rs96 UscmP2VYfOOnaneiMf4VEY9AiPvqvj/3YyKZzWdzvhB22z2LVJevc3e5hzukb9N+jDnejDmHz/16 f51FTBD9tXclVGdqhkhlwv9K9DvW3jrZnFwtb9PjRoKHC1fUwkZyqwdf/6DX67+v0l9///r8hBOI ghTV0nQhEuDGf/7+w59mYbSN3a/Vs+gUuN+8+tquf/37efwQO59ULYXs+oIG///bwwx7v46hgqH+ CKcNO/H/7b4eifh0LBn3QRUYj/HDCiD2ezsLgl7EU0qGwXdBCNiNVtun1MwXQQP9PHd2KGOITW01 zDwZ90scjHtNO8fFYh83RZyFN0RDCDC4IRaEaM1i1ORDCERaFqciOmhGnEZ/sEIiIiIiIjEREqMR EhETYjlusI7PnWKlEs1JfO8zrkVRGZMI7NdMk4kiOyWKvOwIQg0QnLcLYQZ2a90f8IUdOwpeUozU IFL5rFIOITsj5HRHR0jursIM15hmrI6BAlITCDNTsp4vmtGGp0OGdHZUel/+Yfuu5f1C4TIf8REm eeyaXBp2mhEeix3thbCaowT7Z011O73v6Z+/BEff9FjnHwRH7ljnH77ffcw4aNlZx/oINwuCI+9Q RHqhPXvXf38e+0vX0ELSW6CFrvnw8X92mH3C25+9Puk30k9ntbp+9f8P1fr7/xr6HzNkcKl974n6 n18OaRcKtr639sda3+/1Q+v/piN/76/b7/X+sbvev6r/t+vLX9YrKUD/agh/vn1ernsEyOgVqf/2 hhQpDwQWpj91qf/v//SMDq+tBbhXn/t6VuoZY5x8W/Uk9CMfteghUU3SxpY/a2l/H09WoQ+1QM4T 8UdNiKaEOsRobC9tIZudMFHTQU6BfhhJjYjpbPcMFYYSqo+O4a3+WOce1gzqPHWDMDBIW/T52IBd poNLGxTFAztcmIiIYQhghFhCGgwp58RDCEX8Rn2SwYTCENYYQYXERERERFqdCGciIjM5TxEZZBVC IiNCHlusx38a4vkpwQZEZhHVm87tkGyWZvIxnYaEZbqYmnef0079BhBkJBOwgyoyDinwpqZfO0jL 5ERV5C8g47SMvkJEJkRFTjVF8g1V1f0a2F+0Z2i376LdmoQ6bhDXXOjTOvkrFNQi51CmsU6SetnS QcIvOjP/Sed906Qem3hN0HX1W1ur8Kq3QXul7T0JSswa1tt/fvV1aT66Vok69G7O953vSM/tEY9G 7O95+a0jx0d70jP6aH6306/+9WfZcLT7zvb7oV9f6953T0P+87nj+ROMBP6q71/SHrX9f/31//19 f//+vj//2vf/s5DP+6+6v79TH01P11tf1Ss+v2//wvt2/39/1LcER/r+sfvao321fSbVulbUV7p6 +whtq3peseCFerZz/r+PGEP/H19iKfimI2Kj4aXscMLd1CQ41jSaC1bdIcaR1C230F+8K0ubo9Vh qmkNjF2mKaYwZwlimKawZ1LHsdVFBr7YitbQiIiGEDK2BkQeGEIYIMIWuf4aDQtYtT/DCnAkLQ0G ELUTtOhGdERERERERERDCEREMIZNjJpiJE8yGIRhDITJZl8qEakqZ2VoyMsheSFLdVRiRY4IjBAt nTtM+jUZHjuIv2SeXiDiXiF+d1ROGDrFJkJHXI3oMgXZHyPkcigZGRfKjITITKhQQ4Qqm/6aWFuD BDzoE4M78RLIhpnVpyCF7DIxXERphbNQh086arSz+jdRnX/oER94Ij7w1peDCzP9N1YfKcNPZEfN b9btXOoSjOd7DXGlvt3pvS+aA0blzd54c2amz1O+p3c1njiGHvPl0nR3ujd99f3HXfva63+IN4k8 XCUJFMwEEGGkI1fS2luk+ezAQMMvvpX1f9Dv87nj90r+tY/+9LVPVa1f6fXq9Vj/dr176///zqJ7 2sEK9qtrJQgrtTcr5ukPCv//1/fM5UQi4qvj0/V6/9/+O1XRnKHKH3rfxCs5DW2cxrsIKz268aUa 2uNDnZrhJwQ9W/9z2ThgnDH944ZHReViKBmBxHYimNJAkPs0DHxCjtLaV0n2viE8K6hhb1Q+rb7v Ec3WqraY4W+vwlYrfa4oX0EoMygZQGGIpTpAzKMVEMLaEXEQwmE1P6FqZEeFN13FoaaHYW7StM3a ceM/xERoRERGhEMEIiDCERoGFMiDBNO4hhREREREREREZbhedleSsyuBZ2BVT6Ox8uZrETKnHRHo 7NYq4vEHAgZUZBxri/ZCDO7i+QvNYyoyoR2Yi+VLJQzEU5FXEXMx9NPVHtk8Q7V6P6b9nTzp6dw1 XJUItmtAq2u4TKcWrv0gRfReVdgwr/67o2bvdXnHDRra2qNbwQ1d6ua2F/b1XT02xCXu9Gf9Xv6M /EMOm0d7o2Un1QIj/06TovHT3/6HwYROy4X362zOLhVevuuwwy6V/6GrNMxEcp3PGuyJRuX66Grx /35GLXq/////2Lr//Tj/78If918LrtnO0jeLU3QTLpUP15nKf9r19Ai3X/3bugRH/vf//v80HHsU sb6j8R99CkLukCFE4Yus6YSDtr6ue9IZu/9UM/77ps8rri+qoR/OOFP91XW1pp01iFdpX1G2vdt9 qvthW1i21+NTZ2nGfdOxFPsYMwM6sRULY2I1Ya1vFMRXxVhJJioiLQedEax2ELTCrahbCan+xCFo docMJiputRF2hEREREMEIhhBhCIYQgwgYQiGmnGIiIiIiIybxmWsWc15brMdjiEJnaRkdEeCBnd5 EZJxfISIPIXnSOxSL5PECI1sxnc0dxn8g4hOyNZCZT5hFRlQpbhVqahAhFIsesggfNYl+e18oSa2 djyDVTQFzWLB+nZrFX6LuvQb2H2F+tbovJo0WnVN1oLD8Lhe7wnRhzxm6k/NBno73Ru/egRH3/Sb q6nffPBsovJTn877ROP/Gvpur6Dbf+JpmApE8jsjoK/X7vTpdLdoER8auEIMGToEU8oRta7wQ//8 f9Ldf06iI7//+9+nBihV9kW5cKFCHX5TsjhYKRxWz37fdf7+7oznHeh/sR9X/1+F//XroVHbanZj V9719bOY4ujI//e63qUoHfs9hF5an+1P9v7Pbz/yMcJX6O1YWwqur3pRf/P+9IGbra2EmNJO1jOg 3Hx/6jH4NDM+o6YrihYjVrf9iN+wkxVLMewwlwv/iP+8IRDCZRMJ2mFN0Whx2qcMU0LQixU2YWOO 1NkeIiIiGEDCEREQwhFhCLQh6oRDChBxk3MZ2a4iIiIiIjJuXEsg4oyuOi39EJlfuTeNSF8OM0ju vKhHRmIiqI6I6CZKiJNEHE0irMq0g7JPMI7vKjL5UZGIwsjaKtGsyTUmyWIjKWG+eztxCnRHS+hE UdIw01NAXQMJ3Dhp2oXNQQFThplPgmg060pTnLcuNaghHTfaaNbOoSpC6lw+HBhfW1TdAyn3BDRo nXejDndNntGHO8MOEH70bvTzwa9TvS+eDXZ7cJvJayIOcf6BEfeYdTj9ncP9Jv9bcdbhkWn2+hRn KiuNN0ldNow54jTYpb4YMGGk99fR/Se6DD7RvVP3//12x/pd9X9/r1cECXM4uFZFrItO+vv64h/o Vvf+jBXbBE7uqHf3/+vX3/94UL/v437r02/r/r1IYv1ue/e1++m/98GDfam6ETuETv6X/7pEOBIE DBc+ugTL6W29s97dQT2s/0O21tJtJjW1tvtW7UayUDc0H3r3qdQjdKxBIZQIC2sR3jQ3jrY/3imK jpScMPdNhI7NcEmwl8LhbEexFJRFQmSHCCG2lJDhRaxahbCHn+LhoNDSjGxUQTFPwuFhhbUyhIED Qy8MO2KBoYzdEREXFhCwhl0hhMJAmEItbTTQsKg0+0LtcRERERFhCIiIiIiIiIyyl0V1TGW5ZHZE dlea2XwQM7wjVFXF865Go15hWRpHdEd4jCIhGEVaOrMZ28Yjs+dpa5fP9H87V2vaee11PonBcKmQ nDINqmQWCaYTtVtXOubiVea4vlRkJkJrrW/tbRraNb7W9Olc1CQ1smnkX8K6+0/cNPULZqEOl/93 6ed7paT9IER9354NeCI9rMOGgRH3V94Ij+gRH766ekCI9aoER917//f/+/b9fbjTaT2jDniIYde/ 3W3W+ldXVPa16MOd+/7+19frrv/dVfXrw6//pevmgY3/8MSk/63rM4uFJwxYjQ7CT/eY/jX4/3f9 f/6//W1/9///9b4If7pd0r+F/0vsh4SfwUugUEU7Ct6v8yL11+RVEdf/2CBWtT/Z0YM/5/1GlDVW 1m7es3W1bpbb4heqEVEf16X2sNYpQhEi6N1tviKH1/+DOrGhHYSrYivbCURX8KIpqFEcR9sUxTrI QdsRX9f8aEdhbFPtNOxTTUVBBoGcKOrTQ000wqZyE01FAzDUeIjMiGEIgwhFoNCGqYXhhBoRBghE RaFqneTcQhERERERERERERluSJOCBndKGVVEeIPOudleayNWRJEojeVGQtHZhkszmVeQeZVIg0QP OucyrRUlTOzX4ZLQl5/O0gqefSkHJ3qdxF9BlRw7Ompr1ISO55CYUvJnUF0HakHLnx7lOfSqFRre mdQh1CVnSyL1hbCLdmoSu1CF+ahF+qzoFOnnQLX8MNG7vonGv0kqer3V6DrTeqVYSV+aCx7T+/Sf w2X6E0jAS3hCobt0ZzvncqNf/O/rRhzvV7pG/87negRfvGEDaVzd7n7e/j7Vvqt/9e+96/1ut6wx BUJoy4QpUXC+3Xul/X+/rUEXG6mgp6Hfx+32/63/v/+Gr1//XXvcW+hb3ghnQV7OY0OrnttVf/7o Ey6CQI48jojl/0Y/ttbc+mpu8//96+rX1W2FqE8d3N+O0ps/v7axHERV62v32kTgvBhR8f/ut7V0 gpoGFxQM4QL2v1ta+17WKhNMRUfb0x6HV/3sWqt8MKdArR1C2uFz/FoebIYqn2KFjDQM4WfZ1G1G wpyFMOxp/Y2K4piFQM4QKDBCIiIi0LCERaYQYLppRaDQjRmnHFphOGg0zg87XJiIiIiIs6IiIiIi IiIjLIdCJ2CZbpFJuYwQM1GYiF52JoqSO4Mp0di0UiNSOIk0Sx2d0RSRMI1I5nZIE2m/2mQrTTIH hBphB2oQdqEGoQdkLyoyD0ui7cJ87V2+jQ6PxIrRY7OoWrNQRFu4PP6ZqCV5rENQqM11dU639+k3 dboINpNOtPD9GxrT4SC1JvUD03uRRkfyDdOvu/9PN1K0b0k7KsO+nm7V8kPRJ1Z7r/oR/kSBciUX C13v+7f0NNiHf+h8iUYCIzp53tskPozncocp+rr+vf9qv499/w//e1pNv+PiI911OjhMjoEUOp0a n/eY0PC/9PakPBUP27WpnKjb/6LHBXttYYVcUIj3H3S8EKbSNSI6V1s3PUQW2kmc3SGh//uEP2KY p7khwrX41m7VhUI4axdrCn/YUnBeGF9/77PqNNBhDQNCOOh1gzbgaCYhKxUF5oGNiF3xTsVHERF2 vF3tnJqb7WPcyIaGhcX4iM5CEZkRERFoZyIiIiMzndyyqmZCeIiIiNC1LdUi8d/Gtl87pGpl8hI0 BchWS6IiL5UZCdknmEU5FXnZMiTRUI1kQSLo7PkLRVo1mSaJSzeIwuTT19bNQqRLdTo0GtnQKahI YTTTVNU01s7NVkpSahNP6vugRH7pAiP4VngmPJSEdNdILBq6NbeaHmoRGthe9X5oDOm/eeP9b9bo w+oIP1O7QIj7zdmzO7nfdPpN608777/Se+E/T+/ytsuEX6niK2jDnikr1/pCIMNfWzRLT87lRW// 7unpvv/0l+r//T1+/+Le9b04TLhfM2XCL/pb7+Zsjhe//tYId6tTd/+7/vS/9yEQX1v/9aTbf/1+ v9et679D/ru7r7saW/2e1CV9asJG77Cn/b/Rib1BCgQpqf90CZHHfY0mTHMOFEfcaV2tpW2utqpD DxxBPq2kO9qPv9rX1WP6oba4w0ItNbG8UxTxTSsRVLCiO1fbCX9rEcRyhzOCI6ZMc7hdtpBkY4KK hhYYQtBhC7Q4tNTAzdhBhMQh2KHFilaFxENCI7GGCENRERESXQYIQYIWhphBoWELUtyshhbiwsMF JuYhEREREWEIiIiIyblwhCsmxOEyEct1mO56RFAwQmdcjWa2XzsTzozESzMI6s3lGTAQ7+OmRtFR kJkHEHHcIxpkLytIhIhFLcL87HERiudLU/652kE8oyeTTu8kJIpQL6lOKdQhoGCcMIO4akDiMQUn DCluUfddng1+3W1tab3Cu15eTRtwlP+FCSqEnYdH4h+dQv/0Yc7pz3VP9vU73Rs0/zj9JvreZy7u uiQ+WOUPZ4Ndng10CI9lOd+9TwXHv3W3FildO+aRcIv0K+qvdf1ZyGrt9GBoQ40403T2DDeu0b4w n69f1v96rX/x1vv+x075oGNptW1fXkUVf9D2ZxcKS+W8BioX+cKqCKHYVDqaCn/7/63xGl8a49f+ 6cML1av6D4If2t8RSjQ962e9Zz790nRtz6s6Ln12uu6QROEhgih5dArn1/P+DmP023TntsJVN+9j SOy4Yhpe/VqDN17WdzvXizqEenq6UhivMOYfERwYJuo+29y3C/jjYoGYJ6tjVj+I2Kq7PbaqLvah KGFhhWI4XQtyQ4SFWl5Vu64tJsKhoWmFMeGFtNNdRsQqxqZzD5Y5xwmKYpqFfQNDsUOLXEZuiIiS 6aDiIhhCIq0NC0LTCEQ00GE1Qvz/acRiJ2poREZviIiIiIiIiIjJvaUiSOzoRLcp5XF2d653CI6C kJkrZHiEjXF+yMZHRHRHSZE8q0mQaKhELjozGZIyrMg0QhkujCO0gQp0VDgiF3kEI7CuaggW4aER FZhH8IUdNNMiYYWyUZuO7i/ZhGEmEy+Ewnapl8IMqMlcXjWy+QmQmW+nCYX4Ij+vwcw/X/dWuGmF uIg0aGvNDXmCbRbzr6brnTU6fealEh0jdpLbRuSO954Dpnyvzwa++zwa9PSBEeV5CD6bQIj9pNoE R/pAiPvCb7XQIj973fSud7dCaMuEr8fxBsdt/Gm/UadbqnnjzZbV63p0u7PVXq3877rfuutP7/// +k/6v5my4VK6df0+t619et2K66fdLdf/ctzUMb/2z6aRu+rr5Dwt8R/7+97//t//////r//1/bX9 NR7vqzm/2EFq+oIbU/7V0tfa/7zG/v3qjA/6QIoevq/qus3lPskOu8pQY9jVDvWITdAzdbpIV3q1 iltV0t0v1tX6r1bWIpvr0gQwQpx7ELY9rYq2IqEx1thWTcocJ1hhWKdWIqGrxrGk2lEdntiO+o1j VqruGENToi0wp5w1CafYoHERdimmtpihQ2Kimo2ExQM6mKYoGcIduhVERERERphCLC6aDBCLTWGg 0wtpraa8RiIiIiIzkIRGf4iIiIxEeW4WZeO5xCZC8p4vkJEHEIiVkVeQtHaVnarEwjUiNR2TEITO xRFQioUrgvTZNPOnko9c1iaaZTtUzueRDKdqTTQaqU4LkRKdNSDjWy+a4vqmpL5bzL173d2FsLWi 3aFkWs7HEOoQIef0YdnWtT+kdZNGL86brp2dQhqCHQIdGEGCB+n73p5383d4QdEY/dUWOd6+gg37 qzwW/QIj9Nr66uqr6yuJMjojpf//96E0zaLpShG0q2jevRhzvruee9X3vqEHqrs969oz7R4XN1G9 Tdqd2jUdCI/6a/X9MIRhNDp8X6d63UX/93FW0t2NiC3rf7ocaGlen/+muFf/9L3/W9LeGvtcMEUP r18MLX/T/+v7OjaghghQIV6VnsZujP7tLPoEPt7+zyQ/MaaoR2t1oyvpf7029+t+9hrVVGpOC/d7 axaVvsaUME90sEKV9jSopwXJww3pXWmcrOVm6Om1+xQMwMwUdWK6/bVWTHBetLGjdj6m7aWtnvaj V01NAXQ42lYq7sKn2pyI0PFTOd4OLxQa1d4wZgl2KYXHORBnVimIr9pWFERERF3EQwmhaoXEWf46 tDTQjiO0wmdFn7P8Wi3oi6iIiIiIjORERn+IiIiIiIjLIfJaiF4judnR0UrlOd64IMq6GQfZ2nRC Z0yqolsZKqOqK2sTtwl17NYREWufUNM1C4TI9Bkxnc8hMg9NMjWU6ThkJJWRrISNUXyrX0fGrIUO nBneCBVP68hK52OIahDUKagjIIIZDCwejAwZGfrZrRHIt7j19XRuyrvzO1V1V2VbCpBIKt1g31Du 9NwhhNvnbo4iOgRQ+vEUvEMOccz557cg6d9jzDndIk+Yc75xzD0b82Hd83QYfZ/ngOukZ+qNAdXC YQiPvCBXtq14vqluCBJbc77rtafGtzmYCPYYZf2MQb3NMwO67mHPGm+r90Y3eKOqWlb4/1r/3967 1vTUXQ+v049ev2/jP9/s5gwaphBW32ewv+w3///93e2pu4RN+jDmTnjroznHW/97/+wlnAXubnEJ /hgsscocoeGr6Bh///229nLSoawpNBQ/jEECFDiG+q3dtj/oRqdAtcLtY6EcWNSUQXvu/v9Y7V7s hhYXufUKtWLW74bfH2dFEVP4LYrd2KiFsbsexvFKxQtdQXoXCBmCLininaiMyItMwLGp/jTUENDQ 0Ls/2ham3Nb8KhaDQu08REREREYIRERERERGblTiIiMSuBIcRlcFzumduyPlXkLRCZC0RhlTRLDO 1lpkmzsVyVhDsTX1sjEoTOiyUqwmSx2mVea4vkvkYyPIM653VHc/QZ3PNTyD0iEyEyoSnVmP6uCF EpCJ2nouGui3ZrEC2dIINXRY7U/nZqEuDTOzVp9nWQaLA50CmvCZ1EW/zv19+6bXhNhJXXXQT+rw 0a+nTqtehSwnlcUWTRF0q9oznejOVF/ennfavO53zv2p3c77ptvm6s8A6bhTu66nd59c2VRu9wQy lAvX/0ul1rpb1ft/pL+6u/QlKzAQQdX1f6V2SHZpmAlOjOd9D//r2/btf//pf/6dL64fp3f9f9ca qLf30+ZGcjfv/4IYIf3r7//f39qh288HHkXwlr6/6yMjMOYf+/a/vb1/ttaptX6tf/WNJ9J67Nwq LxCeo6tY6RwiF1f4Zuev+xFcbxgzAhNzjhNpRq2l3xpOt62qN8rYL6wrVpW0mls+vOgf80DENbWO 0LQtYaEWKYqN2NjYSsRTFP7XBMVSsU6sGCfwuNNioiIYQYQYTTsJhBoWmELTTQ8yItU0LTQtIY8x hTITURERERERERERaERGYcw6ERERlk1Q0IeVykzvjO4ZjJnl0bSZCZC0dc7MmRiOZGMpEZHRG87z xO0tU01tCIo6hTpGGaxMqSN5CSDQdoNMg8g475WU+elKjITCDKvOxPKhQyB5UI65GktGho0NhOqW qqegmEGdWmjO91NYSyH5NGg5BOEZTimoRB3lOiOcMjNTXkdBNT+Q9MnDFJtJv2eD5mvoEX0SH+/S pPVo1tLV9O3CSo1/BDh7hCK13XvTpWO3h6rRvTvU7up4dN09No3a+EjPmw7uVZsokPRIdU36kYff /bPBr6/3Sdpv/FvS3S/11fEoB3vrrcaud7zvdXNM2EOxmbMLO54gwzC9Hc8W38ab+YXmFaXj/uiM fpd/u/Xr1/t6Trt+36aSaH/H/7r6Tlui33em/ar/n0h37r6l/73mcoct6//3f+v+6MOeG8jH+2CJ j/9tD6vg7hJWwl2FbSOoWKWLmg49jSikrrtXSs50I2CHH6+r+/uo44o3/zogggcEK/UEPWHj4jYq NJ1XF9dWGF2wlak4L/TS2k02l//aXv22qFdW3zdSbSehq0GpgPM530rCwwtCNimK6yH6sYsVx8bF NfvFQWDOEx7kPii3GLIx8zlfFhNC0LQtC0LSsJqdCFrGmqFoWmhaHF68Wmvcc5CoWhERERZ0RERE REl0IiIiIiGEIiDCiIiIiIyuLo7T53PISIWioRUIp2S7Kqi3KkSoQ7/pndAh24prETTTQaaZEZGR fKlkHE5Ea1IPCkoyDOzs1yN5CkSaJREa+elChSUiGoIdNwi4aM4ZKAp1aDTtTqE7O1MQ6iTDmHCU /vyCF5KYIMiEFkEIkJFuHetF3muqS9aCfpUndZznCQq0I608PVTqEYeahP8/6FIUZyozud79Nq3N 2p4aBF16N36m7NnPr6tmg0ep3ay3LfNle3/vS2v9q///SeROLmC49k4PQpDBhNvV0g3ZojEtK87n fCD3Tow54ku62CKHjb/v7fX7i2v/8fFL1G9fW5sF+v39x6/K5SGKEfZ5WeW3v4IGFdXSMe6X18jH vzDkxyn7cjHSG/6//633935h52OEji7/9D6tcLGu6ijfs5TndCN2e89zhT195kY1+3r/dpnO9H9V 3te1ZQ5Y4UNY8iYXVi6fNAX/44+btpNr+9W3/mgW29r/zOfcG6jdGKdihaFikOmqjrXf9OGXOtio oWuk+Kgwo08Y3xehp2hDQtYa5xpBhDs6MkNKfs3UN3accaHYqaAVNNNREREREZyIiI0OIiIyKPER BghEMIGCERYQjETLkIs/xERlcqR3rndEVCOwNECVmRZiJLEVxZVO3DCppl8jEmdmIvnQy8QfZA8q SsqyKtEUggZV53TNZERmEVNJmrIGjWRV9VOxxMLYIYX2zownDIyyWDOjI5wYTC5fP6dnbiBMJ2po C9hUynF80GiugRH3XuFxaD7Be7midQlLo1vCU0Nf8iAiLdheNB5xzx6b0b0jvennc8WdwfyQ+EjP O7aQb9+npG6kHnf7PBr6wg6LvdK0vNGXCa3iv9/iDe6M6frDDMKtGcqP65qRdXQ1pdkoWNPzud63 Ca//ffVf//vXV/3F/r3/Zm0I//ciYYVv96fGt9vhpG7+7/1+dEEm11b+l+ttiPox6V/6r/93/0nv He/hm71tY+wQRDB7fjyaIETxfbe7rjN7c9trfzI6/vrZ722ve6sWsd9NpUFiFv9LFdq/hm7deqHd Ppe3Xdq2lHdihih2KViKYprQQMwXjdYK2K43eI2vNAxEU9sML7pMNfTTQsJn+7QtMLFoaraFodRe bHbjUVtRxUznHxEREREaERhNCGEMyItDMiRCEMIRDCDChCMRERcWhEREZNkrOw0YRU8m54i8Ilkj lcF1CdlRnTyCZBIvnVmIhMhMp8vnYmju8vmoJZ3Wjs6ITOsbyoynzCIhGERCIJlWafz0uagmpFwo X/wudq9MLaUGdco00yGFTs1iBUwnYTL6n0g4f6Rx9pJqzDtbpv1vdN5wt/+1hU3C63qjRh9/d53O 91qeM7+n9AgV15x15JHq9T4qdFjlRRn8ER+0CI+/aTZXUnK4kGG9L19tAl/3XM45BSdGwlL9pN22 eww718NpXQtV3W9e9U4YdUP/2wxC/X37BDQ/3/qOReGRMFytsjhf3of0v/u/ZFaSXNZQ5Q5T1v38 oVv7/9cz/+v0gvXjd7ev+vwaXa8RHmgER99L8ISKUCv0rUZ/jP/8EP+dUJ5nRnRGf+6573pvV/Q+ gRO/8eI+/wt+2l/3qldLkKH/32dAlpE4Lt0v16zDlDgiP2oIJ77W1sc5ENbEVFf7EUDNugirOUL/ /CTFLEVEbEViNtqguLiIYQ0IiLQaHHadqOFvQ40zQCaZrMOUPdqq2KhcREREREGFtYiIwhGEItBg gYIGEIsJrjP8RERERERk3tEJErZLUeyoR0jsSytI7OhEh0rgud0zsfI6BScF0GVGg9OGSXNY7I1k NWQeRXUp8vndPKTLoyKTKREIjVlayDynZb0+duIEI0gi4Z177OoRhkECJwyXCGgLnRaGE7JpqQdB hbJTF2VEdmsXaZGCnVWp9HWLspxDQMBBlR59ddnguMJtenWU4aouMNaTvS7zqEYa2hZqCKmjQwmn dKqaqi3eqfRhzDyXc3RhNr71aN6EMObFCbngHN2ez58hFPBroECvqpTmgRH3Z3O7Sqd2k3Ltffzv RMfNBrwg+/K4kGKp9r33f/EMMukh3EN04pN7hMabpPtZ3O8N1/vOOeNL06CenfhdoEDik633/+xb X//4398f/V/sGJSfuyKf6Xq3+/0P36vjV7mcXCv0WOSf91vuoIoevTgib/yHhf6//r/X//2+v7+P rff/itC/uGiVRHK1tJCKtYZuOgw9nLXCChnPwQrddrKUD/YInf9tLf/W1MbnsENb+z3q6tT/C/tt RCFNpEVUdMMJRpZAwXuohHQMWuN96p/kgb3rGl+x03SyQ+phyhyh7GlYLdWkPzOd3e3ioKKQs6bF LBXscErFAzKQpiKmg+eKhbEVS9rSoRoWyY5xiEXpY2GFJwx7jxaF2UkUmOTH4am+1zotVMe1000I d3hbQ4sUGvljw0PhrVisf4iIwQhoRERERBgqEQwhBhAwhEQwmsGEIYQjOfCM04iIsqaDCmw7txGI iIiIiIjhoRERGhDQyuVo7KM7tE2EkW+sIiMIGdhAwS1pl87PkJmuL5UZCs65J5fKhJkJkNGeZDMh aNQQ7oiFqmkSmTC53AhrFC5rEJR+fwnZ00yURdlAYNYlqdqSP511TSOxwpKnZCRCog41MjxCorkl Rrczlv9AiP2kFWwq3qk+6p6+na+jbml8lImrk+dMo8rhQmnGg3U7ut0Yc49EY+d71vugRH/2p3c8 GyjZsL9hX5hzj1t1dHfwYXcJVunpf9Led0/87nd/fV337jVpNX076tnKhDoz9UYcz1Xtgy4/nHM/ 667/+3+vrvW6W/6S6+IMStkjwxKFi3Ubt1uZsuF2sni4WlwYgvV/790v7/9//t6F/9de717X0P/p Ura++DBe+361Y69f/31/IoGPqgQ71dbPI0Bc7BAcoBw0jc591/Vqbve1P36EFLoF/traWrGl398a T/SN1vWmNK6i/TH1OzhG+hq7fFe60I/8UxhhcVsexTFcYMwS8RQZgtbDCrLpZNzjhS+Kf7ZyCUR+ 9q+xGwu1hpoRDQ0LtC09bThrYqZyowg4cRhC4vHJjgmh+KHaBnXWLFRERERERBghEWEItCLQiKwQ gwhENNBhYtSbiEIiM3RERERplaRUZTxLM7K8RlcWjuvNcXyCzZU0mThgJlXIM7OakoyERUZC43nY nlcDyEzpEaynZ0RNtFz2dmvhbJRBNAwhpIM1BJE3bJwXRBCCCBz6ISWzueThgg4yNBTQF5HpCDTK TMMqWVwVEfCfu9X+Gszkx6NdWccGjW9hw1TOonnY4i4Xg1Rbui8ek0yVioRX6ud/U72VYaN9qEH2 0b4g9Ozwa7NBnbIQe+tOs0Gi6LHs8FxnsOaC4wg/9Tjwvbr19LsQbxGm6fEEuxSdJ3ny3bzjmfVo w53ikHUgrhH8YTjjC+93rbRJ0jdv//7//ugS9XTeru6q9/W9Zmy4W8VsETrTav/q6M9tq6H0/tpZ 0wSf/MLd8wv++9D9+v+9L6ev+1MJelfxepSwx6xpRChm61bSuzkDJ7NdJ3/9f/f99BqbrVnu1DB+ 6sRH/9+bm03FUsKO6tc2C50Xa09Wlv6M53v7a232o9tGX0MEUPfDDuroMsfHX5XC0vwZggw6oErG hHoQojhgkwwowwo4/axX02l4oRHDCR0gSYYUo0MOemltuiuCBLVU0I0z/DXOjCVjimKd3Yw01Gxt cscoexUQmKQ92lajQUREWhEZ0RGbdDohhAwgwhEWEItMIWoQmiDUmECRDjsaERaZ2nQm8YiHOY04 iIiIiIsELOQhEdjIoDUhXKc7qRB4SISIXyCKz7UjjZwhS4GcIcIVsTOyBCmmPZ3OBTp2C5KhJ+Dy FWVYhqEIOIVnZMyPEHGgLmgLmsUhMpQLkHkJEqZHjumakbioyuF6fCGuCJPcJb5KQmf1U6hCUiJf VBVSOmurncChMJ4Q+ruFHRG/BAtL0XdFjlPSWCI+/NBozQfKuzwa++uFf11O54+ETidIuFmdYgia cqDDlPnc774TSCFqdzvRhzvSvxSbFbn9Y0/dIz7Rhzvqd3z+t//Wq1bdBCI/tvxxWut/szBenp1E nBdb3M2XCV9bpbmcYCKP+14e7P2/YPXeP+2//6X/6fS19/vX1f9uCHBEcjCHd/KXninIv62e3P// 3tc6G/7Z5TkbzQYLU3fX+6+f+fXt+qbTVf9v/5+xxv/ffX2trYIEmu6xjXfXuxpD8NPvFHTwYpr4 4/49/7XemIr20m0ojdYaTC7YjttaX4+L4g4tC1IVJdp+Zyh67FPG78bGix77FAzqO08U1+sRFsRm 2nQjCENMqaFoQ0GEIhhMJhGaFoNYiwhaERpn9WhEREREREREREREZNq0J26OZVEWhKzs6lcSjsvn RpndxfCDsniozyClSRC0VGQ8pMwiWGRDIIzIIiWOys6ZVcqvowjNHbibYXd8vn8IRhUzUJIJq0yE wmEGaou0Gd2yPHSIHGuCZrZHwgyojt2R4hPITMMoDEMqIvggZURoGCuS/TTWvuFdayx0SoJrYV9F w5nemjO1ej/hDCVyx2axFfg07WGF1NYRSuFCf0XmnR4ur+7CZ8aTou7LHBEeRh19NpBvgiPJBtf3 WCI+6CDhJAiP/B6c0FvKc1ufms0FjoJdp4Q96//irzud/CahBp6b+unqnp0Z/es/0vq5xzPS2+eG 1PEYQcMOd7raN1qEG5If7XWv/v6tdsiTLhcVbv7M4uFV/S/67bzSLhMf1ffrzOLhRBhpelYYZH/6 ehFJ53viNt/99iP3/+v1/9e//3tV///b/+tf4//v/btWc7X1tXv+w1P2z3/vTz/ffdLvMfpIbSNz s9/vr//P86YJXX4Iu/9q/f8GbpSwXbSvStIM3XS+hV47V7pR+0rWNLSW68fsLbrav96j8UxrdHQV /V6s5XX/tKKYjDFO8VsbrsNIWIr7CthLTY9iOf/xsRTaXasaXwVK2sLjShgqG2vfaeZENBhMIdoc XmHO9jcdiooNUhte17UVsbFPwT7FQtjJwxxWxxEREREGCDBDCEWEGCEMIGhGZyhynsIRFqVNNBoa DQviLVYYSc84aGoiIiI0InsRERERFoREZkIRBhDJuYR36O1jMnhEtwqERErgqlcFzuma4vnY7TBA yIy+pJmSaITJSENbMiuKrnaVyEkClN/yuLrOzXwt7phO4aZTimsUg5IIMqI7UI2yowgyrzQFyDiD ilAvIYrLHMEMDPWW59TqRFCGXKnTu/erRd1dhoztMKdN0YIW70GprERY7NYn6U3Vc1ia6ntM6BZC tO/7R39PVoz9GcGkG0THKHSLv70G3agiPKgg2lNBovzQW+klwlrvc2eD71/f09dtBunQIXhP+f61 VXRhzvrRhzvaSdXGEHEuLO+0Ycw/ne3fVz9mgqN/dev/3Fv6HHuPc0i4Wtut1dLsaczZcKaRcKty y632nNGXCL7ur70Ib66v//6/3/XqvX+++/fqtP/0retff4+8riYOCFf2tr9HaiBBe57s9ghSMEq1 N30vvX/pqf7U37zTDJV/72pu36H93/vVsJNpXqxCtYs0DCu3Qvx/91/eKqOrrgwbelb41vqrrtLB m3MwQRTFRsRSCYaSWyhyxwWeifCH7S23gjjj72wv/DStY1fX40pu2kdAopemmmmoUVMOceixynKe LQxoXW6vFBD2Nih2nYqNiuN7Yp3YpIFtOIiLQNNCHYQieWstzjnHiIiLVi0whGg1IgRC0LQaGmmd dbURERERGbsIRDjOiIiGFM2iCya4iIiIidho7OpXK0YR2Jx3EXyKiApC0dpaMi3UkqThOztX62hR KeyURh2QcdEeiEyEyUo3FO1Ox83EYi8QmQvIPITO6R27L9kHHoEDhkDzqOvuF5n/afS5qENQiaaG EM6hFzp2dO9eD6TtVoER+1yUo9zveFNj7pGf+6hLTXT9dfW4PCaNkpz0a3rd9NP8afyIdV/2jDnd ST6nijdmzNyf33qd7zw76tv26/2nr6+/9lbZHCmbI4X620Z+v0NPQmkXCEUi4X/K3GAq+INhtHT3 BgyPm4wEp//TW//r/Vf9f+3/j63779rX4YpeO0/v4Ie16uoIU+vU/w1P8EP7f3XbPq2z6efvP9VC l0tTcvyHgqvgib2phyrXmF9JIRvq+hilHxvX/+KStVtRVx8EKCEUNbesQiQGLUh4QTjQ22kniMGb ZxGxQM6lXWrZIcpwW3Xa6aGTQKThjX2q7jSgr0ohPfDXhp2msd3GgaEXj4w18JWt8MwM26dioU6L HC2tCKhhCIiIiOLQhoRn/OMORFoaacWmqEWFWLVxEREREREREWhERnRllrybmSO0tCVvEZXCkd3m EU8XzsfKpF8qXZ3XkKRU0QtWQPTOxdEKYWmE7W8/hc6sjmdfQZAsiYLnVHqzUZHjWKSsUhMg87Jo xGrPRri/ZBuyErJJHWCI05y4zUyPEJmtkfK4WjH1111vv2H0FyHa6hTUJhNNNVuD3NQSGS1p56Cp zOCVzp6VhUH532gRH3fne8JGf2az57NF37nHThEY9Ql1eqvB1awbr81t0hXu1fXrvV7f/1+DDxSb /1b5/z/mHOP9GfegRH+eHTz/nh1O7fSbpz6Rn3ugRHup4ZaQKpXG2XCV/VkXFvX/veRLM+n+npW8 cUtzSLhaqzU68QbXURBhpb29Pxdb/T3/+//oIGh//Wqrr/ruv+3f71/vv67a/f/Xr/jan7eu+ES4 PfWPBCjogRPEM/3wTI6BQTI4/qz3Z5P9Td9b/OmCX53PBLrCHa80AvXXev4rv1aqgQdG7f0vEK/t UIqO/YYW0/xrjohhd+IVrDN0QmNL6qhb6BCr+K/sRTEUIu7EU0oMxcL9sJMkOEyIMEaHH39tLLhs YShMMJRwWs3W18+o12KXCxfaHaGqYWPFA0IZlC12N6aXeOCYpYTXTsVcGE2KBmUCmqiDBCIiNNCG toMFP9n+NC4jThhUGEz/oWhpqkNraF4iIiIiIiIi0OIjQlGIi4iDCGTZPnaVk3MIREZ/QyuVI79m NSFZMsjpSEyoRB52YRuOxPKeIOTO5ogWdpSOzNCNNbNAXJUIhGqnTs7dl8J5CZTjITNAXCDCDhkL i/YIMjIvlPF87cUlsXyni+dIgzhkoz8QmQ4rrMX+09LT2ut7ZqFBekWO0WO7C8ggbC62mFwvnt/S IhBaP6/Suez40bFPB++7oER96cKiMfzOXFBB0EG2U4NbYaNjW1ebK633Td51CeFv1ik6Qj2Q0YSk 6r6+tGHO+bu1T03Ti3O957NGnne6O/qyD533O9+q7T753v7fv3NAXQZHC+v/W9CaRcKNNr+DDI8v pP9//q6a7/t6u6PWZyov//+n/r9//2///0N/2/1/+ta9f/wxWt3/90vs5fORGf4If9/7Z7ef/v6h Fx/++v/72r9/jf63Q//a2sVa3+l6622pOkDUftbW6O1Ar+uve+vrrvr6rakSBe2/9exTFJsVX2DN s4imKf0Iv7StKGFhPGlaTTYWNKNJhpDGlGlNzbCVv8/40u01N1ocafa4pIdimKKAXhKxsYsUxsbF MUx1xTOjx+xxEMIRDBCNBhCLTORcNBrhOGEwmgwgwmmmENBhCItDhhRERERERmRGhERERERERllH hEShSuCo7PnbkdkZT5fNQUg0VaIXkLR0iD0y3BOVxdWdwIgzqyOeFtKzUIRMFzUZHyngnI04ZhEY y+dujcd04ZAshM6ZGshM7NYgWVeQkEGVcQmasl2YjXldU6dlLQVFxi9eYarS2EODiRkcJhM7dEcr Upx5/OnZ07z2dGEGdPNQRPNeq/5/+ki8wm53M/QIFf0XGezRSdZ7ba34QynPBfXX7+7VGt4Q+m11 u401v1kURxEfWr3PfCBxSbnjo3oefDxne8Kd3tulfu7vwp37o3Un0nr9/4/9hMIR63GaMjhcafT8 QRae3f+rozlRBhl84GJ3PDf/7fSuvHyfMBJ3O/V+///0/9f6/X9f/0tLoa/3v+2v/9aaa7a/trK4 mGGznrHijf2tGThT/s9v/ufTB///+2EXGZyhyhyo/oaqqhD+rV7zHyxyo/u/oeou0qV9vWh+O1t1 hhQ3f+sdW3kMV6ER/vBDBD48EKs9uuNDv/rrlOZyhwlY2l+IqGctdtJiKQsh4VsJNRpNL6wv+6n/ TCm60tFALwwkv/psNLm7FxGZynsIaHaiheYcw+Ka4hRixvvFQv9j8GYIfc07qDMnxG/sdRW79oRB hCJEKxhCHDTTKmpagIMIRFqE4tDQ740LVTkVFxpw048REZ/iIiIwhEREREREREZkRDQiIyydkJiI lcPERlcSzISRUaqdkGZBWZIEOwKIREJndM7vOytbKEd0iHFzTIxKwbBkvF2QkgypZBxBxCsnDB0z 0QcamR5TWyPGkUmEGCBhAwgyMZHio5IkMUFwGVGQeVyX5fTOxxIvOoSHDVN0aGp0/0lzp4V0WOU4 Svl8/5/TTTTXKdEdBYeup1EXXrMOZ+lO4OdwdIzvSDvv8zlj9V/oRXrX0bKNlGxo1tXBCKmcjCrC fV/ujDnjVZFFU7neINiDdf1/1tUDba7oz7c+p33/f3V06Toz7xDut6N33+/9hC/bd+nMwX7IlFwv Z9lwhE4uFGnbR0/reLS/3fp1dfuvR4KiCCIsFWnNMwfQlcpjATFlypW/pmdfkoQU6IL///Wv+GK/ +ve9b/ffr99W0CQr04r1sdt8eM//uwgrCCjWZHp5+gih5HgrU3ebvlCwq+qMD6sRod5j/7y/623t yY5h9/3zDnfZCD/6XT7qIKIXXtqO8RGNY16hCRTjvrvp90u1tXrvp/DJCYIQbdIUbm57Gh4M/3tX X9jQUE0F+GlrCu/hpcJjVz2xqGbs/4YVbSbShhLb19Tov4YX0P/1FDi48KhcdjFwZwi32OciDMoF IbFO/oRsccRsRXGhXsV/vERDQiGE9CIYIcRF2EIu1tVj4YQYStC1JEqYQvP8eIiIiIMIRmc48REZ yIYQzkRGCERFxk3EZX7FoQ4iIiIy3UsjWQrsqQyIy+VaIWspIp0Rmdl0Ind53RGRVSuCyn1ko7RE LGFs1CEHXDCDTNowspIgcdGma2XyEjsJn4IGSrCBnYrnXsqBkZF8qMg41EV1IpXKRNPXYNGum6Z0 CaDRY7iIeXz/nv3W/pNT+mdkwqn+DVdTqETThL/ciDw2jOtF5rZxwaCDbf371avVhZrbqjW/WccN Gthb1RraNbzDne376VdLcJpHc7/DdPPh4f1/Tzv+9J96bn6+IbpuCI+/NlL3pdvmbI4XwQLvvx9s 0ZHCiDfe2/7eaRcL/5nGAjhAq2/fe3BgyPq9eaZs0khptK/uhVfv1vV/1r6/H3r//ahiu7/HbWP/ 0wh/v39Wp/ghgyZR+tz3+1P8lGCXX7FobzuVH/6m79IepebQoETe//wRH3/y//mc7x9I6rtW7WP8 fiE2r+1ji9r6jWdiAxf3WqZKEEE+l+M/uzyurr9rjfko4pioik+19ArSsLQZ/z/1YqNLtNtUb7YW jsQFm6hCeGt6/Ftra/Y6x+CaamHKi7GOwmNih/92mN9nQop9COvhZwMMRXrFRHFhCIjMqhAwmhEW ENMJoXGhwwgwhaEQwhpOcSVdtDU3Q1xEREXERERERFnQhFqp0QYQtCGFOjE7W8RERERERlcoR2nR 2asxHY+RvIWjvI7nEvKTCKoiu+dkuSFU7oF9T6yErIOCDNUQOBBhA2wQM1Z6IZwzv4lcXyEiEwgz sDZfhkdkciQMqWQkdIl4jeQeVwTPVT0lTb3moTOm6LHdH/RbtFj4af+djhAudfNQRNeI07OgWj/n s6hTqJf+a9f6/oIN/0HoNoGjY01YTpdq6SNbW2RIo19L+0l1tvh979GHPH7p79K0nZ3Dp3Vbn6jv d9G7TzvefOk3zZ1+bKLza2+m/bzQF680ZHC7+3mkXCU9WJ69iVWnUf+6FW19W33IjIYPu27dbwhh AhKad2CKHj/H+3+vfqv/+Gv//36+uvhq03f203i9CNdQs5H9hT/BCukNqbtr5DwS/tX/6vUv/+Pw 0WOWOU8dDih7WiKPOzUK2lN++28f7XHt6bpQgrU0Bd6s5+pOGGzndd/e6w2hF/Vc9gmR/N1KKfre 1+SHBNpT/+GthWITaXDBY76aQ4YXbwk2tpA/ZDDo35uZ0Cxy3Hd5GOEGvHqKHBoY/a2KYqCjmRYp NiMMwTEbEcUxj8J+tBdPEZ1w0OGELiLTCoMIRDCm5MJ5/7CaYQtTDd2pgZu08REREaEWhERGdEQY QMIWhEWmnd4iVrERERM0IiMrhWdiWSzL5UZKzJYipZzO8iMR2RFURkHhSCImw6TLdHK4kC52axdm sQLmsQJpn0dUekHZKMINQgyrzo0yEjscZVoIZL5TjKlncDKjNYyoiDzWRJ5B4IZbuaB0lTVdUa3p r15/TU9p+2dQilPkcoRqYTTJT2nYUpxDUKnkP6SezQaLzu0XlAiPtovO3+8J/RsfaNj61RrYQqcJ ua2ro1+a2FCaNb7tGbnCB4pNpfCevhPTv993+/T9OjcqfzNQkZ6TvpN1Tc2UXmn/ejd6et8f8fuv 9+nvXJwx9Ctow54sfV1fe5pmAiukMIVyfN5dBaezbtPr//9/F/8P+6fX+nr1/369Nf/tNCP46a79 pdnv1c92kYkgQq6Q7UvRfzQVBT/btfbmcpwvrVVfqWOCI++9vl9/WF17VjVjvpDbWphzjtJtd6db XEXtbOfX9CMfdAh6Qwh7Ss5NnPran+CFIzc7+2lSSsR6EdCHDJjlDgoqf8aU3bS9ikNtbbXP7Stq 1DC92Fji4YXHXc+ojxQa5nKi1P+/DQiGvQt9ja2rYp44MF1igzbsfROGFWI9wZggZHSfDQjQuGFQ oyIjiI4iGEOGFP6aFpDFhBp7HTm/NyTHqI5jy0kpREREWhnIiIiIMIMJmcp4hghnRFmPEReZCEUZ yotCMmwcdzYlCERGEIiIiIiLQ4y3WMIMqWE1I3kJmuL5KyJaRV5GIwjrkIzES1GEJdlc6KdkuyXZ 2QnlupSDTJT2i3cg6D/NQidppmsQE08+uyDgnZ3PQZU8lOYZ2YECDCDCDJXkdEdEeNTtI1sj1Vnx 7wm2+1V5oaLhqrqnuahAvaND01SRbtEx2i3aERroyj2p3av6vNZ43o3UZ+k3CbReOd+7wnCU77pJ vpAiPLQbhBug6SBEf3V671f1pd70NLdOr00vd/c7nev3T9U6N+unStn6l3n9Gf6//7pvr93/6Gt3 +vbrcrTLhPImyOFIi/oVden263jrb3/Sr1/r+uphe36of///9cP+//Uf/9cUt4Qq+1wQqGbvq6t1 z0313/3q0jd95/wf7n0+/f+qMD9XVtabCTdNVHaq2q2khX8/XX9+h+1H3ilg1tbV6JXq30912qig Z1Y4xBmB2IqI2PYjV4rjiPttLsqJ1Q7SYYShhQhxrn9iONBraaqf4aVqbnT7Qu01TFPQsLlj2Kim KhMVG1ERERERnRDCFoGCERYQMIRYQiIwjNBhBoMKcmErClutqmhERERERERm6NM7iOw8RJsRmQhG RLCMKQeEGVepCZK4vlRnc8lZFXmsyCGVaO6I1dlZyE0yNo1I7E8oygIU9BdFjvJSENQi2dPOzXtB moRMJmpXan0dIxQyXR6NQhrFgyDFU+iEo0gQZ1oRIfoIPqqvfujXVGdzQ1yaV6enDV1C2FVN9GUF juj/BJrpvn+jdQIuur+nReUg6T3f/oER4pz9Exyh6Jjzu2v7NBo6CD/CJxEnzYnmkYCY0NLe/a3T 1dXvu9VTgw+4IXggcMObrfpP56q79aYX9f7/+nod96/v/kSl8VFkWiHzNlwpBKr2NXb9/JP/ncqN 31WvX3r/vx/rrutsH6w9xr7XBEcZjGf9qOL2R0Xmzdvk4YBDbVz10YrSMQIUUsHX8IncEKs92ewi 7uewhtTfh+jA+h9tfbS+I0NtNWqtInDDfTrXzDmfFKdB/Ix8ZNBXPaHMPH27Xdfni+K9eIoGbczh Y1Qi0IwZhz7cm506G3WFyTlDhR8FhDz1qD2k56hpT/iGxw0Oz/n+1W1Mh/Qhx9hcLBoRlj5hzj4V yY99rFjQ2K+HERERERcGE0M1MzlddoREafghoQ7VMEQ0IiIYVBoe4iMINQhDiIiIiIiIjP8RiZaM 7IyMxEiEIjcmyfJRkbwgyoyEjQyOlCDO/RfKjIREIgprRA0dmsbyMZ3ecynM7JI3mtEaztIEOiPZ a5qpNqfno6aot+agiEYTJSy7BOzUImdFZEwXTTuwgyWMjyDtBlRnc5O1s6o3GqMRTsvpQdkJj/90 E3rLHU1vTVwun1kuJui3YXrRo52OEfU9EOwmE9NbRgnv3b/T6N1pnxpPSM9GH82fuaDX1hXCDzjp 6dJvShP+/6BEe34Tdff77M4wExFJ6bquntJqqcUr0Yc8SDautpN9XT845nrb/1O7qnQIv7n//8Nf /X71+/3E0ZcJ9P16/T/e/ZnFwu90979br9Lxq5nGAnpD665oKe////669/bb//+vS/vqw/9f/r/t YIeThi1Gh7OV1fHV9Wchm6CFde/Tra/V14ef6/eEMnIugW63X/Rgnqf+p+tNr6G2raVK+poC/fa9 +1aT1dK2tqP/t1MPiKY1ilt17UfgzhdwZ1IU/xTFOsRXWDMFhpb2osVDCsRUUw0ve1is9MmOtLVi Kc9sV/Hw0PN1podqaysj0xXxTTFOGmKH2MPuHFrDXoW18REREQYIMEIMIREXDQiGgYQYQYQhhOLC BghpoREQwsMELxERERERERERn+IybGkdgUWhV8ZNk+EyTyF9kDiDzplazqj+dGYiER3yIzI2juaJ TkbzIgIQaIwzshWVpSbIEQIjs1icH9nvX86qyURhgpes8kzsd3JDkwz/NbI8QmQmka3aZV5Bx1iO kzpwwtUE67KHf1fa7ad4Ver14h6q+ahEZR0Z2axMIR5/hksC0Rj6dEn4gw/v8LC/4IjyBEff6QIj /IR3ar6ugRH9INhLrzWfndP3O9yJxcKwy+czBZnGDCvXfvvVPV991tzZe1Rn3ow53Wf67p5xzD+b t4Yc/f//rxpxVod5E2RwoMSq/X/1t5oC5qa/XgxKTrczi4VLbjS3XVw2ZsuFdt8Miid/t9GP7ef4 RN+jDuph8XXv//3x0Qw/+3f/7/X/v+o8PUb/t/+PnQUOOeho/pDP8nDGoIVr7WFnRCIo4fr+cCkf 9Jqf/6MD6vr7U3LQwi7+21hhe2/4X/z//tLilb1ZhyoraLO36tdC2/Ff/b6tX8as16qQxX7xSEbx VcEtf/6MixQMwXWIqhf4QdiNtIZY5rxG/tq56iNsJd/ghTP+FkTCxaxaHpxcd3HaFqmt/HEaimhB 2h3jjaitjfS+FwozoiIiIiIiIiIYIREMINCIYIRaUMIMIWEIs42oXO1xybDEIkQhERGboiIiIjJs gQ7HCHYUiNoy1hE7p1yFR0lCBnbs3koMx5GkS3KrnYkipIlOdpUbzWEIXncM15I6NuZgo/895fP6 d2Qd3B2S7Cl4lQpKEfyVCWdUepEHPsbPq7SJYiOlJRm5Bx6pf/0a7WdQjT3nSdcLdqSj14hnZf95 1IR2Ewix/LdTR7s92e3v19JtJ0qspz7dAiPvLiuve7Iju7hWqrBEfoG2Zy40Gmxse7f/XVzuVFXD D76b0EH3n//o2X/dz/P9qrroO9f9ff+/W79kWyx8EX/W8XzU8d+6b6deNRS37Vv+jOVvDBVJDiO6 Md/v4Wvv6p1wRC6dev//9desbXQ0S0Mbuu9P7qETu1P/Y9/PYIYIjHDs9ghQIf2CFOs4Wzyut6Mf xGz6s9tTdBn/aXa/2kdBuP296kTDFIs7g10rX7rBFO02NbXvxcYM4RfoRsVxsVC/w7EVbJDn0QeN kxz1EhyhwTYSFgmPP4QjpYa7YXXjv7TtNQsd3aluUOg0IjMPDQg0IxhnJqPeojiszlPmyIiM5ERY QtYiIYUIT6ej/4YWQNLOREVDVoQ4hxERERERERERm6IzIjESUQkKyp5N3RXzESHiMt1qIfZLxCnl Rk5F0R0pB53TJYjCIhGEU5FTzWZryNIlhpkaRVop3Z2dWQfLdTCWe4dH/s1ixEUahDtxCDgnYTtP TU+jqrCcHZrFCDKjITg1hgmRqJSj0amR6tWDDvpwsz1U1CLYW0a3o0PTT0XDh6ot2ahDUIw1P8PI T0NXzZugw/rRGPhTZRuou6oER/nfpPpN/3TkY8IjHdBwqndt81nOc2l0l6Qvhhl039zOnGroaDow 541v77fTt/pWGHzzSVzDnejDneGHeDD3+bqM+/fHf9Lq/Q16+v+RJkcL/77si2Z+Ndb1uyIl9kTG Xy6Xt263uhhFvQ+u2/u/t//1/5GOnX1+9//0oapREfQ/+zlkoGH7W33Vs5ue//V9XoZ/2kYkMoB3 UETvz/c92l/9hF3Qwi74IoeCKH/rjn/XP9hhX1ukOO2++vq/3+aH3R0G4/JD3X/6JoK6LHkMV5z0 IjW+q9wX7ELjY9XimI2IycMehFYOyhzOUCMLC/Q4a7a7awro/wvdhEpCsa5ui1WOGhaan/NmtqlH 2nHGKhb+xTxvHBb8LvBnCkxURERERBghEREGEDBFQmdDGfzuxFoMKsRnnDCFhC09CMLgx2dWFERG msWhERERERERcRGW5KiEzubO4jucIiIwQMEGVPCZLYvZG81FZUiIwyp5C8hMlmd3kaR1ypIqM3na XEsZ2LIp2U6poMlYqLHafBkHAoThpoMlPkqENQgUvkJ59Go7kgZY5tGg7OxPJwwa2XwTKjKllPpo NOjXmuEqDavDQqa3OOGjQ0aK2qrmoRU/gwr56ps7UVqtyx2dKyVCHQKix3R/02k2jDnHpOjP54DV JxDDSDpN+i7ou6BEftfQIj9z2H/VPvNBooER90EG/C6CD39663q62xBtGc76sMPvfeE8IPW8453t 9bjoz7fr8aD16T7yQ6Rv039ff2/1X9v2RRNddeOK+ru+l4ItOt7+61bX/+d4bxXb79/9++Q8L/4I mP+//r9O4aV+uqwwvTf/77X+/37XS/6vqIL9ujphBB7p1MYIbZ7s93q7uEP1Bh70h3nZcMav/gmR 4L/n99D9Nrd7asa0/2sQnbW6WkNjfr+Ydv0w7+Ycw71p/1tUIr7tbXsbFNMbFRUFxsVCWKiMGYKr Efa56iM6YViOhdimUOZ1DCTEVaVXdGgL2lP7tNC00GqFpqnaWphzvmHMPadivaiCa6aHFiqYoGZS sex9RERGhERBhTHvQh6EQYQtCIYUtWEIi4aDCDTQtTkQwheItCIiIiMIRERERERk25HdMTucMt1t KUuyZZLIvnRmIq0QvJRlIjCyrMiDJVlIyCMk8p2SaIxmQNFWijp5fPz5ePRF/C9tlOiOgn5/Cdwa DQZUch9WEGdawgzWaYQZUZBx3ONTspxVIpEsy8dEfzr//6rtbYThCK9QvDRoaNE1BIaNDmd6ot+6 LH5031wuXz/ghp3nr/Sr/zvdcL/O+ynNJ0m1ZMcER3TaT2qCbQIj/CDf7oER+0TH0vr68twTMX+R QMf7r9XMOePb+4bp6eYc74IO6vT606Xav96W6BA+/z/3d4VD/Vv9f/rsiTI4V1X2Rab7rdd/WwYn r9b1mkXC+VuLha/H8zZcJj9/4jZ3O5Q5T2I+v7+39D/C///e/7Xfr9/S/7xr31trFG+HURHcigYf XrfDU/99Qid+uvvr1Mb0YzzCZH+v7zHCn+CG1P+9bPbG0jcrPYIp2XQVD6hm5+GbrV9Nhb8fRs/R 0G9ra97/f2uhFtq302lj6iu/UNQ493xEUt+tpawZ1MRsU8fuHYjhbDCTDCVsVDCjEcaosc0FD4aU RxDX2SHC1iNDZv+RMF6m/FxaFxfaaFof2oWxsbWxWhtCIdjaQ3waEXa2trwZgniIiIiGEIiDCHDC DBCGEGEjTKHy3KgoeIhhBhTDlDlQUPEegwmf4iLU5FoaiIiIi0LtCIcRoREOIiIiIiMm4GiWRXFE IiIjLdayEyVxfUIM15G8haIWiMzCKc0zs1ys5lSKzlOzuER8xktZSZ1zedpFLdS7OoidmoIix2p7 NQRMi+mE0wgycFyDiD1PIlYh2tcjBYQcdnXMMIMp8j6p2QuIOTM0QfXTS0qDfa9vui419WvBhUW/ bTuWO0I9yU/sQyj+6NyQIFdG6k31P/q0d903PBrv3o2dlWGiMegm4XoER9BBtYV7vD7v0NX0NO3q JFEXRHyOl9fpxptf0msannpyXe7VXTz/VyDvWazP//r3924QiI963XVzQFzNkcK34nYIGARZZHvW 0t/UfXszi4Wnff7fW+sV+vq//8ev/9a/v/0qSt+stwQMWcrdYZuuls5TIghV9auqMhMKf6uf5kQZ MpZ7637pfs9uuCl9am5v2CKHpaQpi6QptZuZoC/7633vY/MOUOUPj90DW1atWOrWGt00hGP61Ect 1Ltj2Kr3wZggimKYr/oRdfOgWNhpCxVK2lGxi19pPXn+wp/tPU6I9B2mhx/ljlDlD2uCmHsbQfil aBnCLYoQZ2uOIiIiIiIi4YIMIMIREWEItC8sFR/DCBghEGmf4ZQJFpriIiIjCERERERERLWMuW60 js+dgednQvLdSaZCZFAwQmSiCDNeRtAgyVM3lRk+dguQmazJNEojeVGdvm8qMhM1syLGSuHvfeek Hn81IjoFTuzUIpdGeSiLs656NQhqECZTiXZ0rIPIOCdnUlNYoQZUog4heQcg4Mklq6RbqqpGuqoR o1tp0+/T9VRcNLb1zpu1oaot251E9GdyEK1p9hT8++nfVJ0tF4q1qd3ui7ou9NouML1/SeYeETHK Hwg+u6QdlWGvzTNhBXJ8wEb1bt0Yc8a6un9/fuE8IPToIPvf903R/hC/6MOZ/1Y6Ix/0wtaa6+2t f39Deq/vjiviuDEoPv/0K2ROLhdrImy4U0i4VXBEys7p/8w5h19TOU9D1Q/u6Md7bEdL69+/tLre P+vSt+qTr/7UaF7UaF96X3f3rPbt1ghVntz2/Z7dScEmRBCnW2z29GNpG/3tI32pufRib+9rdt/z /tZu22tr2pOGAzdjSUnDEdpR2kg/7SOgdDtcft8fH76Bg7beGIVcU9+xW7xxGxVvtKGTcpwlVhhd jRY5u+yY5ThMVC4j1e11+NSJwSfW0NBoaHaaxaVqbyn7tYaEZblOUOUPmcofFIzlOmmhaaw0I8KW OU9Rfimna44hcVERERERmREREREaEREPQg4MJoQ4iIvjOEBC81lXoQ0NC1Ix3JqitCIiIiIiIi4h xERnQmEMsh2dEJZOxERGW5Jl8JqRqL5CZTxfJajCKjO6ZDZiOrMRTmQRnZCJajCJUEIXncM7F87o oXKXnTRY7y8egtkPwuCaZ1WSiLs1BbbttBkJBBkLjUIQeE7ISUlAUhUEGduj+ajU65iJbpkHVuGF QQb/Xu11dO1TSra0aHzO9TqIvzAqJRaJjtO0NNMIZ0CUCI+8GCW6/O9/Rn3O/9qd3NmnSdJ3SD6J jlD1QIj/1LH7wg/pUmqem8MQq3qv6f3Xv/ferq6davghdGHO6S7qz3R77Svdn51M+f83LpZ2Of3e v/X1vTr7Te/9mYLq5EouFUa263M2XCMbTb9ORF+/VqND/G8xsRv+v/rr+Pr/q+v//64/V8Osf6f/ uu/qCFN630CFOlrdN1dM5HUNT9c//fq1N1GWZFCI4rrDCBWYK/7PJs+t6VpKGbnf1ek+vGp0Ctra uv3Qq8d9N9DXRUgkd02hFEQko+04a2I0I2tiKBmUCNiKBmC0qUUxUGurYV1Xb4j7s9hJhFAYJOo6 hWgpEwXNAXtYtNVXQ1MrVMULxVcw9qNp+OEGZPEGYGq9YzkRERBlCIiIhghBhCLRmhaDCEdlKSRb lDnHbTPuzkWdCiIiIiIjP8RaETmIiIjLIsxkW44jK4Vnc/I2jrlZRUvKsiIzCKjO6IhaO7ZSI1CE JmsyqI7PkIiMiDik5XKFnZr3BkIiOgmp/JQrJUIiKMYVM1CJkpEIOCDKcQKThhMlsEylAuamEwgw gygFyDiD6evDBCK1T1g0XDt110W7CzV0aGEPQ0WO06OvkP/e8zg/+0bJEHCbCMP0XekSHvCDyT6m g10m1nguEqCDaNjnguK/f3xBtGHPFt66EJb09wntG+q2jemz21T1z/em0b9PvUJt3vK6rWn/rvXf CBL6+JSouEcTNlwlPQxilauokrhpvFerHf6dOmvmRkkvePX//tf7vbX33BA13f9f/4IUUsMWCCtv UEKs9kQbrtU57DU/bPbSN11z6mBv+z2RQF3rPr+vBFDwqYVqtIQn1m7xnRd92sYrZE9MFH7SKNAw Trq1gwqJzDtYZHSdre6oRhCnlcXjufBcdYMwVQpimIpX0I/InIaEdnthhWwlHCB7VCNtJsJQ0oVD +had6mzBNPM5T68dDRG5nxsUxSLHiLFbGxsUDMDO1xxFoRFxGWTCDCEQ4iyiELLHM5TtlBrYTCaP 4YTKnYTCDT8RYQiIjCEaEZ/iIiIiIiIyuKItyaJjE7pkSQiInalVO6iO552jJfBAyRF0XQSO4Ik0 azIgyTRCK1KdGEVCJYZ2NMl2SedPOxRcwj+Ezs1YTzrINMIRGmaxAgwg0yHpwZ1DATs69plRHTMM IMIMpxc+iVsvQZEZuKdl41MvqZohM1MvkJFvp9Pmj3aqjXZh6NbuaKLj/ara2EW7000W9Fu1VNe4 aa6+utv/tIN1O+mp3dN0z9p0bKTdNvtlO5oNdAiPv9B/nHoINwnCIx76BEfcpzpAiPIER90CI/eu v/qq6Sylhilfce1tJqnp18MMaevd66hK/q8/7er26p6+t7fne//+/tVfXV6fH1zNlwvsi0V//tmg L9X3V4uvVhkWn17X3zSLhV80i4UtxwxiPr6mwocqNpb/3v7+vQXdf/X/6+416V/f/4a3/r974/Ed jXV1dbOf6iz/BDCLzav5OGOjHOj9eY7pz2k/hF31/p/Q6n/+8/0ZGDN1tWgvelDq0rSi7W9VzoP0 vWrX9j21340ZwRHvUhivFd6+uPvqK/+4pra2tjY4pWKYrwZsChbDCxFBk3KHCjX6CxhYYVXHYioL cKxFRFI3/jS1f1TQtC0NNMJ5stNC9DC2KDQaEYx2tDYqYfvwtrdp99imnriIMIREQwQME0IYQMEP TQYQYVTOdyh4iMzlWceGFCNEIhhPiLCDCGhw0NC8RERERERGhEO0IuIiIiIiIiJaQIpZBvK4HiIi MrhaOzWO9M7RoM7WsjWQiUkzIKjCKhHaUjs1ZvJTlazsTR1RVojedOnR/OzWCZ3AkibVZ7tMg6GE zVF2CaZ0SZBxBYlBBTrF2VFdkJoghXNTL5rZfOqPxTjhl0bSZ9GgLwZEI5FdY5XKRPQtWdw+93ho t2qaunmoUlIQ0iHIapmoJWahGGRUKut3nQLEQetIGgwmVwoSt8w5now5h4t//M4OEHqd87/cKlDB dqd6VOshB3JD0CI/aBEf9+60aC3s8A31ow54v1V1ThAjuib/VoNrdLa9/OOeM7nexCn+vc45n1ow 53zZef9b1uto35sPG9qg2PU7tEn9+/6+0FB9GjLhDRkcKaAuIbr6699W9dsGC+vVr263rdRX/38a 98acIutbzvfSdof/u3Dj1rwv//rvt/mvG9J6Tb1++7f//p9vh666/+3fj+8GT3wajN0Z/zkSHBBX V9fQIf7+Petv3X/9nt9fyciPguf9bQ/DfS/ZaQIr/P9pbdTolDzd7/4hOrHt/X/5KWkx1+2t33VA mCKH/W6xGCKcMjpb+Ye6hg46/Hx+0rxSEI70Xb6+sFBpUFiKZQ5gm17UIdK9rFO+2FEIRxHEUwgh Eek1R/hpHXCtLbdaaHENC8ltZVDji8JjDW47sU7HBBr2KDXFRUkPaDQM6exQ+xSEJ944hhCIwQiI jhghEME0LQsKdYQi0GFORDCDXORaHDUkYQtRERERERERERERERYIRlkqRGZGZWsZXKM7QZ32X0wg aZGkUJSVEVNFQiMRhGrOxKN5KkVnJ8mMyMI1IyUup7CDCdnZqFTYNNDTJTp2E7U+iUZ6IOu1Pole C5ISna2j8Q5NSoR6IPKlkHAgfue6vo15xw+kaP63rudQm6phDy+uer9c9LkOslQn/VtGfzdpsQ3U 8Gyk3voER9+7tKFb6JPW79X19X3V0bHeqeu61cMGXR5EfI+R0ECsavfyMS171XOOZ+9vBO9b/327 36JPVK7f/4t/FoRERq9fmgL/37q7fv0P1e9gxKGf353uZsuF+h+X/rfCLdV95hf/x6//DBFD+LL6 sML01DX//6p62k2366nQYedDfdbBDnI/qCFf6oRtntiNCjsF1I+Ck5oi6jBS4yciOL90jc783W1W 9Ts1D2lV/a3XX3rM5Q4Ij+/3SM8iiTUMscw7RnO+IjCFow9Divx/S9oRTEVBMUgX7FRGDOnqxFUI 3OOaChwu1Y8/oRuL42yQ4Jljng4/P7BNW3+w1tVbU5NNYu0uLteNCLsbT6JD66waGEIu+DODMpYp p2KiM5EREWhBgpkaEMIRcWEIiwRRiIjQiI7QtDQajQi1iIiIiIiIyuUDE7xCJlmWWihNTumQkQcQ iKeL5kjKs7KsyqIlGd3kwioyFZWs1ogaKkjpkTSdF4zIMQ7Nfzp5rwTC52JRB2fScGgzrnpOQ4Zo MEMeSEiEHORPo65h2R4joj5KGFTJdgmQmdCCcMui6IxBcgUVEVwRHqk2vbq4IUtnasIdQmmjQ4aN Ffh4TOm+Xk4h0qdxEQwh6HobESQY5GMM71fCdG7uvfO96S9JsjGk3vyEHfBEe/9kIPvpHfIQd111 YWHoER7/9D5oC787lRX0dzu53O+33DD3/my9U/fVT5b+lua7s/PRufN2bDvm6yoDqnrv3f/S9/nY 5e67b9bItFvmkXCVuv7/7u39PTvvu5pFwrt1vQiDf5my4Tf0+s8FDnj9Jv+ED//Q/MILeYX697/p RJDtb4NfXvHx/H27//XX9m4EKxEOThi338ESsH+/9rZOgi862cDFTe/vXBMjjYrrQ/r+++f//Z7I cCX9TdCl0li0Otaf71QIG//0ayh7daFO3XQut1UUsYMw4Ij7/MPj7qyKIjwSyEQJCuU6C2u3xBRW PoR1wZxnOnxsRTCBrY+PF4jhLEbKHNy9sKLrCxuGFej+0rYUQhFZGBXyGF0hQ4Tha4WY6m7i+7TQ i+7vrCdRxHimFgzqFsUPtLFQuq6Y+CrewZ2nQRERERERDBCGCEZj2uaysuIYQjiIYQiIhhM4WcLO TCn/iItcRacRoWhERERERFoRlupZkkzIiKxCIiTeeMrlXDO9c7NTshMqMg46dkmjCNQQlZlTRUsh ESxkujCJayXZBoqEYRUZ2OjmSsIQvJZbh7951CKf4YTtIJwyDs1CAmE7CDCDCZHgTTNQhC8IOyEl IOKeU1MvAgyryHFdZZHvOOHoJv11tbnCzW6NQms0NbRbuZ2r7qSoR3OloyuCHeiY7NYme1fiGH/8 /XyWGgRH/310XdJtAiPvQdIOjj9AiP6LiEoV7uElV4QbC+vw2YRWMwEpzQFzSMGqjbhh1u2ckr0Y c79BNU9eldWr2ltwg87nerv2e5J8/0Z/TyQ6fRn34tNfVUPb2Rafj8iYYrczZcK4+v06vW9eort/ 7GjPvGu10Z4bvr+F5hzvvZoKHKcoe8w90MK/pPl1/euv/f/r6v//r7/77+3/87zCJ5GhdtaERxo/ 2clCJ39ZwvVzo94zfs9vv7q6/X1Z7ft1BSPBZwn7Pf1/4Q/rxC77CXrxzdIuN767X+3/jtb1urpv 2/j+rpCP/tb+1+9v/C2sMV767wtiOGboj7e/XbSYirC2FiOI/vY2ScKz32sbGtpd1N2I/Cx2ELjz dHhbUajVRQui3sU0xTFNNTuYe7G0DQx7HsUxWx1bUREREREWsMLmPEQ0LCM0wgwgwgwgwgwsWhaG san+wg0NC0GFERn+0HERERERERGf4iIiIjERE0xGVwrOzo7nnZ0VGdMqyJPJoZjNSI32UiMIqIhW TSN5UkdvG8rjXK5R53iC524Q1CZ/QakKntM9moSDCdk4YIOOgUi6P12St2dUfzWyPJ2QcdziEzrm GVLOh51ys1bOzUJpBL0a7kpEp6wthder9tdOwr1+ahE16tT0SoX6XJD5IffTetXfN0ljnfbPBrui 37wtb+d/TvpUgRHunfC953O7KUGEYdPO6d9XJ0byOlnHM9Xfqgw1+qfaB/3ne+691fSMOd9U/X6I x9/3621tu/wmEI1a378WRaLcVszBfb9ciJfrr/M4uFK2y4VLb+yJRcL3bzwnr/zuccocp/f+hv/V t/Hr60+P76Dr2/////9f211uCH94iL2+/+ozfv9Vs9gid76tZyOCH7Db8nDH1dNT/DSN9/1p5/3Q Q+31d1//8/7S9/hpTOVEnDBFx7+9edQiVrfpU37aj46/x4+69vwZtzsfvHx+xv8bFUOsJ4jhhdQk yQ5Q4JiircRyQ5hwo1itf72gvxU3X1444tC0Owh3aa+Y+FtMULyY5Q4QNCLQtA4ixQap2t2Nrra3 4q0IiIiIsIRERrBggwhYIRxDCaDCERERaERoMIaF4iIiIiIiIiIyzKI7W6VyxGEdnzuIj52ZZCIq MhaKhGszWzFZ2phCVM7IjWyIMledlqKhEpRVYmEWsaKE7wtnaoFTOgVM1CIPycFyDjpF2VES8kgy ryJhgINMq7PoqWQca8FNeR0FITUq0YggyIQUg4JG0R1X1f0tUaO3RqEVM6hOcLM79FvRodaZKhMI YQjNQmfwmmmCGdQmEEI0CI/fO/Ru83dGyk3Ceez5Vqd++kH54NeEG0m/wuqhL6tGyq3etyl5dEfV e3c0Rz+6Sap/FK0Yc8V7Rhzv7OVXjTre/bzud08/5/yT76Rn1z/RuW9fCER146DQxciYYx7W96+l etzNlwrHuZsuFNf39Zoy4RvXbNAXxxRn2/1a3jiV1XBv//Vuvb+9f99f36WvkMIr9XmFrYIoe//+ 8P/f9Booff5kW/UZv85GzldWv+96XbjP+cK0Ymp/ggfvmP7an+hH9zo2e7Pp/Q/roxWeTn0wYh96 X3qdqgXU6BdY3V+1tvY+319vxXRObdbXdLH0WP/+wRQ+GF/4++u4a2OI62Iqn0vWGEmKYYSe1aCv av2ckNJ1hA8MJRhYsL20eu6+I4+9G+0rGpwF0LK6w4aHanG8yzmgp7FUxXFC9RVccdOIsVGhj7ux j/sb7SofjDBCIiItCIYQhhCGhENCPO5WRENIw5xynKfM5nKHiIi01P+f40IiKzkZ/UTJQhERGf+J ohaERehENCIiIizoYiIybGQh2KZ2aokYriT5B+IiT4jK4Xnbmp3cXyczEp0MvEJp5FiIgyRkVRGZ hFQinMlTMRrE1u7OxVlOjICUrlQiDRe6eIqmzp2xphPL5/sKqYT8JIGw4ZApAyDrIFEKgg4ZHRHR HRV5BxCZ2atM1svlcEqo0aW5n1r6NbRcNf1ukW725wUOHDIgJdQZECEo9Fu4iJIOQ7NQm2vnujZS bz2jPeps0+82HjT03/oER9+EHhPlUOccGRhpEY+YcMJb0G7C7rTr90mqdjrxpvv6/6f9a/W/bPYb w2GGjDniGGrQYc7nevTzYeMw53vok6rnfb1x///31bFbXfzSLhV80DFOvGGRa2GRaW9kVEQ/tva9 fW/zvvtd77+YSNBW7f/1r/RtPxH7/3vpJKtbav/9P7f//v1Xt+zlaV4vrreTg7q6rq4z//nR1vnV CcSfBBAid78Iu+RGCX5FAxr9/YIoeC/f3qEPG2qufV6V02F7q/ugy+/eq7aWuQobxCNYrv5DG6xC /7q1/0Ir6tX66xHGxFMbFAzKBxGxtfsRT22rFWe0FaCgvta7hd7JDlDhEjQ7SG7Sa72GEo1m7m6q tNMJ6Vrx2q4pqOFwoXsVBbUE7GDQihbG7GGZQ2NimKrtNTozOceIjRAlMiGEIiGCEQwQ7VNVi01j QtcmOUOZ4YQtONBhNC8RFqhDiLTiIz/EREREXEYIRcREREYiIiIiIyuUZ2Rl87pndIhMp8wjWRL5 fJbl0VeQeQmSxGEU5EujCJYZK0dnRCZJsqiMgpFQjv1U/hO87cIdQgTTTC2Fs1iHUQ1CHSMMJ2mE 7IOTUq2XzWyPLhBlOyPGsUhedMjojojshM6RA4p0FKdBTUy+QkdHDK4WyPdVfXSdGtrraquFXRcN c6hEaGp/W1dT0p6Rb1cKSoRCIro/moQEMIa2dAvq99Gf6N9G6gRf6dAiPugRH3Rsou6NngiPI77h OgRH9Um30CI+6BEf/+EG0CI/okPC/4SVV6hOvt67K3mAmKQ133X19NQg9B6p13W0tudzuqe+vrtv d1tLuf87ndTd75xzPn+jdne8/Nbnfd/9P31117X1HHH//evXb9v/S3fv3rfH22mzSLhX1fxoV/en X8f+jOce/++X/r9//r///+wVf9b2GFr//x0+Gvt/+PfXwt9Di8M3QzdvXW//2e2z3Z7171db1f9U N/vwhhDtfWz397U/0N/s+rPp/9frNBT318pYLx3ra96t6UcZOGIpX6uvr+6kY/1fqYfMPem+kGv5 qwo//2ra+qt03/HiKrVWIqI2IpiNU1dYjsFYj21YYWf7EVEees9QwsamgL23RDC+jf7zQF0ONI6B 4YWNbuGh2dFn+1tNTZmcp1MewqaYpp42K+mn2nYpitqOE+/sfscIMUxURERERFGREMEItCLQiIYI MIGELQYQiDCDCEREMIMKciLTKEkLi1MjP8MJnSBMKW6UhcRERERERERERERERERGondxNMm5QpXL MulKWR3hEbyVEa/IV2RrIOJWyRFJG8i2R0eyryDyUo9lQioyaCEQzsPO74WyZmEvJPBToyOaDU/k WYS5GnmgLkHBB5dGau0LsnBch2QnB2dVZOGDrmJNBmvMMhI0Bc6o3FXhAyDiDyus9bTSnOcyOg+o rtFx1TSKIh3B9aLd1d7bV1qdL3XVNNG9oztNTrvSDT0zq0zo0GVwT6BEfeeBC/1hTvhNu6M4hQYL ysaLHKdTwa/CD/wnhPNB76fcK7uaDXpAiPU2kHpAiPdzQaNXo2aTdb9erX6zud+lavfTTELFaFuq fW1/1eErd1ur1tU9U6ul1T+0gm6R49XU8Up3dX/6jjXb/9v6BgidkcKCJp04rZoGN2//xpwYgv/c Vv/+/vx3+zOMBFf7pX3r/m///r0Pc3lP+4+/8Zcf/9P/rT/1v/+v/q/9det//nPnPfuPdV1UWFP8 GD9Z0XSY7XXyfwQ3UEyOO1//ox/QKXQS/65///fhArLpLesR//1S3U3YjHzorOoR/u1DIg/purVC RUK+PqK47Xj0I21jx+0orY1QiOxFf78bqx7/xhKGEvNAwzfY7C2kskOExUjHCYYVwvGrQVptJoL8 MLhdKrU1MluyMwhpprmc930CkxynTFP77TFMUzog4tAwhYprmPjawzKBtb5oC7W1gzNOYYJoPuIh ghGhDQizAwhENC0ixyoKHBEeEQYJhBoRoGFtCIii3iLsIRHxEYVRERERGhEWhEaERERGESMRGciI xERERlcLRbJmpXKEmWyS5HSe9CKq630bv6H9yuKBhz3qH2UObAkOLj+f8RHK4XyuVCFspdXoscp9 YQtdRLZCmXCX12e2pu4xq/+eCnv8REYlsrSybToVxTKFII0x7ud3rz5/wQWMQRNp91mHOOUOcew9 CIuWyF4Mk0x78N9Y7Qwoy2mdhR/IDolx//LXWuP///////////////////////////////////// ///////////////////////////////////yA6Brx/////////////////////////IDpXe8f/// /yA6L+o/////////+WQDRZoGqpyuUBcvHstBXQ4T+y0CgkPNOtamRQWm36R3O8G6vf+7IrcGQIaS W+xH+vtX+wi7z6Owy4wz/7zITG/2IXe6ULdq0LTxwsRiIhhNcRGWQWinpNyXIyLyBwybfna2iuWc rqeZJcg03Rh3DLczEOkXZ2T01LozR3SLcSL6rpB2UOHoXv2nluTSfqeGjPumxBhhF5Z3O7+l3ue3 VL69XDZhUNb/u66TyuLBj/3+PVfv8pQL/+0v0nwRN79fTFkcdf5j2NK/0jqMPZzvwQ450P/+retq guNjCSQMw5Y9eLW+wtiKYqFatZ2r8Xf69C001VTda9+sMqEsRERERERoREREYybg4jaOqLKtRB+G S+qZWcyEZkLEdqjMXZJ5hEJnYEZ2QpXKAsNbo/kp7MtEqZCRKIu94ODCpmp2EzvBS3AglNlO9e1c ENGt6p9sOGm6vNDChOjUiGDbSuvSp+p3wnO7MiHO/gi/pNrN702Gy6bQJv+dzvW+u/Bhhhpdpd06 N9IP9CwxVq+u3Tn2XCaT9yLURKV/dfGv4RcdD1f7V19egq/6r7/tTITGHOAvkVB/+hm7fV4RPJOg i87VbVP5/bWwwSr5/b/tr2x7ak0HoV39/awyOUNbFQlnIXQM8hmNiq6CsVC4LYimIphhJDYhWFCc RF8WsXHYULradiphyx4aiIiImRUhEWtpoGEDBBhNC0MREREREZNxtGpHkWcDqaDTITKeL5UZNgRG EasqmXR3yMIpzJYEMihyuUM9GQqJ9hdQnan0FhhO0Gaou0ggy3Kqnpwm9d16VXW0aGqc8gQt3lpF qoER50b1vU770d/doER/QIj+kHqd/Qf8JvofM4wEXc0zAX7fp+t6ults9Vdfb7/WvT13utP//ril ctyYYGre59fz/b953KH18fWv9frXd2+GtqP+kKiDt6S77+3/U8gR7OdYbGhbDCXxq//P9tVvStWK +17tvTFDsV7EV3EUxGThjC2erCV93n+GE7Q7T000oa4pimmoiIiIiGEIgwgwUyIjhhCMRFp5/jLJ OKhGRSjsXxERk3GsqOGpCZGs7J9wyS5CkS3MIlhnZGSvL5VqTdWIahJCaz+p/Idqe1L5/hkECHSL s6qGdIuwmmdIw0GdmsoWzqEO1cXOEglPD1fq+6+ccNdNPVNXwqNHVXX6MOYfJDxd/9+vxDDmxJTv 3anfO++CI8k3awRf5r0gRHtU87pwQK9v9v/DZhJDXf/aW9U9O+kt0H6f9rbdXV//esX6vXW///hi UV961/7/txoesbEYRMe/X6a///mE1uo2/7b/wYNNQQpXO1CCCDVnK9IEPpK9KPtJMkoY6r1/q/kP Czdm/U3QzfiFxsfTHv9K/23edAsUt4rY4gn3wZ9iat+FatBQZlCWI3WIqY+IqnWLjUELVbjQ8Lm6 PQ4YQapNppqZytjYVRGCEREREREREGEIzHiIMKEIjEaaEZZCxHYpktRCIrqWInYGpXU8r3pkJkHk WRdGEpCIEGCDOxTO6ZLEYUMgaOwJKQmQqO6ZNgVGFK5YIZJVZFwp1C2EIjNaI6CpoM7V9kUyeOiy DgncOzrlzTOgLmoQ6MuycFztxDsfMQTv/10EI0a2jX3XTzqEXh6d+unShU14Red5uz954Nlafb9/ tJHfZTn1O/Z4NdF5qd89nyi7uju0CI/eh+vbJwtDTaMOeK3T99Vzjnj+DDWkvGnhPS2KVwnret9P i2Ohr1+6/SHurtpbyLZY//SvHr3UUvX96/O5Q5hyh7/t+/7drV9+EWPr/9//3//tnMyWQcgiCqoi Lf77rqCHOeCFX/pAgg4z/1+1s9319nu0t9cdEqCHUK/at2tpX0vT+34JPrFLtpE4Yj7WNjS+qgzB QSC9iuKYpigZy3gzA8cRwX7rsUrQVhhLpNiPN15gZhtNC7TWLVC0GFWLj9TYVkXikWOYeGtq0IiI iIYIREQwgYQ0IiDCaERBhMIWhEMpp2JkSYiIiIiIybqAh2JKV1PSITITITOrTISIXkKyCoiIvkLy ERC8hMg8heU+XzseN5GZhFQipZ3Bk2LeVysIiwZ+Z1EOl+dA5KhCUeSiCDC+dNOzoENQpTo3HUQJ 92E0zorOjLs1iBM7RyCNIyWl17pulX1/3pQoQpUm9tXv01mhqw82XPW6MOd+9PN1G73U7tHff/Nm bKovMEXXC53/dTvRd0m3luW708b9b/9aQ7+/uRPNoEUP8ii0mknRhzxhaV6uvf0twmqdYQfvdf7b X4tvX+vphCPsJlwji41+P2/X79aj5W2XC+8XRgdf01/9f/6+v/2/X//S/f/W+uCFd4IVarDOYIVr vqM/ycMCjds5Wc++z31WvVAh/Vnv2kb71yuVhM+qt1ptI6B4+KW+vrzQFzQMW+aBi3W0m79j47Uf /pRZ03igZlYqEoMwWlYj86dfvGrEUxURUocsIguwwlrGOaRXxdpqYLP9oWmh8eY+Y7dqbCrtNNC0 LzwUPYodq1NyEREREREREWoQiGE0IhghDBONCIYQgwo0JNxdCIiIiIjK4tCYzs0RV52oykjKvBMr gS4QZJ5C0U8Xzq0yiI7BFDyEzpkbSYTO3wQog8hMhMhEas7rSllorm0XSM4ZrEJUIt+hEUU+CKHq eyngmwaZqi55/OjLujqs6/ZD00j+mZguQuJeO5xkKo/p0Ig0nSCS8J8IR9ghU47Rrcf6aMXdrf/+ SoQ6hNPMjIJbSbRhzj5Iejvdbns+Un8QwdPO53d9Iz3Prf63vdng11SerSzn7pbozp/6xSudzv6R hzxDDLpb936rtf3Navt9Rp0Yc753O/3nc7/dft9t99urrtt/8buv3/x1+aBjq8pUXCJXW/tlKi4X 1puve//9f+/odNthdS//H/Ta6r8a//a//9990v3/90nX9b8h4RfbrYrWPnTjBCmchghqM/u6939q f4Ib/Goa9/qxpQwt/83X+K218JT/aXPqvVKbqq2va/ivX8rgg2Kdj442KYrY6vjhWhG1/SwwTBmB mT8h9b7FW3XG6smOUOC49BoWhaaDCaGnoWoWo44tIU+Nb4vtRu4uGhF2rKN1oyIiPTQuIiGCEMIQ whcQ1ERZ/iIiIiMshDKRCMm4OCDTJfKiNcXyWZjOuQPKhFPF8heQmQrMkvI1k+VxiOwIzJLPnpFu zUEOjCeFwnqeiH2mFyUBToF1P/l8/namj8dwKE0/060nra/7v3/r/3hUXDnj+m5/1PHne877ev0d 7z9n6Qit/X1dE4wnVs2rdJOo/mmYCL673fmmbJf99wmTo2iOqtydf/oE63WntP3+00/6+6+0NfHH wmhG6hMjhX9/Gn/oVa39PM5Q5Q6f/4/5GPf7/VD+I//9+9Wbo8aEb9b0lJwwKN/17aGbuM/3BDc/ 2sR5udrHQW++m9ZubTrfRKAp0Cj2jQU/wZupRvXrYpWtrYjYiqwZwl2I6hP4v9YZblOlhhZqYtNM /xaFphUNY7U4Q6ymsf3EZFHsU01EREREREREREREWmVNBhCMREZNxiJhHY0jsIjtaRUItxvqmRrT IpqU8XyEyDiDjo0zU7OsVcXyEyHFPFJlPkVzufZVkQTLoyqZ2LrmM9Mg5zc6MZ6IdZKRAvnUIdQi TaV0fwvyD/LozSn1l8/moQ7NVcNM1RdhbO6QQZ2BCdfr1/X9V+v1u7pNPTX1vho1tU1s7HCIt2pk S51y0iteubDu/695so775uzZhPT3zvfZrM7//9G7vO4Onqd6BArpUHCJuUP1/9b7/+S6SFdzONta FIe+3/yQi6Lqqd9qm3/rXEG1ulul5xzPpuELV47vW/7vrQPr8Ie//evghEf9p+r/i+9P0/+9r0Me Ip/BFO1YirWG7f/910h/63xHFRH+dEuv//v9tQ/XEU2CHdnP1Gf8M3Wcvv31nRfsOm7DOZSwwoIK 61S3/3Vz2JaSlwzc7XoM3aDngxfXmgLmgLthWGFn/fXd1QZuzdBn6ThiohNrH2q/3UWP2KEGfdFg zFbYiv9iExXsR/GL3XuoMwMKNoKxFdq2FWLTWLuzotDzozotMIdoaarffmPeEwh2nY4qZzjwoiIi IiIiIiIiIMEIiIi0NUDCEMIWEGFQhqoiIiIiIjJutIlES1HYWiyCHThkD0yKRri+QmpCZLohkRrK fL5CZ1ys5qIiIuinIq0d4jGazJYEOmdp+TdSCMPoxn/Wzp5qCZ0YQfhbOnan8lIiYW0zUkwnoNLP o7gQ7nVlOH6q662vFzoODpvvqqLhraNFXW0aHMDpr5/iDD/9AgV/n5c7nj+jP/fRs0873SDfaBEf eg9bouL1FhkfPBjrNMwFpP3USciO1/8nRhLXf26QpNr9f1622er4Qfuhrd6f1tehH/GE0P/ttf6/ vf+nim1UStsuF59BE3zQUPYjedzv/TV5hyKP/6/+kN3/+tf9Vjf8MjpMlAw9Cf3FRf8EKs5YvHzn jP+6oENbOWt63ghX91OE2ew0jfoRoK/DN3714r6C7+xa1N2O0n6de9JtdG7GOvhb9bWxFAzA21hr /4oGcHfY4jigZ9nEbFQzk7r9n61Q4uNNVN0cWpIatbWjdYQYTW1UfzQU8XiIiIiIiIjiIiIiDQhh CDBAwqERFxllJUIiIz/GWQUR2cIWQRCMm41lRnVG4KRvIPU6ZGsp4vkJkJkKzuiKeLoqEQuIUjtw h0yTzCKlnZ0dzR2ek3B14TTz+ahLmgqsg4hhfNQhKRDoy7JagQJMLaZKQkNJT2E0zoy7OoUKdmqh lKDB1i7/ugRH3VdIW9fVdMEI/danB7V9OnT1VPutVfruf2fDu+d96N1G7U70kd9rNn+p39TvRs+7 PBrtTvvmkXCpbtvO54mmYCxpbnMwiO0vczjCI8FoaGltGc7/czzaBFPSHs5Prt0tu3+QcNOvf19L tf0/29OI1/Qj/p/bX00I6JYyOFjvpV6enKVFwvqt0rlqqqqrz9v0P90aCnzuUI9vOP/5GP2/S/f3 266j3/x/r/6xghQ/Gkv2OL464qe31Gf9nJM5x7/6ijfs5DP+cH+tV6n+CG/3+l3Vn73659XVd3pf GRMMNL/elqRMF/5s38dHUIK9U9MaUGYbsL32Ka4tjGtiK9U3XjYin/7OVNsRTQUJOrJuUOhhhaUt UkWqERoWhaVoXaHZ/zIQuLTi8x48b00Ly90uHEWKDWMRERmsoeIiIiIiIjCEVEQYQiItBhCNoRFl TiIybjea2di+J2L5UIhaJUiKIyIQrVBkHEZF8qM0IuKQmQma4vnSCBhAwgalI0zrkayDzplJl0md 0CGoynjeVCOrMR3ZnYtkKUm6gIjOzo0wuagkUpqNQvIOQwmnl8/+p6Ooh0XIOHhyPdpBp3D9BndI 0BclTshKqTumtrM5Me6H7aNbmujX/pvwqdtryFNDBDRrrbRonbhKXNQlG9U3U8Z3vN1qCD6SO+5r M7oOlaVr9O/NneazPQIj7kQbpN0/CdJtKez3QIj9qWqSLjul/9CPZpmAs7nd+9P/T7/r3pD9PdPa 2ct6v+nnHM8Um63RhzvH66/+rp/uv+//W/+9O+u+nhF7wde5myOF/1avdL63v0Y7r/v3nc7//1// 8wojfQ/Xv+rSvML6/+k3X/9vDMO+2NL1s3OoqL/b6v7a2raVvqtnsnB3r2sGDnCVu0hn/a32+/ev +OGFrVjSjtde6vSte0m6tVBn/DSm5mYL+vaq/aW2v3uk/2r9W31iMMLilYhO+xsRTFCbBeOI/Yr8 GYIKFiKOoSGbojYrwxRMgftWGlEb2ub+LQaZ/tDjTTWGlHaaqY93ago1aG4SexxTVRURnIiIiIiI zIjORERERoGEDBTbnmPERmPFgg0GEIYURIohEXERan+01TiIjJukRCNMpISUIcREc7nUy+gyMi+2 EGVPOmRrIXkJkLRT5fCBktzGQeQvNZplYyEynRhHcBDscIdqKF0Z4Xg01z+dQhKmqkrRHQUJtphP OnZ0i52nDIKIahAnDSCRrZfJSj/I2tRbSbW0GjY39QhuCEa6Nb9fXRobD1Xn3Myjadwed703O/Z4 D375sS5CLRn6To773qd3pNnYGwi8ovGgRH33QIj7+yrDr6uu4hurImGH0hnc8TSMZHwoTRhzxrur 9/9ydHPrDDhPCqvs92cq+sa/v1/63/+hH1/v6++vhMIVvIglHH+ONf3BFtan+pfvzogl1NBxyoob /8jH/36+/+/9+YSLHV3/1/r31ut9KIV9CL8M3fYz/f3vq69TQMRWKN+0rOxCBBB3Pbnrfn3MwT4Q oGTa2RpMfGqCbX0b8d3Wo22rera31WEtXVYhaHFWq7+qvYpDYqCYr31pj942IqKYigZlC60I0F2r EVZyz1EVIxyhhh8NJhpqhx5uji400GmnHH2FzYpnKdtRoYaBhDEFFnIQ0IiIiIiDCGhGdGnaFoRB hLhhPLaxAiIi4iIiLP+ecRYUm6hFIzXnM7WYrqWJEkIiIwoTQdlSyDwgyVZGsg8p4vnSI1kL8q4v msiTzUSnZjMIy1M7hES+ekW7a8h1pqfWdOwvns1CEpCIGugzUETKAwdmsXMJpkJkJnSMMJ2fROC5 Cv6Cbpv+fHp6ut+qw1tGuqNDWNXOoQ1CazQ1TolFdvp9/dd/fne/o3Zus7hoER96bReUg7PB8zud 3O/10CI8k389nzX39LInGAn090UBF/9+hSEQbr96arHf3XtHc70Yc76p6d3FK97a/fq/23hD/+/9 fXx7Sv+t/et//b9/of/zQUPVekOYcmOUP/+NtyESv/v1v/6/f3/8GF/62rajQuCFXriIcnDHqtnO zkhC/dbOV9rpd9e/+v4Q/BMji5utpRX02s3P2r6m6ThgiYLsK9bSJwXdW0owr/ba228UtrNBx9rF aeKDC8GZSFVtYM6gR1rwTEUx8VFPxFPddq6sMJY7YSkY5TWFBoNBodw0LQ+0+zozkUmmpj2g0NBq o2ooaYpp4oGEMRERERERGhEWhBghEGCDCEMIQwhDCEMIRDXEREREREZN1JFRm8m/Ij5eJ8npNycX 1CdlPF8qMl0REXyEyni+U8XyEyER1yDyN5T5fITKeL6EcZKIxEQjCOzBFXkJnatmI7syTzuihfP9 OFs6anSCDC2dOwuvmtEcs/yDoP8JtnTtdFjrWwTtM1iGoJuEGaxCFRqFrftX++mr7rYW8Iet3rrh bQQsn3ddGh6Xcz10873vV0d7/U753/zv53vpXs0GjVoz/ed7ufQbennf0HCLyi8wnSDaIx+i719/ /+63/79/zTMEs7ne70G7+u//sJsOqtLtbhPCf6ef+gmv8Nf/6v/+l9fTQ/btUt/1d/+MGGP/744+ viRJlwmP9Df/9Uv//3+phzj/0P163Vf+F9f63//r31mH2EvUnDDGvqThh9fUaEP+t7gh3VAh+s4Q I2r/p6c9Nnq1fs9tTdc+saVH+GrEVWt9NXpX1/fN116e1q+sIEm2Fb1tYonDDfaxj3HYrwxCo1bV MRgzqBFMRX7HvFCDMoEUDMoEcMjkFCsVEUdlwwtxTYSWtO0LsJrFphbTQ40O1TTsKONhBpZoKejY UOU8NRTMOYe9TOcfERERERERERERRFHzDnHiMyLQu0IiIYUIXEWhGz/oT+04iIiIybjMiuQtEtyn iFRMI7miOjtCEREROzorgdUgwXITIxJkJhA7IEsEGVeQmEIZTkSo7KjJUZU87SsleYRqjepl2d6i FO9GM9UaxDqE04MjGEHBoM1wXTTq1OkXMIMlKzpGGaouzuBE007NAXsgTL6hB9eZyY8JLo12H3DR rhD57o1t3eNFxTu01TUK9dUXj0towQt33xYQbRhzD5/9NzwHCRnzwHTa6tpOl87ndwm96Rn1O9G7 O/puez5/QIj78IP90n2nxNIuFVxDfViDavO54k4yOgVJ6urM89L77/VXW3Qr3WKV7T17ntb2phL9 W3/7/W/+hH/7pghr/1/6X1vvv//F09iI//+fL50wl+dEF1+5nJPfvtX3/7/r1//+I/6+Hvb9Bm4c PqoIKPTCCuv8Xv6dIUb8UuoId/fVnu9K0vf9GBtbN1sJfmgL/aUQqWIVr3VbpNrauulfUUrGsb+2 tqDMOd/rt1adj4/2Ngg0sEawxbH8bFMV7WxQMwStLxFMUwwli7EU57sLGmhanIjsJIWqxodqmELj tYtC8/XaYpp6i2KiIiIi0LU5DERJdCIgwTQiIgwQhhCIMJQwpZQLERoRERGbkMm4xHeiIlmoQ7SC EPMhmI0yBIxEWIjBSOQUhMhetknl8niJxPEU0zsqRC87gyMIq0RmYRUZ2a52n9GM/hNPQ5nKLyVM KjQVWDCfl8/kPei+fzUJIhUZyYIU70GmakmmmahM+juBCDiUZhlRdVpOdB6GdUKoUkMNK61/vWYc HdkpCWjRRcNNwrr2p09NP79Tx9pn55/RIdK5/ngNAgV/e760bog8JGelSTcJ6ud+jZ9Enq7U7v+/ +opcaM8NzuVGGCKHiG6v/p/6EEuucc8enW90u6avRvX/+1X+Pv/W24in1711/0C/22yJMjhfp/98 X8X0lczZcJYj//nc4z/8sdHXC9bEfTEbb/r//fr68b/16w8fOjdY/f8IcEFvuCH2cwZMXr/jP/V1 BCr6s9rn8FI8Fvw1P+zdaC+2ufXdP+fUQTaqGbtAz/QzouKV/++0t/jngp8GCoRsaQ3f2vqKi9j4 4uFEU7gzA/oQml4+2KYoMsII/F0NhUtcWhYUkrWNC0sJoen5/wQ07Q01tMJFuU/5FHgzqax4jijd EWSfiIiIjNsoCEMIGCcGCEREWVNUIjFp5/QiIiIiIyy3iIidgSKhE2A6TcbzXF8qMigVSFRT5fIS ITIPOkVcXwgwgZJohWdmMujUzedieQmdQhX7IWqhbVDJSEC2dQh0CmoWj+ug0yMRHQUlHhYd2dq1 moRSDjucdzjWKSsU6I/3V+Z0quqQX1tGho1sEI+1drT1mUTscJhQkt1nj00z45uoEX+bs2Ur0CI+ 6TpOu5ClBF/p+5seFSdEnp3ybp4uF080DApPQ12kO87nhv19P3MOePhNLtK90mnPc7ndTud/P9G9 b1/779dxb/v/+nr//966GP79srbLhVHGu8/eudH/6/7Q/7zCtfb19atdbX3///iv6/dQzdbXZyX9 f9bevyJg/vvQIU57mB//aRvtntz2CZHF+x17akTBd7U0Bc6BbvZ/3q2l2ttri3S2vG//4/ZHKGCK HxVrYx4riK0FTFexFRGxTxRKOIpigZgdT3x7G6xoRbJDlOFF2E01ORamPmSX2laHw01U2Y3d+nkY +gwhGIiIiIiIiIzkQYQiGEItB7EMIQwhGVPPO8m4WhcREZ/QiIiIybjfZbl0U8J3ediWdraEZN04 L2RrIXmuL5UshWEHZWMnSkHKQedezItWoMlxCVCBfJUIEHDIKIhnQKRdkcycFzqIp9FKBchXZ2J5 Cog7M+GElW8KjW2GtJV0unV+SkQ1BMKbM8ByT0Rj53vzdpynNG7PZ8bPmkd3PBsovPU9nz+qUabE G5387p/yKg9DuGHQik+/uNXCd8Ur/nHO9GHO+uq7f6+FX5EE/02Rj/3xv3IkyOFOwUMHYiLhUt63 +dMJf/b/MORvf0WPtceH+u3H/qv7ft21iF//64vZytTogQQO2c31h67rntfGf85Fqf//f0oT/bff XxtpIQtDtToFDxS3mgYm7a/eK9t9v2NAuOopiNrUrYYhLbFIIpNpJilq2GEu63V9XtbTQtC0wh2f t08/ppnJdM6L0xQ49PxXFRoRERGZEaEQYIRBhU4iGEIiItCGFEtx0IiIiIiMslER0cR2K5GIp47Q KWckpN1ri0zs+TkX1CB2VPL4UlGRrKfMIjMvmsiIy+dUfiny6JbmEd5l0RCMIgiMI7FM7pnZqirC SbqYnnbhEIwnDC2kp7NQgTsLphbvBbOqPQTTC2E7ISBNM65hnY4UpQLpn0EoWE2sw6nxw1ecK6rr aNbV1XtXV1tc1CK6r1rM1g5GOtyDp/tM2NcjHBF/+0bs77QIj706BEf21R3v3O/QIFdHfrO/0CI8 jYp7NfvzutdVEaemwwzCS9hkdF56xS+v7r7giP//90nr2jDnivdU7tigrenPX2/t+/j1uI7691// wYoV/dLf+t6+t/6dXvj/v19dBFj/0o79X/ox/0/6X/X6/f/4/2tfu1as5e2p0wggfaqcKtnJvr+/ /Jwf8EO9L9vrt7117fQ0ZrB90wwkJFAXtbWK27Xm7Fet6uveqd6W+t6/2+/UUp2ahbW6uxsVsUTg ugVxFSMcwurViKYikI2IqY9iMGYIIpiKiPjiN1qwlN1s9RphTkWuqajGpu00rVC1TTTQemhqaATF VocRERmRERmcoeIiDBCzoiIuQJAwgYIQYQYIYQhoR4iQvhCHEREREREZ/ybpIyVo7dhREhMmylCM IMjIvkJERkvl8hNSoRri+hkHnXIzI6MIEUPOjMZ1yN53NHXI1kpR/O1eQgQqEQmdj5uO6Kmt50aD CdnTs1CGtEdAoXQRrESP4QiI+5BCD/OjI5ko08/nRWmp2PmGp9ZrEOoiDc7h2asxFSzpFqmSo2Vd 6TV1woQj7nCfqnh/H+qf6rpowStWtqEyUXnodNoEX9anijP95upI73z+jdvZVnzVs1nj3O4Iv777 w10CL7+fUw5TpF3hOgRH34Ij3fX67M4uF/rt+hnc7v+y+tC+KTaXV+/X9/xBEfqvp00hDwh+vqn3 e6+tL///+6/Eff+6vf/+2r5K4f2+Kof1/+u+/1ujOd//6rf2/wrj++v1X/Q//0Nb//X/bBFOtrvj jx/0CHZu/9ZwjNtfdK9wQp1wQ8nDBFxSP66zBJ7s93v7rgih2R8FCEe0mLS9oLGtR2331n0hU/7W 1dfilpG7UtxxSzZojAXj19YriIrscbT1sUDMEvFMRwyPp/sUxUUIM6hKDOE4MwVd124ZzXYqNLCw p/2EGhxYQaef4uwkI5uvtNNY179NjTXFy3KcocodTDlPaYoMLBnCbiIiIiIYQsw5Q8REQYQhgnER EaaER2EIiHhCGhDCEXFqNCDQiIjNyERERGTcSQiIwpBIqIl0VTITITNZlWiMy+RmXypIhM7SGSea 8wiMzCMpmSZnZCOxRHdstVZUm6gISiTNYh0aDJY1zUIEHYWwtpnUQ6MjmdYuZToxBBmsQJphNM7n EHaDs7nWEGNdNdMIeFRcdPX171BDmiqvuduIdRECLpGjnZr+i3ef9TxRu1O7S5swm9Ge6BEffReY SM+p3aSTaNmd+jvwkrifkm9X6D1FfoaXnc7soyPl0qQ7miPoEUPruryKI4gRTqEPX7zud9PTS9rt zud8453/T/6V+v+n90IjddBkcL9fYTBCP//9tdRretfbS3iuytxcL5pFwtOWqUq3f3/+u/Xr9V9/ //+/r//9/Xv/aiULnJits3RpfcyNnLUZ/7X+M3WznH6X+/Z7vpvr+23Rjv2p/gpcdT/fHHhUNpe6 80Be0vbtW9auOljX+0o31///ftR9ChXuqhr6XY2vY/iKiK9NpWkuNhhViKYj2N7XphpfIg4X2Fs/ RGf4tC48x7Q7TQ1NyGhxdiputU+LFIGLFDgwQjsVERERERERERERYQYQiDCBghDCacMIWqDClkni IiIsIjoREZN1XMKGVZkQZ2ZR2IR2aIhMrOdgWVWEYVOGg0Gdc3FTyDygMEHkHEHKROKjNcXyE1gy Ei+UA4QMioyPJELzued0yl5CVdho0UW7tPIdaVkPzp+Xj0Q2nYWzp3n9AwthU0I1OzXs7Ne8wj/R hGaoER9ynNJtBPoER73mgt9b7/0tbr+zwDXlukbGzPdXX07009N4MOnp6p98UCb//qud3o8d3vHn e7Cnx08Kfu/uv9fW5FP+/yJxcL+5oGP/+lzOMBO/3wi0/xVvxWyJRgl7/r//QX91//X/+7L69Paq l/DBFD1X6/p1Q+n36+u1ou/6uvz/BQr6MiCKHmEoIoeYJiIu9Wpuv4IoeqEbb/f97zD/VYjYj2qk Mb2raUUo+hVr2hEaEUGmOh+9UIpQYP16bXUaP5SwwCFP2IqFtpQ119ptJ6aaZu0tWx1TP86ax02t pNpatYM3MGbnahbFMUNDgzqBVYM4Q4NbWNRnX+IJimKOwYYYrcGfczbmuuGE1sJhC+GhfxcRcMLF 4JppWh/en4iIiIiIiIiIwQjORERaERGTcLxI3iIybpMurI1kIinM1ozzsTyERrRUmQaIIiNo7HCG Rai3IULdkIJadqdEfiE1NaCpkCwgwmR4hNUzVF8hNSDzWy+diWpCs7HztOiEwgZV9bgwujQ1W81C EpCAh5BiIt6uahFP51CBbOncwHXO1FmoIRfvP6Z07TNYQrxUCI+8w4ck/Sbv3Vd0qbXV9d1etftL fX3Rravr4QYc/r3dfRhzvRvSN1UYc76bnfaMOYdXz/R4/5/5336N393Xp0Xn/iHUSeLha2JSf1u4 0PXauu9U2/jp78ZpmAi770Pt6vrdCZLGRw/9X/w13//7/X/cNfq/pNa+v+8rbLhfp6Q/50wSs91P 28xntTrqXQS++z6f/W9fdDv61nryN962t+h6/9sw5J+9YgiGC47ukoQkQ4iKveDLthkdBV/en6tv Wzd6k4PjP9+gQps5kUDGM3ycMNq2c6HsRUL+PkY5Q9rbWNCP74YWNfVn/Gx01n/71qNpG/rVpR29 qFMeOhzkQZ1Cil92NimKeK9YwZwg32IoGYGwZ907WdNjTfsKqcZY5Q5TlDxHFpn/P9xaDTQtC7P8 MLxdpqblji+1N0RiIjCERDQiIiIiIiIiIo3REREREQwQjE/iUvK+iaEZNwmRJGsyTRrEOqyNRK2S zOZC46hCDxKrE2HyO5XKiz6UJpqpUZihmsMEJhBkJJqRQMJGgLkHEHmuL5TxfJfQZ3kXyoRUIhed 0wQyEzuihEPIU3o1s6+jA56TQcGkaxEW86/t6NWvXC2dJNAiO1s1CGoQlSI5HcIjoKgtMrxUSHb/ T71vU4+5nLeEqb3rngmPqaC3+trqmgnVwkEghhCNGG++CNO/7+z3fSTz2DahBuYc70m/pxgg9npp BN+jved71O7ptAi69SESSv/St80ZHCr+xv/Yhx3r6+++2KGnNIuFNAx//S6vV6M5UZ3PFBzud3O5 32clKWqMlkZcu8db5hfwa/r/t79dK//r//0/69d//v7xmbLhQmXCofVan/0oJkfCowMf0dMJev2o Ip636owP8/ZvKj//6uvXav7f//T+kzuccw+2ki8j9roRVImPiuIVq/vUR69Vajvj+vrHVpfu37fX /6MEP8Z/4iHsdP8WrVnthH9wsLS77C0wwk2tnu/X2NK+mltW9L1vx7+9/u7Wwnx0MGcIOthcExWx sUDOrFMUxYYodrY2IppScMRHxTxWx7HZy+t3gzjghoZY53MP8cRpoaawwmlpx4TQsLYQuLjQ8Y44 1ERYQi4z/EREREZuQiIiM6IiIioiMREWnEWf8soQyXZ3GQvESEyVxXSs7AkIybjedcwypZCaYTKv NcX9SNZqZfKUC5CYQZURBxB52ryNZFWY0jpggzJOjCK4SldUzIVETTJUJot2i3ZrEC+eqP+vmoRM 1iZD/P51CIR5/TO3i5hOyunD8JVOPS0E3CbXv/1uZyY6Snxq9/qix/o1vULp+dzvpXRhzv6dJ0Yc 70d729/O/ahA2iQ9XRu9XfP1hM/b6bqd3O+56ZXFwx7fV1tmkXC/3W/775pFwq7jXO96uhKAf31E e391391br/9f///f8NYa/X/7f4X79J7/f0v3szkh///28//69/0ND5+3//9XMORv6Q3vQ/ML/910 L/x/0P2trbf6rju+la/32bqFwQ+zlr2knpd6Vpb+9oLd/baTaXrGkz9n/8a3/trH9T/NAXbSn+2t Rq/x33Yw1tMb0xTG1FBit/9igxTscV+DPsT+xXoRtKxFBhREWhEWhFphC00NDjtQhoNT/Hx50aHs egyxwoiIiIiIiIiIuIiDCGdEQYIRloKcRERlkT51jeSnKhEdG8lQQ7hlIiDRUolCO0MhXK5bFd8w ynaqsGhepKovBMiEpDNMp4vk4YITUjWmVeEGdoyDyEzrknl8yL5CZKI3lQumoQ9tELqrmC+ix2CG +F81CZ6IeqZ1CoM7jCkOzp6n0FsyDENQidnVWZLRnr1BEeRMfWzw6ek3SDfCbXmeq+6Nb0a4Q++9 VdQrWnd/pJ0CB6cevP877p0bvzvuFP1GHOOm37p5u06W/9oEXWjZmzTfozv/3j2CJp9saX10Kv7i t1ht/1utW53O7+3fpdIaFXp0m3/0/X6+/f6/T/2vTuN1+79d13//7f/7vDDupwrr1f/3/oarqX3b X9V1j/f/Xb7x8hdahh699WrZubCT6Wv+CHdWv/ghQIUu12e7PekCFOx1aC8USnVhhLP7Greh2sat pd8/WrXMwtpd9c3bVYycMNrw34a0ZzvaQgmKjYpitiExTFbHuDOFiKhMVsYMwMwNWxFKrFAzLj3u IuLRLpggwtpqf4aaaGhruZWhp6empuzeU9qneIiMEM/RERERERnQhEREREWmhcXEY0J0Qn0IiIyy BobI2ioRCI7OjtUEIhSuqZkKI3FXhMvlRmpG8qI1RJJBqtkHkJqQrIXhTURV52t5UI1md/l87Jsx Ep+g0zWIt4TCDId5BArDIwIdQh0C2dQh1CEX7JQEmCM62dqgQ1IjoJhMLZ3O9T6IS9IER5UCI+/7 vpSnD19V3VJGt9qhFT21zscJTemdRPVOjDnfX8Kd3+z9EGGjdm7P3RvSNy+brn+n3RuSq2gQK6VP 6yuUIj5dEfX+t/zSLhdX7yk9thkfoaHc0zAXGh+hjSv8UYc8aevnc7/fRhzxmRkghER//r/9fWgx 4/HT3v/3a+v/T12/uq+L//b/z/9VXYeEXFtu3RnKhb68znrapr+35hdf/x+3RkYpbv9R+OgQrhkN KdBumcidJmGU6Ucbhm6zcRQHhm6h6BCmzl32kn+/3r3lqmi/rvTEV7StYOCHCzgYQjOgXzQF0NyK BjP7a8Vb7a1ev+szlO7fG+GFtRtDtYM6uKCQVprCa+wZyvGxQM21pvGhFsRXasVQu9rHERaYTi1u zhFTOhTIzjanQp/XMjtPN0Wtp2Nrp4qIiIiIiIiIiIiIiIozneDCERGdCDBCGEIiIYUsxG4iNCIj K4LmRQjPNZknkJnZrEIjtLENbEyjO6ITsZ0HemS6Up0pTxHjXF+GmTGVeQmREFTKvKhGuL5L5V5B 5UZ2FZHSkuiIi6TNR52a52nRUcIPVGhnUKCGFwtyJVPZ0aDOvZD86NOYIGdfNYq2dGgzUIdO8EIz pBBhbJwwgylgup9EJEoCGsTPdNUm/V954DrpPf+6RrrYVXpNd+tV1Ro1puoWrbrujfRuzvtHfi93 U8V+4U77PdN76BEf6nijd/ns+Op3c77Z4P1INz2fLvzXl307EpOtxoUt/wQJuv399K2NX9GcqNf/ Q+aZsIKTruu491ik3f4dBNFeF8Nf//3V//6//v0t9//9r7/XpP37qaRcK03QoPamF2pe7Pr1+rQ/ 9evpGB9V7fa/7//VL//r4/Hbh+kzJQC71nOQuoMK316gwfFKTg4IcfWkCFW//FbnsnDAz/9jVvW1 v9an+ue4dvri9DQ41Y0jrrP/V6aWz6tafVtVcKh0va6X03WtqjOVEfJSITguHxHORQ5OCx+xUcQX hrBnBnVpY2KBmCYqIqvOm+xTWxFMbFMVj6hcr/0xGRjnHwQvP9oMJAhxYXi1tYuwhhT/x2h2qaaa cXmHPqYcrCnjnQpyIiIiLBCIiM/xEREREQYQiDBBhBoRGhoRai4iI4iIiIxMhpELyN50iNZTxlUI dmMgSIVmQnFWyO5XK5URqyh+oQZERHiXyr1IOCBhSDyhl9SVxdEIjt+whkIjsTR2KZK3z2p6YM1B YMiAiLHYVzowmqMEpmsQ1QUIRrZ1gnn+DginCWdmqP5TihBmpH8r3fd54DqDWEG16TelRsahDoLq n7aMo6dgqLdp2/7x5+c9hz/V533U8ez2jct0bqU9nxzvtqd3eU559BG5fzOcfCD/33wRNPcQ6jVp b/mkXCseNdDO54YpOv+74YbYT396Fpb3MlhF0YRHS74a4+///////1ukveyKcVQnYhkcK/jvXERH jQ2HZDwt9ev/OOZ6LgE/39//1oYXuv//6zDwYZqyOglEFZuvvqPHF4Q2cm1c5f3t6TGlnRAieUYI zmM/ylhiz26ghU6ObtHolGFCEcKNtW9Wgv5/NAXtJD7rX1+f6FO8X9FAgLdd+vdCCgoLYpiKa9Y8 rYL7sbFMRTQX4Lsjojoj6+yhzQCQ7CsnBUjL/GpMucJn+00LQvzkef47VC79aERc3Rxxmwz2KDQi MRFhDQiIiM/xGciIiDBCIiNYiLTQuGE8SN47iIjPNCIiMm6SINktEO1eJhCQaOwPOzRCJ2p52JqV wTCDCDCkJkL4MgWQmQeU+XwgZqaZTxfITCBnVmIqM1xfNZJndEa4vlQiUMxadUW7Rb5hp8iJzD86 iBOwn4XOvp7eFtMoDB3aCrmsQ1o3bcHIpYZy2sNaCbhN188BoeqvNbptdbmvX+jW8ENcKCFVw2D0 /Tq3Z7rF0tG6jP0nrnfdaV0+gRH3pueDZSR32i89PO4OVjqd3/p2M0jAQigYBBTud2UBFoa7rV/f en7J0bQWvVxq53O/3oUZyo+IbHS+/evaawvcIf/36//+Ewh/+r+2v1S/hztIer16ukZOpnKHKHU2 Hjf8hB7f17/+v9V/uv/f7ft+dmqX6y1g17XWhoR8XBg/5kbOd/dWr6ghVrajP//rX6fXPe332CCO xJ349tJurPffnT//QtvVtbSvSptJtfvW1brvvonBe/bWIVxpbY2ON+uK2NrpiKimKYjBmCxsQvYi icMMVsbEfxsVCOxrBJpbTCaxaHklCHm60Gg0wqaaHa3HamPDtNQSEINcRGf4jBCIiIiIiIjOiGEG CDBQmhDCHltcIOIuIiIiLUm4TIXlWIdgedzRGZGkVJEER3eJ2KIS315XVODJiVSEzXF8IMqeEDsg 3ZKDTISCBmpmKyoIgmYSnRH4hSKhHdnfgzXuyDoMDN0LaZLER9U4Pt81BAn2iKMDTspQLp50i7NS uwgzsdH6H54B/1+6NbCEaNbh102s1unZC6Gtr1rpp/NFPh8X7mw7uz3Vo79J0knngOnrn6k9PKzQ dHfZCKez47VKd33pN7luKHwQLet2Pf77nc76sQb73UavxCXruExV3QIj9b0+QdT+DDlcXDFa7f// Trt7/r/+gX1/WGIQ/+ZxcKn752NUiNJaW9L7Rgdfq1f7Uh4W69+v/b/7fX/37+GpaRUrOiDBk4Y1 qgQr/r76sIL3Ss5X2oMno19fo0DF0oIUM/6uilhiGZLSBE8Q1zIT1atJ7PdXq2v02sQmwsNYptW0 iULbq+htbY6/HWm4hf0IQM6gYxgzBBFMVscVBMUxScUxUUUA7EbFTwV+lBmB9hhJk3PsqwrjsFsL oNNDQahMINTdaagk6axaHodjBxGFxn3Q3RERHERERmrMiS1BhCIuIYKqaiLi00IiIiIyyDERmJBo 7/E+hLIYRapmpXVMyK4KEGajhkvkREfCDIyL5UZCslcXyEjXF0VGmSoiIzCOz5C0QvKhEozsURWU mV8Q8yE/JSECb50YTC2mudQuFzUEC2dNSLsjmTgumE7OsXZKxEzpF2axFzuuUqbuGp/+6zW4T0mr o1tb9dV9+6RcP1TXVNfP52OEz+vD1/z/SdbqeKM/SdAgV5+XO+5+zvb+p3z2fMJ0d9tTu0Xnqd2j OUP/S1Wyne8rgq+1Grp/67rpfbImRHRH191Ff7pKx7W/f3hDtb0IP3zjmfbzvww75XFgX9//71/7 x0IjX+v/9J6dfS/JWyOHVfEnDDertvpbsiyWf+v7/rerzH18se/vf9f/a/6/11/H/DC/rHZ0TIDD EM3N06x91uv+tFH62cn1NAxHV70+rdbZ7YU/71s9oyK/od+CJ3Wu1HawwlQVjW0tvU6BfvqO+qpd b/qNJDG7Y6Jwx3M5T/0Z76R0G88FP+DOFWKYprikI4ikE+xFLEUdd1YpjiOl/oKv0Lva5/iOF48f Z/tBhC0GtpnWbzdDWO1QaHmc48cXmgqyh4/7G+1C94iIiIjORERBghEREMIGCDBDQiItCLiLiwho MKsRLSClERERERERERGWQrRkHkhGkTCOxrMOVwQjIoi+U8Xyozo7IzMZri+dYqZWfS2CDIjL5CZT xdBDILnTP5CZCZBoq0dc7IRhFWiVmd8Z2QiMiqop3TW07+wnreewnEcNMLZ1CLaCJT3qahDUIdFZ qCKfRCoJ2mmVemd5BMIMlrTCDK+VGtq6v1rq9c0NkQew0a2m6hbmCveqp36ZKRF9GhmsRGhhDRY7 CGi3ZkZBNOgRH+d99PO+0CI/3pB57hzoaToz+bM79z631Ruo3fRsvpIER+9JtUm1QQbWg2lXq9Lz OLhe13q7frSewYdXXaQ+9p/a1VPuk1ejDnd1v06MOd9aN+nRv1zud+r+//+v64f/YyLT67r8V4MS k8cfxfrdfNAx9b74/Qq/t79qvrnc77r/6Q/3CLH/v//9X0roV//6/fv9//6/vxxd1vX/bXU6IIIP dXVWcn1Ri0ZoGM92ewQqz2v2+s5DujF76l7P/ufTr921tNX1Xhq/V6z/tK6Qp21e1NAXvp6Vjj45 uf1fWr/be3WVhQ1tYad19YpiKYimtiFEUxFeRQHY4JYqIrYjhkdEdgz1mRXZQ5gf9jYj+LXtULpC NtIigLk+h8doNNDhoNNDptVtNTHtIR7XNmbI83Wt9p9DaiovY9Dd4YQiIiIzIhhC0DCBgoQgwW4j QwhaaaERDCDCEZ6RDCmcpzj5yLCnIUkOUOxYUWhERERZU0IiIiI4ONCINCIiM5CEtILUm4khOw8h MRITERERGVyzUhM6Z2nyoR0yqZAldkDyEyoWSjOzLMIqSJYyuXRbgXU+jIVE8/nbiGvCyDi9YOGR HnUKdQhmC50i5qeyDjWjcnZKUmdIuwgzVF2QkQkdrUmUvNbL5kZBOq/kqRHIKEO/hwa2ktX1nUIE NdX00W7WzUJnYXeXz0Rf11+jd7yKYQkIg3VZoLd/PAc8B/NlF5ns+OkCL96SSBEfv6ndwg7SBEeW vre7QIj9ou1foSgHfTuhnc8aD+RCMLENiG96emhV6rfnc753O7rfv3VtadGHO6vf/et2m9+t/Oh/ 6751DDv7t41f9/t+6///0vW2aMjhX7+v/fHok5noY7/3X+dEp0Svjv/8f///S//X//v/pePWGc4I XX7Pfvf86MMEFDBBEgMLZyuo9fv9/BD0t1v/2FP8FL4WIzNWYQW/83Y/Z/3nAxbauv9xCiFR1Ck4 Y1pZ7Kf9f+krGtpMaXePaEU4ghFPqZJQUtIFWvf/1eOKH+FBAzA0FYp1x7Y9jYjDJhEpoGKTt++g Z/1EVQ/n+OPXMiLTWPCp5k5j2hr2t9oNB6w1TUY0DME4MyhQURoRERERBhCNVQwmgwhERYQhhMLE ZhyhyhyhynYiLCFoaoMKdpLBWoiIiIiIiNCIi4iIiIybkmd0yyVYjK4KggyMi+VGEGVGVLIXmvMI qMqEQtEtRfKcyMMiDNbMRCUM7qzs1RUIrWTZU4VNbNQiDOnZKghDZdmsROzWKRiCpnSLsFtBoNB7 k4YhkEzDOoUg4g5M8kz6IoGDIUivwltGtq6o19101C4U6hNU10aKNDRo98NNOjUE6vTXPXpJ0CI/ o3ab9F5pGejdnfaLz01O7QIjzpN0HSbhPPZ7ktOp3ozlD0n/5oNC8IjHlpBS9XXdCr90NV0K7wnR hzx/enunW6fxScN0t4h0Yc71v6Gm3yXp/j/7r//76/GvImGF/X7r/tWyImRRPW03u5oy4Rvb0nvX H3XXf9f1/393S/11/9fDX6HpNvWGtgih/dhFD7+6/tnN0icMNnOPs93q5795yN17990336wwi7/r vtTc0NCPqIpqz3771Q7Wo2lJww/Ud2urGt+6utrq+2TivFZ0Ct+PzD+9dhhdmSWGGIrJwwDMFvVY jXYr6SYioqDSKAdioYSB4LcKl2tdH+f22Fm5ih6Vqf9vN0amPDU2Rxx3aY02mKGFsLguKf/2KrmH 3mRERnRFoRaEMFCcMEIgwQYQYKXhURDCaxFlAaERoWmELVH+IiIiIiIiIsIXERERERES0gVSbmDI IjKrK5KhEZXF9MqECDJPNZHZCsg8hMjaITINEjIqiMRhHVmJM7IRhGrMjCOnsoTmtEfCoPTJSy7T g5BET6U1CHVQ1LozSYJp7yPfO8+iEjsbyngnZHRHRfNbI8SuL53cXyXiK5A2XyvnovKZFmEI0a+j W9Pu9PUL0mnpfcGuqZ1CHYSsEOIiDV1sLZ0k8vn5cyMxP3rTfTdTvynbNBnf6Lzv+6BAm9PPbQIj 9+l6toER/V19PvXSLSC1+jID+Yc8dyhG1q9LeGGk7v8J/3dfusVrdvnHM/eblPh4pdo8POucp3vU 8VrnfaMOd49rvr/CYQ6+nM2XCSJRX3RoyOFxf9TNlwtL+EXuPu6tddCl9b/p3/+/ruU6rbxZf82l +/MKu/11Xe4/v2I+t//+GtJt/e3/63qvr93VeQxP7EcR7b2kmM/3WOhm5kNBF4v1GbueycMYaRvf VXgyezXqh2+CG59ffr1W0/v7EXfggf3D9+2v90/XEK7S5oKd1k4YoMuCnjrd7a/0jD3+ihIGna7f VvtfrFdPqifh/Vm5zHvFIR+x0F+FsY0P6sm5ThOP7EVFHQLEeeu1kh0hG2kMasWojGlhQZucaSCB +/VVi+O0Lvwtp8eXSDiLuO0GoJp34wceNimKY2utihF2MtIFURehnQhDBCI7QYQiLCD0IiGEM20B CIsJqchBhMJhBhCwhaaFoYiLiIiIiNCIiIiIiIjJuoRVMjmIlfRFkMuV1RBMhMIZ3eXyMzCKhFSz tbyFZ2aohaI2rO4ikRXfUtJKUrlisJqe0EFsJ2dVZB2djcahCDjUKQWTPo65hplW7ISJRmGTgudU biowgdkLyIiVMxFPF8IGQjJe+vPD7n2e66dnQJ66kX3pVXPS+mtBMJnS0WPOv50afraZqCEP2QrT Hv3N/WgRf53/+6NnCJv7v0CL/oER+3qCI9PBcX+4Qbu+rhNhXRsrvD9r78M3Utpd7ow536pNVBA/ /Vb9brSu8Jup4e6vT9Iz9539Wjd9Gm+/97H1+9dbmjI4U7TsuFxJwxju3/d/5oGOrH0vrr8iUXC9 X/69D3h7/fGl3///X/fra/Vqv3+r6/9//6/9PfXwRQ8ugkxGs+6ar0gQ/xn+KN9s9zkbPYJkcaH+ hT/Oj9P3WECsjoL0CKHZfC8//p/+9z6VfLSBVQiNZu96t/X3+serBhY+K79d4+1Y0kIir4iKH4+1 /dbTBDaUcKY+rgyOiPMRURsoc0FJ2xXv/ocijlJz/cLN2NLVoLaVJ0wwte0FYYSjC2kTgu0ILBmk UIXqI2mhoWscdGcoePIx4MEP11sUO1sU9AzKBQM4X2timKYrBnkFrQiKLHgwgYJxDCEWhBoZ58RE REMJoRDQjQYWOLQYQYTU6F1EyVdo/iIiIiIiIiIiIhhBghER2ImSEZRFcQhEtYQqRT5hEERhFQjq jPOjN5V9kbyDRUI1IqAhK2VTTOytGXpKVwRl8yGzCQTsg4E0zqodrdnULIy86KzqrTSISCDIqGDU yPGtkeOiPxqZfhneuakR8Jmpl8hUQlZA2R4hUQmdiWNdNJc6hFdP9rSgwqevntGGqLdpK6Xbrt6E a5KPNYuXz+lkqE+gRH+eBCnfaU7/7VJ5rysaJP7/3eEG2eDRRx+gQK/oER+0CI56re4VfVwv67Vp fnc7te6e1q8OKz/37fz+u402r2t/17sPn/O9/RGP/QIj/P3y1TCrv1W/vX+DEpPdqwi08a974zSL hV0nrelvtdxBsrbLhFFf7nhP/V6iaZsIdiMwEH/Wb////rUXXb9Y9d/vVf+v/Xr+tbf/vTVV+t+3 pfd1QIZoGLrBg7PZOGATI41nTqf+vW/tUCl0Cv50wQVT/c/t6qvvEe9O8jH80FD79RH/3T30ranU K2CHUcznH4r3VrfV/EfpIQh+Gv0CHbe912exn+NC+NeIq2OIplDmrNBXWKSOgUKycFVFDmHOMQvZ ydScHbSYjYioUasL441YXqDP9jWP/LVE6xU1LtbjtC7UscFBS7LHhxGh+MdWKacGdQKQXqxQM6jF fFL/8MJoQYIQwgYJoRFhDLrCEO1iKtS3KHbTCYLDCoXZ/QaxaHDCm+OO1ERERGEIiM3RhCfxERFo REREREREYiIiJX0y2Qak3WshEVCOwNkmiWMpEZDMhEVCKhEHmQ2iNREBDv0MrqmZGYhD0zqrOsXZ UZCQQdhBkZBM6mR4g4hUdMwyngpqgUjEFNeR0FNAXNTL51ysRByhBpELzoaZUsg4leYyC5kWWwkr p62ahNFv0W7BCt8lIRNQhoZ1CBCOl1P5KRDUJl8/poyz2yWIEUPOnp5KGmZCrTLSC10Xl+raR3a1 Cb6D67pVBEe1VZnLegRH71ChLu0bPwsEI1wvp1Y6p+/90Yc79X0rRuoz7Wccz6VtG6jdm7P+oQet 35uyQ9a+3PfTpO877hIz6R4yuLxcLQ/ul9bmjI4XycMb0NbmcXCq/09DQ0OI9r9vQzvd36eLInmA nc7nf67kR9f9avrX/+vtfb/X9v1/1d/bXXbtOvpV9dv69P7/LSBVefrZyNAwCFWl/Yz/ejHMi659 erU///qz3Z9Nn1Z5P/obb+xH5jRivMOVG6/Xv2D+vxj8VWxr/9r/dFGgat9Cu/x7ZH1YaphbT19V s5/ttpLQ0L/+CG+sOPj62oMwMsIkrbS7jX7CoRxHr2rQVCNDNAXjtKNKb5EgX9Qzdhhds+vYYSf6 voHaVoLrmcp7tBrajGkNrYpNofja/9imK/460I4v2PjOmxGDWrXFpoQ+4iLCGW5XREMJnIQYQiwh Geef7OjP9oNDs6ItC1qOGELWwhFoRLSBVERERYQuIiIiIiIiIiIiIzozOU6EREMELK0LKBZ0xPwn ZbiLQhxGTdbR3ZmsJZUBDuaOnZWIyW4yUIp8RIUjIKUrgkpC4JrDSIOITNUCBJ2bVkCicMHRH81s jxCZF42iIi+QlBkGy+QqJUy+CBwzvzTKjJRkJkLZiKGXRdBMg8yF4v+yUiIuHOEDRlE1CIRxI0B6 Sdq5qEiRkb4NclHrpw6b1PpT+uhEUahFv60/O4eqq3BEc3mg0fXSb32eAa3uujXlQDr9N9p9VctI KXpGHO+rs94Ybn9GHO6RhzvRvU1njTD2kE+6M/Rhzj58PFAiP+PO9+53t02LdPu/1c8GujZQIj2P MgRlAYrdXYxDx1t1vjTdiDmgLjt/XdYbV+rszi4QItP/19XBhkf7M42Je3q403Q1V+Gv3/1//pb/ 7//9Xf66r/1/oX1YVvv9J/utMOZH/VHCHhIwP/7n1eppglMeuCl0F+v/9qnn5u/6V/4RcfqRj0ND +/2vd/bbt/EL+/uGm+8QqdtUIq/+7XvxXBk9OoIb6ukdMJPeM//ddWz3+WkCrmSnPb62ErPcJz1d 1bdR2FGFq2lTGtt02k0xH5DljSq9KGqELYYX0b6N+Gk2qGxqIILiPUUxUcFG7G1GrFQT8YMygU1H GNVxCYwZ1IRTGwtiv1fY2K4pdCIaDC6UWhanmmFQiGE0whaDCDCFqSBhbQYULDCHFx2Ewp/hhDER n9vN0REREREREWCERYIREREYQiMRERLc0xOxJCJaqzybjaKtEYjCKcynzmd4zshHYmiFZ2kEJYrO xNHdOpXVMyFmmdQoJpoOHZK2X0Gd3BMg81sjxK9M6ZuOp5K2R4hNTqjcERqDGYZAoi8mVOL9lYiE yFZCRB5kKYyuWeFdJXRo+uEW7CHauEO06tX0aCk7TTNQSGRASj/IOL7hkECqSoQ1Cefy0gRVv5ro w66bhNoER/oOtLroER6nX6HVGyrKcNfbXg0jUEChToE/+jPug9XavvXdWjf533P+qerRn32e6nd1 c2RDc/b5rPDQIE3ndzZSmyjdSvHvXve/Wulur4mbLhEt1Ff+vM4wEY/dXSEMGR9RfpvpbEGHtzud 6Q4zud2+WkCq1/i+v/+v+v7//72qr/vH3rv+4v7f+9401+l3q8xuv/ufVTd9c+nXuvWpuzF/v4Im 946/qjphf//0OCFN+agl1tpd0306w0x9vqGnFbq30NdMV62ciaaCD2clv9/CC/3P7Z5ffqIwkxFR gscaw0o+41jwsMJRr+f8LDSJwXQhZwF5/tr2msQiWBf44u7qf8GaRaphzjgnQ2mKYpWtila2KYr4 2qY+F/xQsRUJLtVXY/LSClcME0IhhTOccw8GCDCDU84iwmf4sINMIfGmFORa50R2moKYwObs3Rxx iIi0IhxEREREREZnOPEGEIjiIgwipLaDCaaaaDCGTcJkJkJiJNEZGuSjoRERERERER952JilOj2d pAijK4vQ4cMgcSjMQQcHZBx0iByRTo3wyBRqZfITNbI+akbiozXF8hIg46ZWcg4nIk4vnQy8VGSo Zqjs5FURUI6Rkq/L59Q4cHSaaL5+dPo/moRGUDhkuIvpWEwmahE7NQh1CIg4vOoTX2zUE89kojDt NOj/lpAq0qcERzmHDncPpOnhN7+EtNlOGkt6v6pOFVtVnQfTwnUI1uvChGtkqENQT8e/QYbQYeGH 1M7p1+79z6RuQhhok+d76BF/qd2jdQIuubM2ZrM7RuzZ1nfdaN3bvqd3tqlf/oQ4hsQ5oy4TrW9/ b0ZyoxdCGGR6d/+ZxcLX0r0NXaQ0NO9CkPrv+NO/71ozlRRnKi+ZDWYCFpBS330uv71/V9K3VxS7 a/frfS+v/fvHX9/3r+9LdL3qo2IoyE8EjrAkdcJNT/+v9QqH3owOfQIm9/f6m7tV739P/31f3X5j j/8wvf24+YfeIUQohD8ehukEPt/bU6DD/+o1t/GlZz2uzlZy63PdnKc7fX2znaSq6+ktt/eo0f4Z ucFCgrtoLbHU/31c+otBffGl8WrSk4YY1jNAXtdDNAX++mGFi21qbsUra3+2/P/78KChDVc1FQM4 T8caUK9jY/Yp1WKXYx/diNilQjraVCK7Xtf/TVVQiLQhhY0LCWf7WNBhDsIWpkQ1N2dFhT/nIySs JhTck3xpRihYqseIu4iLiM2REREREREGEIi0DCcRHERdnRERmQw00IjERaDnamiN4iIiIi00IyyF eS2O5xCYipViFdWhEt/UrqqOx0YjsUyF50OzpH0EGEDBBmpmI7p2pqZHiF5qGVPIVggyWkVPIKiX zCO1TKygQcrhSTCd+/ppqn6waLcoZ9V007IvIMJpkojDU+iUJNOCFafwn9GxzW5rdO8OEKvo1t9G to1vtNLwumaRId89usKd/pW/6TpOlfPAdnud99N/TpP0jPQIE3qCI98MJbq3ncqOlZ2ni4UicXC7 29PV1e5SgwINsaW5EwwrkTzDI5ETzCI7XvsiebwRQ6quv6d8MV3T1u/7/vbX//1/9fTjTQj/0whH /ra+3hgv++/1U3Xn+6odqY+uvljlDlOU8mmCSMX6yTnHKe+8jH19GPox//+/oZr+vMf+PGsftJXr vvbWEIi9pU31BCPqM/xn/+/jP7v9qtdIQQ7SX+0v/FTfjVtWwsMJfEFZ7jX7SVfhhewv7FLdrFLM 5Q4Ij6Ta149ffetDYpimK1hRsU+xv/EcR/qxFOuI2yVhIRlpFai0Ii44MENbCaDCF62h2ELjqo0O 0NNYNDY2EIiM5EGhEakxyh4MIQwhGY+ZERDCER50YiInYEhYIRERERERGWiEdhSTEmxrmV5a6tSu WZ3rHY3Gtl8g4hIhMg5MicQcRMiOLZURfJfIiL5rZHiEyDiDzXF86sxELjueSoiRwwprMqmVy6P4 1PZ2OIdqN1zpvSmoWi+fjqIahI4a2dJBrq+dRDUIt+SsRUHl0Z8M77MMKEGSoIq+1u1v/C96qi3z jhr9hbX01V6bCnZqIjXW+GmmCJj5ohK1vo3a53/e6/o3UbrU1xBho73pHjO90Z/o3JF5QIv9c2Vp v8jHSMPCTpNyY+1LSBVvod138zZcIaMuFnc8dp6GhGmwwy////XZpmAlDCGu1cl1Qzud6v+DBmFV OCJvGnhA8IEJURt/9f+v/3a+rxr/6/7pr+v6D179/j+0F/Vi40KbPoEU7LoJXqCKHmElU3XRu/bE bZ9WfXgiY9///9amHMPbb334f7/EYX//H6drERv0hEY1jv/2ra6kOQQf+Pf76GheznZz+tYdnt/d XOqCJ3vqD/yuIFI/m6h1GrCv1tvBm6hobaUQnvCVBb0nVfNAwThhtVhpBz4Y/tIGf6ELjWdxmO1J QFluMtIKX8GdWKBnCLfeK/2OErEbWxHEV9rEUxQOvGw1+E7S4Y20kqcbTz/wwscWhcWp/z/YVO0M JhBoedGZFpoZjxaYr4WPmZsVM4LeIuIiIiIiLiGCGhEGEDCEWmhBghaaDTCEWsRDtUNPERERERER ERcREZNxpFSztaRXE0MrlKMI2iPHY5HZM4Z0iDPKjKeL5CYIGQkQTKvKhHTI3kHGhkeI6CkHEHkJ ncRfO/RryFsxGsiIzCMi6Oz5B5kNs2UIRFJ156qzp4XNQiZqEJRIM1CEQk8/qahEIjOnkPzolXOx 5BqfXpp2SiMNMlGbiMFNQtuWkFLo1tp/p7tbCo111TOgTVwssfvfDdbVPTp0W9e0ztX6YTChUCB/ PZ7pOtv1fzvebpCdNo3ando3e35stM/f77QIj71O9+rQTaO+6nHq7wRHkRj0Sf4xSbq67/p1+hTV 6Fd8UYc8fJwwkIrf7119LduS7V6bX6Sd7qnRvU/6MH99/uv///6/r29Xr7r//p2//63++kvxxt+v a3od1YX//s+rS39tDkKP/616//Q/+v/r9L/hd16evUnDD6sM57q2r/Zz/5yNnu8EMEKBD/vS91vv XXBFDy6C37n02e9/dNrBhZubG1ekThgbSQ4wlHbao37U0BdtKqq9WNUbow0m1fqKVCIpjWLQ2I7D CsUxVbQM6sRqx7Wm8U/XxQMxc4Q+ziKpX2KtYjdWqVdbFNBghaDBbCmRan+PNyFqsXmPar2hqtpi EwhoGdTVScZhyhyh83HH2gwQiIiIhlDhOIi4iIiIYQvhhCIiGgaHEYIPQi7QtFpBaiIiIkJiIidk YiVTOqEREREZNzCMIq0SnI3nTKRGEdiiJUISsy3OIdEZAxEzIIpbmUE7TIPU+jWIp9BOyF5ri8ah CDlNTL6ZqR+JUyPEKyEzUy+dcq2X1TMIwjUjca0byVZ+Wzs0wiNQdqltBLNQh1CahaVclQiep1ER gm0aGnr+vn9dGBiINNMJoO6RnOnDO1iQa/gi/r9yY+9Hfao491XQIj7pN+k/revdXq66dDOOGqo1 vLVAl17RnO9Hc730CB319GHO9X0b6MOeLnuvp90CL/873vR3vZ7mszup3dTu7Ss9iGG1O7pvGW4U y4Sv6/e6xvret67x34v//rsjbLhCcMf7/sdO67pbtoEXTGGGXXurmmYCdfek2/43g1///6Tuv/f1 9VX21X/v//DFDxaX1pram762/9rn9DvX7+nPrd0YH/wUugRQ/eqm7Mj+hv6MD+69pbow5xwQRcdL vqWPj7fT/3zOceUBiYe/X9/DTv/1tUIim6xr99f1rrilY8iYYoRNeEnj3UYR/9xH2tt1QtrR+iO2 6Y0kN9XPbGk2k1EV/3pI340rPdr6WFTs9xC3C2l5aoEtU07FNR/Lc4539NPGx/HHGxhmUvtbEU+x xsYtW1TOjHC2tj8YiDBC0IYQjCEXEQwhaYU80IYShhMJ2EOO0NBhbCGENCPCxhMIeIiIiIiIzdER ERERmcp4iMjHi0IYQlmmFac6bQjKnE7WEIybpGZaoqebyWMRUqM3lTRPkUiHFUxKSETsUSct0uCZ 2iOiPx1MjyZ9HXNwTs65iCDtOyWYXJCNAxBkxhAyryIiFYQZGRfIVHf5V5S4jo2goUhEWqSqW6ru jQzuBE/9NNOtNNFu2D2wh5fXgynETNYh0aZKGmmFyVCHZqwmddUIjSTHek2u6BAr+6BEeaeroPOO DrXvngt88BqjZSpPTRsra1e9EqIj3q95xzv9Lt+q0rpGfV4bp0bvWMIOLow5x9WiQ+p41O+rne6N 2kZ/kLU9nyEn+9a7v0r3rv/Vq4g2vQ/rYIFWH3ne3/S2rr9D19kXYTFJsIm8TTMIjojoIof/67X3 Vg////V/v/r/13/6f6/+/X9BaaERFFqkqggVl8JXmPtwUji/hCtLuvp8mcCC+z6Yj3b+9f//V+/v 66//8cRG69vxV9TDtj21j7VirVtX1DB/3T/FcdWr6tnOPJww7/GYTCm56jCvasmOmI89YWKaC2kg TFIYZ/tpHT7b7C9+FaVtKNJDaWhG1nimPwZtjY+KDi1WwtprYqE1+xUU8UaBjY2t1jY/U6TDCWGP 9S8KHKHi00GEIiIYQiGmgwp/iLUkrVjQtCGgwmFP8apisHGi1SRRhCLiIiNCIjBDOiIiIMIRF2EL iMRNIyMQiIiItcjaKdkFZSI1BDIXibKSMtYSpItUCUtzKO1GYcGS4gQYTNeR8JqQrIONTL5CZri+ EGU7L5rZfITIPJREKZiKeL5C8g8l8iIvggZIyZZCdlXF87plGR0YQXluSiJp3ot6M7QikZT6508L aa2vmoXPfhbsh9kNoMLp5fP/w1zsdYQiMa1O8jGEWOU7hNpBvwuv2ujY0CI+6+Frpv6XdVua39/B rad1RhzvrsMOELSvvP9z+iQ/nfe873rr0Z96Ix99Ojvf3qd3O90nX/JYaBEff5oPj1vq7ItI/X3H O8OaRcKu9/6v/XmmYCTunf/8ieYCP+6/W75E8wYUnzbUGGYVfuKv/61/8X///pf31/3TX7v/9NfS +v706VDTCHF99dX9v1BE72e3zHeY1Rgr3o3fwgV//v/rU3fdD/+phzv1te/6iP6wl16+WqYW29jo 6DdhgtrullGr94++khFetr6t9DXbf2vqNC2aA7Fb63uM/xn+ETz+CHdD9aWFocaxqEKz/b/xrUaT aUaUa++s/2GEr0uvC3pNqDNz/yLj71p1vFNLC9DQ4UbxTWxQM6gVGxsV/FexTEfnTa2I4qv/hWxF BlwUMFRaEWuf8sc45T+cJFoWg1hoMIMJhDi47CYQ+MJhBoaHHhbTQtFqjSiIiLCEQeciM3RERERE REQYQiIhhCItUwnYQxERaEREREZN1pHaMguJJMlqJsSqW6rHY3FW7NbI8RQFyLnZ1yBwIMqMKRrI iKiOqNxTsjxCZqZfITITO5xCsEGQiJOIPNZFTzpFZR2KIp8vlqga57z2uFen1P5D9M6V57NYhDkz paaavrmoQ6BTscISkImdWgZqCaDJUJnslCTOkYaYWx99oER+5388FxhPrvPj/sJab+mvrrqqNbdV 0a61p+FO3CK/p+t17GE2tu/avv8kPqeO9TxRn3zvtG7P2bqNyp6ndo3dJtG7fvwRHkkCI/2+6X6V 96e/er9vRnT///W5oGEt6HciOhoVtd8TOMGFrp3/qnRnKjTd74f/uq99rr77dUt/+v//+Nw/fr/Q 98b3/vX1y1TCxof/1+seldBVQ/f9Vdf1nR9b4Pvy/a7/fca/1W39DXfW/fbpQQ3UIUtt8VghxXfS 7fTZz7s5NnO63rs9jP/XPaghx+37WWqBLNzn/EUxHDCTHN2oaXNzfVwtYVjX41jOgUORoF0NsLxh TQF/bSjn/VLf2qjqu2mmOtwZxgsGYGviqzptbFPsUtFJ+hG1X7H+yeBOr2rEVHFoMIMJhAwQ1q4t C4sLFhNDtTdn3ZyM3VGp0R2FP/w4jixTURERERZ0RERERERcRERZ0RFoQ0+ItCwgwpZKYiNCIiIi Mm62spGUiKhFcnkr7JselusMjx2kZHinacMIMjER0ma0R0prZfKeL5CZC8g4g8EGRiN0kqm0OBmr M51BwZws4YZURfITITO6ZCZC0U5ncBSD6urhDhyx2EIwQjXC3krFIYU1CJghwyWCKezpuvnTslhN hc6edNc6BU0HWWqBKuusGgnVNdfBLTRsdTuRRd/4W9clASCI5/d7nY4TdGijDUc77Rn2jdnsNJtG /Nynfc735IfN1G7WjdENI3L+53v74to77/1nzpN/Xet8RD740K7r5nGAiM9/od9sIFQv/+TxHyPK +jueIMMwl337nc78OtOSiNtz0akR0uv/f/6/+19sW78dK7/X0Ij/+P//9/Iky4X0+MzgQj3r659H TBLVz6bPq//qbv+59f26GtP+q/YRY7f9evx//6/9N9FChpxCeoadq+r6jW/ra3qDB2c8EP+ciCH2 5DwkDXqCFE4Y+7DSN/60ZOp/2NY1QjhQ1jNAXjSvS/1IYUnBewkdQpD8iYYm61eEtat1Qhd9bX0d Ao/aiGsfsUxXBMUqTFMR/x0rGgoq6wZ1Aj3Om8VC2IwZgZ90bHWrDSFs5faYU5Ggwmf7OiGmELi0 zpzkIMKYGSKDoj7CHxdhbCrHmWLFIY8REXEREREREREYIRFwwhFghcGE+GFQtYxEREREREZ5qW5l nZhlOjsrRbiUd6om6whGW6kDhMhkVbI8QmVGQzhmpG4qMlES5mIhMhMg865G8g+GRkVcYR1NM65G 87nEPIRmIqSKeL5C86svFSyESZCZT5apWqosd6udLNYlYTTOlcghHOlnTzp3n81QIoeQ/vPaadNq f1OxxFP/quSoRJ1ThqfWNFvhBudB9P2lT6/Dpvu7V9UI72U4favT6nUIrrTZKAgXXt3h6eXz1any r6oz73RIfVtTu92azvr/37dEh1Viw/nf1b6SN36+d9onGn8lZ+u8dv8xkddb+jPfdLf621enp/fn e+4YZfbpdv7dGc76G3V0dzxXeCGrVQYN/+r1xEV/S+3/76Tf//967fx31ru3+3t//1/5EgXNAXZF O//95jv1CBWXX/a2lqv79ra6of+kEXGP60kN/tDf+//rwsbEfV15z76QiKf3SjUEKv7UEKBCicMK /mgYOmEnW/vX9s5+v96tnu+cjORRd0ntpRS+xrXfDV0twk1DCVVTP/9qIXNzdVYYWbv5SgwjdhpW 3T9EUDDa/5FxvN0M0FPsUh7TFAzBLGxTWDMFjFigZgZi5gn4wZgYXWxFMU/savsVxxGrFa2sL7cX tckrCoaDCFpw0GF044tVWNUwqcamRrDTWGpj2hcXhddZaphQwpyOIiIiGEIjQiIiIMIRENNOIiIY TBNONVWIi4xERERERERERERloKcy05bmUVwKKUICKHkJEHnRmIhUEGa2YiniPHSKhl86GYynjGai JPNQyUmYzqzEayIjMZCZ0iFMxEZl87HZiIXlOZV/4jNQi+SoRPwr57X7TVBqn36aedEsggtcLZC/ fCfqkW9enCo1um1/XadJ5oujZa6bRra3bw+03JSE7IvWi4f9qfKN16ubtPTzvv532laBF/Sb+0np 6bR3/s0GdwnnHWlCf4T8twvMBCvVGAgq9CaRcKr0Ktrr76W9dd05OjaI6I6Wnq11dd+6Db+l87nf +62dV01tavX/ffr7//1100IjX3f+v9d++7Xb+vczgh+WOd9Td++eyh7/qX//j/v33/f1/7/qv6+v /+v40ONd7ZzFR7Wz3ddq30rer19ajP/26tXX1BDv79rf/BArMILa8//+2kh/YSIoGGGF7SvWf96U MK2q2kvYWGFtK6fpJ121vX+1iIp0h8tUCWr7it9ilQjYpiK9iKYqI2N1YpigxsMLEZ0jChpCxTEV 2rFVDXxjQ0Gp/i0GFMjYaaHaDCDCaF2mEwmKDVCxtNbG0DMoFDxFghERa50IQwQiIYIMEIYQiGEG CwwhDCFhAwVBhPJuoRUkIiIiIiIiIiIiJaoEqaZGs7zLcTxlulcOGagwS8VGEDKiIPITIOIOIjNW VSL5rIjIv2RqIPNIpGYiEyWZhEpyMyOiOj0QeVCJZmEdnR2dFGRTluqtOHDU6yZqCBM1iHUTNQh0 CnSTkEKOmtwZLiHT8ujNedVYTTU+kIjNQqYVTrGGmdIxJqQYYumdmDIIctyY/TWa4VcKkqdhbRra bw1+rTpu9X06CmoRO7T9B9F49JandhsNsKCD1O9G5U3P1G7zZmzU7uXBnc73Sed/M4c2e/6dXnfv zwa6LHKeqM96Rh76/80Gh0twwZHwwZHx796FXUcSfMBEh3renf/tLxBtId/f317txpuEIozlRruq danj9YpP10NDV1//pNcW9em7X69b/W//69vV+l9f7I2y4X8iTLhPqn9YRcQi4/+373Uw4Ij7/Xrv 9+9EPC/sR+v7of37f///6xH3vU7CCuRMV9WK0zm62e2zkND2e1jX/1errsIJs5k4Y7wQ/VdXPffv X00jf/am5v9jShPCdtLCmgYhpRxXxnQI6V1V9QwrqsQo2gZvthKm9Kbreh2/aSsePxSj4MjfaRao EtcLglYprVjVfVJrYxYjJwwxFQlBnCVjBmCxFfYS+1YiqC6uvz+20hjULp2hhM6LCm/N0ebswGmm Em1Cm704YTtNYYqZyojFNDjsLa3pjiNCIiIgwmhEREREMIZkIaadxEcGEItUOGg0IiItC7CiIiIi IiImEIiIiIyyiNTpmRjluZZ2JZC81svnXP8GQLKjIPITIOOmScXyEyhEfMIuzUMhcaiIwiryny+R mXzscImVBEminy+ashYQ7ojt83lWjWct1gQ7Cfa+sGa/U1pTpqdAqn0vhCI0yUrTTwuF1hppran0 qZCYTsp0R0FThbul1Wdwd24Ie6WmF+WOkbKujW0a3ra3MDDRreE/Tn3M3drCEWjQy1QNUblWQfzv u1EPv/c2X533wme9X9PT6BEfdAiPvRSHW873//ptUmx47pmgL+7aBF0CCrNM2Sow54/veu5ojaI6 I6CikG9+1bWzRHER0EC6+vYZtgw1coSpe+2ct1XRvVP/6XwYoYXpodfuLb9emhEf/9foMIRH//FS LTYTLhdbuo/NIuF3x+9ro3lR/rtXmHKH/eloV///1f9a//QXy/rvUaT6//ezmCFPjvpE4YBk0ChS EH9wQ9W9IZ//aghuvTU/3/9GJl3esNTd/Wfc5hBXn+6ufXWLofjWyH9a22tHULNz9ftbSq0m1H70 r1ogxva4/es3cEIoV7Sjtagzlq2KnRigZgneKBnBr2I9WKJwwDMEGxXsRsRUM51cR+xFVdnuSHC9 jVtLNyx2hGSGIWh+YasIXaumE0O01GwVKO11GDiPCtirQiIwTiGCdoWEIYUx7hhBhCGEGF1zHtBh C+7gwp5pqIiIiZoRERERGf4i0HETCGf4iIiMs4jTO4RiERFREr5y3WCOxTOkeiDjpkJmUYQyDzoZ iBDITIJlXkoZjKjOmVZHYHF87HCGsjt8rWQmQtEpCU7+lPan87UgqR099I1iEokzrqtmsXPqzVGJ clMXap2R4jxK8EUPNAXTIOUtUCVGt+v266MDd086iqe7WFVMIuHoNb7mCGtxEGEI6+ZqqtPVrf7z Zf6vRs1O++nReX4T6MPQIj70ju6p2RB2szlx+q2djMwEbRw03308MjojvdXhmHQ0t1aVwht+6p69 d2z0tz5Do3xpvqzl3TUGKX29+I664/3/ff3//r4qnSb8aciTLhDRlwjH+pnOP5uPGKQxuFrawvr6 tdD8wv//1/719PXukNC2aBjHVecYKepwjPd6QIb1Z79Jdf+0ucI1/c+n2puTU/0dqklr9/Nzm+dq QXqGF42NasKThhG7a8Ut6sa7pWvDBO1Hx77H86LV1/UM3AzKBVnLpQZ1IUn8RurEVS2e4atpDG2l 3fZ7sIWhEaFoeYGOg1GjdFramQmnsaaGo2KjWNrHjhhCIi0rirTQuLQiM0FQUPEMIdhBhM/2ELTW WqBKIsqcWf4iIwhENDP8REREZ+jJsLoVETsLhEpWInZr08t1IzkiRaYIcaOEPWRhZSgotJVyIyry Fop4vmsir8hbMZGZfJZmOGS6M86ZGsjEYRUKyNZ2lIR7cPPanspx2mSmCDOsEGmkdZPtdMEUPg0r C5IZg0+01UhFhU7hlRKSuL64XM5GL77BdGuq6o10YJTslARbRrZ1CQ/W1TW4PXPSdhNzpcMEMLnZ remxD++tU21O7qd2dUlb1O70kCI/paRGHToER92p4aBEfclZtq//9krNUCI/ffcEE3VvO54k+bCb kRpb+4TMKnhkfI8u5OjeR/nc7633mHPDDDL9XX1vXgwZda77o8enBhz/rf/oF7a/aYSXT11/h/Ed eEwhFe3/XXsf/pJa+xYYlCH1638iniv0/W40P35Y5Q4Ij78H1/6D8xwrX//+8x/hf//fwrof71qn //uiCGq/jQj+3ful7ba84TVDN3/9/+yGgi83X9/+EXk2GFBD6wTI4wicJs+n8EU7SthSUJZuzdtt e7CQbYwsaiG7SXjC9/3pWElu9CE7a3qxrepFxvc3au1jJQTofrEeGkhVX7xT7GDTVNKGojs5Nf9q xHEbsVWxTEVQViKhLMOUOV32THCYimRjgqvvSqGKkZIhoXF2EI0NCqGONCxtKPC2mg1TULhCLTTh xaDBDC5osRQMzWF2FNsqCEGEIzo4iGEDCmPDCaxYQuGFTiI00GnpqgdpqIiIgitCpxFoRERERERE REREZNyVHeJREi+MrqqO1WL5C4EDKjISQMpESeU8XyEjoENREmrO55Gs1kVGSnIHkpZiIWjXlWjC KvIRHdEdnzuilcsSa5KAqedAsGU8gzr65qESTThkRGHn+0zp51i7U9msXyUpOwnZqJVOuYaZCZEw XT3hb0a98zkelO7W1mBlwzUJB4TVaRrfap1gtNq+uEPTTJR/R24TvO95s03U2RDpTu90d7ovPCbW Zw6mHu/T/U4++SfT/oER+5nKHW879+eCb1//T7mmYCU4JUr//CFsuW6M5URBvp7zTNoj6r70r+jB f763xDql3/UE2jeiuBX/xbXTUW0C661/il6v/29MIR1f9Nt7/vpfTZmC9K/mkXCir0K/X9+pnO/f 11f7r72zogv6HXfr6x/69+P9f/93BEQe+q6jQ6gyYY6BCv3PaOEr+mEFr4z/egQq+ls9+CFf/Mje oJkcbz/fc+noVfRKAsNLzoHOiVpe9KOz6tJ/iFFKjdvsJbGs3ScMWF99I6hfY6Qof1hqwrCYjpj+ EhWoMygRrZdKw144TS79mgYDLCJa1YpkxzjguI0voKyQ4L4aSFjBn2lBTK0PMDI1apqbsRsULUIW msa2hf5uKiGEGhHDUkOCHawaEdiviIMEIwQuGE0+GEwnERFGPcRFoWgwsWFPsT4an9RERERn+Ii0 IiIiIiIiMt1WOylGvIWiGhESut8rlHZWMi5w0GQLRGOUPKfITISITIPNZEgzkask4vkIiDRVxBxC kQvIRHYojozFZJmRhnZCOuTYUXKFDV+RKj/iMnVkPU1BF09tT6XOmmdJBnUKdREzpF3nRKQuX4MJ p3JEh9uW51wJ1L9sPp2dwfshIp+6vaNbafTC69qknqmdQl2SkJ7w0XDRofIQLrv/O4PSsQ13Pn37 n71T1fzvt3pAiPTZReKqnfq6XCsp3TpN88N1/+DDIlmB9YJb7/+ommbyPKaZtEdKlaTt67/VO4bh CRRHlv2jDnj87nf7hhpXT46zvv/yKYcVugvXd/fTQjTCEe/vVf/9eEwQtJevfXbIlFwq7ItL+UqL hQixY0UtyvUGLEYXRY7v9LsV9f/19D//8e9Lr+//99f/+1/Xk0QReRo9OkS7Jww9AhghTZzFG+M/ 7q0lvU0DGvuew1P++vzQMP7z/8ETvral6p/27P29ZkYMvKFP8MKdVbVrVRf+2razdfqopToFNAwN 2xr31+P2EjoN26dLHwYMVf6+1wutikKBmCCgZgZwl1+Khgl3EbKHM5ReqS10tvTJwUW7X2OF2sX6 nTC6t6/3hY4akadNPzdFxw0GKaoNC4jUuoyI4uMYOLsb7ChYYpDp4gh2IpriI4izqgLcREWEGEIh gsWELiIYWLCFwYTWwpnKyNQTTQjERERERERERERGhBxghGTYXybiIT+Iy3MtSqRfITISNcR4p4vk JlPF8hMqEdWYyKRUI5l2QedQhCIg0SrJPMI7B5VURtHY4Q65zJUiTMi6OwildVyaLhhc6dnURXXN Qi51VqldGEZoIRRqESOqTIbCappqmmQeqDtT6TTTK4FyuWhE+DXvULraYW086BP001WcG/Tz0r5f PVH/OoSYIvtGh0Xj0dmoUrgxNdzOHO+90bs77R3ujcp3+/T/s8Gui7ru1O/0d/X3ulSTfpN/60Yc 79xBhrv9D7/4rv6MOeNXtUNPCFs5PpdkQn1879+/k6VGc77Pdd9P+jekYc7rW2+9e/pf/Ve/X/3a 3sf6ug762+/b0y4XrY93/2noa2/6qRdAl6qt36+3//37EVvpL9cOP12I416Tb/j+01v/+CFJhK+g Qps5vq/2c71Jwx73XrZ7nGDvSYaX07qGp/2+jA2kvsRufX//iCdV0P0r0kNvqrbVtQZutpR9Mahu brerQZbnHzdFVf6bWeyh9qHQYX723gzAoTEYMwNsRsR7EYZYTdMV22F7OQM0AqUGquIoWh63/Wz3 Hi7aTN0pQY7q1HUJhc/phNT/YQcY2hqKn7G4i4vTVP4vxUbC9jadPY4tO0LQiDCBhO4MKg0IhhU/ QiIYQiIiLWDCF2EOzoi1ERERERMIRERn9CIz/ERERGmImR8RlctR3WiUZWEREXyni+dcjeQiOoUh M6Z3VkLRUZ0ZiITITIOIRWViOmVnIREtRhFTRC87oqaan0ShhNcLqezWInSqeztxEzUJ5qENYp0C rDJSC+QoKmQcE7ITUlOR5SE0zufo9enpra/a6MN/CThdtMKlwdKev1+0I8lIQml969qd2jvdGfb6 Nmv+bPNmE6LxSxyh8w5Q5Q/Kc5nLi/MOU99AiP30iQ6173lKR723S3/r70hNM2iPbBmI0zNK+k5K UtB14QoIRoRfBgxhN29CHOqXrcnXsEG9G/vfCYIelrr/u9aYQjjTLhb8SJyHi/12aBhkXU1V3/NA XNAXS8KXCmjLhNycMY14/i+t/9UN60WOE/G//3YvhYfxjfX/6jr/VhI/1vX1vpbPYz/oRRurZ5NT /s92rZzc9qjIhF5h+vOjOjf8/2p/3Me9pZoKHjfN1jSvp1WbnHd59bzdix8nDFpRxnQJ50LbtUbp KAn9vpD4+SkJvDMMEPQv39KxHEV69Nq/Wvqxqqv1kRNpPr/xr/a6odfHHFphBoam+OhY783IeY8M Kbs3ZhrCxYqnmcpJHYod6kYafBmawuIiIiGCFqhxEWnGmhadp2hp2hGhEQwqF5xtTztREZ5oRERE RERERERERGVwVCJ2dFuB8rlYh2+VOL53SIPOzoqEVGTooynSkLRCZUIhERmXzWRGEamYypJMg8pE YRKo3msiV52JxvO8jsNFcDVNT6XO4EIfqaxFQycMJmoQKdEmF001slCuHhO09NSs6qVGEGqdG96h bC9nZqECuq4SOoRPW0a2jXaeHsPPS7VouHnslH7eix2dmoUrl/0/zvdF5/mzs8Guzwa+i8aW6BEf enq6usp3ugRH7Sem++4XoIP79t7/od0dzxSEnRfL6jTjTku6oZ3O9+vW1bSfsMHfW9XTv/v1c3fr t1X//0hEaTaV5my4TXv/6ev92RUdf/2/fycMK9ff0NP31+79f9d9//16/VY3//QYS19axb6+r62c gQr3bOc5G+6w1P9s5/k4Y/ur20gQoIu6/3WqGCKHgt8x9+CKHBgih+Obt9R1baxfuk6iN3H/V6Ta tra0dBvO5h/pNq2lM7iK13dTt0FQiK9WxGoM+z7pdYawwl69qydgmI4q0mKZblDF4uxGxRQD56hM VXDSBCmSHWY96YU3LGObouxCYoam67FA4tNMUwg4wXW00tYM6mn2KhA0NoREMIRcMJoRDQaFpxaw wgwgwh3xFhBgpcHti1iNNTrgeIiIiIiIiIiIiMELQiIiMmwtiMrgqO9KytIlQyrzqzEdcqyJPJXm EQkSvMI65G0QmVCITNeYRqyNZCIqSJZmEVGdESRGEVaO4MlqOItxZUzvAkNOzUv1PpNQmmaAunem dFa6dqfWmQcqpnQapkagqkZhSVxfTBNM7phMv9YMlgRGtp9N6ouHq9BfPTp94X1zqENQhDrCvFZ6 OoQLYQwtot21nbiLfmzM4ek+3T9wm3nfzwa87/f3rnH3+kEt4Ij+jOcf6SBEfdUCI+6CbptUCI+/ 3EGGjOVGm/Xelc0zaLoEUPS7Gm17vJ0vk6BFPNSLpd98oXO5UZ3O99Jvxd3nHM+m9G/X0/ok+r+0 29L+1/fWmhEf6vW76ZcK+EyOFNGEI0t7wpcL3ft/9tN2qtet0P/q873/45F0Evb1TV+O///9Y/+v /WP/f//x4PpNv6///76+qYJf3QIequoo3bqn76VqfpOGA8/w1P/9Wp/r/5OGOq0K39rbPr/3/f/n eBYgm21bWoaU/7S97W1f0bo70PY+2tTZH3/+m7U6BZn396wyOgn62trt969KFxxQMygfbG7xFNhK I99QZgeviKp/7XtWUOawURpZ6e1YikIpiKbSYYSvViK8wKELQaoMJ6YQ7TFBhNYu444fx9inYxcW FNYJr4p4Ij7THFPFNWmmmEGCcREMIQwTCDCERoRYIREWELCwwmhFoWmFP9phBghaaiIiIiIiIiIi IiIiIiIybC4yypdK6qjs1ZiCDO3yrIjCIwirzrlWRryNZ0yMRRGvMIhM65G8g8hEVJHXIQIQcQmd uZLogiJhGETLp+jc1PaaaZ19T2mp7Oi1PpCgnZ0V6kP0zpF2qntInBc1ikozDCYTL6n0E7JRGJZX LPp6D9o90a2jW/7Rrfw/T/vz+/nSfTNQlaMnQVNOaGv2vp5fP/erSt9W6em+/pv6t+eDXRx/vr91 1O9feZzXRb6nek6BEfv0CI/6BEer/q+9vTq3vu26u/9406vf25Ol37XtGHO++zkNNwgeluut70u6 p/y2EL/+//r+6X3++rdb+3hMuF/6V63b491Hp1tffrf+//v6oV5j9/VDfj6Qr//Q39euv+Ovf1fr 4ML+vsZhKMEPSuk213XwQpdVBDvW9InDG1P0EKBDvS+1nCezy+ujG36H6v8R0rVtZu2ktpWtTc7S m7SN1tJ/qfoq6VMfbfN3tYuNbX9KZzj76ilB7JDpimDCXoRsbFBlg1mgYrDMD7axGyhzA+6gzFyh zhEr3Veem0tpWNYjoXY1dWf8GhaYoWthNNC1fuOxCDCF2nF3HFRj+NikbouENr2KGv4gwhnRDCDC cZjxFxaYWIi7iGhFWmnGaCrhoXDCERiJJMRERERERERZ/iItCDiIybpER0FERGVwrMI7jMIEIop4 vkLiEyXRV5UZrzCKkiMy+dGVIyTyDyEyJxFMheQiOxNELRUdVTtILkrENQh0wnqmmdcw0wvBlPGI JlOJ9FCNQQlQiZ2kwQJM6RiNeCBJlPKdpWdz4W15lGwoVNOzqECvaZ1EXkLpTmhhTqJ5etVcEI9M IRghnaqIdjiYIj7o770d7z8ps1O/SnfpTvVAiP2yr6BEeSbl3X65oou/pI70kSHhJaTf7sMjojtf UUhpbNM2Enc717pbnHPGvFKqenQQozlRX+geE0T6o3p+5uc88454ow539dL4j/360wku3W/Tq9ru EC/96XNGRwv/42XC0KW7viv1uV0l/v0WOZP9/35McER/X/9e3////v4jG/29LHerb+4Ptb6VD62c 7PcaQwQ7v3pX1++kDB6X9nv3YU/37PJqfufV/dn1v+971/z6vqMnBdpe/3SVjV//OquNbU0Be21H wZ/nUJFirnYjRFHbGkdApOGG/3VuxFMRsGFYjT9f44iqXjYjQ3VhhL4r/S3VCPWl9bvK41WmEhsK blOiLQ0LQaFoWmpGrTFTHjjvzApujydlDwwuYcFLHKc45T+OoobCDCljsRFxEQwmELBBgplQJoQw hEaaaGCEGhGhhCI4tC1EYRmhERERERERERERiJUkdq8so1yuq5kKkVcaGR0RxndKyrI1MgeaiNaP 5CZCZ0yEZiITJCPIxlOjCJSzeQkdmMwiEjooZBxvKhEtRNlJSuCtSlswaZTiIRnbiQ04MjAiaaZ0 WahJDh+whGE77NAXIOVM0DCZHzCI6tVtMvlPF8hed01hDVNGthZorBo1uQulGt3S6w6bpIL/RqCB X4iIcPbOnhcLZF+yafn+iY+kaNPP1qfKN2eA6eVmbNN2vaLHKfJjljun2eD5nfwnng10oIj3PBcW CI8dXCftAiP3BEfe/vXBDCptK1EUnoRBtbEJU+7BAhBF1vCEYQcP5pEdEdF0o7ft9jTc7nek9jCb n62GD/et0vp/t//u+3/oE+uND61/xERpWl++/t6vuu7ItN///+7+/7X1shEF8wsW3/V9v9f/1XX/ Vf9etf//1gwtz3pL1ZyunPaoJ6UGTCdSHpl0CFWe9b1mRur0rp9/2qf/CLv4IpwwS//sLpIeOOm1 JwXbVDiFDXzoFuolQLqO6phpe6vq2tr/etq/mg3hrEd63qRMMAhzOcfVwsVxXCiM0C0x7TLwLbCj G/DCURsVYS7ViKsJWFGFsVJDgoimOmqoXzQUPBhKGp0INT/hLI05lCpsOM/WKDCHDFMJhBihYpoM UxULDQNCGmKBn3Q64H9CHEQwVCGE4tTIcyoCap6aDCEWEGELCaDCYQYTWLsJrxGIiIiIi0IiIiIi IiIiIiIjLLiErlClctRkVxGshMl8h5HyOiOkzURV5UI1ka8qCJNFPF0U5kmjrknmMkakHk+RrMIq MhEU5lTyERLUYRGI2ioyFoqMmwNGFTPLPZ1WahDrJoREUmU4iaantNNbCdqfSahDNQuUJUzWKdEm EyWCmoQg4J2mprPJZJkYlIVHc8FUtILXvtO109GthTqIjW60a3heaHumFeYdBcvWFcLfNDCrhcLY QwQzqEJSEOxxFsf/ujdqd3PBspPPyWnvpup32k3/O/pnxzQCI91wRHtE47pNondFxqd/BEfeW9Ex 6pKgRH3+drDevoUtxpum1GdzvW31c0R9AinrvTmpLbpdjukLX6T2gTX08EKCH+0m+EDwQNT/RnKi jDnfX2/vf//+l26e99BghHXrmgLv+6V0P+r4+v5rZcIlvr/jjS9b/ePjVW7S19b/1j/RGP/f0P/2 4j9X/99f+sW/9v9equoIVZzfV1umzyf7pdRm7el85H9K/Pp9qrPYIb7Z9WeTU3b131s8rPLv+3fz /GbnSHGle2sX+2s3YaXvra3o3WHq6RoGAZ/2qxpWkRQMRY9v1ep1CkT0LJxU7f/vX9YMwO0rFRS8 cVWTg9WxFMMJUu8RUMJX7EVhlwU6bCr/EbEUkhofrbexFFpBa+Nc/xYRHTQam6LQafUapihdrDTF ToXtI3Q4ixUyKNyGg01NBQuXZh8zlDlD3imopoYiIiIiGCDBCIYQMIRmOxEMIREQwhcRDCaa2E07 TiwgwmhhCHoRPYtC0GFJuXhERERERERERERERERERpyuFZ2ZqikGVaITKjIZmMjIvnVmI1kVeQiJ 4gRGpmIqMhEdIjaINFOR2KoiplZyoR2DM7mIduLTI8mglC2va/rp0YSfqnntbTNWYZCR0jEakmmQ ONQp00yHGGVEpGtMJlcaoX3MIj6NjOoTOoRhOF6bRrDOnnUTTPSNbps6hDqErOoQh2jW00zqE075 kFawna6msSCJ0dKwi/o3srg/ow6f0Mx1a6S877rS+1/p6dJK+qunqd6Wju1elSljlP0tAiPLVu9X TavpvOy0iO/atXngqJPmAqM531a7q9P87lR2tbXnc70Zzv9GHO/dekrncqNb/87lRQQtWtU6MOeO v0+75aQUv6EavX66de3vX//rt61T/7ftt9bf1f63/vxr+IMQX9fZHH/6/j/mcse//7ejX/1/f8wu u+I731/+P/X/f21/37beEv/xFet//rxB4jdfxw2/t1eutrYIf7ula/v6/YIVdRpfuuThieC3/59E 5W/+3M5Q5Q7BFDyPhevBMj4Xer92lba//DV9KGk3XT+DN21tJ//n/bdba0r/FJUou/mgLxIug+76 ETmhEUxxoRViKvnOmPiq+NiojYqIwZwmOrNAwx8fH3xhmUMJOva0rKHM5Q4L+10XBTtoLuvsm6Tw YVoRp2ELjQtNBhNLi0+rCdp2uhp2KGqYocXEYMdiprKcodNCf2FtRUl6BxZzqY9nafhhCIYIRDCF lAhj3YQjMiIsIWEIhhYYQiwh2xaoRDiIiLWOLtPxERhNCLTiIiIiynQiIsocIRERiIiIiMrqqLZS umWyqiyuWeF7ok/53zII5/X/x//BD3s90hGOyhy3KdcWhFGc4/tCGoiOV1XLZW1K4KKVuIK7hZGV g+iT4c7g/PuD2RisMitgf8MPBstdTi4XeT2D/c9441P/H4/W7/N3x7W0IxES2FNURWnhXVc7miFc g7SNCuUWnc2P+9NX68EFjK2GCJguIRbTz68/lPmPmQ2D477qWup4MHXu/2/9fFFpKSiIiIyEacTN M4yA6Jrx5AdE1H/kB0TXjkB0SUeQHRJR8gOiajkB0SUcgOiapRkB0TVLxkB0SUgLlK4jkB0SXjkB 0TUIIYyA6JqMgOiaj5AdE1H///////////////////+Uxaj+QHRNR////5a1rx//////8rgfqP/8 gOiaj5AdE1HkB0TUcAEAEADomgplbmRzdHJlYW0gCmVuZG9iago0MCAwIG9iago2MzU2OAplbmRv YmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MSAwIFIgPj4Kc3RyZWFtCnEgNTk1IDAgMCA4NDEgMC4w MCAwLjAwIGNtICAxIGcgL09iajM4IERvIFEKZW5kc3RyZWFtCgplbmRvYmoKNDEgMCBvYmoKNDMK ZW5kb2JqCjQyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9NZWRpYUJveCBbMCAwIDU5NSA4NDFdCi9D cm9wQm94IFswIDAgNTk1IDg0MV0KL1BhcmVudCAyIDAgUgogL1JvdGF0ZSAwIC9SZXNvdXJjZXMg PDwKL1Byb2NTZXQgWy9QREYgL0ltYWdlQyAvSW1hZ2VCIC9JbWFnZUldCi9YT2JqZWN0IDw8Ci9P Ymo0MyA0MyAwIFIgICA+Pgo+PgovQ29udGVudHMgWyA0NCAwIFIgIF0KPj4KZW5kb2JqCjQzIDAg b2JqCjw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvT2JqNDMgL1dpZHRo IDI0ODAgL0hlaWdodCAzNTA3IC9Db2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1 ZSAvQml0c1BlckNvbXBvbmVudCAxIC9MZW5ndGggNDUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVj b2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAvQ29sdW1ucyAyNDgwID4+ID4+IHN0cmVhbQr///kB 1It3jkB0x6j/yA6BLx///yA6BLx//////////5AdA1H///////kBwTUgOATGwo//////////+TYm vEtcGvH/////kB0DUf///LKoW4lrJ7Uf////////////////////kB0DUf/yA6BqP5AdA1H//kB0 DUf5AdA1HIDoGo8gOgaj+QHQNR///IDoGo/kB0DUf5AdA1HyA6BqPyA6BqTdKQyuFjsshbkLy3KF BB/p5eP/oIN/vScpYZzwZzwZzwEHwINA/qWuoRDX//yyCYcnDOZghOBB8CD4MGYMGYMHwIPgQfAg +DB8GDMIRxmYpfFfiIiJ0937u0+9bjiy3JgQNtcshbidMRJfZTlWdyh0zwZynKHCZVlQViZWgTKc oc45Q5Q5Q6ZhyQ5Q9mHJD5GOSHsjH9ivxEREREREREREREREREREREROmM+mwv/4/rVR9xGIjIDo GpXW0ZGkWQtQ0+yF5bi/9VstxPN+v8INByuWhj/QIEIIjxaRYq7/CYTfZnK/r/uPH///f/63r/tO oi++xHFqsM0BFpAiiIiI5XCyK9xXG6CB5XJiFvOIVFuL5a6tZMcod4X7LcTE6BCDfNl/CY0ndIf0 X79rq/Cb9b6+5aRWravZ7f/GxSlcYC6/ra/9hpSup5HTzH/xURFpp3wwoiIiMsoqpN0rOyaLojoj ojmdhbMcrhUelQiI+y3pEKi3KMtdQoTb0qb9TKsyPmQzGgRHq2eD4699K/CbvFJ93XgiPv1b/1/0 m/7bT9+v62ZWGC0itXbVbp//6/DYvdYYSf9rmPG2/FMa/er9oNO0wv2Ir4iIYQu+/xERDBCMS1XU m6VnYvjXO1rLecQqLcoRlV/O1IJ6dl8uvpfxEm1Q87A0R9Z3Ki/t87VhhbtX58PG/7uuk91nRf9/ v//r///tde17juxX7aQlqLSiItO/GMREQwoyutR2JZ3RFPnYlmEVLKUzZlNmildUEO1fZNO1TTJU ItlvTKjL5T5blCGF/3CWsIHwtqmZKMyIZH6Lgofv6wRH3RcadVfzKsRb0LX7ek3aCDWYP0CL++qT 6H9X18eleu10Yc46gi/716X6fa11/rDaXdz6OwYYBD9rs8v/ar/9fF1W3rF4TCKH/7/3vRaRWqgz b8tRiK4iPbVJf6vxzddp2psy3KHOP4j+29jXTTuLChNQhENO17UbFRERERERERFphFpAiiIyut52 JR3PNaOylErOV1IKdpBDtxU1CZNhGRBmMp8kmZDFSUL6Lh9WpBFZ38dmqs7NUfzVGReMkRaSmszl D0bKLcof9Otenk09PXzLVpyDtJaxD0MIR1pvp3337u/tvTfudqGRwvv6/++/CRnzQaJaQuo/a+v9 7/11/VpBv/Z7c9uwpuvrdP/6//VdjK6kFjjxrtJ31JUGAQwQoERB///S1X21Wwl0lxXH3+YcrY2f s2cditjwZt4UOZz7cibNTjmcLaVwk1aEQ7QcRadhPi4hn3OO0sYxERERFr6aFhNFpFqlcEy3KTER ERBgh52V5dHeZhFOqHhbVNOEUqJsnyBZryS53RHdEd0WQ+wLYTf9SDEUhQh24p26LpM7dJnWMgeZ CMtIrVBoER95x/5c/XUKhFBDzLVhNRs9Ner77mP0Xl0YcqKLcoeq/ZkcJw3/W2vWROLhOEOkLUIX Ruo3rhIz///r7X/rjjjQ/WjOVH//VPp9T83t3+/+l+t6t+sRiurntbPdntz6f//ieJiKiK5GP/Q+ O1tOznx/2WkVKrTvOiP+saFIXtLbdDYQYQYVCLTzZeWOd8w//V44iIiIiLCEaGeeeaaFhC1JsB53 PEREREWi0i1SbAwh2ahBGlmvMgmTYZlRkGs2/MomWvahMjyZCmXzuIvncMvnbsvmqMk8XzKZarV9 J9bW119O+2cmz3+d98ER/0CI+6BEf119J0aHjjd9N0m/r0t533O+9Ai66swqWv/96/+u679Xe959 zMo6/rTv/9fX+tflpFa9OZIB3Xa1/3/X//Vcdnts9rQ7f/rqrfTevtbEeNDzLX4iuNJiKjWNLbVf 7W7ThitimK4ipz8/qf4iIYQsIGCYTTQaoYiIiIiIgwhk2A8s6nHc87nndMZbpcYjUQUlKNxCRqjs XyF530W9EQaOzhDscQ7HCHY7CmQFlGWoZroOMJhM6BfJUITQImmfRqkgqQQo1UY9GHzDp/fS3pdG 3M2/NYJFjgiOv1TdH1U7uf/okPIPR/rfvWNCOyfzLM6f37S39TtWGJ3umo/+f8/ufTn1t6/1H0sf Vdvd2/Y2OLi8GDfUtIoX679vZ7Ky//2EC9LqsNixjjzqEY0jUiOgr4v+1Z7VCPRtzNvzb81gv7Sp UoQil/8Y3mHMP3rxwkMVljgmlhdfGq0L+f8/59OfWCBHuMIRGcnHFqbv7xxsGCcMJ6XERERERGvQ 0OkOKN2bMznHVDybA85ncI2jslhERoRZUikpGTbNNSF4J2U+gyVZVxfJURbkIREft21ahPP66Dsh GR415EZuJdF4gmVEQTKuJblXGrLXUL0/T81vVbRccJa2EzqFIuwmdQpF2mdQpKJBnQKo+ul3Sf0d 7wm1t/giPpVdafr8t1iLheyJZgJV9W2/++jx+qubtTvn61O7mzU7ubOWuoX+k73X7X9f+3Xd29L2 0len96fHz/vdG5Wr3SH/7/XXj/Y/WLaXu3x91Gt0t+vV1+tW1/6/+0lH/xV3DVbVG531dLfvFJLH rGkrHS+tprYhbFPsRsexFLSZDCtKdArSnUJqdQnFwwQtBp2qdpp33qmlhOqTWlxEREREQwQhhNCL PuZ1lTEqmUYiIiIi0Mm3Ip47+GTYdKEGVKQZGZ2B5VMvnc0W5hS3MgiLHZKhAmqnsLnSLmmW86yB RMR0ZiIXnRmIhedDMZUkdWYzXGSjqgg2s1v9fX8vn//977TW/z/3RupP+gRH26ndu6/9N9XTCfaf +NdD3v1/uv/9P0990lf/7p3v//IlFwqv7nWLhFyJRgJ5E8wEVyJo2iOlp/5mvfVY///e/1/tfTWs JoR/mSAxhhbWzm3WvrFYz/2I1aRub9TDlDlP+phyhyn2v36y3WAXbSIoC9rzdvrVdXcftRoR7xoR 3oNI3dLmR7HsV1sRtK/hn+vthL2wl8MKPtr/nIsKdCad9oaFX/a2K9ivYp7Yr1iIiIiIiI0IuLTC HaHYQ01i5ahmoiIiIiIi4ybAed0Qy3WSIwZfUihFOZhBTXnYuiVkdnXQj4jU7AtNMhIi6TLemQkX ynyYjUMqWahlSzWRUs1kRmZJzwRPzQpznOZ/bo1s6iJ6p2pLhEyVCJkrFTJWKmqetqfH8Kfr1067 ur6o2VmiE0a2FRrejQ94pP2K67fc7lR9UZ16N+rRupNovFTzW6fSbx/FVfr622+9Xvir0NPCFbSF W+n//v17/66+//9P1/50b5zu6UEPox/ghvta7/7fv/3919tem1/0lv+znq2e789tpWeTa/W+K2mK cGcLEfasm5TfWxa51Be0iKBhwpEwxakUDFpba4MQ1JK1+LFA47FexrDSThqk2vaXHDCF50Wq2E86 LCmRYpnQgxCmPitii1TVRERGhERERBhC4YVC004YTTQy0EDEmwLiIiIiIjJulZ2L6DIhkqjGp3Rc 7GhEbGSGmtlufIjU15qIiER0mRQiBxFCI1EUMjUakZVrqkHQlP21CaS4QjU1gupThhSnDCa1mzVz vbhehC50FHLHTOgqimQVTBE6/P/QTpOrXvzwvuFNlJWVZ7umzwa9LPBr/3x+t/fa9Rq7xSDfQ0/Y 0/f7v//64rdj+Nbikm9v7nt19fVc3va6/0//a1jtKIa2k/6znvs5/zn2szlOcfa6H1YYSjY9iP+1 rte26oRbeuRj7zQUPY5nKcocoe0q+7DCSewwktWF6hhef8aEQwQiItC7Oe8krFQYsVI1YqSViv4i IiI7TbCdhbCaHiIiGCEMER0IjJulZ2NmIj0GdreW9Mhf0W7O1MTUtxeMlH4QcJL5lrrLdZRjI+XR eM0R8wjaI6KESFrzjmfv70IiLQiIgwhBngzngINASm97df7tPXWvv/3ERETp3X6v9d/9//wwl364 IfY3Y1+uGELTvgztVWIiItctAsQjJulI7MR7IthOmnaouAy3SsheW4vXpvL5/QQf8yUdaetab9zK sQtQzV6v9X/Uf971luSWXRHRRkdF4jojovlCzCJCPojo2tG7+mNb4iOIiItCLQiLPgQfAg+BB4M5 4CD4EHwIPgwfAg+BBmCUP+Kdet/3/X/9qDd0W6VidcRERERINCDKSGlq6sMJM/WGF8Rdz32K3Yr9 DiGEIsL14iO8/4iIy0VUm6VhBkhFCIJFujIWqosdppkXk1TLcXjJOV0EHp9P8J+m/qeJ1R9b81v/ H+Ewm/pP//79ev/Of+17/+1+K9r/6tpW+FEVXvvFe1/uug0IiwnfioiIi01LKYMRhBnY45N0rCJw wgyFxEZXVMha8JtF4yUBTpJ6Zbi8ZEM9VSDwg6Wn/9615u1O7V+m/3291u69P16cXVf9fvX7de// bWPjVV/rDSyLhdL91uxUtyhyooJr/tLQaERaZwNO+yQ+IiIjWxURDBRk3Ss7JokIlcXzvkREXyup ZUl7VcmkEGvhTILjtUv63qv5kUz9fR3vU8NHfavV94///d///6+l6rv1nwq/7//v/8f1j29X9Lv8 dUF+tQQ/+xtbEa9fEQwhaa8GbaViIgwTTVcRERllJilU5N0rTIsZdEdBTVF8heQiK6mqo2NCIoLk qETUheZBWdkkZDB+g3LH9rqpkUtB73SdhM+UCI+6N1/1zJR/xSuvoSdLvU7v/6v/plwjrS+ZI/+/ /679P31kY//7PbU3VX/+8dpXpRj2/Glx+YcmPY2I9/3X/CEHaan+P7C+Y+IiGUoBUI7Q11xERERf iMm6VmVZFXkry/0GahAuQmV1LIXmSmjtUzLV+aKrZDrVTIsRHKwn0m0bKBEffd9D54fp6Gv9cLq5 atr/r7/zwVH7MY///39fqv3tnt/JyI4q/t//dTQMXrFb/8WvilYimUOZyhwWttrx9qY9oXEX3iuX 2IYTQhhVuL7CB4iIiIiIy0Tyjk2zO55K+Mg0d0RZgvy3S/OzVWuQ0mReMSZXC8heZFJmM7Vdfae8 l2/T1Xs7NUf7MtGl/8NvvoER7fhOneqXffBhj9U+v3+gRcvtedjRBh/+aRcK/XvpQuqa4IH/+qW+ 7/tS3WQwCFYRKwwSMIEPXDU3V/r6zatVoEDYQK6ilHt9tIpYP/cGfczKeEHQSyhzOUCVfVbX7BFD 19Yihi4jQ/sUDMpYiOIjuIu7X+dEREWhZSMm1oRERlulnDOzVmIledmDMjX/+p2tikJlcLyF5kpo 7VVhPT6NDCqqpk0i7T1dWtWYSJjlD6+kL+6u+8OCFrd9nc7///1iTguq/39X//rzIUZHCpb+614j s8p0X6/+wwsNL4vvxn+2l9imK5qf1/jS7CDCxeeDjx3/peIiOLQ7jj8sphiIiIjCBy3NGR47dl8l eiY7JZF8g4lIyrRXUurr6BBtc1CJp5CoyUs7oiVRkM6BEftAiP2qQdbVGxnURcyKfO3Fwpepb1u9 aBEfdG7uv+F19f/919DXO5UXfuSH6BEff+v///rdqvozp+v/v/1//77/S//b0vXbXdbPd7+/1bbf /jWNLhpNrUbhL/UEP/37FMexxHx8a9P/esMIMFsJhT9YQtPgz7pitiKiIiIiDTBEdU1i+1EREREQ wpZQmT4ybpXGQvIPIoZyKjLcTXyVCdZ1ClcKrMlLOzVmMleZK+W5kHJmHVl/C9NpfrdmVYhkn5br EgysaDcMPm7082XXafX3Ohps53hgxoTRG8j6pdOr9Xou/rd68PpoR+LbqZCoYV+EH4+Kb6/3/7/i ZYGP/hBHFZ7Gf7r7zucc44Ij+v//UEEpEwX+0jqFXURH67Pc6P/dIwXqwYVLXu1zJAYb7u18cyIu xCmXWrtUxWvxERGRRyh4iIMIfF2ubihyh/50REREWhERGTYfO6IRGV1NggYIGSzMgmdhIni3WSlc FCzDtOzLTtjK5bkL7Mk+dzyVZkrVBpB0bNHauJEvqpMRlQLdmWqTMk/mpSbq+DBXeaz3f/036TdO r4YhfTf5rXP2v/X7+DBf266vuUtH1737W1/H1xf1HCZcJ9GWBi+9WlmSAw9bxTev/ioYWwu1rrqM 3cEOY+wiaBgpQYwZ9jYarznZlQL/T8GCTv2K3+qvlDluVJHizkZyI0GE/8+61i0PxOQiInfoRERE RoRggzuBQTLItIYRNwwmSzKojtSRpZNicZCDCcrrfCBtF80yWyDBDhFuXyF4TQo7miV/SeE7WnVH EqwRHkTHBEdHY6uy3ExPTat9TvZVnzhBmE7pNwhFPwnK4IjeC/Wv2K31etOb8+u9F+6Ea/ukr0+1 q/q2u/CbyHHutr9f///G1+9nRunrb0viN1/SVdfewwtheNbX3iOfeCt1+xTFW0rDCUw5XVX/hpXF hNULTFCI/OhQZcwZlKxUQYIGdcCCdxGKfDURER6EZai3z/GV1XK+ZC4uiF5KIq8lJkIlEa2qZKha Cl9NMvl0V1PIXkQkiuBola9BXCeeluZBWgiSXBKhBhJNMy1zJIvzvubFugRH3pZCD11Srz+Zcaf/ dIW+m/5+tvo0CF+sP+l/+vH771X26PDf7euh9et+vlcuGN/D//pz3/zDlDlDlDlD39fo5/aqw/96 xz/vWhERfr/tZ0dDd/7EUvsRX2o/EV/MPtj+1N2tqSUCn776P7bxEMJpxEMLYW854/7bxERERERE RERyulI7pnc8leSpFESkiWmVeRWOGQiqdmvnZqr0KTCZTihc14TK4XkLzIsI7QjI0v2n3o1uaGFo HCHqmdjhCVRBUYgg/vvU8GvTpNok+FqujQ1wmmix3X38abW6ef1mD0b16QeYc7+kCI8gg3K5aC/1 6vv+P+LvXQv1T0/1Vf9f9hbqu27//5kQQoEK3V6vs8v8+n9Rv//9fdWusXDQ4MJ73S//6wZ9zMpN sLYSYYS40NVbU7NQvFd8fdpiExsVM5T5hyrKfLH/FJbhWwlF6FoMEGFQu0Iu0f3d5IcFtccRERER EREQYIRERDCiMrqpnZEdzyVZCiKmiKZFUTceK4tQmd4Idjiaa6kTyjIOK4XkL7MiedjhDsIjsDWa GFXRcPy+ev/WGZViJEqoZhF0nSbReUbPC9L/39hpoyliJPdUvn/TwhSHVvvdfVcqDReL26/+/uRt lwn5nFwsZpFwu4MOE7nvRsPH/5hX7+rGRxf+n5FlkY+vvzKr2ttnOz36tTdjef86NT89Qi33+3v6 d0li4+0h8GXkfvFX8iEEnc9zqX7iODxaqttpdtf/quhCdD+0qduhzdm7TGNU47WP8F+eu1cGf4PR blQUOUPEWhFhCI0ItO9czlPQrYx8bCERaEREREWhHEMIaiIzdEZXUs7Di+d3l0SzJUZyKkjKmI9c Lf5KUp3PQMrkuQvIMufwut3Ta52ahIPVMt6RJP877QIj/UJ7umVYa6NbyCiFck9671v7e6MOd42/ TeF79ev/11thFrqt9+SHXj/f/XX9JdfneGyuUhit//9AhX7brr/9Gc73wleknDX/Bk1wvvX/NxUe LsRsRu2EmTHMOF3k00t7X/x78JqmKDiIsaEJVOoY+9+InfIMEIYTTUE/7sfxMITaERYIRnQ2haEa YUyW8RaEZbmQU7NQhK1Z3UinhJuTUrqkkkp2L8MpMKEGV1PIXmSlndEn5t+ZTnY0JDNfZKAiLHep kWCncYIEpKokmw/vqSx7qgg64UIRfw+56z1zjniGD+eerfRd0vBh+OPSfbI/6ir70HRv+G/Cr10P 3/WhoclIYDBl10bczqb9sIuIIp62/+3rF+vttSLjDxG2btfbPrPrmPCLhds9We9/QXCQ4aS5kK4R FHcML7nagV+hx1UUwsGcFsV6EUUoMdcF39xDVez/ad5Y53KH+/CuM81P6ERERERFhCJxTkWhqqiI iIiIiIybDo7W0SVEoyFojaLMNXK63hMvnbsvquoUhWQeV1LIXkxHc0pXJfra3ep7z+dRCUiXqdQw dwKdmqP53PJVQjsV4fR3ugRH3r71VJ18KuTS+s/w+v1/vVujdRhzv3eez5ROP/5h6zjhyuWgvX/5 KQxe/Q12ThjUUrgn777sx24hv/r/wwsNf3S/fHen9rfBgy6zI/v/OjGh3/NBxyoe6/r9U13of29L 0v0Zzj5h9m7+hF9dbPYIiOrCV2uhhFx/EbEd94vR/j79V29jjBD4jzKiCTdraaoar/djffYpWTHC r0b8QuLhhMJxFxef4tC1u1M5x4aEGZSs578LiIiIiIiIsKha2mhEeuIiIiItSbpSKkztYhldbzse Ls7fMVoMlbI8QrCDO6RXC8haKtHcz+mqejPVyUdosd+mCZfQZ3TO55KoyCZkj6U7vQIj2k2uroIN v/ot/5lpWkf/W9U/Tc77fp1XR33Cb//5XBAxr/6ulv/lKIjiv/pP+7316//X//Qr0t+ytRgIVtlw n7+ZG/0v+9QRT1+aDjnf//Vr/9/2NY1Vun6iKtaEb9v/an+0jd14/0rq3YWNabS9f0m1Hx/CGtrG hrYpigZ1A3/YjtL69KbsXEWgwmFsIWndpjHfwZpJ1xEREREWEwhF2nHiIiIyuSR3ojuiO1aKoztU ykUINNMlXYTIVHVmKGERrqZws4EVI5t+dsDSLHD+1PUzslLT24a6kGIdz4OSBTBRnPsbKkXO0ktB B3eukE3SdPKcNGt+vBwetnaiCD+2q2+r1PGsQw6bXRr89hz2D1/MkBNOVtkcOVuLhav//wwy6VzJ KZt7pBrHGtAiPvSPDS6/+3//8b9+uJSouFBF74sEVf/O54f2p/VT90N8x/+EW//ff////90PYq9r pce2pFxh9Wv8+mp/hsjq7///thff5uxq0FhhKu0hFeLH2LBg/+K/8UOK7WhtbFQVsV6+TTCnZql4 0sLd8NCNC8zxYQYVbT8w5Q5x78QkK2N92OIi0SEIiIiLQi0Iy98SBUwhaGokeERhQQgwhBqV1NAg Z2S5XFEIiNM7rzueSvJJot2VLCBlEmStaP52a1k07slloIG9PL5/MlgMBSFRMR38ZGUVRHYrmSf/ 6vXaT6NjpV/yafktgg1MqBd9P/vV9Pvzwa/vvxb9/37/ciUYCf7jTb6/U7njz4sP9fdf17vVXXOj LhO7/OxGbRH1w3QwRQ7LoFVaWrXn70xFfvr1/qEI3/ERQQrBDdId21d91am5hS+v/43n+01dQ0vt IM3O18fCEfFYz/r4Z90OpwZgQdZWgw+wwkv7C8LqZUCxf2nDCHsXYrxwZ1+v/UREREWdEWEIj0LQ vM07EREREZbmSOzo7K1K6rpqVPU7UZAkW4aMIlmVxVVz0p6sggkgiCxwwneQqJiO553CU7nEpiSZ 2ozJJ//pbpNfyXCHY4gQzscTVEHlT3dt9G+z4d3U8UCI/aukqa5BAja+9/xXf+t9Z3O9GHO6RuSN 3SlwZ2i8+GCoMLfTf+vvrXW3Q487nfCd4Q9Djp///1ek2//r2+/vM5h6Io/hm/Xj31df/7Pp7/3+ uPN20LunaC/S7b/7a2c//W2z32nd+mKFrYj/170OP/tKkO40I0z9cWFT+xux6/GQabUeIiIiIMEI jCFqf8/6FpWKn+WcuoiIiIiGEIYVDcrgmVzSIujsyxER53Uy+dxF8leEGmSWL5CcMqIvlfkStFcb zuiqXz+uF9FjujGe1vhrmRoJZComM7NYEDBBksiFmdgeXzIQv2gRH7QIj92gn119lDhrarkZXR/V PJW0wuF/Vb1vVN9aBAr4htHe6Nnf/nxo1vQnhrZkcJ/X/9X/q80zAQMH+k0673q9PzxdAiPvX+v/ /u/rTWRKfxX9+m1vX69GHO7sR//26sR69TuVEIm6/d9rv1r6r/re7evrXQf1HFyL4QJ/XPrwQMjo Kh9X///8Gf8aTEV2rP9vS9Cu+otdCK73r///+xVbFfEfsFbEe+ybqf7YW14jvW/i4aDW0LsIetpG gp/hx9imK9iK2OIiIiIiIiLQi0NBhNVNS0PLcyR3RCIiItNAwmFTs7G0fRLYREZXWrTKlhNNBkqz urITK4XloW6V1LeR7sHpNhB5/zqEK92QqIMyPHbxfO6Z3PJVmVX/hoPaea/6/oa3ff+2VYbKsO0r p7+bLrqr1+emQ7SM9xDYhut1t8pWR2RyoVd0b0jw//0/9f094QjzI0ZcL+OuVuMBClZgJtuz0fUm mCR2a4W9K+OYcscw/61+u1TWr1eVwQMRCQgqtXSXEXs5CjdXc+v6m68zlRtD/UEwrb7Wf/mgL9/B rvjWND+/K6lwSCpimK9r330LYwl9+jdH+1sJoceY8X32N9r3cyDHcaERERERFlTTCHF6rqIiIiIi IYKTbs7+GVyTL5MgXKUGCVZkF5Csg8yWcrCMi8VwsWE26SsyKAhKRDp3ZdGashUTEEGd0jueSrCZ UuvM5b5nLf6r0mn+ix2dmu5NPubGSsSjPsYQbGEG6Ruo3d//0EH+/SDa63V9+hoX9rX6v+9J0bP/ ///T3zoy4Tfunr0h+v/d/xGr6/+t1+6p11rPbDOZOGGnVqbupf0utve9raUNLMhQMIbQMzlQ1x7b qwQwQ/Wz3iKYpirXDMvcf64YWqrtKOGmmqmRn+7TvjoRgz7mZSsGFWIiIiIiIiI31TEKbsm3Z3Pn QhEQwQtVU7MEIiMrreFCkqslcXRUshsxErIrjSJajIv8FOxxNlPC2Swe4TK6h2pComIEGdnzueSq OxsiprgiUUTjQ64LVzW11yDERY7O4ancJclOUadmR8xcKILVkqXO+0RjqnSdAiP2+EkEGwhgh16N bJSETQcrgmYMKEXdGuNL+87r7rrf5xzD90SH9/ulSMPhUP1/0v9vrtf9WnrneHRnKj2YS03O531T 3mc74fD+O9f/6/+lb/+l+I/Xb/jQ87jMcERyMfv1/a3vr+3/9/da7//721oNrc9lOU+9e9tJ1+l7 +//3udF//X/nywY/EbYitjYqKYj99Wwtt7ba/2Ev4pYtCHEPXTQ001T/FRTxXFd7DXtXWIdxERER BghaENBhC0L01TFCxjWmhEREMIRFhMIYidqIrGTZWjtKxEZXVIr5hMlYRTuedz0ztTCFusH7TQ87 HEMlgFyUxCpIyPHfxUoEGVRFc1X5ocz8Kl6NJOj/nvRblDtMEyP+qcxQp+6LyzwbL//9CG9b/+PZ W82iPK0I1a7n+/6Sd0YdPe/pXTCEer7xvt/VkUS031r/6/3Wr/vwmXCa/4jdRn/Z7f9GknHH7/v3 vtLytgvar+vqGkbn115z2K/bCXue5/zd4x3tVvQi0PMfFPx/X+rEVERERDCEUxx6nRHalkVEM3RE REQwpNuR2dJkrzsyxEZXW9MKSqJakggyCZfITIrqQfK6l524Q7NQmCDCSYWzqICGdFZXCohUdk87 1jGdxF0SuOyhEsy+ZIX16VJGtq61e/l8/pqFvOwNKF0zy9o30f/NAhU6BF1o3WVZ8av6+rr6drdX 3xUeqW6T6EUnfXr0Z/O/90CI+9/9/o4t+v79+/rte/6/+r3+v/t9f7f/1vVa+3yuCBiGbrN33uv+ e/JwwrxH/637/HaQ47iO0m9InDFrWoe6pvrBD/WDPule2KiNWKBmXWeGf7FrevV6U0FD/N9n/U50 01Mi07/sVEVgzYExHQvERERERERDBC4cdoNVi1XERERFoMIRlcFR3Wzv4ypk8TPLfSEaoMIMlnFE K7Knl/KmjIGjudy+ZpGdosd3ko7kUs2QdB2QqJdG4EDCDO4GSzOxIipoyEL6aQbQQb2X/eDV+1wm mmndpkpSa1+nroMH+RhwRH/K5qb7oER9Gxo2Ua+jW0//r77Y+CST5rWG/Sq6fbSvp9+/X/YMP4LT s+wQ2RRX1v9e9Lb/iP/pL/6fV/X/6//Mri4W7ra2CCOIigYBkxe1jP8yS0CJ3+6/vMd5jvr74M3O GlaWglaOi29V0ITrsa3ulul75jIGGGFP3WxsVhCwZwYqIp1hb9JNhKwq2q9r0O92mE1VckCIXhft caEaEfEYM0FOviIiM1lXGCBgha6aEQwvpXER9DiIiIjOjMeMx+MRMqYiIiHGV0pHdI7nkqzJRnfp M7K8tHjGV1VhN+wUmemyPY1OxuJVkKiDZfMiBncDJZBBmRocIV9GVQTeDXXXTvReMhenXXS8iDRd 3fXRdtGt8IOSkIjQ87niUvMBStxgJc7nd9hJBCvzvbp6eltJJ/6a6/v4QLOzALrpfVrd087nfV/b 5u8/a/6d6f/+v9dvf+O473+CGDB2e50P7/r6//zC22uuv30dVcf++lat1tq/2kt4pp6+2MGcGKX1 uNW+1u0v3Xi40LWNcFM5URd6YqKYrhhLtYtYiIiLNsSQiNCGgwmqDFCxSF4QiIgwhDCamHPhQ6iI jQi8rqUd153PJXnYlmMlmXzuiOyQxHns7Nayad2E8J2FCZ2TR+JVkLyYzuIvmRnGQzMIyGer9fXS cmgSaGnqpGVreFUyPrv3d+d9oEX9Um//wr63a3r//el53O9J9994IuvQIj72uHbX9Jf1kY/f/da6 X6+IIj9Ck117/b4f/vr/30vmQcPBDKUD2+l1sP7dTsQRHFfCBWXwu13/5udNd6tpq93V1FLoRFf7 +ZUSZdawZtzOp2IqIoaY2GFZOAXwmML3pRKcd2q6aDQ8UDi+DNugrYjp4iIiIgwgYVU00GFTW8RE RERDCp5XSsmwXnc0IjK4KZfCndM7nkHmvOxfJRlOZHSkXZvTK+ZXvKUoQijuBDscQh12dgYTP8R9 mgLnYlHZMQlMQqJdEdF0R4pQYs7nEkzsURLcy1Zw8t4SX9fRbqutfCERS5fP9F8/2Ey/r2p+yQ9E nW+jcr2p8dPPZ8uiT3+aCx0v9+vnqEDxW0Z7zv/8XxSfxStUb683WkEG/+ukd9/+nrbXbfp7X+9z sYy4TF9qxp///3t6MH779/1+Pvr/fxf3//X32/6//k4PdnNbq/w1P7z//8RsR3+hqwu2k//1nagF 5+urYW1FeNdb39/XfsVsexgzK/vFMUwwk6r5GBXUGf4M//0pu4Iehoaep0IdphMUPLHvwmK/9iN+ ODBEdCIiIiDBCGELCERZWyEOPTQuzOVmIiIiIiIYQwhDybdnc8hM1Z2UIlMbzuGIjLc0EOxxDUJa rkJhMjIvnYnnZiL5K8heQZHeGd4Z3zqq52YvvRbsLnavsLqqYQaDCDJXHYFEKZiotyh6Lcoei413 T6CbW7dbd0a3NFGhot3yDivoIRhCKCG96+nne/zvdVp0m0g8IPt03/2vzQMd//++t09WvU1md0/3 1X1/99f+n73pu6d17Z7s92e6BCr5kev9X/7+tdaW9/HHH+v2vqdlwf191/q6//r9sm5xwmK9tJjS q+l7SbVtW1t67XN2fqN3DiIaHY4oGbYmI32OGEoYStLtdhhK01QtNNNMFTCDWwvaYpjY6YoWKiIi IiIiIiIhggwgwQYTtBhRERERk25HdMp0bRTorraOwJluWe8JqmZFUXyF5Dk0ztJlTyF5EZ3QIZGa +t63+jO1P6qp9JJnZR/QIj76v2qTev6c6/TsbElutJVr9Ai/7rTvvv+EoTLhStxcL/15Eww2j7Mb t977OVSQ///1pXhivtVV9jtGe9qf7U///ekZHejHFPoUtVtxXH70rbVfNAXtdP1nX7flqqeCC/7E fEV+2vN1ebn/+bwQbWO1uPORQjp/rs5W+oifDcREMIWE4io7u7x+xxEWdERER2hqTcphGf4jJtyO 6I1BDWjsDypmSaOx0bypoRpk0SaSaoNSFYTtSFx2oyp5C8yBEXy3Py3S7vRlfPSNH9yVBHU9KoLZ 27I8SqOxpG4IH33ffSb+rX/03C+E00/fdnL63+nRuSu787+d77qjZ9dR7d1Z+LhSJhj6EikXC3+l /3VTu6b1/VIV16/a7a/raW+luvBDBDnVtfef8yPufTz9Q19/1v/9JfNYIj7aj/2tpirr/19baW/Z PeFDmsFZy8bhpf7DCUV83X262/qNbWHFxj2tihx2KUVp14ioir0rSte0IhoXDCn+0NO7vtbHEZU4 iIiIiIgwQYTQiGFETIlMREZNxvKvOxsipqjszi3EKW5lFzOzWMOQ+rTJTpoIpWQmgyV52VRKsgWa o1IukyaZ3Xnc+t4WHouHu5VRDUIEGp6O1AXIMTQipBFmUoMEqjsbRiIX2kYfwRHpblu+E/5c1Smu +lr964KmSjv09U9B31b7VzGjDnejDnek383dG7zwbLM5buaD5Z4Nf0CI8vX/6//rrreu6dt6taHG rSDuKvVPTVPv//7//6/13+1F/1em+rFK+v+68f17qCZHHENft/tUPe3///tffxS0uv3SFR//vSrt nNdfu+/tcEUPXq6w1HbChkV0yxzj7brtbWbp2oCqh7dWtaT1TFaEVGhpiuKDOMBCcTUbsbFU6C/Y 2GEhYYShhK8LURDCEMLERaFpoamU8/3aimNj2qBmaqsREREREREMEDCDCDCERaiIiMmw+Xzu8wiE jWjsnluOjsTR3yhbCpmgLpqZF8rOSlpnatpkrwgZGZEZ3Xnbmd8669dF49Kf73/CaqfR24iDCDJX HY2y/QIj7oER954Nn/dahXTazW/TVGhot3r6+vGr96t/endJ99F5SDwg+gRH7r/+/++RJlwi6619 8Kq16rf/+vTEcNdf9+/pR7q9fv/7rehtTdfdV643/+v+t634MzlQ1Gu1ve/Wz3dXVt62IpiKYYS8 dn77YSbCStrzc43Vta+rTTFbVbvbFMU7FdfFWlcaxFoREaFphMLp35oKHtMexUREREREYQiDCDBC GpbmZneGIiMEDCBkZEvmQSIRFlGs7nmXIkKibtFxUv2ZHDCkqi8QeQvILGQcQLNeQJHdEdjhDscQ latMhXhGegg2t6WE86dkXslBp+pBojoJ2kqcZEwxSum0CI/1NBr6MOn37aTf0Irn3MylpLTr1vY0 303/XU8f18zVUyfOaDP/v/pZoGPb/dL81ZsTRhzx21bPeGG7SCD/f/+/Vf+/VML12VtkcLHHYMMR 2/r/91OjvSrav71MOYf+9aXTa+OO9L1XusEKBCopcaF+28Z/z7mZShJ/7Eew0n2IpqtV/f//CBHl rnRnRa2KHcGcKOprf/j+zk57sIJOGlEREMIWhDC3EcdxaHjQ9CmOIiIiIiPjYYUsqTn/P+c8ZNyr NaUqqMI1mS0ybCEIiIjVODCpppnaEStl87MRfJXkxGvQZ3+V+77DC6NDRoDOxxFsLqRHrIu4masy rZf+diTQIj7pNpOqutvvzDg9deTcDS4YdP09OjDnfO/ne6/iH+kCI/cEPZFE6d9/W///3hW+639B fr+/tf/+tF7x6S/nRsInfa7puvd/X3/tDf/vnZgbtqrrrbf6vrghuSb9/68LiKhpIU+saUaS0pEK 0b9+sX4W0xRFAX4pimPBnV0IT/GlEWsMINSUGHi0Ggwn+CrpioiIsoOIiIjMbiyiLQybD5fO4i+d GVGdgeVlHXO1tFayLI/krR2HjC2vB3kKSanZ4vhSWAuEHalTwQZTxAs7czseI2iUZVFXW2ccjrqe r6P4W89VTanpbyXCBBsghB+ciDmDK41TOxeIL0CI+6BEfegb/3vV/ngt9b7o0dZo38Wr1kX713Xi Etv9+d+9DCDdN/pN8/JJtluZ3uyxy3f3r1/7CBb/d/9+/2/T6jTwnfuEHfuve/X10hXUf9/9Nr// aTd+rf+dkww///Bg7wQ1/Q1/QrvMLfr/qu+r/3q3qdE3o3amcqPrutqmrpJ9nO/8EO/OBjnRBFD1 sRURUV9sm4Kh2NKf9q2s3e1+L1tX3V6r0I7TUFtYaH2K9iExCafiPVhhJhhIQywoNIWUOZynCvth QwgwkXIriLQu00O6vN1imKaYxcR3wzNVWIsIREREZ0IREMIMIQwsRaeJXVcyKmIiIiIy3Ms7nkmZ GZ2L53NWVZlTVmRb8/59BO8lOYZ1ScNMljuCKXkqyBZr0Gd6o7pnXKxnXKjOxSr6c0POzFaaq8NG hr5JBPWDO40zscRT2SoVT6sEGSnN1+3Sb96QIj3krNJtfMMJL8scHutYWl5naae/6f+qfwYdPO+9 THJPfxddG7fNn6SDugRHr7f+/99si06W+1ozrzrGAmEn6d9J7+rqnxx/qv16/f7/bfaugX430Lfq /8Kv0CHfghQInHX/9/WpnKet/x3H1/5vo37SumKWiUDDt0+lEf+NC+SbBDbPaue1u9V/+wwuyhzW C1ZbndQlPKGFuP//yISaSHNmOZzj6dWK7WOxWOI0HEYWEItipz9jf9CEdj/TrQvw0sKWoZqIiGEL Q9PIcewhEax3gufvzOU/7YprGIiIzkRERGaQyIjCEOItBhCMRO1aK1iIiIybdnc8hM1ZkMy+Qmdq rTUyKUW2UKW5kFJoFNQlnYFF2Fs1CkK04ZBNTtJkRFRAgZkIzWZ3hkZjXX003CkoCBFu2DCaXR/1 JmzBaDIXoOzsCipMv5sU+JGz1O7nH6JP4TYNoQu/RreujR0aHWe17hvbof3SfnnRhzv3Bhzwl/pu p4fTekH+0CI/f3f/9bxrddhkf2t/V63KV6T9dv1vHH9f3q//Q+jie1/VdMjheyNsuE7q6/32e90v 9z39+YwicfXQ/6rr/Xrb1+W5kFJoFj41vWO73XIoN//3W/Gf90M/78IW/lqGSpJe0kxFLvUaoK4j Wf/aTGvuvuv+o5tzODN3HamyMaHC9/2KoL8Gl8MJXN2NKIiIiGE07Cmi1U5+O7Qax2KHY+tioiIt EjEREREREQYQhhQhaDUs4HstNoLcyZiOzVmI65/NWdlCIXmoyVhCEwgZXGkVNdvdVtMlARBqThgI m7KlnY1EsyIdlPmpl9M7fO8yTMlaJMyM9dXr6o0Zq1CBslPZ2oaf2qEUuf00zyTs7F8lMR0XtPTt rvNCpupoNFJ1ek1r5h/6ND7RoedgXoRVb+0CI/natLQNq7Z7FJur+p4vv0z970m/Sbq7W/4MUOEy 4X6uOn3fX1q8e9+nfp/ebvr63of/////V+/7/v2m9reTg+1P27pGB/UKr+91/ofmFHqYVVj21bCp 4rZKAjrVq2kEKil3X1+0rW+8JkfBfFMVMf+sNKz22lDVrVYYS20uf7qszlReltCKCwwmEI48wQVH FMQgZ9iirYrYr+I6HiPolAWIiLQYWGg1i04ad/0n1wZgVRGf4iIiIgwQiM6GIzHi0ymqTERdqmhG V0pHeZfO7y+dWYjXHZiIVE8cM5FcGibYhERldTSYTsLf8hxcdZ3TOxKTKnF8leUmU8dlGEDIwyWm RBkZnZSiLxRlqLSp6Tr03sG1t7yDi3yIYTzsbECaDQadnYlgnGPdAiP6BEfen5Y5MfNBown9tb+9 ZoaNFGho0PCG/6+u/4QO2k3fes+HjO91qd+jdSDpN06TdLLg97699//vTteVsMHYiLhVb/3pL6Gv dXp9G9Qm8yD67/1X6/49KvXa//f911f+P6cEP637Xf7/nRan7+//1/+YX+YXq2Pq9bVW0u19bW3F Xtf1WP7Pd1aV3VrdufTq9lDmcocExFMRUV2FFsJMMJf7dNXpbS8bq3q2r0tQ07qo4i00GtimKYoc VYxYinaX4qIqGlEdodqNoMIGCEQwmEGELTQaxYTz/aTYpa2KiIkxiIiIiIiIMKdEGFMeM80GFxdo aaERlcEgpqzsTRhEty+diWRRHYWiFo7JcREeXRmiZGYImTMEFsJ2tk0zDNcqZS5UyVZCRfNcEGd4 R2dFRkKRUZqzsTZaqmtJ3p6Z1Ij2uE3TTCHRePeSkQlAXW9BhM7NdM6BSUJM6BbCDJWy+ZDMfq1P ep7hJ9AiP3OP6nel9uqWr6NeaO+r+i3a/3dL68Im8et1fpbZ+/qjfm7oEX/ptIN/Nn5oVUHQIj9/ +krVdBev0t9Pt7WRMF6F2+u3V6+6fug3aV1v4j/eu/f96/Hiy6CXY////1/vW/5lgYvfX8Zj/Xr9 LYjnIufWv0v/0N9D9a+sGbrGsazw/+m7WNTqEBgiP/DChXuvdbwQ8EO9tX+Y/vQVoLhj2I4imsJT +9UMlATYte0tUjqFzqEvr13vg1hrcH2mh2Yc44XW+glitimKOzXoGYGuGsRXxERERDiGCBhDQiLi 8/2dThp2muYFU0AqYppruJhCIiIiIiIuLwhEMIMIaimTQYiIiMrpSMjTUlGEypZrMgjK6gUi+d0W 7O0jSVF4yJgumEGVKIVkKiVYTIzhkcy6TLor9nZiPcrqgTTQWe0E3o0OZ2/6L5rEQ4kIllwS1Lcs VLsnqaC62mwyUZkk6WjQK+nZ4NdJtIP7rTfMOeFIo/T07TtOq1PRkQLnc7/p/saenq11en6FBTcF U96RnwkaNTv6d8Jfb6q/0r9XInFwpEmXCETBf/0qQVfVXVdJfTduiT6/9HOPr/9fX18QghCSrf/t /d+/O+//6rff+rU/Wpuzo/6CPYQRz6/r1+q+197/xFTdbC9WrdCrjXurHgglCC36j9Kv/SQ//a91 w0mGFbStf/V11LjCSxq0sasV9qjD/7sVzU+GKYpimKHfH5qeOOgurQXC2w1z13xaFpoRDCDCaDCE Xa2g7zOcc47w1jvj0xTTuxxERERERERhCIaZSIiIiIhhDQtRERERldTyv8VxvITOzBlT6n1mQpk/ muCpqQvJVkLy3F/3r4IaNDJUISoRV77v8jHpNqEn73lLy6LxdEdn8uiOi6I6MZnF0R4jojoj5/I+ XyOyPmcR4j5Hy+UJTH/P6p0bs7nevV9CIjQiIi0IiIuIiLQiIsIRxkTDGK9Cvv9Daaapqtd/9v+o iIidec+ZGz37f6/m7r+ThiwlDMT+/91ffUEU40Pv/tb1jzeU8IX7GvcRoRFoXkKPn+NO9REZyIiI iMrqhluKI7oYidqFCDK49DCBktzCO6JMqfCJu9EUsPBZBbsKmdIxEsdlSyFd5C8txfOxQqCBvg00 0EZ6b2muSsTg/vJRGI15dna3afZWNqd9XO/pAiPIER/CXMOH9HZRaapnal+rxCSSV7pd1T13O539 Bh/1oER6oIj+/fCLLP/q/67rtkSZcIIbIqHKAYJw5OBB8Qjin8vkfI6L5HRnF0bRjNEYRxF2fy6M IujGZ57Nojo0RxGaIms7SfVfV//v6/df/3/Xu7uNCIiLQiIaERcREWhEWEIs8GcIgRxDPMgmy/91 38tIqX87FHf/9fvr+1N0lGEmVB6ynKOpnPATOOdz4CZCDnHu1W71v9r9L+OPOwJJsaoba8Uv1+Nc QQ4iI4iIiIiIiIiIiQ+KddusEUPMJfxVLxG6xr3+gv+KSjSiIrOjojVEznhhDTFOxjwr7nP1paiI wQiLQhhC07Vf4asNYM7TxhCIjQi14iI5aSmoiIiIyuqxXuOxLL5C87mjucStkX+d3H4meYPBfUpQ YQedlOQvLcXzsCZ3WuEHhC//0aHl8/aqmSWNaI6TO1SL/mHbow5d9HffzwXFJ+690Z3hCKC30g30 7f7kT8pSxhPVrX/TemgRH39N/+vpkcKEyOF79//3MWjcq/7etf/X6urxl9V/8iUXC4/+29xXfVqf 4an/q6RiYjf/da/+w2O/9IfH3q1wyx/9gmEmFP1z6/7vpbEf92rGk0f11iMVuGu693H2EONMUh++ 3Lx+hsRURERBhCLSIxyh4vvUIoQ98RZyIiIiIzzQYUsoRCIiMrpSMjSkhytqZxQxWXsSK2SGNywz WHK6mkyaZuOzWN3Ei7LJIRoC4QZU8Jl8lTL5K9BlRkQZkMR2tdHcOnhCGhD5FHWX1pFuyVBF19Ai PKCBnaMmQU7P52BMKEH3RhyT0Zy48/pfmg+aDpI4/W+E+iQ5Q7wn6aUzu+kwm6av0F+K3Vzjmer3 O9/sx6NR81PoziEk/6f98Qkd4b/Tq+91v/7/TkyZHgqV/TVN/v/8II4gRDiYj/13/X/9+whHuUoM fS5agqpXBQw6/roJMIjcN/dX/0v1VdepGOWP/+ji3HURURWCWizsGf9r1+376vEew1Z0W1mP/T1s oc2+Jj2SH8cIP7aUNe1jWIr+KvYZcb66e3UXEGCBhBgvEa2KYrY2KaVnPwwn2K9uIptdCIjOeItB hC0GE04i4MrfXYT/JPioiJC0IiIiIiIiIzohhVMsyhFcIxEZXJcvnY+fyaZ/JVhSgjupWR8jikVZ 7JSKEDLIXoX1tbC6xFLYQZK2XyV4RIdmuIgzuaK9/W7XXBE3o0PkoKfXN9fQIN4IGdmoU7Pnc+wS IToER97W1wvVmPcbabStAiP30+iMdhP0gnevhAhBF1CBCVHBEnj/gw2lenrdad0ajnP9wRKPXxaE XHgvfK2C4YY1+vv2tOtlLRdEdEdZMl4Ua//3/7///197hCIjCHYRdyGy4Q7WItIsV/OzUUj5NBSP 8ZhRHMiFvXf1/6f//WGO9ZcDlwPRnr+ECOWEmP1e12GtqzozH1B7U3YdiKrr8GOc/wgqYarGkraX FMMwV7/O4zCHtvVB99oHoR0Nimc9itisMJiE/94YvztKoMJ8XEXEbDCpw07TgynCDCoX6wdrEtIX UREXnOhEREREREREQcWhloohIYyWIRcZXSs7dEdHfZHRCpBkdINMk0YRkaI7uNIZXVRCZhQQg9iQ iC8cjEO1KnxmvIgzv0d0ztbzIjqE0HoivQTchddqelZIeoIGTQOTQKTQJyDhD7UjtPEbM02jT83q nlZQIj7+9H/RJ2mE0H50vP9IaD0G9wguxWr3fBh+jUc1M1KNPzz9/118QgvCLT62/DBj06VpXTd4 QW95aRUr+/hBHl1/wwRQ/f7p6ffEIKt8dnt1tdBLeDB/hCPV+r7/oJPw1xsk6YrCginthbvWWPUI Ec1YathJtbXQI/gmXQVDrFMLiOGkSgKxFUesEF8UwYKwy6BJhhLCSoRXm6DCBnHBahipGIVfHhhM QmIhMVaHOOFP+0HERFnPDBTEwhadXBlDggYQYIMKsZtrXiIuLQiMx4iIiIzoVCNSfJ8WnHGV1PK/ wVDJXmEVaK+IR64VwmmpXNUmSrIVFuL6ZrZahYuesETfJ/V8ySwv4KEGdqrL6d3wuG+d//2FRY/s d+dirBE4iGDFdvn9LpGWozChBsIER97/wsN15nFwqi+52LwXV6/H6D//3/tF3H/4X2MJXpNT//// /zdxRol8IEe31HzJZ4ZdEe/4PfMf/fcMYS4j9CI19hTuMx6Xutr6B42EPJj/scMcasRUREXwwhgi Ru9YNIb3nPEREREG5vsFERxKMZXJcwjI0iuMiDysMgpkEZKcjoqiKkhOhDCq52kzBkXyfkMHl0EG mEGENVLcX0HW8IWuaRIn7P6LdhFw0W+vzIjKEEThna3UCI+/MOXD+GFRvS/Qem6bgij/OxTL+nCD Z2pfryl5HyPkdEfI6I6M4j5eN5mKR0R0R2fiOiOyOiOiPmeXRHRHyOiPkdE6CmEk7vhiFoL+rp0m 9fzsmC/pPvX0IiIi0Ii0Ii0IiItCIiItCLqrjDBCCX6v9ecWRUOThnNA5OBB8QuM+yPl8j5Hz7I6 I6I5l0aZtF0YjREfNovkfM89EfLo0Rnm111V//dqna/8QgjiYj9f4jXXjQiIuIiIaERDQiItCIsI RZ4CD4EHgzmYJLw74vf7+IiInXsec9Al3V+/ZUGqKcpynKwJlQZwpxyhynKHOOCI/LHKHJj2mqpp /eg27da/vXbpcJYM1lD7q1epzxcRERFxERERERERERERESHsGmM590CKHl0CKH2IpdfQ3F7W0rX/ wxW22qERFWtqmv9imKYqy6a/D62k1DCcREWc8aYQaajH9/YwZ2ngiIiIjQjiIhhVERGV0pSup6Zb JIvlshSCfcIfy3FmvvLSyn/67xghv9Ie7JtZZVm6DjH+M/4jK6VyuqiFuBZuqELLNM84ivPotyh6 MOTdphA/CEUmnCH/e57Nb/S/WZEsXC7Pd9f/jYj/qf/q01H8/S3FExFfoRZcJ+IiNRlcFyQi3KMt Q0H1WQRpGfuWl1M5Th/6oXxluTDG4IF0izUpkc1EItpxNxT5jtCNLQu7zDljgiPsHvtcRzJYzxa/ f24iI/Hd5CjhRGZpzaj//////////////////5AdE/cf//////////////////////////////yl Lx/////LVVeP////////////////////////////////////////////////////////////+V1X LosxbyFqCEHpwiQ7/BGnvSb/WWYFghOBBmCE4EHwIPgwfDOeAg+BB8GD4EHwIPhS7PmXRHyPkePg uR0fiOiPl8joujPLojojoui+aMui6I+XRpmEaIzRojCOxRb//v1T9C4iI40IiItCIiLQiItCLQiG d1gRbUswkxOmIiIiQaZUytDuU5WFDhBnHO6qW5x00/XdgyOPxERERERERERERGfTYha/DLHC92oj tCMRyyjWX5XS8JtlkIiFXXfLIZXnf/I2nhXCkR2R2qS2vDoRHvvz2RtI0ljmHOP+vwYdoRD3X+D7 27VfH7EVf2hYTXcRFriMso1SuqojxkC4QcEIMyFpBosdlkDiFUJqsIP5ZTUJnO2p3atvhOr1vWvN N/X/9BP+0u8wn/thWNJ0r/8VrDVftYYTC0I72DBKVyTI6FrrYqIjOQhaDBXERlk0SyblWnDO1uL5 3TLefK6kz1eXz3Bhc7cTIVQn9LbKd9hfLKfzw3r6EMMhJHe83fureZAcXCb4YZdL/Q/Xb17XQu// ospqi6CBfb3n6xGEXFr/7CER3YxXDk0G9f2e/8N+2bsLG9IpYY9nPtu1tcLYjVfu04tC9OwpkX7y 0iuiIiIiIi0IjLKZYyyF2tBndMKdjeTRmIt6Igaozsmngp2oCbdkI7NVSfwiT1r1/TfgkM/6dUCI /9ftF28fetv7+l/6X9/phpf//0gQ4IjkY7OVr+tYa0oYedpwXbSVvq7FAzjEDHsU8a8NYg85FrYr iLiIiGE1ERllUuV0vMizkE2Nn3QpvQ4M9nbYEVyQQyE7TOwnaeE7NUSTO553PO553PO552Yi6r3N 6Vzs1CbXkt8mlZNPJpqTTzs1WFujd30vS6f79b3vTv9D7QQT87nfrdfvv9X6O++1iEF/t9Pe/197 0/vtNUEe1X/v/fb//0vtm4EKCWCH+rpUCBWR8EgRQ8vhVXrXX+h0htfva3ERoRFAhQIYIUCFN6XB mkHBn3Ox7FbJjhMkOqqq9c/2pj8a2sNCGhBm359zPuZtiYioiIuIiIu7/TVRERFwwpZRXUyKIRld LzIsyFZSgwFMgNoMt55A0a0VhHdFK6oFMhUQi9qCqD5CCpkKgU7jBM7tF47/O553PO1Fpe2eC3QR J8J1XQwhR2OEOzUQ7HEO3EkEaSVPznHMP3GEGwRMdDRv3Rd9U1VMKw+6tP6VoJu0H6CfRvz/n+jd RuSLzNZ4xulbr/6a+hqhUVGhoaGm79t4QK1urS2vu7/6/pfoRXwRHGX7X3Prc+nPpz6u7XeV1QK+ rTaqG+I1gwvDI5wwnDTs5tnNs5/4XFBm3QVQMe6F6HGhxxcW6+eSlaYQg7OfzDmHXMOYevpLFDER FxEWhEaEOz+p5qf8/5uTUrhaEREREREREQYVMyWUSlD0wp2eLxQihHajJskRA0ZDFkPIX56TdO1P 9kI7NUQpkeO3dnbsvnbxfO7zGdxF0diiw96X99V8K666dhNQtrmnn9ejP/90d/zv0CI/aBEf0nV1 zsmJoNqN3XbG367f91vW2gRdc77nfa7t7S/W16/S3X/6vS3XdGcqPrj+pqUP//X9L9b/r6XtZkNJ AyOiPLde696X9P7f/Xr/7cVQiObrEfzf3/b/0vS2u+r0tvldYKRR7VtNb6sR8RxrGrGrGrr3rqch C0whEaetpimKimKYjeKiIiIiGCEMEGEGEGEGmELxERERGWSEa2Vx4m5pnc47+O/zuiO6cm5Vqgzu cEGTYRkGirRChDscIdmoQ7NRDt4JnY6WTcbrOoiM7JpOix3hT6TVJJQhQQo7Bl9Ug9aCDrp6Nvzb mfflwCRhwVX3Rv1903/XrCHFG2BGjroVb/3erc9uenP+f8+s+qsx2+/6/b+OONjYtkh3v1Lpd1tf VDrquo/4IRTBkd3QIdq66Nvzb82/NvzOVvDuUOVtR/SHa02lzQU+6d6oVEYjgzAzDlD2KBn2tjWh 9s956z1n+z6z6u9CDhrDCd/Q4442Nhgs51ERERERHVdULEZZVVT/m9TdmzM5T5GPk3MmRDhnaTER EREaEWU1CoINM7hGKHk2Gsq0YRTorCO6I7ohGi3aM7CaDhqXz+oTtMiIxGogpKIuzWiO0yUZiNaI +mShG4qMgkVGQVFXadBN1OPKd17r+mh6YQilTCEUmmdApKJM6BSUQQZ0C0n3pXDD/O/9Hf+jvmfz u5N+gRHvWu/vOxGdLTa/Vsi70+nr313R/reEHqnm7U8OftI8Zs0jxmz5aQupNhte//bGtrW9Lv2l 7V/tN/7f9P/TwyPEc0hja+Y/oIuMdP69Li/4v+P+P+Lf4txEd6tePOg2gdrvq261tL9f/v9f9lDk UcLDWKVpYVzfHf+NToEY1OphYpTqgsVpR/HqIjYqNhLC31iK6SVpIIU6hCsKQwtBSGFaUhhYYSJj lDxGqHd6DXM51PLHBMKoQaqE11S1FghP4iIgwTiNCLCERZSyp1kKdZCnahUIiIiIiIiMshdnY05N xRl8hNM7uLwTMiyLeeas7DjeVJGrN52+bzuaO6KvhFu03RnDMhMIuXzNGqJiTtNOyFSdkKiG0ypZ 0dlSzozFW+E2ukH39fa339/b1vXzvf3R49OjdVfrp1hW8K3p+E+wnr5my4Rf7+h3+9K9XVX6+r+/ +v6/7/0dWXCbkbZcJ5EouFrIlFwvkTi4XcieYCJP/am6+Y96b/iO/tdX+r1/X1VfvpDXa7f6VnLe g0jd6an961PzdWp++8/b+Zyn341+NYjQ48GZyo2PbajfdCr3Q7tqO70NC7pWKHjYRQC+tDf7FexT qx6wwl8MF1hhYYToji1Io5x8/3esdoXaHYVOxXsVuxURZRCFlEREREREREGENBhDQYIcMKIiIiIi IybirKoiaZX/hMq81JbPoIGW58qEQeQPNbKpmtlURTs79HdFRoZ1sEOINPCDI9ZBiBBkrECDJYKE GS1GIEDKlAiKFmqJNQTpv9kQdz41V8KjQws0MKi3YIaZKgikrETq9XN2fIdXed/y408u6TokPoOq NjWa2FRrfvdrSbztTq9LvQQaVtBNJXP6q5/08/6ebqTZaiF61Fv7v196xp6GnxV1HvFK6GnG+YwT LoJL/B+/+/t3/v//+14jOrC2rt3r6Xn1aWf3XPr8zXX/rjVoIU2kIO2Enb+zUGHUigYuiKaBptpQ wt9nK6s9t1QwzgyxwTGMaxFaw0lbCoRthSJgu2EiKAu2FIoGLXM53KH7CFhBhO1U1lPY5sKjFS4K HxWx7FKxWhE4hEREGEMITyDBQhDQMJhCeQYU5FhTkWFORa4iIiIiIiIiIiIgwtna0iN5ZBmOGQLO iOSZdEdF0Thg7UI3HZ8t56mrNZEayKERqIrEbiLojedzzuiwyIEi4iINJNPyMa3lOGMpwwEynDBF CKcMEUIpwwRQZTjI+E5NxU1nc725oNHT9NBc7ozVQRHRmujNelrQQioMNGHO/7nw8RoN1PFVRnFV inPBrdDc8GvBXPBrzoPM0Fj50HmaCx86DzLfYZH63rdJvS/ylI2E6YX40+o0/jT6tQg37UIP7Cnz Q/bTX++/0Gr9XGtxStyFHreYRH8UntRVu1FW4Rd/3pf+v6mHO/831Vf8e8RFfHWx08m4kT23x1av axWNC6/8/lPvnO35rO/W//X6W+tK2kLaThf4j8bevtaF3qc++c+6nRtcF1FBrjYphVXrfwwl8MJb wwu7YXdtfbSviGEIhhNCI7s59SSgcGLFQYsVdRV0xV7FRERERoRwwrDCtqDEMKDFqDFqWR8QwhaF xcXFwwUm6UIdjeRiMIREREZNyrU7VtQqZ2Ti+dzy3pkLUm43WjbGhhcLZNO9P/LHwRH3V91+7nuE f0m+d/71rj/X/9bt+N//+9SbgREfBUbZT2v/XvEVnY2Ev/UpQYWrJuFntWIpiKa+DjHJDgmmgZ29 W/zpE1vxn+IiIjETta5N1tEbR2rCHY3nfqmVcFOx0YlO04Lk0aZb0yFXPQQwmg59pFt/6QIj1Tv5 oNGvq+jeqXs9igm6fffj1bHv5b2s2k8f+v+hFk4EGYIThnPAQeDOeDOeAg8Gc8BB8CDwZzwEHwIP gwZgQeAg+BB8CDwEVc+r6n2N/6+uq/2tU111zQU+LivtbUt54nRCIiIiIiIiytEylZUFHTPhTlWt DdOFs9tpMMJaiIiIiIj6RY8eNimK7iLR9D0wviM/xERiMm4siEZXUHCZfCDISOwmfSZ2fLeeQtV0 XDrtGhnbia0d9wv9JtVv7q/fTokOvr9Nn2XCN687w31/9+N/9++trSN1f/7/TpD82bX9axHDXunb S7/hpihqtitj7sIMIRFoWnqIiIjk3EkRmdlSO1NnumR0eWFLxCa2TYZkK8RDy8egn7TrdgiPdVOP fq+s/W/0n9Xf+/+tmcXC1r1+LI49//7/sf08/7V6uuGRvbpR96/DoWf3Efw1Xsb0wh2K7hhCIYQh hPURERyyQjsbyfk3Ko1CnTNx3Y8oRkVZbnyFcm4mIthMFy/ZkJMJr1RMf6JvX6T7zucegQPU7uCH +p4nXOX1p6Gt//9Nevbdql7Ef/f/3Pq/bPp/9r/8kPY0ilBAUM1lD4ra372qHSobi7qI93YqZ4a2 bin+0q8aaM0IwhDiIi9RERERyyq2RvMixSbiUYiRk+QemVYp2NSkvldSyFfTWyRaCNEFcmgU6MJr 6R3vXcJUTf1Vv/b/d+CHn7SPH6XoddkcJnZgMbf63v3+PUf766XOeCBRU7nHO+z3OR/p+xpfHiLs frFf2lXZNzjheupNAuFXjtYOIwYzQUPF4INfcRGraF6nGguosocIREREYjLInZjOzBnYEcm4lGJb TTO55GRfK4XkK+E2tGho0M7NWEwtrep3dNpNpN0nu/Xdenp6nijx1rX7+v/r/uv///77uu6V7//0 9Y1tdbWK/X9JMU2k2lhWOl47TFMUGtj7iIaaEWE9RERHJuLI1xgiMR2BxvO1aO61CZfWwmX1VUyE yuFZCuvzD19tT+dmoTW6BEfuFToER/p31/1v7dd13z/+v//v2/iaRgI/X8VX+oYIof6//uvW9CP5 +rd9J1fptUWOUPhm4d3rEcNYjimhB4/XhpiEGg1X192CaYQiM/x3qIiIiIyblWQnJuJhFpBSuTzu IvkJlcLyFdGVyvXWtnTtfhEnnQPur793PQIm8TNwzuL0d/71jQW89Kb//r6+km///8tpYVGGBqNu 52Wal0F/18ejOMv+MRFepOGH7n04Y9WmLql8XQPuDPs4zr91EO0Owt6zcnERERiJrxOwnJusiEQ7 KRHYt0GEHDCl47SJTvsq8rhWQro06LdwwuCGTRhPXLaWF7hBzuDgiPutX9jp1sGGk3z/pHj9f3ZG euo/mkXC/91Cf7///+gid9r/+dyov47Umhd6wZdxWKi6+zTjrYio8K/+c6Q4W1O8NdfcRk56cMLP 4iO9SbpdKASEwQYmxyblUgwgzsfKgZ2kGdnyE5NxMRG6je1PaaZ3AuVwWIVk27ppBtJ65rc0Qv2W 5mJn5V1d6ToJtFjnH761Hb3fr3hCKrSNktVYjd9db/XynBf0mqG/XSH7/64js53t+2v2e5yO74ts LDCz/tKwlHf9nKrFMV5OGGPr+PNyYTCHVhT9H9YiIMEMyIYTuL83YiIiIi0Mm62QybigwgzsSjst M9ncESaK4X1Rds7Uf3dqQrLc0KjW0EG92E2jQzUE9Mr56en/dJtL0XD6t/2lku6edzu/hP//r//f 9vv/r///rmRKGOuYRdYIdq////tKIjptIbX991mPLSK1Y8GfawGCsNLtVW6fSsKdHYhMULHuwwvj DBCIgwmEwn4p+IiIiDBCMZXJEXRkF5Cs75EQR2SZhEWZ7KvldSC2RdKTRhBhNO+zUEK4LEKybcqe m9XNbXp19Mrx0aeu6RnpOjvum54T3+g2ZAebCU/XWu/5/Wvrppf9916/6133RGPtL66b/x9y3WGX CGSwGNqM3QQ4+/91v3vwZcu6aVtfStI6hfFG/OjDFNYM251imI2GtfrfYIaoWEGmFEKewXvvxERD BBhA1QtY/xEREREcm5VkKzueQedmBkOO55RSul5kKLJULnTt5BDMUVyuIVk25dOwvudjew38tzJK ZLYn3mz/y3M+aDQ9U7CcrhaLojojpayISQlKzYnZ2n+EG20E/vujTdCIj+G6YXr/fba/6b9qgfUw 5Q5Q/7LowlX/H2vfMeCFN2cxoRcEOIj//0//0G4v0pCj3XtdQQ9b4MwmkvOnOfDUW0vphpd3Gbo/ uxTFbgzLjioiIiIvQYJp+mFEREREZZgE5XJcyU8iEREXyaZ2sGRpLVSG0GF5BNljThFuMiFZNvXM isTTXhzwyXErwpktozXVqd879mgz0nNpbLnqW5mICDTujOVFLv7p3+53KjVGLdU+v3q6W6Tf+q+0 /ozlRntv9X6W/+/6ttv/71b7u3x0+l/Edvpof1tu3/9pb1tJ9/j+/3y0inrx6sRTGM1PazDngp+r /bHVxaFppoRFihER342G4xERBgmE+LTvLIkQnZmhEQwhGTcVRuJWk7GV0vBDIPOgQ7jL4UpZkJ9B HX6C2dgppHWLvsj5vK4JEKzJSzuaO6LzA3o253VBKmgRQoiH5kU+dmqs7NVfet4Iv6NApqd3SsiO 9b09O5XVUR0sjHMHuDI5pdkQqr31Rsvv338rhQYj+K1pB9JfHX/vT71mHKHC6ljrfg9zfr+3etf1 5kUhEENBD1t/3XM5Q5TlD/99df+59Vn0xah4jY0qERe0vwQoEKBCi1QpftQZgbLpYoH2l9tR1rxj oXURhoZ0R5JWK3Bm35t+ZrIGhUXodp+q7KnnnO54idmqEREWoiI4jK5KZkL5BmYyni6Ox0FIxGQr GyIToNT67WwTSBBnapF2FzXBSuFZCsyKTMZ2PG+jR02nC6aCIaQenRphDVXu7O5x3/SbfS533PAp OfNTu4Wu9PXk07099X/ta375g+f19dPr/63S3690vulx1Stb9/mFHa365vp116af+33K0y4Tzslt ra9PpP9+3X/Z73111fh26Wbmwwt6oRx1GsQwsfvT0Gp5sFI+CsHiP2KYivWko/7W1G1QiuotBppn PGh5blQUPnv7FMVWDLHPI15jxERERYQi+DvtNPtCMRERERERGoyuq5kCERGYRL52NI7Wcwjs6qfS adnSTBBp2RTKOyuCxCsgWZB5hHd5hHY8bzt839Ua2F1TOxGg17/UgxAmmmndp2drf+nnftTvWe6B Efuv9VcK9P/fW0u/v2631/Ruzv539XCb9+/6Svq52BSXsZpFwu9D9/aT7+P/fr34P9f10t0t/XOy 0MFpFSq63pN6XrDb1nRqf+9+v97+ObtpPrGsdB/q8f9s5t9N6TrrOjq2GlEU0rag8R/rqh//2ldX +mKDQuNC01i/7EVEUxTG/EQ0GEIgwQiLTz/adphfERERETv0IiMs4PIzKEJaxkpXJcyFYpWdmumh ZNIm1oa0YRmtI/kJkXi7htIGV1SIVggy3KkdzX00zqiOi//6bDk/bIRcK6aZ2O7/5OghEjGb/ndk rMN88PVGtmRCL5da99qgnZzNout8kZdEdBa3Bhhg2h/Scy5AhEGVnMAmgRH793dTopoR3ghEf8ik MQi11O9YTtNPrfsRQ9vxv+Fdf750eY8rEXCf19xRurOjpaLyCgw9fHsatVX+DNz1+f98akWHhF8b eB7t1/hqbr+WoLL1/X77pQsJZNMLra37jV+kNxfcd/oeFxUTLqd2K+1+NYiIiIiItPwT7VPW+xUR nQ4IREREREGFERGVzJGRZmsiozuMvnd5dEpzuvNZlmlHUyFhEzqtbC3n0d2lTK4XEKyBZkQR3Z3w qNbTwrrapgho0PXTQZ3Sh+bFT9wRH9AiPu+tN/o1tGt8PpCrdOk319vP6Sffp6ejs1BDtTOVwoMd f63+/j+pqzaI6VbXyttMN97XS3/0P/0whHvVlbDGznsiNJZRkbPJ6BD6r/s8v3r0r7a7S/Ha7dre kjdg07XUZ/vvU6EO4Rd/pmgYBm3MRTEbvG2l/2tr652WjePN1aaarlj4rfzLAwUoMd/C4tCzoud6 IMEIwj+Gnx/H+FxoREREREZ0UZERGuJsdC04jK5kjItQTNWdnI7pEKRUI7ohNjE2Q1TReNTyTOsY ZEwwmpC+yuCxCsgWEwgzvGd8/oJvho1u08i92SkT1IjVG5ovGEGgztTv0/pdTj57PffS/3SbhNot 2jO6P5aRUuZDSrtuqeknFJt+kYc713+nV4QdIP4yuFBhMuE///380DCXZOGNe+6tbq76qvx//6++ 67//7q7+ZEZu3St8f4Q50f5j/66+t+//bazdtaW1S7/p/BDvur9UP38MJVlKB3VsJMnAL++/Wm1b VtK640NBin0xpigcRp2MfwZ5VgwShhKwoIpxz/iLBCLOiLC3FoXfimKYoIfxrEREREGCBggwpP2N RxEYINDK5KRXJowjscIQmSozvDE2Y0wnaWEyUxdhM7PlcFiFZA0EHRbsLzjeaH2i4fqSaClukjZo uGdpXhPO/9JukCI9T/kuETTQQbO1QSr/bDNy0/TpX/1PFJ0i0itabXeM0i4X/6crYL7o7njSV02j DnHj1r6//7/X+t/rDe9vSRxmf+ulusyP////evXH741uq9/vXtf8MKxHZ79sJOrYXX7b7pW0v7FM KMdihqKF9XimMJWvfDCYWLCEMKncelYp2OIz+hERERaDCFotIrUsleImSViIjK6rmRUZA+zurKWz 2VJHXykqpkILDO/E7TWGEGVwuIVkCRkMR3Rc9o0Vgwtb56g0WO/IjTMjqzs1VluHfpsInGZ3Napv fBtBBvXdPTy3wL/zFCDiGHQbV18GHTmSXnPf666LSK1b/6F/rIlFwt0wyP+mn/ffc/Rx/Taj/8Gs f/r+/7dYjz6IcErbWkb6GCJx//618fM5x9xxBHdhLSH5nBEfJQN7WmtwQwQoEQg69C8znusJJhq/ jaC20hHWuNfwhGbsKbfCEO1sK4/BmlWbeE3CLfwsXFp6poRarDCd6oNDCiIiIiIiIi/O0+JuBZQh EZXWFFmoioyl5A8vnajOyGQ8r18LSZOGEQxX1Loui6IPCeV7MjiEpiFZAkd0R3TO553Rbk/aLh+F bYiIMntFu1L5/Qr7JppnbinbincJM7+O1mtMPhPPBrzeoIj/IQf2gm6+Z+vuFUIZ2ahDtTELSKlw YbS2NO4QSXzZDdPT/tM+f/myiY9JQo8Gxp1sQgu7r2/78Um9/tJ0CDo3UblN39ruEF9beq+6r+p1 ZHC/Q0NDjQ1C9OqCP+164IoeXSXxH/19Xdv3BF+fSvQSVvXriI20ge13Gf4Ibntz6c+uz62ElhrD CxxFQ1Gkws3/1/jhhYa2c9dRTEJilaYoGYrG+xX+DPudDQ4uO9hoMKY8MJhNWO1uPzZ7XjOhCIiI jOREREaaDz/nmpvU/y0ipREhWIiIiIiIiIyuFZkCR7JNKdqMrKO6IsgxdNhqFgyOi8mSll9S3pF8 leQrIhmI7NXZ3iMIy1jv8tQqXLx7rwQIj8RD1s6hF1XbuwmmduyPAgwgZ2lY17p8JbIjt0CI+6rf /WFdXTRY7O1XBfVVeCJvFGy616N6R3v8J6ed+lzXQQcIV/3M2RwqC6vIEGF/H/furXtAi/09WiQ+ xZfX//e7//9f+t67StXne3iPSan/DX+ZF/f/+v9f9/94e1H53GXrXr9YMjoj3r9919fVq//DP9hp X4YptIdWIpCO+vbVtW/ut61/+xQ+DxQ7UsexH7FMVEUxHDWGl3xcNCIcNCwoR/YXtNO0xTFbHEXE RERERDBBgmg0NREREZXS0V8R2YR3MyVok2SvLISZ3PLd1syGsoVpl4hNNQg0GVEXyvmSrIUiBo7v MI7cQ7HEWV1S9Mh+FzqERoan+Z2w1syMhFTsJphVO5x39/+9XpJ30nBhq6/pPNvzbq8hWmPV/Vzw 9GHO+m76bDDR36NnfQIuuqqoMtIrXeK30utv31cMMuv6HXq9s9tnv5nLHj19e//4a/H/+dWRwutx xlbjAQpUXCUIbginpTngmR0CW1/+h+EXH/+vf+1Xt8RrcR2q/2qM90iUDf1s5bjP/6Rt+bbqbrSN 39eyQ4TEVt7aWf7WrvqPX7paoaxra4M8inQYQu8cU1sVBbEf/sRVnts993YrxHYQtBhDTVUGFP/c dqNDems7VSiIiIiIiIiIgwvFxaqM/5uiIyyJEduZ2+d9n8REZXJWR4r3mtBUzXmLCeVLITK95Kch aq5kZCBDRoaaDz/VqdQi2mQLMiGR47eLx3PO59dVSbqcfrTur/q65NPOzX6M+0Yc70b9PST303zd /yaA6O/Te9b1vW9D/7v5EwxQmRLmzX8rda+jP6v//3f/wwX17Q/NQY50a7pb33+vu59Wpe/Q9ZnL v8w/dWu/9/6y1BVb6u1gwr1x6MOWPtLF7OQ0f9ZkR3+vrW1Gxrvxx00FcdtazQF//9W67rBCgQqx TUUqGGvdiv9f/4imLWqtCwp/zDmHYiNMIanIi/j+7FAz7mZqjiIjQn0IiIiIiIhhMLqWR+hERGTc rRqENbhkBhmpXS8yF0FUIOGS+YiF5C87nkHmSzkkyFoqDO8MeELRgZbuGmgyLVkpEOxxDp2pfP92 g0Gdj5hnb5jOz53PO1j69Odw6nH7hJVf11Roo0NNQoTO7s7tJnYXIPo3pz3Tgw6Sd+Sejd+t/SbS eoIjzVghnZqE7lcFjATGNJuGR//0Z+kL//09PW6zv+kd+1++L//23+9f771ukrRnKjO5UffzQU9z 6Ri9QROF+FCv/7Ee//1/0ukv+WkVKNDwYIEnT0TQbceEK/s5E4YfXpuvr69u22/x+hHZ7tYW0Fa/ joM3ftdWPj//9L9yx1GxULDWDOFWPOm7+w0ilg9BWlttX1jWNQjNbVYjjU/+vdjTa2leK4ppYiM/ xEREREREWFLpERYQtC4woiLCcREZN1tHYHnYxHdkQRCbISuBI7opXJcyU9MgegZVxfTyVDK5PL52 kwgyuoYU7eCdMyKgmetILZKAh3+mFyVSmtmDRds7pnc8IYQo7VYv2kuuCJ/dbRrrf9oIN+ixwRHV L+ccw9/fQIv8/opfVNoER999Gd0/whGfa3uqtPeaRcIq0vj+9frCp1v7PrQIj73+7Crx9f3//qvW VqMBCtxgIxcGRzr/26G0jdffuK///u+1taj/LSKl/8a5z7VbMPtf/eqempu1NlGcreEhwvxr6zdv 9i6jngoc44Ij7dXpfa9qNY09CjbWv94qtrV41xEbjYj+KCsMJf9ntz6vSuLi4vBiGEz/9prcOrFP /Ix8MKxHERFxERERERoMIaHjQ2oiIjMOUPmHYMFJuZM7Co3mIlcdvluoTQnE0ZoZXS8IMhOIwgyW RfCDO6syMkmSpCIjK6p6LHnS2Seix2F0zuYhkSgumQWMguO552a53PO1r3wg39H9BB1ue4WvMiny aaqe1PrP/tX7Bg+rne+2Y5uz2fP7716eunpunDYq//3Qilf9/f+//fDb6//7/v77dN/StU0gvv/1 /+l3e/8EN0gQwgRztfWI7PevqvSGhoZaRUtX0CC20r6srYL3+EMEPXGDMvgoGbZgcUGI5zrYr6qb s3Ubumnw1CEZj2vBn3M+5r7+IjNSIiIYQj47VC9po7W0IiIiMrhaK+IRIsjPTIUqmRLqRTKVnjCD yF51SRFkmQeTYdHdFy8ezIUkHl49nURQm9ko7BMJAhnTsrgsQWITBTt4KTSO552cjuyO0v/ar1rz RhNrp1S/oaHntT2mmvqmp3f8kPdK9957EKez5d/Cha60a2jW+vpb/ozp/df+hSb/ebs/770np33+ vf0vb9b//+tDi+/VrZ2Wo2lsR3WxH9t6Vqv0bv//vv3p00OHY0ntt2I3oEP68EP7PdntDQ9bX4Z/ 6hn++tWtRHapfa2v3T01P/2wv+KBgmKJT2xQMy6x445/z/bW1FVvQtC4uLXOe0///sU2r8RERMiE IiGEItT/n+OPTEIXiIiIiIgwmhllSZNxPEZXMkZFmQmQfZGs7G87jL5UdlSR2eO/pXJYFs6iHUSD ztXkcgvw0yCwQYQZ3bI+dxF8pedzjs0KEPVYehrfD9FjtFjtbW8ujPowjNX6Ruo3Z4D0SHSBEffM jQ/QQbQQbSdX79UwjW6MOeJkB5gJQ0IhsoB53vX4N/T06BF/gi/r/dU+vT+8Kvf5pFwsiiv/67S/ /r/7ejOU+3O/0pnOOVf3/9f771/t//7LSKl/HFts52cohYi7/+M/zJLQRd/662q1qI4j8wh22vxx wv/vVdCE/2t9/dbv0vimtUoJr42Ip9BftpNhJi1fUGboM3bXtOLU/5u0OLTQ8L9jY2KiKrq2I4iI iI4iDBC1tCwmEwg0/0FiIiIiIYIREZuKjLKkRMRCjMjoRF5XVcrmqIphAwg1JXF8nzxlTUMrrCK5 PO541PVk/qmwRHgvpkpSaIq/mKWQWIFnc+7O6s7nnakjP9fz258Y63o0NPYP/4cM78Q7cW1//5vX ed79O7ysb/8HBqFTW3xmmYCLfTkT/+/8Uvf53DndovM121/pr1/qvv/ggRktgvqdYuFK3FwonoT1 CdIYlPoc45Tme8zlPf/jf7b/6///HBx6iLjQuhHfXqxFEVDBEHOh/z/5/k0wSOzXCVv5u/ftrMOU 4Ij99PX/j4/pYSc92cwRTy61b9bOfFUI2xGGCBmCL/1+IKIJDjiCBC70IjiLC9oXQIX93+FC1SeI iIiNMy6wnGhqFCn/N1rjCERH/afeV0vLcnk+TPO5wiIiIiMrhazski+SvMZBdDOmgyC+W4NEsRXF M7oqGFwnkX2/P6an+DKrWmQWJiO/ilBgpcR0R8KQeVytmyqtr3sn354brZLQhXGV+RHk09QhEZD8 iuT5S8n1ezwbM73nffYYb3pOb/ngGl/77y3UsdXr/CDxrX/enDDF/1txDc7ne7//tT42mfHV/9PS uvS/UN3+7e67f/32KuKT7v/mDXb//9aHfSGdEr//9dV/8cfX1vVvSBDBBG/iNUwQX5XqDHgih6qv 96/tPbSb6vXCC5/3N2IX9ehGCHfdAhSMfOf64piNiKBm3cF+dHeFxgzQF7CYTauv/xFXYTVIY4iP CdrHwZ9zPugqGEgy3KKf9wwQiM0E3iIiGE0LXhpimha/m/Foc7niIiIMIMJxERaBqTYKyFZERssu gglIvG4hsqSOIq8S+JfER2R8jov2XRhEdXZ0zDjs6o/EWglemE0ygMFe8lOQtKpay0sREHERD5h6 F7d4TS3Rne6RkZBLTJiO/gUKQeNkIPYIj0Knmc4+F7zuIUK6bq5nJj/yXCHZqECgp1Ez9efrf2+3 v6tb7mKnahB0fl6SQIjeESenXv3X0t1v6pf/xptR+dzvnc7wiY6EEnRuWt19x9L6/c3v//7/7fto JtF3Gh//9XpPgmRx//9f//6+v3lrFat+69qx9qhUYLaxHa62cv/f2GlDSbPodrV0LDWlsJMmOo2K tsJN8f//ow4svow4zHa2KFjYhBpQxQOMuzvanQmKil/j21wY8MaHYTCaEWFwhaDCEWE0z993eNw7 g/ERERERERERDBCwQg4g8/5ZHyuUIRdxEtYSVSnR2L9l0fiV5NjEdzxEZbmmYipRCsKEyPFLRRkY URQQMjIvmRpF8lWQtEGEOzUIVwmdz6aZKghKAgKrp51CaYXC9ppJGQsyPEVcjSy4I2otUgRHkkgi T1/Vk+aNlb/59zPItv/6p0Yc8Z3OPBEx4zvt+fa0HVXO90d7f+vCnjU8f9eqToJ0t0PYY7///Zys 9zv/uu//t12v++H/9f9jY0ttf9///uw+9Kc+z2v/v/qv79euNbvtvncZff14YKCBHlr6+vz7meRX 1x8a0u6vqob41+MJJtpX1fX/fV98NbUVUU4MbFVyQ9Co2I2I/s5We2NbCtrERaFoXDCEZ/7CaYXx xsUxUGCURDiIzniIiPsINBioiM/5+iQXDMOFJt+dhYpqFOwNkrypmdiyEREyK8TGImFJtCUlKNxK kbgg0Gg9MkGcipZ0wpklZUsgeakdjaO687Viay3NAgTTTTRf0bqLd56Rbum1XU/2QYiZEamaO31O 3RhqFC10CI+ktWk2gm/QT076uuvnpVQwhoznCoXP+FV87unp6e+m6vbX9Gv++vQgiTwRN/HV63X/ 3dfciYpHK4Ij9vpBrt70bqNmz2FcFy1BZfr13/+GCKH/6GDDF18dvfoaFjCLuIROIju/uv/9CKf1 kK/Qrfjkh/6XC8Mu2NJjSjjtUWOCI9a2lMiaAv9nvVDs8rPpGLQ1h+OlpV20qHbSb6XRufHzuVGe Ch7aba0hmFGYVWlDWznznsU7xTFbzI//i6iHQ0Oz6miFRorZ/iIjTiLQ0GmEOIj6M5T/3/jcMbhj iIiIiIiLQhoRERn/P/EHEHk3WyERERmHO8OHk2HMIM7FESER0eyWMyLpoQ79MhUSpG5E3YVDtBkL yhEhELzo0zJLypZUGRiKgzvDO+Z30IkoGJ2akNFuyUMJppwgbO1AT0Z2Sju1X8+rTTQaDCDCDOsE GEHQTb6qk/CbSDq/b02qeEXD0aKNFFvTkEEy8aLt6dKd3U7urR/71f/07/Tek2k2gm58bDoNoIN/ pXrdfFff4yKA69v0/T09OrzQaNPXX69Lf/9+gr7rr//9dB9fe//evVv+qzwU5T5Y5hzv9Cv///0r v/2saTHVq2XRHtK1BCsReEIva+6///+76+0ml1YaSEcNW0qW9W0kbn3Xa2t9raqiFHueXYw0rCVi tiooGYZr4r9hhdhpMMJNhJtJ6ajiOGEIiLCn+GmnERcNNNcVsVFMbHGMsc45Q9YiIiIiIiIYQhhA wmEwmmEIg7KRiIiIMEIiMmyqjuxSrzLMSCx3NSbfhMvkqZfCZQGDuepl2QiK9xKchaNedzzJYwgY IitRL115uedjiZfPR2p4KU+mZJQWyYk1UujNHdM7nmhEdqg0+gRH7XSbngt6Vehghpf5fPVWnqhG jdRuda+d904wg6MOd/6JDpKbNP1/vvLdJNpNy3WouFS3S3XW67/ne87ne72v7/+wp8dPT1//36/e Hginrtrt03nRlwvet+VuMBCtxgIKut93n//eq9/7ERT+/j7+xZHtiyPhddav/j96T9RvX4f/9dpG /xHEfP3n7711VWNY17XvZuf/5klBcdcGYcw8GRR47jvdWt9p2KYpnPYp2Nr49jQX+4vN//bW0mws dhMKhaFoWhaGplKP7vv+xTHFREREREREREREaHaDCDCk2LUSEIsEI0zaI6UimYzkQpHYEZ2JYybd xEcRSpnYwMGuL52a5XtmMliIWiB53PK4gjuyluZ9smPkh5KRDsS0gup/7TIhH9MgxDt2p38d/muL 4IMIOrufqP68z13Wn071CGTTyadp2i8aLt/DBtAwejdOy64U/Z33vV/6Jj139J6DoIPfDDEMMaFc dtLe9X9+CB5//ugRf6ur+HD3ev+3//4qP/Xq+/UKFeP/436f9//7rXlutg4IEewgR7sjovbrekF1 wQ+zys9qqr/e/oIJQgkkI5qbpvWbsNK0uwQJOwRQ8EMEPqsuiOiOlza5bmfFIfTsUxFO7FbJuUOC 4jiNhNMO1iIjQj68//aaHaw4j6gz78wQRW8Zj5zxEREREWmp/s/9w0yiMpG04uIiIiIiIiMRE6R2 U5DiC0m39kCylBhBwyFxfITJZl8hMrhaKhybGokGRAqSM9hhc1CBc69phBmuNWUZSsozuedzyD6s p2FmcmPpuU4a2q2vot36+duKdu16JDoQw0Se0wg2ubxDc73Ruo733qEH9/CQQ/O9thl1O9xSevDB kfX6H9/X/9Eh6XXeL//+Ov//vvjjneG53O8nCrfwi4/f3agi4t+3/////tx/zsLG1/axGRcYf1s5 +pOGN6MfMfOj/+iMcof/q7bputBd9E4Yvqqtfr//+ZEtYSXY4LeOOdChbEVbEYMy6w4tfX+//xjV YtNCLW1OhMJ9D9/dj434iIiIiIiIzUiIiItC0PLKZbQcRGojLczys5Cs6R2JxfOupF8rGQmSszIT M5EtRhEsRC0W6Pn++j+FsJoJT0Rash+EHTYTtMmJMyC47+gyFxfO7y///3Qp/70a9a/5kViHY4kN bC/670eOjQF+9XTdNo77/VZ3Iym63byJhgiYYf16pt6999/evRuo2RDoER/ggV9r9r/ubVpf/r/5 qi4XoaEEqvSvoaMjP5UUP/7Q7XX9V+1r+C69br3j/raqmCFAhVq9PrTSN3s8v/2qzf/5/t9RHN2q dK1vrHvbuzkDJlH/749X8R74MwMxYNgwSYir/Q4yH7erarHaFoXDCnRFqqTYp9r9YqIqIotQXURE REREZjwYIMEIi1P9n/BNBoYiIiIiMyqCZTUNCbKjIJEYjsqRNhYxEZNh4vhBoNNM7/IJnY1l87Et IqWVJHd5uO59bRY7QdH87ViE08lEgwudkxISn1DIyPo1SDZJLJuR7ofcz6kZUfdDtUcL0HRr3qt6 rf6fp9XTaqnn9I+s73SdJ/ILo3d6nho73CN3LmbT1/1PGp4u81v+/9XVvkRp0L9f/Q7p30/0vS/p P99f33h6D/1//dqn+///K3FwpW4uFrvfv99qhw+1W//bX0O4YRQ/x8f/7b7/q6T1ttZyBCmKX1s5 xGtIRXa2vP3mHO/qOPfVraz/BsY60r6j5u8w5h3t747jQveq2I2KYrxwZgtWxGsx33eL9pQ0tVVt Ub8/7CaaHn+4wTU3WhaqmvYpit32Kf+IiIiIiIiIiItBhMIaF6H+IiIgwQiMm35KEW62iq5kqxkV 53PGW62GEyCxGsiMqIhWa4vkEyWxfVMqCOwIkjsnkvG9VpUf89moQ6QQZqEwuSiQYXy+f4aDTIuY SIXd2aoFBTv87nkJkLzufmcmPu/VdfvVb/YaNdGtp0SsS6fChSadk081CEoCk0C6hBv/RJ1Cnejd VHe9Tw53v+S102k88Cl6vBEogiUd1tfjTt03zvb0roSJRgIv16/+GGr9q1O530r4Wgte7o2UblPi /f///q/39f/ItPW8JKvrwi7iEXcf+he8N10ND/+r54Kf/pbfxGFf6XN+t9///+L/df+2Ps3Di/rG l6hyUIIvtq3/22+68Hxquvj7qf8/7bqlj1vrW+gz/it0rWI3/uudxmOd5jBCilg7Z7+x/7UbS/sR tbEV6BZwMMV8dsV4Y8GNppDJQFOzUJaFxcWhDU/RcMIRaHrtqY92qa8Hw4ZtzOD0lERERERERedE GEIiwqDBNCDiDvz/n3MzVHEREREdxERGFLIOirRTxKERVHZJk39EdCdjwjJt+QrIVnQ01CDVMguQ qCDKmjtbzIhAhDBB8i/kX+mzqIix2pfP51CWRcKmSxJ8MiIuzXIMIM7+O/zVn8lDMR2asxfv61SD 166SNbCFet6N7m5nZrJnZrIPX9//dOjdq/5/1N1J16aR36TpB/1+m3uW61Fwu+/0NPf4kSi4Srpu dyonYKjf/3110jw6nd2Fp0E9f9f/fXXF/W7CYQ9JX++//e0CI6/7zud+vV7fxHvP319/+v/f9fBi h/4qLkTDAIbrZutXhm4fW6fxn/3/+v7/X/1aqGkhtpAz9NAXWyLhW1//Y0uKjiuKzQHvvtODOFHV iuK32tBMVx/dL34XVNsJNhY/hqf4aHmRFqZWnaHpr5z5z2tpKY+NioiIiIiIiIiIiItCIiLCGhEM JhRERGTZaRC0SuMg0QrJGTLMMhEW6yZ3hyul530qhBlREqi+QmnJDnHoZOkzsbRKc7FEQNBBhByu qedmsmSoQlIieFzr2yCCgjQSGdhNOQQWM5ZWGQbs1SLgNFwGdxF87iL50ZiJZGEd3mF/TCrNbfte 2Qj0ZOre1TpfQQdBBwuvbqmFX3U8Zuo3UnVHe+81njP13PqeDZrZoBEeanfoER+9J0m+wvCtdb// Q0NZpGBP36btftMavtINOl31/TdOjved7dOgRH3QIj7/X/70//XfsY1fqrvV7S3r///+vrztZvX7 bfXP3/V/+v/366/////1/+4IbFcM3Wc28f9ScH/epwlQQ/70tv7tbX//3//pYVCkOwq99Pa9r31a 7H/pbaT16+t/+/Urqk1+xTWxGDOFihYqy6I7YoGdSDCQ0txrw1hhb6vpsJXq2qjoYU/5/tC0GFsJ qI2tih6YrYpimI2I2NiKiKiIiIiIiIqGE4YQiDBNBggwgwmEwmmrP6EREREREGEGFK4VmTsgmTGd jeZV4iW43luCYjzsHhNAyGRciDyDyKigp28XyVxfKMj5H1O6I7SGVVEsRhEsQREKSLtyLuCPcEkn l8/nY4RFuGEwhWdPCFBcLoRGmmSwQJ2oTNcg0GEGEGFK5Kv6wnmtzR+5nrrot1o0NV+efRuaNzRu ovGFIqzBkzZg1r8/1dJxnx+7U2Z3tzvbYU+PSbRuo7/W9IOkHoNwmzqRfVNU/+o03TaTmmYCeNN/ r4q52696de+nqutdXCW1PDanh9/f9fTX/X6+rK2C9eNb/333V1hFxGknrc7BV4j9f9qbuvvr/9eY X6/+++/aWvpJYQ72crq6vGsnB9fpvSbqch2km2e2+v6111++vv+DP+NtW1bX3bSjW9bXVtdD/47i oqORIUZhX/86P1YpimKrBnCxTFMRTFfEVsRX9/FzQ7YoKxr99n+wmmh92E1QtJz/rnP5zqc7mgoc qMw6pj1oL8RERERERERnRESWoRFoREWhFpooQmjBhUDWPLQCbtCIiIuIiIybPlTyUo+sROwNPK6X hAyLHYJplPF8g8qMmmQXCkoyNZ3TOxvKklJVjK5KgVOm6tbIfZqEU/hBpKe8lEXM6hdMiQYyFRZU KENGzC6dX3S1iF3qqXX61q9unQIuv0SHvo0J/andzd+eDX6LLYmdzx3V+6v+d7tvVW5oKC1v6406 2v9fX9f/btfNp1jXxbO07I4UibI4VbfRhzx/v9ddev6H0qFTjlOTe2v11/1X/vVtdbfBD/+7VRH6 SUZ/jP///23VpWlDSY0q/RuxFT+3486hf9uv+/GxTGxTGDOEse/9bSoL/hhJbtvi7QYQaYWNDU54 tDjzbKo7FPvFRERERERERERDCGFXERDCk2xFdThldUzvDs7WsqM6ZJMIM7JMwiWZhFOR2TytZKzJ ZkLWz29nakwmaxc9EXkGjOwmmE7Ts9kqECen+E3SYX9Ug6T+jW61RcP/q9TxRJ1fU8Orgi/o77pu 9G7Cfq/X/O9t3/V0u/f36Ffff//9r+/q6+r39NkUBCcCDMEJwIPgQeAg+BB8CD4MGYMHwIPgwfAg /EfI4QzEI6I6I+aMjsjxHzRGMujcZo4jaLojo0y6MI2iOj+YRtGER1j1//Qr/90n/4+1r//TXT0I tCItCItCItCIiwhERcREXW6j/7iltbr9XVWz29EqxOmIiIiJIQZTlDlYUOEynK8p0yxyx1M5Q+Qo /aa8/21aC23z90rSdNb6tKf6Ha6QiIiIiIiIiIiIiI/Ypraj3a2KiKYjYr9iu47QsIWhoXDQaYTQ 8/6+IiIiIiDCEXDBbURERldUGdrZEsMq0dgiKnGTo7WlQemFJfKeL5C8LBlTyryKojpMhMleXyUy ZUsi5mMlfRsZ2lZCs6BSH2uSoTL56kIUFjh4QijUEC2r/akKiynVIP/uF0q+eG/yx6q9XtO+nps7 BVkU+fl8720SH+4vU7vhT9mxQRddP19Flff6/7f/zvf8ECS3NM2IPaQpX96Vr/+9cf/127Va0tQq vWv5EmRwv//42PVf/2Ipv95oKH+3tfVd0990P1CH6T+GwwcajQu62c/21FG+/115j57KydAsJjX9 m6RdbSX3ROC7arav2vgh5Y53KfWo8IGdQK42nQhNb7FbEUxC9ilusIRf/nBw0LQ1BC0O1Me00Own wzNPxERERERFghERERERaeTb0I9Mi0QWOyIyW0ZTQyuS4VBoMkuEypR28XyFaklIqERdBTsRnZSi BKoKjO0Yd6ZKggXtS+f0GdYINDJRF3l8/hSDOzVkYIdkI7mjvI7gyveYXBEo09B9GtqvT+jX1mHS Sa/r2g0ylnZMmmEDO0ap8KK5v839PP6nf/9PU7uEz50Z9e87/Rv0naEER4IkO1Cvwi7/7eRKLhVt R9siWYCfq3W4pN1X/pd0k3o0OkZ03PRugRf7/Xr/vTr6a/+q//366v05SgxTfTTpOTJEfI8CKH1/ h93uu8/fMe+rUzlRiP+v/2I33X/22/+whER69Z3GY4jiMd7Xhm76Ghw7pMffHv/XfMftr19M7mH/ /bXRFH+2uQIF717DP+1wk6tKDP9W/2wr3bHY9rie9r+fKcjORfQj2Irr2Ka4ql/iKtiF7DadQxVr etxDiIiLrOiwhcdoaaFod3prp3uqfYiohxZ0RERERIKhEQwQiIiHHO4xaaiQrIViIiIiIZTTst1v VSUo4iMZ2F4yulqQcoPki+pri+E00Gd3F+QfakXB92SLTuctO5yw8FFZwI9ZTbQV1TTwmggmgl9t Gdhf7CYWwthNNTUGEynEOxxDtxTtx95voUgRHGFbp0nQIj9z/hPNddXV3WggwmEwgzs1jEdjxv/Q QSNCpqePXTdb6BdpNoECugRdc7/Z4Nfm/N4aL5ou2EIYQh+9KmErWv+/4hJLrq+l0vUafQTaCdBN oIG0WOXDncm79CEF5v6OL//Xwgt/1+7/0r996enhO6tP8II9/vr//v6CPd/9fVf+////V01crhQY CCW1VVW9bW0vSCW6Vrv7/72v+t//WnVpDiOI36YYSbWNUOGre2mlaat6q9bDCsNJtW1u9v4M+88j HsRTFRTFbFRURsRURXDBK2ITGxUUxHENfOdTos57QMINBqc8MINMJpp2OmmCYQYTJjpkxxURcRER ERERERBghDBCIiIiIYXK5hHa1iI0ztVaZCeZJQyWDldYy+ChMhIJKFNcXzu8xkVZ6CDQZLcvkryE MjERpHdEd0ULYVFu8EzoEBVsJ/zYwi8YW9B2REFJpBMmmpNI9E0R+Jpnqm4IlFBNuETeoIk9XXpt J6Dq6o0P/pV0k0voz8KNPgozdBRQIv8726enSbgi/6QftbW07W00114Rd/M4uFRr1ou9ev/t1pe9 fHEER+1tb7X9//ri3Xrdeuv+uveVEd/CdxHfzBAhK3AIEJTr9Q/3n7D+H70///7///jQ0J2sPdc7 jMbaQ7zuMwjVl9YIjjMK671dXI5BYMj5HQXre6wRQ7LommmXV/w7drtqCKdr+G0whFKG1dVvStJC OIjb1VtVQlOOJTjJoZHMmgpHyaCEfBMuoeIrPkCEY+DHCc+bEUxFMVLHMOcfMPiK7CV709PLgcuB ouBg8MIQ90IdlbKbCaaYQi9FG07FNU+9PT01tnZkovORFxcRJahEREQwhadp2np92nGIiLiIiIiI 4vVSuZIrhZEUztaxITJQiJIREalLRIR2ki+Qv5BwhtjCCIoGaiLojpTJKyp5rZ6NfK5IJaYW8g70 1g4iOz2vqRgh2OIdjincDO7I7yO1jhd9+pvvN+aDOpnBzPr6bwgwg0GEGCDBEJtUn/N3VHj5Qugg ktAhoGxDwp+3vTui/ov6L5ovGiY5Q7Cf6GK07IkGF3QR1B2gklggh7fX+E3CbQTaCDaBCDc9H//r 8QSUQgu0Ek9+trur09PTpO37nO9rRj44R5TooI99X8e9P7///32zd7f74IJPwl3kEdqvr66//+h0 P4tL5z0PsIepF9W0p/91sNWGkwwrDVtW//TGP3jVhiohMV+wwXiFFRCYqKjn/n+IsKup0J2c6qCa r2Kwwgwg1CDQYXxEREfERGCEREGCERERBnHBDxztaxERGTcrRTxLs1SeU8dz5XVMKEGE0wkQmChB ktzGEGV+yVZCvn8yFAiM7RoaBF8EzqICot2E9AiPGRmIuWXIv/VIN02lYIlFQiT4Ta6CbX1vedrV PPTpPTmIKM7nHkFgRMeKvO/p0bvr31x//oIu606aCerXbSbofQIj77W///+rbf+q//6+hu3//w+/ 4f/9q3//YRFdBkdEetbWI53GY38UZxl+1b0ulPf7+f4hCI20m0vDa9rhvbSvVtTJYDH//lwUPimK nRwY6YpwY2NiKYpdbVKLsIT2GE0IiHGhDsJpqZHdiOIiIuLiIiIiwpZFPE6IRk3A5UzskROiLZE0 QSIVkLUrksXztKwmRrIaORqlIWrJKiKokKTxyEHPqThhBggwQMixlTyFdb8hOwmgwmgiLacGSk00 1ri3tFjtNP8sp+r7BE/voz53FfMOGm/wm5/wnhBufM+NAif8sr90CLr114VNq100GGjQ/9+CW0nV tXr/eVwVUnnZaC+Xt9V6qMQ9N8a+Fp/rS7yK/rx39iP+vo4v29/EEF//7GhIzkM8yHOQz+QI4gRx DPxDPxAjyBHkCOIEeQI4gR5AjyBHECJljkY5fkCPIQcw5tl/62dGSH4X/dZzzpglvzn+gjytf9/d r63f//7Qi9CP9/6OiTg7qthNe4hWx+6hBL1fa+jHkqxOmIiIiIiJBplDngqCozDlDlOUOUOUOEDM OVBWKRwWOCZ3O5xyhwRH2Yczljr7FpX+wopYj+Ew3XhpKXGwwraVpQ1r8RERERERERERERERERER EEPG/ZHxBnEUphzP6gnd9io2IUbGxV/1DCEY8ehPIRxaEQ1PBQ5xwRHw0GEwmoMfDM0/EOIiIiNC IuIiLjvEREajK6XyuqalsqV3LZLBC0gRfO/iFRXU5QQQ+7T0bo+vtIeu1vK4UDiI9qz3BnbKmP8Z /xHK6XnawpXVQhMjI5EWMIMrlZkci1H+haFoa0bqNBro0Gto0Gtvoarp3qv///5aarlwu++//X2Y dqrppWmlzwU/GxFRGxGOL9lwEy7BMuAvz/ERER1iItRlMilK4VE+dzyF5XVOQjTj7+Qw0jOuvm/s 8lKWyOiPqRQMFcoRHD0EFiNCI1QxLl5nzQU5h80FDnegWdHJ5xF8Rdh7373y01XBg///4YO1QiIu NglERisk0/ZTTQP5AdMKP/8gOmFH/////////////////////////////////////5AdMKPIDphR +ACACADv5DDSM64KZW5kc3RyZWFtIAplbmRvYmoKNDUgMCBvYmoKMzQyNzIKZW5kb2JqCjQ0IDAg b2JqCjw8IC9MZW5ndGggNDYgMCBSID4+CnN0cmVhbQpxIDU5NSAwIDAgODQxIDAuMDAgMC4wMCBj bSAgMSBnIC9PYmo0MyBEbyBRCmVuZHN0cmVhbQoKZW5kb2JqCjQ2IDAgb2JqCjQzCmVuZG9iago0 NyAwIG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1OTUgODQxXQovQ3JvcEJveCBb MCAwIDU5NSA4NDFdCi9QYXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8Ci9Qcm9j U2V0IFsvUERGIC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9iamVjdCA8PAovT2JqNDggNDgg MCBSICAgPj4KPj4KL0NvbnRlbnRzIFsgNDkgMCBSICBdCj4+CmVuZG9iago0OCAwIG9iago8PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajQ4IC9XaWR0aCAyNDgwIC9I ZWlnaHQgMzUwNyAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEgIHRydWUgL0JpdHNQ ZXJDb21wb25lbnQgMSAvTGVuZ3RoIDUwIDAgUiAvRmlsdGVyIC9DQ0lUVEZheERlY29kZSAvRGVj b2RlUGFybXMgPDwgL0sgLTEgL0NvbHVtbnMgMjQ4MCA+PiA+PiBzdHJlYW0K/8gOq1GQHSajIDqR RkB1Io/////////5AdMLxztaUc7NF4///////////5U1GVVeP///////////lntFrmFIWhLRquIj /////////ybJfctZQo8f///////////////////////////////////yuKIj8rjQenmo9PXLZCwI /dtZ9NivsLeGEIx8rlkWyqD0EH0TsOVxtEfMegQeCER0G/rZ0f3sNK/FcQ1EGUOCiPK42FLaNVCa eajek/7LZCwx6W6zWUOcfgwk4i9ivhhXxEfK4lH+E0y2Uuptee3vVuy2QtEcE7dId2+ZyMftjcXw 3vu+sWhaiP//lctUrizCZbKzl+EML9bo3pAiPvoa/f9z6/w0/6Hel2I8801EQwoyuWqVxdEdBMtl UpXEwsMjxHuxEPN2Qg71c2Q8Xr+rfV1uVxML1WoajnbJoKiGpXGkNP5Dtoc7TiGWysBMzlDnHaXE Qbnc7+/39d77/EJfyuLj79bGWkpKItDHKZEqE8ER6W6zpNwtOb9/6/vd8Yj+dGIy3WfwWFgiTy2B VHXhLXgidx11ceGl4zGGUOU5Q5TlOCzw8RERHgxxB4e8tyzHZhEdG1iIvIo/PNcIFEJQgjnCC4SX H86MXrCwstwsZH4QXCJvGgm9+MgKFCzxL48MfB4h7xy3LMo9+v+P5jyAoKrWO/XEf//LcK64PDsq A4hh2RAFFLhFxluFDel4LtPEct1RwnRbh0E/fV/3V12stysF/mRiP/yxas7NKqjLdaUtyzI6LoLQ iP57PmKTffruutirUGFHLdUzChNOr0Z/rv7/X9b+xFWo5brNLcLCVzgKGnbPeOucBQ09nvHvP6iM twtUz60nv9W/DWh5h+j/7iPlus3+pblcXC79T/j/u/EeW5Z/l8/17//yAoKK30OI7wZ/f4jy3WlL dTEhaJ3wmtDu57xdcw5n6FqI5bqjhB0W7LYUvCD9b9OWwVIjpflsCgY2q3pnRw1vsU/DCqoiOW6k jnK4mIEHcJ+WwpdF+2E34TaT9X//5bAoGP2vbVup0bFMVfYW/EGC+IjyuCKmWypiaCD6L/K40GIQ bqvl2U5T/uI7r7hhK9MVcQwojyuLM7PF/QXuuWwLEcujPbTf/z2+v+3+vVv7erv3jStj2xVvpoNv EWniOVy3O7HtPo2dJXK42ZeT3hCK/BEfdcyPXuGF+UsMRpOMyMRyuLlTo16V9/ZbK3+jGg+uw7aX DxGHqOZGI5XFc7IHU+lLYVF00a2v0m+/ve68tgUDGP1purM5Q5Y/N20sRfWxvfprqIhghGOVxfO6 vZ36+ndd/969a7BDrXBmAUM2qu8RyuCItlVqd+H4fLZWTlcaBcGGXVJC8yGETH/LZVRh/oJ48LtV xEcrgiplsql8+r0nW+VxoMHc56rDvzIcOP4bX4PN2ONXaqoiMt1mlcofCDBS2FJZoZ3AQLSdEols FISlYIm8V06C53O/f/v1QP+7fM4zH77ScMd2tisH2KhoQceLgwojK4soUtrPnos18soUF+P87Hjb mzbdPp9kdL43Qj9+GEGlzdES2CkP+FFqZpoFqOVxeO6stgL6qWwVCXdeqLvztwXhB/4+ZG++57+q H974jM5T40Ixlcb66MZ/LZS7qpbJIJ9zseOS9rVUYc79prfW+I6/uHDh/eGbojt+u8LFpqKiIajK ZGuVy35XFK1/II083Ox45Q/pqz03/26q+rwQqg+vEQ9QZm0a/UWFHK5RF+VwNBcmhnqK2n53ujQ+ v02//b/+33+2Pekw3sRu9oQ1EeVwTOxyqCBlsFeYd0Sdpp9GP53yuNZslpuEt00P/fyMfr1xRvsN K//HGl8MJpY4MpwTXEREZbglTlcXq8IthYZf+Yl/wzGv+tGff2ut///4j9ft9edGI+ItRDCluCMa yuW6RbCopXFe2EnXziz13wgzH/+vq/tbd//h1K42GIjQ9fK4rzozc/Q1xERyuNqny+fy2Uu0v9+v /vy2QVlwliPT9TcoM3Rru939riItRluWqVwRJlsLLlcqSeXz+E5XFglaot3S1eE3nc7vfV6739d/ Yj/+95jLSLV/DN91x7G/Gt8dDiDCGRR8ZyMtyRCMriuCB8/plsFMeq6Lt636e1312tvXLYLLH/Cu qZdZv3ggRHP7FU3a2qeIgwVPERlcFUKWytHK40C5bIWfpQ+ez44J4q7mH6v7/1+t62uvYqIu12p0 YiOW6pF+Fur53fXv1V/3riKvDCjlutfluFhaWb3+PuW6lEfShCPBWcBQzHlutf/luWAv8yOv/4j5 brXLdTEhcw53Wtv/+//bq8cWoy3C8gKEnUd4PB2eA4g/luF4JYhUFgrWo//8t1rluWAuQFFL95oL dVFBNjpv/91bC2KtR5bqkXoT6MPfvet+q963XYtbFWFHlus0twvf/vv1ppQQ7UGcBQz48tyWluFt B+cfpW9U/1/46tLaWI+W6oyPV6vRn3rf6/q3+I7VqOW4XyuCdyuK/IOAop9t/nw8e6t2WwVv9f9L /lcbDFq/ptKg1K4rRiOgwojlcbzvT9lsLSqXz9IO2AR+9v/U+Hhv6tW3X9V5bAGC9iP173vORgz/ bWtfcUP3aDQ8REct1tSuCYWVygU7HClsBcWkC8LlsFQR6Ix8/0hzOn+ccz9LYtq9+3/fb53aI6C/ /zs1Cv944XHFqdsKd4iLCjlcWzvWqejs1cP+v6nd2+lff10K9fHWbm0utri0IxyuKi0GWyZcIvpb JJ3ptfT7//79b/GWyFBj1mg+WUOblcWhxiLUcrlGd1ZbBajCpncwgTu6S3pGHMPQIj77qnr/9//t 1/Vvv+31vX8VEVxcNREMKMgOgalcExlcVr/3/r2srjYYtQZgFqVeMt1tSuUxfWFztwtb6M90b1/o f+WwsX9s+od9UGsHvopYLvYirLYU61MhDERICgoo5XBI7plsFPK4uEOzW1P9e/o36d/j9/9vvYVD 2cgQrodI3eDM2Ar5v008RER5XFY7TxbBYuf8Jl/rrf6QIj723KVGAlftbX/HU3f6jV/5v33r+FsR VrFpqIiGFGW4XSuUxfg68GWwp0Lc0Ay2Cj873HV6+CJtgs/+u/7fV9QyTYFB76Ox/qxHEEyhzNND CgheMFURyuCZbJlyuLdlskglde6Lv9BPfcevK4kGLPeo4MzZS90Zyhyh+mhFqIjK4KtlspalcXCX +EX30Py2SUyOFu17OVT/xj9fzdHiIymRryK06FcSyjkHacfNj/T9cwPGIRNp0/Oew/lshWeL+3+O IyEHBZmno1H//////////////////////////yyFij//KbR3j/////////5AdF76j/////////// /////yzBHH/////////////////yA6WKP//////////////kB0W7x/////////////////////// /////lcXFLMIi/CDW4RLGr4IOgRf9ddloA0XyPkf9/hCIkVpGfX14YW65tNinTWuGFEUIxDUeVwt Fma5kURfINHfZfJZF0W42VMszggXOsEGFsLYIP6+quuiK76N2d91PDQIuud9o2NuVxMF6H3/pPXf 31r6X/deVzV13mO23+19qv4d730zn6sV/t6UNtfeWYOGL0sK2q/h2KXurEU1xFMRRXmmE8RmRaGg 00IjERER5XFxlmJ4yFIjWdmuVMjIvwgZZn7yDiHIILsyDEIvGGdhA9ExynftvDRrYXCadAhB+5rP FWaDPpubPM+afTe9N2czYRJ3V0hqtIN9dfdNKm7r/69/X+jDgiPf2r/37SBD/HH13qz3rthbFVa/ t09rHFKwy44YQM8gQULXGJAgwrqxUrlaw0LtJzdFoMFEREZkRERtNRGVwpFpGiISO55XtEo5XFTh lpEsCZ1CHb4IofefzsT6ehShCNf6ND0SHz/SOxNd/pt0Z06jO53YTOxmCKf52XRfLpe392/vplwj ehEfb/f/9ONmH7Y3+zl+4zfWijsN/zQF7vH5+33fj6Y6Xd+00LU6I0Lv08RERERERlskilpqiJsQ k9mSxkMjvVAgyIzCUyDy/y+fzIVkHnc2EGTjTCdgoW6/rOg5ortGtrhEx6/+p3evO/pud9lAroEC v/9/pKxV19FxGr74Ip6XxX9dbpet4iO0u/o0Hf6378OxrOfH3rfUZhdVDP/S9pdtJvWeN3r7a92l FimIrBjYio0NSW9U004dqI4iIhxi8rhaLMOybFaE7ElTTMgRHYmiXy+QmdJMwiOjtIkyFI7A8vyu UhEZ2ZC0EGdq2EGFs6LkH8RI9jBRKNMLdUm9e1dO7mHLH+6vn9JPU7up3oER/9mgz6GCns+fQIuv jV+9JdN9PQbbwkKV/Sd/1/71/XcQglfvr59e6X9devqkcX9fWDTbqNY/8EK/CCTfBD38drpNK3ru rpdrTarVimlaWIoGYIKFDYoGfYoIrN9oWhaapra2oiIiIkCU6EGEIxHGVwtJnakqZaSxF87MRfKj IWlOzGXSDIHnavlcoChdbyVIugoKFuRa8gjSNEltXwhGCJD1uD4ebs73QIj/4JNI78iDn7NZn+/6 bsnCKjOVFFxH3CW+7xdf1oIdLpa+EWk03f/35h+23f/d/yuVoK+ldeUd/GYT+DJA+uoIVfuq++s8 O70mjoFuncJiKYimvisGNiM6BaYxztI0TQ4uIdqRpzbFFEREQ4zbNAUrimWmdO0PLTgQ7ERPkZlJ iJMLlmF4xhYwgyRKZJ8p8uggZ2K+Q7MO1mcrZOE0KOsXMnifO1YQFtM7A0CKH4avQyf58cw/Wl/R rYIR56UZ959EJhh6vTP2p3fo2Ud9pOlw3XyQ7TDDGse/eGR0X6SH3rnc7v/vFYN9q6S8RF6/37/9 ZnBEda9f0u///9W+qEWgQRvtdWOp0bPb63X3ELeufQhAttJtLXWO+m174SYiotSOKTg7FNfqxHFb FaaVDTodxm600OWkFKIzOd80FOU+ZEGEIiIiI2hdxFxEZaZpiJ1QiTbVFpLalprB6nZXmuL5Bo7S 0VGQ5A/VqejsxhQudGE0zUJR/TQen8ENdi9fnhtat9Z33O53bo2b1bMY/t53O9d0t1SF+v7tr71+ udlbLhe/rLSBVtUK//6/eO//Sf23rekKN+z2sRjYYWbvdX0xr8c/+xX7GxG1uq/MfDCFx2EOPN0c RBBRERERERy2SyLWCuWoa5kCIp4vlLzzJPIPKeL9naTuWmtCGQuIF1QZqCEPwvB2Xz+ZBE1VJb0a Gt2u3SqZZKNEY9Z3u6XN3ed9lO9/87p53Kj/u9DWu4YfTyDj/63a/f/18i71aax/b9/27W9b1CLH sRhr+/vq3FZ7BCn6OmEED47bX++ookBjvVCsGbt4rjYjBglBmUCKgv4tC0whmRppraeIiIiIiI5b kmQvJul5kIiufJpkaRFsnzIof1QZktikfWyDacZqI7GsvlQof8JxFQe2dIuegwuU6BAk/7z45nw6 1WT9o11sIRRCfyWIhEdERNEXRmiUoqEdEU6VXqfs8B07U7sMOqbR3uvLcLDk4ZzQEJwICIEcLPBn CIZ+cgRzPBnPAQEQz8QI8gR5AjiBHkCPIETIJJCx7EG+13DDFX/nc7yf6/SvVe77///7/VeDDfX1 7vluSYnTERERERERERESHXmNcmmF/S0vf/fOIEUP+7pbrYQVqxqCCOdr+/xEf1sKt1EJtLSQS2le l/+9CNjgmKawpfSNAwxHxzH+n2oTQ8R20LXxEZyIMFiMw5Q5xyh8x4iIxERoRFxaluSIqWTdLRNq I7JoRE7E0ShU7TMgmmQiBBkDzXF8y7TCD9ZlUwgzIWCGoRMhEChdDT69es9whrdT2+387tH+l5vW d/PZ7+b710lqKM53/zud67ik2t//3f21b/evV9//67+///+/1XjqGbv4j+29X0I+3tLH+tt99Wv/ aVeNnPqKYimKZz7QtC0z9FoRHaaEYiIiIiGCiVXluSIqWQJFSRUkQtHYmiFohaO7RNxqNI7Evp5L pMlCTJQlTIVWmmQqTMhjI8ZFEXyni/GU+XzpFPnjJDMJTstl9r292RfclHkX1IvuReclH6uFwu4T uQf6aEVl8/lBhLrv6v++/97662tyf0nb0aHLH0qppdr+3+/77p++d9zved7gw9Ai65rM76eEz5/n gQv/v+///76X/r7DGrut78Ur3dWr/6X6/1+ul/r/4b11f/V716+CGCGCGCFAhghgmR0CQTLoJAin a/7///X7bf7Eb5vrdUkkkkhFIRxHt9er6ggjf1v7cU6v/+ccw6lDmc5WXBRUTgIMnAJk3KKlJDqu Nb0r6CBbetrsVeGbqEZagxXoaEXEOIaENCDiDOFRBnV2KYimI0yONiKihDCYp/Hj//1tNNMJDoNC 1Ts58RERERERERmsocp4iIiIxEXluSIqWQLIXkLyFZC8hWQrIWiF5rRkTxJpU7INqSoQlQhKhSVi kqFJUKSphMlaVMyIIjimRbEHE6KkZyOsS9knl87AsvmsvhDVQoUKFQoEPjMhYIdQiIy1dH+QdAMF wXQfpEh6J3RblD0TiicURj9V0aCx6rdN+3DW+0XH84WCGEIwQwQz+kb6N+bu1CB5/zdqnvmsz54D ne6O96bvf/40NDQ4rajQj2/T2IN//09a//7+nfWr1319fX+2e7Pdnts92e7PbZ9OfTZ9evlOT6H3 k6Cv/7/VDY40OOOOOGR0F77OUM3Q9frTCC9X/Xbev+qaEe2kZDQLmgL1DSn+2vEK+r1utVNmZyno 3ZszZmgofIx8sc46mH7FeLFexQwTEbEUx2hpqhDtNUHp6F552EL0f2mp0Z0Wn6phNMKIiIiIiIiI iIiIiIiIMpUBNCIYUREjaGW5KiF5UZfJbl8luXRLcwiW5hEszCJajCJZmEQRGEU6Mi8ZFOZFmVeR 0E4XC4WwtqmFVVCaadhU00GgyC5WkQmQcgwhGdqMhX7W03XCuthbCuum+E5EKp/InKahDoFTke0k /2e71BEfdGfoER9tAiPcER90CI+84/QIj+vzW5nDdfVJGho2xutddJ+u6+ntL6fV7S7Rn+k4t7+j dmzWbTn0/f/T9f///TuvrelvpsIK9kIPoafdOGR0nbv3/9/////X/3/0CbWPFv6iN1v97X1X/Vf7 VbVXr9d7DQ0Zzj7/4SHHWm1W7W9W1W9bVbvfq690gYNXE9ue1iOfYlX8RTEUxFRFMRTEbEcRsWva mQrrN9dDIYe9G7P/7TTTTTCYTTFbFIQv/hTnUGRzp/u4YQYQYIGEGEwg0GEGE01BNYjP+YRGN8eI iJhCIiIiIs69nHMPERk37TILEKyF5CshWQrIXjQh5bkqIXkuEJSEJSEJQEJSEJQEJQEJSEJQEMix FuNZCsnhEy1ULpJJKkqpKaoyqOGZJcScX1LouikUUdM7K0VGCD9zBRgo4UYKOFHCjApgoyjXIPpu Ik9S3D1P52BJM1CJ+qrr662nbXvWT9up2rCKjW/2cmz3DNzZ7s5We2zk56s96VzWZ2gRH3mo2p3Y MOvSRupPe2OOONjY44pj96d69p0twwY287nekNdeqpUlX/+9fG/w7art/fpHCzhZwo4WcKOFHCjB R1e1Xt/KWq0tUP9/v///709V6pqxqEEcSv9nK6rdnuz3Z7s92e7Pdntz3Z74YW976kUfpBBJzd/j bX1HHHHHHHHHsUxixHEJrCRdAih7/GrFQ7//67QYJhMKSHBDxEULi1N2ojP+eef1P+f1P+f83Z/i IiygsznHO7EREYiIiIiIiIiIiItCLUm2uYRT5AsheQvIVkLyFZC0QtFSRrRNkrETLVS3JNU7IgIS kISkISkQlIQlBKShF0R0FJRl0E1TJs8XyEidmJSLx3ZnIqECDJHUJvqqQVUNCI0IolAXC5qCIR0f 6bTQeXz/5x/Uw5Q6mvPmZyh8zlDqYf/+szr2n0a/+0nu6EG6D70Iehbo/z/n/P/R3tz/pnzet9Nr +tXr/pv9//v//EUm36czzaI6BFP3//rjjY4tjji2Li3/qvf9oRFLv99qv9e1Vf9/j17+I/d+S4Ql IQlAUlAQlIQlAQlAUlAQlKI+F/WGbn1tIZ/ur1YjtJKlSVIJBCK40o7Sn+3qtpAz/7VTQCmCjApo KLDApnOVmHOOCmgFBbFKx/FPsf3DCehqFQ1CGhGhnJoNM/2hw0O0PEREREREREREGCEGCEGCGIjL ckRLs3lPkvG8lUbyUsxEpjeSqMRKY3kpjeSmN5Ko3lOiblPT/XTv07XXTu7TtMyERfMhSI3kJhBl XlKzL1+/uum2vb7rra8LyDiJrRHIJmsQ6RcyjJ9S+fztRFzu9P07T06Twnp6enSfXbwhzW1Ve611 X1d1pX9X9dWt1fO+zufNZ4bpJOjdand//U8P+9d/+/fe+/6W4Wm3ORglRnO+roUt5FHKdf/k6Nou q+v1/69fr//9/qh+3/rxHf14TQi63V33VrdX3V063X6v/zjlj3/q+vYik//2u2ratpNq2FbVtbSb Xb6a/FRf+9z2x857ulijf7FbFMVGxUVFRTGxXeo2vr+2qHhLsM3ONdbhqmmgwmg0Gg0wq2Ipihf2 Nitr6faVr4uIiIiGCDCBhNNNC401P8cXFxoXiIiIiIiIiIiI5bkiIHlOiEMghEsIlpEtMlpktMgj IKzILRb2iNrZCQVNBp2mg0GgwgwgzXKd0zsTRCZTxfUIGVaIVHZjLoqMp8v1CHo0Ua2jQ0a2jRRo ot6Ldot+ZJxDtxDtIIdO1vL5/CaZKRAWzr2E7uiMf03Wk3XTaTcJug9N6qkuv/Nb17XV/PPSur06 ur06t1aT6N1G6u6O919J9G6gRH33Rn9cbq6b+rq+6dJ6voaGdyo///WToxl1pCl/13fr9f//1v3/ 7t/9/7CcRv+/7+z6u6uvvurq6dbXbtd1X+I/0t//1rHura2rpOrq69Olwzc2cn8EK9Q90M83Zy/J wx9fWGlasMJQ1hpQ0oaw1vzIgMIV/30Gf9rrHetN63mcoe0xTEJimITFMUxTFMVr8YMygR+xX7EU DMEEV6EHcNBoGEGEGg0GEGEGE0zoc/xadhDhoXRutO1EREREREREREREREREQYKhlkE2QWIVHY2h GW5KirRhFPkCyF4QMEQhSDJSEJQISoQlIhXJKoTTzUGCKBhNEh2iY7TQYTTKeMlegztLifKM7nko yoIy1LYV7VUb2jToEDaNOjfm9ovnmVXpnZOLmdQsep9IM7VxcyMRdp6Rh/TPBrTPBr09XTdXtpcJ v9Gt6pfpo19QQ0aPp7xpsadb333p6dX+0nqd3Nmez536bqCL6STddXtLSunX9f+/96v3dscStxtr db9c7nfT39a//fX/+n/9/xfwhv+vrt/967771/f/1/XX/+Rj0P3//zH71t10o2OOOOLjwQq6ilUn 83DP9ddLf7S6sRXDSYaWrqv9NrpHULEfzc7qNf3+77FMVOiznznzHs5850zn4M+zimtBf1sbS8cR 9hNNBoRERERpxGhaw0PMMMeOLTQ0LSxEREREREREREGCEZ0Yi1LclRL5V5N0tE2A0d3HYaGq6ZXF c7G0CDsgWU8XwQZqZiO1NmI1lWj/fnathBoOGRm2F0H52ri5+n+/6VGvD9bRcabQ6bRrd7r+p3dN ndn873QTdOzueHWk/b6yuDjAT33DDLrv/df/er8jH32v68X6X1vr6+/Q/qZyn/vhEx/X9//v61/G heK9SaChzgYb1dbV0u1urz//8JWlC2r6tJtKNW0m1/1+1scLBnUCNimKaWKiuIu0ONMKvaaaGg01 EREREREREQYUZbkmVaMIjETdLRZAP4VNMiMwyVZhkqzESrMMlWYiVoxEqzDJUjcStG9MqmdjWYzu mdmIvnXIOIVkSRQlNIyHy+ayNTN/Cb6appqmmmmgwmg4sJhMJhB5LWEGE87NdV1P8g4qz2U6BQhV GEfwug+6ow/6giPVO/QIj3O+kYfSMPRnOPf/9fdb1brBD9PW0XHf099K9LdU8Luqet626nhwp3fC ndzvvtHe78uDO71ng/ftAiPvCbhf1eur6f/V/vq9XS/X9LS//7eE7vzud497VV+/d/7+v/+v6/69 fp/39/X2177/dXtbX1/+6X/6/+l/9eldfpfr/7+h72h/fsRT+//uvitjqKVj41j2PY1j+Om9IEK9 V1r/1f/W62xa7haV1oK0rQWguk0u0sa1fU3brm7d03QZud6V02umKw1io0OGscNYa2l2lYoGfYoI 92Ma6Y2OtiNjYrsJoREREREREQ00LTWwmunx6emmmoiIiIiIiDBCIgwQiDCDCGWsFIREZNvyNIgS KmiFo7FEW+iLc8CctyT07TshUpCshWQqIVmqU7V52MQQyF5BcqM1mQTL52ryNrqXz99dffeQUSQf ZqcdwRLRCL9moQJhfP6Z0i79df/9dathCp1LuqLhrquqfv/1/69G7NZ4+fSN30bsJtHfb71O//50 ZcIROLhSJxcKRJlwhE2XCESZHCkSZcIRJlwhE4uF6Gm7R3PGGE0h7oVf3tyGlpb7Efrf+uv693+l v/H/+vvmgL9P/am61P+p/tT/an+1P9qf7o3Jqf/f/3Cfq/f4/14Mscw/GsfHx8fHx8ex/bOV/7zh bOQIbnt19Qs5GOttC//6////6FNr22vHSHdX1N3Vpdfjji4449bW9/FC8VBkdEeUGcJY2I9/14u0 IiLuLiItVP9qniOb/P9pprHDTUREREREREcRERDBCIiI5/QkYpbkmVGYzXkCyFxBYhUQrIVkKiCx Cs15CiOxZHY8bxEjEdrGeSZJx2LfCrZLiEqEJUISkQlQhKRCUiEqEJUKqaadhMvkJEpRiKvQacMI M7LjI4pCdU31UKqhVChdGtnaQRrW3CaD2uGix3FLdGH+jdRuzdRuo3Zuo3UbqLz0606v1OP6bNZo INzPfdPfQ0NDQ0NDQ4wh1tGHPFK53/Sv+GHWM2Nde9f//9PX7r5pFwvVmcXCq4YZH96cnDBahav/ bbe23tu36+3/6/1/ofrqP9Ls52c7PdnOzm2e892eWe+6/tJ/an/+8/3wi46/Mf2Nc6hgigYImC5E wwRQMETDBEwwRMFyJhjbW29tfSFePH7SOgr3TrXuK1XTVV17XtWKY11aC+xwnhhYa/pqmdGZGZFn QmdGZFnRnRmR2ITUVTFC7WPUFmwwxCHiSaERERERERcXcWnENCGgYJqhHDBfbtRMIRERERERERnI iNRGW5JkQlNcaiJaRLSJYRLSJYRLCJYRLSKvJJnYojs6OyaISN52dFfPhBhL9L6/XOwJqq3ZCVkH EoztVDqQmQediftNKpznFTnOKHQcTMgoVOc4oCJ+c5xQ6DiZkFVbCF2p63Ol509T1FGsT/PAhX6/ un6/6uvSLHVPwr39/mcmPS+ltfv////r5KVoI+u3V/+3qFCDow5x/3WuOOOKjY44pj0GRwtCUplw jr75EmXCfdjTaW5OGDsuGPWbv9f/671g1f/Xrpf29ffXOfOdzos5856MfOfOdo3FR2p/ufTU/0K9 TCWp/qFjff0ZyhynKizH7iP9f+///cbx+MfRndpAhFD4Ia6/4iP3//q9Wvf/da+0+89MbXtTc7r9 960zn8kWkiwjLCRaSKwYyRYSLCNRGpnKeNbtAzhfBnClTHx1/GnH2vb9xGhDQjQYLF8XaFocRiIi IiIiIiIiIiIjluSZC4m6VklRkN52VGa8jeRfOxalcXEvVTsTtPBFD8zRERRkUggzsUyFZ2KKEH+S 3ztIJl8/IzvPR0CxBlDTkYM3UWOztIISoVaL/Vfar6Qf0m+79BOFC3hBvv3Rhzv+qbt5uz4eMJGf C7pukYcw+i0gtV7/63f/fdtW/qxp953O+qc7Lhgf/6/cQYIFrwaj13+aJvXXb/7rXkpDHuxG6of/ 9BEUHSf/+5j8GEv3tvDLHMPulNaI5WvHuCHav//2O/DLgrYH1aFttZughtpC0F6bS/tve4YKq2hq K6indAo2tlJDBBXG8V1ERHFoXDVUzqYQiLhoWhcRiIiIiIiIy1DXluSRCom6VkKM7AwhkKojeazL cTR5SuF/6aR3TUq0qZLIvlPF86RAohM7JIvhBqdkx+vRoaNut56BDRY7TsLeejpJnTsL1YQP/pN9 fSCDavv+q/dOETv81Ij5tG0R8o8vkjI+R0YRHMzy+RxDOI6Loj5HI+RHyOiOZnEciPkeMxSOKfZH MjojmfMj5dEfI8fjDMIujOLsjovkdGeR0XRHRHReM8jojojojoui+T5HRdGEXRoikRfNoujRGEfR QjolMLdz3283adGfoEX9+p3e6O96uCBuVxQMEzBEIiLQi0IiNCLiIjQiLQiLQuIjiIjiItCIjQiI i0IiIjBCIi0QI4RGEIg0LMwSuLK2yOFfdteu67vS3f//eu+1IcfTTTTVV///9fDCjv/67da//7r2 Y87iE6YiIiIiIiIiIiJ07zGjbtT/Q//rekLutV/tJ/9XtpLj6nVEeC2t13WrGkCFerrDC371iHue /m6EIptJi1YtKbuvfUNJiv+6Ghb78KNimOthZ02I2NhRGmubih+Li0zkwmEwhaGFhhBhDEREQef0 IiIiIiIy0hBCIlcayFcrled0yF5N0tBBmRRG8lSKkiTaqQxCuTvdpou2naaoM6yRF5UyMi+QmdrW Qkg6f6CDbXR/U/ow7CYSTCSL5hezsL7OoQJnahnq1X06T/qkDd0gRHHCbW9XWa2E7/63V3v06NAh U1vO96+f6TzQG1/3fdvvXqtpf80zAT1Grr//r8NW6/c3rRxVpenvv6hh3v/q1Q0N//1+/eeCn/+/ VK/hq6Xdrqr2sb6io52CBiGbrrDHf9sJRz/n7aURoR96XdE4LtrB/r2KDC/dj+aliKao7UvinD9x EMJhC40GFOizntB2hfmRDQaeIiIiIiIiIiIiIjluSZC8myxHboyLmTa86KVwvuybBYiYTO7ZHiVs j5LIvmpG47B5BiEfVMyNUVeQn610XDV1sLoNNEWsRUg+wUzhnXv/o2eFrpOt0nzOTHt6r/9IdW0Z 9oEX+d71PFpqCDzWeNTw9+VxQMf+9b0t//iPdN2df/zQMVv+v/f/Xzsuldd4f7/mRrbPLtfX6/fw iMH/4f/ozljlDybhS/8XvTdU3/rFLbq/w4rJwxiIf93/DCxaxqxpa9pWuD6142qrRu7FMUxUUGsW KihFpIGZOuIuLTTTTTCDQsJoNDuPEREREREREcrljO/RUkdrMV1gzvMqSMIyKmVTppp0fSahOzsT wmRYMHZiL5BcqaKeL52t8It3/YRcPC52rrRY7ULZF2EGSoQLmhnYsJQTf3wn5x/8INzQWP38JLw1 7+/t6u3Tq7UIHR49Tvkh877ncj2BL9d6/X/WK+n0laM6dd8GDRnO8yT/743///q+v+lb/wYftw/m Otdf1TC3mP//rv/wf9B20l+f91t9BCnS7r1j7ffXF/YeL7/bC8a1DCq2t3TS/3pX+Hof1sVsUDNu YjYpiNpXjYir2MciPaERYTQYTW0whDQtNY1nIQiIjORERERGIlnqQiW6FLckRUs7S8vkLyF52N5C 0dwiCaZbp0cRUtMyLFK5RQ7C5KxSVinZMVNO4Z2aZU8iccMhIJ2RUHJdERF86pI7UmYiDRq1569b CYUJ/IOKhnZKwgyVCaDOrT7CnRhBhcEGl51YQep2J3r0CI+82Zsy4XtkoONaRo0nXLddr4Spulv7 /0+kKCdBB/nwzwYczndyQ+6ep408KfHCRnzvtGgQqep3evvr07rHEicXCavbDI/S6O6f7/8Vfq13 qv920ER0dlwxj/6u9frdD6/3br9er/r//8MQh637W59Oe3PoNI3P9Qi4+/23/7//V/0b//eYc454 5Mcof9qsXHGP9q5ExQ8aX8RUV2t1Hvr32sVmgYxF8IX9iKVU/20uFtLbdNYVtJtWlvSiNtLCpveu tqblN2bo+xjC2lajBhNbFRVKxFXFNbOhfF3EGE07T0001ULFhC0IsJoNC01OeGhaoRGIiIiIiIiI iIiIiIiI5XLEdnRUkZD5KiJaR2BGVJFSzWjsbRC4yLImwmqapna2KmmE7JYrTJJ3Z2lxfbIHnXKz muL5Rk8RPKUip5ri+urwqNbRraLhkXrCFZBQinqDTuGRHef9O41L59Epgg1XNQn9F3p6eE/rpeyn DV0DX10n609XW138IVtdbd0b+jDne+IYaM/Z3e9voEXXPZ7X9Tu9AiPujd9fvV0/49b3hhkfrsQY b75EwxSd1j7+5E0cRdLX0Ov/+9f/uwih0h//3/496pLhMIR//vbPet1qEyONz6/eIwi4/RKEElVD RnLHKfvWxH1v/t/420m1bSQqDC93qSgUPfxCBClxF7rJ/N7saQo3/7OdP1bW0rVkxwSH7rNzhbGq Ceb/vrEWGbur96SHa+fsUxTFBxvaiq4WxUEGYJ32Irfa9WI77TW4YQYQYTU800LQtQtppxx6nPFx oXam5RERERERERERERERoREREYybFKMnRC0QvOxJHZhkQi3QiQiL5kOi3SqVwvO4k1T1IVBBpkFR hlSyUR3r2qDI1kJkqi+CDIWinGdiedcjXe//slARFu8J2Sj89HZrBBoaanQKnYTJTBNMlMXZKe1P 9w//+lT+t36+jQ3pXmtxaNdU19anHD16kUVdTud9N9Tu936nds9nvTm9Ubs79J53O7ptqd3u74hh yuKBjztTZHChMuEImy4Q7TsuEX1fpXrvpccfzTNhHbS7r91dL/vNEe8GGX/9enrr7df1/ddP/pqP /2l/6u+2qDBDQ6Mj7U/xm5MKf7U3X+1/W1Qv/9XRG/+utLf6/Q/CJj/+P+PjV/vXHQIVUaRFdTfE Ys/1uttWNLWNIigYxn+dq8IIP//7+/vhrutTc3VCP86BWLW11unWkbvcQnv+ONDjWxTFbCwZgpbC XnR1QUUUA7WxtYMwS/ULi7TQi4jQaaFpoWhaZzxEXZ1NJjtDT1j1xERERERERERmREGCGhERqWYJ YiIjJsUoyU0VJHYkiVBCFo1ot0vJ4lmdmilcLzuJMyNclCtO0k0yqZC4qWd04wgZUshMh5CJM7fM IqSKhEJnau352tCLkonOwloyzyWsIMlDTJR96fyD+KCd2nee9et3X29fut3TL/ND+9dXqr/ow53W /dPZy+FO7qd3+wboIP7NZnzwbM77f75XFAxXW3X/xkSjAX10t6cpWbEBh15E83kcifOJaexq13Un SnRF1vXv/161q0v31/TChsVtMIaghrur15EgXCZcKaBiH53KcrNf2CZHwoIodkcYJl0kjFim79d1 2tTDnfT1X////8dRHv+oiojiNxq+NJjSBChoXBI36jP8Z/v7relORGf6Mivv7b2THBMjcJhZ//aX WuwgXf/2vaT/6r3P7v+1GHEMEIZgob+0rCwZtz4UuNiv+KFimI/9/4000LVO0otOIaGqGo2hx3do cXGuoiIiIzdERERmgpyniIhggwQMEIiIxGhFzsHCIyuWx2tIyHR2KIyOjtCK4uiUoROmnCZ3kmdr KTIVKdjepWdMhTL5C8guqktM9p0VERrIRFPl0SrKzkJnaUqD9clIhKhDtWIp6Iv+vZF2gztwkggn uDOpmCQWezqETC2p9EoCnQKdqqBOjX/dVX7vX3VKHTsPTcxkdV+t6dUEK03/zjnijDnfOOd7vvzv vqd2jdZrO+rIxtT3VDMd6NmkCI+/o2UXfq/9pfW67t9eluRPMBEt6Gt0nDDMJJfa30hIaI669v22 m0dzx/X/t/1twwv/6fr6Td/HVbv35Thj99pxf/reCFXf7feh2v/oznfdbf94Rb//0P/0KH/bvX1v 22tvqCFbekONsa2c7/SOqCQe14j2zlOj6r/+1+SdPav16zdrjX9IpYYdXbVCFsUqz/j++puZFwp0 C22tivBodiqjeKdwZlFiq2tOKFioK8Kzn+vbEf0lx2qaxoWhaGqdoXGmdCaaawaxd+bo7TWixwUv ZmoiIiIiIiIiIktxERERaEQwQiwhEZZUkZJ8yA0IiMrlSLc1yUhCUZ2JBCVGmTxKEVzJFcTRCo6K p2iIVHa3KkqSZU0apikys53TIXggZ2TZvKhFPmEVGpKQiZRkYjsT6nvwhowVPaMFmdkqCfIOCMmn kqEIpGkn2mE7OgUiYYSY1OyYX3//pB0uT9t/r6Lh/+lzhJQIl/0brnp9z1VyQ/Bg6mszv7Ru1wnh Po77mvPBr81mis2S0gtW/6GO+NXRh0+GGNO5GkbNd6Gy6I69+zRfvhxpuzlT6MOd9ONuvuoYWvrv Dr4TCFfxEa/hMuFX2m1ePbetxuh+59IwUNGCv769/63v9aVeP9aj9vX4MF5h/a234II5vWM/sEKb Oc6NreGpubeq6zhP7rm76G57o/ue7SfXCCW176j1tJtR++joFbrurbztWF9/MPj+LYrj0KihrBmC vmgYYquI0mGFs5NhXtUrTVNUf0xdQ0LCdWh6m67VtDhqWFio4qoqZp0ERERm5DN0RGbioiIiIjMi IhhMIMJQwhDCGIi0diaaHGhEZviMsgqZ2LISKZJAgiJXA0IyuV53SIVJkpipZdBTtRqkao7E4vko jKM7E87G0VaIRKd2jCO0v36Ld56CEanrL56RlELyD7WZ2kEImRCRhnVWmmRMMBOztVCf4Tf/1/rb eqdpp3+tpf1d+f//uf+d7zWZ2U60bL0jP/eeDXQIj7ovH/q7/b/49fp3QZ2TRHSpCykir3J1qNN1 8JrX/dC3dMYRQ+uvX87GMIR4/dYTLhTMF1/8d/1GscRU8FCP//7ksP6/r3/v/apkoiONQ2o7ev+M /7PcOPBDFG7Mjr+57/tpTdQqbmzdz676tcfj6WvpW6vWP+x1wVbuxexFMUP8ySrKHMD39hWIpP9M IWp9laHV2mh0ayh4jjQ4uxTUzlPLSClEREREZuiIMIWhEXEQwgwqERtNHaUhEREZXFUV1qP5LWSx HYtCKZ3RGQIjLzpneuQuh2EGmEGQuJRlREkyUpSWZfJCPpMhWQtFS0yERLMvkZl0VfnZKjNEZkbW jGe76uZ3IPsGyUhFPfYJhBAuEIyUhCL9kqENAXTC2FhnQLBETiFSYQPPo1inYndb+EHSDto1179O l6X1p1dXSykCEpEpNbCZ2TE//9XPh402jff+ZxCnfc8GzNiu0bM9nzwRHuCLrlxzDNpJdGu6otyn S9/1tX27V8b8lSLougih1TXuNWkNdCKV6vaV8IP6c7nejDnfdN29C6MOd+1r+vX63v0IiPzaS9Xr /czZcLX627e1r+7v79DW+I/ffre/iv6W/++v3//x/r26TbttYML+3f7XStd1hm5edH7fV1bOQIdn v2p//W9cRv++3aSHZ9fwZuf2lDVuu0o5uf3Ed9Xx1Haj7f2kp0C3/fxFIseaUXd//DFMVGLFLX/x GxSgzBViviKYikpsO/tXtQ1R6inbW09bQaDTTP96canPDTU3KkbrQ7TzOU4VC07HsUDBO8mOcfUV EREREREREREMEGE07tCGhBhBgmhERFhC0IjKDiGoiIiIiIiIiMsuuVzJEdFlSZ2JZlVyuF53EQqU pedjIIWU8QojsxkbR2J53aMI7PkJms1VZXKf+jGeui+fyKRpIPTU/pkKiUBCFQTspYYNAXCbDhkF R/63+v93To19Gt6+pKQi2tIuGg2GuyHacf//1603pNvvU2UkCI+7PBrzQa3CbmHBow4PuH3/ayJ5 gJvxq/vepFF087nfXjTjTruG3Dfz0lpBav/adJraf/19E4LhMjh3/b/StK9xBsQb3w39fYjqbrEV M5TlDlD/74/ob////X1XGVxUH9sa3oRF3X1WciM///+6vfItAgjsnlyBMjjdf4Zu3YZudraW2lNz 17JQE/vXV0rSikIUdVDL2jtdVXTsVx1/6XasRTDShpNhWCgoIT5X8WhcXEXdhPi480AnYppjY4pA oQM+xfaEREQyt0CERGhFhBhBhMIMLadnaeCIiIiIiIjLIJ5zKkiKoswelcty6O7iFSDVNMpWQrOx EQLIJnZojGdgTOyEdcqjyDR2pRauihb+myUhKMZ6It5KQmXR+VT+E8INPP4QZF2EjW7O54QZUCkH jX9p11q9aT/VbRobrot2mkuTS5nYW6O+/Suf119o3L/9He9Pv0HRnEJAiP32k619/9R/p8dr3/1b 70umq/es3z/6//9//p13kpGv1lbi4Vvq+l3r/UTNlwn/7p2I9XYi+KBA//Xj/o4v//fW+vutnJwQ qznWoRKw3+6an+t16b6hArI6C2mtnk1P/fXwwsYZu1Fgzd5uaBFDvSbUV0ZzD21sIP+kIiojtMfs RXsQlrBmBffXCDTEdpOuL2lEca1x938NTdHqbrT70ItMYu+x7FAzFh0d+GCEREREREREQwQYIREM KdEMKhGf4jERERERGWjRGSfLcqRC8tobUrqSO4yFxka5FEpK4vnZdl5SFZrySIlBpqQvJ8gZkXZ7 OzxkQzXDTv7J4lIgXIpk8EIyVCKS3tMksQcRMMEWNSVCKXSfZUZEwXOrL5Kc3EVyjQcj2Bmctpv/ +mv8sdBftGiQoT7QS9npGh7fS9hP0WO4aplpBa//o3Kd9/CmxzZ76s2leeDXRnFLW6TdPzwXFAiP 3/oINz2HUER4dedqmYCRWKW9kdEfoadIen3TRhzvUaemkb1/T1e8J63qd39OPVcribLhPTX/4iP/ /3d3J4uFSbWsb/tczBcVv9LePwRewKv/6mcp8w5McER5///1/STbX/o3uxZHH09e/+vr/T2p/fjQ vQj2c29Kc71bOWCFRHb4aRv2v9nuP/Z0f/uual8MO/iq//x3r98f/4+9NprDBQZh9ra3uvqxpU9q w2NL//6bEV7FLgzFpz3tdYYWI43P7aTDCT8NKNLX20jprS2vxxGbk07TU3ena2KF2KRHH+NivYpi mF/HEJriIiIiIiDBCIuIi0LCZRGf0IhhBhCLQaEREMKTahMqoREREREREYIZaKIZXK87pkLjtYgg ZKc7FYvncZJURUzkTKKWjsnmQXEn7vz2nIPsJyK5PKQoTvJCJU7z6ISOmSyJIy+CDKAwQqO552qs j3/0a22t/haei8FX03U9IihfljtIlYiq//6eazxQIj7/y703+jvv93dbQQeaCx4SdAiP3/fW6b6/ 9BNU+7/2/fBEfne9W0gg/pf/v3Xb/iuh/9d3zSLhXxFfVxptGcqJSouFrctIKX+PX//79jI+C18N ftSJ///Sd/+P9X//5z9z/rEfqh1P9DRFBf/+78/fX/N20nXvSW+O0gZhzD2+kYeK6u+rpWt+Ku31 /rYqKFiN/VhhLF4jz06zfqNKGtpPq6xr/Haaa2uaCnsU07TvTvixTFMVxXsVEREMEDCERFoWgwhE MIaERppoNC4uGEWkpqIiIiIiIiIjLT4Z2DUtyTIjJOMjXIvEtM5EpysZC0dxkLMIMqSElKOxNGqM Z2qo5kIiIyqIlXK4X3IPpO1j5BxLanslCyUaahNF4yVuzuMjkSpkeJSwmtnXO0MjwQdlBphAyUnD gyYjqjEdpKVyivv9thP2na+i3dOuhq6Ht5/Xf2030DNfhOHnr+zQW7+5rM7Vv/34QdJtAiP2q6UL 9J4TcJ0bMJ2dwa+v9+g//TvTt+7+t09bo3Kd9s/d70CL/v3V9iHd6ndv39d///emv/f1+hS/bXfp bXp91cEC7pe//V/0v6oaa+9f19/jv2u///6XXveWkFKVxUMfXghv9pKCFEUDC2trfufV9fof1+l7 q6r1oUOu/6tdvm59bdNpPpQ0/yU4Iofardba2trdAyZxxpeUOT2exjgzqQoYZHKsGYFNs+wsMLGq GxGhFMVN9iNim1tKGFJRrCaWbnFra/Yp6p9imITFbSTT7VRTGxSEIGYJWu0IYQiDBAwQi9CGEGgw p5oMJnMAh2EGCDCDCDCkhEWELRaQWoiIiIiIiIiIiQaEWCERGIyuKR3UiB5rztKzCIXHYkiFohaI XmvJUz0V1aOZ2oR4zu7l0ZpMlwihUyVCHaRKmmRetbzsUzukEHZKEfjUy+EHZE84QQZqyFMxELiV RfKjIjOxW9p66bhQh72vTZFIhxFK9rvW8Pposdqf/1s1ikNp+v5r87+bK/r03DCX1T+rwQfmhoIN 603hcEtP/6Qa17SFGHPHWJQ/rYre1ved/mH9P79PUER95IfU7v310PX9PkSZcKRKLhSVsfcGF5ry UMuFr//vv6e9ciebEr53t0rnYiLhcWR6+/99O9fr8GWWrIYTS//9r/9vfTTX/frVKxHuf++rOXuM 3xn+CZdeogmR4KEDam7dAih5hBf+tu1vMaH+iMdP//rU3S0gtWRB/HvrHb+voECF9pIRQROgY1t6 ERX/exFOkq2ozd/X46GrGDP3XiKV7WvWn2GFnHUIP3FNRhKI2oYXm7DS7jV/aX+/M5UcNTdqKHF6 9ihm3ThoMygeGCQjrDFPsVser8RaaFoQwTQiGEIu4hhNCIYThhToji00NNDQtC1ERERERERERnRE RERGWQDyfOzGWc1VDJsU6GQtEVckKktjZcGUipJZi0qUG3GybXSuFx28TErp95CoufpnWMlcEGpV YqcXwgyRw4ZAo0jhnZ8hUdGYiniPBByuVifyf/njBE6Q9vzIYJMPy+fs9hdURhQcMjAumdmvkqE8 K9wl+GH9d0mzud3Cfwkk3//aNjuDlQGlSNDuwtNro1vJP/DDciiNrq3/3X+ccw+nMX/o73q+eGLD m70/zZp532k9Gf50ZcLhsQmhXSxpe+RJlwurT+/7f+riINgwZHXd/vQ+lv39v1/Tx61/19W/7ur/ 39Cxd/rX/Wv/tTz4SNoZv3U57deozf++1ViND/1L5wUguCQRce211f/e6Md/x1wgS62vcaV+vvxG /63X2kasJOrDigQqz3a3pP/te/CS+wwS+k2K/fXDNzm7GkwwvUQUQs0CMVxthJ9YYX7Hj6GLsVJK Sppr+OdGutjQjGFC0gwgZgWxURURxYTQi4hhYiIiIsIRFoXDCTqFzbG0z/aDSxGc8QaERFnQmhEX HEMKZGTcEQidiUIiIiIjK5TnZZmtJnZbpHYkiFoikd1EdraKmjIyySIp4jXz6O4iDETJikMbUFfB TsmJdGEZo1WQvJWy+UHDJW7JWjkRfKhG4IMpyBA8pzI7CkKjuedM7E89e9f07Ca+mnkkiL1r+uCF Z/QaaaScGhFaqe1SquiQ/qfwtwRHCROP/162wm1v1pOe7BE+jXhzPp6u07fo3/0F4QIj4oE17+Sr ved7q87+bNvU8ezGl03PAdTZvvtbv0OdQwISfQLxInFwvv/Wv1rvTv/r96uIMMasikR0R8EUOil5 gwr0wQQndYa9+EEcX+69qXQIofr//9eLdqvu/H9K6ERGFQ7xoaHuf9nPCCs7EBiMwrPYan+xER7G Ewr/r+qG/67+dEFf3kY+O/yQ/9JanesYrh+kK9K9vXWPiNGPdUwgvnRGf6nasUj9G/ofdobKHMWw xq6s3ec+o1YYSjSJQFm7QVa7SiFa96zdlwL68w/esXwfF2v7BmUhTFMVTu1s597HBMV/1dPFqqM0 IjOjQhtlTQiL+0wmE1OtRYQjIwgVNDQuNbxERERaERERERERcpE0DCERFqWQXR2NMSb3CIiMrqWZ DIhURRokpHFwyCkdiSOwtlaQIGVREtzJGT5XJUdjWR1K4oC528TEao6hgigL9koChExw8hVZKmXz VJlUSZKNE3DIoC4QM7EuMgiNRlRF8hcRaIzITI6I6I8p2DOIeslwn1zD+CByF5KQir6M7BDU/oIO kp2TYTyKGEGmuSkLIP8vn0hERrRaS15oLH6XPBrz2e8Kg2jQlbtJ0CI/fTa6wm2eCY9Gt1cn/TRo a2k36asEUa6QQb0Ycz8acUm/XB6cinzjmH9b+5iRvvq/BB0npGeGHwkaHWbSBEfebMty3dbs8Gup hKMafqr9tX/ab/1psiQL//+NvWPdX1gwY1T7p19PCDv+NN8H1/31/xx++tt9f/+19X/9//192++/ Sd/v/f6/0vUf8yP/rTn1FX/f///T+Or7Ef7Xte39um1tSUhI9/rfXiLhppuur1HhBG/XiP1V1t7X 66X2u2FsJMGEglc532trGl6HN2GEm0rWlBBcUFu+iUhLqgzddKIux7x8UxTFSxwU5/7G07Fc6P7F MUxTqkFcJTnsRpNgovx5aQUrCoWmg0GgwmEIjtCwhENNCLP8WmmmhpDBhOItTBYqnanOhhghERET CEqqERESsIREp8MEDCGZ4iGCaDCEQwheKksRLRCU52LpMRFokIpeUYifxEZbkmVEXzXECRUsKERl DQZBcEDJVlXqdq432CCHNpTscQhaIV7C+QYhKhAVNG9pqf08/qSs0iF12dhTNsqUdIwyEoOynZHo iiDwkStBSEzQMdb0kgRJ6NetGjqi7qvaC6cniHaD7V6bC8kOyH2jBY1/O99VCvTat1ZjfhX+jOKe rhgujPekCI9wnnHTuel9Xngt/X+dyoozlRCJxHeve792/phKrsQoVOtU/6t4Yb7ue5/9Qg5aghev 1X7brX3/f9/8lDLhfOgn2RIF/zSLhe67Bhi/FqJpFworY//22/09/X6Q/Q3Wjn/gz7Sf//613+n+ n967+/sZhatpRGuqq+oaRvuo6XMjr1P/9qgoIoeYQVGCmeXP2179f/88VhpQ1ubt1N3iMfur6ris V7W/CBHNCIr7Hd/sR/FcagxsUxU517H/6sbGF1wr7YSYjCCtpz/H9pdrFxaEO01Qi7TT83FPHYVK +GF+xVIUGYLGtKxUQwQiIbEREGCERhC0IiwhERGmgYVus3xdqLRC87EkIiIiM54zOU6ERGTaeTxF 8heQsYqSgkzKiEWhDy3JNDNeg0Gg1CDJUkiKEEGVGdiZnZkiuDysIRO5rbqmmjcyLmgkXjBMLktZ gk1CZ2SuzsSiDil5P2R0XRdFPl4nNM1I3HYpnRpkJeT/zw0aGk2qSCbtBToKFKo0Pmhr51CLxEQY IdNpp/ZqE4Yb6uY6cxU6NArdGcVptT26c2tJ0CI/bpe2tPp9OEuGHXXf/1CrphfX+n02l/OOZ78+ Hijdq6nj06Ix/Bhj/Xv+//Gkv/r1udjAX3uNW7x3/OxkXCrzun//+q/m/+jd3X7//679f+vrv/8E Eb+I4jY9VyOYL9Tn/xHuvrMi/c5/76TrvP3+2+EC+/iOI4j9jX7pvqv6XteGbrWKxV7X/hJec+c+ YcqPd70FnP2GFjXXv9tJqNtcL7FNuvjxFxoT/NTOdTnyQKt2nYpin9jfjFYprfa4qOIiIiIi1iIi IYTCFoWhEMKeaDCFhDhhC1nREREREREREYjLclRUsm6VnYEyqM7NFTVUGEGakfiLx9EryOgpColT L53TIOJ0SEa4vkrZfIVGuL/9GhzQ0/TQj+zscTtMLrkqEW/vWbST7+rhXX9bXCr/XdNK/ekbqzv0 Sf/O9533N1AiPv/9937uhInFwvfO9zSLhYr9d0hr////YRQ6v1r/Wtfr3//xH4KR4KhFufXP1/+2 kbnOe/////bVCK4YUd//x//VvShnP//M5x9hKp/oesRV3X9xpXrHGl/oT2xQMwV/3dja/YpiKVjt CIiGE0LU/xaDCFoWhENNM/wwoiIiIiIiIiOW5LkLybpWZKiMkZG86IyGIkiO6f8yV5TtMhUQqkta ZmiCxqRisIGSmCDKi/mVVYQyUhKhpMQyLiBNNEHF3IOGzrv/3VLngHM5MfDWrbRrbaNb/5qR0Rpm aL5B5HRmiQiPmaMIjo+jojyI8aI2iPl8ujONMj5rR5GiPIjo2iFr9G+jDmH47UINzWZ6N2kZ81md 081md0/ctwsEJwzmYOhaEQZ4M8RcREGfAhCIiHEQzwEBCIhngznAzngzngznAzngzngzmYJ+NU5E 2XCAiadPTvQ9XTuvTvt7+mnqv2q2qqvqkn3+9f9v///2/X5bkuJ1xERERERERERE6ZkHqR8Fs99v U3WH/7Z9fXf5j/8v6/4iKtbfGsGHrrdrH9b/rd1ghVfqN9fJRhKGlaTSHQW14YSW0qbC9fwZgfjf QhMbGO1sYxGxihGDO1AXraZ/iwhdlhAmp/iGmEtJ8RERERhCIiIYU5ElCZ0IS1AJRERERGW5KipI m6WqaaZ2JMvnZ8yF4vlRkKyIjVlWy+Q4qZFTyIyE/66hbKcZKhTo7U9/IOLtTpIM6NP+gRH7dcFC 6fYXbRrb66f+t+d7pLCRn/O+5rM7p+p4dTv/r5SouF/RnPDnc8erbdd6d1siWbJf6W/v//7//+6V f/umEP/p/q/0jf///+kLv+/9////qP///cer6XXpDP+K40v8RWsYS77b2lm7etrtqq4V1/tO7HbG 8VrWxFMYsbu10toWgwhoMIaFxad2mEwhxoWoiIiIiIgwgwgYQiMRGTapEIibpaOyrIXlPGScjKpS 3JIJl9NM7JguRMFwgyVoxEqrOmQKO7i+CBlRkHEoZiIKiqLr/VJhNB57Zx6n86Sa2prCEMKuSiCD JZr0CI/e88FxngsejZf8d17V0a2kk0+mCH0t9ahN1CBurSndvvvSM9Ai/02jc5s1dTPX1/juO6vW 95FPv667V8cNq/XMOeP/9df9f9W1/1/oev+v9//+/0qHGh/717ff/7ffX3V1tY/1j+t1s5q66//i K+GlDSbSaSm7Nh3zdoKxraROGDoFhpRS22va9imKjda8d3fimO0ExTq8VaDCFoNNBhCIvWNC0GmF OhTKaGh4iIiIi0IiDCERERidhSGTYvmtFlEo7iOxfJXHZXpk/LckiIGqZN1uBBksZfCDJLgg0GVE XyDyKkR2sZ0yNZLo7E0VCNbMXQr018gnpqFs6MJxHqfR086QQZFTMGSmCDOrCD//zZW0aHdzW0aG vFot0yf9O/XT7rp/N36ud705ip0m9zfO953PFqfGGH/3U7ukaNIz6R3aV+m/V1/3/61//FXDDFv3 94VX1+9Px////6/1/+rDb9a/7r/////7tbW////9CrV//f/7XkvEdBfbV9YjBCnqI31j7oII3pgh Wl6S68e9cIRX2lGl1a99UFbUEFzdqMLGlFLSwwvhexTFTogzKQqaliNrilC+DMEVOrq0rFanSJoN NCNNCLCGg0hi7Q4aUaGg1EREREREMFjiIiIy1grOiFlIjLOWorqEfzsySpiMtySJiNUU4hVci0fy LI4zsCIisCBkWR3pAnlSzu9SURBZXJOL5K4vkojJJkJkH/0GqahA0yCZfImk+wgZBTLn9ko7CF57 TSg1tO8+lW++je3CboTuyKBi0a3SNeDQt4Td6+hCQa6T6ZkcJ/+g6z2+Z0/091c8A0aDXWn3Ru+j QpnDQIj7wRf/SeudQX0sigL7fT3J2d/7/gyKJp7/+hb+EIMOvS9vnc7yfN5H1NM2iPr//Vv6w/f9 t1YPrv/39Pr/3/tpoRphCPzo7fMe7fY4YeP7drQ/S6659R+YjphJ/+o19+vq/DCv2x9Mdp8RXdr3 QIU2q/qEv+tJ/Gfoz/+uxVuw3bUNxqGrYj2wtRz/iNiCvVtVm5/7/x8MJ939pmHCSJYrZcBcUDNu b/QTEVEV/a/3oWhEREREREWhFoMJqbkPOjCaDQuLGONRERHEREXERYQjESN52toZa6RKdjSINBOW 5JExGqJutxknRvIiL5C4lGd14IZCs0jzIZhAzoEITIWjumQfyXCemgwt6ntaJUJoNdVTOxxCH/S3 VV695wvo0WCKOYJwv9GHMP1andzve/9G7pXrpVNnv1Qf63/InmAjeUqMBIMjnQvvmD2y6I7nc7yL I4uh3/36+vpr6rH7/XEa+EI//3/aW/8w5h8byMfCu9drhe3+vt/2P9RoW1FG/OFs5sOGl9IwP86N nsEK76/hY6+bv59IbEVEbn1/5SwxX4/apj+t1tPDV2n2vahltQEoWmmhoMIWhxeOf4znoU7FDUx7 UTXiIiIiKu9NYsIWmn7P8REZ5xER2WfXOwPESaYjLckoZJxN0rOxOL5LIvlAYJURFzgyCZJ53Psq RHaESjIgyNfg9QuF0k6yUSDXhnU01z6W/O4P0CI/a3M9GtwgfV+HBouGdjiLcET9egYf1vO96mzT am/qd387h1CdX6/iDD9fXxptLwn+5ORHalKzBLQMMVtGcqN/k6I6I6I6I6+/1//77X+hGmhi9PXv xoRER8EFvf/r+7/8mOSH1nVBTQ7XVtD/mrCC19J9X20v4rghxn+oQUN6u/nPnR8QvY1vSsLaxHrv 8QXa7qjd9foF7GxGxTGrS/9QUNXit9/0wTThhMJphM54whx4IQxCd2uSGsaEREREREdhC0I48sqW hEQYUUxluSRCom63ZWY1DJYR2BxfKeL51yWZVmQrIHEoZjJYZU7/BkECJprr59ZfP6an0ahOwgyU Bf8GqNlGtrren/Pb0wtc0f7zOHN2rSdAiP2jvfdfXNp+bNNpNzX+og3Wr/W/9//3ekK6T0H/07f1 /r7e/1710/f/zsDwo795j/f0OI/0N7+hb/2EEt7/6/q8RrZ5Ok+v+IRLAthKwl31elN8Gf/N0nDF rakoCfeCpjiNiNiN/5qa1YptJbTXUxMJWE1W+0I8x7UVM1AQRFoQwpkQYQiIiIi0IaaiIiIiMmxT k3SsyqyRmtGQUjsvlGVzHK4XncXnZRQyPkfBTxwyWRHjsayHl0XSZqGSyL8ZrzCKIieSsiLZVQkr lPb/xEfhXO1cg0IjTW9O8oR0Wmq//dkI9hNr60i4rsn9ei8mnaNDoxnqZqAm//Pl1ed9kKVTu54N mm0CBXb0CI/f19B9Xr5MgQnDOZg5oGc8Gc8Gc8BB8CD4EHgzngIPgQeDOeDOcDOeDOeDOcDOeAg+ GczDnZeLhd+tfIu0/catJ6vBg6S32vdb32Gcjsbf/6r/76r/9VVbH630/9/1w2NfrtdP/FfVmHNC ZQ0c2W0dUby6JCLohPm7//7/+///xGq3xGlyuKhgXEcRERHHd6tW9etL/9rCRhXq4Ibq82yrr/W1 bS1SEY0rW1bTUIFb9Azdq0gZoKfQyuU6/XGxTEU0rDCTDCURQJcR1YM0FFrXHhnMtStd/FoMJpod imKajYT1ixTTxjEREQYRB4iwgwgYWDQi0GENcRERnIiIjP+VxVFmlCK/IREdlnKclkXyZMjoj4Jk TzzKoiU5LWFKGeyrRC0S0ivnUvn8s6fsLoRFKg08+gh9msRPv63raLH6NElQTuZ1TYXIV+t9537T Pl6tL3Z806Lv/v/9xVv3nc77xVteg0RRG1kU879naoiOgRT/9a/T369v110ITQ187BAwWkFqxHa/ 3t6+6H97fWumNwQp9dW2Kf+9/PYz82N2dGDP+r0m0mK/RvuthInDC+K/wZlIRsUwuP4YShqn857+ umE0ItNbFBiFNx4jrjxFwwQYQYQiGE00LQtYxERERERlp6IyFuV1LLOnNMlOScXyVlZCmYini+dc 7AiIGyQypZ2UI7FeVyzBFD31PpdOH66n0UvKNSnDEHkEjESnTWEI6fTC2jW4OnW9P2dBR8Hqnudp BKVNvzvennh1aBEfd/9OeDXZVtXQIj3a53O7Xt/1sQYe9fb2vjTivVP6M5Ufv7qv0+uvt8ca2EWC /zQM+9Lf/0P+8lCCvv6H1Xev+vv/bVJ9dUwgrX/nRnc/boGD9eYOCFXfu+wlNzvptKITaV6o3b1G 21OifYpafd17GxXsRxwUUxFb1v2qHer7KHPgLvjTCGmEGFQaaa/RGoEKRgqDCoRHEWKiIiGFQhgh ERcNQTiOwoiIYQiIjLUqhlcpizgcX8hbMRFiO6DIyL52SZhHY6PxK0bRC/R/C8GuqrkojDTTWgmp RkCF+tw2nnto1tbtMK9qtojCd873mcNK/N9NoER96Rnzv9UCI+8NE4/XxBh1rfvX1WvdrXz2R1Ah t9e+7vr//1uDEor/hh9Dvzs1QJXqu///6v/g3f9JMIJ0oj1//b6KUCP+DTn1n+3rEKGF4aV6xS+s H64x/YjhMUznlKDDEU6xGiMcqFEVax2FCDCEbaGgwmUHDVzOd8RcZjwwQtCLTVC8RaERERlcpGWk PE+NBlmB5J8ZK4vnYojuedzyFolmYR2KcIvGWZ0g1ddc7cVMkBE0zsmvQcs4gLryf1zsmEJpYV0w rp3Sss+mgdTu3Dejvuu5Ifo3ud//dOZzuUPXc0zZKGDH3R3O+tG+qQdLvfX4iG6XTQoNr/t+RlQk TBer/r+NP16LHKHe//9Q7//12YRHl9jxoQcJG16/ghw3Pqci3X0CFYiO/CWoIEt9f7cfwwVvXyEH +1vpKxHsbKHPZQFXVioimTadJ0KscWkNhDjiM3RcME0GoiIiMzwYTBPTiIae0SEJhCIiIy00IRTl crgQMqaITIsRLDORKhCEyfPxVMyT5C8hWdgWY+qZ0Vp1qdV2EGSwU7nEv5KIjjIaNsjBQn9Gx6fN Gm0YG7qYdhTscS9DBCwv9K/erMdO++kG0XdfqRYaJPR339yJ5gJ6/3ZHRi+64TRCRLtGHO+ubqNF 5513/prXva8RvvvivW5oGCJsuEabrvGv/1Ix9q/XUJe20v//Ufr/+6Qz+wQqI3VGGDbtbPb/2znt Td7Gmz3evhhf1tJz6piKIqGBG2/sayUBfjfrlnEBjwZi057JD7TBmBhLxV16TarEfsa6FikNxmRH aceTrXP1qKMRFoQyy3TVBhCIwQtYcMFaPoRFlTiIiIiIxMCiJF+VwvRMcM7dmIipnI7MERhWdrTN 53hEoytKVyntAgb+rIrk+mnBneRhnSMO78pGv0npunXRraLhw9bTazuep6JwQ1id6uum/p4Tczh6 BEeqd9P/IsNf7q++XJVbVxBuqeltKyle7o0XRhzx//qrEf+3/0/r31V1/XV96lj/8Jf/9fH//K4q GLrX0ET7q+Q4Jf31fGljXt6YYWGlDC/aVhJiCilYwravNYIjzfbfK5TsUxTBhL2NjQTrWxSMfj2v aXYQYTEIRYTUIaHYX1tUMfBghIKgwgwnERaxaEQwoiVhCIiVlCIjTJoKmVyTlcsi+FNcXwgzsSRV xINSny+U+YRTkRmYR2Fs9moJXCQXm5nauCZTiJhQunaadra1sETdraT6ao0METHrYXRra7XO1AVA iPuFane9PU7tGzTm0EnQIj7zv6dHfpN+vBE4j/t+6Q/YIm8a9Ltde6ds5HYkv9a/ql//C//errf4 0/9//2lv63////6SB/4zCfW6f7PcRof96V1elpT7KnvSninek2FjSj5nZfvV9W1f2Gu3YjUGKYjg wk0FWc/DGxFRHYSiOwlZ7OxbsIQ7CDEIXm6IiDtMJigwmKjGIbEMIWhDhhAwgwgwgYXaEXEREZ/y 01VCV0+UYleoxGVwuQZHRHZXp2RwpE43kGRVxB5qM7G8uqKtHYpyuViMRIsjRxxItTKAxphbhKZp T6rJRNQULJdkbwjW10aA182tdOjdRvCJGEHNkNvNwW80Gv06BEfb0Hf+haCCTljlXSEMOqQVWNOd UqvX+Yn3+IS4Qmfg2IhLdKzQMev7XfdbCCPIX3TCCOLzC/8wv/qOPZzQSafZ5BBG0gr0lvRkX7f4 i1XGEK+LCBWEltfS+wl+vP+bn/1CSocRsMK/EbEVPT9ef80He1zdjmH7EIdaw1X1oaEHERHooU54 aGdEMIRERGI8ohD0IuIlIqkQhG7VOVynCggZLCOxTKjJzPYWyoIq+GdlWprzCOwPMfP4KmEzswKv YWGnwzsSakhpBNMJ/UESdo15raZ1EacETfDRrfDBDTQSuvtyzpNWqbSdH6qVhLKc6fKdy3ozip36 M+76YInEVerILKKM5UacETiIMNKzqiOlBgzCJXIIaYSXdb7+v90+r/QXItLmYLxp1/v/Q+9/Wn9v 7ULq4RY929zf6/9qCI4zC0rp7PK/tKNF3up0QkHrPrpeqvXP8cNpw1bUY391mdl8hjd1XIY8SJgv Ed6v1/BiicMRSfHBhKgxwuDV+E/sRUR6oQew1NyFpihB2FbEIeFzozUtMKItzkQwQuIMIPTQMIWq p2mgYQMFaEREXEREREREYnQQi2MrlkXyzqNOQg5Q5Qqfi9wXBjIpQTBl2dWUclsCJKZPYsdpjrYI Mi+TyN7Yi1QZFcn/KMnlKNewuSz0ztJ9cs+nDXSdE76NHunX1gif81CToKFCRadBRz6nQaH3QIj7 qj5equEwtK+qt33rhOF1QfeqTf6b/ePdoEE+8jHBavl0b1swiPrr3O53/PZGL1zCOLp/6W/r4pW/ EfxEcRHHv7x2DByFHxEf7//2dz31CCObes7ljlD//0v/B4qv12//iHukF3FYi7pTnzoz4Ve/7nPw 1O5TlDlDsbSN4IV1CUWq2wwoUxbFdwwv2uO2Ftuu8cRF21VbEek+xSEYYXsV9fsVx9fxGDM0zsIW haamgseItNC1tSStNckVuSCrxESMTiHEREcRYWGuaCuvEREQYQgwoQtDERGVwvLZSuVynstlUE7p /LOTjIESLz+wmW4vQh/2n9dp7lcVB2unPehEY5XKdPz+uIxyuFxbK3yuViFnqZhmQrG4txtHO6oQ whDCEHVG6jQaMzlxX0NU9NXPZ7Zkso4gRQ+v67rugwhHdf//4Ij+z23e+r+wp/42IqIq0GEh/st0 ybpiP8/xERZrCHiIiMpkS6IRp8VxbJ8s6TMgTLco2Qdpjr36N/W/4X6XtAgWMs+gYMhsMFuTDAot pz9V86Mx7OizYeIIqyTTv3u+h0wYPa/9/6faffY4iIiIjI2nNGaYY//////////////////+UwGq 3j//////////8tsIo///////////kBwDUf//+QHRtR/+QHRtRwAQAQBMtyjZB2mOvfo39b8KZW5k c3RyZWFtIAplbmRvYmoKNTAgMCBvYmoKMjMyNjQKZW5kb2JqCjQ5IDAgb2JqCjw8IC9MZW5ndGgg NTEgMCBSID4+CnN0cmVhbQpxIDU5NSAwIDAgODQxIDAuMDAgMC4wMCBjbSAgMSBnIC9PYmo0OCBE byBRCmVuZHN0cmVhbQoKZW5kb2JqCjUxIDAgb2JqCjQzCmVuZG9iago1MiAwIG9iago8PAovVHlw ZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA1OTUgODQxXQovQ3JvcEJveCBbMCAwIDU5NSA4NDFdCi9Q YXJlbnQgMiAwIFIKIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERGIC9JbWFn ZUMgL0ltYWdlQiAvSW1hZ2VJXQovWE9iamVjdCA8PAovT2JqNTMgNTMgMCBSICAgPj4KPj4KL0Nv bnRlbnRzIFsgNTQgMCBSICBdCj4+CmVuZG9iago1MyAwIG9iago8PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajUzIC9XaWR0aCAyNDgwIC9IZWlnaHQgMzUwNyAvQ29s b3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEgIHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAv TGVuZ3RoIDU1IDAgUiAvRmlsdGVyIC9DQ0lUVEZheERlY29kZSAvRGVjb2RlUGFybXMgPDwgL0sg LTEgL0NvbHVtbnMgMjQ4MCA+PiA+PiBzdHJlYW0K//+WgTUZAdV9a4RHUbvEjqP/kB0CXjIDoEvH IDoEvH///kB0wo////8gLqFWOQF1C8fkB0CVKMgOgS/jkB0CVKMgOgSj///5AdMKP//8gOmO8fID oEoyA4NIj8RkBwDXJmrK3UOQHQJR5AdAlHyA6BKPkB0CX8fkB0CUf/IDoEo///IDoEo//JsJqP// //////yA6BKPyyDSjlMknH5AdAlH5AdAlH+QHQJR/yA6BKP8gOgSj5AdAl48gOgS8ZAdAl45AdAl HyA6BLx/lNJWWaNqIymjNRkB0CUeQHQJR////yA6BKP/////5AdAlHkB0CUTRePyA6BKPIDoEo8g OgSsqsfkB0CUeQHQJR/hajyA6BKOQHQJR8gOgS8eQHQJR5AdAlH8gOgSjkB0CUfIDoEo//k2JUYU rqowqkBMTUEDCtjRO6fgijnj19W/7rf+sMLdZa4IiPkci/Ypi1QiIdhRVyuSoMKfTEfuJaQmojK5 mjtK6naoE2pATEl5/jK4WGMS1wqP9cIO7M5TlXvriN2bkaw7LSFlfOy0F6bx9e7xGcjbdFpC6iLD YsbvepXJCOzOIjEYIM7VdyGwnCJO/pMgJ0WCNL6niOn7/LXEqt//+uv6LSF1bU7BQxFZa4NY2KrU IXYR2SbS1BgsaZzy0hdREex32mpN6YiWkLqV1Nnnn8abr0aA6f1e3lriVUNt/lpCy76HjePrDdG6 WuIDFsO79podnPiI977TRaQupNgTIEYiNS+fwg/80dekG9/WQE6L+uNiN++sM37ogJnV9jH7URDC ICYaiMgOgalcyzskIqFyuShAmdNMazW/ovKTq5a4Ei0ixaGt8Jl8dd+vvr17ZyvBDne3jtUl+rFB ltcS/m60Hfy0hZaEMKvSGIixripXM8yT4YRaRUpXVQ5lQKI682UXCLXJotIKWnaDpj26bkHaRKOO 3Xms8OVyQKZUC025aQkqVL/mcqWhMcE/jaFgh/iNrUrqWxQlpCaqZK20POzOMMIMcgm1VpzQ8Op3 pNkBOizH0vTlriaHt9X5a6QT69eEvv/yQ8tIXVpY9tJGdOMT5NKaYQ+26joXXlpCysEMm5xyh7f8 YIRD/jEeKk2UsX2QPEtIXWj+rKr9y11GO/QdvM4uFTw19Gh0Pn/TmPMOYeP/ehfX8tIWX6f6GIjU RxvOdREtIXUmyqyPEPGr56hAiP++F9/23yAnRfW8tcRnTH9IflpCq362ZrHGrP+I7Fe8MIaGI5Ni XggZB5ATOqJjzp2OCbV6v+t8gJ0Xvx9a280DGGFYUmxaC4ZgExbfMiMcgJiSk2VBBhSXszlDginE 0Ihdn1NkgJ0WOhG/Ri+lZ7uZqPJD8gJ0WOf45hyhyh4joRGJATK1JsSZhGoYwnaddGzRn9Xrvfq6 /dJ/1+QE6LFrarYpihtNRDCiQEw1Jst4nRSbKYQhsxLXxzg036cgJ0Vhl0R7xxH9L6MD92wkQEzr ZyjHGGFUSAmQrP8YiQExJR5AdAlHkB0CUfybKWRpEBM6oiDnBsbEH4Ij2QE6LNydSych1ecDDKTQ j9R/zI7XrICdFtIbUbFC8NDHJst5ATElJsqoj6kHjCEZ0CVSzzzDneQEzrjXj/b3/kKH/95ATUeZ zj3Yx0Li0QEzqIiOTdOpNlvT50CdfP6k2LYwEUerkBNOvP/GPwzd+PXxef8RHJspZJ1Awg7IlTzw GjY4vTwQL9fvyAnRSbLL1GTZS1hpUITGQEzrBMIbOAmZDJsS8EGVGQE6Kix2o0EG37+rM8uFICdF 9cfXO5h+8cX2q9inWGheI8my3kv8h99f7ybAhEfBfoRv5hyKP/QuCGQE6LekOsh8fiOQHQJSbLeQ ePXv+TYFRdEdF9VhCIjM4jh/uQE6LMiM/x1qv344vEcm6dSbKpJwmaAvmt1SeeDZ1Y1dfe9fv/ra 2KYYStMVBhBhRGTYEyKdSDIj4Xl8/oRWvmf/qfnvx3/r2I376wZ/3X2OLtRHk3T8m5GCwhVc7neW uJ9dv/9//5a4gMePi1MfF/9xlckyPna3F8YIQad00no1GgRf9PXlrrXW9fv7/tLr7BkdArdqWuWh ixEKIrhhBqY+Iv/k3Tr5NlvTEZXMo7UwhmC91rzdZVnzK5Ii6C0IpWWuEElcLBfVwnkOP30X7zI2 e/hN3U7LQXtVfb7FP2qmRa1iIiGFDCUQx2CldYzIdEJjs7WOzqJ/X+jZ13TRa4mt7qJa4Mk/pPfz tUDFntHtv6jVv52sft/0brvxoRtjiw3u8rmaEPTMq4eZHCXSrO53yuFguu3V/s6P9f//axd2OIhh EBNCiOV1gjsL6akhUaHl9dB6+t//v/mExHelfa4ZrKHlrktiNxeHWth5kRG44PEZXJM7MjqEHz1N H6QbtvWWutK6rkZXQ3uH16g/M53tq5a9YY4vDCRV3rYxmPiIYKuLf+IyuSsy1jFfT9IER79P/+v9 0sgJ0XjUfrwwqtCMcmy2pXMo7VBCH9VPV0Se+Wuo/P/4crhYL428Ouw1LXMPMRs+kNh/hkdBVDDL rrEc3Y76LH7hFu4iwjPGi11Yw1ERrwrk2JGRFCqVzKCDBBiPRb5nZNy6ugm0g6DrT02wyzDTlcLB f1ww8/0lt8MPXMQ3rwwdv++1DDf6thJtIGHfa2OKYccWmEGgdYiIdG/F+V1qHhBnaXkvllB4wiY7 yH2TdX3hB9eQfYKHSv3bhlnxdzsti4X5rPE7UjLQZYIEn/60rsMMIR/qf9had2RGhUV1FcEK9Up3 O/DSfavcIvPt2KrDMbilc7LR/8NC7UUML/iItQr/lmqihNbHERGpXVYyeJeHn87Uvybq7qrvns7U 0er//a5Zx+2/mcXCdbloWQu1f7f+oQpTCXn7f8/dghGKuh/t5usLXBDH04M4Nc/0uNYtdgzOdnzE RGnEtBkFjwpN0+M7TcrrEdpaLxoGCbgeNTtYCpBB35nJj0ztK+jfagg6Nbyzj/fHbSfLQticder1 9v7nZYyOFRu9LX66HnawFtJtWp//QTHaQ/2mdQExX2e4iLQ8cR5XUkZRz9phAyni+I6MZ6TXLdbi /10bGFtbK5fMX3p53urqnVrW/0CL+diS4IjxZzWt2r0v12nSTloWgmI//17/Sh21fXqv+dzvhm6g wlGlb9a/t6c7LQXY27UYr/jWGExFOF/jORFphf8RER2OPK5lnaVk2BoMKV1XvJto7OxPO1NDv+zs mIpaDL79Ouf71nZbFwtaN38ui/9fuhviIPavP/9+4IUP9XDCznevvc9odvBm2t9hhUOYcw/9C7EK 6F64iGpuXisREaLQZFHldYZfO1PKhl8s0Exrqf1ybGudmMvvQIj9+tlusiBOztUZfHW7873VXW6+ 3/o3Z38ER99fev0KXaX79D//f++qvpX/+UwU29Kb9/ZzvS36sR+xHG+t6vYQ7C2IpiKGIjP+niJ2 BphRGVzKO1qJeLKX+dqXnQITY1RNL6upbrWCyDkGcvamHf0boQ21ThyuF5gK/ilNZndTvnHDLQlR c6f7zueHTvS3hh39Ggp6r/9/TiDdIEX44uCHZy//9VqvrRoC/3130dqWEv74M1e7q/Y9CC/i1zIu xsY0FYWvEREaoXhRSxBghppYiNSusRka5L487WhCH5knRkK53TI18KtmWEnn9T+Qwp2tXn/um/67 loS/qPz2+9+fuFL/39vft99b7qu33t452WxcKgRH38M5ghW3oaHf1/j7Y/+f//UGaWgbz/RukMKP /6m/Tv/1r/EREWh2nm2t+9KIiIi0xHLMnC1K5lnaqMKGCldVrThEdHZBEmjtbQ/RsZkBERyxQanZ JhPvToeYka51CAhloWf680Gh6Zj29c+tf1T7XTo7njN3va//TWv/Q6wQp/+73/vt9Q1tNYj197PJ 1gzbShTEV3VtracdwwmXCmPY3io1iGEIiLVejdiDCEMFP93k2WkIiNcrhcdmbshwjoxn/uQfYKaD NysrYIdM01Wnbiyc1kPsUM21f9c1mdzDgiPQfDO1YUsoGu069O9U88A+aek93+v/qGRVyQuorNNz 9fEb//7mjzQMC+33vf/8Na46wZvwwla8UqjzInYJrllqi4XqxsYuuP2q/aaDCYQ038Udqwgz/iIh hDj1XxEZtip2UDrEReVzPMq47WsZXWcKZIEO1RqQaK4VkYZyK4HwQoKEMnJPPqsr1hjz9VPVOm0i yqzoznfjP6mhu/TzQWPCettVGm8yK1b9tQg2i3e/d9vQbarik8IP/s92rfDQ+v//HIWjY2Grr/d4 12G7zdur/MKLU3UW5x+4u7BgrhLpYNCLQuLVbFR2vERERBggwojiKyuSZ2ZRfIPMkKZGp/C3Z2sw IiyLDufeHc8hh2UDK2rX1V9wgwthc6xdnYIC5IEO+i+TckkxH8799Ggz11tU6QYXQzsS4bdbzPME F6dtAiPugRH3qd80Gii+9k2EzCCOyes7EK1/Tijsti4X7r6+ltpJtBNo73hzbG2sUPreccER/+3+ /+saen/mHI95tav4qN1P26/r//+/6Bg7OTEp+bt6+Kuxrv+utfdf4MOM7MY92Ip91rbTW+opbVtf XB6uNNC0ODCGIpiN1bSYpjSxRtiUvxEWhaaF4phR26BAhxEGEIaEMK4ZdEep5XM8yToRHQjaeVws ZHFO1vNDI8CBJjLH1WKO1QIhEUdrUV7zuiKhHamibftH8Rot6zPzJKCnZqkynQVSkZbiQQRtTZm7 U13086BM9FDTSMjmd0M7CGbONXQjTaz8t19Cd6NLUh9w+6vq52WAvt/O547ozqzufokO0XDhA//8 d/9vpp03Pc58Jun62e9Zj7/+1++LW18w1tpHYIC7aVPRSwx9oeNdV7/2K2PUySgtW3re6NIN/7T3 mRYQ9AzA8Uz/bUabSdfWGCEQYQz7pF/+z2x2lEcRGhERai2ExXJunxI3jQMocE81Mmykj8dCU7WY ySsoiKojSNQk/xEWhp4Qo7UgsZGxEwp2qEU6O6oRHvLHpNBM1B5trYZICkyBcyM8lyK4REdG/9Hu bs0GjPBndUi4p0CDTMhHF3fat7Se1d5u2e6bno57PkyJe0a3/8Xp6baptt22OnScUr0a3T8JuTYE DGP4/j/979OtrvzpkfX+19G2tfr/6cysF17JwUOEEIo7UgtqxVnRF0tatr/9/8OIwkE2k1SEVZ7u oMFtf3SZz3W7K2tnXwUGCGFGxsQmwlFra73URENCzg7QYTFaTFXscRn+DBCwh2mthSy0QiIiGEIh hSb1wIGW6GS7EemV80wmdhWUhnfLo2clmXkZ2i3al8/gg1PorjDMZ2J/q8iYYSbhN+qBEe0zJYZ6 eztILJvYL7+k6vXo1w3ug+E4UlkX9eZEsXCydnf3V3vTd3oz3W5rkTBfMd/4d//9fd1oMPp0hzv7 Xrz/Yau9GP2I7Xit/6ZeHff4aQ+GMbXtJ20rT2Hdrbf99j9uPbwzdjpG7fvTnsMPHiLCHBqNinww t+GGKhhYwxtRcURB7CFxHd22KVxllDzsSQsoiIiItMKboak2LYk43nZKgRQ9RM0Ii048ujNXZ2pB TtQEO6ZCZ2OEIPEdJ3vBKdwKaxSWS52t5qzuh9+Fc+xs26QpFDCDRgk7VBLCZbrZErZ3qv++fWiM eiQ+JnbqvNDMllnpMhhAQZ3En/XiyI3OOf1P9GdPnqf6Nmkm07RraDQIjvSxH+nFKONNceKQ3Toz tqtF+0aL6d3WYc44KHT/9fX0w8g3twg6TYbtYMzlRuqEWGjbmzys+t+cGz6f/f0n+vBidqDeLsef w/Fx2K8MLZyv8MP7X/tq+1JDwac9+35/MwXj21+66+1yZ/EQYKMUNGsofM5x9VH/DCUGGKFtWDBW KwQkVqGB9xehcXVnRRu7FO7YWKa5Y/Kmp/iIiLP0RERDCF2IQMEIwiQpNlUyrQiI0Ii0IjCDNTCZ 2sI1Z/O3I77MIqMlWJiNWdicOaKGdhcEHaphVKdqRYQIMEHZA0dl+k2iMfrqjW1sIYTRndQyDRHS ZqJS+fRXtHSK4FG/To3qp3drToER91RoM7SDzoPtWUOGEIon0/TXPo7Eog+7r4+8IEIIuluvn/Tv V+IMNdGt190nV/918Whp/8dttXvDDLqdzv6f3q6+E9+zyf/X//+OL9v+9IyJQw+dl1kNUt7WRjuK yGKR+6/s8rXfcETH//sRfeEyOFBD3sNJDwsuBtr6k4YYq7VHRO1GEED//vM5Q57x1/2Klj2uu0mI pWqtL4hf8WoZuuI6tT/mPdYYTCM0MLdimpY5TlDlPDBCxVvC+PSf7m6PvdpRERacMJhMIRFxDUj2 NrFof+q/9jiIiIi0IiIiIjj7TCiIiIYUm9cdhGYini+QmdmsbztJG87HjeP9c6BU7OzXMNVuztby DzWjur9Nhb2nu9vc7UvOnkgKd2IVwcXzsSR2Sv0873n6l6BEehPCu7W01C9hByb3Fwi/+9XVP3uS 9W+jUaNlc7UWRkR5Fu+vr7+//S6e+9PTSM/rJwxQfTP19/G9V////tRrb29K4rdpevdOve6vrr0/ /y8O7p/sMLHR0CtrFK2t00CFE4O2tnv11DD6+1sUx1FOsUwwo1yMdR30CFBvG1iIYQYU+0IaDTFA zAziBW+uxt1EXEQwQYVYMKfsRTJ4EHsLERERoQ0GhDsVLLYxHEMKTZajtYggyozIZkYjsChK0hk2 C7OwsIi8kYlMkEoUvncIj0Gdi+VzCvusJsENDC2RQiORICl+QmxNmhmCJDLkd0jsmKdiSNZHYqgp 2a/5/q6ojHSBEfdC0Rvue3TqhnbiBVCahVvqNc7nid/Tdr5oNeeL4rdTw0Zy4aokPua2dqwgImPz 19+/02m/uq1tXCL2ENZQ6pJ6aedzvn9Uk+CT/JsCBj3/x/r/Yr7CGv/rtqJ2IDFWjDniETeL1qzl ZHZHL7a/+9sVb5N9f+//9egu+ydgo4ju8TscJetpraQYMYIParY/7n1NB3Kff9/DWDishB+xQSYi mIpjIevsV6/wyOgniO9fxofZ/zoQvLHKHBNMuAgYKILtwk/xoRvwwtt88THMPiIiIYTQiGhEYIaa 3p2vycMd1hjo/REYIRERENMqaEVGPB+pNltCIizohoQ4vs7LUUIlbI+dwR2Ko7Ojpji49NNK0zs+ mSoyXSclsWKXUF7WDjlDx9aujWzscIdPIokGEODO0kEyCIwjs1R/CDOwKCEZ2ryWs5HaFyLRy3QI j3WluqLdrPYapkXgmqdzOwg0Ep7Vs7tBZNi0FyMrTjp7Sbnc7/4QdG9CtTuyJBj0g52I059iS2sE Pw9/X/7//EIvZhLy4u9Ws+Oz6vpu85GH81O9f7//r07YMp36v7skO3yDaTo3r7bTCrutul8EP9z6 Dfq3tf7rxV/9D8qIR91W1/StNYYTDBx0GLEpYYdVfRnCj/bjj8RUNJ7VkhwRHUaoZD1dQ1V1/Qr2 ln1ERDQYp2MGhFmHVaEE1hwZtjbCsWuZqbotqUsQjnFhCwqERZ/TBDtOxWkyb67Cxyb1wiIjKXA0 GENIb7EKWOU5ncmy3nQIQ4txfERGYeIhqEI1JspBUoM7G4vkJk0Mx2dje0ZoRGqMDITZPmoTs7nQ yWCEQy/BnYHEFIRy7XPbW1a+GEGvITauewgZ28XM7G47BikvF87pmsiIzCOycb9Nueh53ujdSdyn OXzQIj9zw6tFjmH64TTvTCdp3aeMEXsx+hq1BhoIPW496CcN1O70aAReV9Gtr1x61/8rYLyKBrXw i9gToiOrv3qndGf9PO/afoxgH/d+n//fD9187rZcKt3XZW8wlXXtK5NlIL2+rnt6nRCJwr39hocO /f+vf9UOrrfek56IcFvSQ7C7nQnYYX0gw+HaXpbSN16///+/LHKHBIcQTEexWtWxURnTWbodj40h 7hrd9B5/3V6TpWEI8vYkFP9oeFsJqIKrEMLaX2Kp0lH21fW1jN2EIiI1QhqCGhEdrDWxFfYSiKYq IiIjBCIiI0OGKDtSbizERYTCBhSbGsYZKIwyDggzsSiDzLjPZVoiqM0TYZCI9PU6hEW/yaMu+01C BmtG40jsri6Kj+jP0CL6UJv9Np3wmg07CprBlJle81mSaOyfquq53O9Xfanelfz5pAiPsGr7Zrs7 BQp24VM1dr//VLqzu8hhg0zARJbp/+qsNoz7cyF32pf0aHfnv+v1t/DVNen80Be/9wwdeTxHCHY0 ww90Zzx58pN1ffX17b7qDmgpyo1MOU//9v18MP3CFciTXTdXh6f3rFKxW/vt0I40Ie9K1nI7aWlg w/5hyT/f49/9yMr7q4XtYYUP/saul7EbGoYd6WLeCJ3OBiwwqG/MLShx2FjvFMUP/Sw1va0mG+vi TMfTYr2lYIcNYiIhoMIXHFpiEOI4OxFVwtk3CiiaBW1VW5hyhynlqIURERDVCLQtQsOIaqIwZhPQ jjERFppo7MkR1OEuPybGud6oREReY9xfn8lJkfNTshM7NUbiryDzuedmDOyM7C8RER+la+mmvpne IjpT9ZA8yKEZaf0CI+6BEfv0/0aGdmoWHB2dqIuYTI8QdDO3ifOuVIt9elv1O/9JvYcN9QrnUQ7E OHGp7KGYJM7P2/vrzQMe5OGDQMFKzcCKH083Qw54DWp3c79YOdw+vtFwztxKGtd//qqYQj7asMMQ bJ2RwnuvaMOd6M4MWHNBr36NGE2vd99Z0VS5uKjLHKHKHMPr6FwYehS/W+74MjCBl8aF+FVq6MOe NG/ev17H0PQiLjP/8MM7J4LIUe/+tJ24Nx3eu9df+IqI/cL//anY4QMO0FOh6S31buoOCLe8evf9 3w00PVf/tpBIMOIXx7//idMJByS2b1ekn/ctQ6iIYQYQiIuOOxUkOEHgvaSiKe14hcRz/jWwlbaj EREQwmVtbQuO+xVwv9pWGr9SyKkI0IgwQtPC5j3w0rFVHJtBkqyMM7EgglZxEREXEREMIWoQefSl WyPJFRkHk0MxneIxkMyWI/4iNFxW4IjoK6LA5DC1YT01CBlRHYHlXkJhTs1ZjO1fpt+hP079r31u eHoseawh2okHmsUF7OzWLtT6OxNGuL52YIlTMenv9e8+ufqToER91c2uE2kq2EgibunVPVU7T7Oz VEfI99vjreLNIuF3q6/795xzPOjN1Tu6RIeCtVbU7+9J0a3TghGX/x/rrQ/r9ffq1/W5pmAk7pwi 7juktt+gRf0urRG/+s0GHKHV9Tp6Nz/f/2/7b0/01W79fp+jsQGK7p1dGi97VGgofQjb/j9t16xH tr/vaW1Lj73v+sfr9/UU9isQ/xHnryGFsL9bEU/hphMajCDv8ERxmFa30s1O//262muDFqN+ExTE czlOU8ML1EdL/8OrpMfM4Ij+91V06uNQwhGwwsRn2gKqEQ5K1xTS98eDHFUFxt91VtbShhYtCjdE QYQiItCGhoWnDtBra/YiopimKiIkJiIiIhxERERoNNBhSuZo7OjtIzsCEKdOLCEZXJEmdmqTCDO3 ZfCggZkIjtVMRp6ei3rzOUMZMwhMwXOxKTOzxB5Pk8TmcjIXffeEG1tIZrYUv1o0POoke2TIIdow gzsvnjITOwhnI7S199bne7n0k6M5488GvpN6fC1L2i3apnVhPyUxdrf+v+Lq6bqxpuqfRuU9nxU2 jOeP0H0aH3CbVP/96//x6udiAx5W4wEoRx3r36t0nhIz6dqd3yupBgpYYen+cHqw1X39r+qsVlaD Cv/1Z3jWyXfvnY3aq19e9sVfnR1L1TQU9v6dpf7f/vpUvK3Fwt2UObczbSCo0s/trBgtr7dY0PZz J7N1rYpTo6t2v0/vr38d7YqOKDEJsJfHV2hxG3sGF9urio+nWm62p/9rROCrhpQ0DBRVaG13xTEL 7BQxTSjajGo+1EWELjM5Q5Q8RDQtTDmHY1P6nPDQMIdimCdWGEmkvEtIoURaEREaE/iIiIMocEIh hCLTFDjjK4XHYPJXmEdMSMifJpiJSkIiIYIX5dGedmoUKmp9E0iB5UcdndaIzLomkfyoSZGZbmuZ DSEdJ+vp0eiHZTi8NMLZLGnaeiF2Zlbg7nrJq6JNZK/RuSBEff9+wSZP8HrZFDQdZDng4NNO0GFO xLkHUilBW6Hahyk++9179+8kPDD54boER90J3tNvwcscoc7vCujRBeZ2SjtM7NQh2JQ9Vp1vbpv9 GdODDEQYZS0tfM6bSfuew2hEPzv6bBEb+j5fr4jG3rQu1f7bDeEy4X+nf/EPVnYLl0CKdL6uFfwg v5Y+r/6SGphBfwp3GF1///rFwQiOtv0XcTsQGBBEwTZojy4R/4ZeTs1C3rNBTvBCKfwgRzwgg1N3 /H1UugpNMKUa/r/qluEyOF87EBi7pMRWPP+vUEFxCHe9bWGkCEcQSpTof0+Y4azQeCh7B6Xjfd2Y LVfgzBLHBgsLViKfbVgiOqj9vW10Zxl/EXKVniIqGGp/86MRhAwhERcaQ4Q7XTEIGfcwUL4iowuG P7bobs7NQnxERmc4530IYQiGumYcoc+zRNIbg78YMwPr3aEQ4iItQhEQYU0yh4hx5ClkamHPtWqk 2gyp5qMq8haIKhERFoXcZapGhF5XMoIMlQgTKAwRfI6LoKRESDhnaQjvsuirR2Jot0mT4ie8REZX JQiLiFRcPiIzpJ+oW7JWaZ27I8QTOxVedNS76VNzdhPPBr1qwnRra3kUBCU7q5KJBppgqn1EZ3RG uL52rz+ShmM7P0Zzvp0tWxp5+1PDVtK0CI++iI/19TsmI2lqycVW9Shmz7O7GdiX9v3GtK9v+unr 1mdBsg3877qd2obQXbZ71e1UJ04KdkxP/9/jr/+vmgL0/9rv7zuVFiE9Bh+gRH/Vqe9WiQ9f9rZ7 db90vXzCf//6r18jGt7V4MMSlBim+4Ij9erwQPO53396ImC909EoQWOm6bST9ZyOPgih5fC37pbB +2UraObG/rYMUK7f0K1+MpYPthYYVCsJ2Fte+vtRQiN9KNKG/reFBZj9+tLf6W+0nNxUYpiqDWxS EUxHq+yMcKNdQ/7Ec0FDwgRzr6o7EBh9LVs998Q1MjCEODCDCnClbQv0DCFimsePxbCC72NVjW0i lhi3eLQiIiJVFMeGEI1tDQtTTtcb8VMe0FYpX1iZAqERERERhOIqIhoRDW1L8ofxUrkmdp0dzRGJ MRmPEQaFhC4tVP9kXR+OogJkeJSy/DKrmU8ozURLcpzI1ndkQmQrO8QiIiPXTwlutwyWNOO7Uq0R 0FycMGuL5QEUEGdgTOwP/7zW0d+gRH3NZ6Z2asj5HWjQ6giOjNBCM7nqF0NMIPIjP53POhl4qXbf 9INL3XhhwkZ5SkhEmtGg90m+hTRGPtmcmPXRb0a2i4fqdjiU2SoS6lbZcK+41/4ZFE9Wg7Hap/59 4c6hQQed7bCnzTwn7VawtD///9f6nRx8ioJZHYJfiuvirrrfqjdp5sk0BKjP8iYYz6+t8Iu/0P/1 Eet03/V9052XBG0Coe0hK24eayh69E4Yb+9ToN4/srHnF5KuZyY+z3Fav9u9GF+GK+qqc/i74M1e IpiKQXS/EXa9C2aUb3Xpa/banZPr+w+3ax+YcqDxdqFtL+w0v0OeystreraVpd1nUF7Pd7ZzH4iL VCLQYINNYsLealiuDGTg45Q/G4piKYqI7C/G2Fi/iIiIiIjCcMLuCEX8NNNKxXMirFL8rkhCIi0I iIiMx4MLEWf7Cm5fCDO4zvVCIiIiLTiNF28/kzVnVHolGYjpm2RjL5ri+ZCrMRN0IRLVBrQbXTtX TTCaDXW/MkuIHnSUnZ6K6yuk7//SBEeamHravTeeiRXnsywMXlfM1DOiLoKQiMi1Dq2/fuqdJINz vdAiP9PVf6VNqmCEad976//qtfpu/v99ng1unMksJNGjUIZCl9UN/r///Wvf3vGnq0km2eD417/l bBwQ//3/r+HvvpXuRlO54dOKujOVGstIoWNG/8V2kvpb96GqhD/WH/3V0v498MuCqihzQUWQrGEo 1Y1bC4IV3XTB/9f7f50a3EaFra2OKip/1P9tbX+77r8IFpFpFCiIi04iNBhBhBheDMD9hJhhIk76 bXW29CMYiIiI7jsUxQ7HFMU9rJDotIqURENBhDQaaGKBxGV1jO9c7/MtDEQaYINBhVs77si8YZ0C nTMMlOYipSZri+ZTZsjIXZLxCkImMRHq6apJpppkoCs49bO1KMSumEGVaCBmRGVlf9hIEX5r1O+k CI9i4V8JwgcIt2ix2axAmp9EqgUyLMKQmdMyC0WkCLvfXQel6p5u8ER/qd3XCboNhKa3qhmQqISD SNYin0EyPD+l976v+rNLq8i7MP3zB5KI3HWNtXSfSc7NfwoVNBLqr//xf/8X9a+1/rW0+urncqNX Ztvz/OzXOR1zym7PApG72uWkUrnbhh1+Ov+N/319r//9Vv0+/FNUwnQq1Qvk0ZuRn2PqKUhhX4rX /enr/9rvMf0290/H99/XdadfwZgtKlQVwpFwszldvCQjGsRiIi691fv1StnvffrN/Hv+WkULuNTO cQtrrF2I2kuGEttX1tRGbMNWqerPf9ntf/GNC0IiIzjOGEPNShGxXFMVToYiIlbBeI45uiLfURM0 IiI01tC7T8w/+riMtIpVM7WYRnIiIiNH+ZGY+f400MrmWdnyFedpLIKhERaFoXEQwpXJFncCZrIh MgsEGdZIlDTIXndEd3mEVaOwVEDjqhESIRHQ07XCeSkRFjsJhLfTTTTOxvUhHIzzsGjuiOmSchfd G7giOFpIIOhCpvOxwiv3l8//l49phVPoIGdwyPEJnf9HYhfrwiY8dGHO+rntV6SO/6X6md9eTQJq i3hLyadkXz9CW/iRtlwqCchsjha21fryKER5UZzvXuv+t/6r4Te+rhB+bX/1////whH1deaBg7GR gI///kyMEU9GHO99XR3++jDt8IM2uV1IMWexm/GGp//uu0bvmHIx9W/62t/1/hCOttvr+zQMekG/ dctSnqP53l4f/utPtcQ9/9M6LU3WI7FWI/9D/vX9v2rKUGG8pzbp/Biv29tYimGEvf2/7Gt3p50f 1/aqbCrr7f9KMef4+HHeOKtin+OIr+wz/tQz/7tvmcp7a3+LhDdviOZG0LiIOItBqdFhDi0409ex X+8dC9hJi19KGx/xGylIRERFggwhHHaHGq32NimsGYEvOf8UzshCIiIiIYQiGEwh3d6cctRClday 6O8M7E1kS1MkkIiIiIiIwthB3BkI7QZAohWdjhDueVCraLjw/YZLiaR3AqZ2N5CZCs7nnc8g1QIj 70G+eAcJ5Thro2z+zqISkTOxxDqaZ1R6O/iEzueQmdpSLUQtfXiGH2IYaN30XGqVbXdc7HE1NQij X/O04YII1cGGR9ISJ5hEcVs5IIPnRm7Ruo3aReUd/uFzs1CBf/676HpocZEVCaMuE1KUGKGhKVnF wnXv5u6U3e/+zoggtQi4vUw5h9Qd69r6YQ8a37oTSMBJ3O+h96VquRPBBXRKMJPZ7GhdGAg3PbU/ 9qayu226/r16rt52SRcKdgdiNin4hMcQuP8+g8Y3YaHHbOdnMZutnu/BDvngp7/3wy0ihQ00PBNQ V/tqDr49oaH2VsMP12cxxf9s9sKf7DGGCBhDBBlFqpG+OhYzZGmq9rWIqSHKHBR/+ThgfhxHERER 6DuLz/n+NSz3BoR/2NfOxSk2JVU80IiIiIiLgwXP8camRHGVzPJkz2iOskbGpTfU5sXCEXldYEW3 ztWjcQWKvIVnbkQ+yVHleMTsWQlqHUK02QrJeTCZKGmU6I+qp2qDKiNMozueQmQrCkLRNGYinakr kxzZp/4Ij9WEIyUBEXDsKjWzUEvs1ClDMMjBQUlaI6C+EGasxAoQMqM7nnRmIhekZIRaSkqTS5E/ NOqq6R4okOkqbtUtKugqFhQRJ4Qj20aGhYVFjyngp2OJuVGdRAUhemPGv/rciL+d4bnc8NJ2CL4R ZXedzv/Rhzvng0OSHhLWE6QeYcER4ESigg2ENavTBAiPEoCZ7//6f3+v/+LEKm1S4ytxgJW6W6O6 cIuIozlR+uqcKNOkjdp9F5CVV9s92scbpcH+///61t9r/1/pN0v+3+jX7nc8NIfKER0R0R5aEIuI o7ne/jbr40rj//vVO6tvmPqbv33/sPvv9f1+v/whER0l+3fWGCzozndKDtBf/ptIoIuPX+sa/e9f uMvu297dfwf/7/3/8ebrFf7WNex2xsNadhq+v922rEVbdI0f9tbWPncZjv/s92rOi57j/UtIpVoQ YKqdoRFhDQ1FQg7EKmK/p4pkx08eDHxTFE4YaC4MbYXvjbSvi53l/7mHKHKHjERERERBhbhoYQiL i0Ii4hxdpWF4eK2NWN9LDHbaVCLy0BaEWhEREOIzIiIg4YQ0z/YVDN2jRjH8rkmdrJkYzvoyB4US ZZQiE9p8RERFpxDYYQjU+k0GS8XYQZAohES+asEM7nHc+GRxFO6ISVMjsVE7niNCWoQumjQ0Z6pz O9MhsJqf0juBCfKMlQsZDkkyXinyTghR3RHQIU8dgYgkLx705tU2bVTvSeur1n3T4WT9hMJHbhDp uCBnXygy5UuEGQ2bipQU7HGasq8gaOxwh2JK3/e6dL+b76Rnu+ZqbPonFvncQvzT96TRt1UYIZ2o QZKQkzlOEnn0QwiZOzZqdpGt1//6v1NIuEJwX629kx6TWsIQYNpWkbvejW/qe+fXSQbamdrQijZ0 wgzqE059iluh//X1W69f3x4x0Gxpqh36fuu2wu2e6eqef+f6veaf0aOjj+ZEmsRxHfw01an7Mf+h oscJ9383+v++vGVtkcLH6S+LHu3pBtGHPGFTbZ73uM3fY+IxXe49YQ57nPs9hf7Prr/SWuF6/16r /XX/xpf3nPmnoLMOccoc4/u9oLN/M0UoF/IoDhAjlFhbCgh/k4Yfqffn/OE9/zWCfQ7/v9f7XQeE HYW0Ii4/1vwwv4UEFUZWwXqLVqNc+v7V1WGbqH9199JZ9iXotIpUREREREWhEWENRzo7Ux8cnZx+ DOnpAzl0FhkfX4ZzYaUUFIkC+f7Co32TdW2saW34xEZGPpoRcPsELzI4tY6EY8bG/xsV8U8U62e4 1k2Wol4redibERERnREREREZhzDxwwQwpyOwhwYIXDCWNiFK60jC1yJpRFoQ884iIzOVEGEIsIRw 1CdnYWYSJDSITsgzTKtFCKFCIUZsylkUgyLMiGbMnjs7OwLEECE7niIiJS0JAkM841tUk0Eawkh9 Laad0l+mvIfZqyTiD0QhSTsGpOzhkZEPKnEClURoER90aBCRnFcNBP/mDhA86CglGhoIHhozs1Gg yQwgyQZcmD3JkYSvJDQchxcM1mg8KUqIWzhnYktfVU0jDnfNP3/5jo8vTes2muabp3TQ6TRhzDhw QdUoIHQnH3MPwey6LoKahkhmCZDi3Tr/XVb4bpzQMR7XYJ/k/rcPLn0/Zjqe6M5cOp74nLMZHXPA hLzDpuaYdBuE8RJ1knmmn3DhA52on/7m/o3///9e1xX71vi6v13TT1203x6tOYfTvTrm+jD7CXc+ aRoz0113/X+/v7SmPmgpyn+tNd6uvtf+q/6rj/9frWL1/fOdhE3jrdVe3mD+96URxDSv2l1e6EXi O15zqOI/yf3X6/+qKF7X5vVrr//a90F1T6uL3/2I+L20hPEw1+/iPvWIPsKhG61Y7+ml+/v/5P96 9f37f/0wvq1N5Q+ZynOOmo1Yq/5z/5z5hzjlOUPQuK4wtrGtkcJEcRxHYQK1wsR//GYXr0kUa74I p2CKHwwQi1QiHFphMIRaoRmPRGM7iIvM5TmHUKY9pXpoLELXiI4riMVnh3F1GuCURxEcREREREaf cRcRebZXax4Kc+amdynKfJDlD6nRzuCwx6tLFcKLKblJQWhFqhEHZSM2/OjTg400qCm4p4M7Tgrm aEREREREREOIg0zhaF+VyRJuIiI08e5bKr/O5xbAsgt9QQ/4WV1IMPN/Q0NlDmbKrjtnu1DBYoeY cw+VzPoXldYEJmEEahOjZmm6QpNlsFX6fvf7PevjYMJFsGIuFqxV+boYTU/4iI/+PK6kiQn3ZMjP RbAFjVU9A7ujQ3kHaSVHt80FDv034vnspyn7e0EFxF7YxBFtMfVhvlpBS7u7DGIh2i2APBkmklCK t48hGkaS2ng//////////////////////////////////////+QHQJR/////////+WoXUf////// ///////5AdAl4//rv////////////5AdAn9Xj////////////yA6Jrx/////IDpb+P///////5Ad A1H////yA6BqPIDoGo/////8rkhlcbzsS4QMrhBTsQGIRIcMKuCM6ZynzQW+gnSFxhB/eKX/73Tn 19jjui1BcM9hK2vBgpusVNpi07VcRF6lmFiEZZEiLecCcrmep2ki8EM7VDrp6LHNslDKZJVfV6FG jyupBVMtUTNaM/c+qDZZiMaGgwmXCV3ZdJr+ZzucfD1+oj77iIeGM3f0THC6MJd4f7rYQv2WdZBf 5kI62LXtd4iI7FIh9qQjnRiwtb4zdmPftNNP8rkrMgmd+jsTxEREZXUwuTRWdiAwdzztIR2ZKiQ4 enqTT0GnQIzuuaDRu0a/hOZciPEfBFD+xoPXTdFmI/aERHul7kZlSSvf9dLv4aD87LGXCe6Z0QQ/ tYcP9exr1dAhUNhuoz/LOZAvYWoZexJrRVsPaV3wZQ5Q4IXaYoGfYoK9nRiIi7C2h7WIiIu/qTcj L53POxNCMrqjPYWzscVSaRA8qWQed3l8qShO1wvnoh9kqEOoQJ2tGh6BEfebP6uqq96bevIIkh3p 9G6jckZ15Zh/t/6DztJFwt/0NDV9L2/+H//962RIMPtv/Ybnt5/oetv1X2Gx3qHjH8nB892ct+dE s5kC93Yiiqpfn+8ZoGLVf7uwhm6P2DOF7Yiu2dGIi04i1z/nRaGr4iIiIiIvyyquLyb1RCs15hZ2 LRCkR0U+Mm5xNNOGd0ZHggyEQQhpnf5WeFwrwauix2dYIO5E28/+bvO/ncNdBB9NGvMOH96Eieb1 XvDDRn3V1PFJsQ99dMIdeIet9/6wk/+v//9f7QK8iTLhLZ7Gf99HajBL19/6tD05N7DHvrEJvq1i u1Ih4z+q/EVBRq3WFbo6pZ/35kRw1CYqNqo0K+riIhqmmELhhQXjURERGZNkDK5lGVWRaNovEHkJ nbmd8yXiFqV1gQyn2EIzoENQiDTCDKvCBnYHl8hfC7zOlVGiEW4aLHZrECYWyUhM//qfHNlF3Sbh OgnSnyrpFmdl1UfFXp4Q06t0G0Yc49W0CLrReQsP/Vj/da9b11dwnXvr1f+767f61igRH32cgQ79 s99Npf//W3X46dToEJww2utq/2u/Zz/qDOFikltYatpft1aqRMMf5v4amrMexCJkGIrY42IpP+0I sIWmmlDQ0GmpkK9KIiIs5ERERFiOTZbR2EGYxEhaalcyjstChSHlZwnZ0M7jO0Mg4jBCeNIZXJAq Hn0SoRG5umkEzUkwsZ2JZFnSmj2qTFI0PP6LcMELmTkh52TEQebtT9tUXmnSf4Toi26c9BUaJZk/ tilu8Ifq71bmi+fwYbzdqzakEaS0Pt3++79PXxsMSI6HdO/qh3rqYUf/4bh/8uDO/fue7vpVtf5y eH/VO8rqodtKfsbYQIjpteaCnvV64IEc4dnuI6b8KK3WDCQxHQ9rEefQQWDlZDHr2faWh5/hiEvs VxYQxWc/riIjQYU1Iiwp0fmRF7+V1JCIiIjP2akRFjHZNxHQtNNcy7IPIVkry+dwaiYhE7V45C7J Zq1wumdj6hBlS4eDUIeto0MJoJFju5FTSXO5Q5x6N1LQIj7pNoERxoIPU44MsxLXEQbSGdzvIpm2 tfT0GqbxByzFlJ939tMIf/rS5E82IEizCQJ+/6mH/+YT0cXphQgSXWzn+NH/+1VdX+aCh7zud8aj /+9Xq9e1GhcGTZip25XWi9j9iKi6iN0vOzVf+p/jQ7SHIx8V8V/EREQwpoKgoeykWh5JmLP40Ihx ERnZiXY5N9EIiNSbLaIaCDJWMrqGUiOuMmypgoQuyURc0GnDIFnd5fIzLqENEWGjW40Z2agkOwth bLMSKs8LS53BEeSDrOOHSuthB53PH3IhU5ELp6uf4gw9AiP6BEfdP+vwfcP9XxYZdHgevryISND/ f8PpB/v8a92voOnN/t/4d7D0v8IuMw5Q5TlR3p/Yfrt1iMO2rxrawzcdBukIj6X/D99RWDUUSe6V pE4Lwt+9K9W/4tTHiGhHDFcK62I2IopFEcRERanRqh2mh4iIiIjOjJuZoak3EsjGiVZIYT2gpLOY PZ6iiQ+zQpNTz67TCaenZQRG8IM7FdSmSVdOp4o1uaGdmu+Xz9vqEzsdkczWIaBgf19Ok369QrnQ cJmt9hVtv+vT9/7/03CRnzdZ4P0s5mi0lldfur/p/X1Jwwl9aQj6nXCCGhWNdf8ZHwr8Uu/26V6s qtb79QQ2I/uZyv6/XvZHy6I6I6Uc3NsK2t0kGWOYfazn0L3UfZ7tYiIir8MJMUwwoZblDhNC7DCW +ratKaAu6TxaYppig4j7FXW7FUvFDEGCYIMFQuGFBiO0LUx4aiJtCIjiIiLClk01J8Rk3RF8p4v6 2diM7hwuF7C52QECDKeL5Ush5/O6ZB51/f2gpBNj0W8LrrnTtT2UySqjvdHfYbQVzDnHUJtAiP29 +r1jJssf67sVOd0IbV637C/30H/+1b/Vr5FAw3BF0TIRX38P9/IntHPx//UMUIQ/vKZJVb9fS737 un+dF5hyx/xjB2NKNYjFSaBXX13NAxQnsnDCxjYpSnJK0mNL0/qf8MJpnPpm3QcU6s6F4MwPxGhG EwgwhcRHd+IiIiIjk2C8/EREIjpHaUZ2oRH+kQwqdH9NCytZB53EXypLfVejQ/Ooi2F6o3bvSec5 guquSgJbCBO2Thh+m/0Sejx1KZJVDFDpX/nFkRkiMBJ3vp87niMmwIiOq5nM5T4/iKhqv/X/CESK D0I66RjuDefv3/98hhe5/trc59jv2//vmRhf6FpeDr26t622pTJIojONoeOyPiLW8VEU8UMRGeZT 4xxaaF+LtCIjJsso65IQiJXdSbBZw0Mp8hM7Wsy1jVHYEpFTWlblAQ1oKdqgp2a5iJUjkdUn2iDp qlOzOXFQQwqaDhphCCI9BqXz/NzKZJVrSe0bkkiY5Q+px+nTcOl/H3T1jO54ZBEVDghGkm6nijQu eA99oEC77Yv+dBp///W4g3+IQLpa/4Ig4wH/ul//arW/qzn+ESxw+z36Vpf5DwViODsMErUnDHfB EiDjHHsa6axBOCPgOxTFW2x00DW0F0ojhBm6obhhNToQ0IjP0NYa+Cd44iIjuIiM6NDshE0QIiIj OmhBNxdDJstZB4IGQkQeQcS6KmjumStnZnlOpNlMRVNYh1EOgU6Sdnb6oMqWUsyPkdKERpoTCujW 1WsJ4Q0Z2SoRCI08w53rTo2UbqNmp3fpOssdI2dbmmYCK3Q0Lh/ciaVHnptGHO9hTZq/6r/9r6Zc LiRGr1uNN7/vn669jv/8H//r/cd+mGc3PfpbU/2z3Ddfb9/tr8NScMIZ0CxpD8bd16/r4rVil0mg vqD2tt9raUWhaDTOjP9nA48w5Q5Q8WKaimKY4iIiIiI0IuGhaaYURERGTZViVjhBkJBBlRkHnRmI p4vnaqZU4iqLo7GKmahEXk1iHUT1VBlRmgLoakry/RsYVBNqtOro0TUEpTs4QLfefu6N1G7Vo77S bSmcuMET6q+rxroaFX96ecc8RhP8/0CL///31/tfWyI31Gv9f3fv/023vDjf27awzdHntz3a+vV+ /B/6ybFqQaUfGaBhsJX02r/q3OfDN3VUIvmgoc79WKYjhpesNIHS421XJD5/tCLz/Z0WmmKdimKG /iKzkRERoREQYJoaDUj35vhqIiIiLQiMmy2hk2LAXJeIVnUZUshUd0RDioRkWfyVypnWLs1LImC6 wakajsSyDrzQaFghzW9NO65Caz1nZMQ6hIPSTbpJPU7v57PnnsP3VbjTmcXCzud9fvuKTeNPqlP+ eAfv/b7X3/K3FwoIFeaRcLO53qIhuvz9/6f1X/phpLS7e9uh3/v0sEP2p/hhobz839yDQXa697ax hYVqPhg1FX/s5WECsVXscU1QMwWwl5DglNzde+OKtCItBhDVMUPEE117GsFEQaF2EMEIiI1N2FJv XiIsEIjybnEIpk+aQjJsqMjwUg9DyBRfJ4pedzR2dFQjsC4V5lZh+wyOiOiOl8ujNEqETIOIPTCh Ayo69Ahsn9CIg16TTUmm51CHUIdQh1ETNeCKH54Xn/DD5no7299F39JJVRrhCPptxozlRBhi5P/+ 6CHudzvk4z/Ru0G1+vS7a/96v61o8dRoV53PH9Tg3tpf+xFfVK3ptv//2vdvCRvf9Xs9ggyOVt9v 3f/4tc/+oIEorekGbnGhv7/ZHRHbZudf7FR8VgprJiK9QyY5k+19YjQ7Su+GFi6HTi0z/DQvFcUu xTTHFG6MznHKHKHiIjWLQtM/5/tC8RaEREREREREZNw0MmypF4EDKjJpkbRC0d0yERUIyFB09M1C ETWfSdnZqakPUjEma4vkJnYlIOEYe6NlOGUPTyUBEO0wQwuahNG56q6uflBhL9KvVAiP2rpP791E GIVuaZtEdAinU7nfP7bCSN6rdGHO6Wm/6+wTapoRH7fsQWP9bZ36JGYCL9qn3PoUPX8cNf/6Du6/ +tqkM3f7J9X/+4PRnO9vsWrDSJwxNz/8mgUISJoGR0XvX9scXyOFxUVb9XtrUjehHGlbdB9UOGEG pyENDQxUw59DkLDFNRi1sm5h8RERFqhEWVNMIWheUjERERERk2LUUgyrVMIM1OGd/mQZksXL5/Re PyaLOsXaZUSkayEzsS9fCD093po0B6ns6V5SjKvv/9Wr1O7Seu/4NffpauRH/vT2+787g98ft+m+ l/mbLhLpc0DGDIunserrD1tf9Ye+uDbXDx3TDI0D9d7U/41CzI4NJrDP/bBQ9MYSdRu0YeCFfiCF fmpYoQZlCzsF0K/PTX/FxaYJxwhY1VBmTrhgzJoqEREZY5TlDlPcXcXp7CERDiIiIxGTcTRvKvIP NcXygiqZfOxNEYqaD9fC53TIemEy+QkQed0RCXXwvOgop32q+dREzoF1O7+d96aBEff9fV0tbmcY CGgY9/r1sJTvvRhzuiEubtV9VX4pfK0y4UMQS7mgL1tqRQMeS63S8w5UZoOOYe/7++Gq+v7UW0HY 6GhfEX9Zzv+p+k6I6W9Z0f2psKcofwymSRaX/vr71HdCJE09d/dOIurDG6++xHuxFfIr41+26G1I YcNxEcdhSSkh5yExQ7UdPCGIjhhCIhhNC0IzJoqERERyblWQmQeSDO/ZiOx8qjIhkFGd39VT9I+i EiH2gyD8IGdfu6NDpvs6iBCU7Rh2dGEyEkWO8/lMkq/05tU/qjDp0gerdBP4ybLGS+SIuEJwwaZg wvp/ejDnfT9XSM8oXTd9OGuqof679b76v1aerv4ODdG7NB88w5h/0/H9/v//99ux/HGheI/W7f7/ 6jdUMpklUHIh//3DCSLcp++oIoeEUOrWPe6xiLW07850x0LvqxER2k0FRrKvaz/i40OIsJrqKmHM PYprxcpQY+IiIiIaoTyDCEfseIiIjORGTYLyWZPkrzJLiFIRojSHOMhMnckFFKZ9iCEKAzGXRHjo iDsNc14Iof2SiCZKxDv6QcVERqgySxCI1xfKZJVZ4B7L+EIqp4qmpNPRvyT8/ow7IKETWxi+GHok Pr2p3aNBQ/dwrnr6DrrwRZBnhgxneG1/3oRJd+IIkWBtXrm+f+gQK9eg//6Xr+gQMMX39RNMwFpe 3z9X/H13/t4ev6dd3Bgx7BBG/91bpbPeRMMAjwDVD73dEo9UUySqTYLwq4QL74aUaUY1nzIuZ74j hm4YK98aEE1pkcexsbXhlucdYVJZ/8ftqlkwJIY0wh0bocRjQr50Va4jKZWFYQs8HcoeIMELQ8jK 2IiLP8WmhjQiHERnCzniIjETpiLRCZCcmypF4l+DIzI1EIjs1ys4qpLIqnC9wcghCTILKVOUKdNQ gzVkYiPm1lMkqoER9+dwdqahCUhM9BDBQmgk1P4QiMdfiHZ7M7myqT6JDwiT0KRs6yx17zQHBAkn fdGcqM7nffPOQWBIZ4Cq34U2OtWqXeLdLrtvWNouKtK9uNP+puKi+//f6H6X5xfa/f6GwZMOtrbb /rZ74fWvxX40ryL63VE4V9X+bnG1BEcjHaq6r9ja4pjFBd/a/jQYfEdpTc4awwhakhAUxgU7FNVM 5T8GPYqtiojOTCFhCwhGhcQ8x7QtNREREQ4iIgwUmy0jsSR2JZ2CeOyXiCx1EOmRrIoGCDiUjKjy BEJ3REL/kpEVT3aR0Cp+mmQea9fQSV75nJv0bNyCVGt5DsIf53O+f11TUE82abq6d+1k2K2XCmgY Ii9vFvJwwO3T+aZtEf5z9td5//Sv/v1xbXTCEfa52nZcI14xRvzHwf9ntDnR/frX/VV/9v+wwRQ9 fdV8Z/vuoan+CIQfZ7v1lX9qhHNz7tI6BYYS8atIbuKjjji7HIx7/THTH2U5MNfZNwXERYUqaERd hTqYQ0kxCHDQzDnfERERBhCIaF6F5NgvEREakmjCKjITNbKvKd4MJ2axTWKEGThgIMhca4vkoZiO x2YyQieNZlURULDXUKi36Jj8L79hDCalPgmQfZ3DQIj9o2UWOUPQTc8FxhNuvVnWI6L9PU0MlFYQ zqJoN1uk8IQ9OMJ6bWd905OghEHVz2fKTfokOgkWYjiG1+hx/tciUXCrv4TvxSbp90b87nfdX+/1 enXr/50Vf/fofbqTYKgQX7nuz379q0jdv/Hv/9Jb/7EL0o4NbXV6Hd9K13df8ENz6/LOZBigmI1j bShpQ11jVtLWGla2tR/5aQKsE1NBQ+THsUxTFNbFMVexTDCTDCTJuCT75jx4YJoQ8qaYQaDCFpph U4aYpig4zZdj+IiIiIiIiIiGEGE00GhafiIiI+WkVUmyqjaOkbyLRsypI6o9iNSuphQmt2a2R60z Uy+U8Fg7IVERnZ4lGRrIPJSzGU5FXjTW6dXpndrYQ/JQFOkgzs1CHWLtT6NQl9pnXWi5tAiPvVoE R/reCI+6wnSVVVPVSHdOi4aalMkiwnr969V0vRurc3Wp3c2Wp3vaLu71cJ7yzD7Kr7X10u6f/xrq 0t6dJW74Q+rrbEER/H0/v/3X/+L6731//9ODQ+1/1vpx/3Pq/usX9Yr9/3y0itWGFvW0n+0r1hq3 SsaS30tnsEPW1IaUswcMDYhMRTFRGwwrEVGxRKQmp2ahGNZuxpWk9RBFz7CaaainV0mtKl7wy4KB BwwqTzoxBhCDBBhMKecMFONqcajU/w4sIMU098RERERERGnEWF78smiEREfk2C8g43lWkyv2IyuZ Sn+7NYuROIOItECyVcMqCJNFQju0REbyMX+nCyHGKpB0FuGp/hpqFCZfTtMv3fq0THKHwwu26vzj ho1s1CHUIu1hbKZJVW/4Qh5p5xzD+azO6nd6iG6dUkCI/aTaBEfcsw1EGVwsMPq9DhtWnJ4uEp39 7cGDLpbRnKjO531vT14QfQ32/pdVX0l2+Lp6X9tL//Rf8x/pZ7/bbam7/1oYImP1+//7/4TZaRUr 2jQU+1KNDFb8a3+NJUEHurbf+9df1f34uxSGCT692u6zfIZba+v79Npev+mmtqaChzD14p6Yxa/h bFPddrEbFMRTqMRERhCIeELQ7CGh6doYxYw001DSiIiIiLVBhBhBhMIWExlpFiiZoREREMEMrrGZ C0eyrRC0UakUihDsyBydlOKRaTkH3MxSSrK6QnGZDFzLUSmwulnboEUOkwTS3JRGIizNu+sJ0Rj7 Wf4QjRraYS5P3aDtB+pxzx7n/a6C6bngQsN1SMPqeOWYdb3/xJVUEEjOVHdWjWiOiOiOsMG9U9JN qWczJPS2314hKltd6BCIjBsf68iYYT//9nkmgR793/N7r/+s9t9v9qCDBMECI5hLtv/+dEJa+vMe rf+1YYSCHTob62EojXCBHqKW0kqfb+8UxUtyQ+nXimPfCVOrGF934iGgwoQu7s54u0jHjoY01j2x xEREacpaEME0I4jQw3iNiLOeIaeVzNHZIjCIx4iZDMXphOyQ0GSnMRK2R47iL8GVrJRlURtFRndp RLSK11tCd6pq4Xhqp7CalOKEyPBR6BEfdGdPoER5dedwfWthVcF1X19U877ne3hhvegRH3RY5x6B EfwRKMrhYYX97/IyrdfEGGRPN5H1fr4QjXYKPf/r+0/rw6aEd/6pbou+dH//Xg/W/C/H+//+71sJ rFK2/T6k+CCGf6/2e/WH/Yioj1KijWOsECXm7esbfUERyMcdqazjsMLFimOITrWxFca0G1iGCaEG hFphTJV9qfrFYMcRERSERDC2gwhD3EREPK6yzsyzsayFY1CDO1UQi+YZCRoGCDycMEKiaZWkSjJM zshDRohU1NYiXkpCZ9KgZHiOgmd5roNzZqwlNBo6NBb10yUBGIg5oYIddJ6RnyT2km9qE8/L+Qg7 Sbv+PVzvxpzQMCrqNujDnfP0PTo3r7/rt/1dN5GOtyXv1yCVDfMdnv6f/nR9tDh/w1b30H7XOygF 2P/tfvs5bD+4brfsNsswpsYXpe1bS9tIiYLo3W7vb6q1bPikcodDmmUPaXY4p9ivyr9uiT4ai2Eg dCoeY+ELQiLCDQi1OhC4jGLFMUM1lj29OIiIiIhoMJhULg5aRQoiVwXERERGTcrRCI6LO1CldVjt aR+JeOhgp007M0CkJkKwgZCyIjMIkM9GpH86Z2dEdEFXPSfoa8QwmdRCL/aYVO9PsjxfIOBCDJPX +9batgiTpbtHujW1eE3axEHhM1Wp6v/z91RsO7Cujd37MdPBEe6fWQg7dGgzut8sw/vrMwxuxKrW 4Rdxof3+0nvuERzI/NkOtO/dv2K/Gw1//X+vrri0Neci4Xbb3fy0itQoIcx+T698Pb1/fMLf61v/ /W1xzQU7qs1YSCEi6a5xxl+zmCFRH0v0+CZdP3U/bXBFPCSGWcyDHHDLr2EKu1HDeh1w120lsKi4 HdUKuxVxGq6px4U5FisGPBmGHPiOIphpV2o61UFN1nRiLQzqSEHn/QirTFbsUODBCDOET3ggoiLi Is6IMIMJpwwhHGtRvQiIiIi7yusIyLWJ2XxEcMyqZHggyEiDyFanYjIXmsyrXV0W81iHUQlY3Lov 5KQgTs7MRf68JsJBIFQiS3Ss0M69hfU77V5xzD5xzPVvmcoek2utlMkq9b1au+/O54znkyRddCHp 953uO1/r2/b/7CEb676/71b///v1Ft//9P1av///zIr4Jkcb/uIyjQrtfW28a8lIS1Qr17SF8exv FHcDfVtJkxzDhMaUQwkScseIYQwhaoeZQKBxGKiwQuIiItMLDURIohERk3rSlukztQimlalcyztU ZfOhhTWyPnXs7KIvncRfKhErNTuihkGh2toaVqepC7AuuqDIbCRUZK9YaZZh10CI+8w9N34Ndb0a 2mkawgQuHIOzmgfr89oz++emd9oER9+tGcQkkinNu5XCwwvtde/tkRrvXkhKrdNTud6N8MOazO4P 14t/d1bp16+CGRFT9L9CGy/TuDZaQIqMi36/SF/B//rB67m/27Q+8GGP/U6a36tbber6zIsNuv39 z6CLj+wyP3uIoIUxFM/RPoJA96X17esYIof/BhMhjfrj+1CfdDFiNiPwahrEfaocLtcETjEQYTKS BDUJhNDixU1lD9iph1C2KEs5kN4iIiIYIQwqE4hao/07UKy0hZRERERERQWMmwVlUZLxkDTVSuZU kOccocrU45dQYQZKkbzseKdl0R0R0pF4jaITIREqRVGQWES0hdeIiwhot6MPTTkEmIiOQQvNYqah BlRhBj206bSDapsNFj2HhTpOp6RbvRY7LMhefju0bkk9O1O+azPaZ8y3Ld6JjlD636fQTrK4WGPf GrXS7Ijp7FXhB34IQ/d6TfTZB6n/q3/96TprvVr5uLhcf3pzQMK6b5aRWs6P7n109GP0oOv/v/9g wv/9/90uGFb7+Pbv73ran+2ewQMEkKtZ0X98fcMKMcMLHtKHddtK/H40NFjgiPPS+rUNfsUrFRup SKKGKsKPqyQ5xwqHhq/aQocRDCnnYSJDnHi0LQaYoebINCLWxVbFcREWCE5iGEwgwhp8WgwhdpG+ WkVqJ9CIiIiIiL4yuss7Ms7NRDtaRblOPCDOwQFyXyDgkREVGQmRREfLoKQmRZGM3GvMIqWdEdjE pCIaLdpGoU1CTFzO/QiM1CAhFKmQmU8qZtF81MvqQmQ9I6aZTIEtB2eDXCrWvzD1wr4Q4iDXvCDC V40rGm5xzvRu59VPD+mbKN2eDXQIj/qyEHrdcVqWdS9OrrvQxf5pFwhPmAg1dCNN036N+frc739G gK1LOViFpFa3/Xfr6qmqT++tmcXC0Pv+RKMBCfMBKptHdJD1/3bPqcH9qW5Q+pMf9r//96/apr5t AxQow5326dbbW14pIYQuMED2rnvXenn+2fX7+1P+pu7SfXZaRWthYaT+aBjPWnf7aUbfdKPyQ/r9 R8a9PNAwu42KYriuNqmv2NWwkxFeh2rsRX/Edv8MINC1OjjQ47Cm6xTQ8z2KFp9/nI/xERGfoiLT Wwgwno/sJhC4854j3lpFak3qsjoRERERERERHYxk3oIQ2hJtYFUrqsdpTL6pot2dchMgcSuL5UIl iMZrMpEazJPIOOzVCWkWLnpbRhgIjyCBvPans1CLqE9BqgynSmgLkK0ysQ/QIj78J6fv1C51CLo0 dFvCHRKLo/5Z1JX69z2ub1b/0bs770d9pN8JtZnLjV/2WkVrdL8W/1279Cu6MOePvTqrz+hhP9+W cpCjvr67/bW/r69f7NAxVqO3u+RPNiVQ7+cZ1tUKjv/7/6X3X+GqYVG6WkWLMPfVYjbrVz3evu+r fMjdWeX4SQ+ZwRH3b+eo0s9rYVG5z/Jww+lba/WvtrDBN1BDxxscfsbGznsV/rEU8VEZQCfrHDSq f/8RDBKIhhC0OzohocNBMdikWPYoGcJ2tYzdBghGnDCDCYUuyhyn0wmj+1ji0WcqCRxEREWEIuIi IiIpFpFqk3OKOztPCusR2aYU7eL5CZB5C87olITIxlWjt0cx6o258jEp07tMKa5SHWmQcEHZUIhV p/zqE386iBDQlDv6zUISgKWdSRaRYvue0d7f9YRG9UYdB32nVJMdnakC8f6M5UeyKojowvCJjoZ/ 0+tLaIx83Szlgn/+l/BCIylBhAm8V8zZcITxcJXO6ciOtdTkZ9///r00vr7W9/4Yto3euvrvYIc6 M6HD7Pqm9pG68/K0v4ekJaRWt657jSu+u/mcWXwRxyMfDVR8VttfuGrjx2NjeKBnLP+GMIRxH/2t t0DlAX00oYQ+ND0Dyd5GPHHDEJ4waQUM3RGbogwnERDwRI50WmmhcZmdSGWkVKIiLiIiIiIqMrhe dmUUjO6I7VoWf/gzqdlKIjwTKCI0kGQeQWIVlaR2kEIxCPL5/g8OhFJhYNTykZY0zqjcSxkeUEDN WUyLr3z2DgnmfNElwkhdFchSgg4tTTV0YI1P/6sXzD6mzVmNWVe9lW21VV6Rr6lnUse9Haof5L5B 41e/O54ir41Ph4z/andoz/P9N+WcrE2n/Wnav/+EWMeCLLF6j71tsau3pYjbI634ODf1/7jvbvS/ 1/fRIeWkVqHBi/24esR/YMGoMH+9pf6MOU4Ijr0Kne4wzdOwuCxGHB7S7v5+t2vDNzGk31QiLqq7 eriCxBpjnPdiiLhdyLwJNpNR6xrmatKbv8WpOo54sIRHkafxBRioa2KjYqrfy0itRhCIYQMKCEZa kFN8WmtoX7xiIsKEIiIzOU8R2OTZVxGhDjRaRYpXMsEDIXkHEvEqMlpERmESwyryER2dCI8rqvyx 3moQ6iJpqmmpqSZrZHyElIJknkIiEx3aCD4UKjQ0a2E8IuGdQgQ0rOoQ6hCKGEHmtEdBM6LLOLfe r5+zZSbp53vTrSuq1eEIpO/6uRMHUUhp1tfq5/z9QIv8/pG/CR767yFaZrX6/9PXavjt12o4/Zpm AiM5Ua4ZaRYtr6M5Tni7+YX//j616q6a138zndjBCnXEXs52c7STtfr7vfd3pakxyh+m+tCDeoaX xcW2u2k37aUMxHXLoJXXZys5fQwQvb4IVuWkVqDNtbG+ksRVrEdrGhGxaxxUa//3jphDzdZ+SbFM JiuExSptBfeMGZnBFxEWnF50Qwgwgwp/zkwmfs3RccWqFS0lXiOLQiIiIiIiIiJZyUi0itVTGkhl dYZfO1qJTF81jCRrIq8hWVCIWiMRJUSyEa52phFtVTyVCqStEdKFL5UamuL4TO3ymlCrqro1s6kR 5Gt4TwhFhbNQhqEC6Dz+dIuZQZchzvtG+gRddNhJ0vl2td1VbRr+q913xIzq/cIuI7k6OIulQIdG 9IEXWjDndI3Z3vTd7U7uFPEpkCWv09ddLq0GEI8jAxjS3XdD+rvr9JWP14P/7/rv+699f++lf3KZ Alvps5N21usd01P9z6RkXPra/7/1Q+v8bGqGG3VbSniXnUfj+Ltf9s5vq9beuktisYimKwxTBpev qxaV3od6VrP+NKOimQNWp5wwmnB4oeaARHx5Y9jaY9iKYr2twoxEQaDCENhhC0LvCM0whan+00OO GEsRcRERERERERESmQNR5XMo7Cs/EiIPP5EIgmXzrEKR/KhELR2toqaKfHV+e9TpINbo+l1IvpkH kJkJk+TxDNNQgyGX1+1VNX7te0v43yVCIPKZNFu1/2p3affr9/8J1RrzoKZlCmkCZXC8wEYlV+wg Rde6PH+17SX57Pa7Ru7emWYPBBjTUGrwYoUl/tvDEEQwwGIIkRgIThg0jAQcUnoaf9fM5T1jq6/q NrDWq69/8VU7stIqUcXOy0MKTg7Gl1qRSy6RkSKpefsx/Nf+/MK/cfac3U9W7Wf4Qi/CEiB3pxoO T6m50mznaSc56+WkVrXMRrmRa4ivkR3///EcMKhtr/+MaERxEaa9nIQ85Crf/YrQiunS4iIYQiIu IjjjznQan/yTMONS0itRERERERnQ9pIZNllC0ToeV1jOyU0zVF8hMg0VJEgyFxvKjJRnMlaOIRGv p2dNM6QTJRp2nZ1iOlQdkJhNMqM7Es7jMIpkaVthNq8N9PdGQULrQja/b8J36Xnf29Tu/pafp+v1 yzgmXQ+nS7giP/5EL76ufq30/zvsFv/77ekrp9se++5oGPJwwdk8jr9/rf67f1wfS6jfr6nYxhCN L0CI/d3W6rjb1sEOZynKjdes2FX+ZzDnfX/W/hhJ01sPHTdUIu2p1JJusXtaEXGf7eq+WkVrbFMR Vu0FKvZNyh18UhsML7aV//X46DCoRFoQ0IySmoKIVbFNfxG+sRIND2GFOqodhDjtX1EQYQiIiIgw TEZaRYpN60ItJSuZZ2t5oyOjCClPl86o/EiI0jsGz2doRPGkU+DBDK6r6oRGFtOpBAyuZ3P7IXrG gZUs7SkO87Ugsw9fTYabnY4m2SkQ6BcJkqEOzVl2QkdQnuqZ8oER97SluWPrWFqkyf5radJnUSiz lX3RnKiO9e6wg7fow537ow5h83QYek8/LRnqi7qfy0ipa6VtK/wxKT/7rdemndthjWRCUarRhzxQ T6j1/v/dd+v/1scN9wf/T9D8EK7+vzQMP4Iftv++vUN/9btt9W+2rev/9ra23qECOdrDs5R/bue3 UtIrUGbazjioipnK/DCiybgrftL1IYUILbw8VS2/GhpaFppqhFig0LUUGKeKQQTI44opEm0r2qqM WCDCDCEMJxaaFpnGDDQzchqmKmcp83YiIiIiM1niGCERFhNCH+WcYmhcREWstIrUrhcZAWQmQiOm VM1ESLx2nQj6MI/mRxDUIqka07KpWS+FIREIiIRhD09VvPR1ERochSxH+HION7OisJ36tF5Rs16p PB/BEdtrrhcs6mq9UNCTrbpGHO6q5sKH3iw5rPGez57ud+mWkVq/1hMuEfrb3oQ2+GHV2Kv1rt44 jvdUP/972RaXerM2Rwu9f3c9tntqbq/6l/0MIsfX/Xr/lpFagzdjJwwPzQU/7tK386IIIPet0M/w Qq9SzibLhPWq943bdMeKz/QhO6vr+/Xjfn/MeNNU1GhRlQvhcULFeDNyiKYSN7iL7TQiItSQ5Q+n 63aHoXHUtIrURERnIiIjQMEDCFwwvGWQXyhCIiIiPK5lnaoMqEU+XzrkmjCUuEIxEKZJ5K4rrcJa RUuqhdQncYUvhBlAYQMqWVCOmRrIXksRhKMrkgRGtnURbz0uyUFDwtot6hSViGtFzU95KhATshtL pNqgRH36QIj+4ugRH3puaC3U1tQh92vpoIs4IdGHPHdGHPGvfrsGH16TjCbp0bqX0jdR36M4pBlp Fq19df+3ruwx/q0nStIZ3O7f6de6YSNDZVXt//+h+r//3u/vdGjI4XGt/oOPb7X731f0v7rq1/4/ /Xo3rlpFa3q2lbfarN36BAj3ev2r1Zy+1Gf9nv9f7G8VG90xFVxGEtiKbVvtY/qbvxt9MNBr1pww qjafDUbTFMUxXsdX3xHEb5jiwg0IYQYQiwlaaaan+O+NT9aRY5xyhyh9rlpCyiIiMx4iIiIMIRGh DBNCIh4jhxcRERWpXJMyHzoj+UZCM2ZrMZjxqfWmqrhMlkXyF5CZCshaKDPZVo7ptP1OwuvWGZ8I HRcMLZF/yL+SpEfT7CnWLslIUlCPQj7rtb64XBEff+7QjabOoip6eWYfLSLFet4gi6OsuYftpf31 pU6tTvmzDcswex3+aoWP9X/3M4uF3IhTud66MOeKXdPfplpFax667X/+v+g1266/ScciKd/DUanZ aC5I0y6Rd/3S3+ufusN/v9v1uHt8Vm7USnGTk8R2uqghjuCFQ/9e++uD2MszLWdhfTwvJ9DYiq+g /7aVvseSgK9vlpAqv+9DNRobgzhFgzBWNkh7x0FopO3LMHFL4xHp2qqSHO9hY9C0xCFoXmgELTwR HOIiIjOREREQYTCGEIjTlpFiiJ2pIRGmxldTRPmRGXynyWorXZ2NzTUIYW1TJYGLO/2yV5GswiWG RcyN4iWkWKqv57Sg8/weYRmgmmgzqj9ZThgbPBrwRH/+aDD4et6ae6NDT5x0pZxeOHFJ0m/exoG5 4D3IxrWjv0g+6if5oNFP1et90REk4htvDDfpdut98aD0DZaRWu+/yMfD97WRQP9a9/GlcKh2vVaH D8mmCSGETHxH/16/mHfSbVeRj27WISnTCCDvfXghs8GHKH3/VhrEVzcwdtYU3YhYM3X+1SxF+trL SK1YhNdULEKCfQXVxFMMJBlufXthfxtBhNCLVU7C+nYoONkdCxUNBrERIGhxGsRIhBhVFsKI5N0o QmeIiIjQzOceWkWKTZTZfIPIOCRri6KjTKnmEd4jCIxEuiWoiuRRDQnkNfNQiBEdBb2GE0yEwnYT L6qQgYsiuQrEa3rME/DVzqEXW8/5fP+pfP51CEpEKZA1Rn+jdc+kd95TmjD9UCI/oER99e+ZyY+v 1HW5mGKGNdzTNojpQYdPc7ndJd19v1cKCD/o3UXn//XqEI5FE+/t1v++RH9CvfpDCEpkDX+eCu2j QC/8Lqv/r/DCwd4Ip9X6vjvVRfPeLekM/wiedqv/r9DhsRHexH3Y0n43Pq9fBBd2v7f+u2/T2e3P div5IexHrC2Irb4jY0kbocM/ttQzfjQymQNWhqf6GwheFbTxtMU7j0xT/jERGYcoeI00GhYQYJoa F2h5/z/k3q6E4hEREREREREpkDXETJEdrCGTYKz8CmuL5CZPk+dGYjWMlSP4IGStH8ltDI0vhV+P 1XRMdrkJkPQdqdmIvlSW1BEnrf7c0PVAgbtcITj4ZThQuFKZA1tQloER9+eDXhOk3a0+uix08qA/ slAQbhGDLuNeaZsQXH6e1W7VaabFhz/R3udUeSwxXf6YX/wxK0ThiCIYYrUMMuv/Cac7nfJsCLtf +Rj//a9pfeMbX+/cpkDUEJFOCI4y/6jP8n833+RMKR+8imCKHzH/hFv3//v3h9jq+I20rVC4whEi UT6qdBh1/69xzI4Y469jYYSk3PHkY5h/xHCzQLeojbalMgSiIg4YQ852wmKYIQeY9lEXXQXCYiuK G4i4iGEIiIiLU6LVz7FQmu0IiIiIiIYUTsEybBoqEMmyzkrM65/IuZeyl53REJksiDzsagTNUC7I oHvrvVQgwQZV4Qwh9EWOtNyCKXOoRFju+CS88b13v1QQbRrfODOmk5NiuMBVrtAi6rnO/Rv10/n1 Z9dL3Bih/ciTI4UrcXCuKurZoGCCqDCbYXzwVH/++v9+l0HHHHG/U0DF9bU/+f//zudyow5h0l+I 9sKKj4+TpBl0R5tbpRF2HQzppP/OjFEYX+hEdpNr4f41MeIhhY7+RMMMU+MkOWGGXRfiNCyhwhEZ yNtDxxHEREZyIijP4i59T/k2WchxWUQeazOyEdpGdvCIjuj+FNQqanc9BlT0GQPIXkJ/yUiBUaH6 LHapkQFJUIdAprRi96ondJv0EG3nvqkCGUysKTYsDD6MOeMIaf6f7Mc2Ubs3aGnfX15WwXIiIqGP IjJALr9PQvaO53ebioSH+3/DVeHu+Pi/uRD0L/3nv5kYcyL8OZynKHKf/f/cMpkCW7n/beZhiGvt /asOhEXiPhm5f2GNr94rbS8H+0n9ToFjOgW7p40OLzHsUOI7FD7OfC0FsZJ8RYKnDCEQ0OIzhZ/z JIlMpFEREREREMEMm43jJtmdxF/KsjUzGVCMhMQk8paOy6luaSDXQNNbOiTO1GbkygOpri+pVchG mU+XzUuq2w0a213w00bnFBfL5/RByOFtM96ndwRH3ncOnp96QIjyQeZ/f7dNpvWUyBqluleIMNdb +qeuFNlHe/81md087+8f/X1dfkRf9jTf/9O66Xv7X/OiS+6+H/66//t/63fiv+wgrrwQ4f+77/Ef 2//GUyNK4SY1iE2rapNxSx6+r69rtUo64qFDSYoMsc4Hde6vSBn/dVaTes/Y0GEggxTQcRYVTnsU xH7GIYqIreINOwhxF2mmEO0018REREREGCEGEIybLSKViMm35EyI+R0FIeRtZFEdMhEZ5Cs6ZWeW 5n6ERyCCHr2pEwxksDBCsqMh5/KfL5UkayIZkwi/u5Y+yQEkOo5/VVz0tnUJqFtNBqC33hM/WezO 0r9b5oNC+aC3Wt6bui4sET6v8UrV3nc756MnS3ukKQbtxhN83cKjP+E3WgRH/XvTeve2Ey4R3DEF W+k5FAtJC3BF1S5FEcRHS7p9X7X/33/WNrtBgih/aFuGKH7TCEa8f3BCrXW/+hn+pOaZH+oj+ayh zj/3r/farTaV1X4r6N1CLtUWPuqEQ8M3GgY6xn+6ox/8GYKGxjxmsfvzDmHKe2lR6bXU0BdW01Xu q7VdBhNC1Q+9CINMbTsV/MjEU6sfsRVwwgwQYQiIiLCGmhqciIhoXYUkrUREREREREGE4YUQaGTb 8hWdRlORKsjaKdEkRkWI7FUMmw4mmmqhMv2QcQrITITIhGt2QaTIUoXmui4eezUIvvmoQ1GpOYIH 2dGgyUsjmTguRfTovOldN+EkCI/f4SQr66Trr9CRIKtPTvzud9b6+sKeHT6M+keHPBs79D9e/7Xy Jhg0i4UiYYRnKijDnjST91X+NX35nJj/fj939V1+6e///X1fq2c6EHv1X/+ZFqfsyNJvdv/1+//+ P3W0pu/+lWKv9v/2q2sfpbqCHT7hhJhrX2rEd+tb+/sUk2tLGt6WbkNMUxC92KaHa3+PitWITStK xQMzKplNXhEQwTQiLTCEWhxaFwYW0LQ00/ExiIiIiIiIhgsanYzKMRk2eL5CpSeKUozplZzuiIvV yLhSg0tfIWi6UhNSDoZJchMlmXyF8LqqChmfyWVPSEZ1CEXCnUJB50ChclQh1zDzvtn7PAq1w2H9 JKlZ3IwrS2qa1336Iw8laww6fZ+c7nfP2fkLXP1He6NmoIj2vG9oMZGMnDAMMW33/21EJEVzbXb/ oPSTlMjS37rm9YfoUOu2PoEmEMdfx/G+kr+EXlhzohL/7duphzD9//96kXDxGCC3XCBHtGcqGSgI /pWcgyQuhf/s969iKhLTQO+Elx17yLhTQFzovzoFvSjiltTjDn0IjobWgWxwtCF9MR7rERERxFnA lOnOjBDzqangp48m01OiIiIs8ixCHGTYdBM7BcRERhCiVFDNeUvJUZJolmUiMiCpBO0QQrOOYemm EDOppnXI1kJoMiMwjrkbWYKNbg7CEUjQzUETfU9moIdRAi7adyHBvn0k525s9HpNqjY4T9qsINhe H2LqwYe83aef1T9vz/Ruq8722Zy3f92Rp21f49q96jQ1f6Qd/M5yqoTOKhf//f/dfq85FwtIboIv Ff/9ehT/1+//PptSZl4UlAW1BFDgzFatpLZys95dEfBFD29dban/YZHQWKq4pJtIIRt1YWbmaBiO IiP6uqH6EbULQUscpwoqSHxhiq79iNhhR/Ix4MJppnVAhENTkQ0whedGf86MKKHzziUiERERERER EREQYQxElCCkXyFYybPF0EGS4S0yBolOREfyU5lHW2DSuHaBp8GUiIiL51ZiIRENKd0RF3C87kYZ woGwzXbIQhXBmuCDC/lOgQJMEM7cQl4J532IfncMlr7nh03PAPVenBCOgrzw67glDNxLoQYYYPcd Jxep3c77q0mVZ8ovFq5ta+CY03ZFPwRPTggSW67q87ndik3T/3/0oYVUl/S16//f6E0i4Wv3pAyY ZwIMowkEXcJlxhh6T9f//+3r/fUi/7cQRKydCgw28GT0Gk3q2v/57Fn/EdiKQ7ORJqFWyY4RKsLY UlGut6Vpd9qUoF/7TJJxjCQLBxQgmKiCaViKDFbGxX81MYLp+mCYUIWmmENNTojtPGf4iIwQz7NA VNCIxERERluZx3QzXkJkFy3NLIIZPPpLIiNmZDMhMqETxA8v2QNWHND08/56TTsh+U+CdhbhkQrO kYeaDPSb+/6nj9hCrM9dhp+ug23T3v29LferBEd6BArksPvQIv1396vIydapzLEYCU6M5URYYWlw YdPVf1+OODivwmv0thj/kWn/KZWF/9VbX/mcp+ttuiQ/8ImP1/G6u2EkbnN20bnaSjQuCFfmg3/J Qggg4IVr4oYa/WVF7GEvp/rvSQhfFLaYpqqxadpXsGYJioVMRwsGYJWDBBhCIiIi0LVC9C1C6Goi IiIiLuMm00IyuZZSzMakzyNohMi+dixFLyfOxPldV1QjIvGHn0p1CEH53pZBdCyDyIiLpSFZLEYX dFv09O189E0kyEiLsJtHTyihhDJQsJ2dYu/tT5pGf/Na/0CI9VJsv998sdJ2t9+x36u3J0fVUGyd d9U5P9TxDD+4YNsJnzugRH30CI96Vtd3UJlwnob1//7BjTozuhSb+vqn/SvrH4/Fr//g/uw/2v/+ VwsMX60oz9tGRSdeP9ddtv0//8s4XabSilRurnUJ6Nzil48EEcQIVhj8EP/XWDNs4p1f7S/9Zz6C hBJ1BtWtXrFL3oWhcamA7WGq7a0i4wZxEOxQMwWIppXuDCERERER6FpDxdroaGIiIs8FQUPEQYQl Vxk3W3iIcRlcLzuqLolGU+RTBAyrRTo2iEyUopCETJLPl0ZoLef8ujNGsRE3qE1NbVclGVTMI7Oi pJA63a/9phUCDZ1CLoan8g7PQTtNM6I/o0MqLXzv/X5sVN0gRH20WO9a9d9PSBvLOpLfpdt/ukK6 MOd9egj6dyfved971aTun/9739962/8b+m9LdV373sR+qHEe//+7DBftfyWsni4UiTLhfrM2XC97 63s8l//XPpCo0P1h/pa7v8M33VUb4Zuk4PH/9RoER776hjP8ZvYIVqM/yzigL32Ip99e21YjTm7O ejfb1D/rxr+tqsXmPZzxjamgp00/b7EUOtYM4zrORiIiI04iwmE0LiO0O0LjXMeP8RERERERFxEb WWSrIzOxcztXiLyuZZ3PJSO8gbIIYQZBKRSU+h2CRdMlEXcPCDCaLhhBog4safIXkbRKOVyQJzW9 OHIest3M7QQbRY7m5hDg1Po6hM+qWgnqd5K3DhB0g2k6CD/LHUPTVU87neTIH/2wYMwpz1unq6to EChTZncP5svlnC77araXx90/77kQhCLMHqTYgw36e3LOVBP6LHLHOPetLXe9fX4Phrve9v1/oRf2 9IIu/ur916DBFQDhvnRBKMXQ0dzv//ax5FxuKVpWra2rdnjh/YJJLr32N9imlhZ0K+0rStIN7Ye1 iCm6dAqNBT/eNDtDwXTFMUxTFChixSCq6x3+GEIMEP0GEGEGmpCAqhO8wUn/iIiIiIs6wCcRaEeO W5nleEd1QiIu8rqvDJLkKRT5hGswRCKZwaLfsjMnhDC5/kUrkOLtQqppkt1IcFIVEHksy+VGaiKp mok/H87g10zUIto0Of5KQoTSJUEwm2ahEGSkKnDsJfEPN2p3aoER90m1b0ZxCXXCz3SRrbDsLvCS T+87lRr6enRvVNT/533N1W5s05Tm3BW9AnH9Jf//x6UTTMEq/Q09Othhhisf6X7f/+/RxOmh1v+L dOyKcKoMmLs9/23//+fXp9TDlOCI///6qe3OdG+TTyJAvGr63q2qGCKcMjoJ4JpQzcNCPelZy1W6 OiBE77r+K2kuKYioaThCI4jImC/t6x3RKQjqhCeI48kLnIji7TFTnyHHzDnH/sRWxpRUL4wQiLCD BBhCM5CoT3ORF2kb7UyhQuamIiIiIiIiIgwQgwhxalckIREYQZ3ZELyDyMMho0idmCK4GoReMJko VkNZDahCvOxLO55CZ01ITITOmQuN5UZBrQea2m6doTu1qd2dhKyZ1kP9TUIdAqn1dmoQ6K6VpP/o zp5oPmt9/+9a06dU771fbvT4pWq/792FRuz9fS0bvlmDo/a///998iL3/eCI/Q929N0+6f/rrX/3 HhtaX0GKHF3X8X98MjowlbwQwQr//hhMvhbX2m9Dv/fxEdrSxHa2rYQigQoEMnDFnNVdJs9k4Y/s UDMXMMsMJMMJA0yY4VUqGdAs3Yak4Yr86LTvOexTFCHEGYGcYdHQXsUoMzM4cRERF2EGE0+Iz/Zx uGmdF6iIiIiIiIuIMzT4XlcljvTIVkvEKRC0d0yDRUkQpGqKREIq534hFwp1ETJUM7tKammmQedD uwQMIGQTMI65G0PXVwmTMKrkXD9XDTTCdyCCH0bqNyRs6WvXTsocNGujW17yzMRheh20hIojiVG3 5uzvubvWIMOg3Tzvtmgztwnfx3CEeQLptLdpszjA/sMP10vp3Vf3+6DH/H0P0RJ/v3Sbswy4Ql5A iPt9z3dnlMjn0wf6W80FD7wib33owv/9Ydf0Mi4WL1jbIpkcVvyVIKNC7pHQV9fu9L8ZvcGv/SWt QaQqNQQr4aULtK131bX1f/z/mBn6LzdGScJioXsVBbHEbEVFDWSaf4iIiItOykgUw1ap2ErTQuN6 UREREREZkRBghYjllHzIwhEWpXS87Nc/kKzVF0URFMg0VCs7qzscQ75BlNOCuq96ksSrdGEZpU1h kkshaUhMp8vhBnYpnTGr2pKAi+mrvwyWiHUISoRGGoWygEJkZcjqFU+jrF3f1SR33/+U5rhKtN5F jV+qp/bQJGc7/faydHER8Kqgw0Yc8Ubs45h9nvnfo0Juke8/Ltqd38MQvbS/XTCEZmGDRlwjDI// Qq07GaRgIl3Wtd7b/v1/2/Yj5GPvwh1t9W36//ruO3SS8rhYOUsMf+ljP2ciGkboRO/7Z9X6NXmz 9e7pdofX1f71Bm6r3j50G9t5PoMjoK/0NPdfpelq38GbcGR42Iqt11rhK+qER+uf/e1iLjU6BZux pXERaaHFxceF1FTDlQYfsVHWxFbQWquguhEREacWqEXGsdqc8Nc4TQvEySIRERGf4iIiIiIybcju EnQyusRfOzV2CGQeQmQeajJPEyU1X7hGoIahCGFTKAXO/juedIjWSvMIIGVfW65wcLSNDyab9H86 enYTOoQhKgRH3p+bM2Z802zwa1//hea6+v+DI509DurjTfff3O+0m5s1X/in+m/SvcrUYCP/71e9 3/5hwhvH8wv0tb/S/xbM2XCfW1oez3ut3QIFZHl5/ofV/16lnCljphpZ9HUIThghhbpdYiMfycMP pXqM/4djYqyOlSVKLVtKSHOOF8/2r9tToFvh2EGFEc1Zj2cGNigaEa/BnUhFRSCq4OIyQ8REZj2s XH2mphqHk2/lTiIiIiIiJZ1VcVOxvK5KhldLgUlUXzoEJdFXnTP51EITJYjCMhYIQ4qrOx+VyUQK t0apBnVWqqThgJ2duy+S+VeQcvDOmQkb7qCJPC84Smn6o1ddc6MJnXU6fM5ScGyh+f7uHRshJ53v n0lO/dteaDWkd+gRH+k990hhi/08Ms4J0hCLuP8MjoJ0tv2gRHTZzGrXbrbqeP+5/ngP+rngGp9d LS+Irp/DEIY0m69L//7jEGyKW3pbhvTvDW/mcF6Wr1////9V/fuL/s5QRHIxv6Qx4IUaBhGB6vW/ //54KGFXcj5Haod6vWOgw+8JOfTSpXtq/T6UVk4OUBhRTCBREe6R0wQV9cGNiOGCBK6gzVmPs5w0 o1jVwrtOfUQkZzjlOCI/P+1iFHm+IdhRGLTiMbFMUxTCwZwhwguFiI/sVBLEXFGc48Rw0GEGEIa9 a8dhVN200IeecRERGbk0IiNVxERE7UbQiLvK6rmQ8dSKvIREHEsRhFSVlZQndMRqfR2phEzUETIY QhME1JYOGVNKS+VeQmQeVCCDIHmvMIjMwumqNbU6iZqEVsFhktEOjCZrENQlmpEfCpkGIE7Cd3ef 9PNiVGys465McER8pzTq0l0I57quuWctzC3qPdNzud7ujDnik3oELgw0b1SPFGHO9GHO61WzGjdn fzvtO7fq467dN1+t0LIxOP9d1tmmYCIw54/0K9ruF6G+t/j/702E3/9/0+vp/revnfdbPb1v/99e fQRO1n1//+0jZ9u1//9d83zssBe1OoT8hhbb21UiYYOhZGtAwnFf/2O9t8R2e29K9KvvqxSXGk91 EV1aEU4Xvtuu31ycMer//Gmci1MkTOYG0i5giPwtF4UPa3Y2o2vip0ViKYir1iIiIiwgYUIXppoT iERaFoWhaEZkQ1T9REREREREREGELEVJuq5RmmUIheZJ8imdguNSusRfOwQiDZjJHHGRhKRVkmZK JSHSJUfZed5kdDX+7ryGwkmmgwqDkHRIpkowpB6FwtzoOGE6DP8n7k/ZB4VJGQVqaA6BUZ3P7kKM hNI69k5lynH53uv23hh0GG/PAhOqTwRPAiUaf4aoER5Bb9i5Z1Jf3VJzrAoMMQYYk/7X0/hAiPiu b6NlP4IjyN1JivhI0cs5T3X47WMNhh+tWRwneY6QLrxCBYvQ7X1Vk/33/6Vazevm+PqI1/32+qOL /dfv6znvlCRuhBHECUR/zjncocp7fJD4f3k+wft+v679PjreGFisIJQgR64jxEfWc+CI5GOI8+eq ZzvwQ+ko/sa7FIJwkCKeEuc/8nB+6Df9ikThiI0o1nH6wwmSUBUMRcUvMegYpoGOGOdGM1j8GYQg qk+WdCBCo4jMOYc4+YdvTW3MOVO2IOIyMcoIFOjOi7X/UaEQ1RRiIiyh00Lzjp55FqEQZ2n4iIiI iItCPK6Xi8rqnY7+53NFsFPfCZbA2J/WqujdghVUOh4MzZUndz3GOubsrpcTIQRlclEThUaDu8/U rbLYKeo07//72rfs5NqpbAmgRT8bFZbCtkcLVhNcjH2f0IjP+I/+PK4XlGdzx65bCS78hGm/8g7S M4opQLz/+oSzobOiIIF11QL999ppoEVgOIiKYMHcLQrIrTxnaZxLSWVH///////////////////I DoGo////5AdA1H///yA6BqP////5AdGlHkB0aUf/+QHRpR/////5AdA1HwAQAZ/QiM/4j/48rheU Z3PHCmVuZHN0cmVhbSAKZW5kb2JqCjU1IDAgb2JqCjMwMjQwCmVuZG9iago1NCAwIG9iago8PCAv TGVuZ3RoIDU2IDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAgY20gIDEgZyAv T2JqNTMgRG8gUQplbmRzdHJlYW0KCmVuZG9iago1NiAwIG9iago0MwplbmRvYmoKNTcgMCBvYmoK PDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0Nyb3BCb3ggWzAgMCA1OTUg ODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jlc291cmNlcyA8PAovUHJvY1NldCBbL1BE RiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmplY3QgPDwKL09iajU4IDU4IDAgUiAgID4+ Cj4+Ci9Db250ZW50cyBbIDU5IDAgUiAgXQo+PgplbmRvYmoKNTggMCBvYmoKPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmo1OCAvV2lkdGggMjQ4MCAvSGVpZ2h0IDM1 MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9CaXRzUGVyQ29tcG9u ZW50IDEgL0xlbmd0aCA2MCAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29kZVBhcm1z IDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCvyA6TXsoQMgOpF7KGDkB0wo5AdM KP////kB0aXj///87WFE/x/////IDphRyA6Y9R/////5VOOVVR///////////Kmi0J1sS0aItBCi I////////5AdAlH8tzP5ayhauI////////////kB0aUf///kB0wo/////////IDoGo///IDoGo// ///+QHQNR///K5WiAqqKVxUKWv+NOQRqgiNTdJtmgzvWk7ZkNI+t9N5kkAgtIsV1/xwZgv0bTYhW rvwwmKHeLQjDCjlcKyyzyz3+y0GQvwpkVRH/SLHKeZDYYlcSBcsiUGIQj/5eHfZ0Z0bDDf3/nttR /2xhju46hy0lNRFqbocY1jEZbevK4qFLKeLPaumWVxFgzJX0ade7pBtEn5GOvzvcmxrna1lQ8MH/ +0HeZAUXCsiyfde3YcH3hbwwlb93tT/CJ3mOrFeoNhsR86Dd+GE8UINfC7uItC/C2qiL1iJaQKoi IyzRnK4tmeWQHkJEHGgLk3JVCDUsgfdGoJRNwhkIEMgSOuYZkX6b36zPgwmZCu6ad57f+jdqfvN7 /uqt+5oGMR7FBB+4U8ft766uW4kX7/mXBgtIKXbwUwgsyLn15bgQOdlhd66+NtjQivtN1CI7Dh3Q KCKHV1zH4b12h2lMRphmyiNjSfu4MydVsU07OoFQqT7i00LzemhEQwQM40m6iIiIYIcRGIyzCTln NMjWCBlRluUZ2kZjK40ipZahWqn86iWdVZbjcmtkKjIoQU1I3KPVUa6fptPmQmFCaZqCX0Rj6b3q d9f0gRHl3zunV/S7W6n/08/9/9bXq9OdCIYL/S+OP270167UEDxb/6+rqCFN6T0EHMdd12WoprN2 2+0qjW1RZw3syFMjoLGtmGPd4pigZm5WlYqg96EU6UcaF2nF2hFpqEwtYiDCEREZxtM/4iIjK4Wi yAqlcrwTLIDyGdkHlufKwjsCI6GV/ZB0IUWStrVnRoMoMuSIOLGdppkYIEGEGVEdkkX6YIVT69sN U0a3PEINEx4RbtwvRuRNld9tTu4U8OXBntTvp1bm7Cbp9ctIFWhudyo1rvSTwnddtbrMSQNnY3JN pNrO+x3rbf1/+30vT/1adPTmmYCrvc+v+/S//vrv/99fT6/abT/0x9r/3rrEd133vP3+hj+wYXCT FBbV2Om0thhWnp1FXb0vxsU16TDCQ0tpTDlDlDlPYobWGlrGpaQKs80LQYQ4MLYodjaERFhMUxTT sUMREREWEIYQi0Gh2oiIiMs5nmSpluZRXQpXCoIMgeddAzIRkrzCOweUIEDCkYUri4UmwZ3an1mQ YidyT0ztTGd3rZke8GjQ60ztb1XjRvZIM4wQYTSKikHaRlP+dwdObX+i3KejvuWOWPS03kh2mlt/ wYP0zTMGredgvwhH3hNA9No0PRqOeBCqazw4t4N+6aG+vr44/TdU6tHWum/4P6+h5df/77b99ev1 xiMZ/qxHZ7fU7ELOL9u+nze2R4jj95XFwv/N3j+oi44bHDVfiP/UOc/v0Y/iOtt2KYjRnJPbXzGx dCI0L/P1qRjnHzUu4aTx4oS0ipRERfoOGFOiIi0GUOfcHOn2hlcUQiIiIiIiIiDBUxLSVVzJUZfM hIUyBoiIvlBmyOwjMjCJTnZKihDbI410GZBwTX9O9NMrguf6ENAiP2jOZ6prwifRoep6jO1rKWNV OyRFzzDnHdbpO3U7tAiP3XVmP/tbUIVxPy/Td0vW+YNf1ep7Pnd1Xv/79Ov9Or5lzI4VuxxOy0Ik NwRHU454lpAq+/2v//tb/WiMdcYMUKT43X1tK70n1/iH1P+M7BF5S2R1Wm3Go0mPY++ojQx9Gc4+ GmYpj0LJYC7b8rlY2KaqgrEfLcpyh/4txG9v/6DQiO1NSwhEHHr/nCzkeOIiGCacRcRnRdoREWi0 gRRERERFgmVWWYEzICxGTcDzITHDIgyMZslMhCJSjsryfIqivyk3B9hM7JIw4aa52EappnZgMSDh Gdk0djSTOmdrR10YcNQsNGjCJ9UjIj5B9181BDsuFOwYMKfSZaSqu5CJIM8WoIjxTumzarQIjj3b mcmPm+qdPaNEb4TptvpwwZhfeYNaDXc1mdtQQekEjfRqNng1/qza///sf/v19O49uEsacabb906r 66+C+uwtaOLpfXEIJ+0nv/LSBFBCmrSt0tE7waH++oIoeX1f90EeX1eh/Q6Fj41IY3jiPCaxEf7q CSdnK11WI4M0ilU6wuYc45Y/QjhWtWkhmgLsMFb5v2WkCK4iNQuhFqaChzvwZ1IULFexCYp+akdC 1iNCLs5+01MOeCh86IYVVtNRERERERaEQ0IiGEIiMtcSQiJavqTcayuMztOioRF42RXWMlbTGTdW gpozICs+lNYoXK6olQYSJQzEV+zWZagKoQqD9MmlYTo0yuChUYdgpOjqvOwkfzswIEGNZxwdb7yx yh8L0g4RN6DCdNhNQs0TsFzpZ3O/BgzJCu99BCGswfP+mwV2DNjp025spBv67eDDO1iKAw/9D/6u ETiIYhLz26Sar//g8PQ1/YWLf1gwX7ed/UK8ZaRWv+MGzn4JkcbZ9fq/eL+3oO3uhv+/c/YonkRj u0wRQ8rhaW1jMK129g3P/Q+OzKfertRHERhCtKeKbaUNjeO1i1i001gzpyxyhyh/CYrBjim2ztGr DCRahYoYQiIjUIROc6M6mhDQadxluU9ihiIiIiIbERhC0GFaERk3BsxHQZ2s5hHdmVOITJDLcEh+ E07TIqGCngqZB5uJGUZ2oggyVZknzIsypZaiotNoER2ujQ1CGjO4afyDyo1Pan1DI+R2QciK1TWn RrugRH7SbZ4LetN0n7c1vvTiIZDCMHXq26+nGEHn/uYqnj81nhpO++wRHkpWMtQsX93Xf1tR/X46 byVdXfbz5bRhzPHG/r1/7v9V+u6D9um1V3prNZ7W0u9f19dv5nK7+w/Q0P/TbfaTHv1avUGR0R6I uKWhf+HaSr62+DB2Ka4jbSsLEda3trg7fNzm77/3DQi0xTFIsfOeGuuKEYr/bCi9qdMFLUK1EMJp po/iIhoRDQYQtNOxWxoQSUREREMEIiLCFhMtqwJkrxGEWoqqTcazoZ2aIpeRSIRKS1CNQQZ2sYIE mpBhgp0pTxfILHaXmSNQQZ2NIxkIivyugRHghHl8/4QsLZFzTO1UIE0kwT7IOOybL53AvRrtrXzw W9V2k0k0EjW11OoRdMicdOTdOlq25/X4wg6N6ne9Txn7PAqnnfbpLrDBYTLhd3USXr9bx//UVaX9 1RnO+d9o3pkV1f1+2MvrT6+v5Cxeu18zBf7XehBiCvP9utz6g4jtXf39wQfm96Mf/719gwUfjuDB NsHfhl0R71ils5hEuBv+u+s5F/v3PoS1AVdWqQwdn/aURsaWsXBA6EcOu+rX99YYXi4jIx4+xSxT WojxGxHX2sRSGMWf401N8NCwpuUx60LuxTVxEREREREZkQYIRaDCnmpZk9pxERGTcDjIhnYsiVBC DhEyHyhSb1guQeEGpUJTQFzXF8ozsKRbpRxZ2JI7z1czs7JhDUJNUgupfP6ZKIuyusQQedmEmCBn WLVIWeDX0g6hKmZ/dfqnzRkoOPBDTz0MaDdJWjdkh+f4U/Ud7/9Tu9JsNjrNf/mgY3oUZ07GK3/+ dl1VL1TtujfSf/9d12u/9+Ey4TpyuUgv5rhoabbctWF+Y9ve03msF/7Eev9fd+2o7V71s5b9C6+r jP+NKdHwk59WqHbSvhpIb65mrSvoM3bt17tQgR7tPpbFU0xXxUbFMRu9dfsMJAkqG2s3bQi1NyF9 2EONDjsVHsVTxERFGsoeIiIiGFzzTCGrQiM1IiIybjWVzGJkCYjJuTSmVeS8RUQKQiJZF8hIhM1D syUZVUdqUb4IZlTs6SaGahAuagipwZBIuzsvBAyViHY3XZ2tx3PNbL9V9ZY6CXavNbYaF6LHr7Z2 FhTscKuTnn/vU8NhM+NEY9AiPujd0nOwI2dzveEG0bNQvVbg+Pr4pPMOnr8ShHNaw2kt66TWrzZm 5Tvedwffr+6//CEa2yKJ6e38TsRFwv09D/gyK1DKzyVW//2/33pf391p8W9L8G8MJghUUt1bf/Zy nI+CJ3vWHFZ/DU/ddu/wfHWra+t6x+2p2oG7Gkxxit3rZzfXEtQrXBmUKop42IpdYqF1hhL7FHak FKWGI0sc/8aaFpqbou1Cw1jM5Q9rapNjhxERBghEREMJrEWhERGfeHQmFxERERERk3WUWg/JuMRR pnZLkJkqytI65G0U8XztURJEYVmRdkvHalnYhGtU86hDsLkGdWg8/p5/KfCa6Z9AncMkkEGEHndD TQMly1rHS/6ghS3prw+WO0Z3ITY9uDCB/RvU7nh1PDvrdUCI+/zvudw9BB0g8HCeYcinIx3jx//f Inm1bejOd9e9L+GH1dXMO6sQeaful6/fEd9Ja+31uIcicXCq+5EVE9uCSQbz8VHv39DpD9t/Q/16 f+99UXovi8M3MUsUvOj23/rep2owSpG/r8H/t37zQF9LWfvaN/+9ZnOPfqIQ6d1a390GSO117W17 ++8bEVQtxHBeCKcMK2kDiFbCnT2KiM6I4tPj1i00+1CawhHGJ2oHBhKKYRagIoiIiIiLCBhCIYVC NhhNMVIxAIYiIzkIRBgpmqBk3UkbxERhOztbyny+diaKjJRkbztXkLR2JMyB3ztUEBchUdIuafn8 1iqmmEGQkVwgyM8JwvZKAiqahPwues9IztM6eq+5+o73Sandr+iT/+m0bK6Nby1FJVdR/nc7/dGc 7++f77/mOrd6bx/r/tpL9ZPFwr+N1dL6v6v33f/+vtv49vh+//nQX/a2cvX7jX9qf6tnsIaG5H1V 8EUPUED/thKO+vp6/H0Zyoocw+YdxEeqEYRHgeuWopLFbEdsdK9r+L+es9IjHKHBEfYaTCmIbaWM MJG601juxQ78w5311s58UGYYhY+IiIhhCLQiNC4iIiLTi08RERFhDJukRXE0MIGasydHXUhEdWYy rzu2ZaIyAkdl8nin4TU/pqfyJhg6hOzqFIXhBnYnIMjouiOjsGijJRpxggyEzJLMgSzW9TtSCOqX v6LedmBIiINPX0zrBNMl5BlqFipO+lvNB8o2YVzQtBNhJv9WT6jZ1Ro6Y67edzvbxW0ml6DfTzjm HzWZ2+2obem6nd1ZtaM/7art603jvuajIcXC9q09O6GxK2BAx/3Mitq6dVlqFi+hX6H++OCB/9W2 l+Gg//nYHb7/Y7VX/unP+tgiKODqf/V/fs56r/8H+v1b5uf6N11jtI1BEToxXtX9/8iYLhBHFfFd 8R6+Kf434YSVjCUEGnVtL1taXwQSbYSwrYaWKW0Li1Tscscw9phCIux8bFD86Kl9Y2s7FIWYcrCh 7rBghDQiGEwhaGVsMIWEwhERiMMIWhhCLQvEyPiIiIiMzwaERHlfJooQybgeVCsqDKxmsyIZT5RH 8/yE2ZlAp0ycm4Psp0CBJwaZCxQmg4wmnIYCH2XJ4wQMyIztayBIyFMnyUsxdwQioOeGFRcNGd7T z/9u89HYwlP50kDgyOL/1nsGrm9Exyh9OkHZoNGm9LYTaNleG66xe3+dyoiGHWsELpXVpPpOJcek 6Vv9vU7uZzOoT/XsG/fHdXptr0CNUYCfvbi/7wnB1/9uv//+Puq/W2t/52TY49wQ38EFEdnt1ddd SfYN5/63oUdiCQ/zsGH3rX52W4QWw1urq9tLPkP3TpLD9LCDKUs4r4M4THEFNSh2FbCtpQwtr7YW 1m50jdjVE6BxF2F4tQmmtioqNiop9imK3ZSS7rCDSsVoMKCEZ5wwgwgwgwpEArTQ0I40Is1lDlPD URoRERGeTlMo6EWhk3LMo3MlrERHGJk5KTYIuV4yDrNcXwUgkZB52VwIGdhZlXF8yS4jasv5kliZ BwWwpKGmp7O0giaa52rjFIzDsN1+CI+4IlHvtUbM8NbUJyFUYYdIw53Tk+6V4UYSM99G7Vq5tIER 93giPMq3wYY1tmbLhf6sIu/V3VDvXdfVOP//9L//3///zvJfBEwzPggja+2kblF/UNfpDv/X+HX/ 0Cv8e/fncZjj1bOfxH/DbSw3z/gktt181LEVhjaWbnF2Eu9JhxqGDH8bxtdfh2lrSY5qWIwapI7V wX+LQjuGEIOIaFqf7QtNCGuJknOiIiIcRFwYIQYQjBPES3J/iMEMtBrH/VMi6GTcHGGnZCog8lPG a2R8qM7V5UyCSBmVWZKsa2Ri6tZKNyHXn+SHpXqfSYWDzu8pMwyZBhBr0CL9N//uf1f00a2CBEfZ CypPSIoN2oRbvP+qzKuV/3vDD0CLr3dJwk5BD/02eC30G//a19++DDGryfMBL/BE4iErdhVPGoQe nv/X/Vd7euquvcLCBHYnPivitrv9ftVUJqhpdfM53oV0Y4e8NDKV19P8MLitroENClCCOe+NDq/x mEDBw1RFLtLvfQ7hRYYVhUz/BBKxH83OwujPVNubuxq62vHYoGcGYL6HX/EbgxkoCHYrP1raVpT/ iGFuPhhDi60DojlonEMKmKYr4iIzDlQU8RGaZTxDsEIiLQaHLULFLKqZCbQiGhEeEIiMm4xntVES U4idrf7BSHJEtiTzVHelZ2KEW5ZpkHlehdsKE0iLNBmthclOdUSPhpmXkZAxGHDI5kdEyFIhl87p WQdhOETjBEcemEK4YT3g0a3DJXEhrDiIYQa524Qg46b/BRSYVT39gwS+eA6beGEkW5Q81tkQdonb W1f65ESLj1XozlRwxC7EG92UpioQtBg0bLwQPO90b5Pr5ahYvw0unNpe6VvBgutcWCUWRTrdW1+h V+xusOD/t0u78fOmF8y5i67fX/b/W9uYcZjtV+t/O3DGEE6wdnkEXfW7V/ePXDCQPQY4jjV/6iFa SxZDG91TaXpWcsnDEMUOD7QXjwZggTGwWgttRY71jRnKcocp7UMIQ86I0LVPCaGdzvYXFMJiKVxE XBnauCHERERoMLF6cNHeJqf1/JuMdCIiIiIiIiNMSD8EVAh2tRDOzs1ZiJSZeKllPl87LxS8t/RJ ndM7C2EG/9NqE7owjNErEK5JKfSZ2TztPkri/UuaNB3a3CbpuslIRX7TUrgoTtFu1PR24i38xpW2 wp7709OqM/10bKXoJ/CSv2undV11+53PGu9p0hnc776bfRGPQIv92u/quv//1fvIi19/7eZ09d9N db/vf6/32I4P9uPu1pb16EbFba+trf/6VQ2zyf16ivfartcUFbStJsL3t6gzc3i/0Z9qnbf/nRaa dWKYpirY4inyrl7Vz02lN1/bTUtQrURERoNBphDTVYzddit4r+OIoYgyl5hCLTQuNBoWhaDCk3Gs RMIRERERqV1bO0vUs4GpNy8pCIyWTshMl0SeQmqmQhFuhGEakdiSOzMSmkmup0gg9SQYSIZpHYK0 zJPnaRl8KqZ3VpnZZrQIjjdggf0900kwlIoHMvO1wt0fzscSQfaii2rFNa71O/54EKeBC9PW1fUK 2sKrR0BfLnk6NhPcnRtEdEdBSjI6L6q0tDz2HzveePbzdmszubuZq9HFu1hNV9BoRGEIj6dzI7Lh Dsbknf/T36GndIY/qzn77q/19ZvWjedgj04ff//DXX9667/jN+Pan/ORv/5FrU3Ydt//Wh33ujDh YjvQj1pR/4jYjx3bbY/W3Xz29dnKh7/7r+usER1Sg9h40mIpG/Ha8eZqzniLOeLjCHF5j5jxEcQ7 sU7/FCsjHlqFiiNCIiLTtOItA0wh5/vN2MYkyxERERERERmjLKqZ3ZkrEJ8jUTdbMp+geTdZzssB cpZtmtG4LhBlPGRrEvnapELRHwg8kzO8MiGI1qg4Q5k8vn9PO1sQ6QTz2CEGETHKHcMJpoM7Fc19 5oNFBOtL6Nj177CDhCG4OaGi3aM71qKTeYfP/P/9ejZpGf806TzuGk6CbSD7yblYL05ETrqMf6vp D1t0S+gn7oG0rp6bVf8Pa/f/d1/09unFt39c77KGXC9nR+GrW8ycRv+/xw7XwvmF/w/+t7bp8M3U HtVs9xWsN/Uh4QVpL78G0jd7bthIk6I48/hn/aXHrN0OwZcccQnXtbWx3/sYqsfserS1YPFcJDCt pWkD68RYTOez/UcMJ2fo09CDBTowUbGxQtO8RERZ7KHiI0IiIiPMOVBQ9hBoarQiJEsaETiERGTc azIYjvDE7PqIybqxToj+dqqI6BSeIUedUejUy+VGdODKRHY0RrCHRH47MRfJVHa0R2qo7SuFBO0I 0RStB0Nb1P8Ga2gwmknrmhaZ2J4XMrWSHoPC7CdLfdZ4B6aLjODqF4ejR89SD7WHR554vP9pTD5u o7/txep3wm+1nffpN/tvxUMPxF/e/zSMBPBBUre8M3OgRHS+PT753Pnw8ff/1i/+rfC6VeMMQhrf 7O08YCXpq3nZWGLntw32axVf/+YcocER9Dv9+n/Mz+lVv67XDXjs57rr6jQjqDBx1rOnIY2relB/ vP1Cv+ZzOU+hww8bURkMPGl83zp7rdab6/ajum1a7iPmHtvisJj9+KpWOzkzosRs4FYaXzdFtJq/ Rmhan+zns6sIceSSJqMRYQ7FV1xi7xERERERGCEMLDCFocWmENS0QjtPiM/xEREdnZxCFIRlcXFM lLMk+gyVoKQedTshM1jOzLJRnZXlOM6Z2txiKhHZiO7FJIoQeZIEYaZPzDgjX3VnTtM6su1ITW31 ynaZ3+g0yrlonj1Kd+kK9avNb086hM9ZB6nrbCGTTsJo3BmoIdQh2t2CDeiQ6Yb7n077+k9Tu3S+ t+nRMf81tJ13q5kNMuEneGwwy6ji/q36ulzsQjaWdzvbc7CIusn+3Oxp1wQPuk9PP9G7/1/i//// pwmhrtvghHe//j29+o0J2Chj7U//wRN1M5Q5Q5Q+ZwWvWvXr7+hXm0sf/0v3621H/zoMPQiL0JDD F5OGL76DU/ftUZGI17716Me73LHMOU+xX98K18/02FptWNRX+pufejdDTrDMRSgw68cM3WbmhEPY X7HC34wZlYoGZQKpf7X350fGKjahr8cd8RcWqoRV2E4aFxxY2sa9pw0ix4M4QRzOcc7134iIzOVG hERFhCI+IsE0f9aEWpvz/EbQuIiIiIzIiIiIybkuKnYHk3MYjK6kjJbdmSeOzUIQaIyMIqOSTngr YoVqdWS2pkyZ9q5liO1nr5kQIgjVAmmmahMJprn9M7FJMKX8mEYioiaGmEDKvO1Q/CbCowSmrqQm rnaiv0XD54a3IJq0/bTzsKD/ebr1O9GH6Nnnf7/Cb1c2kCI+91bwtGvrK4oGF6GQunentISe0u37 96ruvmppHitPTfNN1r9f93/399c7EBj/+r/NIuF7VydGyVJvLc45V77kaf/r5jBFD/VdD///3/// CaHT2hHdbOc4QV9VZ7iI/oEPdZ0Yhr/f/z9695h9rvhhIywF8zWrarHt60i83S3HeorFKO9q6jR/ bq+xXDCtLEVzHxGyhzDnHBNO2Ffmcpyh7EUdgROvtra+wZHHcQ1MihjTU//DCFxGuKGmhEGmthbq xCYr2IUREXEGELtbWIhhOIsKhYQu00OGFJuWuf4iIiIiIiIiI1MlCESHE2MuVyvMgSL0IEDO4KGQ hEYMledipmvIOOyxKQdVN6VBt2mp9BPLojxHUj2Bkh2UNInBc7Ws7Esg47E8hPr5g57aLjDRoaLj rNDiIg5C7VikwlWdkxDUIp087C2erc7+8xq3TZTmk3TfaWyIO2Vb53FTQaOoX8J9JLums7WOnpwY ZhU9O9JOjZDjU/1YQpN6N2bL/M7/+9afkEl4v+79urwQLvapzssi4WnSE7Lo4l7Sbe/6esHqYSDf C+YXUbqYW94vWb//HO9WEwh/TfW+ojbbpNh+dEi7Ta369L+DD//5+28PXq2/bGuHtcN2FiE9pLaz QU+17XYZ2rCxYW1Hdz3ZyhjN8nDDt/YqY87MkhFA0xUK4jYqhuL20hM4FSjbS9DjD/UNjtMIRGxa hUrT1HFRL2YBTOVFiq9TshOp094jOiGE7zHsIRn4oeGoKcYhP7Q8/5uiL4d5N1nERERaFxOIWEIi I0IiIiNRRJMpZXC8yLM6ymSfInn41sxEzZ7NeS7QMyPn4yEZIEJNbMhRpppGWmuEH5QZgyGzbW1P IJouGVGg8qWdiAwmauzueQiOxRFR600IQIaosd03p4QbTdXNDQQOaxDSIdTZKhEkb3qTQKmdmsXM 6pM6BfU7tGhJPCD07U8Op4099Wla2FpwlM5MfT2vqqfyuKouiOJS/R2ZU7nh//SvW2u+uYqdGHO9 iFTcw53jCD96z8nand7z9hCPp9o2k/79dKtd679/63BhfXdNq7cEXW2TowjCVd/33613/t3v/6/x v1/5r/Xf6wxQ1hOI6/38yFHV+19tthK+/eltVQtbX8dJ/++h/0t8b+0sRjd0xG2FbVY0m+bsbaX3 a/6xmgLqKN9jycMft13Y2FFRQVwtglWzD7Xum177S8mgXXSo6hY0LUx40IYQa2FhivooQYp2Nitj YqamZGvaUGYIoiIsIRYIjoWEwhcRYQtMIWnacRmA47zNWxERERERERERoYyuVkZBWZcZyOsQpFJl 0dgZluW5kKI7sqZkLBa6P4RCJ9oMyESmuL52JS0dluSsqNb6b8JraLdmSPMkBAudkwmf4R2KylOj EnS5s096L9oER94T7rtr/qCGjQ+9P2/CD16t9z/R383b8uZjtUkg+sdav7/p/x/oX/353O+veY2/ Q+v/61/tcMLDEqv32drFf1f7/7SCrb/of7Xv8HsJZkNBbCU/2DBb1dQh2XRHvWzlxGdiAx93UOhH TDC+xTEVDVoy4F40o5/9v06v55VihwwTTFAzy0sUvzUzU8cUdmnmREMIRYTC5kQ0z9HaaoNO7QxE RERERERERFhBhRGVynLczMg87rRUZrRK8q44Z2BETYfqfScggoRCbNeCpkvmJU+yEyER2t5CR2JI oZeU1DOxTOzXI2jr9OeHDCDwh6oNy+f0gdlPNQiZ2pdnUIdpGmEI0ztRKqeZo7Sv+5xMtzPm/r6M P/YWLq6uoQ5MdTQ9c9Pqt6K9rtUE7oIN8/3qnX8w87BrRhzvU7G5+f6TBT40g9r/e+7TWum780Bf Ffv9fXrc0Be+8Z3O8Unrff3/FQff///7EjH7X//9a7ffhiVu3mgL3nYIC9WHEf98yNnt/qN/j+5j 9V3/r2orj83N+1dhgtcMFWKwZY/BFD//d2gQ4Zu/vvOxgYTnIhWdH4PLnbSFitY/CtH6IjmwqPdX jCKAX/dcLcw53Xy3KffqhEWKDCF5hzj3H6ToXdjfO1L+OKYqZyu4t6tC/xFhC9CHxF2c68WhHmRF ppqhDVOL+/EREREREREREGCERERERjK5XmRZmQIZ36IRHYHnDO1EQgp2qimRoup7KhIMheCl9Mvk pzcE9MJnUYQZUZqjtZGmdkIjM7IZSZrVPyngqNEipKthbhoNIG0CI7RfMIHN305HvGR7PoIM1BU/ 5oC9N26BEfdXpGHwqSeE6JQ0m/mjBpapot39p/SdGh9fPHqncw+nN+2jH0/pBsiDQIj7/QdGtfvD Nh3903a96/3/+vX5pGAnWFpvberw37jYf/t0/X/6tX/X2t2v2ET3Fd13ad9K3jdbf/v/T/et/vVT uVH6f9DXH6zdDG6w2O9bVYr1qI42GlGOL94MmaWtdbXdYeGk22xFMRWFiL+O/2171kUe3nUku44d inaaaDC1nRmnDCmHKcocof/FHUIxFTdsJBCu0IhoXaaEWdCEWgcGU4KhEQ0PtQTu7FQuIiIiIiIi IiM20AhoMJlNUaLSWMRERk3VkZAiJXmtneqJYjxqZCmVyTLevlcLkyo09Mk4vkvApfIPCDztWlJV wyXztLLJMzt4hM5/RreZU+8LZ0aDWzowg6DhBpXItZBNhThhORjA7Kjg/T+/Og+l/QIj7xwm00Fz uDuaJOyRQc0OD2++tr/88ep3dfM53qYdI0CsQ81mdpNsGCzuGk2yrDhPnZK5XFAxTmgYOyW77I7X Tukn+67f6rBBbvTsQtusa/DDra8H1xH1X/+k61e1oKrzsm+wYIQbVwQJc0BdkVpJTOi/OewwTLlX /6716715vp9+H0K/X61u0rfj50b1jrVY6f71sGT0rcO87UYJPhg35kQicftpPnaVSQ5xwr9jSaVj ppYjiPO1hd1Qd1iFahh2vnamN7XFdCDQj2R1TG0sbS38UxidjfFQTYSOzWBJiq4VxaDQjtRYsIWE GEIanPmP5IuhahRUQmn4XERFxEREREZ0gIGFQak1YIXqoiIiLCERGTdPGQGiMZ2kyJIg0SaLevGV wuokJMJwZEaZDaalCJCOyXL5UZ2DzeFIVna1nal/LymVN0aGS3L8iVNLbNQRNM7GDC2dQgQiiVCH amIdiWiPYZ1Bwh9qZmn7/+k2RMF54D1rSftX9V4M7Hr+j/Xr7p8e1p0bvWgRfwi+zwfqN1Gzsqw/ /5XFAxv/8vDDwgm4LuhQxruhHtITsadB8ff79xH14badBBiv30vV38TsYy4QET3HNAXJww/RkJwR Q7I6W1LzD6b+m53KHLediC+n/+l69Ya+wZuoRG9YYsQYMnDFrZzURuHv2ctbPb2e+f7DCZhBZyMy KH+thR7kr1TYpD/bTWNtKMTQMD4MNCKX/tY4M4QYNRCmITW9DEUrFa+Q4LTr8/4tDyMeMmpBT/F2 puvP2Y/4hAzJ07X8RnIUEIiIiIYIRaEXkt4hEXGriIiLBCIlpBSlcsZkZmdpbTMhCOIl4yLUIwg7 CDhnfxMZqwmmEzIHggZ2KZC87Ls9mpFdKsztGdosfDyI7U9baDMgxEztIEIbLte0yXRnHfx2kZfK jCBnaX0g9PCDZTn7/WjXVFxWLero/hA8mnmmdNc1iIt52Si0rXN6tgwyC3/VOk2jdhNzYp3M/oPe n7wYTQIj9hKmwvf+uRCp/bf3vQ7pD1k+bSrvz237YMuLW8k9JtEh19/9SEX9X/S6/+FCHXerf4MQ S/O+653hv6hNekXH/VD6v//3/j2/oGC/Xf/7axHanQbi1moMdq9We3Vs5R4z/bVXfBFDzCUf///2 lJDlD21hY7U3NhhK1jtKOl+0p82xoRG+r/df2KZRFioXgzhFTFMVsauvsMLh4bsKNL9sL32hFhU7 4uGmputTdFodivacGfYoK2NinY4iIiIiIiGCEREMIREcNDTCGpZgliIiIjK5Uiu7PZ2lZ1R2aa1M gTMPvTKnEFi+EGFITMhGQiOxRGuL5UI7VTOxTOweRPNaqek09s7UglH4IGtoMLapnYGgmnZ000GV GTQ1kMHJ80zJ77zvha3RE/V0a4Ik+jIgI52rCJP6Lf03/R/O1ML+u95v/o+NAi60nBJ9fQIuvdBN 9PNyhN9pW9JX7oW/3pb20XESfNiEup3O8nR/VGHPGr/p+rqFT3TP239a1w1+++tJtMLBnY0/cJlw tfr/2aBjxBL39uEKv320P/er4aXw4f/9t9f/9IL4ePuNK1BFDs5fdXW6wRHIxjP+HD+xn/b/4Id1 OjeEEe/Q/N1pbSCEVP+NWLStLb/Dh/13+9UnW91CC7S11jhil/SY2KoGPxOxLtinXjYigZtrYYSf ikNsLP87UwsWhYTOiLi7TQg4uI4uLTux+1sV8KIiIiIhxDBCGEQaEMIRDU1LQ87TniIiLTRT4jJu NRTx2lZB52PkxlPiIjK5XGQsGCHIM7UjyQdlSUMIODJLnankbRUI7SkVGdqh/CE47q6tOGE5EKj/ Jx59WdNM7UtM6BUGa47nF8y1zI1vPBcZh0Hp6fnHDmtzDh3a96/6Ld4TsoM41O1sTjCen66boQw0 nEPW/++8zlDpBPzj3TfXrf+35EwcMMuqwluN//dC3T6vo0P0bv369V04v0C9vNAXfKUGfqnOwO/p bpveh+qv3T1NBboIuP3qaGh//jw/9623X71hNXW1cWyGN21JcwQqD5kScMT6QQ+G3/+3vZ9e1Yjh hJtL0u0jUl6n/9ekdQrdr3XbGtr2KRIcoexTFXsLNguhCBmGFbF/WDNu7QMwRHYrHwTYtWG9x3aY ITmGmhGF8kWofHxF5oBCE9it2uIiIiIzIwTiItcIZblOVEWELXP+IiRtCIiwhFxERGVxVGSoibDh BGmFMgkdk8rWEioR2lZDZUEdxlZzWZlq9GM9Z6MpuHIOKn/LHBEGgp2phQmnkKCoM7SMvmsVBnas Z2LxPmU/r/H9whBDqeGjW89aNFbCozsIGdmAil8/nZJha+/M53nc9mgzvfM0s19zfT/NaSbQIj7o kPSDnY4VExyna/hDu73VK2mgnf2GFRhzxoNr/dvQbp6+CD02VuQcEIef/5CJLara9ft38deah1/q 7qRFX3/Q/c3FDtJs77Ufwg53PHEcfpf+qC9sEGO7e6xwx+v/6oQ+6Df/+7rHta4IVOEvgiOwehH0 YgsO//bPdqXh7tWHsR/8Gbs3NpRva8zV3wQOdgwva83WycLa3qT6DBFD3r9tKHZ7dr/9U0rFCDMD BkdBXjhA9THxFPlXUwwkxFBCI46+MOeBcGf499pxcQ01URi0IzOCadaxmcouKeTHofhhD/bHERER mHhhCIjMhiNCGEwmCJHIg72iQiOpyI41ozQtNCIiM6EIiIiIybk2ZAud2hERK5ViJNkKVwvCDMjx TikcgQMiMvkZmEVGdWYztZRhFOioM7WDKdZB5G9ZXKe5h3npDIqZyTC2E7OgXs6xdgq2EGdwy+g1 M1DkcHnOxxlPHZRkJHQrrpB/ZnptzW1dfp9NbWaK2i36w4h0nnY0rOm4IHkeI93pvqFP1Gd6ToEX +d9z9Sup3aBAr6TaBEf4Qb+dwbc0GijY+9dEY7iIP6uRk3it0G+uu1339dyXdL6T1uS7Su/bnw8R pvfO9Urvc9Pf+H9e3969eN09evf//++INr6TdXkqBgJ/6huY7/rDQ/236+v++/frd//6kh603f/p 7/1/K4qGG6b7q3W+2tvXdJ0v3/X/9DO1GCC/6uuaCxzP19K1/VqDc/21YbG2rev0dAsNY1YV6rfe oabWYfFWve6+Iu4IZOGG1a4M0gUUPsU7xURTEdMU0kLEVsUxFDDCVH+CbSFsLaX400xQrw07tO00 GoU5NDtbTTFfCjiilhjFwZghy4R2NlaERERBghEREMIQwmEGEI0GEGEtC+DOOCqIiIi4jMiIiIjJ uDjIHmSEdnRXWcimInkMrlkX4M64IMiMvkqZMZ00GYiYyoUMl8/HaxndXqa0dikdqop2oyjheQiC Pa2wnZFQvIJQSIDrIYnCDOx4wyorOxwXyrYSTCDKjKdF2ESHDNTKrxkJmuL9bmdqjW1dEY77kY67 9Fj7U1BOpD6UtFjvBDQIOSApK4J5raq2Qnne4u0k877Rc3s0Gdo3r5/CeE3UER754NeGgQIQtBB9 abQd2yfQhp//BAhq0vhOURHRHRH1SdtwglJ851oL3pJ0Yc78abno0q6b5/06NTU723SRn/X6Onv/ 2EIiOm3EII6MjhUwQxCV+vdb++H2vzOLhcVvekrBgxRnO7rs0DH9hyW1qv//qgjy/wgn9+v9f/N/ 3f/Tf4b9/1vqDBp3TfTaUyN+Ekxn+M3Qgj1DhhLX9vf//6an/Z9PWv0l//Lcw5x++jIV1dtY1kn+ 6uEq/sJbEcUt69qK4Ifaj7YW1YaUeEja/uqaEXsRxCFimKYhNcUKF91xhhOuw/bCRTjj20vNAXbS jaUECTf2LW+1JSrTQMIdrGh8Q1tRWxVScHH8U/xhrVQXjin4wQiIgwmdCEZ0IRENC0wTBCDiGhGZ EMIGYcELUYtBoXiIiIiIiIiIMEIjMORjwwgYQyylYh2NI70yFw0LiMrqWV40yowgZV6k+p2toqEI 8yS2E0bnZFYwwmaxCJgvmEfwUoCnbxhmpXZ3OO/jsbjVF4g47GRVTLxFzI1nVnYv/tJ6CFzW19PC p2q6nY4R8LmoTLoz6bTwRC7SGd+EjO6b5nLdpOjdZ4PlewRHFGnqCI97pb24Wk1rRoeE7uVxVG8j y9PuaZgIlT1dCKv1hE3jQbpJ9vnc7/Rn83d+npzfzTwkZ8JoR+uqa13/Vv0gtf78zBdeylBg7EBi u6H37/NIwwWg31/+uv/6v4j9//XfdV/71//Q0v+M/4+1Gf99XtnO949daBCpkf5kZkeqs+mI7r15 hzD7/67QVtb20O1Q9IGbnO8xsGFivr/+u/bCv8RjQu2sffa2KaticdMVsVXgxsQnCyQ5Tha9r+rE aGGbrDC/xVLHFpoaDTCamy0/h2EwsGhF3dja32t3YqdHw06xE7JMREGCEQYQiIOIjiIsIRFphT/H DCERwZexdREXEREREREZNwcMrldZA8yT53PKhEszCKtEMzIuZlUZ2F52VH4PzscQKQbCppplOFO0 ZCaZ3bL5KjI8mdk9EMVG2dmoiqZ3GdpUX+zjv1OoQ1BFfRopncCGoQIuGulozvP7+g/KePy3xDB+ jdSSgi/1TaNNhVp0CI/aBAm6Qf0b+d6aLjqEHr8Nl84GDLjMXTzud2jDnil2Tq/MVB5hzvRhzvq6 3pbq79AvhN/M70CI+/j0I8fff1wmXC/r1vW6v+RF/u+0Es7HtXIpmAhLrSbev4Im+dynKj3/Sbe/ pfv//uq/D3r4aiEv/TVPpv7vmRUKHxEPOjnv73/oZvcR6/+30Yn+H/al5DQI98hR79cH7f9eF/3H d9+2kulsNf71bX9Ju63qsEvj8Z/w+2/a/C6+vYp44ivmpYq212HoRURknMRUaz/Q+YfDCXg+w2Nt V9Y48/xxaaG4TTCajaik2hdD/8n2Pwa3eIqIiIiIYJhAwhERFoQ1M5VlDlDwwgwphzjlDnHYjMe/ tDi7hw1ERMiEItCItCNCItC4i4MIREQwUswvk+RU0yB4iIiInYaGV1JGRTF8p8vna3msjs+QmU+Y SGdWY5D7CSrEKdHadGpEJG8mwzCcrlOmFwnZ2piJnbiGoRO/uYcGSMz4NBqdkQTCp51jsqyCxMiI TILBDOmRvO1Orrq6aNDVQtsn+no+QQawaL6p/CHnqro/nZMQi/p3ntJT+dNaP/ed7aM/RuSQchaR uovM78N6V4STbnsOE2+v0/pbz365gdd/vf9bdD4Tp4Q+7DfxBEtD26cMPe+f7vXev9mPvffu/0l/ rdfjpeDDHdAlbsQYa7+Nr23zueH2v78Mw2/f/3/13mP27/+3br7kh+wa/f/07/fG/7fK4qGH1brb ObrvZ7U9vqEjadQR8JkW8EnpDs9hDukP/X/Q4JD1j1GlFrHaWJoC5oGL6CBJ2lhg7Yyl4QKNGHgi nDBFD5h7a/5EwwhH6MDk4YWDNIFFRScRpLEYSpisuFYbcQlz+EIjz1FT/u+vn/n1N9qf92g1NyWa ZT5fHe0htRTtQUx7/Thr6YyL8x/7afgz7SvEREZkREWEIgwVjJjlbMBCIjOQhERcaxHfQ2vHk3G0 IiLOdMENCIiIiOIuMm4zTIeVw0Ii0TcL55oZXFK1sydGskzpG81RiNWVVGEJWEdlSOqxHl8/2EoM ljLmdvgmmRQF1tNtT6Cdpnc4iIj4TTKiOxKL5K4vhSEyFRCI1jJGRrL52KelW0FDjCFI1uva9Ncn iHehHR/wtp2TI0lJR6aeXz+E7+7g6CngOZzu9J54NmnSf0CI/cMF+r/0nTSffRsr2k//ihBut0Yc 8fGrq6t+t2IXzd/R3ugRf54EL96v6QIj378EeF69f+//dL50Ce023/5rVdq0akXRHyOl7M8xl5Vf +ns7EZjLpcR+biHhev2/Mf9XxdeGXKvjw1/skCa70EIiP00I+3/XTQjvb9hBRpd7r639JX4/of9A ge9eb//eoj6quDN2I4hNLb913TYVtZub6XkuwWYf/hEfB3WvzkQQoNTf9/xn/d+CdXjiNjYpiviP whVH/iKggdi1iPVIdbUGf96/+c6oXFpWmmmqDXwv3EWK/BmB9ivYiviIjQhhTIhhCIiGE01OqIMJ hM54u4tNPtDxEXERERERcXEMIRIhDLKVxGoTskhEjaEZNxiI1l8lkX9SC5T5hGpH9SVGZKEQmdmq K2ioR2oGVxHcrhciNQ7C8GCRKFYVNNQUhsu0GZa5HI1CoMjog2XzqENaI6BQgygZGs7EslkR+wpp EWRCZ2YOVyoJauvDBAiP3pv4RMfpo0UKCxIge1QjRePKgQrZKFvXLozwmahU61O/nfc8Bgk6vO/s KCTVTvptNEx4bQIj7zDpaDbOc+uHpPYQVJ51CBUaHnc7oUu13EGwicRfXuIIj4Ik8aW1c7W5G5QQ OjWZ3X0ekbta6N13QIj2G0F/ou6TddsyG17191/Sua4YX0/ZBIigZ06FRp3/3oVf6ESniPkdEdLT 2xC30Yc8YQ0/9EYPr+TRJX/uv/r0YUP9+9fH/Y9CIj12r+v/v3d9N6SYIKMwiKBj6OgpH49afuHN pabPdnv9/uzyfWzty980w5zYj+/Uwv1TesaxCnitN6y3HO8xx9r37V8GvX6nSI6CTaaHMe2c4c5H qvX97Pd0n2MMowIpioWDGDMEEVvhjaCxGQWrFDjhq8RSEaH+hve2qxGDN221jbXvi01Cd3ap8GmE 6iI6sYtQuZzjnf/ODSxFe/FcRxDCEWhBsQwmnEGxGXTPOz/YQYU4Q/2hEWSBn+Iu1NS1jzdWIuIj tOIiIiIiOIiQRCIiGheY+TdVyPCIidleIiIjK5TGTqMlDMRkNGRBmzMgVKZeiWMyTsyLbns7VIIP XMuMwaa5KYuyGzBmvMMho2ZLWFyKRB53aTOmYYQZUZ2CHZCZ2TGSsIdmsRrO1ef6Wqnc5hPpzOjN QgdU1TVQg0whyCK51EBDTTRY81iJOU6BVSz2dAtrfqd2UpUttTw8U2upx9Tx0CI8hPDW6Cq8ER6E G1hBwQ5oc+6f130un09K76lz626VuqeeLz/mwqHzDndT/qnV0Yc7pzD0km77nza2/p/9KuK39Lqt f2vHFzRlwlbeK/V1t687nh07ZHRdvWHhAhBEfx/siPv/V2v3//Xv/X///9Wv9eIq+sWhrGsbrfs5 /8aWquu41Z77am792eTpfX7v/b6R0SGN9F5dLhpMUq2hH90lFLawwrVDX9WnGla/ev/az7pztQKR /TtLOexWEutoKxrq3xifLvvj1bW26QjtutLm6dAstx2sX7DQatgxl8UPYW1hhdVpPux4atimo942 OGc6taeIiIiI2whERGEIi8/2hEWFP8RDCFhM54tNRjTNsSvDBEdCIiIiIiIiIYWMJp5XUsRLcnmQ zMhiGf4iPOyWLo7W47GZlNFPmEVNHds7sIZECHYJkCYURIXkUzstUrigLhbO1MJZdH87VRAmmSiT JAgQanc46owyRHGFRDGoztRlUyVJSjMI9Z2KOTaRpS2tJ2qvqEGix8+64TuGnNtVoJT6VDCEVZ5J +aD4536LxfSNmd92qL5oIN7ugRHqRndS+zbGqfXEnsGCB4q67kEUJ+rSaX34QPT5/6p4VPZ7aQWf T/PBsc0Gvb+rr0Hid9fWNbhiUH1tjKVFwv/2xnY10EEx27jTik856lz/38O4cRv6te+t6+q+mKWd 438k5bpvff3XrDbOUG9nv8igUj9r1Puwp+6/VI2xcGEEc0bYYaGsH/3btfVvSDoYcGbsbfSFtra4 rsUrf02EF0w17erX1rsMKxFDnaFVrEcw5xzjlD2KbSs9v6xhbPYdDz+3N3btW0hSiOxCam6L1M5U WqERDsJjj3appYzsWSxnaN/I1MMJRlOPtCIiLQiDBCIsLGhEWsZj8adxYphVMfERGf4jNlrmeIi0 GmUOE1UmwvG8rqGQoyoRXG0IiI9GaERERp2dzyVMvhBkVOwpCZUZB5KchDJJkhBSoROj7O0ZUIii M9REyP6yaWui3eDnUIdRDWJan8EDwQzUETCDOx+zWgQJNMIGCmqOxusqcX9N9rdPCdJUvVPr5nrh CPRh4V+QcW33II90Z7nfVN0YejdRuokPp3RqPZVnxhF4tJt3S0g2CI3rtq+vr/tX/ocZ3uThi+nI n4q8J/f53O93c7G4ImPHOw7nw8Sn53+/1r/9/1286itr3ZcLV4u/67d+mgn09W7T++uCBQaX+69b f+iTljwQND6/7vX/29f/6//tpBqI29Jrq9bObZy/ghcIlwa2oz/vbOTDiiZBh/uKaj3//6sULJjq NRhrEaFoU/vcEDc32DBfbSjYqv2KaRnl92u/fftBoWKYr/j9oNexC+KUMI7v2MMIcMajtpNDGFsr eWmpqZ/U3RaGhFrDCHam5DjQtA/xixUREREREREREQYQiIiDtOGEGFLKUITJHiIjJsFZ3NEoVnad lPEHHY6I2syLPMlnk2K9SKRtkY1TzuZpoGEGVea4vWiW6HUHrJDD71OcMqIq87SGhk+dofJsLhU0 Gh56kOZwcIsfZq9N4ZogmSGfyUdmoRNTvgsHnvV8JmqKyjFkwjd3mdp/cJ6DaNbW17tFxTT3VGt9 QdawRdSdlD8vn+Yd5fPQQuQ9YadG9QqdG9Pz0dGHpOk3vO+4IjtYTaM4b+jdp8gSmvPYd/if2GLr 9B6XSuk+KSXQ3REwI2/Wr/0txY96D/dCt6dOIMN9ykb4bf9bMe7o3Z+KHdTx/9yMd3vbvvu1/h19 h/9Ppi2G71yJgQhmuF/3/6HEN/ZEZCdz6v3PpCpsK/9V2uqa/oscoe/2/V376Ufe6xBgv9qvuvoN B4t1WSH+OK3a9dAhV6RQMe1w6ghue3XrJ8EEu0jaUaChzvCTG67Edn17rTDh1igqFzc6c6pKI21b XY1hO6TBsaSHaWJKAuCCn/j7Qi4QI9hlj4jdtdYrtvMOceGqmc46rEUPYpigZlAqEMe5F/YrSiC/ HTwltH9QZ+oYnkuFBsH0IONULi0wpj2mnapoNNc2fmGBe4wYx+zn76FNYNDEREREREREQYIRERBl bVAhEXURERqf7QiMsoxEbQjTs54iIybFaO6IwiWoKmQmS1mRGdhrERhMvhOwmX4YUhykTNMg8hMq MhxGRpJlRhBlIiEyEzuDEgRFXnbmW4xV112GS4muHu1z1HIgxoMjEFvJAQINPJARM7pHY3lSyVYU n62gRH9bBhhEo/BPW/7B0jRBD9BzRRremjQyKRDyjztR3YQ0RWraM967ne4YYQIj42lm39L89nuR B2k31o02k3Xo02k3DBd16S/67r4YZHwgWGIK1c0zAQnzAQnzAVvHEEqp0Yc8SdWZ5zI6Wg9Ok3pN 07Fd783N9fX16H4a2tNU1TS60C/r0GRwsMIRr/5myOFp/BgvfInGAm4kmt6+t+ETjD/rqZzv5hzj +ZyoaHv+YX39b//9/mERf6+1HKEUgl/b6fUi43nHGYzQF+1GhxxDjj5RZuBk6tpX+M/xRv2trdDP 91tUxBDBTCWp/2ERRgPEVGsaSC8G14j+r+bnEZ0XbarbdXb7DMF1a/BhJunVCKHyVJLRPw7TFMUw vBipyP30116FaEbx1+xTGxXsVEbIxz7UewQ9AgeGEwg1WIbEZjxocXepz5GXWOOOwmg0OGEoMIQZ lLUIRGIiIuIiIiIjNuZ0QwhEQYIMIRmP3HmaoGTdZ2hcREWnERGTYoR3QIRPKXiU5mQtiIwqSqmR ZFCITITISIPQZA87gip5CZ2a5LMiudz+ekYrRePRKAiLHadkPzpfaZL9kYjGmSnzoFISz/mEfzoF ITIkC52OZHjtJF8qWdjo2zWjF//VBB/u/fRoe5OiOwho1u7/XX/XC2Sj0HYTTvuev5/1eu/a9Ob1 0I0n+ftbr82LZ4Ned7r/r3byW0VteKvHXTk4YNMwP9X5cEx9dPuSLvIjf6tRp0vne/cJGdwp30OH xZHVf/6qmhXv7YNffjhDdYf9OaAuk2Rj1siQEFP/+Rn76V0oaMWCPfmgoc77X0W5UHf96+3v+tzD 0OHEY363v6D/+H1/5hzDtvDYIGYrXEXBCgQpoRcZ/xGThgMNMboEK8n+G+zo3wf0jaNh/ginZdJQ f/1xcHc9s3QhtpfVa99BjbWjqF9G6HBn+dAt+k91vw91iI7jSj9Yx18VWDMDMn785503igZgafdy T+6fYaRJzEfRBuNKirbq0FiKYtTkQ0I1i4u44aaqcvesXqZyquxi0Iixgz7QlfzchEREREaEGCER EREYQiIYQYQYWIaEYiW6TEREREZNitEtykR2JRCo7WpERNjlVQmX8Jl8lTL4QYQZFciqITCDkMFp 3PuDrBQQ+4K3qfdCghwZ1BS40U1Ctl88tdT0uujPRY7RFCM1CIsds+MnR1QLakLRHSZ1EJAVM78Q kBCWimsUh2pFhSkyDiF50yrRiNWpEQ1tAiP2+gRH9AiP2k2gn0gkgn2kwn+hFBU9QgwoXU+tAzr+ SgKp/CadqdGmI63t67rem6b0Rj1pvBApHiQIj+QiyBJZuo1OTCReZp0XlExyh+o4Rfb39aT0+6++ luv+RGrjMOnmHPFXEIsYIVbhN0GjDnjQ1eg4T03XCF7XoN1fP1+p42lCRn6+SH/1/wfkTVd13+Qg 171Wv1f8UnoaEGJQZb6fczi4XdvXsNwXV71Q71v+jHDfRGD7+77Bi/Xv7e//f/r3quN3v0xX9+kW OYe/T637drd3232pPni/d6tvs92u7Z71bPbZ7NAdhT/6CYJPP3Q18kL+sR0LxHEUx4e0t3X10lbv SFR/NAwwYJYkTDDBgkRQMIdj7DUIYq+rHghIug+0+00hixQ8U8UxsUxHvGrFasUvMOU5Tv4pryUB Zu0FtpYYQ0GEGlDQuLTSIUFWLUx4YLmPDCl2U5Q+YfQiDT4YQM4SsLcNcyE6xERZ0RERZl7QiIhx ERDwjRCI0OLU42hEREZZCvETslRUIRERERERk2EorCIjU7MR3YQ6hCnjsdHYnkTZ2Ceky+pBZIhe REEGkkE0GbzsPykCmrO9fKTKvO9Mp8jM7jOyuKn8vHoLeegmEiViHSTRY7RoKTlhHEj1IqlUvkfh KU7PS2XRdEdKe1KePxKhQpeU+jVZSRUQQM1RuOjs6xVsj39AiPv6MOKCWmgg+NI1uYcseafxElqZ RT3iIh14QeFX18vHvPeqHt57X79e/QYUw531PGrc9ufVN0MLRrf59aM7fu970TigRH39+r/mtpV9 q/3/uuku/94uLX0F05FUfXMdtp9N/OdvrPbeEHr39f/SebtP6M+8ZHF/hhejm+6+v14hL7Qj7j1Y eRMF979W+h7u9X6b+m6bW26pex/of/+u6o0FDDOC8vhBHP9fhbv96G+339QwvF7f6jv/vwZhzjlD 71mH2gwv7FLdYpC3WEF/UyL6Mo4b5ka9Xb3Pe1obsYQ+6+kP/iOxFZ6iPv1BFOGFc+s+rC4VYtfG n4cfis2eGxod6zDmHqH99bXuqtbVclF2MNUEI0LjiOP/KcaZdEd7b0pTlT7b7EVi+zc5u9hSGHYq bmxaxFoWp0RaFq+05Y8Uh6iPdxff2nmgoe7VvVV7FQmq4qIiIjOQpuzOVFnQoRRiI4iIiIiI0Idg hGhcd2pkgQtBhRFppoWqERnmhEREREREZNitEkztSRWsRERMZkIQjCZfUg5STi+TguTTITCBkqwg yWZGkd2ZBMwioR3GQszvGZFlXJSE8/helPantNT+QvQans6aYTCaZ001IiMMJmpHoIMp2R4g4lEV cXyowgZ1qBEftfVbmct/faNd1VGj380NX34tFu15h2rnT89hb0THdH/W8/6t53u1Qb9+mzpnv3Sb /dJ53/8w5n0H3SB11f1+E/1/E0i4R/8acgm337phO3Io1p3+6bS776rS+0rRn2/8730m7/+qcNV9 dB3TdL7tqh/f/+//3t/T1/t6+ZsuFrfv9ntqbkhv78NDQ3/Q5h/mFFdal//p/rX//+///h/1gwo+ vrq3ratauUba2pOGLr9IENdfoEKtf1VD/eft6HjSj7Z+xpWk83ObtpCM3dbS5udOu3r8VtrvTfQI e+oq/XDFY+7FMUP1bHvehHWQ9CLiKBn2e4WwsocjHBQwsa1P+Ip9hhZ/2FP9oaDTQtO001iO9dNb tbFCzqQpijr+/sV8REREREREZyIi6MiSlYiIYWGEwsXDCGmh5NgrGhFxEREREREYUgsQcdhMrSJa ZTxBsRJapNhVpETBc6vJSy/kDkyKO0DQZqyqRfKtHZqiqESMjWYRKcgiUnyNZfIWioyHFPndedM7 NMhFTSoIUtyDnLtnUIoOqan8jEYwuRmFUzSal8/hNPP4IeYR/CdkX7OoSR6SQiVYINSSxLo3Grkh joERymcuOgRH/t1hOjW0a7qaAv2CHqjW/1fX10v1kLSX1tB5fP+mE1P8HIO1BuE0NNzdrebDu23n /Rt6TdN30gRH3SITvSevnf7s8GuvoER9+5h0yrv9TXrV+3Wewd+qerX63QIj2o2vuru8uwRHq+dz vTf7v0u7xp/6v+j+P/pP7rU8bcal2ePc3ri//ft77XX9q21r67feRB0//u3kQ0rf/9/BFh/Wrv// wQKE3f1f3/fd+9+/0Nh7v7/od3sR+scP4j/1H2IZH1e/X19vr/YJranUJ66Xsdl0R7XdJ1UGMfX7 fYN1f6WHe+1ghVgwbEe9MR+uhsP/EbaQSjStXTeI4jtYaU3W70voZ/vaQZvt+jdDukDN21XOgWww RH+99ilUMO/y3OPYqWOExTGLuuxTFO4aYj2Psk0xT8RTuSfHWxFMmDR0Cs/1Nehgz/9ZvnTVsK1h Cc2mhDTCEWf7Oe00O00P0O+/iwn2g1LHKHCgvtD/a/iFFDERERERERERERBghERENCIMLhCMsatK NOIjUEGFLIJIRERhCLOiIjO1cJuFRRplUikzvDJ0VCOw4REZNxvjsINSEyKNU0yKcMqIvncZAsni KohMlUQLIRELyWIwiFotyKTdQEeDRY7NQQ1CKHoxnqjGezr2w1soZ6XowjNFOiOgpqCagmS8ahAT TIOOishMhUdc3EJkLzqjcVEQmEHqW5cYaCDahKEH19bXnHaug2/00wQjXzoENQiq5qETzUJhDNQm mmdLOnp0Yc74QfZVh08/5J+Yv//cg8Qw0CLrRY73/1ReLfVF3nH6Xa1penvfNb1tr4hv1Gd/p/Vb 16YYZhUvCDevtc7njCHINKjDnejDnfCdXtGHO+tGHO/myiQ/qeL3VpP/7H/Xb2u77Xf4vu9t86sj hbX/86MIdb1vjSvW3vW5EwxTzvbIoGP/3q//RF8Je//WxGxHrhEx19bf/Ef9//f/uv+v+La7qv9f /9+IVrDNz/3tuUA7nTCCD7XbHjN0NfbZyxn/7/bZ7+vsEK+50V/mRddVBQRQ/r32sE2lH3sRhm6G bnihC7VWG/WGbnd8Vqttrbeht/9dt62dUr/8VghoRV92NioTGuxrX4MwUFbEVv917FLv8fFcRVt7 KHM50/3whXf+FppsLFpqmmf41MeLi07C2g0+NPjzdxcWmueCnu1GNC8VVQtja2sGYIdWKiIiIiIi NC0IiIiIMJoREMIQwqEQwhYTiGhecCQ4sJ9qIiIiIiIiIiIiMmxWjCJUiNIqSO7RrRRktMhFCdqV buyCyZfTUij0yDjXF8jMmEdcqIkuQkQcQ4jWQvITNeYRqyNZCshERiIjO60ZCyran9fIv4W41DnU IdQgXBAynEz+UBSWCHUIaglH86BSVCHQKE7U9nQKSkSwmR5T2QqIxBTplayEzUy+U7L6dAiP76BE fv3X4TqvZp6+mqr+qr166v9GoTP9nUTtfPet763X53vPZ8WYejfn6jvfRraV6NRovM2Zs3zZRszc p33fPiRedAiP/4X6SCuvX/f/IlFwv/jjr4qK/087ne/Twn3Safp6Htff24T6Xb9zdv0SHzu9Gfd9 fg1X1//9r9/+/bv28RvG97xet798ScMVveRMMUL5FAwjPf7rd+/ob+1P1V/zi2t3//X0PW3dDF+/ WMbv9YNftV9vr/h/1/UVwQ/UnlT0+Gb7OXr9P6w0nPS2c9bPaV9Lue0ZG+kOdFs+kOZH/69UOxFT /jS9qIqI4ji476i1/m+wy40KOoSLn+dA8Z0Cv83ToFi/f9cnVhf//769exQ4M6heqsR6WxvsQtJf haURVaST8Rz/7iNG/7/GFY1n/DQiGmsNTHs583ZusIXGhwYKbswM3fmCj9Z1f2aAUznHjte1q+17 GxTFfERERERERERERpxERFoRoGCEYQ0IcQYIRFpnRHHGgwmEPJsLo7T52CIkIRERERERERKEIiNM qrU7JtMKZdE+S2I6ISMhmTxl6J5SEyQpbrc2QSTOkEiFaDjJ8haKEUIkIoUaFqd0RRk+RVedzyjJ 8n1o7oz2URFMlbNWRLJZXqUZA6W6q00DCE47CaRKK0WO9EUrd2nZPZBzgpQzDIIiOgsZRk8ENy8R 8qlGhmgL2Uq7ZDFIQYIMpwwEDhxohioPScw4OYdB0ZxW6Cdk///7L/kJgiT0LCEa/xEGSoJ/IIVL bpUTHeqwfaLHep4tA2k/sL9sGH1/+GDfwujOTdhZoNf2eD5TSmg+ZoNeaD5vhPP6Z4NeEHZzmmZy bqa3PANk/zekEG/4hv+qfpwwxGOKigwxNAXJ/CJuh2nnc8Wne8VeY+dzvrFp3HeajRhzv70hp0r6 ahNpPhsMP0Fv/Wq/N6/tnT7w3XoJ6e/xxiqt79sccUr3rdcQQS3T5hY0/YgwYMGLQQVf8lGCV/tY RQ9dS+kiKVms45Q+dynPGdyhynKHrM4Ij0Mvgih93/9/6v//9/b0gq74jXrdxCX49CC01sECTCoR TdYII5+IviPiIthAjm48RHFGO1r3J/N853e6/ZpZzJ/N1/XvqEEer9f7wSSQRz8x2gsKI4iNqPCC Wv/wgv5Cj5nfENbb4j/SGvqI0Iq0h7bW8Jb09Tnt70T4QQII5hBW2ktrguSHhmChaGL/9BMjj+dG gY2SHFcUvsURg7Y/YojB97DCUVDCwwv2ErCxBAgsIVHxF5j50X8RcReN2vcOGEwmnm8p7tNU1U1L Oe9NRTFKxTFexsVCj0PQiIjOhTUiM0HcoeIiIg4iItC4iDCERaGnDCZSmEGEznsINIjVpqYHmP44 tNUIviIiIiIiIiLiNTcU9p5yMmwUsRERO4RdEeMiIxGSeHEQ4iIyupZ3cX7O1rhghFIZkcI4yuU2 FtTtSCQ0ks7C47EofcER93SncOaQw8k5trM9Z7+res7neIYdGazNf996WyJRcKu2wyPsMK2Fc9vX RX71/S/8XHHF3t4T2u1vP/8IuKSVX38EKu1Fd/IuNqaQw8k5trI0N9MRWvfC6/6gzbRH2OFcGXcM 3Z7m5z/HsJoWFXHHHVfERERvsXHlkK+f1P+f4jK4sjvXOZUkdqYQlCERERqg9NUy3S8/GR8/mVXz Geqsi9zAqP6hBqEDztazsSiuR1Xp96/RoejPW7/9f5/v6fSb9r7X2/G3v77v+WkCq2nXX9rf2+tK ZGgYHEXeCKHmCRgobf+r7ra1Qin7imHFL7OjBm5sU1n+f7GxTrr62gzbWh+GEGEtr93DCdRxF2t+ IiM3RLIYx3HtNOIjLcyxEiyM8S2xVSup6kLzsLwgdlul5kIzJGdrWdieMrlgh2OEJSEU/tWq5hGa vK4zhJVfp79VovHrL5/K5qKWkCrJD5uzjmdX02193+vhRoz3od7ImBD652MBhfr//X7eu6w1er/6 63+dzx/2fT/NpQ/RnKgpyovxHdgin3/3/bLoL/62uIi/uxEVEffKUv0I+/5v2l/gzOU9w9vxePdj EX2KEU+hbDNzDP/+LU/xaHDVb7X7xURERERERaHFqTYKxEZXK0dpYQ7VDKn1OyIvKRURMioYO1EV xfMhGZJ0WyDVT0F5y0NFu1z35lTs7Ws7E8f2+jQZ6CbmgsdV33nYXWdqPvoz+z3Tt07UIG76+/8t UlW3ruNe1sV3yunRtF1rT79jbXXp9+q4eEwhGZcyOF+veh71OWNd/0P/1f+t/xra2uM/xn+CFAmX QLYSzdYis/tbaTfN3/0IoEPu8YMIY2Kr7+U5rBVRapLx2FiGE0ONDjQgzbEjNbURn+IiI9VEREZX KRTvMhaOyToNVKzqSWL52KIrgeZCMy0Rfo3Oj+p68vn9bOyYhXLhTJAUJ2dqjL52YZHivlSf3+tU 3X1ddcyMpy0ln03fb/ujP0Rj5+zYkd+gRH7V+/7e+RMMX9dzDp96bXut0Z91j3wRQ+SH+pfX+v7H rdfr9/oRocx7ER/Xti9//++uPRb/D396r3r6+uvn/R/fDP9iPbyuIDmRwr9P030CFUWOfvv/7TxU KoiojjWrQtC44iOwhamkMNIZaYoGZp+IiIiMKgYTCYVREREZbrSIUZ2lqVyyCl5MqWmQrOxLK4Hm QjMhi6bo0POzUJnaiyuECGRAina1HYlGRoyPddJvX9Jb6V9Iz+n5/9Wi8o2etfdd+RMMKJEowE3h PQ1877+tdq9rrjmQbLhDssZcKdjGXCJb/f6Zj7qbvTfrpa/+67X4ZiGs7EBjPdnsNTdqbtTQU/17 EbaT8ftFdOGDLwwNY1Y0O30WkWrtMV/4My6hr3ffGo6YTQjP8eprK7NxUR2trYqIiIiLQi0IiLQ7 CLSUlERERlupIhdK6lrIYCiks6Cgs+wM4CFQrlNeXj3kUJPTzsuYQf1rm9Jvv9kBA0u/9BBT2/+E j3H/7pbfGRMMV2VzDMq2ZVx2sx2J99vUQgtv1/7tMJlqki6xGgj3vzUs6Kr/u4yuLA4cEltjp13q tr/hn+hsN/+NRENNNQZt0/v7W0FERLVJFcXmpFoRHBpxiIiIiMtCmiAgtUm4hno7JKyfK4MjKozK pna0hlcti+d2yPXoNDCDCDBAztTFOzAsLa9NhFjt0XbRdhomO0GE66vCeEHk/oINoJ0Efkbmi+ed 7oz/tbDB9PTcJ0g9Nlqkq/12vTg2P7/Wk41/968Nrr//le//9feY1//99B31b+1dJQQI5uYW6//s HjqNW0oa0EtCNDjjQ+xsUxSEWh/fg3YTCDWrOfMfOfNTLcrIxEZ0ZuKeIiIjCFhCHLVJFLcyzsux EREREapnZlSup52a6sEEGdhDORXV5kIzIYpXKwgTQSosd9qqna1HYlFd6qBEceXNINwn9dLPebtN bmOum3+n7pDtddPv739daOLfv1/9vv6uv5j6X6V/DNz2sRuktq/24Q8aEawwu2lf/12dFCOP71m7 m7MeI4ap6+stIFUREZyJ2oQiNOLjJuN4maEREaqdjalcqzIslCnZc06n9BoIF2yunyeMuifMuyfO wTKEdiiK5qyPfRhxQIk+Fr/3pnYiVXt52t1Bo7RAr02/6/+v9NaVF3Hfr+uvnfdtd6N916xxscca 70Nr90H9b+9fV1XqCI4y/aox6MfOfOfOf/m6MRi4fv79b9dvS7t4MbFf/9/GtrnOhDhppprdr/Yo tIKUREQ52BIREREREWhuIxIDXUrlsXztLxhfInnTK0Z6ImjUjutFpmXW9dPtbOmV9M6ZlEdMyfOm dlWdUdiiMlv873354br+t+t6Z3VJ3ZaQIv52CAvGrexohgf/v/14//w38ccaFRx0/9nPKmu9lDlO UOUOUOcdMmOCI6ad6/7ruLhjERERERERE7VUGVBTlOU4K12vfDxEREQQqxFPth6tCIacGZp+IjUc rqXK5V2WylVctlVE7nc4hUdrWt9NMJo3MtIsX/8R+7vlpEqlcWDDTCpx0IjZzgzNlKF39TcoiOV1 POzohedrSlcsEXstaOF/vN3/0JSwwRMFzsEB6/hS1SWLhPN5Q9nRlwUOVFfZ7xf3EXpGgp+Nvv8c etb7/dn+IiIjXERotIFURlMijlcWyjJojOIvn47CkZ0hWm94QPBB4QPmHIVpGdab26b0fPrPYfPb 57fhLGr6t6t4kcf2/b9vgsx7t7t+33rhscNjbYwR7JNMfVt23Yb4MPu7tO75cJERaERaiojJNP52 mgf////8EFH//////5bYjj////////////lmi6j///////y1TCj/////////////K4Uo//////// /////8sFqj/////////////////kB0X6d4////////////////////////////875EBxWo8f//// //////lcsKCB0Th0CJ/V9y2QQCNr20p9OKW4YT1ER8rqvy2SW5bIKYQdUJ3yuUBieE3Xd8x6/d3H 2tr3+IvUR5XLCggZbKX0W5TvoIQf1f3LZBAxte2lMfivhp7gymysaiI8rqqlcpNMtlb6f0aH3pt6 7eWyCBjbf9jmPsN+7u/F+oiP//ldV6yuWhC2VVl+q+f6BEf6il3elfe/s3eljb+sa5vsVEWFGV1V Uy2VLlcsC2Xy9qIh0brBEeu3Pibjq2/r5XBUR0t/BCN/oFYSGztlKHEMKVylDXeQ7ZMjNIyhlsqo mabXQdGHO/fW+v7/7xPoLbfQp9dcVEWo5TIu6Doz9N1zF3q/4tceTg4/BCHiJaRb/UcpkUzp1v9j 1H////8gOjaj/8gOjaj8gOjaj///8gOjaj///////////////////IDo2o//8pkLi0gRcfKZKEXV SmRQMbzH3/3aiPK5WJCDLZSrL70CDfX/lsggYt/YYLMd4p+GC+LtRHldV9lshQThPSLm5XKAxCf/ mP/3a32GF9MQoiwo5XClUgKhXTLZJI/joJ377o9uvsO/v+w3VO49Nhu78RHldVv9SuUBitnR9//F qOVwp04RbvCbq5AVC/2gvRbKzD8xwy0i1XXhjj21Qy2VmLSKd41nIjESAqKqlK5bjU9Fsrf9b/uu w1LZBAwWksqEOy0iyHcx7Wbr4674tbxEeVwX3XV/vX3qOUyU8rqsvg9XstkkcrlALhh9kVpLUw5Q 5TlRXQiOCJ3+WyFjf8LLQKqLULGNcRyuSdS2Qu+ev8rlALv6vzDnHPdv0I2EK//m5xeuIjldS4IO mWytxaQIqNctlVEHTYSq845h/1af9J3dbd9pf2Ke1tccRDCiWkFLyuW5bUIanotlTSf0O+lvm6Wk CL9WOMXr5ur8tkLC2uFEZmnwlpEqjK4LltDrlspaTLSBFsEMeukb5aQIt4j/ufXtPof4zfLSBFER yuURAVJVy+fy2VvHSqWwGjsWE/4S74yQ8tIFW/RnuOI/u/vBm6///tfGWkWqIi0MsgzGWQgQtbVS uq62WktqVy1aM1gkad8hWmP+fUPuxzuWO7/iDf0Yc44IjreVykMYiP6z61LSBFZQ5lzAxoY+WsDH amzUacYjK4WjCK6giypWW3UoTtMsqmEGto1taBEf6eZ+t1ugf/XvX7xstvVf+sb6TallUgmI4pYa aljnHChghhCMRlkTqWQ7ssq3yuq12WUtDBZQNdrUsqiQO6TzQaOpaQKq1Y0Hqd2Mri7Lhd0r9/2l 6X2p//1fxXbW90vqxTYWNbWwmKaSiIsIeIyzQWKaClK4LllWAg7SK6hkeLKki/0ZcDuvyuJrnH63 pBuelfR3vvjrtfLSBF+v/x9Iy4F6/47fvr3PUR3142ojtKwg1GbohhFpKSiIjLNKnK6rFcYy7CDL MWuVyy9NFu1Pr7U76fT7pLaTZXMT9/p907f/r+/BMjjjr2kOhTq6TrkhwqWGFGbsHEdivuIYTTlp AqiIiMtXOVynK5Vk2rR7updFcCtA7hllKF7P+r9p6/WE2ynB/1tVcQ378GJRsI4ZFZdSqFD+v+oT LhLEZX1DDqCJx7v3RXLiuGkbsM35qY4LH79OGoX5aQIo0IsFTjjEREcsiOV1WU+iyqjI8WUmUrgo mq9wl6uEa3kh75NlejP66M970673+3DX11v+h+9eYV/mc49q/el9+LYsa2v46pio1i0ItIZaRUoj LHO5Q8cIROKWTRiMrluEGTYnFcCyyiXU/ot35ZQkvWE/2t3V39bfVk2QC5XrB4lP2t+pZUjGh9To oscocw5Q/q6r0Ii4Ip5dZvw1f9CCBCy0gRX2K9rpxjQYQ0PXERHeIyuSZXGRNxTlcoBeRmwGczDM i+XiyiDNnqDVsJ/eZyY+e3wRHNXoH1CDY7iw0YfwstIEUacEWbVGeDDL9PeYNxr6rH/0vwwdTZCL f/td1DY7k0QSD3174aRXEQLXELdVtMEUPscQvhcRURHYUs2EsLDWWkCKGCI6oRaDBTnjEREicIjL IMyuIRn52V8sh/TU7W47+gzsD/+p2qCHZr967ttV3JY7X+qMOZ/hh2unDE+yS1+yLsGJTbFdWqtv 1eCFFfUMX4KXwoInc7rwRx5dav9CMi4rhCIuDMuEMe9qwoLkh3pprYoGcKC2CKOIiLXWIxERlnU0 dpUU0FKWTTL6Z2qBDs1RWUdpEMJ2V9Qwkp9Erdpn1V9G3Pa9Lnfz2e/6BEfu/9ik256vrf6X7xvr 7f9/qGtffb0vRtzHfof1tX30uxFMMJZ6RvxrP/UVG+xXcGCDCUaDCFqIs/RES26lERlkGZNq1LIQ ImR8jowjsdl8hcdpGR6sREPvV82W1fXpOV0jmsztHf6M++PTv9kSBevvr/dV789//XOj6WMNP+/3 ddRtXYwl7Frm6xQx+xVp2gwhaYURERHLSC0ZK+WRCPRlMIdvF2dqeRysqbL50FBB03CfYQzCkHFu EGmW3Uvze9AiPIjena2i8c+MZNgu20g9U88X5sO+d+gg6vTrq19K1ettd6bq76+/2xXt//+W3quC FXWluK/v990MdsFjWGlr+raTrBmgocJiE0rHaTUaTFQ10IsLoMJjFimiZhi4iIsJojNYgwhGZGIj JspImxqpNis0ztRF2ZUEO8EO1vOzXIVHog0UwYVXVMINTtS7RDApUoOGNGftTvRftb2/T9d/cIPP /5cGfao0PO5/XSV+1GnhO4YlBpvCfd+v3/btrb/0rGldWe9fyNL23fd17YWwoIeuEJFO2OrEVSsV HCtJq2G42g1sLBm3QYzou8MIRGf9MIRFqIiIMIZNinHZ2VIriEZYsM7AwhknkGXRdEdHalJnc8lG dlPhrsREPU7hBVPZOztDCedwc1+Hagh9yLv98N4c7Wrmsz70n5xwdTviHa0zMMU7nak53O+/ODpb qLfrfXtt1gw+uTYpwSVqY9/v9Dwa+sQjtIFF76zsED/rjH4JK+Gry43fNz2lwpHJC2KGnpj+G66Z S42FuNC1QsKIiLQiIybKWNTsbiyrCgpCIpQYO1vIPO5x2SRfKXE+Spl87VncJlP35QaeF41yIRj7 giOJmC88Gvpu63rZOGIXCJjxxp9Gh6zv5oNed+tPQTsvCorZ2Whim6KVFwq7jQrvJ2Yf3Xbv3Xbv 6/r3d/w1MIMPHVmP265+3+34Yf3WZxpsb18NjH31KVZz9Q2o69ig8MK+22velEd6TGw10ZmHYr3d rYj2IoOxUQ2LQiLQtMKY9oQwrQiItCIxGWmUcslBDLWO+zEVzWJboM6inc1Jv2Xwpf1TwhYTOzUI XUmyWC6I39aBEe0RbosczsLep4va1T88dBO2jOePZuBEeWKdv87Wn73Tb03V2Hvutf/9f8fDDxbG vS/+7W7DCqx2F49/9tdsVh2K8KPEVFcjdQ4YVtfYaoMVEaEec8RBgoiIjLQkyek2Uv5NhUMGszse sKdjsvnanHo7nmQzqE892kv52OIZECZoNc0pof4QJAiP3pKtqnpJ3wbqt7TRso3YpX13nazsV+2j ukhof/begydNHF+GKF//eEOHen+/e6vrb2/1OwQMWe3PdsLGs3TtLoimNJOMy4MWKaqsbimdHWwh oXnRDQjP+ZGIiIjQi8tGua0IybFrUhinZGVyRSbVZhhBnaRkeO551zDCoMmQYO0rOxxkWNM7CZHR HRHy9VUW8iMvq5NPTUFRuaSp7YQiI+nCbNAXQIj/e1YIjekHmgz+a3Cf1PFX6721neFetpIN0l1b PB8/6uXxx6710laLuPjTnYJmCTp9xVyutr/7D3r//r7XTj/6v/+DD6vUIFZhBfpA19+kYf+vjiu6 YxfpCIqPmHGX4rUc9X3V1cK2FDxrTQXDHw0vbVsK66qKdigZlC3B5hyoKhsVXFQwlFREMIWFQiIO Ii00LTQYpqIi4iIYQYQaiIkxjJsoRGMyBMqETYX1k210wgyGIdoylBgp0R0FJ84R2kRuO0uO+7I5 BTuMv10THaZ2PeEI1TTTO1MOTSCcQYULe1QJ0aDu+54Jj1ee+nXdgiQ9XutOlbf8EHRu63U75s0j PnOwk6BF/hiUn3Tu04rdD7+9P11hFxGu7X/r79v/u3+LpevJsQv7WwmYQS1bPpu0tcf8in3/UISL o6YrQj+wrccVrHqsZhbX2wr8JtJDYhOFO1IPSsGR0CU8NNtVzkWKYJoGbdBWGFXTrEVhjiKiLCEW mp/iIzb1UEIOGoiIiIzikMKLQybVIhMyVUdUTYfITE7NeV1XOzWVEewI8G2dpnZnnZL3DJWZyuVy 3vPanpg07O3EkHoXxtl5fU9oipw9uH97fnsN002wg8LfbIXQ44bCbg+/249Tu0blPh4zxeeDx35W RbXncP97qCL2kST4q3eGHkR9q94hIGDLqnEGyyjT+33r69f3w9ivwgUX79VQpDYd9P/h+DsVjcIt 1qTTC8ENVBhsfZyv7ju0kgZPQ46D3WEF6m5zdOmFpUKbCTUMODsc3MmnxCttYhNQZtzVboQml4xd xDCrioXDI5QhuONMuRSboYQuIvBVhioKIjCEREZgYTQYXERERk2GUrlOd6svhBlRHY3Hf5CZK0bi aZlGd0RTxfOyXL9S+f10WOzrvR24uENT0dqfprYTsso3fVdBB/wur62dmoRXSf1vO+6vvkh+jd/0 kCI/oEXW+/999zutlwiM6cnzASht953O+ryI6T1/r//9Lprba1+3939llTgvYjfXwUuiOgk0jd22 6m66Hr/1UHvVFpAiv9WqERj9+NdnJQQr/fh9cx4wzfjVtJr31+Obtf2modtVq77FRQM+xJfFPq+D NudjYiikURX62g1i4tC8/oWqGmha+IiIiIiIuGEDCBhC1EREZNtciSO0kVzGV3OVyTO56BlRhQgz seKhG8ljL4QM7fPRBMIGVeQiOxNFt1qpNLkInGix3nsJhNdNci7TCLt6Z2oSZZRuGVwQJ2zwGE4Q b7qzqHXRsurp0D/bllVhKW41NyV3rneT6c77q7Wp3aV/6Wdzv8IFQ/fSTaz0aW+9oEu+5RGECKHk 6I+XSRBruccw/7bWv7f6+H/8GIVfWhEaERp+rT19NW7Pp8xof0Pd/r6X68H1Vt/sEKBg7XXWP99b opYYY+1mRnRsEP+/VHXWOKWbrS/Gla3hKP+w3V/4wZgYgtDq2lXYopYYmPa+vyTwZ2Ub/FppAp/4 tCItNWIjzojjQ7xx2CEZyIiM5ERERxaiIiIiMmymjIoybgdK5bnesQmRiI6CnYTPxM9BlOyPGuL5 0juqO6ZKM7FsvkJ3z+dmsmdOzoFtIIWuncg+zWqn0Fu4Z3kYZbdaquq/qiLdAgV1dsJemvsPTG29 Tu95+2s8evRn81nhokPd9AiPvlOejPvpbv7kRPBb6Xdd02873KXmyW3rs0RHRHRdAih4MMuqr3/+ Ldhiv/9aX1200N1/QiIiov7obaWCKHqsGVtf/1tf/7osc49D+sIsf9VjVCNbCEipf7//9/GhDpfz ohIP/m/pMI1BSodxGxqxatr+rrNzvVbIY3ilvtYM4QIZ0LYqKYoeP62Ip+C3WOLXPIoOewgwmhaF oWmhqseIiIiIiIiGCFrGWjsRGVwQjtTRFcyEheCDOzxqi+mT5oC4TsgcQ8/Ha1Ha1HTP5CIp4v0X nC8dTc4Mgx3R2phTtUE1CrloLPTegRH75oLHpNwYLqkup0CBctAndJuq3Z4PmkEHp54ckPtZuo2b Xne333KVFwn42I034g2jDp3QLbobgiOkYc8f99a3/Xr9bYYodQYoa9L6/tT8v/3zpgl/717d+/su iPKK/qT1m+1Q4hW3mgYWz2Tg9vvqmuIj9jSiPS4T6pnakFjTe/6BCshR7VxWxU1MFxTOhILmP42I 6zoi0GmUi0IehcRm2tn60ItNAzNPhERERFxGg4sIMFURERGW5LkZlcypXBYIOQcpPJQYrDKjOudr edmUXzrkZk8Qi8ER61PRlNppmoRT2p/Xz/GmWgWi/0m5uT7qjZT/Vb+sL+nMdQvJpnOp3faNyfJS j6fQIj73zwa3S3/3CV6cNLenxvQYTtyLmYdX+LiUMj4Ip2TRm6d7/8Qgm6/X/b1219a2/CER6r// CCPaH/S6mNz6Q2tCq3+Prev8RhBKrtMdN0tqu0m9b6k/m+dH7/2hzcxGlhhaOAvN0Rm6I2qU/0Iv sRfS851vvoRfX7Efv968RmpFoWuchC4tNDznQtMRUWmhGdEREQyiWLUREREZaKlK6rnZLEnHf5NI jWFIOIPIVHc8qSO6ZT5fJZF87pyuW9hBlOJ57NYp0CnUQ1y52arTOxxAtr/zstkwl+FpMIeneFXW /vz45Ifvow53z9Ru/u82UCI+6O//ek873KUGL6326FGcqJFAx5FAehq/3Jki6I6BFDy2Er9frt9/ 490ur6/WvhCIjf9N7/OjH92/tzHSrMOCI///qMrlIYtV/9f1s5W/VghVDtnv99ZkdRpevzdtujoF je1/7KUGL1vr4M2yX8U/W8cJeKfBmLOrEUxH9xoQ44uLU4M/oWhacamRDTCH0IiIiIiNC0IhghiT amd0QiMm4+ZFoh1RUhJXCovnbo3EJnQVAzsPO3ZHlTKhl9SFR3yKqjtyINlWjqj8dz64TTOnYTg9 XRgaP66NBTrKWYQaaZ0YTIxKn9bdVdGg7hzQD169fEfT0a2hPDOgTS6BEfep3f02HGtGfdnu+d9u fXCnh9PPF+0/X1v69hAiZMuErdjfXeMicXC0k5E8wFW1rRhzxdAiOilo2iOgRQ/+vv+6Wv/fX61+ mlvX14YhCmhEZZQP/2lqr+w2pu+kjAx/oxXn5/1MOZ7qYW/7b/D/saQIVDC4MMa2/rb0qFe9Rx+k 7X7zQMDP+D3pUtMUp01+NbPc/41bPb8UlVtrxG2637diN86YYTSEJ9io/YqP3X0Ir4qdHwewhHEW CF2FjTCUWgYWLSzHi4iOMGEMqRYbojNkREWdEREY5G+EIjQnYH7s7WcSJZT4rK6rHc46I3FEcJAw SIVlKDB0inDAIMq4hWdpWdvF8ijI6I6LovHTCkKyyq1K4KJpp6dhSVCrIPymHZrEJUIdkiI6VeIi KU9hLCwtaBEe57ZTsESiFmgt03NBooINqkCEUtzD+wRN2SgJnrN3qt1dhheTe8INz4eLVNq6N1HH MP0CI+9M+fCul+hKVFwnv+GGR8Iu4o8XFbVvFJ66FWnRnKjXju3gicRnc8Xrqq/b8f63vXfd+9t1 /62/X939qbrrt2FBE3w/31/68xtr+rf/oVf+w/Z7H4pJiKOow87jMK9er+967Of/f++sZhfhDx/q wkF4bXb21bCTTaUaob6263pWlN2eKf/2rasMKF4MbxTFRixx/FPFMRsVV4Y9jm50b4tCwhaxDYtN BhMJZ/i0LsJoXEHGq4iIiLQiIzIiIiDCDCEOItRIWjtbxE7vO0pCLRUkMshAh2qCFPneBDtVgmIW Vy2O55UI5EMUk4kZtqd/EJhQQMp2R5IIUdzyQz0ayIiL52OELKYWj+p7CFBBlOIE0Gjbp5ghnavP YJFjgjuFfprkhmDSTL9f1RfMJVM/XpIOuowhT6bRrYXVOdlE/fe5uwg3OOYfVW57Ru+f653259Hd FZ9b06Tzvup4evvunbV1aeknjoSfMBGNK0t4tBsW+l1a7wknhkfI9O+7feP/bf/aarv/X/fv/+xG v0OPff/59z1N2cG19Z91Z3K3df1r/0THVb9VsL/aSS2cxr3pvraUQQp1bpvS0uCG/o35uZICsV2r GFc9of2e4axrn0OfXaVrfxhLM0+l+qphbG1oe/GxTFRbBggSYMxcGFYpiN1sLGtrEWUShDXPOPhh NKhG7EJphA0sbFRERGboiM/xFn7M5T6BggwhEdhS3VMozriJ3PERE7piIiInZQh6ggZKEVGVNHHk EZ0R9GoUhRqZejuiGVwqL9pIMiHDI+YKQ4s7CkjOMhuwTTQZFTzs10iKmbJEY51ZQMmQGR0R4lTO GWUbVewqN7JDTiO6BwVNNQ+2EX3BsINKmilmYOIMkMEGdA8RBr3W9AknQnd89HCwRJ+jO4TwnpuC qKQQPp32ERbzDhwgcsoT6O9wbSrnhNz2fO3mHhRhU9GD6unzDtGcLMIj6bU8Oc7pHvM/o0dd3/Yr tdxxF/wi7/3+//01x6W+9d090+YP/+UtVvX/1+q3TX6+1W71VJY67/QvbXT/7c362OULOIo12uH9 Vtek/79HNX/yheuvlH01/9dvinVNNdLT53GYTf2n2sd6emr/fqr0k/664Ip6W+oi7viOOI9jigsR trxHEcRcUFkUfGsR2R4jlEcR2I+enSuF4O68VO5xyn+k6UQmgtxFdWFOhOGhanRnCjniDjU6IYVC IPOjOeznhrmcocINc51CnRBnafiIiIiIiLiIiIiIiLiNCIiLzhce4iIiMZXVctlKUrlvYIEvctlT E+n9G9foetyuUhh9QzDgzNlaHetT/iI5XVaVwUQtla69G70h+WyqxgJe12e2pu4xr93n+NRF5TIr jg5XKco5BGkaXoznd68X3uCCxiCJtO+s6MP5bJbHC64YfdyOFiMQWZp0H////////5AdElHIDoko ////5bJSvH/qrv/ltlP4////////////////IDo2o///kB0bUf////yAkLKP////+QHRJRwAQATX Z7amCmVuZHN0cmVhbSAKZW5kb2JqCjYwIDAgb2JqCjI5MjY0CmVuZG9iago1OSAwIG9iago8PCAv TGVuZ3RoIDYxIDAgUiA+PgpzdHJlYW0KcSA1OTUgMCAwIDg0MSAwLjAwIDAuMDAgY20gIDEgZyAv T2JqNTggRG8gUQplbmRzdHJlYW0KCmVuZG9iago2MSAwIG9iago0MwplbmRvYmoKNjIgMCBvYmoK PDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0Nyb3BCb3ggWzAgMCA1OTUg ODQxXQovUGFyZW50IDIgMCBSCiAvUm90YXRlIDAgL1Jlc291cmNlcyA8PAovUHJvY1NldCBbL1BE RiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0KL1hPYmplY3QgPDwKL09iajYzIDYzIDAgUiAgID4+ Cj4+Ci9Db250ZW50cyBbIDY0IDAgUiAgXQo+PgplbmRvYmoKNjMgMCBvYmoKPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmo2MyAvV2lkdGggMjQ4MCAvSGVpZ2h0IDM1 MDcgL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0JsYWNrSXMxICB0cnVlIC9CaXRzUGVyQ29tcG9u ZW50IDEgL0xlbmd0aCA2NSAwIFIgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29kZVBhcm1z IDw8IC9LIC0xIC9Db2x1bW5zIDI0ODAgPj4gPj4gc3RyZWFtCv/kBqkjtTRXSI7VUYzNEdF0XRtE eI+R1EREREREWO376sovx///////////yAur4+QFyaj//////+QHRVbjyzRtR//+QHBNeP////// /////k2K0U2JKI/////////+TcpVMtYv2uI//////////////////////////////////////8tg 1yuB8rqQpaa0C5XrDEIPWi+c0Fvmg0Kgg5lWhhBxoN6bQaWlmVgRvh9/fVh/8wewwkG7q1rsUDTa trvYQsUxCEY08RlkJqWQjI6I6I6LpMswWRXA+V0rMk/EREUuZXHC+ix5ZgEEK4QTT+0zXtaRr875 EzRuCjTaNyRu3VyuCAug0I0noaF9/Bvf9trmPbnR1btu6u7d7dWbmzcxHvOyE/GhocL4u4a8yRxE RYU/5/jEREct0sjvEdp+V1IUEGCITdyzBZFcDzJPwg4IjyDUswCEK4QTovmjXbRp5sqvQQet6DaQ lkLJGHMPRhzDpdNrbf1dU9U2ZWC+96/v+//ra9q59fv+zn20mPYMEotr/7+xTC4pRttbbq+whEGC m5PFPG7xGnFoWhGIiOWQmiz10rpSJpm47Rpnc8yS83WWS1K4UaYQh52OJ2EyvURHKDToPRY5Mfr8 ER6NlO3zxeEwg3oznf1To0GtiGH1b18pQY0rK2C52s/9PsMvk3LAx2//q34f+lca9vf50d+ZGHr9 0EXFngqCn9jiKvv/hxS2qmQmK+I9hu772vg+rEcLt7uGewvdihxGmXAULfh3EREWnERhOIxEREcs o04TOzJHZrm4yLYi5GQJndMrhKTdGX0W4adp0CBmQo0GdmrTz3Ju4YhP6BEe0Tvrp19XIVVVOd/a BA21O+p3d+Xh31dkEygMfqRGTKLhK0lbpXfhv/0/+4NV76XrO1h32Hj/BzQV39qG1M5Ubr6/hxwx 2k0243FK1Y47ax8aTDW7aiH/UQf2KaVpXn/DsUPQYWI2wmlfH4tCIhpolSFod+IiIiI5bpTK4Ei3 0pXStMyT5iTJZnjKnmmeM7yL6DNUdiMi4zIER2RnYojsky+ZBxfldVERoYUJ0f9MlYmgwtozuR78 3QgZkKyDO4CHZMIZjC2vWvgiPfo0NdGjBEfenv0TuqarabrdG6tmJqnv6dG706XkHLm+u4IG6nej cpsTzv0CI++hd6S9+/ob/9e8adLIKqSuhScUu6/r/8P/3//2snX9oP/IG8TsDf/+8jkraWhttq3b f/unoj37W6h/3DcpyYf1/z3Eca7EVnthxXq1EdghTaw46bOUOzmnD6/8cijnH6z/aQ2KY0hWqYoH aWKDxbtt63pdlEQwq8GCwYUbOeJ3PaHVMk9Z9q1EUxHn+IiI4z/EMIRwZxwQvNyGboi01ERERERE RETslQy0nYy3WmeiZx7UtCdSuld6dncMvndMlJkkR2J8I7GZ2JZ2qEd4R2BkdimmZV8rqYWm6bXO zXwQMECTKGYamh1kWZ6VNMoJM1RHM7gWRyDII0lnhPTrfpkqCIW8HmHYT9Gto1uGi4a2FkLKjovP dXO9+0ajSRoND53B+b9Gh/T09Qnqd6N0iDZoM7tPvuv7087nh1uUsMYMHtZWwxtuRMZH9bVsduku n0neNqv1+v/9a4MP/pvQiq61/vEEXINN/etK/6//vmcoc98H9ZhwRH9vv/NL/7//a2r6gh2v3f0I vjEdD2xzkW6tZF3Ot9OewZOVK3K6mFbStK9KmRjq7piP7+231tW0qtKK4+6rUUGNiKBnBRWxyQ6f udGtt/imKm3oNwqnQIxjm36YQawZQ4IcGEGCHxEadoXDWNDzOU+CaLSKqIiIiIiIiIiIYIGCBghE RmkXC5N4YiLQtSuCx3U87rzIpzEZFmQ8rxCPO0doI7IdndMhM1IIZ2ki+amSoyO1QZ3rHZOL9nYq RkZIzzu0QZ8uiOghKdvuduJZQFQRLoxrZQHCEaZ3wReHndI6RczulagmR5BmSexEkZp1MOFa6c4M 8NVdOW6RoarbDOxX4+9XRomSAlueP5j3Ru0jUeZo0DCBF1znsKfHTmKbqBEfcpz+dzu31nf0G0qN Rq+9WvQk+XRdEf6dsLJu6T1bFX/+vBhnYj691tV7Xnc7+2/e//ERH3G4MqPXXV+4t/yLscyOUpkc Kl5SouFBiVuF9X7f/r6fu+km//tf//wsP69daf///WuhHatnJGQrWcIGo77rdRGv50QReYNjan/d YaRvZoGOquv48Rt2EkK9gwS2LtVYptcmgW9JCnfG9jUdVbvdf5XJRpznQYre2Khm4OxFMKKmPQTE cLO+kY+raX5dMRw0ttdM54iwpujhhRtNBhNCM2xNQsfHGmtp2mN47KN/iIlSQiItYiIiIMEGELCi ZBOf4iIiOxEtx8niL5kn5N+0jucduRGEdoR2JZT5JOKTKwlMrzuaNSOxtmVThMJHbhE0yGz/Z2o7 JAUlYhOZcfDIKIdIu4M7GkfzWJaZ9Hc9MJ00lRraNbTXVwmvsv2wwqptrqTSultGdzw89iFP9J0m 4Ijt9+alG6wp4bDyVnNlqd2dwd2i4/fVOcW/pRq90E9/pXQqrhhiDdNe4bp0EGt3/tVzf6OL3rw3 kSZHC/T9Vgw5FE4peyLsR8fvKUGN+v/vrf21/33/r6Wn/XBr/3/07Pd7rYbUZ/nYgMOrnu1UEEbQ Inezk34RdwQ3P4Q0NGRsFWLXEVG2laTcX7UGXHGxWECTBBOQMMRpE0FaqNKYf8Rx0+KYqw/gzlxC XChLha0sFyQ4SsoczgqP73JOUPljlRs56N0Nb0PsKboaqKQXNhVx4Vg0MscoeOPjU57CE/xERDCB ghEaEREba2hEXp2EItCLiIjERnPERERERlpYMRLIK8sgiL5MjOR1MxnZ0UGcjtCQZ2p5WUdrcdgT Oxp3C/fd7Z3aCkiPxBYIvnn0ShJnSLs7hl8nDB3SBM7PBBwyE/cJ2n2sENB5KRKb00/TW1O3CTOz twiLfDUyQjr0d703V9NpIw7cLT+787tAiPuzwa6SQbShNncHp8m0L/dX0nnc76DfO53r2/1vX1To w530845nq4Yb/g/1WspQY/21b/et/69fFbp3XVrqwyKRjw//v//2/++P0/f6fVv6Tb9fw/3p1Rkb X93/t1UEPS/7X9+37oIuKjD3pWtpe6XfbHbfaU7lD0mNfV6tvtX98mgrvFiNgwSYp+DC7Gw34pgw XEHZQ5blDhUkxFQwr62EvWGFgn7TFNVsQh2nD7ELxaEQ1uxXFMVxTFQviDCERBhBhCIgwgYIRoRD BBhC0GhDQYVdREREREREREZZxBlnI5ZK87FjJNErPO06LfMk2diyMhcIQ87EuW6ySn8JlOIg4I7I SZXSWfQQZ3iI6I8asjoKdmsRqSkt+WObQk1RkN1RcMKi39uVxATuZ2CEaEeetGBg1eD1vTzDlD4Q bzB+l6QdV9+eA0CI/z2HG9K0hBpfo39mQlG6dzvvptG+jd63P4vXY8m4c/T41e0vSd+2+vjQt5oy 4WMECS3BApbrLg0P3/3//4YIof723f1X9ZF2GHt+fV1EYIbX+hG/Z5OfSFNI3Zyb9WHoOjdtIoSD BN11aDX6MOYfa2nDVR3wwbfQYebahb2FQjhrMOVhQ8GWuk2riHbSjQ5ueufyHrGp01iLWxUscoex VCLTTsfxS3W1xxCYqIURDChCZoMIRoWENBhM/55oREVk9zCk2qIERERERERm7CGFLONzQid1QyyF 8ujskRzztWjuvO0kUiO7ITaOwMQjOW6Wy5lKMLDOzVH86o/oOyLZxnRhImTNtTs4hS2YYQM1yZCu zv4g87hl81I3AgZCSggfWGuune6DTTSwnn9VQaNEIUSoQg47NQh1EXTTTOm6NBQjand6BEfe7+Fd IztGcQqmd3ou7U70m0WPS1Vb00bP4o1uu7K2GvJd0++8Knpqqd+E6ShunaPaJPKN5/yQ+d71PGr7 z6SfXiv/1r/fX3eQTxqv9ud7fqKPCdL6/fdi6b65W5///9X3NpUuNA//x//fX/X19a13XIu/v4IY JkcV16X7+lh2e///48zXt39rv6SMDfY1q1Uairq+rVW1WYc4947SW1NaI6X+oYW21fVivUEOnrSU 2wxFMocw5Q5Q4TIo4TGxhYjigtCHKlbGEm0gQiu+c7j/jSwsNKmz3aw1i0NCIhghaaXDX4zDlDlD 2tioTsfq8UxTWxgz7mNioiDC2gyhwhanRFgiOhGEItDTU5IFvN8WmhYTC9qIiIiIiIiIiIiIiIiM zlOxiIaluZZlpnZdEYybrcV4QkQ6n0dmsXalCKcyWuwgzVmQKyPHc8pWUZLx0yCyDOxPCBlXHc81 sj52Pp+1Ty+mE15Y7U9BL9SH+eghOPUJmsIdmqtbU9zj+rU7utzSmhoER+0EH+CI+/vv8w6bea2q ek/i99Lf/SdLdK3dW8gt6/bpP9PN3dAi/ffb9f/q6/dtaW7M4uFj9+tzsZGAi9D9bvRPdD62JGPr f/7/pf/v61WrV/1vfrese2t6uqFbW7U/50QphKh/vP26Mbqv6HHmgp7Hgy3KHw1p+vRh3fsIf1CE fdqKu/2ewQq6ry39cekmhDxrGrDSz0xajr7CRvxH8MEuPdNZuozlxHThr8MER1sVFPsU77gzhPvx GoMygRVXi8REREREMINC0GEIiONM546zfdoafiIiIiIsoiIiDCEXiIjJsOjCK40iuriFEZaI7DzI TFO1NQnZ3OOxzI8QxEyHEbzLM4QQPOwebYIGUsFzv46aDIyL53SRCDlDlbs8HapQvpYTJWEz0ahF TRY8heE0GnR2OEU9o3Nc7HCxFhPoER9t4Ij7ovmvhLntoIN/MPRsczkx69pBwtpMw54r6/SfhB0b 78kPIVavuRRbCpuuoIPN16q53vNlIanfdfK2C+nq3jboz3sjN36u9JJ9x20hvV/8NuEElv/+v9tf b4d/1//ru++vjiEF//nR/dXPpCn/g27W+O/9/Q/f8II8v76/braVpp/02xFOvqra62e1tf9BK3pY ivYimKQ5u/iDtQwlOexSSaVpFKBebraV6R2OFCgih/raHdrd+MQy6ha7qRMMMf3FMRoKI2I4YQhh DPONC0Kvj2wpkRoNNTJyx7CiIiIzIiIzkTvEIiGCJNC0T4MKWYKIcyK8REROw8RKXjJt2Vy3IjKN SrEJojsUEXLVKuTY1wU7HZfOzXIMUlcEHGRTJ8nVrZ3iKEpri+dziZGVcXzsT1hkS7hDXU/hB57v Q0R7mDRt+QRapouAS2djiJrnZPsFQZVitVQIj9vov32jQ2T63cOoe8IVcKjWwuuCJPmHBhRo363v hP9Obw289ntc8B2e5sO/9AiP5ClP2s3zvvcJbgw5s8f31bb/UGDEcREG2Ot42Qmi8JqP67vhE3iI MGkPX4f9/u3/t9ffv/X+gt6uf39DdYr1SzqM7ngkjb/3M5UFO0awW1//+vf3hr69pLEYSNoilm+4 qtaoReh13s9xHeoIcZhHZdAgmznQ40p/sVNzwQJNiPgs/tpPrn9vSGPfqp43YILI5divarnPX2Vs MKOMb5GPiNZqWIwZt5DHEJLzzhoXEWhGOc8YWGEIxhpn+IsJ3B5aie4iIjM8ReaCnjMOYeI0GFQh 4TQlqJStFGMIRhCJQxEXxGTerJnCJlRCKlSI7JEJD6lulx9FKBdBnZ4vhAyoZHzucdjxBxfoIMq9 BnfxCI/WJFfEHSkYz0F01s7HE1ugidtYOQQN8PsOaDPnthB63PdJ11ejdCDmoJMOR7NQ01g/NZot IIOub5nvO91sxwRf0bugRH/TMdWkIdluW7tTsCfp8duvSYev76XZLeh6+2tXnc7wsIO7Ep0GDLrq 3r/79edqY3/+/7uq/XbRe8+DixZ3oy4Trf3fhvvwQPX+oO/ev/f7W/C/eqdYje99QiWBoR9d57+t iPNpfwYPrBFDsj4RO4aRu7V7S4bHekgQN7DtQbj2NViP87UJ39Cdxnagbj+MWOY9t2I2EGmc9iKH 4qan40OGFGnhL8MJhCIhphCIiwp/4aEZ0IWpHvhTTwnHgwhEQaERDBCIaggwqdreIiIiIiIyboyu lotx8o5NuwgZkIyEyZpSfPM7IRCZCshOMg0ZGZHZGUM2R3aMKqZkhZ1VhDUIMmWp01JSJ5D00zux FcJ2dGXd0bKdp/zRX3T2T7ujW1hA63p+r33ng+dK/7RuW2/06LH1oER92p3y3WYwEV/fHd98jhd8 SdGwgMMezIqlbQQ5g+vS7O+dV+vyIlb/Y9dNQw+lr+tf1+88FPf1VYP7dZhzDnH9PzOcf/d/tb/0 /FRfUEKBDh6t2EkhFwQ7OY0LhIwgQ2nVz6//vSy1Ri/DS6B3SYivqPwRfOhtKLiP1Y8RvsYMwMwp hqwvBnCvpYM6+NV2IqljhhU4hiEIjzdHQ9iphyhzj5uKe0PFghppxEd2E0ItULTCGIiLKRERERGT eMni37ESbnjsRSbRxk0yEisRri+d087FSJbF0QmZFcdM7wyXM7rR2kCSFapWW5lIPz/R/JUIuQ82 yWiwZ2OaYVM6dlbIhIwylhjVbU6ow4M1Iw+myff9VsIWnDQaNdX3h2mkp6gi6RoDWcG05/hNPU8Q 2/3hF5QIj7yLDRszuG6Vzvv+p3zQfL9Cf636nH4VqCI//DBi3v0NejRdIRBhjT/9jSWKt2/7mJc9 PtiCJDNX/Dd9//Xe/rv19kZVv2Rwv5W2XCRpK6BJb19JDjf+63ClKZHXmP/ylP6g+0OP/uuu9LsV hI2tbPf+Pns6YQSF2u+kCGgd/fXMOSHBEfsE0mkbs4P4Iqwd/1BArn/P+O9J6jiE7dfrWxShu1Ru 0I8RY/saVnzY0rSqv+rEdqnCmSCNiMGfdmJ1B2GEv+Tcoc4/8/0uFpY1GOPN1prmcqFBCrCxFoWK aeSGFEIXjDSxhrjM8REQwQi0L8x4YJxDQjiNYjIrVBGijERERERaFG/O1VQRJuTjtZxERk2Hy+ZB xhFPF87PnYMzsVy/ZA+zurKfOxtHc0RtHdmRDhdNNOyKZRmoQ7nJp3DIgJDIwQlooUvqFtMIM7E+ tpOk+qkZl8lIk8MK8NYYTCrd560aGi3nau6BEfdAi/wRdfouJoC6q84/JY5rnaQ0X7RJ6BEff/Se E33r67Su+kEGtGcqPZjSewYMv0HBhoJucIvp36bVvf/r68Xiy8O/+q/eP2R5f/7zQF/p6/+9b1uG /pW//UKOE3/+4YX/9f//XOjZ7YePfEbfQRO+ETvrZ5f0hUyP2tpb1tJW1XWMMbb/6kXG5oFOwg9h hJi715Y7rtXoEOxFMRURX79rMOV2IqF1C4pWIq6PWtpWtWg01Qo3Q1xTQg7ULm2NBYYU0FD2tpxd imKBmaoMWUOEDCFpxENCIYTVVTjQu00NOGmqiIiIiIiIiIiIiIy3MzhBnaM7nmsjt8rmcaiMkvO6 8hx2LGdmqI0R3OIRQicBqTRaZFHn0dl8ozsuzZkpCJnYONsqMheiPZrgzubL6aZpZSgXXCDvejW5 FL7KeL9+mqNFUGUFZKAjBrITcdFu4yD6NQlJv9J980BevRozXSb0Z6fU8BzQaEyrDW0E38zlvXTk yRdF0vdY398Krw9PCp57bow53jikGxqd7089nxFCxhB0bvwQiPft9l4d8Z317tX2d3fat9bYRe4W CBf+ON/eP/S6Im4w3/D1xf4ar7f+vev9/q/vnIght8ig7DxnRh9Jd1Deqd/8N9Nv/WcUfvjvStdG gp4Y727VSUBXVu1W2P8MHeDB+tqUu091hm71gzDBTMOFi7+domKCpQ0jtExhbe286YW1IcFjSbSi NGsrNpR50R3TEWsO1i/NBQgULCw7tRxBBiogmKj3G2KSiI8yIiIiLBEdNCGhaFoWoJqT3RBhTo+1 N2LWIiIiMELCERERERjk2V4jJucztGdQh3iMlJE01O552qM7DRrZ2HkGoQZ2OESBS+shByiDYjuJ SFaDVBkyBc6NMmSOwXNbI9RcVm3TZGZfK3EO2INMJBD0W7OxwiLHaW2iLsSavpua9IER9zQF2GF5 CD0CBCl0E3oJ2Z9eq+noO2cdfsQufrdQp/XTo3aDYz9p6n5Tvv/xX7Lw7yCYYRSowE91axIoGPoV 9tcVFd64t1+38Ga+1X3zf//rv9ffVG3P4YeMMWp/v/7cx/2//lKG7eu1JoFr1DHY369hDKUEI7+1 s52utrdnL6sMJdntjSckj7h4oaG+2lHpN0w0mkO9bFTAxsUHEdimTsofLj7HsUxsUOxFQwq2hEMK CF2ESMRYU/w0wmp/tRGf4iIiIiIiIiMRLTLVJt2TSNx3BkvmEV1RHY+ZYjtRHYsR2Bx2LZ2kEluZ a3oNUzucEyPSD7Gz1glIyQZ3UrO5wQZ2DGR0CBZ3RBL+2jQwm52a+r2dhO1bCDRh53QUH04iM7iC aLcpqp7WE6Qed+roER/nmt1zSRY7SDYV3RsczwQpodr9Wvvnc9LvCBejP+EG/N6Ix0SF9cKfvnsh OGJW43vS2S29OtyIxCX1265BOvndNq5SswNdx7RnKjJDtO11rvw//0DCC/9XdP//VONdJ6W4rlut Het19Q1BFD+9W0EfwVfr+Du/7sjhOccse/+28zgstQSVCRTR77ftghG0/UMJKht16q3Ef8YqL32t +kLQ5Mc45x7FQwsRg8IY1KtoUwotKNIG/vmHOOccER7VtW0n9z6GwQiDtMU0JRsUNgzqBvjOjsVQ iO7xTFccXEQYJhBgsMKc/aGhEX3HaaFpYiIiIiIiIiIMIZnOOpZCedMyqzsEhaEPLczR2g1s7Too RHR/kTY1EapnZrLZWMLF3IOc/E9uiERkHF8hM7JxkFZV52J52YzCNdz+jQ00FBkEEOoT5/ahNGEE 8YWyH+ZFLQZ17OyYgTskBfpNoERxzDsJcJvS57em3v+6rqunvp6YVBg53O9G7uIIE6u57RodI7/s 766nh7o3Z32jUd/tXEP9pCuEXX+Lpv/3X/fO/WPvT5If10cSru9fb9beTQJ/pXpf6Dpf+h/6nTCT /t7Bt2qMnvgg//a7/4d+v5n2rhNYgv4Zu1IpniiK7Y0TmHbqCH7pZOGIbZyfq10f20ojrvjhpbYa c+mG8IOx1Q8a0HivVkh19ikSfBOxqxUUDBIW7iLGDPsUtKdM7BpWIpiou0wRQsWmf4akJsxF2F41 jN1oGCiIiIiIzbFDchEREREGEMtBzEXGTY1I7pnZgipryfPsmZHdWRRnsi7ISOyrO6ZrM7IztS4T OzXtNMnyjhGSgTCed0EIPu04M7G0R0p3CVNSD8jXRdvdGtkXv6C6NDnQVs1nUSm0CkJsmIwho0M7 HCnURT1enXp9/suaLxdPqi7rCeiflY1VJtJf9W+tv2tNG+h/+EKMOeK2+Ko3pG/TzdRhzveq/9fx 9dX5BKPr+kMIvdDaxx7dunc77vJwx6/1+/bbtYf/v6w3+h9bhtr7wQ7oEOdGINc+m34Ofyntnv7+ Yck8MNh59P/28GhzH3VJta+ONiKD45SgxbfauLhhw4MJwyOi9anY+R0Ft9tXvFAzbExQM0FOvmso coemwga9X6bCXnTCnZ3HEbaQQin1Dzd+04acR9oRB5uQjBjMfUbFIGMQQqscLihq3qDCFlDhUIiL T20HFoMJuXsaKnZ/hhM5hC0IxERERERGccKEIiIiIy3M0ZFKOwrK5UijOwRiI0zugzs/ZJCU7nnd FGdiSU7IMyKmRiO0I35Hu2dmvyDlTJTJHcCqQ855S2basJM7E4INQnZ2t50GdmXkKaF2/wi4aYSC 2EIcn/CD9Fu+Z3n/fCB8m0HX2jeqdAgQpExyh9IhB7fUz/LnCbdIP8K9F54Sp93CCq0oUIQ9z2g2 QVgwb1T+5jSc7+Ul3Td+52N9oIG+gXfilvtFUqErbLhOvDYr5my4Ra/TM4uF1310zNlwlZ2Whj/q EEcS9Zvh+v/6V6u/79fw1f//gyZpoEKCCV0jHfw2z2Gpu9+En6am7qv/Pz30P9qdyo/Mf21SCXa8 WrcY9sNNRCBHu1Ua4jtWhXatVtWhUdhhXy0ilS3MgsMJBlDmxRxpxg6/EUEuKC/JjlD20h8W0mf7 DCQ9xX+R7wUNCsc0HeMw5h40Gewow1jyiLFNcV7FDhheObaAnZz0W5VpxB6EOIjiwhEWhaaFwwmh EcIREWEJmhERnPERERGIiZKudl8RO1rk27Jpnded0ynRtHZ0azwp2s6ncEZCiP51js6OwLIqpXVB +fVnZqETUJoPCnZYGCG1s7zJUKCeg1ITkI5wjggzsf+6ULZ2OERb5BBBhzFM0yHaaCOz5S2EGE+0 Yfn9T3FkMKSDOR2tRaQvUTt9/pK6wm7JwXCJRgws8GijDivTRnM7YTdBv/ncq1pt0+CB/b9n9zv0 b0rzn4IER8WKGg9BhHY64U90ndJ1zfe/igpuo0Pxq395Sgx/3jV7cvDvQLBgkrXKnp/3Tbf179+k 10252WBj/UeP9Pv4YbteQf/RvQfqr///a3iEELe2l9QQ1Rkb/u0vbUYxvf2HH0trf3ehxhBHl7fN hUbDS5++dmoW9bI6I7dRUMc7zH0qaw91phpdrEeoQSa2xuL2NlwUOC3e6YiojtTuyD4MbasRg1NT FBWPbS5/zc0MhhWG/2EHEaxpFjgmlYpIPg7FSQ8d3VhUxU6P19O38cRFoWmf7CaEQ7U5/jiLQiOL U1lDlPmLpoRiIiIjiIiIiIwhFoRGIjJsPmETMzutEyjZFRncMpEWgyjtVyRyuloJppnfhE8jEqDU t/ZHiaR2aRqMIMjIvyIPMrLavPDWoIjwIaLd6vns7UpMEQ8tGF2MIH5x17zDlD2qdUE+v+qJjlDt FxXkI9EnfSbtbMdCDpfP+m8rqsjPt+p4aBCc4Qbnfc/XRqOVwoMa9V9kRf4kRLmcXCrW9/9X37/0 9d/8Xh4/Dfvv+9f36S9cfs0FDlR+oj4d9w/an+1eqG/2v3//xF71zs1C22pOkGXbdqPtP1xStpWr 6T8NfsRUw5Q53KHpFW7SQjB7S8Y1n/qxt1etqxV9oREQ8w5TghYqTeIYp9ivaphRsRUUGFcQ0NCI agiRtC7CFxaBlDlSEJoNAyhwURERERERERERGWlyOyrk27MhiLcCj+md3lIIdiSK/ZNMqOVyXO6S qQmdzifK3EHJpw5B9J28X7OxvOpkEyMMjmqDQZ2JxfKeL9QQsyOJnZr6IoUWOzowtPD0bdHZ1CHa jsEQ5TP6EacibMcLnYKz10l9+k6umztzRv6vrojHessdTw5nDXXTfzSrM53/bVTxpGdnfOnBh6BO e0Z+jd3mpd2Ez41c3iHnfc77RnD/VVk4Y8f+n/JbMimSjJfruhO+/Su8Un/NQp3yXf3p/+t/RP/+ v9qEFoP/Tfp2/uvl7OD/X8N97Prt5j1VEYX/69KDCLigj2jAQf1cHraof/3Df/XvqyQ+33wQ7ilj w1atk4w4S+267NzDPA7aXdRGRDh+r9WGPofa+wn1aUWGkD0qG57Dxaxh9jRvuudEmHvq/b/NFqK8 GfaFTSsYwWqGLFZ2QgZi4XxUx6EIWIpiKbD3ozQhoRxaEQwqeY/an+Lhgh2hGCaaaeIiIiIiLzdE RERGZrLRZiyZC0IuJ2VqTYdnb53eQNHZWiVsp0d9kdaDINCTeaTldLwg/JMRU00LgrTOxvKfKVEJ nfoq87ciTwQZ2eUg/ot3IOsy8ewmdgQiee62HIPsRPaIoKf5rFJowmaghQZ6QZrETOxwpIaCNYnQ Tt9XM5nao1v4InswwYbfb+F09PRrqjW0k0k/TaNh4r6CdyFyN2nf/zEDDnw8X/tEh0QnCnejdmd9 BtG7TzdRoEJG7K4WKF3pu36221odu/9rYZH9u7ofne2F0roUm9ehW/qsaHr/EGv9+t8V+hr95Qv9 2/dabf13Fv+jD26/Y7Xe/L6Hf0ETjXoaJBTr//fvff/aN78o7W1cMsexVwmzndfOjEZKBve/DBD/ qNKzlYddYZz1XTuzn8EU420qc9vQoba8/9bQW2vNzqrvFpY2Gx3UbaR2ahYiou+CHGNWGVNaEf7U 6EwtihqhBmCJj/d2PY0Fax5GOWOwwhaEZ/qLyW5raF6GhpG67tT/YUww583YsoNCIizoi0IiIiIi IgwQiDCEREYiIiRvEZXWUd6I7nmXRpEsiCCWSuIOO0Z2JIp+CBqCKHnbsvlQozpBBhTXEfO1ckEG CDKWGDUy+qBnUiWxVxfKXEWR2EM7oRVPZ2ahTscRdPo/osdzBLYTCSLHcz9c7HECYIHR/C+Xz+U+ FTQZKQtGjhV9k//QbpdCEgg6TaNCXWfHIo/+6VQQ0aKNdKk3P+f8726Bh96T5/nfc9qrSbGfnO+0 bquj5Dd6O9/dKrNqm5s6f8UvNAwwxfq40v63rS13xr7t//fnc7s797pq9P8W//DcP9/fo4v3+vOg tfu9/+v73/7tnZI95hdn1fzH6H0ixyhwXr6f2vfqCB39rx/sRr//48O6VlLRHwrDBX1ewQI598IR b677V6um+giXBtnJtdLX137aiN1Vh78IRSHGleEFz/bXPqNYjbStW1jWCB4q0mPn/fQM3+8e6JSF boRwtiqoIfsVFsVxTFMUxQipoGAwvtiP9ipzpjQR2Zrz7mf4aEcdranOg0001P+xF6aax96mahlO RERGakRmHO8RERERGZERERDBCJ3mMRaD0LRkW4iIyyViiJGYidM7T6lusZHRHZkU5kjldUjsiO0a YIMq8hfZ3ALkzkiEzueQeS+VLOmVCLoIRnTMq3JVn3qVqcZ57KWaB6NwZGZeT+DpMJWdmohD86MJ +fygKVKhKf/00QSkwi6OzO/S6Tk4Ymt/DmcmPQqlv7/TJUEnB1qd3ew4iT2tr8Ke30+k/zwHCgg6 NAWjd7and96NRrn0/SvTy3Lffb/crUYCdy8O7qzOMBCJo9hRBsdvo1A9DT0rkSzaI+r9PO532nbp P526WEHuc87C0XX9f18NvW9rEevTm0v61phCO//eN1/sJlwvvtnZYGMbpbz/6Ye+tTOcfM5GPIeF /7mcr96+vof/cJDseul/+t6Q/GGMboaFxn/EJ11Wh2zmCFR0M3e195wd1xRub/7Ofm7GF+221/4V pRH2h061z/ZGOrb+bt1/+K/rDSvznhqKf1gmK+sGZQl79iuOGXRHn2GXJN+GCQnQv+Li9CIaHF6e Y8Xn+4tDT4MENIR07FNC7HTvEREREWhEREREREQYWIsIRDCERiTYRiz/EZZRbKEW4NyLWVsg640V uszVFyuS5kEilZ3QZHwqkUjJPJnaEQfIIhm0S6I6sk8uiMi+mpCKplruiLuBHl8/nTyKGYI7JhEC I7O3yOZ1CE5lyn5xJBiSKiKM2uSmLmdWXci7HLtGsT+3LHS/vqqCcIa9/acGtrf6cGmglv3TCZ+f /sKe3P+n0blCRo4QKajRqMghoER90CI+9IEX6RnnY0aM4pGxfxFL/711EiNW0dzxxqrEECaenWvr +uqsJU0k/8pS7f/SreHX/+9DfhF1////CL2a6x30iPc/EfX/Dv/f+GalX7////7m99Ah90HBDteG bobpfdnPSSBHwkhragyen/9fWgZNLpLZzrW6s36YpYwe1tvi41w3hWGCXet6UUsUrxHF2wZ5CBT4 MxbCqLFPFK0scQmKJUFYimI3V1O1AX9bQ9A1s/WhebkGlgqDCkYhNDQ8FNOjQU6iIMEIiIiIiIjM DPtB0gIRGXu0GmheLQiLCERGWRTRkLoyC8TsWIroQlckpXS87nnc87LnZUsqSBBndWCDCDNWSZkF Sms72TP77JUIStEfCpncxDQdnZfJ4nyfOwcf0Xbz+EwmXiEylAuEzsTofu6YTqEI57pWjW/8Jqgm 10XDX6RcPvVeto3fbMaJD6Sfr026DusJtAiPvzQfMJ3Mg39ytRgJT0KMOeP2jOnEkq+y+CKffPbr 7fevxStW1DDlcKDH2v9f9dtoP4iOPDD13X180BffztOy4Ql5kVpEnrU2dK/b/fzQofmP//j9/+/+ GFzoghQ09rnv1iP+HDdec7nP299df5kenUZ+wwid63XbfHbf/4PDS/XhsWho3W0r1+1ults7LR98 Gbf6it4qc/jDK2QI+n2w1e5ODsRXsNJsF8q+E8aoXDU/xxEWhV3F32c6fTaHYqKHGFxETswhERmR ERERERmPDCFoGELVSyFOIi00IiI0GTYaQjK5kjuIvk0qKUiUsxmQJggzskzvI7SzKpmszshEYR2J IyR0wvR/hFYgvZS8njsmIg7z2djcEGSsRBncCZ2rVk8p9aW/zeCHCddUa/XzRVGhqQcncHr5393p mJJd6RukKVN1e6TaLuk6Lv/B99d3o77653O7q82tIQmr7606Cap4TRR+88A3qVwoMV98Pf9zqLuS 1xH/ndvKpXnYyLhV8e8ejvp/Pjb/+hw//sIO1vd/h6DjXff/4f4dDzo3rw4ivwRLgb1Bzn2ct1Ya sNQ1P/7Pd1Z7i4YIeK/b0p/h7u9Ag9qHW4xtJt25sivaUbrHtpc0FD/bEV2M6E7FCDsUVXelYo7D VlY6d1YYVYYS5zzs9OOaChwroW9bQ0I1i0NOz9aGhfF2KmcocoexzDnH+IuI29RERERERERERDCa EWgwUIQemqERk3vOwVCIiIiI0RNlDLKW0rrBnZ9kE2OcIV0pWfiTzIWGTIjspztIed152rZvK/Ii OEztwiNzU9AgwglBB6ZFWYLOxIITmXJBwZ3gU6Z6IX3nZ87UsjimkEGdrdRcNX/65nei46znPtX7 Row9fqztxEKpM7UxNOjdoECd0aBC6D8Jup7fZ36Rs0jRSbKc0bE79OFljlD9Guum8RCL37qqf8hU djS3pf00hhVZBKnDbt/1ZEOdzujsSqEP1aMOd9eu0/vzRkcKqD9a4q/3vtkUqNqn8iTLhfv2yqpW m2/rfq2wce0c2//h//7//qmP///jj3dff7ORW4GRmnTW2KGbrw9X+c7qzlqvdHRAid2DwQ2p/3TX 37ba+9uo3DzdiNjrEPdRr4x2kkLqhCeycKkK7q19Bo1MFiKtvthVjrwYLsWNoL0kxQWGEoWQXoGY K8UPaiEKDCe1xU3ZCbDzniNMINclsaNzD7FQsUWOCcdp2OCBlbWsVBhCM5slBCOLQiGE1iNCIsJl SVhREREREREZZSTO6kW95XBFK6rnc8yLxfsp8qTCBnTOyvOx9M7G2Rmdi2pOzGd8yIR3UiZsk2ZA 1U+lP5WyC8PMZ7V1PpbkMAzHOc4o8wiNUfZUsIMhhDvIE0GEGdUdpQTp6prcPXhA+m+yKP+4Ijoz Wp/Oont6LemhzxRbsEGRyX/vO/ngH11/1P4VdUKa+s1mjCfQTaNBnqrdB4uZ99vH3Fv/MHvnfM1I ul8JX/T+jOd5Cqnv+np20b1WYqtGg1897r0vO8Yf+626zNhCPEIIhsuFjj/pLT7a8iYL9q23j7q9 PdXhhYopRX8NYjprQ/9I4uviP7fcf/df/f1xehrb6sMowQTt+rjP+wgSijdnPn8p722/r85Hq0tz 6iGv315hzPm599NxCBm6hHN0VXC/f44M0FD/2FdNpfatqsGnHaTpqdqYTjdbK3oIzsjhVfVv8b// Qu9qLax+w0op0OYcocqLaxFBL7uLQwnqYcr74vWPToGPuxUU0+xhhDtCIPFBmhSxwURERoREXERG c8RFsRFhBhCIhhCypoRDCEYQxERZQ6ERERGIktyjO1Ay3Ecrkud0i+ZDM7BmRtHcGTMiNZ3RWRwp FmmpknWwuqDUJ5CK04pMhGX0XYZK2Xzqj8QxDtEdhIJGsjskF/fPe0a3Og4b87LIkUngIjyM7W0E 63eE8JpJr0d7v2Y6p/34YUMMenQIj70G0CI++6L5vBEciHz20WOUO+vmRGp39/9++dj+GKDbXZir 16/ug2qTWroIQ1qvMrBciGmr2ZsjhVePyWs0YQoMEGDFX//W7+nIJE7Lharq8e3/bv1//w/OyRNP tf+9V68Prc2v/frORg6QjGf7rOiThiGKN7EFMKLC/uv4KXG6wbSN37/c+vfWoce+6+g+qBJoXet1 focNXHu1W7qGF7Efkmpj6tj8GZKvggqZhzuUPYimGFjCTCDFFUq4jjVC+0LiLjVSQSI8dCIaaYoM YM4MIX9qpY6iDBCIgwXQ2IhhBgmCxEZ0IahGaiIMIZzoRERERGWVTyeERO6crhediMyGJCjrG8pe dhSIXkHnajU7plO6lCOzVYIEmaGR0S1mC07zCM0dgSTzotEE2EPBe1BrRSwXCDOghNntGNNOzI4S L7ZP7T6aYIenbDTTCaWi3hMt1sTr7pVSNEMO6/0veW5Y+p3oERyns1pBNov2vf87xIzneNVYYbS3 tNTud5FEvwnbpemhQV08JshUQVow5h/3fg/bVXBhjTktemmu2gyOFfO8ldzse6va373TyW1O+Mvq kt/mjf0r7iP+tLQb+n71m0v//D0rsRghwb/IpZpQk6UG0/jP8ENh/sH6X3/WrXD94en/40ggR6tQ 4MzlR/+m9duPsKrfa2rtN232boM2xC42dSQUJUxRVfG9j8GbYxQ1E77aCxG2EmGrFCJU57XviLQt cbQtb0PixQhr2Nigwh4qIiGEIpiIiGELQYQjOiwgwhENRZRCEREREYiWYoy305NvzuDOz52XM5EQ jCKlnallTMk0d0RCI7tFdIrMi6P/K6XnbiFLBDscIdIue4TslH5/CDTOxxTUIdIuwmXzqj0ZFumR ryNx0EKnGrLojwJ3yuqVqiLddYVr66zQ8Kumuv0fyglZC1Fu0G6EfyHaSX6NmePNmp3dNo79NfSD 82UbNTvQIj/v928N0CI+i8erCbh90hJe/SH33XbbW3ryIaTpNe3XffdI0PRpuqtBA+jfV56b+nvv +v+DErYmXVXzQMdDil6X+RkQqILEVi4V+m+g/vWRMF8a9v7v9/+tfVof/b9fv1acNeH7d3aX97/v BFDy6BbOVf2e9Lem9SJgkHtrOhu57s8m1Sb1BDg2DhvP9D3rpte6nI59WutCIqMYiilAvGtr9IMO jduvGOLj/rbtsf7Yx4pW1+Gm9PWEt7SsMJMRzUnYrvkTB/TWliOccznApBWQW+f7DclqC0kxWscM KJ7WDNvzdnOpjxpimmg47pjzWUPmgp47Q0IiNf7oU+wn1YqO4iIiIhhBghERmRFoRaERBhYiLi1C EREWf4YUKIi0IiIiIiIjJvVFv2JkNZZBM6RSyKTLo7AjJYlO68hM7nncIwiVBCC5CZ2ozsSivN8r krL5S8oyMRhErHhbJlk+g04M78Q6BSCx0CmkCdkHJEqENQpIR5FV7Lo2inZLEXRiQZ2U5CZC9BwV fUKoQIj06Cqtkmu0aNH9hqkSkJSD/RgtBUDCBkp+IgzM00I0Z2dgddqn0CI+3uaBgEn7QIj7/035 TtG7NmkbMhAQ7/0XGSHoX2yIO0J3aVP7ujZzD1+smPCJxH68VpXvDDod0dzu957B/dNnNBB0bqNB r7o2Q88J5ua2Y91Wm/N9fjoGd9cf5LWx1t7Iq3Fv3FvBg0tz7LhI8aGu/r17d9980DBEmXCr7X/w w///h98Gqv/9g/+n99V+3dbj16/7/9/nPDDxjMKc/1Yc575jQwRO9nv+1oW9INM/0YKn0577wTI+ CX9it2CKH4UFmO2kbv9hfr7HO+976bW7S53kMbxnQLd0dAt/iu8kPgwrarEelvSURGhT472sR40t w+DH7EZVP4jz/C+nY0rYitc9IaHEVChqNqSkL1fraUjH2Keg04eSVoXaX4XP+ZUzV8eOZ3suEDOo G+gmc8GYRcXYqdGGhERB8GCEZqREehhBghDQMEKifU84jhhCLPtKiIhoRi0ItA4iIiM3IRERERiI lcVyjESL5N55MuWRUyUZ2lo7Iy+dchXGdzRBqyvCN5kaqzCOSyulx2XCkWyeO1C5BBQuCakcOfQX kOLM95QEJYEIas1svwZLmR4mkVaI5FCBORlBthgkyGLEZBxDgkdqaN3T+7s/EPVMlQmmtw62X9Bq na97kZl1noIYQdeezscIEHJD8JpJp3RqeldljgiPQwWkaKvoER92aDO72Ho082L0d9kraOPzQF/W RCtTx7VF83P7oERy0CI/6b7fhB22KhVaMOd1b1ek7vhhtU2k+/uGGr3Xz/ngHXb0jdQQcGH9NVVy uFRcKvH6u4MF71t69dX3gwxV6F/9kWi+XxTtvxwYP+8gljWGDE0i4WqS3rv19eQ//+K/3uP9v19f ww97rsG+qvhv2/7m1r3n/aznZ2IDH46r9p/66ggjadc+icMPqCJ3+gw7FDs8qB7HQ4efV4Sqfv3d cfYYS+rXtKv5nO+9bqpsoFbBhIigL19EXG7dbHMO7TsXXbhpthIIEexV7VY0qqxXgzBYaQsYW26x 2IphhRpwSWKwy1AjhcRQej9Hw0p/ZUmhsUEErrEbS3wwnadja2o2nain4wwpuOOg9Qt3/tj6HYSH XtcRERoMEMEIYQiDBAwhHERGgYTWGEIjP9oMIXZ/Q4tToiMRERGdERERERERGakRGWemIld8RluZ 5kq5C0dpBDsSRUIlZHaVnfo1iGSXSuS2fygKZEBSVChTUy+dmunaZOZBhCLmYM6hSDyVO1NRkEZf ITNI4RFaDINkeJYiOiPGpl8hEd0zIhl/qqdBOYJ19GjBp6dHStdGCBr+nIoMGrghGuSDQZNO1++j Tz5lxpAiP276Qb0abpGijX9AiP3mvRbtAiP36NfnsNdVtN10CI/+3oNna1boINNnut++tlBE3Cq8 PvXue+E6W/90PO+5uzvdGd+9d9/06boY1/o0i4XsVf9pt9d4/evM4uFenEEWnX0K/Qb3/fx/Q9// /5m/9x///v/7bX//9t/X+tq+57RwnwQ2p/3Ui111VScMPqjV/9ef7dpEUFb/s+n/bwq/9G6wwkJ1 CRf6SQ+2uwwlaSR0C19Vd030PsR4YNvpsL62xhCn0u7sUktntiMGYJ4pnCCmNUmUOW4TEdnqNY19 hUQmsaocaTDeo19YYSLcFMOd1HTjtCGEGuWOdOhqKYSTFDhghiExWxTuDNIYKtCIiLQh8GEIhhCM EwhaDCxEMIRkwgU/w0IacMKIjP8RERGbowQiIiIyb152amInRCInZZybDmoQZEGZA9M7nkZlLR2q mZFLMhmQqIgQrgildLwgyHHoiYLhE4DCDIXEHFKDEPP6mEfyUJMi2fgmaouyUo/mtkeNRhBkJGsz vovAgYQYSO3ZfKjWV1SuaIT6hB0XH1h/qqbhB6Lh9p4V0Gi3Z08Jp6osdo26bNQinq7pNoER554N lJ6bp5oNeZwf1vWn03oER7ud+aaLdwg+5pTQ1efnCDboER90n/08JvGrpun1Gtptv/7ntvT1T7r3 wg63/Toz9dJ8+q9Eh//X29X/yJMuEJwwa2k2IN33/q3r1/1/9P+ldd1fcX+jPcl66+/t//+nkMP6 obEfW3vp//v9/9W/v/6/7dt9QXXb/tfGbkjIhEUcO6IcCC3BDdv1dLCkcX0vptQRQ8ugu/6t11Pu f3+DQ4IVfDY21jtfe0WcP2ISN0M0FP7Y741Qpv7T7pCI7VK6rW/9f210wwk2HYrYqr+EGmGEoJ3c XDLLA3YYSaSkY5Q4URxqRXQ2FGrFrDCthc/xpeoPNzldV2KfanRaHHEWNBe+007FNYNCLTSSGDOM 7FFAYYqNj2MX+DCEQwhEMIRYTiIiIiwhFoMIRk3KHBEexaDCQIj7CUMIYQjERERERghFxEWciM3R GWRUibrcdMRFRE7EuVwtHc47L+SjJMyER3xnYrko9TuaOyvOy8TAQymKRAm8ujNHY4Q7BmElPoJl ECDJTH0EzukahFPZ2CmEoMqumd0yPl46RHQWQxqiURVxfISQYSJ4yyqXz/Saaqlpot3SdKi4Z24i 1qk2Su89hCKQj0YKR/C+jc5qyOQ/67vNmeBC+g+jXvpsKjZvncQiDPv+pv1626Qer9b/pNLT6V9X 9OS7nc7qmn1aDe78/0bnoKz6vne695/r39/jtN1T303r/t43kQzvrpkUT9+27nf7QQTFv/k4Yp4x O1Rlwn1Yj6zeh3tt9gr//x2g6c2l+wRQ8cbTEJVD19f9bEe2cvVXW7Cof/22e1g2H6YIncFI+CoR /BhAj2jBQ3+dHWdORdqim7cGZzvjiOZyhwRH7piKmHMPtQ19Ic2XuIwSdCK1Ouk2l1+u8fj3Bn/i 6+I3YUNULthIdj6ck87/0C5xyxwp/k0ChCgdDs9z/iK18/1/2ubsw5VlPrYofin5s+IzDlQUOUPr Gh+FQrH7/NTGI8RERaaEREQYQiDCEMIREWhEWmtxGcIfYGY+xcMIWmmsYiIiIiIiLTzchERGfsmw OMoR2poyqQi0Ij1O7RhHVm9MqjNcb0yBGVRErRkl5HR6KminjqjTEraOyTMq6V0ugyqxWwXCdt3D CDuyjkMVBqdEfggyPHZdmDIXEHRbkFSYQcHZ2BMjxK0R0FOmRqCBkHIOVyUSGSwJQX3hot+2gejR 09LVMlQtPZKQqLHfq4IRqf9Fjs6GmjDukdgRpT2fMER+4VzODhNwuDm8JIN+8ER96niF4TfCDcJt AiP9OroIO0gRHkg3RJ4bnHPEUm63V2m1feeCKLIJV76TeQWpW5xzP0nRvpPuQvrufn603VPT53ts iiS2/S/xBum/z5CEF5EmXCf93VavmjLhPofXCpfvbmkXC+vrf8Lt6//pa/h0v1/Wv/29f+/v3HbX 1/+v4RPN+/erqQ4ErrXEIEf7xn+Thja//9qburZ9dPv62hXP19/fMf87CD3+1fq6iE63WEt1vq9R bSSfxrbSQadrrV9JJivaxS2v2+F8bFRGxwoasdocVWDMEEVGF7XuGpFAXbShhIWNSUBZu+2lpRr4 4WLTQaYUExTV7Q7u17FPTFKxsUxUJ3a4oNXHFocNBhMIXDCENTogwhoGCGELQiDCZyEwgYQYU42h aDQiiIPiIiIiIiIiIiIiIiIjORlmleT5kSxBTO0+UMqiIWhGTZ0YRVo7W86xvJajCIwzqyW52ZMx IZCIhMipyIBFHqoRFDOkZVYyBo7W1K6rBOGmdqYiqE7CaDkH1PBtCE293TOoiyD1HHOPgiFkRDWE EH2QSQZCR0zurOumdheno/r67a80OeOoTCfcn91giOp/YQj+0FovuXz/DCE4/U9EzrXVfoER96Rs wnQIj9pOto3rgiPTe6cMP0XehP2EvMGjHMcERx5c0E3/BzDpv/9bXfXfQf0t6bpzE6CqnSD1YbdY T+IIknN3oxPpNeY91+eHTvv7trHb+8zDGP16/4hJfq/BhiaAvjGdWgVe15dEerYVNdf4g2vmkXCt 5LZ9iVtYM0jO9ar///3CC/66X6BEKaMW/eIjrNq6/b//Xvvw10N/nRs933q6xGgj26XfeEpyLZ7n pBEY4MEeySvYQYVO++1+IzpglTW8/UKgwRQ9Sf7Lr269xtq/V+CXGrDCtqECPdrHtoEaHhhmpF0F iNnP1WI4w8VaePq2hFISLsKBEcs/2Ir9iojYYSl2YfG6sQooJLWvsINYTCEVMOccoevEfhn/BRGv NzB2un+0NTDlRhNRTCFpWFTQajF5nOPktmBUKhE4na2UjM5X/gtp3xBnTnI08aBhDCEOIMEDCEWc 8REcYQh+Rgyt4STmPEWhEX2c8aFrEXeIiIiLzniIYIjqfYlERFoREREZZQNiIiIlKhKzjK5lk0Zi KhBAyuTM7RkHlLM7G8kep3kS8djbK5g5XCwxbnUIdreQcETHZqR/KMozv4kBEGdmoU6BFKtl+M+w kdqIKCDCBndJM7PHTOyQ7rVqdqYR4Izk71dNGjS59LumkE4SLHyx52ah0YdnY4XP+D5oNChPNlLV //RptJtGzNedDQIj9zQaKM4hQRHHQbQQbpINpawXapvvcgrnc7+vf9J6d26D/W9P7VNJOlc3achX N2/MPik/tN/tmkXC9vxlbi4WrJa+6f4/1beqVhU3TtNrabtu//+h/+/f9f4fjjf/WPm15v18d+x7 Xaf96v+M/9ScMTohpG/dQ7r5nOOUOUP/v2k//tfox1ofrvtToFH/0Krx9hhQ26k0CkMLQiP6TrYT XVbp6W/aVb+2FYpLY/bZQ5rC1dWKKrxSVbsR2sRxG2sNSaBWNROoSbsR2KaluVsl486I47i4YIWp blJzOUOFJKExXsUxVIdO/aEREMIRFoREQYTCGEI4MJhToTKRaYTKCEVzj5xtToUTsGhERBAhZRuU GRERHZU0cI7Lo7qjsCHalGW6qjsNENCfxIHkUpNv8E9UDCDOxOO56xkHncZfOxPtNQuprPyHFoPl 8/pk+dUi8ZDZyOzXzscSQ5pOnYTb5DBmMFs+gUIP3BOvo14YThBwm3ukw5Pq6/uETHxDCJj5o+ej zD/6DbBgktzw8gt6MOd6NhTsGG+8770bwprNEEnsEnSblutRgJt//+GIRBFWrffkE67xDkE2GPkt 187VrcIKnwibxnOwibxp+u+1t6rgwSB7026+g/fuGG34dbneM0Bc75iEipPt0F7oLX88FP/9iPxh /t76w//h+sP+Hw0FDXH7u9+OL66q7q3G2xtE4YYf7VQwQI5k4PDb0ocyLDCCPTBvUZhVUZhX/FKI wz9tIN8NxaB+8VBwgvD+r+2Eqe1nd2Kzw71+ax+7GdhqazxdwZ9zsZrIQhnTKUmIo7DTWdkaGVTt cGMlZYY2KjtTojtC0LQdrFr8WhHFsWKcH8HaiIiIiIiIjNZUREZzoGEIcRDhgrQhzsSQiLuMtzKL JyEUxE6LZkqZ2a5kpanfx3PIUkjsTR3TITOwJGEg7B6n8yGjCDOoU7NQh2OIaI6o6ZHIpZhIKduI dPCdyK1FlB+tIER7VJBhNCro7SBF9bZCtRVZ4DOxLIVb53/ChPP0gtP9Eh7BgkpCtGgQlRu9oER9 ztYOIbTU0jAQgnbw/ve8UZ7hiFO53p1RJoqTnc76fc7+rwlfvWG2uvj/9gwS7f0g/3Ih4+mvhApb meCW1zOU+Gh+lV9vuL/+b4f9w/V396hBNONC8Naf1as3f/v/D/2G2ewQqvwZNqKrEIR8Hm6MYU6B Rj//GIw423TaHjep2pLwT404aWF8Vx2Va4xsGbYmIqK0OOLz7mf4uLU50LXPippAtCIiIiIiI0Lg wTM1EsTIxluU5NgiETsYhqTb9SDR2PKRZnZVnYyNI7EaakHDLdbDB2kZKpTodpmuPMi5EHkJhUyk iZBggtH5B525Enhc7UZGuoQaaVWnhB6n9T+CzjsiGml0RMdguaDhmsQKSDCUghB+eW6OxHLHoQq0 aHzxnOfSrqESeoek5nvJ+7tBdo0NQRMeqV/hT87QQbRoVOQrpzfSt/b+FerMdTxhTZUGDfDaC3SD ovIK6NAhM0Gdq5aglxSsjMhVVe12n63T++24Rdx3v8iMasiUYNW6FiEdUeRHWNcJwibxqknd9/w4 f30cX/u9rHa2qX9foNX0KBhi0gwQj28SIcJ+iTiCuv8fw4f/rdf9vWhocP1/4f8w7yLEQTc5+TvW 4afub4O+/91Dbu6/dWojYcc56qwRHGX4jitt1Gj+CBHFD3UZ/oHdOe2DYo2vWHB/ZwMbUHB41iOG Eh2K9n6z9UPq4UG4aWoQV8R/uqG6M7WIw4e6qrFCL1sVOiGC/f8GNnPaxYrwmRxs4X8MokFWVfgx 5J5CtjEGZqGTQ8x7CERkhqLiHERDTQvGM544tTdFoPNSI08RERxEOIjM5Q5xyh4iIMIREHFoGFUm 35XAsXMhJUIi44iNVOyTEmecOyN4iNSGMquQxnfxfChAyMi+FU1xVKGazI7Umcdjcd1ojMwijPx2 oRnFTyEyny/JsOKEGSwQIGnYKmF1BwgyVhIaEVIOgzk9mqP50ZHMlOmE08INMIPNQgXhEnozmdhU Ttq4IlFF37hOaaasocOZ7ev1e6vot3oz9VuCik23MOcdQQOjPwowm0d70YPWfHP8Qw6mzNZ41PDv 0Z/zvvhPpPo2UCI+9F3p3rbXrsIu//kE7/V1ENmENN03f79VfaW9/1ZE0bS0NfS/13q//9fQe1u+ 8X6//f///7+mh/+H2tv9/1D/f4dV/4Rbr//0P6/1bb7br//BEcZfbS/2wlfzuMx2vqw7tV+GbiGM Pa+8V8eCFX7cU3GM/7PfroPsf3sU3rtq2lfQPEbFhY69JtfCz/aVX6jYpeO/2DGwTWxsJiKwY42I x6pYK2Nihar9SUcRQYQYT+xFWg4iLQsIQdhBhTHi0z/qmqHfF9oRHn61EOIuIiIiIiIiIjQiIjdx iZC8JUkd3kHFVRZClF2V61LdbyKoheQxhBneRfUEGEGpL53EQJEri+dMk4vnc86I/Hf51z+SjKgK dhI7mzEVCToigbwgaLHYXNQRNMlQh0YT1C8gmnOxwieTTvWQQgIhhZBzm8wvdOQw1FXfRO2gg6t6 NjRsa9+va2uu98OYY20+rfuvBA/c79H/T06N2FO/53tzYd2jvefla94Vmgz8+kajlwZ2gRHfT88w olOGCJhhbIJ0/+JBP/odKyW+dQx/W/5LdRbQIjr70nbbTp4TukG/s0S4SlutpV9B+v8P//0H/+3/ w8GIQkFvBiUWJviuyCXfTb9JlwohBURpzHzHvsO8xv/D/7Pr6YfMf/9/w34Pqv/0Hv7f/hBHFt+n tKG6X6wzdDbVtJhrHw//XX9YdnM0BeGeDBOGP0ZO0mHr262oz/CCv3+xQPDCrfUYe0rVDaCg+9xp XTV9A8Xh2ltXphmBt3Ww2NtdQksd32hQjYjUTgYJwxtY/TFMYsRisyJVEDOnMixQwzCI8xCJKmMX eK3jiI5qWwmf93P8RcRDTCYU3JoR2heIwwhp3DCH4jORERnIzIiIiIiIiIYLEGCERGdGIiI5lRGU IZ5oRGTeiMi1ECzsDEJWzshQzsUiIEESviqd65B6YIMqUQeFCZCZKdUyMFKpBBhSL5Gs6ZC8hUVn KfMI7PkJk0ZiTk2EGXPP5QZ6Iuwgygwg2QQNkqCHQJMFFuGdGEHabBhB6cwLP/n9T+Q2XeeyVCBO yeKp5qEJEYfk4L0L9PjpO58qtU8Tj/ZTtFuZ7o2OtbVddOtV5GFdQhe3WeDXvnh88Hdwp7zWZ2to 3Kbuf0nni9hIQw4Ttrvn/6ffqd96N2d9wfaNmYcm7hPPZ80u31bfX+yW9O9PQ0LHV62G4Jhl9bsi cXC1x25pmxL7elt+nXeeAfpCk034pN9+Gu39Ovw1v+9f6wxUbu//tqmFb9eu/Gvz5f0//7XQ9v/0 qg3797mgorf9YInCtfngp/zDlDlFY+Rj0OP6Q//Bvp//+/W2xxpP99Va2c7N1C9R5EwXIY3bCWKi 9rQiozd1j9s9XriRMMWe7Wr/xHP+3aWMKD2rtpRZmC+f7VpeFcVuraWfU3fn7N1pZ/oU/W8baDVs La2Tde7tKGlFjGNeNimlnIULDVVxxb9Wr1uv8R2DMXsTjimKYqIji0IjsIMKbsyO0IiNYiLQaxca HdxaHn+wupuhoMJhNREREREZ+iIiM9lDxEREREREREREMLjQuMm5EW50JXMIRO0mdiaMleZH5NjG EGd2yPlPklyEyEyVxfsk4vkFyMZHiFZCaZGs6ZU4vkJhAyWxfITCBlUR0zuayEzsciTScmwgwg0W O1tSFCGoTC8g5HJQwg1yVCmoQp8vsggjn8LnS0wudAoTWQTQjFhqaiQacHQtBBtXwkuvrfq4VTQM X699o11vmt8M93uaac0XYdGg16dGfbyQ9GHO6533Nh4c73hTu0Z9zjmHow53XNh3fboER9/pud7z ZSfZrPD0a3PB89o1tJvIxybZ/f1voz3S2zSMBF3r/9XrdWnrbl4d9bnAw/X77/09X1f04q5OjyWq enIaUMOg6p+/X9v/Wv2//r/pb/Df962v9fr4/kSZHCq7/1aYIft9mYLyK1Ath269fX+/87nff/f/ peldv+w9/5sKuh/6//fVdf97/69YRMfh41a3+//Y4u+uv6se3W7/2GMevF/1BCtX17xn/f/VqKN/ v+ZE6YQQeTajbVtJjVf+6+9K6aY0qWLX1tuntf5/31VpX0dAra+68WrpPxpWvxC4/GxXsex1sRTG MbWxXFNRh2KFr9iMGYINiOoruKHSitfYqlhcaDCacaGh2mEGEIsIXFoWhx2E7TU5NDTjtC400Lwr iIiIiIiIiIiIiIiIMEIYQiDCEWpZhbmQmhERk2/Ox0czs1i3qCHc0mScdiyOmd150wUt1sMBNSni /lWyPEKyDyEypZCZB6R0ipoJkHwwgyMi+QqVBklyRl0sMgsRtHdMg87nlRuu2FuDXIvWdGEzqwmS i86dowOegh7DRY7XzoFkQrPzBCORStH8iEmdjiHTsmnedIuYc0Fj6dXhq+8XSfer10vKcNINhW3S Z3Bryx8w4PzqEVffu7UIHrnfz2DRn2/O541PH99s9vo3rEGHCed+s3RD7sJnyIe/Ru7/wkZ8Vvv8 Q9ev//uZxgJ8d+JOGGGR//yJhjwQXirgl6MOeNC/2aJevT9f////tev9r6H3+otoKurgm+v/6QZH C/7X/yL4S+tf/015/6owMbn1OiETj1/M5J+9/3H7d/9f/7X1iFfghUVxqCFD5OD/DCa5NBva7rQu oMmKDvBg1tvc9AhlKDAz/j7aTFMaUJjWnCtLXtOe5/ofwttW1q1IYchrptI6fP/9Ckq+lsU0xUEx QMyhdYMwPgzhQ/2tBWxUR1wohAzKBUV7x4M25nCdpbQYTVNOLCFqh/F5uQu1TCDCF5i4LqSBOLU3 XxxqIi4iIiIzdERERERFn2GFBCIiNCIxFxERk2jNaP52fOzVFbRKUdi0QViQmdg0fzu2djeVxJHY moIGCdkElIV2FIiTIVlXF8IMJkgMEqZfITCDshUgyoyFQQMhMhSKvIPJTEaic0ypohModkpyN9Fj t8lDTNQQlIinolAQ6NOj+p7W0Z2i3DVfpslFaLHZ17JQEU69koYQZqEOm3ns1BNsFOgXvP50CnRk c9B4TdJqvS0n/auk9PNBb1vp7dBB91Rra9Kv1rWSkJVN/xdJvep4z/Rhzvfn/U8b30CL/TpNjCDz vfq0/v5u03vU8NG73ejdhN6N2nvn5TueOnX/Ua3vUf376X26dbXzQMbsER96f6FXf/offx3R3O97 Xf2//1/b/d//e39f/X+uuw///9L/76/3p676/9ra/V+6G/6GhW/qX7W99Zkelf1Mev+tr31Hev2P 6GP/6eo+GR0R67+Gbor1v20t6evr7XY26U4GIZudTQMPW2cycMK2crr/bX48tQTVtYatBYj3Wf8e Fn/NzYtYa8NbWNfbSbeGF2iJgvaVRqhtT/jdbbyGFtKfp0CtKNimKa94r1DX9bFIRsUxQYprY90I wZyuxR12lwZwvrFPFJMUrpUtoNCM/xaF5viwhxdhK000OGEI/Me1jU//5utDs4NNbOBqIiIiIiIi zoiIiM5ERERERcRETVDQMEIiMmwhiJkTMROzGIiMmztTtPkoRSMgsdqUdl0QnnZEUiJZKV6zOwMz soUIOESSLx1SphMIMjIvlPF8qXIYrM5wuThglGbio4IqmEGmEGakka4vlSyV5hFTRULIXFQPK2in MEDzDuguh56RbhosdhbWyVCa2SgItp/n9Fjs1BEwQYSXU0ifCpksRHQUp0R0nBZ7TggpIDp0g9lz V6+nQQb3CuEpvq9szlv0/MPWg3o2dJbf1cEIwQiurRcc2iFBERYc0aTdZjnfz96SenR4fPHkh+gS O/RuUKEHqeP5ivSdG7Vo0CEjvdfQIv66mGbV1TegZjSni6Qb0+wvu9tvq/1vT53TtBL+hFbXzOLh et3rod6rvIojh9kdgih9Lc7nijDni+m/T3Szud6/X//8e+9f661tsQgv+n//eoa9/+bXWEwhxEe/ /Xe13/TT+3/++7XqtD9/r//QR7/bPq1dLef/qh9X/V/6MPmH/Xt+/1H//9V/dKI7dTqwXerX1/fw l26kUSDBeo1H4j7Wzda9ruo5/cn7r/tviLXWI/u9b9rsRQQ5/2raTHTFr+ENiKQi210vtG62sbaU R2teu6a22v/P+/+ojdbFMpF2C9io2OK49pEh7FBhY86E7sVx7Ebr7EVxTxzn9sVMfsfFWhFhTrVh BhMINC1NS0wRRsIRxEdhT/DCnPaFxehxacXpoRfmpaiIiIidEItBxERERERERERBhCIiDBCIiMt0 rIpkKyhHdMoRS9MROxKOxrEqiExkJ0QiSqZUxcJkURHR/s0shWdiaI+kRZku7IsyIR3QUi+VTIJn dMnkyCJVInE+S12QcM2SLS4QcUhDuOHIOc42YXFqmmREEkwQMjEUJBkhSEgoXDRFHMLnQc41CarG g8/sJhBBNBSCCxfZJ7V8HaIowuA6JMWeGjOwmkjO6TTReNEacWmahsQcbRIMIIi4ISDSIZpZoN+l BEccERx3TbnuE7J/mcHMOVa9GdwRPBEnrdOjDiElwRP7wg9zOVFGhqjDmjyfu6RFuqCTQTJ/sjXo wNJhJNM9HThh6uDD2gw6GE8Kn8FGnMXZjoNbm9rrW6oYVOb3cUFNZ7hh6M4hTx0aBSNAoMPyMXFF 12thJP4YY1hgxE0eEh+1MIIodIu/6/1Xp8fi4QXqOk1uGG1TX/XQYbiv6zf5vv8P74hBGpKtMRH/ 719HF/H05OhCC9xCCFRBhj6v01TQbG+yMN/X/63qEkEewiKn18PtP7/Tu15oKcp96IwYR7/MyCCO bpbRuf/N/m/Oh5HyPgst1uPFqrYVWtDIZnJ1CBHMngQQIJd1Wc7RnGX4jQj01iNnPxF47BLiOGEF kUlN4JG/X19V9QQRvQcRHe4jQjEFtKoaQILwgkPil6w3fxFa/9KRxd1MILEaBLEUhHEcRhBf4rwS ZzpDYpDiCxdVLp3Bip0Wc+50evm4p4xzoihHYSSv8JAozHlqCSoiVGPZz2qfa4KZynKiNMWIhxER nOhGRjdoXmg45Q8Rlj5jpC5z2c+amamOsbPIsOeM1NNCLQ7iLQiLQiHaKEIsw+mhERaGZyQ96jTt NYiLiIiNFCERaFxEtQUURERERERlcy5XJPrfctlV/p2vprwQp+MGYBVaeJAVKFHK4XFtP8vnr0v9 /+5bJSyOE3qh2IqYct+6E9wZu/3+1jxEeVzPLZJOV1lEdBS2QVhYQikOqVGc7zLAIKyBBWgYOxgM HdYEFZAg7rAg7qBg7TgudiMj5jL52Xy6I7I7Oy5F2R0R1O53/b9NO9U0GEIiDiIgwhEX7f+fSjaO bTNhVlPn0U+jmDzYccq8znHLHKH/M/+/rv/Qjrf74i9CIh5tHPo86f/9/qv3/a//pf//GIiIiIiI iIiIiItCI7HFoRqI8rkmZE87ojvI7FkdiSO7Z2TFK8I7V59nYTPHU/6ZSzCaZ2XOGUpBBhBnYRlz OwjCBqE9M7EH19CCI86esztE8YQtC9Gh6NDh3fqeAm9Gh+gg8EHnguKM5d+n6eZyTVLLzKwwUoML 52XDFN/2re1e9v9/QYO2v+67b/+u9U9//YMOhzHzHe1zcVHb+91f/Vu9u/B/77iri9sVfUNLTWx7 imIqho3X77q1YbcascRTdMU1ff6d1fd2qYTJutQYQYVxxERFoRENCIiLWIvERERyuSDLIKozUIMy OM7cQyE44SYQM7pHY0i3EoyM88zIE6LxggYTO/y/p0nnYgoZ2Yy+djDOxIKdq2f1CDMhTvTovqLc zspYL0jX0a7rnYwMQwmmvNHek8INwnb7q+tZ7DdZ3I9qzUaM7fSb/3vtuy8O9/vsrYLq+y8O/Bg6 em9//Tr/t/be917D2/wYa+GHdv/9+1sMPf6t1Zz39vfB/+m9dccMKxWxixFMRX2GMMY4trYY24oy Ggx2KrDtNXtuH2SHTbxTWRRynhggYUIODBC/u8NircGEDO03nREREREXHBl7A048RERERkB0CUs0 LQyusRkEzuiJtqIdiudpI7CR5lkTxf+md3l87BmXM7BkRyTwg8IM7Ls7E2YZ2oZc1v+UoMIXFo0H d52n0WO6RcUGhaFr/1ng10aDXSbDfcIPcK5hyPZMzlw0Zy4oECvzI4YKUC7Lw71e67rzsYC+t+9A wdNPTV0v+m/r+v793btcGD/Xf/zHzHhve1+6bXZ0f9+wa////vbGL9WqxX+qsOKxtNXVfXv3h4jY jfb40mK2LWIpt0v/Qdk3CZcBCPvgy9q2wQIUybqI+IiIiIiIjQuGEGCBphNRERERHlcyyziGdjUd iWdiSK/KVyTsyDy+d5l87vL52B5fOwLI8d3l9BhBggwQM7AhggdcysMFKBcrYLnYgFzsYC5WwXO0 8jQzsRosdnYjTOxEmdg9M7Eafdf/6dYQfRs8+Pnx3Pm+y8O7l4Yey8O+Tsz5eHey8OP1vVvq/f39 v4b6DDa2/Dvhtt29933/f//X6sPFuxDDxYfTB4sPH//+v/35XUgcMYY2MMYhjDHqvr2t//693Dhw 4eNKNKNKLWLWOoM0gcGg7hoNNb/tJUk63ERERFoaGhxxrQiIiMSAqUqTfI/HZrnsmcfzsmj+dhGc iZs9nYTP52N52Jo7E0diiGV1mL8PBbTsE7VtbCDs7EFZ2XNM7BmmdhDTOwbPVem63b+tradr+m9v 6twnpuFsJum6bq6bYTdcJ6boEXXt0+3vTq9PT703V0+k//XX/110vffsyKV6/+q/6//1VdaQf/XW /9bV9+991+H/tK0m1dbS6tbXXq0nVh70mGkw+0rSYasMLaVpNpQ1b4aQPYjYpimKYpigxQYoMUxT FRTGNoNBhBoNAwgwgwmmg0GgwoiIiIiIgz7FCtiQKTfDO8M75nY0Z2Bmd4Z2Bs7A2dgbOxJCdmMT tJDrX9ewgcHDlcz4UFChQUKEgoUKoRkCcrrAn1XW9VCSz/XLnmDzB5h5h5g8uamHmHm0R1m6jb+j dVzF0b7zH2XvMV0YvMepj7MeEMxYU3tqY79C7XtLtdtPtdNe17Xte1q0qtb/Xr/fqv/3dr2va96d 62u126+vqvrYT7TVU10/T//3T0O57QjiOI4jiOI4jiOI4jiNCPocmO/5Y5x8kOcf/d8/+wihToU5 GdGEJ5Tos58x86Mx1OdM5/0b4iIiIiIiIiIiIiIiI9oRiZJI7+O552J52Nx3POxvOxvOxLOxLOxR HYl11XVVW01lckjLVpEzYSJpKdq9TsGwkTSCR2EanYOU7UJUjsmkjtWlMhaL+j+mkmkE0EEwgk0g mkoQSaCBBpHYQwkCYSBNJb+jOISM4hQRHGgRHGjOIU7iEgQIUhVoJNJNJNBK+9JraSaSYVNK1UJG hI0Cp4EKexCngUjv7/VVtbXXSvsLra62v970c9zf0b6zfub6c39HE+cVNG0tdLRxf0P0v6////1X X783ebvX/4JrYIoetqtqsR2ChXVX1136+v/6N+IuIjiOI+I0I4jiOI4jiNvX8mOcfIx/y3KcofLw 4+Rj1074irXBCcU6M6M6MIRDwhdnPmPnRmOpz5jwwoiIiIiIiIiIiIiIiIiPK6zF8tkk62ZXnTKz nXKznTO06Oud1Z1ysZ1zurOmd1I653WivyNSO60akZDXdX79df/XT1Oud1R07TTXctIoVAi//r9+ tr////46+Kjjjjjjjjy5F0nIO+QsFD++l+/7/ERUbEfX8RZWxUococpysCERO1COIMoc45Q5TlDl DhNMhBzjhTjnHOOCI6174iIiIiIiIiIiIiIiJkYB9qr2IoGdpu1xHKZJVK5mgsrkmmWyCBO/9G77 ofWWkFL9jBDs3ajhmbJJvP+4jHK5nlsknK6wJ16N30JbJRGAn13zwU+2cxxeh//z/HiIymSl5Cjl NJKK6nk/MOIf88VekviXLHBXh5zwRWA66YYP+C34qIyTTdlNPh/////yyiaj//////////////// ////////////////////+WqTUf////////////////////////////////IDoH3j/ggvH///kB0q /4///////kB0b4//+QHRVR///IDpWo//////////////////////yA6JfjK6wLCdF8HhOWxVUnK6 kyuYjv3Z2nAj2w4OH3uocOHz6dq2HDtb2KK6zlcDzueL8MIRERjymNSluOibJUdzM7mz1naQ6cOD TyzqWE+GHow787GU9vTDZW6INuWcW+leV1QFyuWkdpUGGKt/9N6BA4YMMmc7f/rmPCJWHDDDkXcW +P6vaBA22GHw2Ph374Qc7W4MNn3RujHxr6ERaFp3w1URER8RiOWRWjCMheO9UZFmTcUUrrAoTs6x dnZIQIGdxpkzjEdmBC37Mi6Clvpwg1tU0wn4QhrghrRfNHftTuzst57c9nh7ozlxRs6vQQf399XS bv6auhyYpurq1+l+r9/99boS3NQX/+tf/////un1vr+1spQY9bPb7Z9M6NtfpjWLpiuohpR7Vr9i ojaXVrJpsmOPUTsFDFrYQaHDKHBEdUI4aDBT91d4hlG40haZ0RGIiI5ZleXzs1I7GjLQn5bmuV0k dIuztSCHUIFwgwgzITR6OxuIRHaVGQGGDsbpXJDvVMJpraBEemiudqJyQaZ2p7/T9qd3NNo02gRH 3RrtpN71ab/PBrvRofXuk6T16W9P36ND+xp/tuVwwXS+rq/3tv/3pv3WztOC+m+rS///r/r9u9a/ t86L63V1v2v4IYJkfBLboECy6CV7Ojtj7jphhWGFtVY1bWojtjiI3rWw39pWKYpiKYTxTKHNsCJD mHCYbwoYW+7jjsJgmhFoaBoRdwZ5AgppqLQiIgwQMLxD4YQjEREREcsgGiMRhFcayzEtSyCJMJ2Z DI7HEO552NRkJZhnZhkeIYh2Z5kLC9VztYy+dQi+mqunrtUd9nZaC6SN3eoIvo79G8PRbgiP269+ dzvoSaLWkv7SfQQvBiC/ZuKiu3ndhg7TxcL9pfTnYIy4Sh1+w/f//69/1uWSoMeoYdj/Z7mPGf// pe1P9z3v6Y/43/j2/YYUfg1zHsRh+P/2gsRTFeh2mmg07U/3ccNbsJ+W+IgwQi0IiIiIYQiLCM1E REcshdmM1Z2ZI152RmSnlvojJHK6Wi77U+k1LozWfzIS7MirO0ghIEkcgo+yZbnaS0CHT6fVp/5k JiJBODMhYRbrVv//7qiY+bw57aoER98/1e3/e/0Yc7pAgdJx0Yc76+o+69+3/W3Q04IuQut/7vxW xHH/99//+zy1C+pkBBj7c99Bg7dv/acNKbngzdn+1d8GrDVt7W9LGxX7v4M8iq6SGxR2qYX9iOoa af+vajmHKHbCiCGKas/xERERERDCoTiGXILQMKIiIwhGJ3TluOiuYR0iuJZfJkz0diaO/R2rjedk 0djFleOV1pEfTTkE2pkqj2bd787MIjoKTRWumfRCIlMmg5DtJYQj2GmCYTXpsEI0771JBp/Dh5h0 8uDOzsp57cECE7tAgV6dL6f028KZaOW5buke1hO+r009X/O53u9W+jQ6vDDhB37ZXIZcL/1aT3rf ft/99N4YlSLkWRL+O9f+//Vdf/1DC7dhpe/ije/+1bWt//ylA96HttEVyOlBE7/yulIL9/HVpq2q w1/21mHMPti0IkSR091wQp1jHViKiKYrYwZtiQqhbYbyKPQLbCjoXaDKhUzQE0Ghp2unanIwuKzr rJTcoBDQiIhxF8GFEREREZXVYsoEZ2KZi0VxrKsjskZLx3p0EMyK0diSO3RkXXz+gzsKCgiE25+c JI7NYuanaRppn0dmspXRZDrl6o10RR4XdTan3Our6dH9T0ZJQTD/bnuG57PD9wgzH1O70d/976Wa m3p0m21bb72uGbvf+3/vnc79Nuq/9f1tbGvndbI4VLdvb3c7yJdrt74p+9u9v+9J/r/vtYYWGw3/ 4T1bXbVQQ0I59zpKM//UIaGhUHD/tc3bqKWK0n469vqYdQRH0Ycw7dv+J7CXsbWGqOzXnPkY5tmq X4is9T+8XOzxB/HjadoREehjHHevp8RF9CIYJxmHiIYIREREMFERO6+j+I8Rk2S0diCITK4vqdhM 7rR2No7E0asqjMgaMls5NiQTz+dhUYMpyO7EJkYSz+mdhFZ2rV4QZ3bI8du7ThZ0Fa1CGmqaXnZq IunqepnYSdeeHmxafzDlwyento3Z4EK9fr9IPegRH7VzfSH7dJ29J6HafRnKj32/Vo8brc7+JerU tIKXinWt67+r+733bpJ/f9b9y0hbh+0Pr99c3ob766w7v//v/2rZznPWxXbVs9v/+CFAhQQr/X9r iMRxfzdeo0kOI5//1zD21b69Joeu79r//xgzbGzOU4WerSjViMZj83KSCJ3xqf8547tVQi1sUxTT VRHERERERERHEQwgwgwhGIiIyyKiJuhFkKc7OzrybJaBBnaTBBnY7MZ2JI7FEdmsoIPppyCCxoLS zHPITfdnaQU1svyPYZzQNFu/o1uHhfmvT4VeDOx/YaCBuQ+y59TtIkqnZoNGp4fpWQaq+a6O/ZVh 9ozg6eHfJsFL7p7/zmtOg99IP7Y17TZBytz06wmXCek3/xH+udpwwd9UK+CL3dxDaf7cfXox+/8w 5GP/f4d1/rXXu1Gbv9669C9r2qMjDc/t6gyZkKJpAk1fqPu13V4pb26G0vbivpvYhNRjWuI4NIWl +MMU+do1jUlECUk5Q4SCHKco1sUNCLTQ4zOU9ioggaEYKY9KM6IMIREWhEMKXv7iLKag2IiIsIRE tTVSbK4R2dpeXztKyUMxFcpyTGVVHY3nc0S1nZojuHhhc7VRN8vn8INM7CBDs1VlGT4QZKkfzuGF CDw1tatfT1TvtFu07CHNDIzL8mwGaO90btP/PZ481/6hBv5Y9JzQF4MMwv8Tozd5lUv0m2yJroPv /7oED02+P/VfQb//DLhH/jV68V5eHfC//+w4jvvxuv//w38mxNBF99Wzm09rDdsLije8EKnPdQQ2 z6dWHjQrvqLEW0g2DP9ivU7Bhf7qoYLdBjwWxGlFD7Cp+gZhnKAdlDmtIbDV9bU3Q0+Ii82/XqOM w5h7FB7QiIiIi04jMd1QhwwhiI04iIy1RLJ8UpNlPP52JZCZ2JZ2SZfMizOhFU0M7NcqQh2lo7NY 3ybE4u7s7UBDUJk8RDC2UoZ2JCAgyVLdT6UlbL52OQW7JASqeqroHa+qLHMO7uT/poyl0OnTtTu7 WbqN3gww0CBX0bqCcOuGH/oER+5hyh9WjTdd20CI6oUhOya57Bhh1eNDTbbuGG77ZyrehB96b14M Qh3OzDCHmZBg9b//BsbqNf9dXIIyXul//hwYf0Uodt96rHVeLb79w8aROGIZus5DP/EMPa9z3YXI mDhI2lRgp+uusHB3WztOC8f4YbeuhxXhAlm676R27C3TDSd9c6P9ww3EUytisMKiUYSXvPcRhCmO KJJkHxxGY+fo1tNDP8R42uLake+CDCEYiIiIiIiMseIqDCna9cIn5uiJa5qpZo0hERGTZUzswRG8 7EkdpWdmrs7CxlVRklZ3md1MyB5B8mxOLtT/qdqOyURcztxOzsZE+EGmZFUp9Gtl+QxscM7Hi7IY Qggp1EqnrOg4Tf6wn9FjmHeZCYmq+i3faYVO1O7f/q9Hho3Vv0EHD69oER+5/ChPoER5Gm0XlF4t b3+ToxF0F3r6GncuYWrbJQqncp71W+krdU9Nwuhqu3xpxH//8R/kTBdd718Qgqf9Xx91oV845n6/ t2sixtbqk24/wgv//f6rOiOOCFa6nt6Rj2150O31fUII/2ultq2e89WNKbn+9RSlbBeGF1Yr9/mg p/0krpRq2EkM0DFrf/UGYLS7FO7Cr+OhtiNDhq0lFfHHkhvQtM6IYQiIi7tPVKxQ4YU2ZjuI4iIi IiwhEGCZ0QwhGEIjERERGTYaRZuqggyMIrjWSzL53TO55kVR2nz8mVZGuN52Fs9GQqzHQaDOxgzt bCnRl2Fzs11ztZiLhVCDkUY7u87pEhGmQq7o10a99Jre/pOjRg0aHT03hA1JUJT6em+bNIz0CBX/ O/3m71Z3zoPVwndPCVXW1cafrpfsreYCJkTDD37qtq/az23nc70vv4t//9JrqLkQ78EWnT/uVuLh dv9u3++dpy///5s8zkh/bdrd/6+rf+/0tYa6++CGNPTiHWG2xQMHq69NT/dv/1trdZ2thYpbVavG 1IuFDcU7dWlaivbH/aVjYxQTSsRQM+6Ld0ETCBhHcBWGEmKYYSdWG+xsVaamAk1jiLPIqIxAppih 2nfaiIiIiMxMIWEIiIjLSAk0IybDUa0ZQrOxuNI7B4ldaM7IqBoM7WVZ2kI1Z/MizyJ8Z1RdWdkI wijIqiCwQZ3AQhFnHyJtTapqp0i5mR/kLWfnlAWGE7zCM0a3ZF2gylsIm7SOoSLUw4bqjW37u+Hu yfU4a+qroSnoHCBucH4g3a09hYSM/uYcq34beejngGjvv7QIj9ozp+n5sybA+wQVoEt3BEf66ehB /DBik4hv3+q3p7ZtzVtnun9IEDEKnBih//vw37r/6/+Pxvey6L9t99f6W/16/xHX+5SvdIXxEUDJ 7LCC+1dTQMR4IeoIYJG0w1JnAgn1dvX0pHu2s412dFXaS0tDVBArhlyiFfQM3fqIafHkIFznoVMi xUyLSgzbPBn3cFDFQUR1bEcc257OSC/BCLQuNVXGwqDT01NBUFDxnPjmagpTTOuJhCIiMznHjQME IhgoQiIjjEREwmhPYiIz/pnYIhEriIrGIyyAukdMhNTurL52JZBxlhHeuERFOZFCMI7s5NgpHVZ/ OwZhLP+f8vn8JtnasTIkMjUp36wibsFBUyU5hhOmF+6/19dXvntp3CBsFV1VGt5Hn0ZxC//532jd 6rsx7pOCI4oEXXoEX6eDEJvppvb39foScQFEiEXRHwRT//rCJvGr6rVuDBHY27+r7/630MIREe+/ 2gvVv+uMNDXN6GhxG39zOd5Ej/0v/9f78Pf/f0mzdQn+DZz4jBD+ParXdYPP2I5/z/Bn/GqH/2tR U7zHarFLaUd//9ivUbpnPBmLXgxsRTqxUec/3x2p/i7Ti/Ofh2mF8RERERERERFoREHBghEGClmi SFxGTYUzskRCZXAo7wId9jJsDRHziUIGEDOyUyT0GkUoy4zXF8qEWQjI1lLKhEUE0wgzqFTm2ONb TK2zvsnylmYM1Rdkzyez6NQhKcw/zXRrzW9GtpTOTHq7wa+np76aprOgpqJJ7PlK9tLn5JO59QoI OgRdfB/U8anf+6LzSBF/WKV09PT7dXFj3V5pGAk9kVLnFwkm6W9b4T1X3V//sf6V9fXMziP9d4zv p1x+4r//1fU+++/zvw//18OK/rutra3pXq63WOf8Zz7Xb+dGGnZ715zvdN09Op0Ctq59Wk6r+vdJ Rpato3Y4pfxxxxUJio2KYiq7fYwrQXztG77r1DCaaan2hK00P0IaxfaH5sjUk1BQGEDBCDCEZuiI iIiIiIwhHiJjFoTsSQnZ1LJXZ0ztbxM0dqxBk2FPWGdpOGVBKd/qdMrpaMi+d2jCKjJWcmyQIUMu VhURNhJhH+DCZkQIdmoRGgpPP5MmcjITVmWggTs6hEHVDtBM7g9PmHI9TXVaHUJunhV1Ro5sozl2 wdBCH+xDpNo3Ub1Z7vmHf3LhIER9ua6TdIafYoEuqCVeOLG7kESCDfTnY20EHIOr6D0/6thIvav6 Be/2qD22/Ii6Ff6+7752M3ObcR/7o0FJxw961h9/4/WzlY1eoMnsHBk9H2c7OdDw7YwQqD3Pp/7/ G6xGdPDN06LdTLAXjs+p+h2G+4ai2r1OgRta38QquKiqTj3F2wZhNCkLEUlDCWbrVTHwQ1JF1OjP 6x2mqGZynbU0AmKiIiIz7WzgQQiIzZERdoRDChCGFERoRERGTYTiupoSkiyCvU6ougQZVo6s3nfo 7Rnc0U+XwmVKOwcdlaMtTO0JSqcFKAp2FI6pM66fnY8gzs187HEC2gRHiVBM9naQQkBCU5nkNGzC Z0zDJaJ5/giQ9NBhNGt71ap3hJXQTf6hMIOwg7RrYTQashyrwSaRqNgwSp/p6nf3JD0CL/To3fRs U3uHxKh06E70bKf0XEacMQlb7+kr3ndPXfdC+d+0hQQdGjo0XW54TaTU1HfS9sGS2Y//71rd/W/f 13Qb6rp19x3byMe/Uf6/119/9S/x9/2/39U/3Gw8ZhMNJ0icMWsdAhX913XZyV3PdpYb7HtbHs91 SweeHcGRx2rTaTS0/satheOf4xsMK3G9N06xjz/fgxhiExQM6sU0oM2/xUUhH+mxUMPasMLaWax+ SauHBmXAltC00Lhrn6/NyDCd34p+eCn14xDiIiIiM6IiIiIiIiDBCNCLKapW0IiIxLKSx3yk2JIr kuXzsCy+d0zsJKQpFBpnbkd8ZGZhFcaRM42XC2ZsJ3cg+klSBAk9tMmgdOyEiLBDqEJXmGQwhLXd 31dtX8Ik8IRsJ0a2iK9fCaaaaa3U7+di+gRdYYNGf0z4eGCVJLdOjQnR3+i/aN7qd6NNoER963mW LC0tsOuyt5gIvouIzud9Ok3Xrt9B0g9LdPXr5LuP94Yfun03pft/r915oGKbq+nSb/r8tSi/tUDD 9J0Zyo/cP/1v//9f//+x8e/4Yd+OPa8ERyMf909fTesx3dWletr+/8W1UMN1Xt6apv/bW1iP6fYY Vhqx0wwletqPiKDbEU1UY58tjimKtiO9imIVBQxTEUwwldoO0O0LjQaampYTVBggwmE7CaYqIiIi DiU+GCFoGEIiIiIYIGFxEREZNlTOzGZCEJKYjmTmZKlJsT0HmX6DNoiM7rzs1zspSHR3edi4QyEZ 3NHYSMFU/w5CkzbVlfiR6EE31T0dqxUSHBQswj+kVaIuEOoQlYQkBCV8Nb6s47huncw5b7/CzjJj 15kgJMJpqmvzPu4hhzOdw/8UEz4d3vpZ9cMx/5TgvNNo03NdGm94VXvDDMKhByciO13pBLuVgMXR 3nO54cMJ/f7nrSdJ6D07/vbWO3iOsQlTfvw/2Pa/4pl4cfV1e6t+Rj/oYRb/mHJjlD9Qgji/RnKH MOUPQ4f6BfUR03T/43X8PH50QQQdroRcEKCCvW8RF1h/c4wRh0YGHjdN62pFAww7So3UKxW+lVuq +boPbfn1YZ/uxbDCwwkSkKwwlVtr3gs7CE+DMnHGL9YvFSQ7nOvzaI+HYpikgxQMwmoYJWtroRqY e0OLi1GIvoRYaDCDCmcpOE4scRERFokIGCERmHiOIi0IiDBRETJQoRnkIp5oRlmVyYimZVoRk2Ao vnSO1tnYuiWkgwkdjeTTKhJJlOjKrrsgmywh9pDOGEwmCnasTPQJpGWBgJl8h5tkpzPOiM+RBzIP 5ykzlhkI1SkLdyQ71nxz4wRJ6+qWuEGmg7CDuLCDu7TzveazPRqandq6uFc7/Ru7o0CFPBso77Ql QwnoPZY4IjyfCR3aNN/6dtJv3rrCLuKdCS6b6oatd57TzQ3Ro8INNz3f3puv9/pf3/+g7X1ev/oN 9BhurbpMP/VyCV//f1+rzHf3DQ9o3f/99/9f3/vwy1BNfXrsJMUraulwRHGY2mznD9OnW9LGtvsN 9+2H9LtYMd9X7HpXVquHUYwefsR3T/fDY243+2ONWwkHsRxiwmsigPEeDFKO9sbEbq2HsPDCQtu0 rFEk7QYQYIdNRDz/Hmpar3d3Y9xphDERGZGciHEREWCBlSEBCIjERFxEZNieZPmRShO5+GVBHYOO JTVHZSjpggztGZWEBSDzt4vmRYiERkGjtOqIidhCPOxNAnn9B8UaxSgy7XO1EXZ24Q6K0z6sg+zu HPesIV8+eZ4VCGtqnp3qvENq2yrPj1vW+FP1GHMOp4LigRH3anejYv9+CVOKT6M5UX6cpWbEFbqm 9q69LtJ93vyFVFjP/V9/phd/13/1fGu8rcXCmgYTIyt/33tx+YVSxyo/9+v/W/wwl/UODJ6Nbrf1 bSTGEPr+616xpWewQpDGf86Lw5Nia3q1/5/2te2lbdRHfTrHzOd67eLdCFGGK+P0I/Yp42TdMRtK oM0hiG3XzshYJqnFoex2haEMJoWpu10L1jZ25QdERERFoXEREYiJXFMRk2AjJNHYlkYjCOycbyWI 7+N52Pnds2aIY25NcuV5W3NszJGhVnBltQDTTOyaI+oVbs1xftO1W3J0mdpGR47pkIgTslsX4ZC4 xnTsJyVYcIuG4QjC3ut2156hA1J9RJSNDVztxDUJ2F2Gn5/DKHlDLn2ix3p/QIj7wrV3p3623g0m 1wkEmE/cpw1/F0LhTxQT6bVHnrvdAi/631mHYMPngilSed9yQ+SHraO9xDDnfd5FVo0Gh/03XNAX x+l6W1rb/oMMcGH5ESXzunRh09P+GzCS3fXSp/1f//v/pbx7X4N/D/W7rb9L4/77X9frvzH2fX+u 1STaQX7Swa+H/7/634Im/9Djf8dv2tPDI53rdX72s3OIoECPdi2k230/233T6nQYdvS/TV10raXx sRTGxaVsV9hLyFpDB41/fVtb6QX6z/mgocqMRTDq1sUPMOce0wmPaaqamOwhYsVx8UxTEVCtiK/E dk3UbFWnoQ7QMJhNCI00rCkOPDCFoXaaapoenEWE1ERERERFnPFlEIREREREREYiIleuO1uk2AmQ bO0tHYnHa2ju0YRbhpNMyBFQYTOxPs7EAuS8Zx3W0wnZ2qGVPNJTsS4RSohNAiOiYy+d8lOyroz0 aGdkxOjpvDBClzstQTJWJIu/nai6JIENQmIWylmCDU99JtJteZyx/tyQ9AiP2s0NLXvMNUnMSuhf fpunRhzvxhA/YMGjfre6dGHO9m3Q3yDv83o30SH6ZjQIv88Gu9f/rcnDHfsOhX6W62xoU6fpcZx0 +1dL+3dnYwMd//VX8GHf/T/k/b/u7q23vXWvt0vSMf/cyL+XQSDDc+n121/RHv59dpev///1ocx9 te1//U0DAYcf1HX9wwrQIcR2cn+I99xVXeh7aVt1rDSYQYasR699IY1kTBf9W1W+bnfjYpqMXYoG cSzOU9oGVNbFDgzDDo/GznxFOlVP02haENY0LsIXF5/tCM5EWhENC4uI2chCIiIiIiIiIiIxEtIf k2S0dredpSITO6I7gzsvndEUIiEpS8nju0ZaqV1oztZ0zsL1OxPCqqeRTTTNIIGdzzsDynSkK4wg ZUtM7KlBAwh+dkwhDCnQLhFw8vHsoK49PKCORSzCDBBoIlNeEyU9yD7A3RIdrapdcL61+ka+m/eE vZc6NjXb89HP+1nc4+f8/Pw3/PYbsrCsV189vhI90aBC3DB++81md9J8QxK2Y0/7lbZcIud3fq+K i/laZcJt2S3rbqvDDGt875U+d6hj3tdti2Pq/DiPh/bfrt1D/98N/6BruvqzyOwXt/W2p/6UN3fI otu1am7tvD19zeul+sP9nPw1gwmEJF2r+dUR0CKHnREdAih0P2rYM2bDGmEy7Yihrtjh3S6qCFBB HE2pFAdhv+9hkccciDnH+oQiKQiPspQOD09vEde25UmxpRHhBXaVBq177FTD2UReKgoIaUXw7yQ8 1b9uNBcGYZI4pSgclOLFC/Bl7JUfxEWpwh5aGPERaZSIi4uLznvGntCMRERGnERERERmc95kRGKm S2qEOPJsTzIZnM7AmRBknnZqjs4Q7JmmInY4h36ySQ2wt6DTJAYTSCbZ3pnQakFRDaZC8p4vnYQW W49IRR7RnaM7XPSNsbLegeEDRY5ywzh+SnsLhB+eH06QdIPNBb/eE3MOHhE8wh1hN7ronb0P11e2 MIO9Z6O+ldoMPgg2QrMgTzNVPD2/nfcEDyuSER8KEWGZ52BXavWl3xrViGytBjdNNkh/6/a7q3Qj X4fX/3HX9f/H/11X15nBEfbqfrDvfvMfrPvTdHahBKdH/RoC/f9v21uODBjvDdbV0u6mgp+GnVCF 8MK01QxXqCH6UNL2dg8L52J0U2lDCq2uN57GGsL2KEfCw0qvVit0hMkiGopCNiqqLYqCHDCkKVKm MGdQIoNWnYIQwQakQe0IqGE7ji4YW0MRhCM5EWf0IjNBQ8REYkbxP4iJ2PluKKhDkypNgOIgQ7W0 dk0VAh2EZ3WgREFy+Ps1NKoi1syqxEKdjFK6VhBhVVTXF5M7mSYT7CDO/ZHjoNB2dxJkfI+YRGZf Klwit6nY2toztFyHqekZQ3RoaFTe6ueKuCDRvcHl8/sREMLZKoFcqjCZqCHYg4fSDbW/S9Wixyh6 T06trydutlO6VZhzOldClN/ap/p8/nY1f2e53+5ioQ9e5BasxTvtAg2riGHu9DCQIutcJmOFO+f1 PAb/2NMzjARt2NLv6ab7XX9LdJ6sMMvmr6yIWEqvnc79r0tR3/6+sNf/8fr//9/dDh2msGIQWt+3 tf7qGH6+fZSnn+hSMD9WCKHa/uvd7ev+ETfDYjhhBHl1X73//+7XaH0WO6v0IjOzULF3QaiP6hhY zoMPDeGEEn//EcfZzbDH20rPY/R6s9saTMOccofW2FHjVitBYcM3Q6mKm3X9Wli7/FRvu8bHCETi RblGhzpip0WKDCnPhYu4xHEVscx9Krh+GsRGthCLQiIaEWELtVjyY5Y7DQ0Ii1NyFqIz/Gf4iIiI iMohCIiIxE7EIRLcmxE7E1JsNGmUiOyiIiMhSOyhGEpJI7E4yKUFluPpnT0zsb0wg5B9k6cIqaQZ QiQithg7EsoQIGS6Ow0SlmI6LJRknF/Z2Nef5BKkfwhBEeRbh6b0CE4+08oI5E0tEakwQM7H0/CD CWfwv/7+E9PP9HH9l3MOm/ngt6b92jXJ9d6bTS9fR2M+9no70aNpOQdoFv9mOn/GEHmh+9UG9Gt/ TzwIV877ldLV++rt9b03YhJLumFrTx9pXdY/0//tPrvK6qGL4a92CKH+vqEEcX9v/6vhun1/b/1q //xofSEfvq6Cv6sJrT81Fq7umpoX+v/5vjf86HzDx+9W6hBJW/iOwmFq/tjBCobr3gh2r+vpfmpo /naTWf8R2ooVEcjHxH7aUN67SjSSbSQjn/ev9/iv2KtplI+7FB3BmGFEo/OzXYr9iKi/i7QjOiwp zwwhFlIiLQvQtDW1MeO1ERERERERERERERERlppOVzJE2LEfy39KTemRnCBnZJF87WoIOyDzs+mS 7UyqzsSzqj8dhWcVgmVTO55B9MLZ2F702dGEHeewoQV2nkzi5BCKQak0CkPy1KdGtwRH3+nrr4Ij jr1CGix8937v06T/1fO730mF02qLHLttM/Vb5+7j/T/3pJythgy1r9oynGAh32SM2a2gRHVPj3Tk TzcRy387Aqt//r68OPzfaw00MGIQ1TaT/DQx34d6MfWCKeYS9fU6MNf2puw3RhwRH/1/zCqSfqsP /b8RHaseu3MOUOUPwRQ8KPsMcbNAxY9raVjP+wQpvaWxaUJtKlew9CLxEdWH+20m0m1XUmgWg+I2 MGfa0KaUaH5GPeha5yPsUhH8IGZqCisLaERF2c8cWhFqmsXnB8yIiIiIiIhhToiIxERGTYURZRpH c86o7qRkK8rrWmQcdqmdlGQvO5x38TTMRT5HQUpQYVSEyFRBx00yTRJMp8vkLzumQcdja5/OwgQ6 ep2Nd52OJqmCEaWeiZBTp5KQnn+RBgMlggWyUdnY4h1Euqrvr6+gRHuZy3/3fSrMODNNNNXXVPvz //35xzv6p5utNA3bzZrR/7uIPo1ubEgRde6N2fvt8fOwP3yJRgIruUoML9YpbrT7qJOETvCXTpDV 2+RCoVE7GBi2v6Df7Wlv/G/h4t/oU6hAvbrX9B+tDtVh+rU/+3nRdf9CvV5Y5Y4Ij6H7rf18O3Z+ KjSbNwIUw1O0gOP2/3FKdcjjtUyaIKCFQzdCEfIIenTZz2sENh57s5Yvm5obg+176+6hCm0puhCq j7RukoXGsd6pBsjQYjv/gz7SoZgv8U+wqke8FO8IGcK/6FapsRRKciiVX7vP/dxcWhERn2eNM4PN 0aF5GTU/2sZkZuQjERERERERERERmbCQZaEiITKdndoyJohEd0RTs7yO0pFuUqV0rOxfNUdi+Qmm aERxQmFO6o7H07TQZS3IwZSkcIesMgkXzs6O6I7NcIHv/OyYRDmcPPR2ahAhkOzs1CIsd+dGCDu0 GuSIwQTJ2YJMzHn9B//Vmek/pL+gg9Tx/0XELaGSsTvv0a//5/wp+pO/O53z+qtG7Tdd1O7rhNzv eYcuGtI93f6b52Ei4XO1EYCE4YURXq7pfUdyMqFft6VyJowFNMwwRQ6V/0ndGHPGvIqjiUb1ctSi /9rvTfw19t9Ye/tfWE9OI/X6q69JbCEbf4/n71N2dG9b4/8+ggVpQ7/Ff3ng495x7///t3VZocb/ HfGtezde9IER9/knaEbbDMVrdRpDi4qe9X1sfb/5yKDXX/3/G2lazc+1Q4QOhtpNq6qvd1fTpX7G urz/tL147WrFMVVOxUzwZ9zxTFNK1tbGxHe8bQX5RJ2K47uOz/aaFxpz/z/DTQhoWhpppqhaaxcR 2oiIiIiIiIiIiIiIiIiIiI5ZBpGQIjuiMhON52XRkqojMtxXJ47CUt3R2takJnYnkHKdwkzv476u zuemdluQvBBplZzJPGmfiqcd087CBc7SCHUQ1CE0C/WUGXMlYmXz0dgwpKhE5FVJkcKoQfUP/pKv vToWtfpI1tg3rRn7L9zjhlpFavzd0Yc49G6jdm7qtzwa6MOd17z9RIfTZEHo3XSDeGG4hhjU7LAx WThit6GhrKVFwpWouEr3uvv953urhIlqV7/BFDwwxDDLqV1UF1HX2/FtaW7139t1UW12/CLFy3HT 2+RNkcKGHH5j7Z+PH9u95+bU/en/+Ir/db8dvWtIIt+cjudk0uP/ZzbOZ3CBRXFXbW01/Dav/RLm KN/uKGf4QRxHajCQfa+CFL/ocZNAvusUxFW3s3TsGF/hqdV+ZHCsV4QScQvW1wmvY7WCHrDTLcJ4 3eFxmgYQp1SDC8KXHBXFx5xuNT+puz7ToRDBCItDU5IrkZJZ914qqiIiIiIiIiIjOhM7cVNBTxGT YmnGqE8sMydFOy3FEd1IqEIkLjLWNIh4jLd1ZA87EahM7SZG0Qmdz1O/0zWlKeMhGdIrGVCIzLrI hnKOytI7C+nB6Gi3efzULk0tT0uQwoQZkgSQcVPzNaI6UFuD2+GVRBc/3ZQ7+m9Qv2/a5pIsdra4 Qj7h07L/DJaE/iDD2ez3SfdEY/3vdZu8IOjdZrPHdUd/M4dWw3ngHV9WGXR4MDjVt8w6cnzAT3di VWvVvGm7fRnKj7iDDVwYdCG0dzu35XVQXi1/ta9Na4ahob/0t/pf/rIJEuwwxf3v4RcKaCv90h+3 Uw532qGUpLu6v/r22vpXw4ev6HnInYMb452I1N+q/jQuCFIseEJE1O5Q9V4ZvvyBg9vv5F4JawbD BBG0dMEF9r1hfoRt837bX6o9YQio0ottf/vSiE2k7hAriFd0z/31dexT7xT4M253nIwn0ooQZgmN iOCYZHIkiITVYKmP4vCx2c9ocXHaGhGcDU3WnFpqExQihwhx4iIiIiIiIiIiIi0DCmH4jEWijEgq I6LULVJssRNi6OZkhFQjIEztZRyKWYiELGV0sztXhBnanHYrF8hMhMIOzuIvqFCDKuIvkIzEhko8 yrOjKOEHIOQ6P4XvfC6n/PaDOgVT/6Sn+COzhCLDQcEZGuCKH5o8+O/uuE2tuvo191p5wqug7nvY QjpNzYeGr+jvf/ne979PNn6vPp/MM2kaf83uXMxpaevrf/NAwThhX/d7zvkrdO26vadv6ZBXTYZQ PerXO53f9v7h////DW9AzoJ4t2vxt+16uO/TWRh+//vpD/ncocmPmHJvdf0NDsIPXQ36j998ik/t 3sP/+vf+uIvQh7r19hgiXhvS+s4ViPtURaxGhHD/2t002s/76X9hhY0kbs3Q8IPanQKjdhpc3cWG CX799imMYr2I3v4oMU71iIsVXsVZdF53mpYpnBmPmPJNbHaaDQuwhocMJoaF2plmGojraaYQi4uI 1DCEREREREREcRERERiWl6n/JsNZZVIU7HFURO5xCqV1rBBmqO0rOynIPITO4i+TRHI7uL5CYTQZ 3PCZCkVCO8y6VS3D+fSdH9VvC4JhBhc6Wi+aLx2CRLMJpkHBYZINIi7QRUZS8nzITC9Oa37v6/MP W/p4QfCJvBCs6hF1SCaWvXdLvXrne2wqbne/dWQX+gV1pJAiPujQIUziF/P3fTvnYGnO0gYJwilA Ovqk6/Xva2VrMBAicRnc7yhGFc7lRr+qa3zv3t2/u+D1Q1r6//106dPhf2E4ru1+q86Auh4+PpDQ azDmHM+YcjHyQ5Y+//f7r6/RhzD4eu/+7/ub1o4n/ra7DehF6F50X0m1X1BDY3jGheMwvxRu//+r 6zos5/5+t8/w66r/esUlEVWPdo0U3/v+9YjiLvXE7CBe8V4+732xFNKGgZk5qZhzQUPrcMVxtfas RWr/wvhodxxoaaHapp2hFoWqBxaF3Ypqalnp9rnaY4iIiIiIiIiIiIbERaBghehEREZahruIiMsh YjsrRVorhUS1EdSKoJSoVsUOupn2ClNJZK6VnYvmvUIjThlXnc8paCDJPiDRBxjO+wgyNI66nYGj /rvXL5/TTyaWiLuDDzWYQdTc2ceTL001P8GFCB5dEfI6OwMT7/z3Rrf3pN9oET/i988PdYeix8RE Gv1KTO6f6t0/u1TmKEj3raBAjovtXN9ezuHwm7Ru87VxHYLw0/6dbNMwE8f67bxCLr9PWpIXb0GG 6vOd0PQjf//p0+spS9/eP1f9wQt1EPb5BI797/RCj/4j+/RGPtUR7j+usHDI5aa+tRpP8HD+/Mit UHtXSGboIVcR3STOeROPHEYIVEc6KkXgSuKhsP3PZaRQv+Ihn/dWtdVsa/3MOcfX6N1iExTuKSGP f/Y2K7BmkGdFoKvHifwZt2c/v0CDRJI7nnUvjuO00NYiPIyshdF1hx2nhCI1P2IiIMEIiLTM3qQi MREZNhtFoWI0jIlMqQy2MUrkmCDJGUmR0duRGs7BmRmT52JZkBoiXGd+jtIWEGZC2ZKq6lCCeXz+ CEmZyD9UO0RjCbh52OgmnBIvGdhIwypyn0ZFCCjy+nNbX00Y59POg539Jsn0IUjQ+m00GSoJSmQo E1uk/6NRv3fz2e0Qi+p7hhutB8wZhJB0J3pXpb+v+n+nvHFBlbzAQa8MMUZyor9XXPCbnc73yFU7 nf/7/+PWP09VsN0uRD72vyIiFS7+3en7diPpiP//3ncocER8yAhvVfbbDev/hw//4//3vaznghU6 JP5uoVEb/wQRvt+H5jiO1g4eP+rX3BmcqLagz/YMjoEu6+Iof41CBb+3a+2k7br/NBQ8dui0ihXF 4r2IraBn2BvVrFoKFMILxlXxHNSwYUk4hVaXa0L3GP2nwwUkDwYs52LQ8Ri0K07FCL7sfjxEREd8 REZnKHLHjMiIhghEWEIjERaEXacRiIiZdluek2FMhEdkmXzsCyDzsoibEMxnYE7OxQyUM98rrSPx 2oEOmmQeE21Ul4uztwhXNEdV2TwQZMmS7gzvEfkH3l8ut676++mqDTp0DRoci1kUFd6Ld7cRB90b v877+p3aN8l9gzhVbITeIP5VDV0EHhPf6HszRdEdGEq/6/imQVHc0diSYhK88A/ZgZnQbfq+5qP/ 8REdb/Sv2g0GgzUP8+MlrWxEWRUr+tERblpFC/fUw/1/reocOGPqGr6NorGVGv/8PxgpHFc9gh5P 3VexpWcnhw2G6uMG+si1kVTJ3BDun4b9CkOn3tf8pQLiDg7w0t7X8go3SdbWxWyQ59pIM4zsRWm0 FxEWKsmnEcsuWphYZbnGBpQwkUmdqCg0M3d3a2hedENYqIwsOLGGKHLSKVxFxERERERmPa8MJhCM RacRERifhk2FMp8wjtbzsSyEzqzGdjsxE+eZU4yG87EySOwJkKRhEhnsmWdg1K6XF/CaZQFztX2d RO/VBkqCWe0yGFBM6o9IMJ32SrMWSEmWpRQt6un+nT03o0VrRraYRMeF0Z2v2qeX1xoER9+d+jUf vNiq6fSbm6d9306NNgk+6QdAiP3CD6BEe/9fpd053yIaPL9IV/f6FMl0+t0HIKwibxfrS3+qdf/e d1sjhff4NBgh/7r2/4QZEO/f9Bf7dev+/lKi4T//r9/7vvvr7Dg4///9f//iGRyXLUOvWM//q1gx m6CHZy1tYcVZyeG2rravGYQIfRiv39djDU/Mduvt0rBgk9dE4YtK0mKIqC4h25/2kwwozvtK1p9K 1ilBmHivYiviKYo70Xgzp2xTFAwWI+xsQsGMMtwo1iNhhJ1o//cdoMIR9FntBhDMf7TCw0HGNqKY X2PYISIQjTCEREREMEIg3U8FWwwgYQiIjEREccTNCMmwEjcWXM7C8yVwiJWWZCOEMhEdiWa87Kcg 87V5BkVREzjCCnaTL6Z3qshaO7NSSNZbvpWUM9Hbip50Wp/BBkrYQYQjImQW2GmURgyUMJErETKl QgnDOxrMPzDVPTa071RMcER6k6TV4dJppoJUZ36M7hpp+tN0bP+QpPwTt1PFlWfJCJ4Iv5GO0J4a M4pEY9IP5c0g3M4Op39s989vSa+nJdhO3Xf8UrQbKVF4YZhc8J9qf9N15jp2m6S5XVYuFjNGRwu3 4qdkwX/3Xtv/fHW4ySBjfppRIJLkTDG1+d5CG/vev7e79r6G9f/5oW9L/+b3h/btfw6+tT/nCH/h vs58yIIVTpWvH30n1nRAid50cf+zyhvzoShMIF/Bk8CWvH/4ccf+Izc2KWl1F21WIT/axHDBNu1+ IjtXYhRX+Gc/bdNOsGbY32naVihiKhfb/GVObS7kxyh7aR2iQJwv4x2nm60PTWIjTTVY/zDlQU9R ih2EJ7YoYQay0ihRrERaERcREGCGFiI0Ihpn+GhEWFQiMZ/iJ2WIREREREYiW40kzLTI6KhE3SuT ZIiTzsTRhFQjsUzpplRKQyJJlbNCyhKdzzpndSOxKINKRbP52fO1pSulSZ9KE7Oqs7JhFPqRiIKC DJWF3CGdjiZ9JkhGzJkC5qdnd5dkozDOkoTs7gUg47Vmn6XXT105C6sESHwRHqhB9dPCDTpcIadp oJ9TUIl+90d99zWnyMKCI+EmkfLc/aNzzwbKLz9ITw54NdAiPtq6oEXKE2oSQIj7lpFC7+v09N/S thE3iu/enjXCe354TjT15Cqf9Tu0q3RuzucfT4+9a3+nboEWnWgvuxfrWzoPFvK0C+/t/rilvsJL NfQrT9/jf/UdDtb/p/a/CB3HX2v/+v5xXkMJ9t63171BCtQYNJuMwm11v3wRHYNs5rOjjX/+fXW+ uoIHZ5f9V5nKer9Z2rCzdennemxqSgLEd1BA6HP37V19Xhpxqqq9BE5thpv9uvoX4jBm2JLshhVv PEwuFscINe/fwwkxpCaAu0lEcMKwgdD7ViK/uGqmcoYuC3w2Iz7g1LQjNnx3pimK2vYoR9inuIiG C4QiM26oiIYJoREREMJhTkRFlIhhT/FoMFERFpxERERERER4neI7E0ZFkdreRTk2GkXyoRCZ2IzJ zTKfQZ2XMIM7nlPl0kdiaNQTOwaMiyO1CluPBbOnZqFOzWLvMIzR2JQTkYcvn0RQyJZFg/ZQz0Sk QLYKdmBVyYRuJXkdAmdjaJZEdmgLqfUrrXhX8LF6anZMIi4chae4PRFjBA0nqthMKjFpD1tMIRR2 XJNDrvvBF/9F5nc7v7ShNkYVf88bzfozt5soER9wRHFEh7w9Pt1ng1/+v90//VTud6vX460+n03p PXhE3jP6z/NN1PGf6Pb0br03f8rYEV3vQrv/7fgiw35WwXr/1b6H9BZ2eUY6D/77fQj7f9f9el4j /+2IyJv/2t2+//h//42rf72Fgih4WbT9AhTZ7ut/t1IhvItZ0b1/29z3/HDc+py3/q79n0uh4j+/ U0DDGkDNn6usM3e+I4jhscd6zvMJuGR0nvxX3G2FbWZ+E1sRQZOwVtLTexsMKdArvME/turEVhiz s8hHn8T6C4Ui4WGHQ7So/wZ9iUNCi/KdDvQ8VBeO81M1LTzZawaHjQproO+xX8MFsIXERDCDCly0 Qi4i0IYQg3PNdCM+ytT/DQiWkLqIiIiIiIjiKN0REREZNny3OREItyrO54k0xEriOVyVJlOZGZSR vOzqlJOI12VRGFnYFHpTJSs7TqsO8wjNJ2dmoUg6FIYDIw8MFThnZq0+DJiNcXzsfPQIOGVjNeEz sb+Xz+w5xwtVp0jUJXIWihrw5FTpthkQKF104ZChQh9bztzxM/vq5srmDMKfwmVmez5ncHBEeedw dU2Sswq22s2YMKv6wYfrXXujDnfdXoIVFbEG1fw2zjhU4bnHO+d76pWd/zw0Sejev/ImD/3abrem sQkCLTpyuat67ENiPsi07/sQVORGmIMOd74nYxkcLb9diPx/u/CC/tf1K1ar23+GFen1+9eIwi8U 7lQU97Vb3iMII9AyengyKYIL6OmCCkYzQRd9//+Dch4JfefVT/uTMeoi4ZY4Ij7aR2OEdv0tu1eI TdLEK7UlA3f91KUC7pN8Qv4aY/Bn/Ct9odiglxzeUPQyGFYaRX6hRFQpY4TDSQK+1Y0u1BxhW3Ro C//hcG/tSxziNNC/BMUMJqEIsbVcVFTosUME8e/eqqxERYQiGhGdGWrCoGFQYVYhoNCLCoWFOQhG IiLQiIwhERERERERGIlulGdkhk2S+TZ87nnYlmQKZ32X8pHlayUI7WUd1kdBSWiHaq5bv2R2R4zZ E9T6O5yn0dl4gkmE7MgPJ9AgnBEFBdMjo7/hmkadhNSDgnK6W1iIcGVAlJnZqJpoilQaNDV13Rof TEhDKf4pEZIU9G9oyijO4Q2RB3rer+2k84638uZtJN5hm1NBo263Yvt0Ekg9UbIeCRhzv6nHPH2Y LDq0m8grO8fq60/20gnmszveez2slq6ez3OOYfV53PGrxrdvV+6EMHuQS+/Iij2v9pR26dyVTeOI r+xq0+//fPL+PtuM7L4Yfw9a7h7//6/fd/evvbf//sIiF+2v6oiqgdqXoe1u1Box6Ef6DSfX4NDI os1FG+jF/2pe73a7VtrMOd7/M5T9hvW23qLT+9rEdq9ba3m9Pjp/evd7aQwvqhb7XFtmdAw4tIgt EUJJ76LHKgp7DSkUcER5tK1web8RfNStnv1jS8VFC8f7FNUItIYtD7Qi7FToxTGIv47zQU5T49ik ONBoWhEWhEZ5lOwYQiIhhCIaYQ86FWIiHxqZz24iI4tCVVHc0IiIiIjNBQ8aEGoimVusimT5kVQi JQhGTbmSxGQ8VyT9TpoZ2a5uzuaOxrMk5JmkdjeWkUKV1qCDCn0Qcd/GgYMsjspFIsYSwqn1oPOw bCRK0R0R2a0R0mQmSjBB5KKM7Cajz2i36nUT7CqlaC1ZPNNppBCMIRmsVT+myn0f+/8Jv154Ndho vM8CEG0E9th60ZxCVQk+jZH9k+2v1f0Yc76GnDDIHEFcLWm0rwYb05EOmp/z8kSH/TZly7ww3jt9 bfW5SgwtnaxBg18dpinoMMfyW3Siozvdv+98GGJ2kv93/fvYYd/Wbyt4aOaG/99HE+u3a+dmoq97 fQ7pD7edHWDBhtdnv+9cEjav4P07PJz6/Q/KWGI0NJf/b/b02w2g0xxHEaM5TwglbUNX32nab+uo RLw3wgjmCCI55/sMJT/e1+GFBwYYiv4thBcUJUnEccffN9hpQQOjWVmf4IJYT/Y/4odihamcp83l D5hyrKe/G0Oq7G/G0OP6FbxwwhEQ0IYQwhDiItCLQjjOdM/55oaGgwhfGrriIiIiM54iIiIiIiM1 IjJvPKMRJsiMhpNDLd87Wey5hImUeiuqMq8yDRhFvSkXbmOcLPQx5LcTsSRmcrkgVTv8iYYiNNzL 2VJG2SlwzqECdlDMGdvmIhiHZIiOiOi8EGVESuL8g6WMigYjBByd8esnbq4MINNCU9V7hpppoRGi x2agi3PzdJ06D0W/Z4Le2D03aE7tGdPNaQIj/SM+oIjyNB3aSCDqr/J/mjJ+5raCe1PnqEHDDap6 ISN08J6e6bO/q24VPSTpNtkFpu1c/0d+4QIMPaRsYMOknzD4q5WwwRkK2DDEigEedrEK2u3/umv/ ZLL/3t21dR/EItVOnDEacMGNXr6tYdbr8MnV//42/+vD/fvH919bDfv+175kWDvCzadYNEUGvH9+ n16pg/7V/f38MHBhf+tr9ffQQI9/aT7TTrENSGFH6tfiljVpdYZz/J8GDhhBG+8EEb73T7a+VEww oIJX2Gp2ZUIRtKOmI2MKVKdWsTs1CQ0o70tsHBAu1BAtsKhHinxYqKEWKEX5hzD5oCaaUWsMJpJi tiOMcvKxVlyYrtCIaTDCEaE8mhDCFoREWdWkb7CkTY4jDCQ2FOjBghZzxERERERGbfmgocp4zQUO UOUPERiIk2Iyl52N5XF8ozsUQtCItCIh5NsI7JcvmRbGolIUFU0zxkyMvhTsbyGRCjjIRBYM9lTQ iS1wmFsyFhEyGy5yHFhSpoRRPnTwQZKA+mQcRMF+yViEzaea2rqjWwhcOZ7o0Znw10CI8iK9l/zq ErbU0iHhCVDLUE1Scg0gRfzuaCLzTzOXFnwodjNj0m2pswZsZLVz5dGdOw3dKezRhOi4wwWZ7jrT pLQZ3zoV6atRB6ffIIhqwYggmTo3EdKu3T5LoMOlnc7xQTZ393CDsVX+0/slr7/Xfv79BrgwVpoR //cMGGJoy4X297XUQYJfIi+/dQ/d8x//7drDdxfkY9+/qHvS+v9OSfvw91W1w6as5fuq1V7EUw9a Gf9r/wwQRtDP1/f37PYv8PqNqriMdrxFCurT2kPsVxG2grW/7UNWsMFQwVuxTEUVVLEbJjo7wmKD BCxWrXZVwIJf7VtIWGEo4yri1PVpoZuqGEGCpoWhcRmohjHdjiopFjnfLHO5x4jBggYIWpkRERBh CI4iwg0DCYQtMIReImSjERGdEREREZNgnndot1sYiRTKM7VHJsjzsE1NRFXhBnZlkgUgkXyE0Gaj MgasuShAyGz3JtYmR0R0bWRMiXCnZqYSTNXhBnaqIE17KUZckbGUBSZGdnUOIyF50R+CJDvshdWI i+GmmkjW1ue4WZwRHlvq0g6IruGnydlD1vQIG9slQlF5h9I1M8CFTfq3N1BO2gRH3qkaKXPjf8MM Q7q8J4WEsIZzyCIlKVlBE3tb710PvXk4gWqvb9tlbIuG/f/edzvOxt/sjHDBDIiH1pd/cgj+2+9D 9/XxfBgxImC/9r/eWodb9hwfBmb+s3+v5hQ76+v1VrfbK3f///vjc99Q4cyMORa2rfuoIVaScPOU NffnR6pMj5HRH1tVkXcCglORBSOL0//0Mdt/emDBJCO63Wg8bFd6XcaxERsfWECPfoVHa/sLmsZS IhFWSfOrFbGDMDEWOGtiP2guwubdCblVpdWRjlDhJwwl2o5u0IjiIYUx7T8/RFoaa2c8REOKG7hh CLOexTseEIiIiGCqdCEREREWsRcRBhCwomRIhEXGc8RGWRSyOgmIiW5RSbIzsLz+EIztbRCI7Hzu vIYyqZri6LfI3/ImesIqJM6KzNqfzt2oJ62SGejsbyaRd3Z3cXynFMqIzyZsJdB+jDXTuG6hDRY4 Ij2F09dOnC2FKVnTBBqmgu9hXP9P4MP0oQdvnfaM7d6nd1auiMegYVN0ZxXZWyHku7Cginruw7ci FO539uRPPa+9BvX33nfz/YMjiz2/aluZMjhRJgYMSleKJwwdjGXCPhhvoP2/bsEP/vO04LktkvJb Lr+JNAm3kEqrWRNgg663vwYaHB/9fr+3vD0uH7/hgtvh7m+8/5FqI8BkbDFIycx4z/JwcMPb/hrj P99bb50Yd/Ddf7PIdvYPpY/UEHUXe1XDDRuhv9jX76bY722NJu69bI6Ttj7BNfzFwgeY+zb68GYa e47GGCf2Iq3dSpTQUqmxxFRGw3KnRHHERaDobuLu7WNCI7QaD7QtOLCdXcZN8RHERoREREREREQw TP8WoIoWeaERERGTY8IybQEOwtmIhmRpHa2irR3EXzKmRtHajO6kRiMI7Oio6RKYuzrF3umQghQF O0ihmoQhsu1yQzDOz+fzWiOk8+jscQJ2dmoU0BcheamX8wLTVPtGiFTT101tC/whFdqvVErEW9NT vandwnqzaReJGp3Rs0jPR3ujOXHvW9GxIER+0W+ezRCoER/tnte13/dOhpv0mqr/ppspaI4f53O9 9J63ILUDjTzud1W52tR39jIipXr+/3875vuP6/+ENvXzvHfil6tWk39/kE1TpIPr1+v/7X/3/9mH OOcfH7cOP/xddd/4f5wIO9bpb4jTOdqwYIdnlH/6a4iDq/sNWznf+///Bu122OmOm1zQMMMErooD FLelFpPz9/efsb6QnUJav/q3T7ORV9BaVipz7Yo70wZk91YjYIEK/fjO0L7iMJNpd7GkDiOMRx2t qY8MIeaysi7CBhMIRrFoadG61JuCYrY4oeIiIwhFqhERERERFpoMJghaFoGs/xERERERiJZQTK4V mU87WqTaEQmQiP53PIVnYnkVzRHXKzmSfTIHkXyky6OuVlZFI6oheVAQmaP+QiIvUz2p9LnSLvJQ shx6O3EIO05BBY/M6jO1USRRmQTTef0zpF3ZLgup9IjGSLxdF0EHZKIJGvBUHr07VU9OwnanUJdX 5orVg1tb1JQJpyHIXcHOFCJKawnSGjOy1Clb+tWp3f6bSLuk2rNBnaumj4yFpG6Rho3WZy3aBAr+ tTu4c8Guqs8B7cINwRHGFpx+/apb+89vhDOOeLpJO/+4ToVoaDvSfbozlRXec7GnbcXz/Ph4fpMK bq5vt7eDEquuRJkcK/t+r3dU3v/+EWnq3fW3/1++2+So41bdb2qH8iLHG/XX+3/bv///93X/x1d6 XevDX6/qs2vvuoUnDF+M/yKA+3tnv+0vsgYYfV7PZENs53++t7t/W6obc4U//7s9+sHmzM53qxr+ w2ON/Y7WqQvErYY43V7VZsv8aj34MHv7raq3xG3p6HmRpLwyxjDa9rTDCQkU2klIYVYYSFiKp+1p IlhWkjfJRhc9Wow0ojQ8q777TjjtPU0FD3Yp2Kx5j5GnN1imvdih9in0IUbFMV7KRGIiIiIuI0Ii wqDCoRGYIhDCBhCIsIWCDCGmWXsINTozziMRERE7T7QiIiIwp+iIiIy0KkomSnCInc+Tb0Umdck0 YRKkVpHaoEIVkLzoeQaJRkazWRUshM15dEqCHaR53Ed2oKXjoEU+gTtM9pnY3JEqEJUICDJSYSOm nIIHTJUIahAtpHWLsIMqIhUa4vkEReBQgaZdEdF+nrr3XnZMRGC6oER5UFvdo1tVW0YHTmhmsQlI QLkqCBUTHsREPO95r9o7/6V0bqNlHy3PAr2aDO0bNPNlF3QIj77U7tJwkqBEfbUhjL8E3BEer9B3 pd79GHO6s5U6Q+612k7pCtpPCar3PfvVzjmHz/r0b4SdXny3rv769vIiJ2XCVtx4urbe19N/XQ4/ xaXq6uG1H+hRdxpvd/0Lcf8cPv+vdes39fvb3/1r+/v/pXqv/1VvVYYo3L7RgtnuzlaW3qCHrdnN 0nPdnvfRgbrf//2z6g0vf90p0CzZ+p+t/9OhxsehHV1UXaxx2quxraX8M3etrMOLL91/YiktuI9y r+7YfZy1YXgzhYxWKXYirOdJNhe+NjSQvB1bCw1q8tyhiprxHajjmyz9EZqdqbrUzlPmu1Fhritj WPwxsUxQwYKEIiDBCIiGEojQiIgwQiDCoRhA4YSiIYQwmf4YKeaEOwg1ERGf4iIiIz+hERERDiJa hCloSYiIlvaxk2QiMRhEYzXnYlnYoIdUVlEty+ZEGS+XRUIqSKfLopzJWiNI7HyN52apPk2hJhOw g1PolCPx0i7U+iEwkFPqwuQmdmsXYQYW7ULaYU+jW7z6JwXJXF+GXRVeM7nnc6rrot3p36encxen reqc0V/W0aHquqdBbiRQRv/0CI/wg/71BEefqn9AiPv1O9INo779AgV0m+0CI/b89merw9l//2l2 tv99P1tnu3686LpK6/f6Xp2+t/FBB5382HjsP6/W+7ddL7dmgYjdSIidkcKvmgY/9fM2XCESZcJ3 /6Xktm32/68gcXCAwYkEieMBCCROy4T1/6F//Faxw63/+vf9dev4r+Ha//3qoe9YfwQ711SBDdLC zozg1DGf/86Mff6Qz/Gf++2q3rDCFf/vbU3QsHz/htI3e/TdTZWNZu/zc2/vSvaV1v/+9ephzPfp vtf9KhrCBHNsfbHvJQFEVYLTYMyil33Z78q72I39YpiP/YiicHxuIyp03O0owlavdggsqd4P8Ghd ivdhbWPG04jteLTTQ47SbW0LWxTGxQtcYvi18MEGEI4iIjiIiIiDCERBhTHiIYQiGgwmhaUXEYiI z/EWmhERGakYiItB5NsRBIl8qiKkZJo7MGVPJWZ2KZCs1EduiNo1mQRGEa0ZBIRO0pEO2REXcjrI IUMmIJpnc8JnVG2UAuEzsmE0zVF2mfR000GE7ClSZfITKeI7CDKvIVmqJJHVGILI2oNKqcG36Lh1 zQwQuka2vPbVPX0aK+elsh2ENFjs1iEX/IUIE0GSoSD7U72VbkxwRHneE36Tciw5oNenmzq9Tv/d JtAiP/oER9+1QQbCV3rU49WVYfS7HgnbVd/rRouKTfdOtXS2/9PW2/X7z/p5hzvp9HHM6pXRujV9 cEXXd86xcKuZsuEKWGFeq69zvG+RIF1fp7/9fv//H63/3fq6EEW1Bpen/3X/Xf++9YY3v+sf/+ww ih1+/rr3+vfv/vUGD/UZ/uoan+jI/jXXRjYfMjrHSgh++oQj/BS+F338IFhd/9bPoMHdjpt/1W6H /tb7W13Jwv2k/M5T0rX6mf6oRUM3Wv6EV/x02oYdaU6BYYUf2GF7fYYSbVhpRGd/1Wx0FoXDJuUO EwwlEeemNJqNtLvr72gqGdMEuGlgmKx2KHHin2KxmWLQ74aEWKDVcUGYHj2MGdX2Nr0IURGWoCEQ wQiDCEWkZERDBCIuwmEIhhNM/wwhrcaEZ/y2oJtCIiLiIiIiIiIiItROxqEZNktFOeQeVCOzop87 F0RBnI7NclrPZUZ1RVEbR2kZJx3NGRaip52N8myM6Rd2EypcOQQhn0mfVl0Zo6I5lXWf6yU5xyCC WzWKme0GmdIwzoj8EGUBglEYZryORBxCop0YiFRoaZFQwQ4hUawx9M6Wi4fDYetLSaYQYQZqCa03 b3TYT9Xtb0W7XVDNQhKQgQ99Kj/R/+lO/un5nBy3LH9/+hdb09uzQZ3TzYvQIj/UER7eEHZ4NfQI jyJDwkoXhNzQZ//PBce/e6Te03Cdt6b99Gg10Yc77+76d/Sd9L6Sf+xp6p0b1OOZ8/5/1uKQbvvG E8tzMMJK/1kTDAg2rvff719bbr8EX9JvXcb6W//V1v/HfUcSJRgIvTvv9/rrvVL+OOI+r/Qpa2/7 /j3r//p//237Wv771ejI3pAhWsyJDgSf1V7uvu3Xjv3WzmvX+CkcV0r9dz6/zNdTdv9DQ9S1Dr7H 7dexC/mgp80FDwZnKi6a/U/b7fWrSKAebN3xSoVausUsMJ/2sM3DW62vvjfpWTgoYwvoKGFGhuhf HiKtjV2DBLDsULBgqdNsRTqGTcocIiwPDCTrH3kTBePuGlaU/5/w0tYaw4xQ8ExX+04ZoCa2tihF pipj3pocNCKsVWux++xTH/sVERFoMIXDBCIiIiIhhCJqgYIGCEREGEPNNhoRZU0NTkZ/iIaDCHGg 1ERERERGgaERERERERGWYKGIybJaNSKyiERLWdi2SvMKitohMi7MR1ZjIzMIliIJm87pFdTjIGpN kZBxqdhT6s1OyEggzuDI8axSQIFTIVIJM6BN+wmmmXiDk7IVGgYIVE+UZB5KWYioyCxD0GVLNUXi F5q0+dRF9PX0aNYVNclITde6dXCe+2SgTJUJqdO9zWISkIENU8lYoIV1R3/6BEfvptAgV0W5Q9Hs 7tAiPuk5cza5swnq5387361ng10vXq0lmHLhuk4X6MOeP2/1vq6V8IWlbbpvnc79pen/f7X+nncp 406OOZ/706JD0btO+gRftEnU3ZbmYYp9d7oigYXzQMV62o1vpWu2r5EwXf9dLevNIuF9d1bV7jfX neHoV8icXC0vO9ur+t/yMev/++//1//jfv+v//23W+9e+vfVf7v+L50ff1Q5kX+dFvMf1n9tb339 iOZHvtb6/Gf9r/a/znqXS+/tn1v8/fX/r23v1M5Tv70u7S264MFiu9f186BGwlpPq3X7e///2CEV a/2tp473VfYX72sR4v7EfxHEUhtUxFcbOfWkxsVEVEVrFdqwwl3+0wwl+RMF4j1YtbbohhbXxTVY 7QuryxzjwYQtO9OPMpBNBpxcNOxTFbHuDOpitj+tinjhREQ0GEIiGCGY8MEwhDQgwhYIREREGEDB CItBhCwhHDCGpyFOiIsIWmU1BUmwTERacREROxVHYjERERERERIqhEeQiMuhP4ldREtRdKROJ/Kr EtGdojIbRC9SDiFoo5Nud2QJkEMly7JmzuaIIz2kRVoWFjsEDJckGRXKFkURppmlIqQ4s9PKcoQc HIPqGg7KcZTkma8oyDk1skGElcFyczByMsJjh2i7cjHgkgdk8VaPRCqOQdBfODg8LdFvh6Ldo0Mh MKFRnevR/ae6hA4RN7J905xw0EDkJIJ4sE35GMDCDIqaDkY9G78OHakH4QbngHP6hB0g+CI4giON Pu99WjwIWb8Ett2p44MOE29BuZy3QIjhQm7qYfq0f34Tczg5nBthArriDDVBL1k+oRN4hE3itmPV fV1awnot2IMN0krEMPcn/6aDhAiP6vCqm2FPbDD6BAt2g2IMMN0dV6sNiEqvb3QWgvfjNAw31vVV oJwwxrcNr3rjigWNY0k6S4MMRCLr2IMMGGxCWv4QV1ra/7/9gv+b8Naf/7///5Ov+tvqnwRUL90C SCPT5j6iozCjiOdFnO0O1X7XYzCCRtWuTo4XxupE/OKO1RGM/+kCKsGR1eFCSbnOO6k+ECBLtdtb nfc7y+uvzud7aTEcRzvUIErdBKwgo+6sJgnO8xvXaS2uEEc0wYhupFMEESMEF3+GlEKKjCw0pz8M VhjmgrP34vDBfUGMIJY1iCWY9hhYisMVDC0xhWKCgglfhpRBRBRHOd2OCtDY/wbwdxfd69iEjUzU tB0MNcJnP9ipY5TnH4dihap0lI4sbFQoX8MKCnOpqQwW0IOIbEREREQYTQtCIPiKBCLWGCghEOJP BhDjxyKIUxcwWUj1HEaDiI7QiOykXEREcRGaCsz7msREeIiIiONC0O8m0ITsWQiIjLd9M+kz6lda /Wl3/f798tYEu7fedggELrhrGvtUNZtLwQqWPng4/2tQj/i7WMGbfd8R0IiMcsg6lckjsiCnZKjZ lqKvy+e/CDT9LbuhPH70qzwr/W+u5agsGN3/+tiNdx5kbv2tcM3U/rX207q7xqhERqIjluaI7WuW 7y5IR2F5uLUJOV0sXL5/y+oQaZagIJVfX0YcQRHkqJD39/oMJsriEjDnfRnT//ruZYGcrAZyShnO 6gIO9QIK0BB2nBgrQEFaBgrQMVt+7uyPcR//9qnpp//diI3f59M2mbSjaZ9FPpmDo2mYPMH//hkx 4ZebTXf///re69/76sI/tOxFdDTVNf7W/W7X2viv9msIREREREREREREXY4tCIiIiwojlofldbzv 0ejtZjtVFMpxhnZqz0UuMM7UBDsHnaBTsbZ24p3AztxKntXOwvcKmmnoWg0DCDQaDCBp+/9F5QIE J3aM70Ycm7Rp4NGmzsvow7ReNF5RoPD9d9wtJp6beg03Tc8A0n0gdBBtBBum7t//jT2reu6vgwdX 109Ou9v66/9v/fwff7/v26GEMEOz3a07e6ra42l/97r1VY201tjtBpNhLbXurVtKGq5uc45tkhQ5 treIIjk27EbFWxUasUxTFfoaF5nKiGgwndnwJhWwvDCaBhNRf4QuIiIiLCEYQiIxERERyutjK46h BnbsjwKXjtbzIgjs1ZdkyjstzsuIdkZ2BR2GjuiO6I7WqjdV/O1QQyzTQtA8INTsG0GmnZ2F/SbR 34QIj7rc9tGcuHB833Qnd/76dfpvR3O+lemuewek2qM66f/9bf379Nrt2DBnYwMU5SgXppylhgpY OUsMf79f/v1/wdf/vVf9fX1/9OqVCzH2rOfvzHs52zogh42/ulu+L4hrb7DS3sa//S3EUxFU6WrJ jir9irVtXu+9k3KdZhyvTu8Y0GEGE74YTvX0++DiOEIhhAwQhhCIiIiIi0IiIjxEREZaH5ZPR2ph DJDO8KV0uOyNVMvCggzuCOwcdiWYMyKmTTPGW9GX/88qiMfBEeKWkGgYTTO+y+EGqZNGXZ2asua3 /wjXDaPltOfMGhPDKUC52I5nbo0MIQwhaBEff+2e6bbXfW2ewczp/SD6Tzwa88GvT+iaMuEOyxkc LH/99Phg6fZuKj1e+k+rt6+9fW+33p/B/2H/7f/f//am6wp/zy0r2v2qjjhh2P92uteu/oax/YrY pY67Vj7puKb906vXf/Z7apqnW/DxqxCiOI2IrjjxiIiNO9BroMEy3CDLdNaEcRERGhEREMKM/xGI 5bvluZxlXHc8pbPR2Dz8dl0bM7HRtnY2zsdHI7+O/crrV14Twg8INME0ztQ00GmTRoMmbT978zt0 3QnjE7tCd2EJTtCcehO7+d5HazalKRfI+tN89vnhNozp0Z088JtGdBtGhP3Ts7LAXMsBeIj29W/f p+mr96a67vuv6t7t//V///fvVaamRmRnRdv2+x8ax8fGrHghTQ+63w2OGx633Wt7paH7/d239tdb 21tYMxt1ppoXdp3qtveuv0IiIiIiIiLQiLiNxGJ3RnZKRNkihBhM7JMy0M9kzdkyZ7OwbPZ2XZ6J nH87V59HZ0djo+junK6Wy+EWOUOGi7DSM13333enYThlLJME4ZSzuukIdBPqwnpum6bptrrabfd6 8IN0G7+6enp4TpN03CeE3CvO+/99J11+9unp+1dX+//f/+tf/q9dZ2S1f9eP/9/X/1/4f/8wtbS1 dderXV60rWDvpRxHN1tW0rSurXq6tbVunxr9cGEmKYpgwrBhJgwVhhbSYa2FO0usVOfMf4Ypppim KYpigxTFMUMMIREREGCO553+DBAwgYIGEGEGEDCiJ2+IiIiIjLMOaDO7M7A2dgRneGdjRnfM74zv nLeEdujtaztLRhcL69dTtKUrpeR0EwqgqcFUFChQUFCgoJT6oRXpv5jI6ziX/9Uy0ihVd0Z15gzH cWY7CDMblzMeYZtZhm1mDy55h5g/HP9Vq/pdrppVa/X0+jF5j8xdG9t6i/q3tPTX0+/te17T7Xte 1v/91+rX/f//f92v/fQ7n1v1URcRxGhHEcR4Qa6a2FShhML4aqt6//xGhHEcRz9xb7EVOjOjMfMf OfNRTDnjJDlDnHzOU7mHO5h/0t2nFxaERoaehP7BCL0J9UItb2VOInZkhERERERERERiImQRHdM7 /pqp2N52NR38diUdzzucdz5XSkW6W9VVL11O1VGFU7jJ87LYnwmZamEiZmgiZmkdgzCR2DaRNGEj tQwkTRqTNhImkEgndT3/zw1QSaSaCTSTSTQSaSoJNIJpLfv/3OJGgQkaBCRoFTwISM4hIzikZxCQ IuSM4hIERyQIj726/1ta/6VqmqapqoVNU1X3uNj39qmqa6X66V+qa/w61/6Ofm/zf5vejftHFubX W5tebX9DnPmPiPtb1v3//tek/N+kn9/0YcER//4jiOI4jiOIvCfqthArq1C3rxv/mP/X4jiOIjiN iK/7TtPNTMfMfMfOfNTJjlD5GOYfBEekUc49qIiIiIiIiIiNDCGCE8p0Z0KdEGFEREREREct3Urp bsstSO5oszXPVcrWdc7KY6Z2VZ1zJ866nXU653rHTO9c6ZWc6o7T51RWkdcrOdUVnOuvQIj/f/62 t//p9p6p/vrb/W+yOj648vkc11/9f/36+xsccRFcRGxxxxxsVH//pppnHKcw54CZGOUOq6p+vv4i IiIiIiIiIiIgh/SSLNLFjUGZpjsU8MLiOUyS8t3y2SwSV1q19o2bvQ//8rkpEcWz3io7JwUOFwcR Ru6aGI5bwi2VNSuZC3C9F36CaXiWyKxcLf9nkM/9kdBfxF60WOUPF7CEGhiJbIt5EaRnIO0lorku T0/v/XqjZbI7CBYhFtM1iIu8w5Q5Q5x0GD0Ii5bItnz99/irtSI0jMRnaeD///////////////// /////////////kB0bXj/////IDpao///////8gOjfeJhR4AIAIAt/2eQz/2R0F/EXrRY5QplbmRz dHJlYW0gCmVuZG9iago2NSAwIG9iago0NzA0MAplbmRvYmoKNjQgMCBvYmoKPDwgL0xlbmd0aCA2 NiAwIFIgPj4Kc3RyZWFtCnEgNTk1IDAgMCA4NDEgMC4wMCAwLjAwIGNtICAxIGcgL09iajYzIERv IFEKZW5kc3RyZWFtCgplbmRvYmoKNjYgMCBvYmoKNDMKZW5kb2JqCjY3IDAgb2JqCjw8Ci9UeXBl IC9QYWdlCi9NZWRpYUJveCBbMCAwIDU5NSA4NDFdCi9Dcm9wQm94IFswIDAgNTk1IDg0MV0KL1Bh cmVudCAyIDAgUgogL1JvdGF0ZSAwIC9SZXNvdXJjZXMgPDwKL1Byb2NTZXQgWy9QREYgL0ltYWdl QyAvSW1hZ2VCIC9JbWFnZUldCi9YT2JqZWN0IDw8Ci9PYmo2OCA2OCAwIFIgICA+Pgo+PgovQ29u dGVudHMgWyA2OSAwIFIgIF0KPj4KZW5kb2JqCjY4IDAgb2JqCjw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvTmFtZSAvT2JqNjggL1dpZHRoIDI0ODAgL0hlaWdodCAzNTA3IC9Db2xv clNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCAxIC9M ZW5ndGggNzAgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAt MSAvQ29sdW1ucyAyNDgwID4+ID4+IHN0cmVhbQryVqMlSIDikvx4yUogOKa/2UMHjIDphfyLoaUS A4SqPkVRAcWVEfIovH5ElH/+QHQJRzs0VlALhQkBcwo5karkBcwoj8gOgSJC4xkB0CUcgOgSj/// //yA6BqP5AdGl4/5JOJhRlKUZVVE2vH+QHRpR//kB0aUf/////5AdGlH/yA6BLx5ZzRR//////// /+Wli8cgNMceQHQNR8gOgaj/kB0D4//////////////5AdAlGQHTCj///////////yA6U+ohKOQH RpR/yA6BqP5AdA1H/kB0DVfK5QIMEyAqFrL5kBUs+gg7jqx/urYWxVhFsqYZ4+bT+/K4XiO/qVxQ MbLZU0e8x4Qh/W3z2e32l3iP9/2EwliOVygUM1hQmI0XgdBB9P7LZS/ddtfFLDCLZUwXj2dHff/K 4sz+I0HdGh+m/tuWyl/f9sV2Hfw5bIUGIaaWIs6JaQIt4/vxH/+VwulcrEhaLzoeWyaRfut7Pa+N AgV60t5u91aHrjv7VS0gRSuFzEUMrlIUNUhzZ7lsqq03ceQRpGXcrlIVnw7uku+Zspab7X3G15XF fprsY7ayCNlbC2Oc/t/LZWEYvgh6VKJ4c7nf/bsL+P//sceDCjlMip0y0lVZ4Y1c2v3r/+I/mp01 EflMiWdff/HeMgOgaj8gOgaj8gOgXH8gOgSj/yA6BqPkB0CUf/5AdAlH8gOgSj5AdA1H5AdA1H+Q HQJR/kB0CUf/IDpjj//IDoEo5AdA1H5AdA1H////IDpj1H///yA6BKP/////5TIUqf8pkSDHzOUO U5T7iI3+VytfK4uEEYTov3hB//LZS7a9gwlVii2VIMWFxkKPs53/1K4XiO9eVxQMFsqr4IhWm8x6 d7RqPfT6ruI9bWwYLK5XsQuGFUbkBUKXH8tlZj/wmvQIjz04Tfrbu+3Udvw2OV1JNt03a4jryuKB j50f/1xeOVyxwnRbugm++vf8x3XxS0Mtkkug85FhxFuUypUrlEPPX/RAVWO3j8tlL6HfrNz9UWyF Bi78RmPv+5XK/qojf+v/3ajyuF5aC32WgVE0F8zM0KadCuKB+k8ef4fZMfDzoxlmUP2ixyhwgw/w hEMMj8WtDjIVmUJx5ZmCvmcofBPK4X0IeEvEafloFyEeE5XFIuiPLNfERpWWZl6ej/nR7+v1ffvf j2t8WKQ7XGf8rlZfCY+a2WgUZiHT71bq9dOWZp7/LMmL0vC219cVazueN20v5XBEx/cYX8bbqVyn eOp9C10x9X95bKX4y0FbLMwLX83efut9/iPEb8pkWCyuV9VnadHLQWmNQg/NHpNlmad6cszxP6/0 bu/odNrxirtWc4YUcrimPzCM0W4pF+f/TULlutMxC/rX8f8772//vCyzNPEa/uWYdLf/yzOCQy8v r6Vpu9K+dzw70xG2v8RYUV/DCDX3EfqVwtFuVq2OVylWW5jI6THroRQYW7y3Woux088GvdlmP/Gm 6QIj19d6p8uiOoIUv/ESNpFpQj1//JOduKtLXmOxg0LHFL/p1+IMIariIrK5ai2UsoTI8W5UuFdM mYg53+EGV1nr3ov663LdIqhBt/qEy4X/9aXlcqi4Xfhqbv62NR7YYVqbtivYoXeGENMLWIiLxyuF 2i3MGYM7PlcKzf9PTv1PD95XE2XCQkn4V9fylBjcszIwy0i1Wpu//6Yxr0uY/9Gf7jSf+q/The7X +IhpemKX4hhCLTHxGlusrlUNceTYky9cmxaGK5ag8X7y8O8rkjX4b/TurD30YdPwxj1/dr8tItUO HH8Yj/vWxFSuF5blW1K5RZbiYhW48YYXwuEyusQ6uSHvND+6N66dyzMuuN/1CZdJf5XKgXz1CEbn 022v9hRbEVOjbwZ25Ta3b7zDmHnb2qHFoQ0LvxERRuyuKbvy3C8wv5ePadnZqQj6wuCBldZq/BEf tEoZXUhL+lvBA2EizNVu+vSedzvvEf7/6w96+u28M/36hhX8swdL+I2K/TLhYi0GF2vwwjvkR1sb U/YiItCryzKIXWVwvLcVRhFQjLVAmLyuVCBOzW7CGNQuF0EZaMvUYc74Ij/BEf0aQget67rt1LMm f9LdLezkjfCf7//jxRcP33retPCfb0/T9TyGM99+OI4j4YL8WmmrI6I6I9H5hRDCYSERr0nEXZU1 a1K5Sp/iMWtMtynEY9H9T6ISMiCMtEjOeyh+/T01ERH/0jW1PVvfunfLMDt90Thjb3LMu6HHr32v VGR+1bXN2Ycp/uscSn66ENvd0oOMR8aYYWbvFp2KfBS6iIYIWkCBC5XC8Rp5XFAwW5hmCKtNPXtS C52kZj/NBb+YfZF2EzvkYXZkGy+I2oQeFTddkzRHSa068Uvt7hTvBCI6tAiP2WY7Nl7K4U/zQMaV yY/et1feVywPiv7uDO7X/hA/oIjHDukbir+rbv6/XbVFnD1x46DDUXV/zBrYqEGmGr20FYu0vX30 IsUO1h2KjS2FxYTQsINNMV/EREQ1Ecm5dD0GR8jxHRNM7ryF80FDlRsRENT3ed3GQV0Itb78pZhB mQt4jmw8f9CYet69uil5hginRFFzOmyDvrfemhGgyOFpp73v3H9f+1+qUZ/tT/6+/DUZu9j9jtGX hixVf/qNQ0ONDvgzJpWIiI08Rk3Bo7D6ggZCsq8hedgVU/qSlplOLggzIhH66zW9MJ9p+3p6RnaL xaNe1vpN19CtN2uyOl/roloYV2JT6Eevva1g0NGHOPbq9Js5zI2vxD2rGqF+9AmX+7FNf9qi4HGm h5uQ7FbxEREWqeI8m6hjCDOz5LMvlWiVkTNEVWZ2dmvhNtU1PGajTMtUYVIN+udQiNb0G+Cd6fud 96Xo0YTf190t0Yc8afp/R33//6/u/V/e/r/9+/+v7UEKb0u3urbV1/2lWq266sRVpPrYoGdTEbxs MK1DX6hrYQtMQju4MUxHEQwmCDQsJqIl0IgwVMZZCnILmsISs9kXaaSZ2JetOYLNDJmZyOsEGZTC SbmLanfn0k2m34UvybC7spWYCJLbadOjQ6SndzDmjcEQoLTXp4/pvr6f4Iijh9TQU/9Bft+k6xT0 To2hoe9KcLamPb7/D+CDj7Gtn06S2xsaTYhKI+0trFqw31hhY4vFobuwsMVEeYcrIuLQYUm4FTzV CaYiMmwqipBDueIiNM+lKUGCF5CZC/pzbfnUJnYl/qaNr2ZHi7vWf2p81NfrT3cYq2RPMD6Dr1O7 xXWmhu2RKLhTsYy4Rd6z7n+Ycw8f9OvCzOcd940Lq1P9qblr+L56bS7IYcfGtusOuNiuoX3xpRFW h5lnVtLm+I0ItDxERGTYoZUuEGSl2dwyPkpirIqaOyec6Ld7q3n0EyUpM7uQdmSPQeFa9JzW7ylm EG+p9Ur3Rn3ek+8TD4T6enXr3qr7RnTa3+//e/f6p63q6v+sevW927D/VrfS3gh/Tqh4YVimNZ/b aSVitpLYpqK+KZQ5blDhfYWbnDCDBBp6aFoRegxVcRERDCx2E/EwhERGnJsKo/kKjtVJIhfTslIh SkakmQzCkrFOwNGVZfCSBgqNdOEFKWRxk4Uuk+845h7DBUrmcUiT7aRGPtFw9au4YgqdJhTzo0Pn eHuE//bBgvesab1bXW4IV+PmNc3e38U9P39tL/s977it8GYcF2tqrEVHbHDS10PHEa7DeNuriGEs x82XcGFHEZj2noOLkYg1Ox+EIiOIsFEVMi3GW6nF2VKIsi5nazGEpkLNap4IZfTTBTsS0M7p2p3d IjfauCnai0Ed2LXfni+jPsIlHufdHryJMuEWN68ECI+P2fU2el6u16ugTdOwwqTW/an/YrutpfHj Y1G7tK+o9Un0F8MU6rM7L4IVPujOcNNDtMRVBjqz6KUGIiI1g4M25gwW4MIQ9RzoxccWpbkmYRUo Z5xp2RQMEKzucSiJPMIyIQjXUi9ZNN89hU0ztOjuaoER+2eDX/603OwQ89ndoKdmqvW40+/d6MP4 PsENO6+lde79dozg+q//u3637+DBt6O53e99bUFLoF6Q/3Bu/3r/T0hFAh/0oeP/XEcMK1U/29cV +wQqGmKDNuZwvxFc3O2/sIMJrrabquKBmwKIiIiDCxx8YiItSbFqJTjLdTi7JY7zucQNFXk+R0Zx UkduqFrqes9nWCZ11QjUmYpLxeO7y+dnVnc7tAiP2/Wqe+SkIEGm4Tsmgf/X/e1O77mg10kaDPXV 6pbpb3vrv4pPO5307c77Rn82ev+3V9f9X7a3aX13vuu9QhaHpfX/+//7TdjSfr2PBDv+3r/+h9BO I5uz/wtaX8MLt9XWtppp/2qDMoFXaTFd6vanZqFiIYQtDjTtNMYYWxFRFIKIiLtC0ItBqZNKyyuh ERBhDLIlCDLdTi7OzDL53EXgpB53TOzEdiXiyKZ0109BGsJhBkzGU5yTETud3Bgq2rzBFnd5fRY7 rshV92Kne6M/z6Rd8pQYhBtgifaniSkSkuDBL9dsXCFdW/S9f5K7/X87uLhZeHfWvXaMOeO6xf99 EY4K/Df7x/19jX1uqmCT21P9h7tq9jXd6WNJi1c+kMfDGOkjHv7vDVMUxUMjoJ+rw1rtb+IsJhIR z/Fw50DF7Bgk8cR3ERWDFinazzQs6LYMELUrhaO6IRJdCIlOhGVyjTO3dnYlnbjIiL5QwgZT5fKl yTCPXO1FaYXTcJ2Q8wZGCnYlyDlZ00E3QIj9/PjXggdXCFgp2oCzw/3W+6vO+/Rh+iJGW/z5f0v+ rXfLn09zwm4QNT/wQX6/r+v3/1/HxBEwvBDb1BMj4X/+F/7+N11+oim6b13/px7PbsHlmCFZQ5eB RG1DC3pRHetqThgKdiM8ShBxaFoM27GxHsRXqdqAuG3fhhNKwpj2nqbihyh8KO+IjMiDCaoMIaaE Xn2BhVUREREREZbAZXFM7DyForSHmEf1PpMqWR0EzueQmQvKCKszsWXX089IRk0CnTyUBVTO+lOz WO6uv/693zIK1NDJkYTNYTPeUylr++9I35+/PnTSdC+lx/33477mZEdYf6ueDW0btvlmadiOOGF3 64t9it/ehf76SG59DeuNr6v95SgxUGXBQ+ZzvmfDC4IUyxPNZQ5Q+0jG9baH9oXxuj/Fk0C0JVha EQ263iqZz0ZEswcMfa/WgZgpXSFreaAvP/8tIEUREReeecIpk5GDG6X72i3JjxiIiNOjOVZTxeZE caoQ8QYTiIaEREflutwiL8rhUUoMEqMjxCo7nkujojCNojxCZKzMizISHlcpCe+dmoQ6NBhCIzWK md9FXBBoGSoxrPBro7/XToKjQyZGEzVuE3Qedzvem175u1O7Z4PjReUm0L+a2QmjR+471uRtlwlD W4q8IaeeDW+0vSbLM0/6/rr69X/7/Tk/7lmTa/vX6am531/f7/9/WEPfT7fj7ZzjW6c9/16XVm5b zCXtrDCUR+VsF3S1Q7XFQQ74jfudzxtRsU017WxWwwlfTa9pZZQpfxYQYQYQtTIjTSN9inoGfZxU 6MRj9xERERDCHaH2vXvlulIRERO9UIzH2/K5RJkKRKI7EoRaeK57KUGCUq4M7crKnl8qEdmMqI7E 4RfXryEMlDC2dEmUM28IM7RoGSjDC3zwa/bKsOCJ+ccNN7dQnosdncCOp7H40/j1iGHO/7amd6CD qQn9vW9wRezV4YZhJd/ST/aN3/Hvrxsev6VZMg9PQk/v11BCmHgiY///0//vzOU96wwcx500EH2q BCr8MpzWrUx3ZtLHoXhhZIcESqSriE9qquqi4vXnKI1+xQNDEK+tiKDLcocFFBeGFysBjm7EQwuT 25GDC2g4iGvQjWdGriMJoaDCxYIjr5j/epXKTOw4RERERnIiL0Iwg0ipIyS8REaJuGFJWKZVoiIv 5G8riBKBBwTCmXmCDW4MhBSvenpsERxRIfVrwwpkl9o3urhRgg9I0UCI887hoscp+6Tf0Xehqrp8 QYcIR/csw0//a762/9ZZhLr+MwnPevvR0S//vjnesGr0ul2CCs9/f38MWhxpXrEJjMlkMOv5j8Gt pWIqErVpfERBuf4NbUKboM5cfWhEWEGCqvYQIZaRYoiIn8REk+hlcrWJxAztM6Zka52t5KMKU+Xy nRTs2YX/yHTwtprZkM8f8GCJvX6BzI4UkGEimgr+SiN2zQZ4XgiPPwnpUn52pxcKtlKDCTuCJuhS 78wakozkdc5T9RoEIswyi+PvvWm+E3//pppp91RLGbk77U/65hyhynO/7TX/2E/+L9aavx9prERf +K3r/2t/c37oz/+I/a8zsvtpL2mrTtUv/Vd9+thhIaDHEVxGIiJ2ahYjEf4iI7FODtcjHwv6iwhD hhNMpGcYam/k2GmLiIiIh3VZXC1IRcUOvh2bUIqVyjTkMBRtzPWSVnKZFUR89qGu8387fUJ6odkr i+VGp3NBgv4SoIc1s6hJwRYW8FsflKhI49UnXpvfCJj/3IoKCJUGJ3PHudzxbOSugRf8En/Xd/0/ 8ddLk4YCJux5XFAxCJbgyQqdC+//X/vQTk0DGhsMP/7S+5y1rtUjYUOU+GktktkkugvfdNr9bpWv iLxmOZGDURT+xsex2e4asR/M7/8jWUNQh42Kaa8GN+LKkYCDC2Ewh2g48RGf4iIhxlctQi5DUFLx 2axdnYnE0MvHUzEQmdl8peIJ0/Tqm/yF5B0g4XITytqjOnqd91wn8h3ZKAnBLr0luqf/3nmvzy+n f52nZcJ3Vk5mEpFF/hBI3fBMx/66fXrwhGRDTLhX3SoTSMBOv7XerU3fv4f+IILtdrIkyOF3qx0P dr1MjDan+ThhBHu6nc7//sRVBa2GEmGF8OP0EEtm4cXiMZ/lmEdoNb7FMVWD+yY4IjpDj/9OGEIi 00whxHBxH/nR+DiIiI851P8caHbk2LcRcRERDyuF52aoqYlg1K5UImFIVHfZUIq8haKcwpLM7E4a 57nUkdmrCZ1YTyQENaTCaggyr0DJyoscp/696eg7eaGCosdlOK+ViwhDvtntGHO+EjPqd+jT+k2C JRhBsKd050FFWo3x1v10tk6I6Loj6pBvunBRV0SdEzX2pZmV4ar//1hCIjr9dF3q532vqjDnfR/2 e0OcK7f/v39f/+9rHW/45h/bfH3pTouoIb8P6+7Lr/7/R+s9+tBWNbeDBJK1ncZjtf4jnP+38znH /G8U/S+xTKHLHOOE2EsNra3dTD97bq/QtCOLQtC44MELQixWDGxTTHml/GhxGf4iIjsIQ4aFqnkg tfESFQi4j1iDCn+WkCKVyjOyGdgQRzuiERHx5mggypaR3TITITKkiESkLRqEJpkDyp79VRbvRtoK j5ICKmQ5JVQZTmgZKAgjfhB+gQ/QZrEwmEiVBEbePdd632e69GnV5xxS1PDggeZNK2+nIlFwrFzu eGT5hF9SdG0R0qQbR3O6VQwpu2e1c35u6LMri/hhf+v1QjTQjr9szZcLVULH/pq2e07odq8/0bc/ /9//7m/6/p40nzuYfpD/+M/xn+6/bU/f7RnK2P/a1QIv9Rdhr+e7v/4MEvxV7CrZuoYj/nZmiW77 FPx0x9+xVt1rEZEgXz/xH/xEMIRscaHDCGMf45j+Gc96jNyERFpplHUyO0M1MfXETsFxEREZuiI7 arLdKRFokrOx1Z2JGIndFP+IqVyoyPHcQTCDJWVhAzWRyhklZEPIVECaYi1SwQqqB1fsgrTIbhwS DNZ3lLZwxoER904In4WjW4TcERyIhF4jyEqGhOP0Z3uTMwkUZRp+m+b1XmH+b6egwyQC873RnCbz DSeEHVBawQP0robL5Hwr/V6tiDD1fp383+b6MHo0Cv8swO91xEa19eobZeHf//tdff9flzyzM/tb Z9SEH7//St/Vf/r/te1H1771KXoGCc6LrxH5Pgggw8bf/te76a6zf01/YikIr4j2wuEEx4IdoMLE cR2mvrOjbf3aWyOqWalg0ogg8cR/EcR6xH1DTORixZz2mmKgg8scoc45Q+THJj50Zj//+Ii4iIhh QhhCIvBC401U1M1O81lDnHlmDhiI0IiIiIiLQi0IvXERBmaZyuUI/HZqj0L71d+/Y/39+WwF/rUt gqEghgmRxrSjRu5G4KFQyuUYgzthS/uItnOhyuF53PWVyoQ7NSVn+WkCKqGIjRY5Q/whDz947lsK Xxb9ntfGdmsC/QotgUjERyzOUPgtD0IanbBbkY+IiZoZ/1LQ6XlcLQUX5XFKwUf4RN4/BXLYFYtJ YWy7UInES0HUiNP4jhYyGGmPMOWOcfD5/6EXjMLS3zvVy4+uDGKBWmsO3ERBstgUwwesGDJuVqNg o4rIrTnM0wx/////////////////////+W5Wo/IDqtR//+QHVaj//yA6rUcgOq1H+QHVajkB1Wo+ QHVajkB1Wo8gOq1GQHVaj/8gOq1HkB1Wo/kB1WvH/kB1Wo+UxNR5AdVqPk3BFH+WDPjyA6rUfIDq tR8gOq14/yA6rUfIDqtR/+QHVaj/kB1Wo/yA6rUf5AdUKP//////kB1Qo////////////IDqhR8g Ogasqof//////////////////////////////+QHSd4///////////8riwQt0vhO6Lm/Cf/X72vY YWrEKy1AsCLC+PPpj/5brWVwSEZXCo7HF9BYflxg9oIPM4criYYoRBv22WoVnmPc9lcFQSg73GmE p3B71iCUGD01NmE4NxGg8LB4jqMeW6obcrioVBldSLLTR00aGmI0X7oOjW8IOt03XrVy1FlX/9dr df2GFbV17EKwldFqFgYhhMbHxDBNTHxDCfj3LdbXUri0f1K4iEYTT5BCC3LAYZoER5rYbp4TfzQW +p3fbytsjhaD37lqLH279d0vvYboZ/9+vW4/626+2/trxqWoVhi7jw1FpLiIhiEPMfDCH4vy3Wl8 t1JJlfMg4g8Rq+ahDov+FW/fNm3+ZLAYSH/S9cEOYcockPfX0IvZyBCoZdgvj7Q+oMwDcoebtRFo XiMrhWTRm+VyoXsr5kIiEoT8rmqVM1CUXipzJLC4XT1dPNnj87neT5vLoKkJailF7+u2mhFUn2zn df62r421/Gbm5/Rn3WKf/jr83WtjrS/0IjQ1Nz+og0LTV1xEWI5XCs7tGEVy81K5QECplfPI2mFU L8GmObKBAr8P09XfM4eWoFK7euZEuYCiDDNM2qTj/p9JhDkHaZqu1TyMedEF9uVygJeoz/TCCGf8 +HjSYil4hXa35t0T8F9PdoGEPQ1/ERob+VxOK/4thJrnYhXGNzyO704Z3hmIqEQzDCxJ7Nbw300x 352SHTejRzn9hshOnqrNqt+yJU1zTN5HS7plqLH36r9NCP8tRSFuoIYIu+/Sr0FjVHamNt7UZ/sR ow5x1K5WNl7WgsW0r+sN6DsLjq0Y7/srd6oMIaaH7iIiIj/tupbkiMIrk01HBNM7VYvlQiFxO0Rt XRUtbUlYnjggV1ewtTxpegRH/Rv1tlq9dO680DGPeg//+/WjDvtV/Mf4rQfarb73Zyulsx2IpiK+ Nteu096wwSf4MEwQjN8MV2sREQwkI5bqRnaoijHhBp7OfRcBnaRl/CkgUkmSvMIRoIOt2EkGQRAi h4TvTaBEfe0Ei8YQjX71500Egg2lO+6/8VTozneu9/8EVCOLv268tQrR1XMJf03u6//TuhHbrw1b V/vS/sRURsV++sdnPa2FxxG8RDCnREWgwhiIiGCjJuYRkjk3BtMiwhVIiO4Q0GSwQhtOHRMei7hd ODwQOggbn+1O+eA+NOopK2Ib/f++z30/WQ9ZN9eGFYa2e40sIKhHFRtLELJDkx4YSusKyiIzdFqF EREallVoZbheZRnYEguQTYMrzUkGip50CHX3fRINNUlPdmct3vNBoptvOE3SDv9JNozuuz6/Td+N PQbsieYCsGE3r//7dJ8Vf1wUji/t7oznHoscKPdaFWtsWOLwhWwwosJtJhte2fU3cUDOoG7taYWu GFhhC4vG/EREbEZZFVzzUt1rO1tKIy3UxDtVQIEnCInkJ1QjomBDqEovIXMNVwqn/5tI3Zs8VH06 Gn77Xj7Pdnv9tvHYWI89r480DB0C5s86K1hDP8RmRmAbgiIiOW61naj+RqOxLKGevno1CHaj7f7r fCv3ow53VXTy3LGRwr6W2RH+3rgwv6D3VbU/0N/YPS6IDFpR+dyhyh/9ghv/8RfvB6hqMf3YxBnL sJRERrYqLhhS3W0Iwp2kOW5YC6DIplYZfIT0jRRFUv5oPlJ3W+KTdN873/+K+ZxgJ/yKKvtf+iMK /UkP2tqreoz/sMJNhJq9L7FMULEV9hMJoeIiMsmKW4XnYFp8/5FOGSWOmQbN/8vn86dwyCBFPff1 1VzWa1/vrfw2jdvhPfvV8MMj2L/eNiyOP0Or/hYwUvhQi42h9ZnKiDM9CKOgrtnPvuLuf2FBOQMF 5/thf+DODCVfYqIjVU7OhDsKIiIiI8t1mOyRGIl4heahlXy3UggIZ1EJR99JQt2jW/O53z/m7uk/ 9tRoa6s0RzX//+mEP+2eTZ9a//+001BCroZ/+OM0DFNr92tQZggr4hhT+mdGmh4iIiIMIZbhediW O1KpZHtIDISL4QZ2+Rvoh9qGF05BCD9srJ2YNW58d/FINzv12aDO94IEyKf9Ok799f/pu/luSmEX f+8x/9c7UDf1dL/OBiW4UFQK2NKNbSdrBMKopDYYUQzAN6Xsb4a2KewhEZyIYTxMrxERluF52Vo1 BOfztIKkQmSnI1msvhUZXU96/RY9wveEXD3wj6z+iQ/+m7qoxzvDt5OZHS09Df/6CEf+z3OD9xyx /mFRoKediOyOl/1oo7W+LoRHn+26m5+6S35FHMPjeOt9COIzkcWhaH4ijdERnRiJ2JYjLdUM7A3w gwgynZfOkVMYUhPNGZ2vR/UL0m0g6BEfv0a2dSL/p663vScL9fv9v2wiboSdLf9f+uE2mXC/6Mb+ h+mv7W/9LbSihn/YYSjVjWf9rM7L/2KjivYrDH8MJFuUOUOceGELtNA48WhEXEQYQg4y3LSER9Dh HZbGpl86RLMma0dlAi8gglL5/XmDMIJIER+2Gvfuk5xzPreezR/9NPv/qH/oiqI6X+u2v1dv4Qjx H+//xH9/9bXeZHNT6xpNpNAzdrtNbGxUY1fxEYQYQaGh4iIjk3EIqvUhMEGd9l8qOp6U9Jhb//Pj X7e7q6BEff/a1deT5dLh7df3aEeKQvreva36XORo3Zuthb1v+7xTEVXERoMJoeIgwQxk3GI7E6W6 zIMwjXEDrJfIwzZdiRoIOg/Yef97w295xw9YQPWazPmszvxDD3rluWAvTvTv2GGXTfmD/+v9MXf1 5kV/8EU9QRMeh7X1f3+IyUaCD//7UbV6iE8/4ji7FMUIZgsJf4hhMJ6ceamIiNDTRAYUKTdVhERl utZ2TJTUZVVLdUFQYKEyCYKakXRehJGuCJD5oYIYQjrThJpJtazuVHbCJvGnm/P0qSrba6C/odsI O///4//dYzCtI32fXX+0p32+sMKr+NjwY4jIEC50CjFprDrwogwhB50WUHnAaND00IjGxlusx2N9 lUpbqQQ7ULhhBlRkoFqncNFjs69hPP/yVmgg3ujOCI9UdwYdP51R9U7d35EE/6DCaTuWoNfXS/1u 9u1s5AhQRefMYIoer1/XHkoHtpaEdO2q7UGYKBWhqwhFistSsMZu1XGDOChPxF4TXiMx8RGciL3L dVzsSRGQj8rlBhAwg7INPUEDVBw1M0QvITIRHUhGESdo1tGhw9SVCGoSwgeCNOm6DkYd6rokO6Te 64b9EnokOtGn+v7Ip3zvdGeGycMJBstQDvv+YSwwv7+tfbCWrrYIndD+/5nKc8bWrHaV1mg3mH// uIu3XYTFRHC6P9t/fexlqJwxDL3NLC/4rY/YXEZkWsaFoaETVTH2qERERfqPcrhSO6dlIjCJEf3a 2sGE7uyUxJoxEXGI/hr7dH8IaD+dmDR33C/ChEhw5XEwwVuMahv3V75/z010KZFp/31HDZaggSzO cfzjsL/XD3XCD4nsVP52oQReX0m1Q/VF+/6oU/9/ZybqE99+FxHDCU/42PfQi8LaDFerC+ItCDBB hDs/wYK+IiIiLYWTcpyeYhKVymOw87V65NEwnnd2p9WCUMl4jWP7020pBEEHIPzJEfv/2goba4Qf 93oG6l2d81md7zO/v3sQoTb07+k3lqF0Z/VYyjc4vvb36bcEGvBCl9P/XVbb03/NBT4hpa/WCG7H Pb+DNsbjccNJq1eob7f3apExynbGLGIMwi+3xERYIT6DCYTi1t8RERG2Ow3lcKyaMxHZdno7Gt3L SBF/vJWy+CBlRnTER9PTa2qqf/V06BEfefG+sriZEdqr03Xq++QGC3Qjf/+rM4uFtx/6/+u35kdb r/p54Keh/hpa+t44uutimGEmIqwqrN2O0xTsU+7xEMJhBhC48RERlcryuo4QZ3mXzskS0GE24bZW IjER0SfRr/UGS3ycwhDIxL20d9rOOD38EPT+94b7hTw0vr7Qg3+k6M5USDXUv//1X9toPdW+uRGX JV//h21r64hAh3/8OhGxHcE0xQV/DlqK/sKkCDMXpcZJ6DoyIYQu44tCwcXEREbiZAWWuopXF87n 2QtFVh5/U/wahBkoP+t5/TTNRb3o7Amqo2UaHD/dkvBhtvV05tdv+2RRT7+mJagv0ONJYa/7/ScE Tuh+YXqaF0bs3RJoPW0k4jh937hOz/YYX8tRWGPjUL9COc+W1ALERrGsRGY+IjOj8m5Z0L8rlMd6 I7Ald/0ygIEy/DJdEfMSDIHiP0GF4aEbDX6NPBEfyMdTjh/Ox1VN12w5+iGH8Jlwiul4ZFpbDDLo 8GO6f+6jxqSkuM3Jtb1BE74RcOWOSeCIIAwV/YYSfo6D1JRhJ4QuESsP1bFRHCc0CRBeqBFD47Ca hKkl+wniIhhU7OFhYuIxERFoZbrSOy+T4yuFafkXR/5WwwQnYU6QJ5KsjaNf/sJZ67z+nZqMwdZ4 Nf0F0wm/OoT0y1AfK5SsafBtBer+ltTw7lcSBdbMwXYpvrvRnKjpK8P75S1Rzv9v7uqrvMjqzopv oeqH7/5ais/vV7cNdut/v9vqwYV+I5/wwqN//ilDIjSNBeK9fYr+PcLxDCEWc8XaHFqg1QInGIiI iwhGEWooFeJF8YLlcKzua4X0ygIdiuUsz0QnDp/pnZP/Oq4Yj6Rpv2E2ncHK4olKUrp+9/ngOENM uEVvdL3EGDLUB3VX/+sN0f8yIzd1BFDsvhL9f//DCURHaghRFUCCv61bFQm0uwgT8XGgwgZ98GCg zFohXxEcMQuCQ4gwmoXEan/K5UZ3zOxPIWjsnD8IMmbTOiM87NTzVm46tM7P2RBjlpAizRQndhA7 q0wn6w0xSpNozp09p/hN8NGiOnr57bpcJGfvlO6uv+rf302uUrNousMHuYi1APLSBFf39v/19NCN kXvlqKBQgh//v3X7+kF/CjtYjbjbWOrUZuhE7xGlYYS4YeKaViuyGN+dzw7FTQccoeGnaaVp+FzQ U5Q/+GFQiHFoMIRDCHhdCIa/LSBFERERFrEfsYjd1K4vlvpuxlpFi5/K2zstynRiITTJeITIwzkL Q9YPOgVYcghE+tsf/7Bw9Nr27OOFz9clhsscmP9Ju+InYEy4Tc0i4UGHCB23enLUAqhlbtR15FP3 tfLULhfIuyan/bz9Cr8V9UZyo0P4rhE7/rrP3jwXnQL5Fxu68w54dpbZaQIruPwn4Vw1Gh2Go4xE ecbwtivYhXERaoMIRDVRERLUVhS0gRSuVIrn4Q0zsaZfO6ZOGCDyWRfKhFPmEQ2bOdph63qdPXTT tbHoER/5oLHS2t68IH9b7UIN7oER99HH3X+8pQYFX+vNFq7qYPLUAr9fVvr6DLhK96y1Agn/RkfV f9f9ql9uv3QIU/sKbvr9o3exFe2tXqPbfVhNaH0+xQMykIr41iPiGh2mmh2KmHOPuIhgthC1QnvP cRERGOVxPOwRHeZ2ryjOrIz6lCO0kEwQZV5qLUEDuf/L6YQ0zWInYVOxHXrPjVGt2EEjTcGdIh3+ f6ujdp24XzDh2Et+d5Y1dCuGKp6DDZFHlqGOxl1p//bXYhsMQRahOXEcHZ5XV9GMjW0c/o1mCHDt 2m6tnN/3+jpgkKRaQKoZ+g8cNJDhheI0OIU7niPxUrYL8R7cL7iLP/n+s1M51BfxFnREZkacR/y0 gRRERER/GW6zlQtjlcFithg65HQU7+KERVHYExqVxa9CMmgVMn0wgwa/PBb6/0W7Hu8J0bs/fenL ULO+Ktve8hR5pm4jpUm7/WLjxpoRVPl0R8jotJSUERB9/bOOUP++IiGNCnpdRM8UbnreSHVqdAh2 ahf96nQ4OLFJQv+Gv3aZ9zOspir9CIi1XE7A0IqWkCKpbA0QyuUsvk0rO6EVhEpZiKdEvnOq+e5D mlP1QdkvDQIj9/Dnt9Np1nRhPW783ezH1tU//76BtfIoiPl0CKerrVtTwyAwNV9v360IiP/dLUf4 Q/e+vf9XvrvxHOhv9rdeNKbopL9pbaUa2KrKcpj/Y04aTSUNC9CI000xtcREQwWGENEBmqiIjxlc Fjv87WkVa52OKdqUE0yFRKmXzWyPXC2n66v1pGfuutyuJRcLO541Wa0CKeqM+0Z+WoYVf/7MwwRN lwtb1uWoXggy0gVXn79/X///jFX/j50NpG76+tIER7rbdUvj99N9dPfeN1/29Y1/i0LQ0NDsRTFf lpAiiIi001H8ty3ERpRoiLpChs7UC6yuUzIPtVNBSCdk9mrsa8+VXyF0MiMJHXH7rcIG+GE0lPfw QJAiPvVOynDTS/iEWkPuhVab8wdqIYc8CF2Wory/+Gg9fqiKAuGy+rTeFy0gVdg4cPr2vQ+jiuls edj4MHDh7/3OiEXH1Q0CI+/w2HD2qxFeQxXe76/xkmgdiK/hPEVN38tIEWpCbWFNNjwSrX+MZ5Dh U01TzHv/xERERERG9bEVK4LnagjsCZiO7M1pqVxfsEGdo900yswYRaQUq6D+wiY7z2SgKN956eE8 IN9731cmSPJe0vqbJagPH9WEI+t2+nz6qt7//jenBDep0b3VDf8KO9sLda25aQIoM2wIJ+KhhZ/k oDvjcGC6YRMwX+FHoREceZqAeM5CEUZzj4ji8riUZKSIHkPK2mvl89HZeMM7NQnJWcpK5kHlPl8q MR0uELQfEGEMhyhOzp5AZou+d+phybtF/3rdX8fug0g08JtZ8PDm7Voz/stQDW9VrtXNIuF23q96 79OxFetf6+L6++/dq/dan//9eurlpFfDNzFiODBIfdciyU0DF9AhSj+SHTFfe4IbTpLRaieLhLTi GCBhDsUMIGYIIoGZqKNxERFhThE1TU/S0gRREREdxluFkdkmqyuFYQZ2BrI2iLsctIEUrlWqNDOm YZ2ahIZUIjpUyYzVkSTQwhSRnghaaBhCLTIhpyCalDlPGtXMOCI8i+bOOGlPbi7CEdGc790mE8IP g2jd3MUznezQZ3lqKz/a9PatiG6H+ltJ3RhzvT+7+v6379dN3W4Rbv/rfTqQ4JOfS6///cJ7+hsR wwlEFBhWI46/99/H0xTSHtLavbarcWmc8GVgQYSBTDuc91YYSHiny0gRWCEREWqP4iLTFD9GMYiI iGEGCteIxrK4vle0hlpFSqezsmR2fUjWd0yoRCchx4lOvZ2n0yZleerJoFCmsVlER/o1tP3rOoQK I236ee29/P1UXktQa7r+vvmbLhN53O+E5agPUtM1VCvvYfBrqP74qpaQIuvdb6G1N2/7tRHNzjVs MajX/bnuP/3s/eyaBbb4y1FbtNDQcPuNVxS1EaFoaecxmgofcRERBhCIlqFzLnK4UhrLSBFK4miO i6MIJnfR2kRVo7KOnGhERRSgwmmXyXyaJSUbv0sLZDYQYQzoy7kEAYKT2e80Gvq/+ncUmxSb539T u2eD5qd7LHLdlqaxw6vV/9LkExV6S4Qd0////Tw6v7Sbugb63X//D//+E9tLX9Y0od1HX+YalpAi w1YaWxpNK+tdq/42KYrjaUqqYpwrDCQ7XDCacMIWhaYWx+8RERDCEQwtNZNtUdhaEYjlusROacM7 EeWkWIjqW6kJtkzjBkgzByHUygkiIq+c8RqwnCHp2RYkzqEOjTxGjdW5hy4bU8NGo036T9DTpO6S u7c0O0btTPyAzRf67qsXpvoerM4wEHet1/k6VW//tSAwNc93WPf3Ttvf1UjHjjbCtpMUFULbFMMu 48Z/9iv1irbQ2gv5/tDQa4Qba2v9CDPsXBM6Xn+LQ8SXhEREREgM0VMZbrPR32ect1JrCUJnasQ6 IoRTxfJdUPMPmdhNOwtlDCB0vMek6NBnde+mQGaLO54f29XTvegRf4U9x/7X/23HS3//+rbr//Vb /cRtx381lZ+uv9WxUVdD9b9EBiF45z2E9X3rGoxaERDPP7EU0FhoREWmuJVoRGmQFIUm36R2to7B xPjCanYlXHsILId5AYUKjQKetk/jqEdkNeyCwYf/NAX3sMMfRu/XDZAYUr/zkQQMEvGhFDrG0CCN 9/oQQLznjgz7A5jWLjxHEZoLH2hDybpyJbiJAYUKEyk1IKKVES2L4wgzWEo/BBmpprct1jns70rp Ggw+LV6DVsNzud/04bncz0CL/69fb+2+uv1fftxr/+tkBhCu67+r1/9UMYr/kx8MLcf/artYIHY6 oLesR2K9gtrYio4iIi01ERIDKlLcKIYQM7B5PEIinZVI7osuN9hBkVs1RfKjWgg3YVUW/SXzUJpu 10E3DCq3qQGaKuS6YIjyM/p21QIuvRuj3CYsUJmy4XsGJ06Tycy6Wh+w2uvDS1oR/NpYabSNz6V/ mH+I2yskXiPD7aoER4v/0SOGc+VfTH9qRQmNvX48x4wg47FQg3EV/EadphU00PP30I7iIjERGTcs ZjKdnZCk2g+0Gdu0yoRTlg/RnfkYgmE9Qm0g3TYIc0bK2L3p6dJJuK//O5308m0P/9dvvBut5j9/ 69pOktr/fgmOPbS/1iwkKYrjYq1bQtNRnIiGEGFERGTdVUm+mUIjEmRGdoyERULpghkNhMisT6pn TT+tJ//y3JV0jeqmfXvvTNZR49XGTo3BFDydL3gwQP/8JhCMJlwvRAZothEoDnPf6mHBEfd3/GG0 CJ33IxzBj8cZ/jP8nDEHhB/Q2gvqq9REetr9/wZgGAojP8WE1i47xERERqTajGW6wgQM7MkTSluF aDTJojjKvVyNqno04QaDNQQ6BCKGYKDIhJnSMPb1dTD0vTQafa2/ekE3OOZ6N1qe8zh70gRHsER5 /rdWuhrsQYf1T9vX/pO9Jff/qxv/+99aS/+3jtJK37N19EOBIEPXu6sYV9Y2NYhVFLENM57S8e0F YIGZRWIuLi1P9rQWPERERFxGTa2Mt1jU76Ioil8twtbCkHCSE7Lojol8hMjfC35qCHUSIkUOf1P5 qE+pczCnnVfXVbu73hBI3JGHOOpuCffROP9rcJY1t0lb28E//xCBfuIQT7+MtywMWEwqCPb/YQR5 IaH6QjCVwzd9BBLrZ7sm5ThMmOUOcehSH3pG0qN2bscHEZSN+xoR//xGc6n9DW07TozlPIDEKIuI jOiIiLQiPHGTYhhPlusRIkwkQmdMKU6MctwsIhO7BO8/hQnkJEHUkZ04RJ1+CBEfC2dQh1CZ3O+v BRq8iwnBEfdJKvf6LudMwEfRN416MOeM7neQGCa+6v+mtqgnX9u/vv7/D6m6h3v/uu4/4jncZeGv ijH6/v/tV26+f88Pvp//uxUnBT8GN7/BjYj4+1i0whDiGxaHcO1vscRENCIhwwQsIWFLcsyjcoNx EkY7UcfhTsZIEQZHY2d7CCKIkUjGclgyIZg05GAwEbhWvmHOg4m1TRo3DFMVrmL+p4dXPYOwgwRF AIHr8aV9zEIYctyzc5mvz+71HVf4MPuoz6ZGM/kTf/v4j7WI50ZFT14jKEcH/df4dLShAs2FRERm PvZ1Aws8FQU7iC0LiMGIhpLEXhRHEGhGCiNSuCrpmSdCQGKFK4tumP/3/MoDHrghzH1ey1xXsocs cK9OLQ1V8RqLxlcS+UIyoOpfsIH/ReP+gge/1lri/iPvvdcGaCh7a+hdii1yYY+wliIzDnHLeWkW LiLjrlcKT9TKYx5XKBAgY1ReaMOd6CDetytgRTlri//+y1xoX/Po7oL/9sKltvd2Knc7u1GIsL3i 0P8f/8ri646n0TMQ7Qha9oMmZpjvRvpv9INo0Pt9dN+P9vrfv54KewwtsZATLri7EJhul9hO4xER eMrlEQFQVQQMaDO8R33RvkyMIGunQ3q2jQa366ry1yz3/52qBnLVAu/9/r42Gq8+nfxFLu/mPDPY TvXxERxHWJa40D+VylAzNPRM7Ojuc/O3MIGTNoM7Uo/j0NCceE76NBoaM4TaBEd/qnreE7lqikX/ /v4YeF//1/rftBrYrhh8737EV8OP/suAnpsP/aERp/+IiPrvqVwVGWqYipXFkmdjmTPCDOyRtb0H hM7Cwo9yt6NHmhr/pvp0azw/+9/Tbf///4IGC/t2v9CrVWIqwldk3BEdRaTTHwcRZhwsGbZIq4iI iMcrlSNopbPcJrd1um6BEfen19Wd9f/TO1l/+v/+171tXexFMMJCJaov2mKh2EGFDiMOW5Yw8rgv jK5QJCOzinZKdcIMEDosc4/LmjQZ6Io/CFrcx07aNcN8drX6bstUS//7fup72e8FCt/rfeOI7Cra X/mcpzj2K2Pb6N2EIhwYQtU3V2hERFDiKy3WObsri2pS0UZ2lKr59EzapqdgumLVU1QVqqjfQIuV ra7emE2jvhhK/0d8YnalQRapREex+b6DEIK9V+9ejdYjCM7L4TMKd9/wSYwROBpb3dFwVeg6Qf+I tC9PCbv4jT7vpRERvWVyrYioUvtVylZ0yso640CI/a6edledPW7r6/9DjswrLVFv+/EZapi/4i1+ 9IauxHvrWGF8QQrUGdp6lcEuVxWx73y2VpfX5bKkJK4kGF0jdsoc0AqGLjenjZzocrgvyuUCT/qI 0WOU+ghHltD9/Z5eL6lslmYCZuqtprmcqMRGh/yuCp7lcS0xa+PctksZaS0sVIdp05hweZyu589D dBL4lz/UWocQRWB0wYPlwmKstp1D//5AdF7d/H///////////////5baqo///////////8gOg1H/ //8gOqFH//kB1Qo/kB1Qo//IDpdR/IDpdeOQHS6jkB0uvH/kB0uo/IDpdR5AdLqPkB0uvGdpaJ0f RhHkbzCM4zzRF0bRhGEXRdEdEdF0R0R0YRdEfPZdEdGER0R0R0XRtF0XRjI6MI8jaLojo0zaMI4i AohREREREREREREREREREREREREREIIRES6EREnRojNF0R0XRhGER0R0YzGYRdF0XRHRdF0R0R0X RxEdGEYRhG0bRhEujaKhHER0ZoujCLovl0XRdEdEdGFxERERERERERERERERERERERIaLoRERERE RERPIp0cQxEREqEfRdH0bR9E6MIwjiN5hHER0cRdF0XRdF0XRdEdF0YRrRdF0bRdF0R0bRdGER0X RHzyLoujCiIiIiIiIiIiIiIiIicRtCIiIiIiIiR0EEOLKwococ8HcococpyoO53Kc7ncrChyhzuc cpzjnsqDjlDlQVZUyuKcrQ45TlEFQUmBspIIiIiIiIiIiIiIiIiIiEEIiKQIEJhJCJtG0IiR0XRh CEEyoPBTlDlOU5TlOccocpynKgocpynKsryplNtRiIiIiIiIiIiIiIiIiIiIiQaMI2i6MIjoxmMw iOjGXRHRHRHRHRHRhEdEdEdEdGMuiOjCI6L5hDJtaLQaoREREREREREREREREREROIwiOi6M0XRh GEbRdF0R0To2jaMIwjaMI4i6OiNogS+IiIiIiIiIiIiIiIibyOjCMIwi6MZdF0R0Xy+R0Xy6Lojo uiOi+XRhGER0cRHRHRtEdEdG8ujiLVF1ERERERERERERERERERERERZUI8jCMIwi6Loui6MIwiOi OiOiOi6MZdF0R8jovkdEdF8wiOiOiOjaLojoj5fL5dG0XRfLojouiOiOiPkfI6P5dEdEdEdDJt6L QaoREREREREREWUUIRERFIRERERFlWCER2cc454KHKHKcqDuU5xyrOOUOeyrKHKc45Q5XFDlQUEK Zo0dIIi4iIiIiIiIiIiIiIiIIEIicR5G0JxGEYRhGER0fRtGEfRxF0XRhF0XRdF0XRdF8uiOi6Lo uiOi+YRhEdG0cR0RZyEEoiIiIiIiIiIiIiIiIiIiIiIiIiIjgAgAgADjngococpyoAplbmRzdHJl YW0gCmVuZG9iago3MCAwIG9iagoxNTI5NgplbmRvYmoKNjkgMCBvYmoKPDwgL0xlbmd0aCA3MSAw IFIgPj4Kc3RyZWFtCnEgNTk1IDAgMCA4NDEgMC4wMCAwLjAwIGNtICAxIGcgL09iajY4IERvIFEK ZW5kc3RyZWFtCgplbmRvYmoKNzEgMCBvYmoKNDMKZW5kb2JqCjcyIDAgb2JqCjw8Ci9UeXBlIC9Q YWdlCi9NZWRpYUJveCBbMCAwIDU5NSA4NDFdCi9Dcm9wQm94IFswIDAgNTk1IDg0MV0KL1BhcmVu dCAyIDAgUgogL1JvdGF0ZSAwIC9SZXNvdXJjZXMgPDwKL1Byb2NTZXQgWy9QREYgL0ltYWdlQyAv SW1hZ2VCIC9JbWFnZUldCi9YT2JqZWN0IDw8Ci9PYmo3MyA3MyAwIFIgICA+Pgo+PgovQ29udGVu dHMgWyA3NCAwIFIgIF0KPj4KZW5kb2JqCjczIDAgb2JqCjw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvT2JqNzMgL1dpZHRoIDI0ODAgL0hlaWdodCAzNTA3IC9Db2xvclNw YWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCAxIC9MZW5n dGggNzUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAv Q29sdW1ucyAyNDgwID4+ID4+IHN0cmVhbQrIDurg8m9aBAk44bitKG/vXt6/+9RkB0uq6soml/u8 ZAdEKyiYyA6IVlE1jIDpdRkB0uvGQHS6rqMgOl1zV0liHkB0uhjIC9qMgOl145AdLqsZAdLr//+t /IC5C4nENlSMCZDqnHIDoj1IDcQxkB0uqUZAdLrxkB0Qt3jkB0uvGQHS6/8ZAdLrxyA6X48gOiO8 ZAdLr/xkB0uv4yA6XX/8cgNzLLoojIDpdeMgOl14yA6XRfiOQHALJKo8gOE0PiVtSA4kXZWxglZX ///9Lf9/SjIDpdf+PIDpfjIDpdePkB0Go////+QEzHH/+TYKy0floPxEf/////IDol+P///lMPyb Ai48fkB0Io/////////////IDqhR8gOqFH//+QHQij/+QHVCj/////8gMU+PyA6oUf/kB1QoyA6r UfkB0Io//IDqhR5AdUKMgOq+PyA6rUfyA6oUeQHVaj+QHVCj/LSVEUyKqI/IDqtR/yAxUUZAdVqP 8gOq1H8gOq1HkB1WvHyA6rXj8gOqOPkB1Wo8gOq1HyA6rXj8gOq1H8gOq1HIDqtR+QHVajkB1WvH 5AdVrx5AdVqPyA6rUfIDqtRyA6rXjyA6rUfyA6rXjyA6rUcgOpOnDUfkB1Qo/IDpj8EUDH+QHVaj /yA6rUfkB1WpZBPGP5AdVqOQHVajkB1Wo8gOq1HyA6rUcgOq1H8gOq1H/kB1Wo+QHVaj5AdVrx/I DqtR/LXJqOQHVajkB0mo+QHVa8eQHVaj8gOq1HyA6rUfyA6rUfIDqteP/kB1Wo/IDqtR5AdVqP5A dVqPIDqtR/kB1Wo////////////////yA6TUeQHSajyA6TUf8gOk1H/////ybBFH5Ta2vH////// ////+W0BKMgOk1H/yA6TUfyA6TUfkB1Io+QHSaj+QHSajyA6TUf//////IDpNR5AYWKP//////8g Ok1H//5AdFOP///yA6kUf/////kB0UW4/+QHFlR////yA6TXjkB0mo8gOpPcfkB1IoyA6kUfKZJF GQHSajIDqRR8gOk1GQHUij5AdV8eQHSaj5AdJqPkB0mo+QHUijkB1Io5AdSKOQHUij/IDpNRyA6k W/HIDqRR5AYhRLRqo/IDpNR/kB0mo5AdJqPIDqRR+QHSajyA6kUfIDpNWUIHIDqRR5AdJqOQHUij yA6kUfy0gNRkB1IvH/yA6kUf8gOpFH/5aw+W0oUR/5agfLUp92HHjLUQji6d4ZSYEh8gOpFH/8mS j+QHUij////+WqrRZqqtjHyA6kUf///5XULx///////kB1Wo5AQPxLOdbj////////////////// ////////////////5a6mo///////////5a6RROKErx/5AdMKP/ymzJR5AdMKP/8EFH////////+W yD7cZbIjpaj/lkqUf//yA6YUf//IDphR////+QHTCj///kB0wo/IDqRR//+W2IUfyA6BKQFVtDHy A6YUeQHQJR///8gOCyj//5AdMKP///5Zpqo5AdMKP5AdAlH8gOmFH///////////IDphR+QHTHHk B0CRD4jyA6YXj//////KaUkW4ouNlM0yGQEg1H5AdMKP///////+QGKtqPkBRIo////////8gOin 4/////5AdAlH//kBhaompFlA1Ef+QGq1EupAaQriP/5AYSqP///IDoEo///ymOUttZQ0o/5TNOJh EdRGWUhR//////BKP5apNUvZ22Iy2x1EfkB0CUfIDoEo+QHQJR/5AdAlH/kB0DUfIDoEo/kB0CUc gOgaj5AdMKOQHQJR/IDoEo+WksqMgOgajyA6BKPIDoGo8gOgaj5AdA1H/+VwpRkB0CUgMjGP/IDp hRyA6BqPkB0wvHkB0DXj5AdAlHkB0DUeQHQJR8gOgSj/kB0CUfICoTiW+KPkB0CUfkB0xaj5AdA1 H8gOmP3jIDoGo//kBSiJsIUR//8gOmFHyA6BqOWwFL/+PywNcf/kB0DUf+WFLj/y2xe8f8gOjSj/ /8gOgaj///5apCj/8tJTUf/8gOgaj///lmCaj///8tILzC4xyA6BLx/+QHRpR////IDphR////// /lsraj//+WBC8f/yAuFqsf////yAuhR////LQIUf///8sqn3j/IDpatx////////lNhaj//////l rKdvWER1EcrhSj////5AdGlH8gOjSj/IDo0o//////5kqqP/////5ARXx/kB0CXjwAQAQAAKZW5k c3RyZWFtIAplbmRvYmoKNzUgMCBvYmoKMTY4MAplbmRvYmoKNzQgMCBvYmoKPDwgL0xlbmd0aCA3 NiAwIFIgPj4Kc3RyZWFtCnEgNTk1IDAgMCA4NDEgMC4wMCAwLjAwIGNtICAxIGcgL09iajczIERv IFEKZW5kc3RyZWFtCgplbmRvYmoKNzYgMCBvYmoKNDMKZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUg L1BhZ2VzCi9LaWRzIFsgMSAwIFIgNyAwIFIgMTIgMCBSIDE3IDAgUiAyMiAwIFIgMjcgMCBSIDMy IDAgUiAzNyAwIFIgNDIgMCBSIDQ3IDAgUiA1MiAwIFIgNTcgMCBSIDYyIDAgUiA2NyAwIFIgNzIg MCBSXQovQ291bnQgMTUKPj4KZW5kb2JqCjc3IDAgb2JqCjw8Ci9UeXBlIC9DYXRhbG9nIAovUGFn ZXMgMiAwIFIgCj4+CmVuZG9iago3OCAwIG9iago8PCAvQ3JlYXRvciAoQ2Fub24gICAgICAgKQov Q3JlYXRpb25EYXRlIChEOjIwMTAwNzA2MTI0MDE4KzAxMDApCi9BdXRob3IgKCkKL1Byb2R1Y2Vy ICgpCi9UaXRsZSAoKQovU3ViamVjdCAoSW1hZ2UpCj4+CgplbmRvYmoKeHJlZgowIDc5IAowMDAw MDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTYgMDAwMDAgbiAKMDAwMDU4ODIyMyAwMDAwMCBuIAow MDAwMDAwMjI4IDAwMDAwIG4gCjAwMDAwNDkwODYgMDAwMDAgbiAKMDAwMDA0OTA2NSAwMDAwMCBu IAowMDAwMDQ5MTgyIDAwMDAwIG4gCjAwMDAwNDkyMDAgMDAwMDAgbiAKMDAwMDA0OTQxMiAwMDAw MCBuIAowMDAwMTA3MDQwIDAwMDAwIG4gCjAwMDAxMDcwMTggMDAwMDAgbiAKMDAwMDEwNzEzNyAw MDAwMCBuIAowMDAwMTA3MTU2IDAwMDAwIG4gCjAwMDAxMDczNzIgMDAwMDAgbiAKMDAwMDE2NzQw MiAwMDAwMCBuIAowMDAwMTY3MzgwIDAwMDAwIG4gCjAwMDAxNjc1MDEgMDAwMDAgbiAKMDAwMDE2 NzUyMCAwMDAwMCBuIAowMDAwMTY3NzM2IDAwMDAwIG4gCjAwMDAyMTg4NzAgMDAwMDAgbiAKMDAw MDIxODg0OCAwMDAwMCBuIAowMDAwMjE4OTY5IDAwMDAwIG4gCjAwMDAyMTg5ODggMDAwMDAgbiAK MDAwMDIxOTIwNCAwMDAwMCBuIAowMDAwMjU0Nzg2IDAwMDAwIG4gCjAwMDAyNTQ3NjQgMDAwMDAg biAKMDAwMDI1NDg4NSAwMDAwMCBuIAowMDAwMjU0OTA0IDAwMDAwIG4gCjAwMDAyNTUxMjAgMDAw MDAgbiAKMDAwMDMwNTgwNiAwMDAwMCBuIAowMDAwMzA1Nzg0IDAwMDAwIG4gCjAwMDAzMDU5MDUg MDAwMDAgbiAKMDAwMDMwNTkyNCAwMDAwMCBuIAowMDAwMzA2MTQwIDAwMDAwIG4gCjAwMDAzMzg2 NTAgMDAwMDAgbiAKMDAwMDMzODYyOCAwMDAwMCBuIAowMDAwMzM4NzQ5IDAwMDAwIG4gCjAwMDAz Mzg3NjggMDAwMDAgbiAKMDAwMDMzODk4NCAwMDAwMCBuIAowMDAwNDAyODIyIDAwMDAwIG4gCjAw MDA0MDI4MDAgMDAwMDAgbiAKMDAwMDQwMjkyMSAwMDAwMCBuIAowMDAwNDAyOTQwIDAwMDAwIG4g CjAwMDA0MDMxNTYgMDAwMDAgbiAKMDAwMDQzNzY5OCAwMDAwMCBuIAowMDAwNDM3Njc2IDAwMDAw IG4gCjAwMDA0Mzc3OTcgMDAwMDAgbiAKMDAwMDQzNzgxNiAwMDAwMCBuIAowMDAwNDM4MDMyIDAw MDAwIG4gCjAwMDA0NjE1NjYgMDAwMDAgbiAKMDAwMDQ2MTU0NCAwMDAwMCBuIAowMDAwNDYxNjY1 IDAwMDAwIG4gCjAwMDA0NjE2ODQgMDAwMDAgbiAKMDAwMDQ2MTkwMCAwMDAwMCBuIAowMDAwNDky NDEwIDAwMDAwIG4gCjAwMDA0OTIzODggMDAwMDAgbiAKMDAwMDQ5MjUwOSAwMDAwMCBuIAowMDAw NDkyNTI4IDAwMDAwIG4gCjAwMDA0OTI3NDQgMDAwMDAgbiAKMDAwMDUyMjI3OCAwMDAwMCBuIAow MDAwNTIyMjU2IDAwMDAwIG4gCjAwMDA1MjIzNzcgMDAwMDAgbiAKMDAwMDUyMjM5NiAwMDAwMCBu IAowMDAwNTIyNjEyIDAwMDAwIG4gCjAwMDA1Njk5MjIgMDAwMDAgbiAKMDAwMDU2OTkwMCAwMDAw MCBuIAowMDAwNTcwMDIxIDAwMDAwIG4gCjAwMDA1NzAwNDAgMDAwMDAgbiAKMDAwMDU3MDI1NiAw MDAwMCBuIAowMDAwNTg1ODIyIDAwMDAwIG4gCjAwMDA1ODU4MDAgMDAwMDAgbiAKMDAwMDU4NTky MSAwMDAwMCBuIAowMDAwNTg1OTQwIDAwMDAwIG4gCjAwMDA1ODYxNTYgMDAwMDAgbiAKMDAwMDU4 ODEwNSAwMDAwMCBuIAowMDAwNTg4MDg0IDAwMDAwIG4gCjAwMDA1ODgyMDQgMDAwMDAgbiAKMDAw MDU4ODM3OSAwMDAwMCBuIAowMDAwNTg4NDMxIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgNzkK L1Jvb3QgNzcgMCBSCi9JbmZvIDc4IDAgUgo+PgpzdGFydHhyZWYKICAgIDU4ODU2NwolJUVPRgo= --Apple-Mail-89-58687355 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit

--Apple-Mail-89-58687355-- --Apple-Mail-88-58687354-- From Matthew.Anderson@us.elster.com Tue Jul 13 02:38:40 2010 Return-Path: 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 27AAA3A6858 for ; Tue, 13 Jul 2010 02:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 TtJFe0vxYj86 for ; Tue, 13 Jul 2010 02:38:39 -0700 (PDT) Received: from mail53.messagelabs.com (mail53.messagelabs.com [216.82.249.211]) by core3.amsl.com (Postfix) with SMTP id 6FB6A3A6A4C for ; Tue, 13 Jul 2010 02:36:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Matthew.Anderson@us.elster.com X-Msg-Ref: server-8.tower-53.messagelabs.com!1279013816!44736277!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.182.155.20] Received: (qmail 5825 invoked from network); 13 Jul 2010 09:36:56 -0000 Received: from unknown (HELO us-smtp01.smtp.elster.com) (206.182.155.20) by server-8.tower-53.messagelabs.com with SMTP; 13 Jul 2010 09:36:56 -0000 Auto-Submitted: auto-generated From: Matthew.Anderson@us.elster.com To: roll@ietf.org Message-ID: Date: Tue, 13 Jul 2010 05:33:11 -0400 X-MIMETrack: Serialize by Router on US-SMTP01.domino.elster-group.com/RIM-TEMP(Release 8.5.1|September 28, 2009) at 07/13/2010 05:32:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Roll] AUTO: Matthew Anderson is out of the office (returning 07/19/2010) 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: , X-List-Received-Date: Tue, 13 Jul 2010 09:38:40 -0000 I am out of the office until 07/19/2010. I am out of the office on vacation. Any critical matters related to the EARG project should be sent to Gerald Paprocki. Also - please make sure you have the correct Matt Anderson on this email if you are surprised by this out of office. Note: This is an automated response to your message "[Roll] [roll] #57: Proposed change: Routing DAOs in non-storing DODAGs" sent on 7/13/2010 5:11:28 AM. This is the only notification you will receive while this person is away. From mdurvy@cisco.com Tue Jul 13 04:05:40 2010 Return-Path: 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 844603A6968 for ; Tue, 13 Jul 2010 04:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 D64uKPOZPJgZ for ; Tue, 13 Jul 2010 04:05:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BDEB73A6980 for ; Tue, 13 Jul 2010 04:05:26 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-AV: E=Sophos;i="4.55,193,1278288000"; d="txt'?p7s'?scan'208,217";a="157721716" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 13 Jul 2010 11:05:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6DB5ScF001527; Tue, 13 Jul 2010 11:05:35 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 13:05:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jul 2010 13:05:28 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0198_01CB228C.10EF11A0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CAC6@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Transit information option Thread-Index: AcsdETbPrvyhawioRZaqXGJI+i24zgAB9yqwAALfWSAAj7qawADF21AA From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 13 Jul 2010 11:05:31.0959 (UTC) FILETIME=[4F752470:01CB227B] Cc: roll@ietf.org Subject: [Roll] FW: FW: Transit information option 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: , X-List-Received-Date: Tue, 13 Jul 2010 11:05:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0198_01CB228C.10EF11A0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0199_01CB228C.10EF11A0" ------=_NextPart_001_0199_01CB228C.10EF11A0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_019A_01CB228C.10EF11A0" ------=_NextPart_002_019A_01CB228C.10EF11A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, I just saw that you have been opening some tickets to clarify the current specs. Could we open a ticket to clarify these points as well? Thanks, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 9. juillet 2010 15:17 To: Pascal Thubert (pthubert); ROLL WG Subject: Re: [Roll] FW: Transit information option Hi Pascal, Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it's more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint). - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn't it redundant? - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? It's a lot of questions, but I hope it will help make the DAO part clearer to everybody! Best, Mathilde From: Pascal Thubert (pthubert) Sent: mercredi, 7. juillet 2010 09:22 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Mathilde, 1) In storing mode, the transit information "parent address" is not used You're correct on that with the current spec. I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. Pascal From: Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Pascal, My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. Does this make sense? Best, Mathilde From: Pascal Thubert (pthubert) Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option Hi Mathilde: Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+. I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router. What do you think? Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option Hi All, I didn't see these comments addressed in the new draft. Any reason? For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option Hi All, I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. Best, Mathilde From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: Hi Phil, Thanks a lot for your answer. Here are my comments: A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? These are good questions. Currently the draft is a bit unclear on whether 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice. Similar to Phil I'm getting worried about the increased complexity. But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? ICMP error. Phil ------=_NextPart_002_019A_01CB228C.10EF11A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

I just saw that you have been opening some tickets to = clarify the current specs. Could we open a ticket to clarify these points as = well?

 

Thanks,

Mathilde

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 9. juillet 2010 15:17
To: Pascal Thubert (pthubert); ROLL WG
Subject: Re: [Roll] FW: Transit information = option

 

Hi Pascal,

 

Thanks again for your reply. What you say makes sense = although I still think that the separation of the fields between the target and = transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it’s more important to clarify the specs with respect to the = meaning / usage of the path sequence, control, and lifetime.

- In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred = (since path control bits sent to different parents have to be disjoint). =

- It seems to me that the path control usage is incompatible = with the sentence “If a node sends a DAO to one DAO parent, it MUST = send a DAO with the same DAOSequence to all other DAO parents”. = No?

- In the non storing mode, the path control is not used to = limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I = guess it can be used as a preference by the root when it computes the source = routes.

- How is the path sequence processed? Given that we have = already a DAO sequence is it possible to receive a stale path sequence? = Isn’t it redundant?

- What does the lifetime represent concretely? Is it a = measure of the lifetime of the link between the target and the = transit?

 

It’s a lot of questions, but I hope it will help make = the DAO part clearer to everybody!

 

Best,

Mathilde

 

 

From:= Pascal = Thubert (pthubert)
Sent: mercredi, 7. juillet 2010 09:22
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde,

 

1) In storing mode, the transit information “parent address” is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing = the info for the tunnel endpoint and that it might become handy to indicate = a RPL router to which a target host is attached.

 

2)    = He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ for = non-storing.

 

We want to factorise: in non-storing mode, the target can = have multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can = place multiple targets for all its addresses and then only one transit info = that is common to them all.

 

Pascal

 

From:= = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Pascal,

 

My point is a bit different.

In storing mode, the transit information “parent address” is not used. The only fields that are relevant in the = transit information are the path control, sequence, and lifetime, which actually = relate to the target prefix. So why not put these fields in the target option = and use only the transit option when we are in non-storing mode and hence need = to specify a parent address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing.

 

Does this make sense?

Best,

Mathilde

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination = and the transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. = AS Phil pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode = to indicate the tunnel end point for targets outside the RPL network, like = the proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information = option

 

Hi All,

 

I didn’t see these comments addressed in the new draft. Any reason? =

For point 2, I would go even further and propose to put the path sequence, = control, and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add that the sentence “In a DIO, the RPL Target Option = identifies a resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi All,

 

I just looked at the updated draft and most of the comments = below have been addresses / clarified. Just a few rather minor = points:

- Section 5.7.7. RPL Target. Based on the discussion below I = would change “A set of one or more Transit Information options MAY = directly follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- If the Path-Sequence / Control fields are indeed used both = in storing (where I have doubts they are really needed) and non-storing = mode, why not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length option.

 

Best,

Mathilde

 

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy = (mdurvy) wrote:

 

Hi Phil,

 

Thanks a lot for your answer. Here are my = comments:

 =

A few items that might be worth clarifying in version = 09:

- “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path sequence / control = / lifetime are not specified (which seems to contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. = Storing mode seems like it is a MUST as well...

I think we all = agree.

- “A non-storing node that has more than one DAO parent MAY include = a Transit Information option for each DAO parent as part of the = non-storing Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) = shouldn’t he send one DAO with transit information A (i.e. parent address =3D A) = to DAO parent A and another DAO with transit information B to DAO parent B? = Otherwise how this would work over multiple hop? Maybe an example of DAO would = help.

- In section 7.1.5 point 2, I assume the node should add a transit = information with its parent before passing the content of the received DAO. Also do = the operation specified on the path control field in the previous section = for storing node also apply in the non-storing case?

 

These are good questions. Currently the draft is a = bit unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, or 

2) the DODAG Root receives just the last downward = hops of each node, and stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that = if it's 2), then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are your = thoughts?

 

Indeed, I think the = current draft is a bit unclear. My interpretation when reading was 1 (probably due = mostly to the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for explaining.

What triggered this = change?

It seems to me that if = proper aggregation of the routes is performed (in particular if in the record = route case you can avoid transmitting routes which are sub-routes of others) = the two schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit on = the topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.

Also concerning your = last comment, I agree. The DAO produced will be slightly larger but we send only one = DAO instead of one DAO per DAO parent. I think if we do that we might not = really need the path control field, correct?

 

-09 has a rewrite of the Downward Routes section = that should make all of this much clearer. The answer is 2), for reasons Richard = brought up a few months ago. In particular, if you use 1), then when a node changes = its parent set it entire sub-DODAG must resend DAOs. This is a significant = cost. If you use 2), then only that node needs to send a new DAO.

 

 

 

- Has the advantage of having multiple DAO parents been assessed with = respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent = set. The concern is that the vagaries and unreliability of wireless links call = for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward = routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger = to the entire sub-DODAG.

I understand how this would work in the storing case but in = the non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------=_NextPart_002_019A_01CB228C.10EF11A0-- ------=_NextPart_001_0199_01CB228C.10EF11A0 Content-Type: text/plain; name="ATT15247545.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT15247545.txt" _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_001_0199_01CB228C.10EF11A0-- ------=_NextPart_000_0198_01CB228C.10EF11A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMzExMDUyOFowIwYJKoZIhvcNAQkEMRYEFPSiPSNkyufWlYzI J6Q757lZ9vyXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAoCkmEeEuSdERoma6SfQrf4HuMBY3i5er yfYeVkQkdA/tDxk3UOowHOJyBxocYnrNNIRrloZitEu8maY3llBzw/IZItrwdyaD0bjg7kCOgZxq Wb9OcAVh4iJAE0HjTNopirKNVVerLYOXY+1ylGZQYOzCAHutnKOmXVGZBEk2q8sAAAAAAAA= ------=_NextPart_000_0198_01CB228C.10EF11A0-- From trac@tools.ietf.org Tue Jul 13 04:21:59 2010 Return-Path: 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 021453A67F8 for ; Tue, 13 Jul 2010 04:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 E89+RBh24M9f for ; Tue, 13 Jul 2010 04:21:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2BC733A67A5 for ; Tue, 13 Jul 2010 04:21:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYdYr-0007oo-Vh; Tue, 13 Jul 2010 04:22:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Tue, 13 Jul 2010 11:22:05 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/59 Message-ID: <055.798c48fa8ae12e4b6b01d186c855a8f7@tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #59: Request for clarification: Transit information option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:21:59 -0000 #59: Request for clarification: Transit information option -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from Mathilde On July 9: From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 9. juillet 2010 15:17 To: Pascal Thubert (pthubert); ROLL WG Subject: Re: [Roll] FW: Transit information option Hi Pascal, Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it’s more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint). - It seems to me that the path control usage is incompatible with the sentence “If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parentsâ€. No? - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn’t it redundant? - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? It’s a lot of questions, but I hope it will help make the DAO part clearer to everybody! Best, Mathilde -- Ticket URL: roll From jpv@cisco.com Tue Jul 13 04:23:25 2010 Return-Path: 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 EE70E3A69D1 for ; Tue, 13 Jul 2010 04:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 URhxgbe4UTCV for ; Tue, 13 Jul 2010 04:23:23 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AF6203A6980 for ; Tue, 13 Jul 2010 04:23:23 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAProO0yrRN+K/2dsb2JhbACBRJ5pcaNCmnyFJwSITYIx X-IronPort-AV: E=Sophos;i="4.55,193,1278288000"; d="scan'208,217";a="225557213" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2010 11:23:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6DBNFbR021420 for ; Tue, 13 Jul 2010 11:23:31 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 13:23:16 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 13:23:14 +0200 Message-Id: <9BBBFA35-E5FF-46A5-B698-039BA9E2C73F@cisco.com> From: JP Vasseur To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CAC6@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-100-65283436 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Jul 2010 13:23:13 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CAC6@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Jul 2010 11:23:15.0278 (UTC) FILETIME=[C93EBEE0:01CB227D] Cc: roll@ietf.org Subject: Re: [Roll] FW: Transit information option 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: , X-List-Received-Date: Tue, 13 Jul 2010 11:23:26 -0000 --Apple-Mail-100-65283436 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Sure - done: Ticket #59 On Jul 13, 2010, at 1:05 PM, Mathilde Durvy (mdurvy) wrote: > Hi JP, > > I just saw that you have been opening some tickets to clarify the =20 > current specs. Could we open a ticket to clarify these points as well? > > Thanks, > Mathilde > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Mathilde Durvy (mdurvy) > Sent: vendredi, 9. juillet 2010 15:17 > To: Pascal Thubert (pthubert); ROLL WG > Subject: Re: [Roll] FW: Transit information option > > Hi Pascal, > > Thanks again for your reply. What you say makes sense although I =20 > still think that the separation of the fields between the target and =20= > transit options is somewhat arbitraryJ However this is not a major =20 > issue and maybe at this point it=92s more important to clarify the =20 > specs with respect to the meaning / usage of the path sequence, =20 > control, and lifetime. > - In storing mode, the path control is used to limit the DAO fan-=20 > out. It can also be used to set a preference between routes with the =20= > limitation that it cannot specify two routes which are equally =20 > preferred (since path control bits sent to different parents have to =20= > be disjoint). > - It seems to me that the path control usage is incompatible with =20 > the sentence =93If a node sends a DAO to one DAO parent, it MUST send =20= > a DAO with the same DAOSequence to all other DAO parents=94. No? > - In the non storing mode, the path control is not used to limit the =20= > DAO fan-out as nodes send DAOs to only one of their DAO parents. I =20 > guess it can be used as a preference by the root when it computes =20 > the source routes. > - How is the path sequence processed? Given that we have already a =20 > DAO sequence is it possible to receive a stale path sequence? Isn=92t =20= > it redundant? > - What does the lifetime represent concretely? Is it a measure of =20 > the lifetime of the link between the target and the transit? > > It=92s a lot of questions, but I hope it will help make the DAO part =20= > clearer to everybody! > > Best, > Mathilde > > > From: Pascal Thubert (pthubert) > Sent: mercredi, 7. juillet 2010 09:22 > To: Mathilde Durvy (mdurvy); 'ROLL WG' > Subject: RE: [Roll] FW: Transit information option > > Hi Mathilde, > > 1) In storing mode, the transit information =93parent address=94 is = not =20 > used > > You=92re correct on that with the current spec. > I=92m pointing out that in some cases we are missing the info for the =20= > tunnel endpoint and that it might become handy to indicate a RPL =20 > router to which a target host is attached. > > 2) Hence the pattern would be (Target+) for storing and (Target=20 > +,Transit+)+ for non-storing. > > We want to factorise: in non-storing mode, the target can have =20 > multiple parents each one with a different path control. > In storing mode, a router with multiple interfaces can place =20 > multiple targets for all its addresses and then only one transit =20 > info that is common to them all. > > Pascal > > From: Mathilde Durvy (mdurvy) > Sent: Tuesday, July 06, 2010 4:47 PM > To: Pascal Thubert (pthubert); 'ROLL WG' > Subject: RE: [Roll] FW: Transit information option > > Hi Pascal, > > My point is a bit different. > In storing mode, the transit information =93parent address=94 is not =20= > used. The only fields that are relevant in the transit information =20 > are the path control, sequence, and lifetime, which actually relate =20= > to the target prefix. So why not put these fields in the target =20 > option and use only the transit option when we are in non-storing =20 > mode and hence need to specify a parent address? > Hence the pattern would be (Target+) for storing and (Target+,Transit=20= > +)+ for non-storing. > > Does this make sense? > Best, > Mathilde > > From: Pascal Thubert (pthubert) > Sent: mardi, 6. juillet 2010 15:44 > To: Mathilde Durvy (mdurvy); ROLL WG > Subject: RE: [Roll] FW: Transit information option > > Hi Mathilde: > > Pls note that the target identifies the final destination and the =20 > transit tells you about how you get there. So you can factorize =20 > optimally depending on what you are doing. > > We have issue 55 that should cover your proposed change. AS Phil =20 > pointed out, The pattern is really (Target+, Transit+)+. > > I tend to think that the parent is needed in storing mode to =20 > indicate the tunnel end point for targets outside the RPL network, =20 > like the proverbial dumb host attached to a RPL router. > > What do you think? > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Mathilde Durvy (mdurvy) > Sent: Tuesday, July 06, 2010 3:25 PM > To: ROLL WG > Subject: [Roll] FW: Transit information option > > Hi All, > > I didn=92t see these comments addressed in the new draft. Any reason? > For point 2, I would go even further and propose to put the path =20 > sequence, control, and lifetime fields in the Target option and keep =20= > only the parent address field in the Transit option. > Let me add that the sentence =93In a DIO, the RPL Target Option =20 > identifies a resource that the root is trying to reach=94 should be =20= > removed if I believe the list of options allowed for DIO. > > Best, > Mathilde > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Mathilde Durvy (mdurvy) > Sent: vendredi, 18. juin 2010 11:09 > To: Philip Levis > Cc: roll@ietf.org > Subject: Re: [Roll] Transit information option > > Hi All, > > I just looked at the updated draft and most of the comments below =20 > have been addresses / clarified. Just a few rather minor points: > - Section 5.7.7. RPL Target. Based on the discussion below I would =20 > change =93A set of one or more Transit Information options MAY =20 > directly follow the Target option in a DAO message=94 to =93a RPL = Target =20 > Option in a unicast DAO MUST be followed by a set of one or more =20 > Transit Information Option =94. > - If the Path-Sequence / Control fields are indeed used both in =20 > storing (where I have doubts they are really needed) and non-storing =20= > mode, why not put them in the target option rather than in the =20 > transit option. This way we could maybe only use only the target =20 > option in storing mode and the target+transit option in non-storing =20= > mode. This would have the additional benefit of making the parent =20 > address mandatory in the transit information option and thus avoid a =20= > variable length option. > > Best, > Mathilde > > > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: vendredi, 11. juin 2010 18:10 > To: Mathilde Durvy (mdurvy) > Cc: roll@ietf.org > Subject: Re: [Roll] Transit information option > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > Hi Phil, > > Thanks a lot for your answer. Here are my comments: > > A few items that might be worth clarifying in version 09: > - =93Transit Information options MAY directly follow the Target =20 > option=94 Is it really a MAY? If not included it means the path =20 > sequence / control / lifetime are not specified (which seems to =20 > contradict section 7.1.4.2). > In non-storing mode, it is definitely a MUST. Storing mode seems =20 > like it is a MUST as well... > I think we all agree. > > - =93A non-storing node that has more than one DAO parent MAY include =20= > a Transit Information option for each DAO parent as part of the non-=20= > storing Destination Advertisement operation.=94 Why would a node do =20= > that? If a node is sending a DAO for a specific target to e.g. 2 DAO =20= > parents (A and B) shouldn=92t he send one DAO with transit information = =20 > A (i.e. parent address =3D A) to DAO parent A and another DAO with =20 > transit information B to DAO parent B? Otherwise how this would work =20= > over multiple hop? Maybe an example of DAO would help. > - In section 7.1.5 point 2, I assume the node should add a transit =20 > information with its parent before passing the content of the =20 > received DAO. Also do the operation specified on the path control =20 > field in the previous section for storing node also apply in the non-=20= > storing case? > > These are good questions. Currently the draft is a bit unclear on =20 > whether > 1) a DAO's transit option contains the full source route when it =20 > arrives at the DODAG Root, or > 2) the DODAG Root receives just the last downward hops of each node, =20= > and stitches together source routes with this information. > 1) seems like a much better idea to me. Note that if it's 2), then =20 > in non-storing mode node needs to send a DAO to just one DAO parent, =20= > and this DAO can contain the full set of last-hops. What are your =20 > thoughts? > > Indeed, I think the current draft is a bit unclear. My =20 > interpretation when reading was 1 (probably due mostly to the =20 > history of the draft). Now from your comments I understand what the =20= > draft is proposing, namely 2. Thanks for explaining. > What triggered this change? > It seems to me that if proper aggregation of the routes is performed =20= > (in particular if in the record route case you can avoid =20 > transmitting routes which are sub-routes of others) the two schemes =20= > could actually be quite similar in terms of overhead. This would =20 > need to be confirmed by a careful study as it could depend quite on =20= > bit on the topology. What is quite clear is that 2 requires more =20 > processing power than 1 as it needs to reassemble routes from the =20 > received information. > Also concerning your last comment, I agree. The DAO produced will be =20= > slightly larger but we send only one DAO instead of one DAO per DAO =20= > parent. I think if we do that we might not really need the path =20 > control field, correct? > > -09 has a rewrite of the Downward Routes section that should make =20 > all of this much clearer. The answer is 2), for reasons Richard =20 > brought up a few months ago. In particular, if you use 1), then when =20= > a node changes its parent set it entire sub-DODAG must resend DAOs. =20= > This is a significant cost. If you use 2), then only that node needs =20= > to send a new DAO. > > > > > > - Has the advantage of having multiple DAO parents been assessed =20 > with respect to the added complexity? One could argue that since we =20= > take so much care in selecting a preferred this should be a good =20 > enough choice=85 Similar to Phil I=92m getting worried about the =20 > increased complexity. > > But note that in upward routes, there's a parent set. The concern is =20= > that the vagaries and unreliability of wireless links call for =20 > supporting some degree of path diversity. Most protocols today =20 > maintain multiple candidate next hops for this exact reason. Because =20= > downward routes start at the endpoints, there needs to be some way =20 > to establish multiple routes. Otherwise, when one link breaks and =20 > you have to issue a trigger to the entire sub-DODAG. > I understand how this would work in the storing case but in the non-=20= > storing case how would you know at the root that the path failed? > > ICMP error. > > Phil > --Apple-Mail-100-65283436 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sure - done: Ticket #59

On Jul = 13, 2010, at 1:05 PM, Mathilde Durvy (mdurvy) wrote:

Hi = JP,
I just saw that you = have been opening some tickets to clarify the current specs. Could we = open a ticket to clarify these points as = well?
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy = (mdurvy)
Sent: vendredi, 9. juillet 2010 = 15:17
To: Pascal Thubert (pthubert); = ROLL WG
Subject: Re: [Roll] FW: Transit = information option
 
Hi = Pascal,
Thanks again for = your reply. What you say makes sense although I still think that the = separation of the fields between the target and transit options is = somewhat arbitraryJ However this is not a major = issue and maybe at this point it=92s more important to clarify the specs = with respect to the meaning / usage of the path sequence, control, and = lifetime.
- In storing mode, = the path control is used to limit the DAO fan-out. It can also be used = to set a preference between routes with the limitation that it cannot = specify two routes which are equally preferred (since path control bits = sent to different parents have to be = disjoint).
- It seems to me = that the path control usage is incompatible with the sentence =93If a = node sends a DAO to one DAO parent, it MUST send a DAO with the same = DAOSequence to all other DAO parents=94. No?
- In the non storing mode, the path control is not used = to limit the DAO fan-out as nodes send DAOs to only one of their DAO = parents. I guess it can be used as a preference by the root when it = computes the source routes.
- How is the path sequence processed? Given that we have = already a DAO sequence is it possible to receive a stale path sequence? = Isn=92t it redundant?
It=92s a lot of = questions, but I hope it will help make the DAO part clearer to = everybody!
From: Pascal Thubert = (pthubert) 
Sent: mercredi, 7. juillet 2010 = 09:22
To: Mathilde Durvy (mdurvy); = 'ROLL WG'
Subject: RE: [Roll] FW: Transit = information option
 
Hi = Mathilde,
I=92m = pointing out that in some cases we are missing the info for the tunnel = endpoint and that it might become handy to indicate a RPL router to = which a target host is attached.
2)    We = want to factorise: in non-storing mode, the target can have multiple = parents each one with a different path control. =  
In = storing mode, a router with multiple interfaces can place multiple = targets for all its addresses and then only one transit info that is = common to them all.
 
 Mathilde Durvy = (mdurvy) 
Sent: Tuesday, July 06, 2010 4:47 = PM
To: Pascal = Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit = information option
 
Hi = Pascal,
My point is a bit = different.
In storing mode, = the transit information =93parent address=94 is not used. The only = fields that are relevant in the transit information are the path = control, sequence, and lifetime, which actually relate to the target = prefix. So why not put these fields in the target option and use only = the transit option when we are in non-storing mode and hence need to = specify a parent address?
 
From: Pascal Thubert = (pthubert) 
Sent: mardi, 6. juillet 2010 = 15:44
To: Mathilde Durvy (mdurvy); = ROLL WG
Subject: RE: [Roll] FW: Transit = information option
 
Hi = Mathilde:
Pls = note that the target identifies the final destination and the transit = tells you about how you get there. So you can factorize optimally = depending on what you are doing.
We = have issue 55 that should cover your proposed change. AS Phil pointed = out, The pattern is really (Target+, = Transit+)+.
I = tend to think that the parent is needed in storing mode to indicate the = tunnel end point for targets outside the RPL network, like the = proverbial dumb host attached to a RPL = router.
What = do you think?
Pascal
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy = (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 = PM
To: ROLL = WG
Subject: [Roll] FW: Transit = information option
 
Hi = All,
 
For point 2, I would go even = further and propose to put the path sequence, control, and lifetime = fields in the Target option and keep only the parent address field in = the Transit option.
Let me add = that the sentence =93In a DIO, the RPL Target Option identifies a = resource that the root is trying to reach=94 should be removed if I = believe the list of options allowed for DIO.
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy = (mdurvy)
Sent: vendredi, 18. juin 2010 = 11:09
To: Philip = Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit = information option
 
Hi = All,
I just looked at = the updated draft and most of the comments below have been addresses / = clarified. Just a few rather minor points:
- Section 5.7.7. RPL Target. Based on the discussion = below I would change =93A set of one or more Transit Information options = MAY directly follow the Target option in a DAO message=94 to =93a RPL = Target Option in a unicast DAO MUST be followed by a set of one or more = Transit Information Option =94.
- If the Path-Sequence / Control fields are indeed used = both in storing (where I have doubts they are really needed) and = non-storing mode, why not put them in the target option rather than in = the transit option. This way we could maybe only use only the target = option in storing mode and the target+transit option in non-storing = mode. This would have the additional benefit of making the parent = address mandatory in the transit information option and thus avoid a = variable length option.
From: Philip Levis [mailto:pal@cs.stanford.edu] 
Sent: vendredi, 11. juin 2010 = 18:10
To: Mathilde Durvy = (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit = information option
 
On Jun 11, 2010, at 7:26 = AM, Mathilde Durvy (mdurvy) wrote:

 

Hi Phil,
 
Thanks a lot for your answer. Here are my = comments:
- =93Transit = Information options MAY directly follow the Target option=94 Is it = really a MAY? If not included it means the path sequence / control / = lifetime are not specified (which seems to contradict section = 7.1.4.2).
In non-storing mode, it is definitely a MUST. Storing mode = seems like it is a MUST as well...

I think we all = agree.

- In section 7.1.5 point 2, I assume the node should add a = transit information with its parent before passing the content of the = received DAO. Also do the operation specified on the path control field = in the previous section for storing node also apply in the non-storing = case?
 
These are good questions. Currently the draft is a bit unclear = on whether 
1) a DAO's transit option contains the full source route when = it arrives at the DODAG Root, = or 
2) the DODAG = Root receives just the last downward hops of each node, and stitches = together source routes with this = information. 
1) seems like a much better idea to me. Note that if it's 2), = then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are = your thoughts?
 
Indeed, I think the current draft is a bit = unclear. My interpretation when reading was 1 (probably due mostly to = the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for = explaining.
What triggered this = change?
It seems to me that if proper aggregation of the routes is = performed (in particular if in the record route case you can avoid = transmitting routes which are sub-routes of others) the two schemes = could actually be quite similar in terms of overhead. This would need to = be confirmed by a careful study as it could depend quite on bit on the = topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.
Also concerning your last comment, I agree. The = DAO produced will be slightly larger but we send only one DAO instead of = one DAO per DAO parent. I think if we do that we might not really need = the path control field, = correct?
 
-09 has a = rewrite of the Downward Routes section that should make all of this much = clearer. The answer is 2), for reasons Richard brought up a few months = ago. In particular, if you use 1), then when a node changes its parent = set it entire sub-DODAG must resend DAOs. This is a significant cost. If = you use 2), then only that node needs to send a new = DAO.
 

 
But note that = in upward routes, there's a parent set. The concern is that the vagaries = and unreliability of wireless links call for supporting some degree of = path diversity. Most protocols today maintain multiple candidate next = hops for this exact reason. Because downward routes start at the = endpoints, there needs to be some way to establish multiple routes. = Otherwise, when one link breaks and you have to issue a trigger to the = entire sub-DODAG.
 
ICMP = error.
; Tue, 13 Jul 2010 11:47:46 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 13:47:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jul 2010 13:47:30 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01A1_01CB2291.EFC812A0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarifications on Section 16 "Manageability considerations" Thread-Index: AcsigSwsvof2ALWtT8yxPukfAbBA6A== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 13 Jul 2010 11:47:32.0148 (UTC) FILETIME=[2D9B7740:01CB2281] Subject: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Tue, 13 Jul 2010 11:47:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A1_01CB2291.EFC812A0 Content-Type: multipart/related; boundary="----=_NextPart_001_01A2_01CB2291.EFC812A0" ------=_NextPart_001_01A2_01CB2291.EFC812A0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_01A3_01CB2291.EFC812A0" ------=_NextPart_002_01A3_01CB2291.EFC812A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 Just reviewed Section 16, here is some feedback that might help clarify: =20 - In 16.2.3, 16.2.4 It is not very clear which parameters are configured versus negotiated dynamically through messages.=20 - In 16.2.4 =93A RPL implementation SHOULD allow configuring whether a non-storing node provides the transit information in DAO messages.=94 Shouldn=92t a node always include the transit info in DAO messages? = Aren=92t the 2 first bullet related to the DAO mechanism and hence more appropriate = in Section 16.2.6 (or maybe we should just remove Section 16.2.6) - In 16.2.5, T flag has not been removed - In 16.2.6, this section contains legacy text (already mentioned in previous email thread) - In 16.6, is the DODAGID necessarily part of the policy? - In 16.7/16.9 or 16.4. Maybe it would help to further specify what = services RPL expects to be handled by other protocols such as ND. I=92m talking = of course of services that RPL directly relies on to operate. NUD is = mentioned but what about address resolution, etc. I guess this is kind of standard = so not sure if we should include it. - In general, Sections 16.3 to 16.5 can be difficult to implement on constrained nodes without interface or file system. I would emphasize = that it is expected that constrained nodes do not implement these parts. =20 Best, Mathilde http://www.cisco.com/swa/i/logo.gif Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 Think before you print.Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended recipient = (or authorized to receive for the recipient), please contact the sender by = reply e-mail and delete all copies of this message. ------=_NextPart_002_01A3_01CB2291.EFC812A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Just reviewed Section 16, here is some feedback = that might help clarify:

 

- In 16.2.3, 16.2.4 It is not very clear which = parameters are configured versus negotiated dynamically through messages. =

- In 16.2.4 “A RPL implementation SHOULD = allow configuring whether a non-storing node provides the transit information = in DAO messages.” Shouldn’t a node always include the transit info = in DAO messages? Aren’t the 2 first bullet related to the DAO mechanism = and hence more appropriate in Section 16.2.6 (or maybe we should just remove = Section 16.2.6)

- In 16.2.5, T flag has not been = removed

- In 16.2.6, this section contains legacy text = (already mentioned in previous email thread)

- In 16.6, is the DODAGID necessarily part of the = policy?

- In 16.7/16.9 or 16.4. Maybe it would help to = further specify what services RPL expects to be handled by other protocols such = as ND. I’m talking of course of services that RPL directly relies on to = operate. NUD is mentioned but what about address resolution, etc. I guess this is = kind of standard so not sure if we should include it.

- In general, Sections 16.3 to 16.5 can be = difficult to implement on constrained nodes without interface or file system. I would emphasize that it is expected that constrained nodes do not implement = these parts.

 

Best,

Mathilde

3D"http://www.cisco.com/swa/i/logo.gif"

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco = home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain confidential and privileged material for the sole use of = the intended recipient. Any review, use, distribution or disclosure by = others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender = by reply e-mail and delete all copies of this = message.


------=_NextPart_002_01A3_01CB2291.EFC812A0-- ------=_NextPart_001_01A2_01CB2291.EFC812A0 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------=_NextPart_001_01A2_01CB2291.EFC812A0 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_01A2_01CB2291.EFC812A0-- ------=_NextPart_000_01A1_01CB2291.EFC812A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxMzExNDcyOVowIwYJKoZIhvcNAQkEMRYEFMNizJWyMW9jsvNU umIHiT36ObysMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAYP08l5q7aJxAR0EhR4rOAiz8ekRUzfpd 64dG/2Z2DVLlx3euQ7KcinvBLMrpbmwiDcsiFrNWyX1TOMCnjmiIgMjZMMw2quAbtLnlxPkgRrXg n0nSp5iOjzIm4MJuF9eZMfSxPZDVNCfOrcj3BbuLyfmKGu0QargwiLXzeMVM6xkAAAAAAAA= ------=_NextPart_000_01A1_01CB2291.EFC812A0-- From pthubert@cisco.com Tue Jul 13 04:53:21 2010 Return-Path: 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 B51653A687C for ; Tue, 13 Jul 2010 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 t0jiwcc6moPn for ; Tue, 13 Jul 2010 04:53:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4868B3A686E for ; Tue, 13 Jul 2010 04:53:20 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,193,1278288000"; d="scan'208";a="267119348" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2010 11:53:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6DBrNWA005227; Tue, 13 Jul 2010 11:53:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 13:53:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 13 Jul 2010 13:53:05 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CDC47@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue#56 (2nd): Transit and Target address mismatch thread-index: AcsigfODEbqCB9L3Tw2qD5v/wjyRGQ== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 13 Jul 2010 11:53:09.0157 (UTC) FILETIME=[F67AF550:01CB2281] Cc: roll@ietf.org Subject: [Roll] Closing issue#56 (2nd): Transit and Target address mismatch 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: , X-List-Received-Date: Tue, 13 Jul 2010 11:53:21 -0000 UmV3b3JkaW5nIGFmdGVyIHRoZSB0aHJlYWQgd2l0aCBNYXRoaWxkZSwgaGVyZSdzIHdoYXQgdGhl IHJlc29sdXRpb24gZm9yIElzc3VlIDU2IHdvdWxkIHNheToNCg0KLSBUaGUgUiBiaXQgaW4gUElP IGlzIHVzZWQgIGFzIGluIFJGQzM3NzUgdG8gaW5kaWNhdGUgYSAoZ2xvYmFsL1VMQSkgYWRkcmVz cyBhcyBvcHBvc2VkIHRvIGEgcHJlZml4LiANCi0gVGhlIHByZWZpeCBpcyBzdGlsbCB2YWxpZCBm b3IgdGhlIHB1cnBvc2Ugb2YgYXV0b2NvbmYgd2hlbiB0aGUgUiBiaXQgaXMgc2V0Lg0KLSBUaGUg YWRkcmVzcyB1c2VkIGFzIHRyYW5zaXQgcGFyZW50IGJ5IHRoZSBjaGlsZHJlbiBNVVNUIGJlIHRh a2VuIGZyb20gYSBQSU8gZnJvbSB0aGF0IHBhcmVudCBidXQgaXMgbm90IG5lY2Vzc2FyaWx5IG9u IGxpbmsgZm9yIHRoZSBjaGlsZHJlbi4NCi0gVGhlIHJvdXRlciB0aGF0IGl0IGFkdmVydGlzZXMg YW4gYWRkcmVzcyBhcyBwYXJlbnQgaW4gUElPIG11c3QgYWxzbyBhZHZlcnRpc2UgdGhhdCBhZGRy ZXNzIGFzIHRhcmdldCBpbiBhIERBTyBmb3IgdGhlIHJvdXRlIHJlY3Vyc2lvbiB0byBjb21wbGV0 ZS4NCi0gQW4gYWRkcmVzcyB0aGF0IGlzIGFkdmVydGlzZWQgYXMgdGFyZ2V0IGluIGEgREFPIG11 c3QgYmUgY29sbG9jYXRlZCBvciByZWFjaGFibGUgb25saW5rIGJ5IHRoZSBwYXJlbnQgdGhhdCBp cyBpbmRpY2F0ZWQgaW4gdGhlIGFzc29jaWF0ZWQgdHJhbnNpdCBpbmZvcm1hdGlvbi4NCi0gQSBu ZXcgZmxhZyBpbiB0aGUgdHJhbnNpdCBpbmZvcm1hdGlvbiBxdWFsaWZpZXMgYSB0YXJnZXQgYWRk cmVzcyB0aGF0IGlzIGJlaGluZCBhIHJvdXRlciwgZWl0aGVyIGFzIGFuIGF0dGFjaGVkIGhvc3Qg b3IgaW5zdGFsbGVkIG9uIGFub3RoZXIgaW50ZXJmYWNlLiBUaGUgcm91dGVyIGlzIHRoZSB0dW5u ZWwgZW5kcG9pbnQgZm9yIHN1Y2ggYWRkcmVzcy4NCg0KV2UnbGwgbm90ZSB0aGF0IGlmIHRoZSBu b24tc3RvcmluZyBtb2RlIERBTyBpcyBzZW50IHN0cmFpZ2h0IHRvIHRoZSByb290IHRoZW4gdGhl IHBhcmVudCBkb2VzIG5vdCBoYXZlIGEgd2F5IHRvIGtub3cgYWJvdXQgdGhlIGNoaWxkIHVudGls IGEgUkggcG9wcyB1cC4gU28gdGhlIGJpZGlyZWN0aW9uYWwgcmVhY2hhYmlsaXR5IHdpbGwgYmUg Y2hlY2tlZCBhdCB0aGF0IHRpbWUuDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiBTZW50OiBGcmlk YXksIEp1bHkgMDksIDIwMTAgNDo1OCBQTQ0KPiBUbzogTWF0aGlsZGUgRHVydnkgKG1kdXJ2eSkN Cj4gQ2M6IHJvbGxAaWV0Zi5vcmc7IGpwdkBjaXNjby5jb207IHdpbnRlcnRAYWNtLm9yZw0KPiBT dWJqZWN0OiBDbG9zaW5nIGlzc3VlIzU2OiBUcmFuc2l0IGFuZCBUYXJnZXQgYWRkcmVzcyBtaXNt YXRjaA0KPiANCj4gSGkgTWF0aGlsZGU6DQo+IA0KPiBCYXNlZCBvbiB0aGUgdGhyZWFkIHdlIGhh dmUgaGFkIEkgdGhpbmsgdGhhdCB0aGUgdGV4dCBtdXN0IGNsYXJpZnkgdGhhdDoNCj4gDQo+IC0g VGhlIFIgYml0IGluIFBJTyBpcyB1c2VkICBhcyBpbiBSRkMzNzc1IHRvIGluZGljYXRlIGEgKGds b2JhbC9VTEEpIGFkZHJlc3MgYXMNCj4gb3Bwb3NlZCB0byBhIHByZWZpeC4NCj4gLSBUaGUgcHJl Zml4IGlzIHN0aWxsIHZhbGlkIGZvciB0aGUgcHVycG9zZSBvZiBhdXRvY29uZiB3aGVuIHRoZSBS IGJpdCBpcyBzZXQuDQo+IC0gVGhlIGFkZHJlc3MgaW4gdGhlIFBJTyBjYW4gYmUgdXNlZCBhcyB0 cmFuc2l0IHBhcmVudCBieSB0aGUgY2hpbGRyZW4gYnV0IGlzIG5vdA0KPiBuZWNlc3NhcmlseSBv biBsaW5rIGZvciB0aGUgY2hpbGRyZW4uDQo+IC0gVGhlIHJvdXRlciB0aGF0IGl0IGFkdmVydGlz ZXMgYW4gYWRkcmVzcyBhcyBwYXJlbnQgaW4gUElPIG11c3QgYWxzbyBhZHZlcnRpc2UNCj4gdGhh dCBhZGRyZXNzIGFzIHRhcmdldCBpbiBhIERBTyBmb3IgdGhlIHJvdXRlIHJlY3Vyc2lvbiB0byBj b21wbGV0ZS4NCj4gLSBBbiBhZGRyZXNzIHRoYXQgaXMgYWR2ZXJ0aXNlZCBhcyB0YXJnZXQgaW4g YSBEQU8gbXVzdCBiZSBjb2xsb2NhdGVkIG9yDQo+IHJlYWNoYWJsZSBvbmxpbmsgYnkgdGhlIHBh cmVudCB0aGF0IGlzIGluZGljYXRlZCBpbiB0aGUgYXNzb2NpYXRlZCB0cmFuc2l0DQo+IGluZm9y bWF0aW9uLg0KPiAtIEEgbmV3IGZsYWcgaW4gdGhlIHRyYW5zaXQgaW5mb3JtYXRpb24gcXVhbGlm aWVzIGEgdGFyZ2V0IGFkZHJlc3MgdGhhdCBpcyBiZWhpbmQgYQ0KPiByb3V0ZXIsIGVpdGhlciBh cyBhbiBhdHRhY2hlZCBob3N0IG9yIGluc3RhbGxlZCBvbiBhbm90aGVyIGludGVyZmFjZS4gVGhl IHJvdXRlcg0KPiBpcyB0aGUgdHVubmVsIGVuZHBvaW50IGZvciBzdWNoIGFkZHJlc3MuDQo+IA0K PiBXaWxsIHRoYXQgYmUgZW5vdWdoIHRvIGNsb3NlIDU2Pw0KPiANCj4gUGFzY2FsDQo+IA0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHJvbGwtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gT2Yg cm9sbCBpc3N1ZSB0cmFja2VyDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAwNiwgMjAxMCAxOjQx IFBNDQo+ID4gVG86IHdpbnRlcnRAYWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiA+IENjOiByb2xs QGlldGYub3JnDQo+ID4gU3ViamVjdDogW1JvbGxdIFtyb2xsXSAjNTY6IFRyYW5zaXQgYW5kIFRh cmdldCBhZGRyZXNzIG1pc21hdGNoDQo+ID4NCj4gPiAjNTY6IFtSb2xsXSBUcmFuc2l0IGFuZCBU YXJnZXQgYWRkcmVzcyBtaXNtYXRjaA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0NCj4gPiAgUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgfCAgICAgICBPd25lcjog IHdpbnRlcnRA4oCmDQo+ID4gICAgICBUeXBlOiAgZW5oYW5jZW1lbnQgICAgICB8ICAgICAgU3Rh dHVzOiAgbmV3DQo+ID4gIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICB8ICAgTWlsZXN0b25l Og0KPiA+IENvbXBvbmVudDogIHJwbCAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCj4gPiAg U2V2ZXJpdHk6ICBJbiBXRyBMYXN0IENhbGwgIHwgICAgS2V5d29yZHM6DQo+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tDQo+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiA+ICBIaSBBbGwsDQo+ID4NCj4gPiAgTGV04oCZ cyBjb25zaWRlciB0aGUgc3RvcmluZyBtb2RlIGluIGEgc2ltcGxlIHRvcG9sb2d5IEHDoELDoFIg KMOgIG1hcmsNCj4gPiB0aGUgcGFyZW50IHJlbGF0aW9uc2hpcCkuIExldOKAmXMgYWxzbyBhc3N1 bWUgdGhhdCBBIGhhcyBhIHByZWZpeCDigJhBcOKAmQ0KPiA+IGFuZCBhICBnbG9iYWwgYWRkcmVz cyDigJhBZ+KAmSB0byBhZHZlcnRpc2UuDQo+ID4gIEluIHRoaXMgZXhhbXBsZSB3ZSBoYXZlOg0K PiA+ICAtIEEgc2VuZHMgREFPIHdpdGgg4oCcdGFyZ2V0IEFnLCBBcCwgdHJhbnNpdCBC4oCdDQo+ ID4gIC0gQiBzZW5kcyBEQU8gd2l0aCDigJx0YXJnZXQgQmcsIHRyYW5zaXQgUuKAnSB0b2dldGhl ciB3aXRoIHRoZQ0KPiA+IGluZm9ybWF0aW9uICBmcm9tIEEsIGkuZS4g4oCcdGFyZ2V0IEFnLCBB cCwgdHJhbnNpdCBC4oCdDQo+ID4NCj4gPiAgVGhlbiBSIHJlY29tYmluZXMgdGhlIGluZm9ybWF0 aW9uIHRvIGdldCB0aGUgcm91dGUgdG8gZm9yIGV4YW1wbGUgQXANCj4gPiAoVGFyZ2V0IEFwLCB0 cmFuc2l0IEIsIHRhcmdldCBCZywgdHJhbnNpdCBSKSAgRm9yIHRoaXMgdG8gd29yaywNCj4gPiB0 cmFuc2l0IEIgYW5kIHRhcmdldCBCZyBuZWVkIHRvIGJlIG1hdGNoZWQuIEhvdyBjYW4gdGhpcyAg YmUgZG9uZT8NCj4gPiBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgdHJhbnNpdCBwYXJlbnQgYWRkcmVz cyBoYXMgdG8gYmUgYSBnbG9iYWwNCj4gPiBhZGRyZXNzPyBUaGlzIHdvdWxkIGltcGx5IHRoYXQg d2UgdXNlIGdsb2JhbCBhZGRyZXNzZXMgaW4gdGhlIHJvdXRpbmcNCj4gaGVhZGVyLiBIb3dldmVy IDZtYW4tcnBsLXJvdXRpbmctaGVhZGVyIHNheXM6DQo+ID4gIOKAnFdoZW4gcHJvY2Vzc2luZyB0 aGUgVHlwZSA0IFJvdXRpbmcgaGVhZGVyLCBhIHJvdXRlciBNVVNUIGRyb3AgdGhlDQo+ID4gcGFj a2V0IGlmIHRoZSBuZXh0IGVudHJ5IGlzIG5vdCBvbi1saW5r4oCdDQo+ID4gIEFzIGdsb2JhbCBh ZGRyZXNzZXMgaGF2ZSB0byBiZSBvZmYtbGluayBpbiBOQk1BIG5ldHdvcmsgbGlrZQ0KPiA+IDgw Mi4xNS40LCBJICBzZWUgYSBwcm9ibGVt4oCmDQo+ID4NCj4gPiAgQ2FuIHlvdSBwbGVhc2UgY2xh cmlmeSBob3cgYWRkcmVzc2VzIGFyZSBzdXBwb3NlZCB0byBiZSB1c2VkIGluIHRoaXMNCj4gPiBz b3VyY2UtIHJvdXRpbmcgc2NlbmFyaW8uDQo+ID4NCj4gPiAgVGhhbmtzLA0KPiA+ICBNYXRoaWxk ZQ0KPiA+DQo+ID4gLS0NCj4gPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMuaWV0Zi5v cmcvd2cvcm9sbC90cmFjL3RpY2tldC81Nj4NCj4gPiByb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvd2cvcm9sbC8+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4gUm9sbEBpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From pthubert@cisco.com Tue Jul 13 05:10:26 2010 Return-Path: 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 B6CF43A69D1 for ; Tue, 13 Jul 2010 05:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.219 X-Spam-Level: X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 0OGowVyKVEzN for ; Tue, 13 Jul 2010 05:10: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 CD6203A686C for ; Tue, 13 Jul 2010 05:10:08 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,193,1278288000"; d="scan'208,217";a="131774401" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2010 12:10:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6DCAGQm010488; Tue, 13 Jul 2010 12:10:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 14:10:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2284.5A810399" Date: Tue, 13 Jul 2010 14:10:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option thread-index: AcsihFYlXYO/2+RXTJGncvBulgiTnA== From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "JP Vasseur" X-OriginalArrivalTime: 13 Jul 2010 12:10:16.0651 (UTC) FILETIME=[5AEA19B0:01CB2284] Cc: roll@ietf.org Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Tue, 13 Jul 2010 12:10:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2284.5A810399 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mathilde =20 Thanks for your great help; I hope more people will follow your example so we can deeply clean up the spec during the round. please find below: =20 Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it's more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. [Pascal] Yes; at the end of the day the path control really had to be in the transit with the parent. Leaving the target without any bit allows us to add more headers that would also qualify that target and thus factorise. =20 - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint).=20 [Pascal] We have to see that. ecmp should be acceptable. We have an active thread on path control, lets deal with that there. =20 - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? [Pascal] The sequence that we are talking about now is probably the path sequence, right? Can you please elaborate on the issue? =20 - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. [Pascal] Yes =20 - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn't it redundant?=20 [Pascal] I expect not. But the node may have a stale state from that needs to be deprecated. By deprecated I mean that the router should stop forwarding through a node child that has last presented path sequence 21 as soon as another child presents sequence 22 or more for a same target. This indicates that in a DAG, a new path sequence should rapidly cause a DAO. In a tree, that is less urgent. =20 - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? =20 [Pascal] the lifetime is important for 2 things at least: - Flush. A lifetime of 0 is a route flush. That is how we do no-path. - Seq number validation. The path lifetime covers the path sequence so that in normal operations, the path sequence should not be incremented by 16 during a lifetime, so we should never see path sequence numbers that are out of sync by more than 16.=20 =20 It's a lot of questions, but I hope it will help make the DAO part clearer to everybody! =20 [Pascal] including the editors since the doc belongs to the group. =20 Best, Mathilde =20 =20 From: Pascal Thubert (pthubert)=20 Sent: mercredi, 7. juillet 2010 09:22 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option =20 Hi Mathilde, =20 1) In storing mode, the transit information "parent address" is not used =20 You're correct on that with the current spec.=20 I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. =20 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. =20 In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. =20 Pascal =20 From: Mathilde Durvy (mdurvy)=20 Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option =20 Hi Pascal, =20 My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 Does this make sense? Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option =20 Hi Mathilde: =20 Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. =20 We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+.=20 =20 I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router.=20 =20 What do you think? =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option =20 Hi All, =20 I didn't see these comments addressed in the new draft. Any reason?=20 For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. =20 Best, Mathilde =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 Hi All, =20 I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. =20 Best, Mathilde =20 =20 From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 =20 On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: =20 Hi Phil, =20 Thanks a lot for your answer. Here are my comments: =20 A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address =3D A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? =20 These are good questions. Currently the draft is a bit unclear on whether=20 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or=20 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information.=20 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? =20 Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? =20 -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. =20 =20 =20 - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice... Similar to Phil I'm getting worried about the increased complexity. =20 But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? =20 ICMP error. =20 Phil ------_=_NextPart_001_01CB2284.5A810399 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mathilde

 

Thanks for your great help; I hope more people will follow your = example so we can deeply clean up the spec during the round. please find = below:

 

Th= anks again for your reply. What you say makes sense although I still = think that the separation of the fields between the target and transit = options is somewhat arbitrary J = However this is not a major issue and maybe at this point it’s = more important to clarify the specs with respect to the meaning / usage = of the path sequence, control, and lifetime.

[Pascal] Yes; at the end of the day the path control really had to be = in the transit with the parent. Leaving the target without any bit = allows us to add more headers that would also qualify that target and = thus factorise.

 

- = In storing mode, the path control is used to limit the DAO fan-out. It = can also be used to set a preference between routes with the limitation = that it cannot specify two routes which are equally preferred (since = path control bits sent to different parents have to be disjoint). =

[Pascal] We have to see that. ecmp should be acceptable. We have an = active thread on path control, lets deal with that = there.

 

- = It seems to me that the path control usage is incompatible with the = sentence “If a node sends a DAO to one DAO parent, it MUST send a = DAO with the same DAOSequence to all other DAO parents”. = No?

[Pascal] The sequence that we are talking about now is probably the = path sequence, right? Can you please elaborate on the = issue?

 

- = In the non storing mode, the path control is not used to limit the DAO = fan-out as nodes send DAOs to only one of their DAO parents. I guess it = can be used as a preference by the root when it computes the source = routes.

[Pascal] Yes

 

- = How is the path sequence processed? Given that we have already a DAO = sequence is it possible to receive a stale path sequence? Isn’t it = redundant?

[Pascal] I expect not. But the node may have a stale state from that = needs to be deprecated. By deprecated I mean that the router should stop = forwarding through a node child that has last presented path sequence 21 = as soon as  another child presents sequence  22 or more for a = same target. This indicates that in a DAG, a new path sequence should = rapidly cause a DAO. In a tree, that is less = urgent.

 

- = What does the lifetime represent concretely? Is it a measure of the = lifetime of the link between the target and the = transit?

 

[Pascal] the lifetime is important for 2 things at = least:

-          = Flush. A lifetime of 0 is a route flush. That is how we do = no-path.

-          = Seq number validation. The path lifetime covers the path sequence so = that in normal operations, the path sequence should not be incremented = by 16 during a lifetime, so we should never see path sequence numbers = that are out of sync by more than 16.

 

It= ’s a lot of questions, but I hope it will help make the DAO part = clearer to everybody!

 

[Pascal] including the editors since the doc belongs to the = group.

 

Be= st,

Ma= thilde

 

 

From:= = Pascal Thubert (pthubert)
Sent: mercredi, 7. juillet 2010 = 09:22
To: Mathilde Durvy (mdurvy); 'ROLL = WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde,

 

1)= In storing mode, the transit information “parent address” = is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing the info for = the tunnel endpoint and that it might become handy to indicate a RPL = router to which a target host is attached.

 

2)    He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

We want to factorise: in non-storing mode, the target can have = multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can place multiple = targets for all its addresses and then only one transit info that is = common to them all.

 

Pascal

 

From:= Mathilde = Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 = PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: = RE: [Roll] FW: Transit information = option

 

Hi= Pascal,

 

My= point is a bit different.

In= storing mode, the transit information “parent address” is = not used. The only fields that are relevant in the transit information = are the path control, sequence, and lifetime, which actually relate to = the target prefix. So why not put these fields in the target option and = use only the transit option when we are in non-storing mode and hence = need to specify a parent address?

He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

Do= es this make sense?

Be= st,

Ma= thilde

 

From:= = Pascal Thubert (pthubert)
Sent: mardi, 6. juillet 2010 = 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: = RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination and the = transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. AS Phil = pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode to indicate = the tunnel end point for targets outside the RPL network, like the = proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 = PM
To: ROLL WG
Subject: [Roll] FW: Transit = information option

 

Hi = All,

 

I = didn’t see these comments addressed in the new draft. Any reason? =

For point 2, = I would go even further and propose to put the path sequence, control, = and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add = that the sentence “In a DIO, the RPL Target Option identifies a = resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 = 11:09
To: Philip Levis
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi= All,

 

I = just looked at the updated draft and most of the comments below have = been addresses / clarified. Just a few rather minor = points:

- = Section 5.7.7. RPL Target. Based on the discussion below I would change = “A set of one or more Transit Information options MAY directly = follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- = If the Path-Sequence / Control fields are indeed used both in storing = (where I have doubts they are really needed) and non-storing mode, why = not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode = and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length = option.

 

Be= st,

Ma= thilde

 

 

From:= = Philip Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. = juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On = Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) = wrote:

 

Hi= Phil,

&n= bsp;

Th= anks a lot for your answer. Here are my = comments:

 =

A few items = that might be worth clarifying in version = 09:

- = “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path = sequence / control / lifetime are not specified (which seems to = contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing = mode seems like it is a MUST as well...

I = think we all = agree.

- “A = non-storing node that has more than one DAO parent MAY include a Transit = Information option for each DAO parent as part of the non-storing = Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A = and B) shouldn’t he send one DAO with transit information A (i.e. = parent address =3D A) to DAO parent A and another DAO with transit = information B to DAO parent B? Otherwise how this would work over = multiple hop? Maybe an example of DAO would = help.

- In section = 7.1.5 point 2, I assume the node should add a transit information with = its parent before passing the content of the received DAO. Also do the = operation specified on the path control field in the previous section = for storing node also apply in the non-storing = case?

 

These are good questions. Currently the draft is a bit = unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, = or 

2) the = DODAG Root receives just the last downward hops of each node, and = stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that if = it's 2), then in non-storing mode node needs to send a DAO to just one = DAO parent, and this DAO can contain the full set of last-hops. What are = your thoughts?

 

Indeed, I think the current = draft is a bit unclear. My interpretation when reading was 1 (probably = due mostly to the history of the draft). Now from your comments I = understand what the draft is proposing, namely 2. Thanks for = explaining.

What triggered this = change?

It seems to me that if proper aggregation of the = routes is performed (in particular if in the record route case you can = avoid transmitting routes which are sub-routes of others) the two = schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit = on the topology. What is quite clear is that 2 requires more processing = power than 1 as it needs to reassemble routes from the received = information.

Also concerning your last comment, I agree. The DAO = produced will be slightly larger but we send only one DAO instead of one = DAO per DAO parent. I think if we do that we might not really need the = path control field, = correct?

 

-09 has a rewrite of the Downward Routes section that = should make all of this much clearer. The answer is 2), for reasons = Richard brought up a few months ago. In particular, if you use 1), then = when a node changes its parent set it entire sub-DODAG must resend DAOs. = This is a significant cost. If you use 2), then only that node needs to = send a new DAO.

 

 

<= p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'> 

=

- Has the = advantage of having multiple DAO parents been assessed with respect to = the added complexity? One could argue that since we take so much care in = selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent set. = The concern is that the vagaries and unreliability of wireless links = call for supporting some degree of path diversity. Most protocols today = maintain multiple candidate next hops for this exact reason. Because = downward routes start at the endpoints, there needs to be some way to = establish multiple routes. Otherwise, when one link breaks and you have = to issue a trigger to the entire sub-DODAG.

I = understand how this would work in the storing case but in the = non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------_=_NextPart_001_01CB2284.5A810399-- From dominique.barthel@orange-ftgroup.com Tue Jul 13 06:39:07 2010 Return-Path: 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 B80933A694E for ; Tue, 13 Jul 2010 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 fNQp5NQbc28g for ; Tue, 13 Jul 2010 06:39:03 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 3D0FA3A68F5 for ; Tue, 13 Jul 2010 06:39:03 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 295C4760003; Tue, 13 Jul 2010 15:41:13 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0BF0A760002; Tue, 13 Jul 2010 15:41:13 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Jul 2010 15:39:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 15:38:21 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF016C115B@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08 Thread-Index: AcsfvPx21NO4ACBTQXKAscsVdOwNkgC0cOWg References: From: To: , X-OriginalArrivalTime: 13 Jul 2010 13:39:11.0153 (UTC) FILETIME=[C6868210:01CB2290] Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08 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: , X-List-Received-Date: Tue, 13 Jul 2010 13:39:07 -0000 Hello Omprakash, Thanks for your time reading the draft and commenting. Yes, the semantic behind ordering is intentional. Some priority = mechanism was needed and we proposed to use order of appearance in the = packet as the semantic. We welcome comments on that use, especially if = this is improper practice in the IP world. Regarding nodes making their own decisions on objective, that's a = different issue. I don't see that a node by itself should have the right = to prefer one objective versus another one. It is my understanding that = the RPL instance dictates what the objective is, and the nodes that join = that instance have to adhere to it or become leaf nodes. Am I mistaken = here? So far, to my knowledge, there is no case in the -08 draft, other than = the ones listed in 8 and 3.2, where order matters. We have strong langage with MUSTs in these paragraphs, the text "the = order is significant" you quote is just a forewarning early in the = draft. Thanks again, and comments welcome from all. Best, Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Omprakash Gnawali Envoy=E9 : samedi 10 juillet 2010 01:17 =C0 : ROLL WG Objet : [Roll] metric ordering according = todraft-ietf-roll-routing-metrics-08 "8. ... When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-brakers in the order that they appear in the DAG Metric Container. A node propagating a DAG Metric Container MUST keep the order of metric objects unchanged. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criterion, LQL as the secondary criterion and Fanout Ratio as the ultimate tie-braker. In such a case, the Hop-Count, LQL and Fanout Ratio metric objects need to appear in that order in the DAG Metric Container. ..." Is the semantics behind the ordering intentional? A packet could be forwarded from a node that prefers to use one set of = objective to a node that prefers to use a different objective. For = example, from a low power energy scavenging sensor to a powered node. Not allowing the nodes to change the order allows a node to dictate the = relative importance of this metric to rest of the network without regard = to their preference. If we had already considered that scenario and determined to be not = important, it might be worth making the last sentence in the following = paragraph stronger - are there other cases besides those mentioned in 8 and 3.2? "2. ... Note that the Routing Metric/Constraint objects defined in this document can appear in any order in the DAG Metric Container. However, for some of them, the order is significant (as described in Section 8 and Section 3.2, for example). " - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nicolas.dejean.ietf@googlemail.com Tue Jul 13 07:17:11 2010 Return-Path: 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 2157F3A67D1 for ; Tue, 13 Jul 2010 07:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 vAP6Uk-KhXJq for ; Tue, 13 Jul 2010 07:17:10 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 8DAB53A676A for ; Tue, 13 Jul 2010 07:17:09 -0700 (PDT) Received: by eyb7 with SMTP id 7so987672eyb.31 for ; Tue, 13 Jul 2010 07:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E7yUlI9/vHJTVhxn6eFBngWxP5sModQWQzOhdkjktSo=; b=S+QBbELEU1YtPgdr2NNjMw93K2J2xkeogCco1cCM6w7shzxeYxvivmCd7OLAI/9xv7 hNBc6X+YtZ4P/SXEI2h7Z70nCjnXmFjR6Og35gVqGCZydk8fu2ZF1TpOnWg5MPzQatB5 JL+Blbr6jb/0OikPU52FIDjj0Pd9VFwtVw/N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x5y92xDeJy8jVpG8Nh9uPha80AlZsCP4Vyt4RGw3E3aYQ0ePtIkpM2Apx0VWD/5eQk rGXwr20UV2pgxSdP9H43dvnJFJVANFzzQ4Kusz9wwonoHAM2FF+YWV7msCSuKRHwUvsj xNlMIiLcV0WN8C72RG7UYVLEMDVildFIXwjpg= MIME-Version: 1.0 Received: by 10.213.25.130 with SMTP id z2mr755680ebb.42.1279030635040; Tue, 13 Jul 2010 07:17:15 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Tue, 13 Jul 2010 07:17:14 -0700 (PDT) In-Reply-To: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> Date: Tue, 13 Jul 2010 16:17:14 +0200 Message-ID: From: Nicolas DEJEAN To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 14:17:11 -0000 Hello Phil, >A couple of thoughts/opinions: >1) I personally don't think these optimizations matter much. Dominique had explained and documented in http://www.ietf.org/mail-archive/web/roll/current/msg03306.html that these optimizations do matter in our application domain. Please find at the bottom of this message the description of an even more critical case extracted from real life deployment. >The >possible cost of disrupting Trickle is much, much higher than the cost >of a few extra timer resets. In principle, I agree , yet see below what exactly we are requesting. >In highly, highly dynamic environments, we >see CTP's trickle-based control traffic to be 6-8% of the total traffic. >Since CTP uses datapath validation, this is tied to the data rate (it >wouldn't go up much if we lowered the data rate). In stable >environments, it can be under 1%. The transmission rate of control information can be very low, yet the reception rate can be high in very dense environment. We have been severely affected by this in the past and have learned how to deal with it. >If we're worried about the efficiency >of RPL, this is *not* the place to start. Maybe there are other issues , but this one alone would lead to real lifetime issues in Metering networks. >2) There's extensive research and deployment experience with Trickle; we >know how it works both in theory and practice. This doesn't mean it >can't be improved (Joakim has made several good points), but I'd >strongly, strongly caution against tweaking it without a lot of evidence >and testing first. Even slight changes can disrupt its delicate balance >(e.g., waiting until interval expiration to reset can prevent the >network from reaching consistency). OK, I understand the issue. Clearly, I did not underline enough that this quick connection process would only be used by leaf nodes which will not directly change the network topology. As a consequence , inconsistency will not occur in this case. >3) It is absolutely critical that reset be tied the transmission >mechanism. In particular, it can be disastrous when a node responds >immediately to a multicast message. As a reminder, the proposal was to have two flags in DIS packets to driv e the behavior of the neighbor router : - R flag: controls the reset of the Trickle Timer at the neighbor router - U flag: requests a unicast /multicast answer from the neighbor router More precisely, the configuration R=3D0 (don't reset) and U=3D1 (unicast) is the one we absolutely need. As already explained above, this configuration should be reserved to the quick attachment of a leaf node to the network, which will not disrupt the network topology. As a side comment, RPL is a routing protocol. Collision avoidance should be managed at the MAC layer. For sure, we do not want to encourage a lot of immediate answers to a multicast message. This is the "raison d'=EAtre" of the filtering options in DIS. Moreover, some MAC layers are able to correctly handle a decent number of concurrent answers. >4) The Trickle timer is not doing more than it was intended to do; it is >a simple yet amazingly powerful mechanism. One major use is establishing >eventual consistency, but there are others. Without a mechanism to achieve the behavior that we proposed abo ve , RPL will not achieve the lifetime of currently deployed smart metering networks using propriatery protocols. Again, see msg... and msg... for details. >Phil Thanks, Nicolas. ----------------------- As a complement to Dominique's example, a much more critical setting is an appartment building ensemble. We have experienced rare "worst cases" where all meters and routers are in radio range. You still need a fair amount of routers for energy density and link stabili= ty. Using the same notations as http://www.ietf.org/mail-archive/web/roll/current/msg03306.html, here are rough calculations: ****** with no DIS options 1 DIS transmission from meter, responded to by N meters and 3N/20 routeurs NT =3D 1 + N + 3N/20 =3D 1 + 23N/20 All N meters and 3N/20 routers overhear all transmissions NR =3D NT * 23N/20 Therefore Etotal =3D 6 * NT + NT * 23N/20 =3D 6 * (1 + 23N/20) + (1 + 23N/20)*23N/20 =3D 6 + 8.05 N + 1.3225 N^2 ******* with DIS options still assuming 7 rounds are necessary to get a response NT0 =3D 7 Let's assume that, in addition to the filtering mentioned in previous mail, we also filter on node attribute to exclude responses from meters Number of DIO transmissions from meters NT1 =3D 0 Number of DIO transmissions from routers NT2 =3D N/40 NR =3D NT * 23N/20 Etotal =3D 6 * (7+N/40) + (7+N/40)*23N/20 =3D 42 + 6N/40 + 161N/20 + 23N^2/= 800 In this setting, the energy saving ranges from 3 to 20 as N is varied accross [20..200]. ----------------------- From nicolas.dejean.ietf@googlemail.com Tue Jul 13 07:21:57 2010 Return-Path: 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 EC9B03A67AC for ; Tue, 13 Jul 2010 07:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_47=0.6] 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 g-Q95pCCVjZb for ; Tue, 13 Jul 2010 07:21:55 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4222C3A676A for ; Tue, 13 Jul 2010 07:21:55 -0700 (PDT) Received: by ewy22 with SMTP id 22so1361049ewy.31 for ; Tue, 13 Jul 2010 07:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IN0EOs9xaXmltcEPiHEPZ1a6ULmdDAoTgJ4jXQ8rU0I=; b=kX6tyFMcKpRz2CZkFbiqkjFJswR4fLwCcYCbG7sNke2sZAwiaN5Pga0l/iaa9S5ZsW lw7d4JH2/BExAJkvGUOMgizh5oZJcmekbnBDim0/R96nPrGFdsr2zJiyLIT5J8OZ+2f2 E2HrTzylN3WpgTf+xZgOUcUX0nLbz5qkbTINw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GUugxOUZuV93QqQuan3Dmjfzqxj/YG1xCRAhySQPmdAUueuTWUP/p20TT+drEC5Mtd IJrfyR1I9Qtr6wREbUwo7IBxVA6J9MvJrouTfJbJcw+UJTKlizEgKlzMMnJj/SYrQ3ZO oIW4+eDMZELIUMCcEijMMU5GX5VHB0AVDaVRE= MIME-Version: 1.0 Received: by 10.213.32.197 with SMTP id e5mr11427465ebd.41.1279030919233; Tue, 13 Jul 2010 07:21:59 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Tue, 13 Jul 2010 07:21:59 -0700 (PDT) In-Reply-To: <4C3B9001.3050505@acm.org> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> Date: Tue, 13 Jul 2010 16:21:59 +0200 Message-ID: From: Nicolas DEJEAN To: Tim Winter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 14:21:57 -0000 Hello Tim, 2010/7/12 Tim Winter : > Hi Nicolas, Phil, > > > On 07/01/2010 10:45 PM, Philip Levis wrote: >> >> On Jul 1, 2010, at 11:51 AM, Nicolas DEJEAN wrote: >> >>> Hi Pascal, WG, >>> >>> 2010/6/30 Pascal Thubert (pthubert) : > > [SNIP] > >>>> Anything else we need to add / update / delete ? >>>> >>> >>> As you asked for other updates, I had a look at rpl-10. >>> >>> Despite the impressing amount of work performed on this version, I >>> have not seen any change concerning the DIS reception and Trickle >>> Timer Reset. >>> This issue was raised while dealing with Ticket #29. >>> http://www.ietf.org/mail-archive/web/roll/current/msg03810.html is the >>> last message posted on the thread (by me) before closing with the >>> conclusion that DIS could now carry TLVs. >>> >>> This is already fine but the other subject discussed (that was not >>> part of the ticket #29) has been lost in the battle. >>> >>> It seems to me that we had almost reached a concensus on this subject >>> by adding some flags in order to break the currently existing link >>> between: >>> - the transmission method used for sending the DIS (unicast/multicast) >>> - the Reset of the Trickle Timer (inconsistencies) >>> - the transmission method used for answering (again unicast/multicast) >>> >>> Some flags were proposed: >>> - C/R flag for driving the reset of the Trickle Timer >>> - U flag for driving how the answered DIOs must be sent:unicast or >>> multicast >>> >>> In rpl-10, some options exist but there is no such flag defined. >>> >>> Moreover, the second and third bullets describing the different >>> Trickle Timer reset cases in section 7.3 contain hard MUST that could >>> be softened by the flags proposed and let the door openened to some >>> evolutions. >>> >>> IMHO, adding these 2 flags gives some opportunity to implement >>> solutions like the 'Quick connection process' I described without >>> adding complexity. Moreover, methods, goals and consequences will not >>> be linked (Clarity is also a protocol quality). >>> >>> What do you think? >> >> A couple of thoughts/opinions: >> >> 1) I personally don't think these optimizations matter much. The >> possible cost of disrupting Trickle is much, much higher than the cost >> of a few extra timer resets. In highly, highly dynamic environments, we >> see CTP's trickle-based control traffic to be 6-8% of the total traffic. >> Since CTP uses datapath validation, this is tied to the data rate (it >> wouldn't go up much if we lowered the data rate). In stable >> environments, it can be under 1%. If we're worried about the efficiency >> of RPL, this is *not* the place to start. >> >> 2) There's extensive research and deployment experience with Trickle; we >> know how it works both in theory and practice. This doesn't mean it >> can't be improved (Joakim has made several good points), but I'd >> strongly, strongly caution against tweaking it without a lot of evidence >> and testing first. Even slight changes can disrupt its delicate balance >> (e.g., waiting until interval expiration to reset can prevent the >> network from reaching consistency). >> >> 3) It is absolutely critical that reset be tied the transmission >> mechanism. In particular, it can be disastrous when a node responds >> immediately to a multicast message. >> >> 4) The Trickle timer is not doing more than it was intended to do; it is >> a simple yet amazingly powerful mechanism. One major use is establishing >> eventual consistency, but there are others. >> >> Phil >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > RPL-10 does keep some bits reserved in the DIS message as well as the > Solicited Information option -- do you think that it would make sense to = get > more experience with the proposed =A0C/R, U flags and then, after they ha= ve > been proved out and all of the ramifications are understood, to define th= em > in a future extension to the RPL base specfication? > > -Tim > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > In a general manner, I would tend to agree. However, what disturbs me in this particular case is that a critical case as clearly been identified and documented. I'm afraid that the barrier to adoption of the mechanism we need will greatly increase once RPL is out as an RFC without them. I would feel really more comfortable if: - we defined the flags, - take them into account in the different Trickle reset conditions, - add a sentence specifying the default behaviour to be R=3D1 and U=3D0 (this is what we currently have with Trickle) , - add a sentence explaining how the case R=3D 0 and U=3D1 could be used by leaf nodes. Alternatively, can you suggest a better way of achieving the well-identified behavior described above (leaf-node only, no reset, unicast answer)? Thanks, Nicolas. From nicolas.dejean.ietf@googlemail.com Tue Jul 13 07:27:24 2010 Return-Path: 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 0C5EE3A6A4C for ; Tue, 13 Jul 2010 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=1.265, 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 TfeAnOLKtZdO for ; Tue, 13 Jul 2010 07:27:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id AC4B33A6890 for ; Tue, 13 Jul 2010 07:27:22 -0700 (PDT) Received: by eyb7 with SMTP id 7so990256eyb.31 for ; Tue, 13 Jul 2010 07:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=55b+55q2fmcwqQBGhGyo9ta9KLZF7vATTuwsmpzndjM=; b=UIoou1+p+z5o3f3MQJ6jjpU/Wa5HZPQsbqnMoKtZdlKvIzDVw74YV3VrLTOALW8fdq pSLPZrU08RrqR3+TG52ZHK3q9eehX0sK25Jnr6IsEIjIPutgQkB77FD6M5E6gxyKR+6R mAdgvImyj8v73YdiV5SMY2mCRLPOSAhHmqTlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j69mPUcyTac6ie9ucmuBlkph4/jATKVLx8PL7sIsYHe7JA7aEoLVq1CKMbAIOJjgeO 3ux1HAqQSdyMUx8t/USzZm4XLVXwp1LqppZaGxoHzUlZYuucoJGIP3hcfVYaAdZl4xZt whgbwxgy64KCyVHfidPqz29E6TsdRkIbamGEI= MIME-Version: 1.0 Received: by 10.213.35.65 with SMTP id o1mr265045ebd.75.1279031249010; Tue, 13 Jul 2010 07:27:29 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Tue, 13 Jul 2010 07:27:28 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CDAD4@XMB-AMS-107.cisco.com> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D024CDAD4@XMB-AMS-107.cisco.com> Date: Tue, 13 Jul 2010 16:27:28 +0200 Message-ID: From: Nicolas DEJEAN To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 14:27:24 -0000 Hello Pascal, 2010/7/13 Pascal Thubert (pthubert) : > I'm on the same line as Tim and Phil for this one. > > In one hand I agree that the every DIS is not necessarily an > inconsistency that should trigger Trickle to reset its timer, but OTOH > I'm unsure that the originator has all the information to figure that > out. > We have at least identified one case where the originator knows this: the attachment as a leaf node. > Let us get more experience in determining which inconsistencies we > really care about, and then we'll publish add-ons to the standard that > cover those as required. > What disturbs me in postponing the integration of these flags into the specifications is that we already know a common case where the only described behaviour will not fit in terms of energy consumption. Please, read http://www.ietf.org/mail-archive/web/roll/current/msg03306.htm= l as a reference for this case. > Pascal > Thanks, Nicolas. > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Philip >> Levis >> Sent: Tuesday, July 13, 2010 1:07 AM >> To: Tim Winter >> Cc: roll@ietf.org >> Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) >> >> >> On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: >> >> > Hi Nicolas, Phil, >> > >> > >> > RPL-10 does keep some bits reserved in the DIS message as well as > the >> Solicited Information option -- do you think that it would make sense > to get >> more experience with the proposed =A0C/R, U flags and then, after they > have >> been proved out and all of the ramifications are understood, to define > them in >> a future extension to the RPL base specfication? >> >> Sure, makes sense to me. Until then, we should strive for the minimum > viable >> protocol. >> >> 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 nicolas.dejean.ietf@googlemail.com Tue Jul 13 07:32:06 2010 Return-Path: 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 7B8B63A6A0C for ; Tue, 13 Jul 2010 07:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=0.843, 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 YFGjAGsyl+Nl for ; Tue, 13 Jul 2010 07:32:05 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 18B853A6852 for ; Tue, 13 Jul 2010 07:32:04 -0700 (PDT) Received: by ewy22 with SMTP id 22so1364537ewy.31 for ; Tue, 13 Jul 2010 07:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ak5+IK76/EHXfwGC3RwuBuHUL5WjVNUMMEGxzyRd4Cc=; b=xxStnqcDOLNXExxL69G9GLPwZ8k2WwQUxCfqmY2gbuaWzdBTyx6uUQsncuKkeugSot I6dVZ3WeYu661NCMs9m/W5Ktr99qjouLHTRBc6mNC48eB2jnGKA1sDUDIH/7LAe6b7g8 QxmDyHeMvUP/5Tod3zRzv3e7pctRF9lyUxuTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LCu2uA/IgMALXVtmNgI9UupnJpSquWkFwVQ/RJkG4TYwg8Mc+4+AekpkRuqO+mQb5Y QEw3vy8f8QJPxhZjXfP2eo+sOT7rvPYUPXKPTze72dwbuFc0CBfaxKRa3RRe/uigQuSR XRiBG0okR3x1Er5IWAgSKB6X1phEtwPaUsgoE= MIME-Version: 1.0 Received: by 10.213.10.67 with SMTP id o3mr11229459ebo.27.1279031530992; Tue, 13 Jul 2010 07:32:10 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Tue, 13 Jul 2010 07:32:10 -0700 (PDT) In-Reply-To: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> Date: Tue, 13 Jul 2010 16:32:10 +0200 Message-ID: From: Nicolas DEJEAN To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 14:32:06 -0000 Hello JP, 2010/7/13 JP Vasseur : > I think so too. Nicolas, you could have a simple ID defining those bits i= n a > separate document. > At least the DIS format is now flexible to allow for such extensions. > You are right, the DIS format should allow that. My issue here is that on the one hand there is a collection of MUSTs that drive the behaviour of Trickle and on the other hand we have shown that this behaviour does not satisfy a clearly identified, common , application category. If we don't add NOW a way by which leaf-nodes can do a multicast DIS request and get unicast reponses without Trickle timer reset, it will be increasingly difficult to get that behavior later, as it will have to contradict some RFC text. We are fine with specifying the DIS filtering options in a separate ID , since it will require some amount of text. However, creating a separate ID only for two flag bits and one bit combination seems a bit odd to me. > JP. Thanks, Nicolas. > > On Jul 13, 2010, at 1:07 AM, Philip Levis wrote: > >> >> On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: >> >>> Hi Nicolas, Phil, >>> >>> >>> RPL-10 does keep some bits reserved in the DIS message as well as the >>> Solicited Information option -- do you think that it would make sense t= o get >>> more experience with the proposed =A0C/R, U flags and then, after they = have >>> been proved out and all of the ramifications are understood, to define = them >>> in a future extension to the RPL base specfication? >> >> Sure, makes sense to me. Until then, we should strive for the minimum >> viable protocol. >> >> 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 pal@cs.stanford.edu Tue Jul 13 10:01:36 2010 Return-Path: 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 B8B813A6824 for ; Tue, 13 Jul 2010 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 ypVvs-WiW8aa for ; Tue, 13 Jul 2010 10:01:34 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A42FD3A6A97 for ; Tue, 13 Jul 2010 10:01:33 -0700 (PDT) Received: from [172.27.75.114] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OYirW-0000uP-JH; Tue, 13 Jul 2010 10:01:43 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 13 Jul 2010 10:01:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 13 Jul 2010 17:01:37 -0000 On Jul 13, 2010, at 7:17 AM, Nicolas DEJEAN wrote: > Hello Phil, >=20 >> A couple of thoughts/opinions: >=20 >> 1) I personally don't think these optimizations matter much. >=20 > Dominique had explained and documented in > http://www.ietf.org/mail-archive/web/roll/current/msg03306.html that > these optimizations do matter in our application domain. Please find > at the bottom of this message the description of an even more critical > case extracted from real life deployment. I'm confused: the message you reference describes the need for filtering = who responds to a DIS, mechanisms which are in the draft currently. = There's no mention for need of U and R bits. Phil= From navagar@cisco.com Tue Jul 13 10:16:51 2010 Return-Path: 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 D8A663A6B3F for ; Tue, 13 Jul 2010 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 zD3NS2ViowF2 for ; Tue, 13 Jul 2010 10:16:44 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C46AB3A6B39 for ; Tue, 13 Jul 2010 10:16:43 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOM8PExAaHte/2dsb2JhbACfY3GlU5phhScEg3uHAw X-IronPort-AV: E=Sophos;i="4.55,196,1278288000"; d="scan'208,217";a="230400916" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2010 17:16:45 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6DHGin4003428; Tue, 13 Jul 2010 17:16:45 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 22:46:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB22AF.2ADCD8AA" Date: Tue, 13 Jul 2010 22:46:43 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB0196BFE1@XMB-BGL-41C.cisco.com> In-Reply-To: <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8gABVACUkAF9ay8A== References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> <03CBBD5D7D22764D8DDFA2295A19D68E08350A42@EVS4.nam.ci.root> <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> From: "Navneet Agarwal (navagar)" To: "Alexander, Roger" , "ROLL WG" X-OriginalArrivalTime: 13 Jul 2010 17:16:45.0121 (UTC) FILETIME=[2B4BF310:01CB22AF] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Tue, 13 Jul 2010 17:16:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB22AF.2ADCD8AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps clears the path control operation. =20 I think it would be good if some additional text related to below is added to the RFC. =20 Some comments: =20 1. "Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root."=20 I guess this should apply to all DAOs (Path as well as no-Path). I do see some issues when a node has multiple DAO parents and they are received and processed at a common ancestor. 2. On a related topic, since there is a preference associated with each path for a prefix, a node does not allow for loadbalancing if there are multiple paths reported for a prefix. Right? =20 Thx =20 Regards, Navneet ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 =09 Hi Navneet, =09 =09 =09 Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group). =20 =09 One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root. =09 =09 Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. =09 =09 Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO. =09 =09 If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries. =09 =09 =09 Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. =09 =09 =09 To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. =09 =09 =09 Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents. =09 =09 =09 There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. =09 =09 =09 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and downward paths. =09 =09 =09 The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. =09 =09 =09 This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10. =09 =09 =09 Make sense? See also a specific related comment below. =09 =09 =09 Regards, =09 =09 =09 Roger =09 =09 =09 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org ] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =09 =09 =09 Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =09 =09 =09 Scenario-1: =09 =09 =09 A B =09 \ / =09 \ / =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. =09 Assume path control allows two paths. =09 D and E have learnt a common prefix for a node below them, Pfx =09 D will set x10 in Path control of DAO sent to C =09 E will set x01 in Path control of DAO sent to C =09 C will set x10 in Path control of DAO sent to A =09 C will set x01 in Path control of DAO sent to B =09 =09 =09 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =09 =09 =09 Scenario-2: =09 =09 =09 F G =09 \ / =09 \ / =09 A =09 | =09 | =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 D will set x10 in Path control of DAO sent to C =09 E will set x01 in Path control of DAO sent to C =09 C will send a DAO with path control x11 to A =09 A will send a DAO with path control x01 to F =09 A will send a DAO with path control x10 to G =09 =09 =09 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =09 =09 =09 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =09 =09 =09 Scenario-3 =09 =09 =09 F G =09 \ / =09 \ / =09 A =09 | =09 | =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 Suppose G is preferred over F. =09 Suppose path from E to D is down. =09 D sends DAO with path control x10 to C =09 C sends DAO with path control x10 to A =09 A sends DAO with path control x10 to G =09 =09 =09 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. =09 C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =09 =09 [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. =09 =09 =09 =09 =09 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =09 =09 [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. =09 =09 =09 =09 =09 Thanks =09 =09 =09 Regards, =09 Navneet =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01CB22AF.2ADCD8AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] no-Path DAO and fan-out
Hi Alexander:
Thanks a lot for the detailed = explanation...appreciate=20 it...this helps clears the path control operation.
 
I think it would be good if some additional text = related to=20 below is added to the RFC.
 
Some comments:
 
1.  "Correspondingly, only new or = changed=20 routing/path information that originates from the Prefix owner and hence = indicated by an incremented Path Sequence number must always be passed = along to=20 the root."
I guess this should apply to all DAOs (Path = as well as=20 no-Path). I do see some issues when a node has multiple DAO parents and = they are=20 received and processed at a common ancestor.
2. On a related topic, since there is a preference = associated=20 with each path for a prefix, a node does not allow for loadbalancing if = there=20 are multiple paths reported for a prefix. Right?
 
Thx
 
Regards,
Navneet

From: Alexander, Roger=20 [mailto:Roger.Alexander@cooperindustries.com]
Sent: = Tuesday, July=20 13, 2010 8:25 AM
To: Navneet Agarwal (navagar); ROLL=20 WG
Subject: RE: [Roll] no-Path DAO and = fan-out

Hi Navneet,



Thanks for the scenario = examples=20 which provide a good opportunity to highlight/clarify the role of the = Path=20 Sequence in the DAO exchanges. Below is an explanation of how I = envisaged it=20 would/should operate and would also be interested in the WG's = feedback. (Note:=20 I am assuming your reference to Prefix is as used in the generic RPL = sense of=20 identifying an IPv6 destination address, prefix, or multicast = group).  

One advantage accruing = to=20 storing nodes, in addition to DAO aggregation, is the ability to = further=20 reduce routing overhead by removing the requirement for sub-DAG = changes to=20 always be conveyed all the way to the root. In all of the scenarios = you have=20 defined, when a common ancestor receives a no-Path DAO that is not = originated=20 by the Prefix owner (and hence should not carry an incremented Path = Sequence),=20 there is no requirement for that information to be conveyed beyond the = common=20 ancestor (node C in your examples). Loss of downward path diversity = below the=20 common ancestor does not mean that path diversity above needs to be=20 eliminated. Since the common ancestor still has a downward table entry = to the=20 Prefix via alternate path(s), its ancestors do not need to be further = updated.=20 With the maintained Path Sequence in the no-Path DAO, only nodes that = have a=20 singular downward route to the affected Prefix need to update their = individual=20 DAO Parent(s). Correspondingly, only new or changed routing/path = information=20 that originates from the Prefix owner and hence indicated by an = incremented=20 Path Sequence number must always be passed along to the = root.


Note:=20 The implementation option of limiting when the Path Sequence number is = incremented by a Prefix owner provides a capability to further reduce = routing=20 overhead for storing nodes - though the few bits needed to fully = support=20 incremental/partial updates within the DAO would be still=20 needed.


Where the transmission of the no-Path DAO is being=20 proactively initiated by a DAO Parent or other intermediate ancestor = node that=20 discovers the loss of connectivity (neighbor unreachability detection, = NUD) to=20 the node that owns the Prefix, the Path Sequence used in the no-Path = DAO will=20 be the one maintained by the ancestor node (only the owner of the = Prefix can=20 increment the Path Sequence for that Prefix). This would be the same = as the=20 Path Sequence maintained by all nodes along the path to the common = ancestor.=20 The first common ancestor receiving such a no-Path DAO should mark the = affected downward path for deletion and should take no further action = with=20 regard to upward forwarding of the DAO.


If the owner of the = Prefix=20 discovers the loss of connection to an existing DAO Parent and wishes = to=20 update its path connections, including potentially re-selecting a = different=20 preference set of DAO Parents, the node must increment the Path = Sequence and=20 transmit DAOs to new desired DAO Parents - a no-Path DAO is not = required. The=20 incremented Path Sequence will necessitate that the updated DAOs be = conveyed=20 all the way to the root - in the process updating routing tables at=20 intermediate nodes. Where new downward paths are established as a = result of=20 the updated DAOs, existing intermediate routing tables are directly = updated.=20 Routing table entries that are no longer on the re-established = downward paths=20 will be purged through the normal expiration of the associated = downward route=20 entries.



Note: If the node that owns the Prefix chooses = to=20 maintain its existing DAO Parents and preferences (even with the lost=20 connectivity to, or desired removal of, a single DAO Parent), it can = do so by=20 sending normal periodic or triggered DAO updates to the connected DAO = Parents=20 without incrementing the Path Sequence in the DAO updates. Where = connectivity=20 exists, the owner of the Prefix may also send a no-Path DAO to delete = the path=20 through a given DAO Parent. By not incrementing the Path Sequence the = path=20 through the particular DAO Parent will be removed only to the first = common=20 ancestor.



To redefine DAO Parents and preferences = (including=20 where necessary to maintain fan-out limits), DAOs must be sent with an = incremented Path Sequence number to the newly desired/re-ordered DAO = Parents.=20 The incremented Path Sequence DAOs will ensure that the routing change = is=20 conveyed to the root and recognized by ancestor nodes that can delete = downward=20 path entries. Where the updated DAOs are received at nodes that do not = currently have routing entries for the particular Prefix, the = information is=20 cached and the new DAO information conveyed towards the=20 root.



Based on the above defined operation there is no = benefit=20 to the node owner of the Prefix sending a no-Path DAO with an = incremented Path=20 Sequence. This will travel all the way to the root and will have the = effect of=20 outdating and marking for deletion all existing downward routes for = that=20 Prefix. Instead, to re-establish desired downward paths, DAOs with = incremented=20 Path Sequences should be sent to the desired/maintained DAO=20 Parents.



There would be some benefit to being able to = send a=20 no-Path DAO to delete a single DAO Parent path all the way to the root = but the=20 incremented Path Sequence will make stale all other valid routing = paths (as=20 well as introduce the difficulties raised in your assessments). Note = once=20 again that multiple DAO Parents guarantee only local diversity. = Therefore the=20 fact that deleting a single DAO Parent using an un-incremented Path = Sequence=20 removes diversity only to a common ancestor should be seen in the = context of=20 the local guarantees that are provided.



SUMMARY: If a = no-Path=20 DAO is sent by the Prefix owner to a connected DAO Parent to delete = the single=20 downward path while maintaining the others, the Path Sequence should = be=20 maintained (not incremented) indicating that all established paths = (and=20 preferences) with the exception of the identified DAO Parent path is = being=20 maintained. The path through the particular DAO Parent, only to the = first=20 common ancestor, will be deleted. Where the no-Path DAO is being = proactively=20 sent by an ancestor node due to recognition of NUD, the same would = apply as=20 the Path Sequence number will be the one currently maintained by the = ancestor=20 node. The prefix owner should never send a no-Path DAO with an = incremented=20 Path Sequence but should instead send updated DAOs with incremented = Path=20 Sequence to re-establish or re-order DAO Parents and downward=20 paths.



The operation for non-storing nodes would be the = same.=20 However, in the case of non-storing nodes the first common ancestor is = always=20 the root node. If in the non-storing case a no-path DAO is issued by = the owner=20 of the Prefix or by a DAO Parent (due to proactive response to NUD), = the=20 no-Path DAO with an un-incremented Path Sequence will directly allow = the root=20 to update existing downward paths (removing the identified DAO Parent = while=20 maintaining ordering of remaining DAO Parents). As in the storing = case, a=20 no-Path DAO with an incremented Path Sequence would mark all other = downward=20 paths from the root as potentially outdated (and marked for deletion) = and so=20 should similarly not be issued.



This is the operation = as I=20 believe it should work but I look forward to understanding whether = this=20 envisaged operation can fit within the model given in = -10.



Make=20 sense? See also a specific related comment=20 = below.



Regards,



Roger



From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of=20 Navneet Agarwal (navagar)
Sent: Friday, July 09, 2010 1:26 = PM
To: ROLL=20 WG
Subject: [Roll] no-Path DAO and fan-out



Hi = WG:
I am=20 trying to get some clarifications on expected behavior. Have read the = Path=20 Control document on path ctl field usage (attached). I have put = several setups=20 and flows, assuming storing nodes but should apply for non-storing = scenario as=20 well. I could not figure out from the reading the doc or the=20 = RFC.



Scenario-1:



A     = B

\      /

 \  =20 /

   C

  / =20 \

 /    \

D    =20 E



A, B - DAO Parents.....C - Node........D,E- nodes in=20 subdag.

Assume path control allows two paths.

D and E = have=20 learnt a common prefix for a node below them, Pfx

D will set = x10 in=20 Path control of DAO sent to C

E will set x01 in Path control of = DAO=20 sent to C

C will set x10 in Path control of DAO sent to = A

C will=20 set x01 in Path control of DAO sent to B



Suppose E = sends a=20 no-Path DAO to C for Pfx with path control x01. What does C do? I = would think=20 that C will need to send a no-Path. But it has to remember that it had = sent a=20 DAO with path control x01 to B. If this has to happen then C would = have to=20 remember for each prefix what path control was sent to which parent, = which=20 does not seem correct as it would not scale as the prefixes at C = scale, each=20 having its own path control=20 = settings.



Scenario-2:



F   &n= bsp;=20 G

\    /

 \  = /

  =20 A

    |

    = |

  =20 C

  /  \

 /   =20 \

D     E



D will set x10 in = Path=20 control of DAO sent to C

E will set x01 in Path control of DAO = sent to=20 C

C will send a DAO with path control x11 to A

A will = send a DAO=20 with path control x01 to F

A will send a DAO with path control = x10 to=20 G



Suppose E sends a no-Path to C (path control x01). = What does=20 C do? It will likely send a DAO to A with path control x10. What will = A do=20 when it receives a DAO with this path control when its previous path = control=20 was x11?



I see couple of other flows where path control = settings may change due to sub-nodes going away and coming back = up...for=20 = example:



Scenario-3



F   &nbs= p;=20 G

\    /

 \  = /

  =20 A

    |

    = |

  =20 C

  /  \

 /   =20 \

D     E



Suppose G is = preferred=20 over F.

Suppose path from E to D is down.

D sends DAO = with path=20 control x10 to C

C sends DAO with path control x10 to = A

A sends=20 DAO with path control x10 to G



After some time E comes = up and=20 sends a DAO with path control x01 (higher path preference than D to C) = to=20 C.

C merges this and sends a DAO with path control x11 to A. = What does=20 A do since is has indicated a path control of x10 to G. In normal = terms, if A=20 had received a DAO with path control x11 from C, it would have = notified DAO to=20 F with path control x10 and DAO to G with path control x01 but due to=20 transient conditions it could be reversed.


[RA] In the case = of=20 receipt of the first updated DAO (with incremented Path Sequence) only = the new=20 information with single path control should be forwarded since all = prior path=20 information is effectively obsolete by the incremented Path Sequence. = When=20 subsequent DAO updates are received with the new, incremented Path = Sequence,=20 only then can the combined path control information be=20 forwarded.





Will appreciate if it can be = clarified if=20 the above flows are reasonable and what should happen...in general I = dont=20 think path control should mandate which path control bits are tied to = which=20 DAO parent etc...


[RA] Hopefully the above discussion = supports the=20 view that Path Control can operate as specified without the need to = maintain=20 state on which DAO with which Path Control was sent to which DAO=20 = Parent.





Thanks



Regards,

Navn= eet





------_=_NextPart_001_01CB22AF.2ADCD8AA-- From trac@tools.ietf.org Tue Jul 13 10:44:38 2010 Return-Path: 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 C839C3A69AD for ; Tue, 13 Jul 2010 10:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 SM56dUHLqbVR for ; Tue, 13 Jul 2010 10:44:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1EEB73A6902 for ; Tue, 13 Jul 2010 10:44:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OYjX9-0003v0-PB; Tue, 13 Jul 2010 10:44:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 13 Jul 2010 17:44:43 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/60 Message-ID: <055.52290677ea9b9f72bf1ce609efdca1de@tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #60: More text to be added to no-path DAO and fan out X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 17:44:38 -0000 #60: More text to be added to no-path DAO and fan out -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Below a discussion on the mailing list, leading to more explanation on no path DAO operation and fan-out for revision -11. Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps clears the path control operation. I think it would be good if some additional text related to below is added to the RFC. Some comments: 1. "Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root." I guess this should apply to all DAOs (Path as well as no-Path). I do see some issues when a node has multiple DAO parents and they are received and processed at a common ancestor. 2. On a related topic, since there is a preference associated with each path for a prefix, a node does not allow for loadbalancing if there are multiple paths reported for a prefix. Right? Thx Regards, Navneet From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com] Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out Hi Navneet, Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group). One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root. Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO. If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries. Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents. There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re- establish or re-order DAO Parents and downward paths. The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no- Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10. Make sense? See also a specific related comment below. Regards, Roger From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non- storing scenario as well. I could not figure out from the reading the doc or the RFC. Scenario-1: A B \ / \ / C / \ / \ D E A, B - DAO Parents.....C - Node........D,E- nodes in subdag. Assume path control allows two paths. D and E have learnt a common prefix for a node below them, Pfx D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will set x10 in Path control of DAO sent to A C will set x01 in Path control of DAO sent to B Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. Scenario-2: F G \ / \ / A | | C / \ / \ D E D will set x10 in Path control of DAO sent to C E will set x01 in Path control of DAO sent to C C will send a DAO with path control x11 to A A will send a DAO with path control x01 to F A will send a DAO with path control x10 to G Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: Scenario-3 F G \ / \ / A | | C / \ / \ D E Suppose G is preferred over F. Suppose path from E to D is down. D sends DAO with path control x10 to C C sends DAO with path control x10 to A A sends DAO with path control x10 to G After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. Thanks Regards, Navneet -- Ticket URL: roll From pal@cs.stanford.edu Tue Jul 13 13:07:29 2010 Return-Path: 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 EE9963A69BD for ; Tue, 13 Jul 2010 13:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_20=-0.74, 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 E46u6e0+Z82p for ; Tue, 13 Jul 2010 13:07:20 -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 1C7523A6B6E for ; Tue, 13 Jul 2010 13:07:15 -0700 (PDT) Received: from [172.27.75.114] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OYllD-0002hB-UH; Tue, 13 Jul 2010 13:07:24 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6427.1278635611@marajade.sandelman.ca> Date: Tue, 13 Jul 2010 13:07:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61D42C01-D0BB-4857-A542-03613F05E08F@cs.stanford.edu> References: <6427.1278635611@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: b78a464e305c82b41dcf341f2fb84a2b Cc: roll@ietf.org Subject: Re: [Roll] rpl-10 --- security questions 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: , X-List-Received-Date: Tue, 13 Jul 2010 20:07:29 -0000 Michael, answers to your questions inline. On Jul 8, 2010, at 5:33 PM, Michael Richardson wrote: >=20 > =3D=3D=3D my detailed comments. >=20 > In section 5.1, RPL Security Fields, the Key Identifier may be present > depending upon the value of the KIM field. >=20 > When KIM is 00, 01, and 10, the presence, absence of the Key = Identifier > is clear. (But, if Group key is used, then Key Source is not used, > because, I guess, the Key Index is no longer a local key, but a global > key, so that's why the Key Source is not present?) >=20 > When KIM is 11, a signature is present. Where is the signature = defined? > What is the format of the signature? =20 > When KIM is 11, a key source *MAY* be present and a key index *MAY* be > present. How is this determined? > I think it may come out of the security level, but I don't quite see = how. Yes, it comes out of the security level. If the security level calls = indicates encryption, then Key Index and Key Source are present. If the = security level indicates no encryption, they are not present. I'll adjust the text to make this more explicit. >=20 > It appears that the RPL security fields are not a multiple of 64-bits, > and block-mode AES requires 16-byte blocks, while CCM mode is happy = with > any increment of bits. Assuming that someone will define a second > cipher at some point, we need to know how to padd properly.=20 > But, I don't see any statement about how padding is to be used. This should be up to the cryptographic primitives used. E.g., if a new = cryptographic scheme that requires padding is introduced, that scheme = should define how the padding is done. It seems like a bad idea to try = to specify a blanket policy that will inevitably be wrong for some = algorithms. Does that make sense? >=20 > I also see no way for a node to tell if it is joining an authenticated > network or a pre-installed network. How does a node which is > authenticated know which set of keys (pre-installed or authenticated) = to > use to authenticate a message from a new prospective node?=20 > Is this an inate property of the keys themselves indicated by the Key > Source and Key Index? =20 >=20 > The 'A' bit of the Configuration Option tells a node what it may do. The A bit denotes whether the network is Authenticated or Pre-installed. The security section of a secured RPL message describes which key a node = should use to process an incoming packet. >=20 >=20 >> 2. The timestamp MUST be in 1kHz (millisecond) granularity. >=20 > Is it 1/1000 that one wants, or 1/1024? 1/1024. This is much simpler and easier to maintain with a 32kHz = crystal. >=20 >> 3. The timestamp start time MUST be January 1, 2010, 12:00:00AM = UTC. >=20 > Making it Unix epoch (Jan. 1, 1970) would be simpler. > As the specification says we are supposed to keep 6 bytes (48 bits) of > resolution, this is 274877906944s, or 8700 years. If we go to Jan. = 1970, > then this changes the lifetime of RPL from 8716 years to 8675 years. >=20 > As I understand it, we are only transmitting the lower 32-bits of the > value, in units of 1/1000s. So the timestamp for my email would be: > Unix time(1278331381) * 1000 mod (2^32) =3D 2726094088.=20 Agree that UNIX time is easier and simpler than inventing a new time = zero. However, 1/1024 means that the time value will be different than = standard UNIX time. >=20 >=20 > The entire Compressed Counter mechanism seems like a waste of code > space. I see no savings by doing this in the resulting packets due to > required padding. The ensuing CC process that is needed to deal with > this seems like a further waste. I'd rather define a standard > compression algorithm that we can apply before encryption instead.=20 It sounds like consensus is that counter compression should be removed. = It will be. >=20 >> protection for a received RPL message. The replay check MUST be >> performed following the authentication of the received packet. The >=20 > well, no. The replay check SHOULD be preformed before authentication = of > the packet. If the replay counter says "old", then you discard = without > further processing (do not waste your time/energy verifying old > packets!). If the replay says "new", then you can authenticate first, = and > update the counters if it checks out. =20 The order will be reversed (following the way you recommend). >=20 > I can't tell from the specification if the contents of the "Security > Section" are protected in any way by the integrity check. Section 9.6 > was not helpful, as it says "entire IPv6 packet". I guess this means = the > layer-3, but someone will get it wrong, and include layer-2 too. > When the integrity check is calculated, what is the value in the > security section for the MAC code?=20 >=20 > (I would assume zeroes..) =20 This will be made more clear. Phil= From jreddy@ti.com Tue Jul 13 16:44:00 2010 Return-Path: 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 A00253A6AA5 for ; Tue, 13 Jul 2010 16:44:00 -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 h7cDVeVkWd23 for ; Tue, 13 Jul 2010 16:43:59 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by core3.amsl.com (Postfix) with ESMTP id D43E63A69E5 for ; Tue, 13 Jul 2010 16:43:59 -0700 (PDT) Received: from dlep34.itg.ti.com ([157.170.170.115]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id o6DNi8ER020803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jul 2010 18:44:08 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep34.itg.ti.com (8.13.7/8.13.7) with ESMTP id o6DNi8Mk007978 for ; Tue, 13 Jul 2010 18:44:08 -0500 (CDT) Received: from dsbe71.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id o6DNi7FH029015 for ; Tue, 13 Jul 2010 18:44:07 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dsbe71.ent.ti.com ([156.117.232.23]) with mapi; Tue, 13 Jul 2010 18:44:08 -0500 From: "Reddy, Joseph" To: "roll@ietf.org" Date: Tue, 13 Jul 2010 18:44:05 -0500 Thread-Topic: Local instance id Thread-Index: AcsivdB2DZ+aDvymQBKvhQ//rnpf+wAJnBYA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] Local instance id 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: , X-List-Received-Date: Tue, 13 Jul 2010 23:44:00 -0000 =20 Hi, A question on the local instance ID It used to be that a node can only join one DoDAG within an RPL instance=20 Now, with the concept of local instances, my understanding is that differen= t DoDAG's can have the same local instance identifier ( since they are allo= cated without any coordination ) In this situation, can a node join two DoDAG's with the same local instance= identifier but different DoDAG ID's ? I assume yes, since they two actuall= y different instances that happen to have same identifier If so, how does a router know which on which of the two DoDAG's it should f= orward a data packet that has this particular instance id in the flow label= ? -Thanks, Joseph From jhui@archrock.com Tue Jul 13 17:14:30 2010 Return-Path: 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 B3D533A689C for ; Tue, 13 Jul 2010 17:14:30 -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 A9RyXF16fUTc for ; Tue, 13 Jul 2010 17:14:29 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id E7EB03A6859 for ; Tue, 13 Jul 2010 17:14:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9803EAF9B8; Tue, 13 Jul 2010 17:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BudOJXLuYlRi; Tue, 13 Jul 2010 17:12:44 -0700 (PDT) Received: from [10.0.1.2] (adsl-71-142-91-124.dsl.pltn13.pacbell.net [71.142.91.124]) by mail.sf.archrock.com (Postfix) with ESMTP id 7A736AF99D; Tue, 13 Jul 2010 17:12:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: Date: Tue, 13 Jul 2010 17:14:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1081) Cc: "roll@ietf.org" Subject: Re: [Roll] Local instance id 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: , X-List-Received-Date: Wed, 14 Jul 2010 00:14:30 -0000 Joseph, Local instances are also parameterized on the DODAGID. Section 4.1 of = rpl-10 describes how the RPLInstanceID carried in data packets indicates = which of the IPv6 header addresses (source or destination) to use for = the DODAGID. -- Jonathan Hui On Jul 13, 2010, at 4:44 PM, Reddy, Joseph wrote: >=20 > Hi, >=20 > A question on the local instance ID >=20 > It used to be that a node can only join one DoDAG within an RPL = instance=20 > Now, with the concept of local instances, my understanding is that = different DoDAG's can have the same local instance identifier ( since = they are allocated without any coordination ) >=20 > In this situation, can a node join two DoDAG's with the same local = instance identifier but different DoDAG ID's ? I assume yes, since they = two actually different instances that happen to have same identifier >=20 > If so, how does a router know which on which of the two DoDAG's it = should forward a data packet that has this particular instance id in the = flow label ? >=20 > -Thanks, Joseph >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=804123af8=Roger.Alexander@cooperindustries.com Tue Jul 13 20:32:36 2010 Return-Path: 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 711B33A68DA for ; Tue, 13 Jul 2010 20:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.357, 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 ilymvHPCqDrh for ; Tue, 13 Jul 2010 20:32:33 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id A7A513A67AE for ; Tue, 13 Jul 2010 20:32:31 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,199,1278302400"; d="scan'208,217";a="60867317" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 13 Jul 2010 23:32:40 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 23:32:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2305.2B1F8764" Date: Tue, 13 Jul 2010 23:29:58 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19980D@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8gABVACUkAF9ay8AAbrhwt References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> <03CBBD5D7D22764D8DDFA2295A19D68E08350A42@EVS4.nam.ci.root> <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196BFE1@XMB-BGL-41C.cisco.com> From: "Alexander, Roger" To: "Navneet Agarwal (navagar)" , "ROLL WG" X-OriginalArrivalTime: 14 Jul 2010 03:32:39.0943 (UTC) FILETIME=[36164970:01CB2305] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Wed, 14 Jul 2010 03:32:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2305.2B1F8764 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Navneet, See additional comments below. =20 Regards, Roger=20 -----Original Message----- From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com] Sent: Tue 7/13/2010 1:16 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps = clears the path control operation. =20 I think it would be good if some additional text related to below is = added to the RFC. =20 Some comments: =20 1. "Correspondingly, only new or changed routing/path information that = originates from the Prefix owner and hence indicated by an incremented = Path Sequence number must always be passed along to the root."=20 [RA] Agreed. More generally =93any new or changed routing/path = information that is received at a node must be passed to its DAO = Parent(s)=94. In addition to incremented Path Sequence that new = information may include an existing Prefix with an unchanged Path = Sequence but with different Path Control bits. I guess this should apply to all DAOs (Path as well as no-Path).=20 [RA] Agreed. I do see some issues when a node has multiple DAO parents and they are = received and processed at a common ancestor. [RA] There may be issues related to dynamic changes in the DAO Parent = set of an ancestor node but these should be transient and normalized in = the course of subsequent DAO updates (with and without incremented Path = Sequence) - where a common ancestor receiving the very same DAO = information from multiple children maintains the most recent update. =20 Where a common ancestor receives DAOs along different paths from a node = with multiple DAO Parents a consistent rule will ensure that assignments = can be made without needing to maintain per-DAO state information. As an = implementation choice, a node can maintain a fixed-assignment rule in = which DAOs with particular path control bits set are always divided = across the existing DAO Parent set in a given way. For example, if the = node has 2 DAO Parents and a maximum path control size (PCS) of 4 is = configured for the DODAG, any DAO with one or more of the two highest = preference path control bits set are always assigned to the higher = preference DAO Parent; DAOs with the lower preference path control bits = sets are propagated to the other DAO Parent. Correspondingly, DAOs with = more than 2 path control bits set will be split across the two DAO = Parents with higher order path control bits set in the DAO send to the = higher preference DAO Parent. Each node will apply a fixed-assignment = rule according to its current number of DAO Parents and the DODAG PSC. = Thus even as multiple DAOs arrive with different delays at a common = ancestor, each is received and asynchronously assigned according to the = fixed-assignment rule. Where a later arriving DAO is to be sent to a DAO = Parent to which an earlier DAO has been propagated, the path control = bits are aggregated representing the new combined information and the = new DAO propagated forward. =20 Note: Other fixed-assignment rules may also be possible. For example, = the highest preference path control DAO assigned to the highest = preference DAO Parent and all other PSC-allowed path control DAOs = distributed across the remaining DAO Parents.=20 2. On a related topic, since there is a preference associated with each = path for a prefix, a node does not allow for loadbalancing if there are = multiple paths reported for a prefix. Right? [RA] Downward path load balancing at a common ancestor is still possible = for a given prefix though that load balancing need not be uniform. It = can be weighted where the preferred path (single Parent, tree-equivalent = path) is one of the next hop options, or it can be uniform where the = preferred path is not a member of the next hop options. Load balancing = can also consider diversity that may be derived from the number of paths = (path control bits) associated with a given next hop route. As = indicated in the original note, path control only guarantees that the = preferred path can always be distinguished from others. Th preference = ordering of other paths are softer and more loosely maintained as a = function of the local application of preference. =20 Thx =20 Regards, Navneet ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 =09 Hi Navneet, =09 =09 =09 Thanks for the scenario examples which provide a good opportunity to = highlight/clarify the role of the Path Sequence in the DAO exchanges. = Below is an explanation of how I envisaged it would/should operate and = would also be interested in the WG's feedback. (Note: I am assuming your = reference to Prefix is as used in the generic RPL sense of identifying = an IPv6 destination address, prefix, or multicast group). =20 =09 One advantage accruing to storing nodes, in addition to DAO = aggregation, is the ability to further reduce routing overhead by = removing the requirement for sub-DAG changes to always be conveyed all = the way to the root. In all of the scenarios you have defined, when a = common ancestor receives a no-Path DAO that is not originated by the = Prefix owner (and hence should not carry an incremented Path Sequence), = there is no requirement for that information to be conveyed beyond the = common ancestor (node C in your examples). Loss of downward path = diversity below the common ancestor does not mean that path diversity = above needs to be eliminated. Since the common ancestor still has a = downward table entry to the Prefix via alternate path(s), its ancestors = do not need to be further updated. With the maintained Path Sequence in = the no-Path DAO, only nodes that have a singular downward route to the = affected Prefix need to update their individual DAO Parent(s). = Correspondingly, only new or changed routing/path information that = originates from the Prefix owner and hence indicated by an incremented = Path Sequence number must always be passed along to the root. =09 =09 Note: The implementation option of limiting when the Path Sequence = number is incremented by a Prefix owner provides a capability to further = reduce routing overhead for storing nodes - though the few bits needed = to fully support incremental/partial updates within the DAO would be = still needed. =09 =09 Where the transmission of the no-Path DAO is being proactively = initiated by a DAO Parent or other intermediate ancestor node that = discovers the loss of connectivity (neighbor unreachability detection, = NUD) to the node that owns the Prefix, the Path Sequence used in the = no-Path DAO will be the one maintained by the ancestor node (only the = owner of the Prefix can increment the Path Sequence for that Prefix). = This would be the same as the Path Sequence maintained by all nodes = along the path to the common ancestor. The first common ancestor = receiving such a no-Path DAO should mark the affected downward path for = deletion and should take no further action with regard to upward = forwarding of the DAO. =09 =09 If the owner of the Prefix discovers the loss of connection to an = existing DAO Parent and wishes to update its path connections, including = potentially re-selecting a different preference set of DAO Parents, the = node must increment the Path Sequence and transmit DAOs to new desired = DAO Parents - a no-Path DAO is not required. The incremented Path = Sequence will necessitate that the updated DAOs be conveyed all the way = to the root - in the process updating routing tables at intermediate = nodes. Where new downward paths are established as a result of the = updated DAOs, existing intermediate routing tables are directly updated. = Routing table entries that are no longer on the re-established downward = paths will be purged through the normal expiration of the associated = downward route entries. =09 =09 =09 Note: If the node that owns the Prefix chooses to maintain its existing = DAO Parents and preferences (even with the lost connectivity to, or = desired removal of, a single DAO Parent), it can do so by sending normal = periodic or triggered DAO updates to the connected DAO Parents without = incrementing the Path Sequence in the DAO updates. Where connectivity = exists, the owner of the Prefix may also send a no-Path DAO to delete = the path through a given DAO Parent. By not incrementing the Path = Sequence the path through the particular DAO Parent will be removed only = to the first common ancestor. =09 =09 =09 To redefine DAO Parents and preferences (including where necessary to = maintain fan-out limits), DAOs must be sent with an incremented Path = Sequence number to the newly desired/re-ordered DAO Parents. The = incremented Path Sequence DAOs will ensure that the routing change is = conveyed to the root and recognized by ancestor nodes that can delete = downward path entries. Where the updated DAOs are received at nodes that = do not currently have routing entries for the particular Prefix, the = information is cached and the new DAO information conveyed towards the = root. =09 =09 =09 Based on the above defined operation there is no benefit to the node = owner of the Prefix sending a no-Path DAO with an incremented Path = Sequence. This will travel all the way to the root and will have the = effect of outdating and marking for deletion all existing downward = routes for that Prefix. Instead, to re-establish desired downward paths, = DAOs with incremented Path Sequences should be sent to the = desired/maintained DAO Parents. =09 =09 =09 There would be some benefit to being able to send a no-Path DAO to = delete a single DAO Parent path all the way to the root but the = incremented Path Sequence will make stale all other valid routing paths = (as well as introduce the difficulties raised in your assessments). Note = once again that multiple DAO Parents guarantee only local diversity. = Therefore the fact that deleting a single DAO Parent using an = un-incremented Path Sequence removes diversity only to a common ancestor = should be seen in the context of the local guarantees that are provided. =09 =09 =09 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected = DAO Parent to delete the single downward path while maintaining the = others, the Path Sequence should be maintained (not incremented) = indicating that all established paths (and preferences) with the = exception of the identified DAO Parent path is being maintained. The = path through the particular DAO Parent, only to the first common = ancestor, will be deleted. Where the no-Path DAO is being proactively = sent by an ancestor node due to recognition of NUD, the same would apply = as the Path Sequence number will be the one currently maintained by the = ancestor node. The prefix owner should never send a no-Path DAO with an = incremented Path Sequence but should instead send updated DAOs with = incremented Path Sequence to re-establish or re-order DAO Parents and = downward paths. =09 =09 =09 The operation for non-storing nodes would be the same. However, in the = case of non-storing nodes the first common ancestor is always the root = node. If in the non-storing case a no-path DAO is issued by the owner of = the Prefix or by a DAO Parent (due to proactive response to NUD), the = no-Path DAO with an un-incremented Path Sequence will directly allow the = root to update existing downward paths (removing the identified DAO = Parent while maintaining ordering of remaining DAO Parents). As in the = storing case, a no-Path DAO with an incremented Path Sequence would mark = all other downward paths from the root as potentially outdated (and = marked for deletion) and so should similarly not be issued. =09 =09 =09 This is the operation as I believe it should work but I look forward to = understanding whether this envisaged operation can fit within the model = given in -10. =09 =09 =09 Make sense? See also a specific related comment below. =09 =09 =09 Regards, =09 =09 =09 Roger =09 =09 =09 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org = ] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =09 =09 =09 Hi WG: I am trying to get some clarifications on expected behavior. Have read = the Path Control document on path ctl field usage (attached). I have put = several setups and flows, assuming storing nodes but should apply for = non-storing scenario as well. I could not figure out from the reading = the doc or the RFC. =09 =09 =09 Scenario-1: =09 =09 =09 A B =09 \ / =09 \ / =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. =09 Assume path control allows two paths. =09 D and E have learnt a common prefix for a node below them, Pfx =09 D will set x10 in Path control of DAO sent to C =09 E will set x01 in Path control of DAO sent to C =09 C will set x10 in Path control of DAO sent to A =09 C will set x01 in Path control of DAO sent to B =09 =09 =09 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What = does C do? I would think that C will need to send a no-Path. But it has = to remember that it had sent a DAO with path control x01 to B. If this = has to happen then C would have to remember for each prefix what path = control was sent to which parent, which does not seem correct as it = would not scale as the prefixes at C scale, each having its own path = control settings. =09 =09 =09 Scenario-2: =09 =09 =09 F G =09 \ / =09 \ / =09 A =09 | =09 | =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 D will set x10 in Path control of DAO sent to C =09 E will set x01 in Path control of DAO sent to C =09 C will send a DAO with path control x11 to A =09 A will send a DAO with path control x01 to F =09 A will send a DAO with path control x10 to G =09 =09 =09 Suppose E sends a no-Path to C (path control x01). What does C do? It = will likely send a DAO to A with path control x10. What will A do when = it receives a DAO with this path control when its previous path control = was x11? =09 =09 =09 I see couple of other flows where path control settings may change due = to sub-nodes going away and coming back up...for example: =09 =09 =09 Scenario-3 =09 =09 =09 F G =09 \ / =09 \ / =09 A =09 | =09 | =09 C =09 / \ =09 / \ =09 D E =09 =09 =09 Suppose G is preferred over F. =09 Suppose path from E to D is down. =09 D sends DAO with path control x10 to C =09 C sends DAO with path control x10 to A =09 A sends DAO with path control x10 to G =09 =09 =09 After some time E comes up and sends a DAO with path control x01 = (higher path preference than D to C) to C. =09 C merges this and sends a DAO with path control x11 to A. What does A = do since is has indicated a path control of x10 to G. In normal terms, = if A had received a DAO with path control x11 from C, it would have = notified DAO to F with path control x10 and DAO to G with path control = x01 but due to transient conditions it could be reversed. =09 =09 [RA] In the case of receipt of the first updated DAO (with incremented = Path Sequence) only the new information with single path control should = be forwarded since all prior path information is effectively obsolete by = the incremented Path Sequence. When subsequent DAO updates are received = with the new, incremented Path Sequence, only then can the combined path = control information be forwarded. =09 =09 =09 =09 =09 Will appreciate if it can be clarified if the above flows are = reasonable and what should happen...in general I dont think path control = should mandate which path control bits are tied to which DAO parent = etc... =09 =09 [RA] Hopefully the above discussion supports the view that Path Control = can operate as specified without the need to maintain state on which DAO = with which Path Control was sent to which DAO Parent. =09 =09 =09 =09 =09 Thanks =09 =09 =09 Regards, =09 Navneet =09 =09 =09 =09 =09 =09 =09 ------_=_NextPart_001_01CB2305.2B1F8764 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Roll] no-Path DAO and fan-out

Hi Navneet,

See additional comments below.

Regards,

Roger



-----Original Message-----
From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]
Sent: Tue 7/13/2010 1:16 PM
To: Alexander, Roger; ROLL WG
Subject: RE: [Roll] no-Path DAO and fan-out

Hi Alexander:
Thanks a lot for the detailed explanation...appreciate it...this helps = clears the path control operation.

I think it would be good if some additional text related to below is = added to the RFC.

Some comments:

1.  "Correspondingly, only new or changed routing/path = information that originates from the Prefix owner and hence indicated by = an incremented Path Sequence number must always be passed along to the = root."

[RA] Agreed. More generally “any new or changed routing/path = information that is received at a node must be passed to its DAO = Parent(s)”. In addition to incremented Path Sequence that new = information may include an existing Prefix with an unchanged Path = Sequence but with different Path Control bits.



I guess this should apply to all DAOs (Path as well as no-Path).
[RA] Agreed.


I do see some issues when a node has multiple DAO parents and they are = received and processed at a common ancestor.

[RA] There may be issues related to dynamic changes in the DAO Parent = set of an ancestor node but these should be transient and normalized in = the course of subsequent DAO updates (with and without incremented Path = Sequence) - where a common ancestor receiving the very same DAO = information from multiple children maintains the most recent update.

Where a common ancestor receives DAOs along different paths from a node = with multiple DAO Parents a consistent rule will ensure that assignments = can be made without needing to maintain per-DAO state information. As an = implementation choice, a node can maintain a fixed-assignment rule in = which DAOs with particular path control bits set are always divided = across the existing DAO Parent set in a given way. For example, if the = node has 2 DAO Parents and a maximum path control size (PCS) of 4 is = configured for the DODAG, any DAO with one or more of the two highest = preference path control bits set are always assigned to the higher = preference DAO Parent; DAOs with the lower preference path control bits = sets are propagated to the other DAO Parent. Correspondingly, DAOs with = more than 2 path control bits set will be split across the two DAO = Parents with higher order path control bits set in the DAO send to the = higher preference DAO Parent. Each node will apply a fixed-assignment = rule according to its current number of DAO Parents and the DODAG PSC. = Thus even as multiple DAOs arrive with different delays at a common = ancestor, each is received and asynchronously assigned according to the = fixed-assignment rule. Where a later arriving DAO is to be sent to a DAO = Parent to which an earlier DAO has been propagated, the path control = bits are aggregated representing the new combined information and the = new DAO propagated forward.
   
Note: Other fixed-assignment rules may also be possible. For example, = the highest preference path control DAO assigned to the highest = preference DAO Parent and all other PSC-allowed path control DAOs = distributed across the remaining DAO Parents.


2. On a related topic, since there is a preference associated with each = path for a prefix, a node does not allow for loadbalancing if there are = multiple paths reported for a prefix. Right?

[RA] Downward path load balancing at a common ancestor is still possible = for a given prefix though that load balancing need not be uniform. It = can be weighted where the preferred path (single Parent, tree-equivalent = path) is one of the next hop options, or it can be uniform where the = preferred path is not a member of the next hop options. Load balancing = can also consider diversity that may be derived from the number of paths = (path control bits) associated with a given next hop route.  As = indicated in the original note, path control only guarantees that the = preferred path can always be distinguished from others. Th preference = ordering of other paths are softer and more loosely maintained as a = function of the local application of preference.



Thx

Regards,
Navneet


________________________________

        From: Alexander, Roger [mailto:Roger.Alexand= er@cooperindustries.com]
        Sent: Tuesday, July 13, 2010 = 8:25 AM
        To: Navneet Agarwal = (navagar); ROLL WG
        Subject: RE: [Roll] no-Path = DAO and fan-out
       
       

        Hi Navneet,
       
       
       
        Thanks for the scenario = examples which provide a good opportunity to highlight/clarify the role = of the Path Sequence in the DAO exchanges. Below is an explanation of = how I envisaged it would/should operate and would also be interested in = the WG's feedback. (Note: I am assuming your reference to Prefix is as = used in the generic RPL sense of identifying an IPv6 destination = address, prefix, or multicast group). 
       
        One advantage accruing to = storing nodes, in addition to DAO aggregation, is the ability to further = reduce routing overhead by removing the requirement for sub-DAG changes = to always be conveyed all the way to the root. In all of the scenarios = you have defined, when a common ancestor receives a no-Path DAO that is = not originated by the Prefix owner (and hence should not carry an = incremented Path Sequence), there is no requirement for that information = to be conveyed beyond the common ancestor (node C in your examples). = Loss of downward path diversity below the common ancestor does not mean = that path diversity above needs to be eliminated. Since the common = ancestor still has a downward table entry to the Prefix via alternate = path(s), its ancestors do not need to be further updated. With the = maintained Path Sequence in the no-Path DAO, only nodes that have a = singular downward route to the affected Prefix need to update their = individual DAO Parent(s). Correspondingly, only new or changed = routing/path information that originates from the Prefix owner and hence = indicated by an incremented Path Sequence number must always be passed = along to the root.
       
       
        Note: The implementation = option of limiting when the Path Sequence number is incremented by a = Prefix owner provides a capability to further reduce routing overhead = for storing nodes - though the few bits needed to fully support = incremental/partial updates within the DAO would be still needed.
       
       
        Where the transmission of the = no-Path DAO is being proactively initiated by a DAO Parent or other = intermediate ancestor node that discovers the loss of connectivity = (neighbor unreachability detection, NUD) to the node that owns the = Prefix, the Path Sequence used in the no-Path DAO will be the one = maintained by the ancestor node (only the owner of the Prefix can = increment the Path Sequence for that Prefix). This would be the same as = the Path Sequence maintained by all nodes along the path to the common = ancestor. The first common ancestor receiving such a no-Path DAO should = mark the affected downward path for deletion and should take no further = action with regard to upward forwarding of the DAO.
       
       
        If the owner of the Prefix = discovers the loss of connection to an existing DAO Parent and wishes to = update its path connections, including potentially re-selecting a = different preference set of DAO Parents, the node must increment the = Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path = DAO is not required. The incremented Path Sequence will necessitate that = the updated DAOs be conveyed all the way to the root - in the process = updating routing tables at intermediate nodes. Where new downward paths = are established as a result of the updated DAOs, existing intermediate = routing tables are directly updated. Routing table entries that are no = longer on the re-established downward paths will be purged through the = normal expiration of the associated downward route entries.
       
       
       
        Note: If the node that owns = the Prefix chooses to maintain its existing DAO Parents and preferences = (even with the lost connectivity to, or desired removal of, a single DAO = Parent), it can do so by sending normal periodic or triggered DAO = updates to the connected DAO Parents without incrementing the Path = Sequence in the DAO updates. Where connectivity exists, the owner of the = Prefix may also send a no-Path DAO to delete the path through a given = DAO Parent. By not incrementing the Path Sequence the path through the = particular DAO Parent will be removed only to the first common = ancestor.
       
       
       
        To redefine DAO Parents and = preferences (including where necessary to maintain fan-out limits), DAOs = must be sent with an incremented Path Sequence number to the newly = desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will = ensure that the routing change is conveyed to the root and recognized by = ancestor nodes that can delete downward path entries. Where the updated = DAOs are received at nodes that do not currently have routing entries = for the particular Prefix, the information is cached and the new DAO = information conveyed towards the root.
       
       
       
        Based on the above defined = operation there is no benefit to the node owner of the Prefix sending a = no-Path DAO with an incremented Path Sequence. This will travel all the = way to the root and will have the effect of outdating and marking for = deletion all existing downward routes for that Prefix. Instead, to = re-establish desired downward paths, DAOs with incremented Path = Sequences should be sent to the desired/maintained DAO Parents.
       
       
       
        There would be some benefit = to being able to send a no-Path DAO to delete a single DAO Parent path = all the way to the root but the incremented Path Sequence will make = stale all other valid routing paths (as well as introduce the = difficulties raised in your assessments). Note once again that multiple = DAO Parents guarantee only local diversity. Therefore the fact that = deleting a single DAO Parent using an un-incremented Path Sequence = removes diversity only to a common ancestor should be seen in the = context of the local guarantees that are provided.
       
       
       
        SUMMARY: If a no-Path DAO is = sent by the Prefix owner to a connected DAO Parent to delete the single = downward path while maintaining the others, the Path Sequence should be = maintained (not incremented) indicating that all established paths (and = preferences) with the exception of the identified DAO Parent path is = being maintained. The path through the particular DAO Parent, only to = the first common ancestor, will be deleted. Where the no-Path DAO is = being proactively sent by an ancestor node due to recognition of NUD, = the same would apply as the Path Sequence number will be the one = currently maintained by the ancestor node. The prefix owner should never = send a no-Path DAO with an incremented Path Sequence but should instead = send updated DAOs with incremented Path Sequence to re-establish or = re-order DAO Parents and downward paths.
       
       
       
        The operation for non-storing = nodes would be the same. However, in the case of non-storing nodes the = first common ancestor is always the root node. If in the non-storing = case a no-path DAO is issued by the owner of the Prefix or by a DAO = Parent (due to proactive response to NUD), the no-Path DAO with an = un-incremented Path Sequence will directly allow the root to update = existing downward paths (removing the identified DAO Parent while = maintaining ordering of remaining DAO Parents). As in the storing case, = a no-Path DAO with an incremented Path Sequence would mark all other = downward paths from the root as potentially outdated (and marked for = deletion) and so should similarly not be issued.
       
       
       
        This is the operation as I = believe it should work but I look forward to understanding whether this = envisaged operation can fit within the model given in -10.
       
       
       
        Make sense? See also a = specific related comment below.
       
       
       
        Regards,
       
       
       
        Roger
       
       
       
        From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org = <mailto:roll-bounces@ietf.org>= ; ] On Behalf Of Navneet Agarwal (navagar)
        Sent: Friday, July 09, 2010 = 1:26 PM
        To: ROLL WG
        Subject: [Roll] no-Path DAO = and fan-out
       
       
       
        Hi WG:
        I am trying to get some = clarifications on expected behavior. Have read the Path Control document = on path ctl field usage (attached). I have put several setups and flows, = assuming storing nodes but should apply for non-storing scenario as = well. I could not figure out from the reading the doc or the RFC.
       
       
       
        Scenario-1:
       
       
       
        A     = B
       
        = \      /
       
         \   /
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        A, B - DAO Parents.....C - = Node........D,E- nodes in subdag.
       
        Assume path control allows = two paths.
       
        D and E have learnt a common = prefix for a node below them, Pfx
       
        D will set x10 in Path = control of DAO sent to C
       
        E will set x01 in Path = control of DAO sent to C
       
        C will set x10 in Path = control of DAO sent to A
       
        C will set x01 in Path = control of DAO sent to B
       
       
       
        Suppose E sends a no-Path DAO = to C for Pfx with path control x01. What does C do? I would think that C = will need to send a no-Path. But it has to remember that it had sent a = DAO with path control x01 to B. If this has to happen then C would have = to remember for each prefix what path control was sent to which parent, = which does not seem correct as it would not scale as the prefixes at C = scale, each having its own path control settings.
       
       
       
        Scenario-2:
       
       
       
        F     = G
       
        \    /
       
         \  /
       
           A
       
            |
       
            |
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        D will set x10 in Path = control of DAO sent to C
       
        E will set x01 in Path = control of DAO sent to C
       
        C will send a DAO with path = control x11 to A
       
        A will send a DAO with path = control x01 to F
       
        A will send a DAO with path = control x10 to G
       
       
       
        Suppose E sends a no-Path to = C (path control x01). What does C do? It will likely send a DAO to A = with path control x10. What will A do when it receives a DAO with this = path control when its previous path control was x11?
       
       
       
        I see couple of other flows = where path control settings may change due to sub-nodes going away and = coming back up...for example:
       
       
       
        Scenario-3
       
       
       
        F     = G
       
        \    /
       
         \  /
       
           A
       
            |
       
            |
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        Suppose G is preferred over = F.
       
        Suppose path from E to D is = down.
       
        D sends DAO with path control = x10 to C
       
        C sends DAO with path control = x10 to A
       
        A sends DAO with path control = x10 to G
       
       
       
        After some time E comes up = and sends a DAO with path control x01 (higher path preference than D to = C) to C.
       
        C merges this and sends a DAO = with path control x11 to A. What does A do since is has indicated a path = control of x10 to G. In normal terms, if A had received a DAO with path = control x11 from C, it would have notified DAO to F with path control = x10 and DAO to G with path control x01 but due to transient conditions = it could be reversed.
       
       
        [RA] In the case of receipt = of the first updated DAO (with incremented Path Sequence) only the new = information with single path control should be forwarded since all prior = path information is effectively obsolete by the incremented Path = Sequence. When subsequent DAO updates are received with the new, = incremented Path Sequence, only then can the combined path control = information be forwarded.
       
       
       
       
       
        Will appreciate if it can be = clarified if the above flows are reasonable and what should happen...in = general I dont think path control should mandate which path control bits = are tied to which DAO parent etc...
       
       
        [RA] Hopefully the above = discussion supports the view that Path Control can operate as specified = without the need to maintain state on which DAO with which Path Control = was sent to which DAO Parent.
       
       
       
       
       
        Thanks
       
       
       
        Regards,
       
        Navneet
       
       
       
       
       
       

       

------_=_NextPart_001_01CB2305.2B1F8764-- From nicolas.dejean.ietf@googlemail.com Wed Jul 14 01:58:29 2010 Return-Path: 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 130DF3A68B6 for ; Wed, 14 Jul 2010 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=0.632, 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 UjcJK6Mttr-1 for ; Wed, 14 Jul 2010 01:58:28 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id CE9243A67BD for ; Wed, 14 Jul 2010 01:58:27 -0700 (PDT) Received: by ewy22 with SMTP id 22so1584897ewy.31 for ; Wed, 14 Jul 2010 01:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Lxr55cjAvSUQKMW0W9GeeQBh9JMlQ+I1ydBITcA8EwQ=; b=RDIW1v0suIt5Kvgf0ia4UcUULmAe6q72HY9v7eDOsLYw9yTSJafYXi46iNxVUgsMuH xjb2WSMKRv81/wUFatNh1X+4Vy3+GAIhD88LrUM1YONePrG/hfm9Drcq87VqdHZ7cE+A FOhrYPGqpO/RT80RUMYfZEvCeBkE1N+XaLapU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w91KPhwlR8uyvTF4Czbza6NR5nkebUaWbd3o4wWpuMV8mySmN/4EgHLyPQuY/itgTb Cj4phpzZ36Za+zevodCtnOLmHNf9duLWpKsnZQiCs9QzvR6NcOVtEy5PVr1yy3VTTUV6 RObwfw27Ls1bH3JRCzpAXZiaCV66uIyZIlOnQ= MIME-Version: 1.0 Received: by 10.213.19.205 with SMTP id c13mr3940792ebb.99.1279097912300; Wed, 14 Jul 2010 01:58:32 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Wed, 14 Jul 2010 01:58:32 -0700 (PDT) In-Reply-To: <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> Date: Wed, 14 Jul 2010 10:58:32 +0200 Message-ID: From: Nicolas DEJEAN To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Wed, 14 Jul 2010 08:58:29 -0000 Hello Phil, 2010/7/13 Philip Levis : > > On Jul 13, 2010, at 7:17 AM, Nicolas DEJEAN wrote: > >> Hello Phil, >> >>> A couple of thoughts/opinions: >> >>> 1) I personally don't think these optimizations matter much. >> >> Dominique had explained and documented in >> http://www.ietf.org/mail-archive/web/roll/current/msg03306.html that >> these optimizations do matter in our application domain. Please find >> at the bottom of this message the description of an even more critical >> case extracted from real life deployment. > > I'm confused: the message you reference describes the need for filtering who responds to a DIS, mechanisms which are in the draft currently. There's no mention for need of U and R bits. > You are right, this message in particular does not describe the proposed flags but presents the impact of over-hearing in a well identified case taken from real-life deployments. http://www.ietf.org/mail-archive/web/roll/current/msg03810.html presents a solution proposal for solving this critical case. This proposal uses both DIS filtering and flags for avoiding increased control traffic and thus over-hearing during deployment phases. > Phil Thanks, Nicolas. From joakime@sics.se Wed Jul 14 03:16:12 2010 Return-Path: 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 A6B933A6A10 for ; Wed, 14 Jul 2010 03:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=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 7HsQS0MP2sho for ; Wed, 14 Jul 2010 03:16:11 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 7AEE63A677C for ; Wed, 14 Jul 2010 03:16:10 -0700 (PDT) Received: from [192.168.1.144] (c-e618e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.24.230]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id E3E1A4001B; Wed, 14 Jul 2010 12:16:18 +0200 (CEST) Message-ID: <4C3D8E54.6020101@sics.se> Date: Wed, 14 Jul 2010 12:15:48 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] New link-local RPL multicast address and 6lowpan-HC 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: , X-List-Received-Date: Wed, 14 Jul 2010 10:16:13 -0000 Hello, The new RPL all routers address ff02::1:a is going to cause much worse compression (3 bytes vs 1 byte) of the destination address in 6lowpan based networks. Is there any plans for "fixing" the HC or are we ok with this? (I like small messages ;-) Would it be impossible to get a ff02::1a address from IANA instead? Best regards -- Joakim Eriksson, SICS From navagar@cisco.com Wed Jul 14 09:39:46 2010 Return-Path: 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 3A7063A681E for ; Wed, 14 Jul 2010 09:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ddu1a5y5Zt6v for ; Wed, 14 Jul 2010 09:39:26 -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 06B263A65A5 for ; Wed, 14 Jul 2010 09:39:26 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIqEPUxAaHte/2dsb2JhbACfa3GmMppRgl2CRwSDfIcI X-IronPort-AV: E=Sophos;i="4.55,202,1278288000"; d="scan'208,217";a="559136441" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 14 Jul 2010 16:39:34 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6EGd4CQ006682; Wed, 14 Jul 2010 16:39:31 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 22:09:27 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2373.201ED6CA" Date: Wed, 14 Jul 2010 22:09:26 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB0196C268@XMB-BGL-41C.cisco.com> In-Reply-To: <9BB070DB2D281946859EA89837931EEE19980D@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8gABVACUkAF9ay8AAbrhwtABsLhuA= References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> <03CBBD5D7D22764D8DDFA2295A19D68E08350A42@EVS4.nam.ci.root> <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196BFE1@XMB-BGL-41C.cisco.com> <9BB070DB2D281946859EA89837931EEE19980D@EVS4.nam.ci.root> From: "Navneet Agarwal (navagar)" To: "Alexander, Roger" , "ROLL WG" X-OriginalArrivalTime: 14 Jul 2010 16:39:27.0842 (UTC) FILETIME=[20300420:01CB2373] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Wed, 14 Jul 2010 16:39:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2373.201ED6CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roger: Pls see my comments below... =20 Thanks =20 Regards, Navneet ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Wednesday, July 14, 2010 9:00 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 =09 Hi Navneet, =09 See additional comments below. =09 Regards, =09 Roger =09 =09 =09 -----Original Message----- From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com ] Sent: Tue 7/13/2010 1:16 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps clears the path control operation. =09 I think it would be good if some additional text related to below is added to the RFC. =09 Some comments: =09 1. "Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root." =09 [RA] Agreed. More generally "any new or changed routing/path information that is received at a node must be passed to its DAO Parent(s)". In addition to incremented Path Sequence that new information may include an existing Prefix with an unchanged Path Sequence but with different Path Control bits. =09 =09 =09 I guess this should apply to all DAOs (Path as well as no-Path). [RA] Agreed. =09 =09 I do see some issues when a node has multiple DAO parents and they are received and processed at a common ancestor. =09 [RA] There may be issues related to dynamic changes in the DAO Parent set of an ancestor node but these should be transient and normalized in the course of subsequent DAO updates (with and without incremented Path Sequence) - where a common ancestor receiving the very same DAO information from multiple children maintains the most recent update. =09 Where a common ancestor receives DAOs along different paths from a node with multiple DAO Parents a consistent rule will ensure that assignments can be made without needing to maintain per-DAO state information. As an implementation choice, a node can maintain a fixed-assignment rule in which DAOs with particular path control bits set are always divided across the existing DAO Parent set in a given way. For example, if the node has 2 DAO Parents and a maximum path control size (PCS) of 4 is configured for the DODAG, any DAO with one or more of the two highest preference path control bits set are always assigned to the higher preference DAO Parent; DAOs with the lower preference path control bits sets are propagated to the other DAO Parent. Correspondingly, DAOs with more than 2 path control bits set will be split across the two DAO Parents with higher order path control bits set in the DAO send to the higher preference DAO Parent. Each node will apply a fixed-assignment rule according to its current number of DAO Parents and the DODAG PSC. Thus even as multiple DAOs arrive with different delays at a common ancestor, each is received and asynchronously assigned according to the fixed-assignment rule. Where a later arriving DAO is to be sent to a DAO Parent to which an earlier DAO has been propagated, the path control bits are aggregated representing the new combined information and the new DAO propagated forward. =20 Note: Other fixed-assignment rules may also be possible. For example, the highest preference path control DAO assigned to the highest preference DAO Parent and all other PSC-allowed path control DAOs distributed across the remaining DAO Parents. NAV> I think there may be a need for defining a mask to identify the fixed-assignment rule you described above, especially in cases where a node is more than 1-bit in the path control set. This would help the common ancestor node receiving the individual DAO messages from the nodes below to figure out the width of the path control bits in the received DAO(s) for aggregation. For example, if there are two nodes below a common ancestor and are using 2-bits per DAO parent as the assignment rule, they may send DAOs with bit settings as b'01' and b'10'. The common ancestor would somehow need to know to aggregate this as b'1001' otherwise it may just aggregate it as b'01' | b'10' =3D=3D b'11'. =09 2. On a related topic, since there is a preference associated with each path for a prefix, a node does not allow for loadbalancing if there are multiple paths reported for a prefix. Right? =09 [RA] Downward path load balancing at a common ancestor is still possible for a given prefix though that load balancing need not be uniform. =20 NAV> I see...makes sense. It can be weighted where the preferred path (single Parent, tree-equivalent path) is one of the next hop options, or it can be uniform where the preferred path is not a member of the next hop options. Load balancing can also consider diversity that may be derived from the number of paths (path control bits) associated with a given next hop route. As indicated in the original note, path control only guarantees that the preferred path can always be distinguished from others. Th preference ordering of other paths are softer and more loosely maintained as a function of the local application of preference. NAV> I did not understand this part....are you saying that load balancing can be weighted along the lines of the path preference or it can be made uniform across all paths, ignoring the path preference? Thx Regards, Navneet=20 =09 =09 Thx =09 Regards, Navneet =09 =09 ________________________________ =09 From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com ] Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 =20 =09 Hi Navneet, =20 =20 =20 Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group).=20 =20 One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root. =20 =20 Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. =20 =20 Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO. =20 =20 If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries. =20 =20 =20 Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. =20 =20 =20 To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. =20 =20 =20 Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents. =20 =20 =20 There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. =20 =20 =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and downward paths. =20 =20 =20 The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. =20 =20 =20 This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10. =20 =20 =20 Make sense? See also a specific related comment below. =20 =20 =20 Regards, =20 =20 =20 Roger =20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org > ] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =20 =20 =20 Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =20 =20 =20 Scenario-1: =20 =20 =20 A B =20 \ / =20 \ / =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. =20 Assume path control allows two paths. =20 D and E have learnt a common prefix for a node below them, Pfx =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will set x10 in Path control of DAO sent to A =20 C will set x01 in Path control of DAO sent to B =20 =20 =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =20 =20 =20 Scenario-2: =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will send a DAO with path control x11 to A =20 A will send a DAO with path control x01 to F =20 A will send a DAO with path control x10 to G =20 =20 =20 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =20 =20 =20 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =20 =20 =20 Scenario-3 =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 Suppose G is preferred over F. =20 Suppose path from E to D is down. =20 D sends DAO with path control x10 to C =20 C sends DAO with path control x10 to A =20 A sends DAO with path control x10 to G =20 =20 =20 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. =20 C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =20 =20 [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. =20 =20 =20 =20 =20 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =20 =20 [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. =20 =20 =20 =20 =20 Thanks =20 =20 =20 Regards, =20 Navneet =20 =20 =20 =20 =20 =20 =09 =20 =09 ------_=_NextPart_001_01CB2373.201ED6CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] no-Path DAO and fan-out
Hi Roger:
Pls see my comments below...
 
Thanks
 
Regards,
Navneet

From: Alexander, Roger=20 [mailto:Roger.Alexander@cooperindustries.com]
Sent: = Wednesday, July=20 14, 2010 9:00 AM
To: Navneet Agarwal (navagar); ROLL=20 WG
Subject: RE: [Roll] no-Path DAO and = fan-out

Hi Navneet,

See additional comments=20 below.

Regards,

Roger



-----Original=20 Message-----
From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]
Sent: = Tue=20 7/13/2010 1:16 PM
To: Alexander, Roger; ROLL WG
Subject: RE: = [Roll]=20 no-Path DAO and fan-out

Hi Alexander:
Thanks a lot for the = detailed=20 explanation...appreciate it...this helps clears the path control=20 operation.

I think it would be good if some additional text = related to=20 below is added to the RFC.

Some comments:

1. =20 "Correspondingly, only new or changed routing/path information that = originates=20 from the Prefix owner and hence indicated by an incremented Path = Sequence=20 number must always be passed along to the root."

[RA] Agreed. = More=20 generally “any new or changed routing/path information that is = received at a=20 node must be passed to its DAO Parent(s)”. In addition to = incremented Path=20 Sequence that new information may include an existing Prefix with an = unchanged=20 Path Sequence but with different Path Control bits.



I = guess=20 this should apply to all DAOs (Path as well as no-Path).
[RA]=20 Agreed.


I do see some issues when a node has multiple DAO = parents=20 and they are received and processed at a common ancestor.

[RA] = There=20 may be issues related to dynamic changes in the DAO Parent set of an = ancestor=20 node but these should be transient and normalized in the course of = subsequent=20 DAO updates (with and without incremented Path Sequence) - where a = common=20 ancestor receiving the very same DAO information from multiple = children=20 maintains the most recent update.

Where a common ancestor = receives DAOs=20 along different paths from a node with multiple DAO Parents a = consistent rule=20 will ensure that assignments can be made without needing to maintain = per-DAO=20 state information. As an implementation choice, a node can maintain a=20 fixed-assignment rule in which DAOs with particular path control bits = set are=20 always divided across the existing DAO Parent set in a given way. For = example,=20 if the node has 2 DAO Parents and a maximum path control size (PCS) of = 4 is=20 configured for the DODAG, any DAO with one or more of the two highest=20 preference path control bits set are always assigned to the higher = preference=20 DAO Parent; DAOs with the lower preference path control bits sets are=20 propagated to the other DAO Parent. Correspondingly, DAOs with more = than 2=20 path control bits set will be split across the two DAO Parents with = higher=20 order path control bits set in the DAO send to the higher preference = DAO=20 Parent. Each node will apply a fixed-assignment rule according to its = current=20 number of DAO Parents and the DODAG PSC. Thus even as multiple DAOs = arrive=20 with different delays at a common ancestor, each is received and=20 asynchronously assigned according to the fixed-assignment rule. Where = a later=20 arriving DAO is to be sent to a DAO Parent to which an earlier DAO has = been=20 propagated, the path control bits are aggregated representing the new = combined=20 information and the new DAO propagated = forward.
   
Note:=20 Other fixed-assignment rules may also be possible. For example, the = highest=20 preference path control DAO assigned to the highest preference DAO = Parent and=20 all other PSC-allowed path control DAOs distributed across the = remaining DAO=20 Parents.
NAV>  I think there may be a need for = defining a mask=20 to identify the fixed-assignment rule you described above, especially = in cases=20 where a node is more than 1-bit in the path control set. This would = help the=20 common ancestor node receiving the individual DAO messages from the = nodes=20 below to figure out the width of the path control bits in the=20 received DAO(s) for aggregation. For example, if there are two = nodes=20 below a common ancestor and are using 2-bits per DAO parent as the = assignment=20 rule, they may send DAOs with bit settings as b'01' and b'10'. The = common=20 ancestor would somehow need to know to aggregate this as b'1001' = otherwise it=20 may just aggregate it as b'01' | b'10' =3D=3D = b'11'.

2. On a=20 related topic, since there is a preference associated with each path = for a=20 prefix, a node does not allow for loadbalancing if there are multiple = paths=20 reported for a prefix. Right?

[RA] Downward path load balancing = at a=20 common ancestor is still possible for a given prefix though that load=20 balancing need not be uniform.  

NAV> I see...makes = sense.

 It can = be weighted=20 where the preferred path (single Parent, tree-equivalent path) is one = of the=20 next hop options, or it can be uniform where the preferred path is not = a=20 member of the next hop options. Load balancing can also consider = diversity=20 that may be derived from the number of paths (path control bits) = associated=20 with a given next hop route.  As indicated in the original note, = path=20 control only guarantees that the preferred path can always be = distinguished=20 from others. Th preference ordering of other paths are softer and more = loosely=20 maintained as a function of the local application of = preference.
 NAV>=20 I did not understand this part....are you saying that load = balancing=20 can be weighted along the lines of the path preference or it can be = made=20 uniform across all paths, ignoring the path=20 preference?

Thx

Regards,

Navneet 


Thx

Regards,Navneet


________________________________

  =      =20 From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]
        Sent: = Tuesday, July 13,=20 2010 8:25 AM
        To: Navneet = Agarwal=20 (navagar); ROLL WG
        = Subject: RE:=20 [Roll] no-Path DAO and=20 = fan-out
       
  &nbs= p;    

      &nb= sp;=20 Hi=20 = Navneet,
       
  &nb= sp;    
       =
       =20 Thanks for the scenario examples which provide a good opportunity to=20 highlight/clarify the role of the Path Sequence in the DAO exchanges. = Below is=20 an explanation of how I envisaged it would/should operate and would = also be=20 interested in the WG's feedback. (Note: I am assuming your reference = to Prefix=20 is as used in the generic RPL sense of identifying an IPv6 destination = address, prefix, or multicast=20 = group). 
       
 &nbs= p;     =20 One advantage accruing to storing nodes, in addition to DAO = aggregation, is=20 the ability to further reduce routing overhead by removing the = requirement for=20 sub-DAG changes to always be conveyed all the way to the root. In all = of the=20 scenarios you have defined, when a common ancestor receives a no-Path = DAO that=20 is not originated by the Prefix owner (and hence should not carry an=20 incremented Path Sequence), there is no requirement for that = information to be=20 conveyed beyond the common ancestor (node C in your examples). Loss of = downward path diversity below the common ancestor does not mean that = path=20 diversity above needs to be eliminated. Since the common ancestor = still has a=20 downward table entry to the Prefix via alternate path(s), its = ancestors do not=20 need to be further updated. With the maintained Path Sequence in the = no-Path=20 DAO, only nodes that have a singular downward route to the affected = Prefix=20 need to update their individual DAO Parent(s). Correspondingly, only = new or=20 changed routing/path information that originates from the Prefix owner = and=20 hence indicated by an incremented Path Sequence number must always be = passed=20 along to the=20 = root.
       
   =     
       =20 Note: The implementation option of limiting when the Path Sequence = number is=20 incremented by a Prefix owner provides a capability to further reduce = routing=20 overhead for storing nodes - though the few bits needed to fully = support=20 incremental/partial updates within the DAO would be still=20 = needed.
       
  &nbs= p;    
        = Where the transmission of the no-Path DAO is being proactively = initiated by a=20 DAO Parent or other intermediate ancestor node that discovers the loss = of=20 connectivity (neighbor unreachability detection, NUD) to the node that = owns=20 the Prefix, the Path Sequence used in the no-Path DAO will be the one=20 maintained by the ancestor node (only the owner of the Prefix can = increment=20 the Path Sequence for that Prefix). This would be the same as the Path = Sequence maintained by all nodes along the path to the common = ancestor. The=20 first common ancestor receiving such a no-Path DAO should mark the = affected=20 downward path for deletion and should take no further action with = regard to=20 upward forwarding of the=20 = DAO.
       
   &= nbsp;   
       =20 If the owner of the Prefix discovers the loss of connection to an = existing DAO=20 Parent and wishes to update its path connections, including = potentially=20 re-selecting a different preference set of DAO Parents, the node must=20 increment the Path Sequence and transmit DAOs to new desired DAO = Parents - a=20 no-Path DAO is not required. The incremented Path Sequence will = necessitate=20 that the updated DAOs be conveyed all the way to the root - in the = process=20 updating routing tables at intermediate nodes. Where new downward = paths are=20 established as a result of the updated DAOs, existing intermediate = routing=20 tables are directly updated. Routing table entries that are no longer = on the=20 re-established downward paths will be purged through the normal = expiration of=20 the associated downward route=20 = entries.
       
  &nb= sp;    
       =
       =20 Note: If the node that owns the Prefix chooses to maintain its = existing DAO=20 Parents and preferences (even with the lost connectivity to, or = desired=20 removal of, a single DAO Parent), it can do so by sending normal = periodic or=20 triggered DAO updates to the connected DAO Parents without = incrementing the=20 Path Sequence in the DAO updates. Where connectivity exists, the owner = of the=20 Prefix may also send a no-Path DAO to delete the path through a given = DAO=20 Parent. By not incrementing the Path Sequence the path through the = particular=20 DAO Parent will be removed only to the first common=20 = ancestor.
       
  &n= bsp;    
       = ;
       =20 To redefine DAO Parents and preferences (including where necessary to = maintain=20 fan-out limits), DAOs must be sent with an incremented Path Sequence = number to=20 the newly desired/re-ordered DAO Parents. The incremented Path = Sequence DAOs=20 will ensure that the routing change is conveyed to the root and = recognized by=20 ancestor nodes that can delete downward path entries. Where the = updated DAOs=20 are received at nodes that do not currently have routing entries for = the=20 particular Prefix, the information is cached and the new DAO = information=20 conveyed towards the=20 = root.
       
   =     
              =20 Based on the above defined operation there is no benefit to the node = owner of=20 the Prefix sending a no-Path DAO with an incremented Path Sequence. = This will=20 travel all the way to the root and will have the effect of outdating = and=20 marking for deletion all existing downward routes for that Prefix. = Instead, to=20 re-establish desired downward paths, DAOs with incremented Path = Sequences=20 should be sent to the desired/maintained DAO=20 = Parents.
       
  &nb= sp;    
       =
       =20 There would be some benefit to being able to send a no-Path DAO to = delete a=20 single DAO Parent path all the way to the root but the incremented = Path=20 Sequence will make stale all other valid routing paths (as well as = introduce=20 the difficulties raised in your assessments). Note once again that = multiple=20 DAO Parents guarantee only local diversity. Therefore the fact that = deleting a=20 single DAO Parent using an un-incremented Path Sequence removes = diversity only=20 to a common ancestor should be seen in the context of the local = guarantees=20 that are=20 = provided.
       
  &n= bsp;    
       = ;
       =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected = DAO=20 Parent to delete the single downward path while maintaining the = others, the=20 Path Sequence should be maintained (not incremented) indicating that = all=20 established paths (and preferences) with the exception of the = identified DAO=20 Parent path is being maintained. The path through the particular DAO = Parent,=20 only to the first common ancestor, will be deleted. Where the no-Path = DAO is=20 being proactively sent by an ancestor node due to recognition of NUD, = the same=20 would apply as the Path Sequence number will be the one currently = maintained=20 by the ancestor node. The prefix owner should never send a no-Path DAO = with an=20 incremented Path Sequence but should instead send updated DAOs with=20 incremented Path Sequence to re-establish or re-order DAO Parents and = downward=20 = paths.
       
   = ;    
              =20 The operation for non-storing nodes would be the same. However, in the = case of=20 non-storing nodes the first common ancestor is always the root node. = If in the=20 non-storing case a no-path DAO is issued by the owner of the Prefix or = by a=20 DAO Parent (due to proactive response to NUD), the no-Path DAO with an = un-incremented Path Sequence will directly allow the root to update = existing=20 downward paths (removing the identified DAO Parent while maintaining = ordering=20 of remaining DAO Parents). As in the storing case, a no-Path DAO with = an=20 incremented Path Sequence would mark all other downward paths from the = root as=20 potentially outdated (and marked for deletion) and so should similarly = not be=20 = issued.
       
  &nbs= p;    
       <= BR>       =20 This is the operation as I believe it should work but I look forward = to=20 understanding whether this envisaged operation can fit within the = model given=20 in=20 = -10.
       
   &= nbsp;   
       
=        =20 Make sense? See also a specific related comment=20 = below.
       
   = ;    
              =20 = Regards,
       
  &nb= sp;    
       =
       =20 = Roger
       
   =     
              =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org = <mailto:roll-bounces@ietf.org> ] = On Behalf Of=20 Navneet Agarwal = (navagar)
        Sent:=20 Friday, July 09, 2010 1:26 = PM
       =20 To: ROLL WG
        Subject: = [Roll]=20 no-Path DAO and=20 = fan-out
       
  &nbs= p;    
       <= BR>       =20 Hi WG:
        I am trying to = get some=20 clarifications on expected behavior. Have read the Path Control = document on=20 path ctl field usage (attached). I have put several setups and flows, = assuming=20 storing nodes but should apply for non-storing scenario as well. I = could not=20 figure out from the reading the doc or the=20 = RFC.
       
   &= nbsp;   
       
=        =20 = Scenario-1:
       
  =      
      &nb= sp;
       =20 A    =20 = B
       
   &nbs= p;   =20 \     =20 = /
       
   &nbs= p;    =20 \  =20 = /
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 A, B - DAO Parents.....C - Node........D,E- nodes in=20 = subdag.
       
  &nbs= p;    =20 Assume path control allows two=20 = paths.
       
   = ;    =20 D and E have learnt a common prefix for a node below them,=20 = Pfx
       
   &n= bsp;   =20 D will set x10 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 E will set x01 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 C will set x10 in Path control of DAO sent to=20 = A
       
   &nbs= p;   =20 C will set x01 in Path control of DAO sent to=20 = B
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What = does C=20 do? I would think that C will need to send a no-Path. But it has to = remember=20 that it had sent a DAO with path control x01 to B. If this has to = happen then=20 C would have to remember for each prefix what path control was sent to = which=20 parent, which does not seem correct as it would not scale as the = prefixes at C=20 scale, each having its own path control=20 = settings.
       
  &n= bsp;    
       = ;
       =20 = Scenario-2:
       
  =      
      &nb= sp;
       =20 F    =20 = G
       
   &nbs= p;   =20 \   =20 = /
       
   &nbs= p;    =20 \ =20 = /
       
   &nbs= p;   =20   =20 = A
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 D will set x10 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 E will set x01 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 C will send a DAO with path control x11 to=20 = A
       
   &nbs= p;   =20 A will send a DAO with path control x01 to=20 = F
       
   &nbs= p;   =20 A will send a DAO with path control x10 to=20 = G
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose E sends a no-Path to C (path control x01). What does C do? It = will=20 likely send a DAO to A with path control x10. What will A do when it = receives=20 a DAO with this path control when its previous path control was=20 = x11?
       
   &= nbsp;   
       
=        =20 I see couple of other flows where path control settings may change due = to=20 sub-nodes going away and coming back up...for=20 = example:
       
  &nb= sp;    
       =
       =20 = Scenario-3
       
  &= nbsp;    
      &nbs= p;
       =20 F    =20 = G
       
   &nbs= p;   =20 \   =20 = /
       
   &nbs= p;    =20 \ =20 = /
       
   &nbs= p;   =20   =20 = A
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose G is preferred over=20 = F.
       
   &nb= sp;   =20 Suppose path from E to D is=20 = down.
       
   =     =20 D sends DAO with path control x10 to=20 = C
       
   &nbs= p;   =20 C sends DAO with path control x10 to=20 = A
       
   &nbs= p;   =20 A sends DAO with path control x10 to=20 = G
       
   &nbs= p;   
       
&nb= sp;      =20 After some time E comes up and sends a DAO with path control x01 = (higher path=20 preference than D to C) to=20 = C.
       
   &nb= sp;   =20 C merges this and sends a DAO with path control x11 to A. What does A = do since=20 is has indicated a path control of x10 to G. In normal terms, if A had = received a DAO with path control x11 from C, it would have notified = DAO to F=20 with path control x10 and DAO to G with path control x01 but due to = transient=20 conditions it could be=20 = reversed.
       
  &n= bsp;    
       = ;=20 [RA] In the case of receipt of the first updated DAO (with incremented = Path=20 Sequence) only the new information with single path control should be=20 forwarded since all prior path information is effectively obsolete by = the=20 incremented Path Sequence. When subsequent DAO updates are received = with the=20 new, incremented Path Sequence, only then can the combined path = control=20 information be=20 = forwarded.
       
  &= nbsp;    
      &nbs= p;
       
   &nb= sp;   
       =20 Will appreciate if it can be clarified if the above flows are = reasonable and=20 what should happen...in general I dont think path control should = mandate which=20 path control bits are tied to which DAO parent=20 = etc...
       
   = ;    
       =20 [RA] Hopefully the above discussion supports the view that Path = Control can=20 operate as specified without the need to maintain state on which DAO = with=20 which Path Control was sent to which DAO=20 = Parent.
       
  &nbs= p;    
       <= BR>       
    =    
       =20 = Thanks
       
   = ;    
              =20 = Regards,
       
  &nb= sp;    =20 = Navneet
       
  &nbs= p;    
       <= BR>       
    =    
       

&= nbsp;      

------_=_NextPart_001_01CB2373.201ED6CA-- From pal@cs.stanford.edu Wed Jul 14 10:29:13 2010 Return-Path: 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 4B6BE3A6A50 for ; Wed, 14 Jul 2010 10:29:13 -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 S5r0C3vcKhsp for ; Wed, 14 Jul 2010 10:29:04 -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 EB8693A6A5C for ; Wed, 14 Jul 2010 10:29:02 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OZ5lg-0006fA-Ck; Wed, 14 Jul 2010 10:29:12 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 14 Jul 2010 10:29:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Wed, 14 Jul 2010 17:29:13 -0000 On Jul 14, 2010, at 1:58 AM, Nicolas DEJEAN wrote: > Hello Phil, >=20 > 2010/7/13 Philip Levis : >>=20 >> On Jul 13, 2010, at 7:17 AM, Nicolas DEJEAN wrote: >>=20 >>> Hello Phil, >>>=20 >>>> A couple of thoughts/opinions: >>>=20 >>>> 1) I personally don't think these optimizations matter much. >>>=20 >>> Dominique had explained and documented in >>> http://www.ietf.org/mail-archive/web/roll/current/msg03306.html that >>> these optimizations do matter in our application domain. Please find >>> at the bottom of this message the description of an even more = critical >>> case extracted from real life deployment. >>=20 >> I'm confused: the message you reference describes the need for = filtering who responds to a DIS, mechanisms which are in the draft = currently. There's no mention for need of U and R bits. >>=20 > You are right, this message in particular does not describe the > proposed flags but presents the impact of over-hearing in a well > identified case taken from real-life deployments. >=20 > http://www.ietf.org/mail-archive/web/roll/current/msg03810.html > presents a solution proposal for solving this critical case. >=20 > This proposal uses both DIS filtering and flags for avoiding increased > control traffic and thus over-hearing during deployment phases. I'm still confused: is your concern that the requirement (scoping = responses to DIS messages) isn't satisfied in the current draft, or are = you insisting that RPL include your proposal without any changes? Phil= From prvs=804123af8=Roger.Alexander@cooperindustries.com Wed Jul 14 13:03:44 2010 Return-Path: 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 EDF303A69AC for ; Wed, 14 Jul 2010 13:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 oxd2eyPwEYlO for ; Wed, 14 Jul 2010 13:03:44 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 7BE4D3A67D9 for ; Wed, 14 Jul 2010 13:03:30 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,203,1278302400"; d="scan'208";a="61001466" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 14 Jul 2010 16:03:17 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 16:03:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: UKM= Cm4H Cstn EP/x E+WP FLKb FeGp F/La GP5a G4ZN HHbC H4K9 I6JV JJ21 JQZN KECS; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8351D7F6-AC86-4917-898F-C63C22C8EE88}; cgBvAGcAZQByAC4AYQBsAGUAeABhAG4AZABlAHIAQABjAG8AbwBwAGUAcgBpAG4AZAB1AHMAdAByAGkAZQBzAC4AYwBvAG0A; Wed, 14 Jul 2010 20:02:20 GMT; RABPAEQAQQBHACAARABlAGYAYQB1AGwAdAAgAFAAYQB0AGgAIABMAGkAZgBlAHQAaQBtAGUA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {8351D7F6-AC86-4917-898F-C63C22C8EE88} Content-class: urn:content-classes:message Date: Wed, 14 Jul 2010 16:02:20 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19C5CC@EVS4.nam.ci.root> In-Reply-To: <4C3D8E54.6020101@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DODAG Default Path Lifetime Thread-Index: AcsjPZ8zu8z4onPuT2C0+oxMiCawfwAKMxyw References: <4C3D8E54.6020101@sics.se> From: "Alexander, Roger" To: "roll" X-OriginalArrivalTime: 14 Jul 2010 20:03:14.0666 (UTC) FILETIME=[97F14CA0:01CB238F] Subject: [Roll] DODAG Default Path Lifetime 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: , X-List-Received-Date: Wed, 14 Jul 2010 20:03:45 -0000 Hi WG, I would like to recommend use of a DODAG-defined Default Path Lifetime as opposed to the current model in which Path Lifetime is specified per prefix using the Transit Information Option.=20 As in other routing protocols, such as RIP for example, the validity period of an advertised prefix is defined not per destination address but is specified through a protocol configuration element such as the route-timeout timer. In the same vein, a default validity period can be defined for all advertised destinations through a Default Path Lifetime specified within the DODAG Configuration option. This default value will apply to all advertised prefixes unless otherwise specified using an optional Path Lifetime information element within the Transit Information option. The benefit of a Default Path Lifetime is that it will allow 4-bytes to be saved per advertised DAO destination unless a specific, dedicated Path Lifetime is needed for a given prefix. The Lifetime for a destination address will continue to apply from the time of receipt at a node. No additional control bits will be required within the Transit Information Option as the presence or absence of the Path Lifetime information element can be directly deduced from the value of the Option Length.=20 Thanks. Roger From prvs=804123af8=Roger.Alexander@cooperindustries.com Wed Jul 14 13:28:08 2010 Return-Path: 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 4688A3A69BC for ; Wed, 14 Jul 2010 13:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.238, 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 L9JHFu6YBBlq for ; Wed, 14 Jul 2010 13:27:44 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 7FE2D3A6823 for ; Wed, 14 Jul 2010 13:27:42 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,203,1278302400"; d="scan'208,217";a="61006127" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 14 Jul 2010 16:27:51 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 16:27:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2392.FF87D41B" Date: Wed, 14 Jul 2010 16:27:01 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19C5DE@EVS4.nam.ci.root> In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB0196C268@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8gABVACUkAF9ay8AAbrhwtABsLhuAAAZYZgA== References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> <03CBBD5D7D22764D8DDFA2295A19D68E08350A42@EVS4.nam.ci.root> <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196BFE1@XMB-BGL-41C.cisco.com> <9BB070DB2D281946859EA89837931EEE19980D@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196C268@XMB-BGL-41C.cisco.com> From: "Alexander, Roger" To: "Navneet Agarwal (navagar)" , "ROLL WG" X-OriginalArrivalTime: 14 Jul 2010 20:27:50.0772 (UTC) FILETIME=[07C53340:01CB2393] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Wed, 14 Jul 2010 20:28:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2392.FF87D41B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Navneet, =20 See below.=20 =20 Regards, =20 Roger =20 From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]=20 Sent: Wednesday, July 14, 2010 12:39 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 Hi Roger: Pls see my comments below... =20 Thanks =20 Regards, Navneet =20 ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Wednesday, July 14, 2010 9:00 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out Hi Navneet, =09 See additional comments below. =09 Regards, =09 Roger =09 =09 =09 -----Original Message----- From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com ] Sent: Tue 7/13/2010 1:16 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps clears the path control operation. =09 I think it would be good if some additional text related to below is added to the RFC. =09 Some comments: =09 1. "Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root." =09 [RA] Agreed. More generally "any new or changed routing/path information that is received at a node must be passed to its DAO Parent(s)". In addition to incremented Path Sequence that new information may include an existing Prefix with an unchanged Path Sequence but with different Path Control bits. =09 =09 =09 I guess this should apply to all DAOs (Path as well as no-Path). [RA] Agreed. =09 =09 I do see some issues when a node has multiple DAO parents and they are received and processed at a common ancestor. =09 [RA] There may be issues related to dynamic changes in the DAO Parent set of an ancestor node but these should be transient and normalized in the course of subsequent DAO updates (with and without incremented Path Sequence) - where a common ancestor receiving the very same DAO information from multiple children maintains the most recent update. =09 Where a common ancestor receives DAOs along different paths from a node with multiple DAO Parents a consistent rule will ensure that assignments can be made without needing to maintain per-DAO state information. As an implementation choice, a node can maintain a fixed-assignment rule in which DAOs with particular path control bits set are always divided across the existing DAO Parent set in a given way. For example, if the node has 2 DAO Parents and a maximum path control size (PCS) of 4 is configured for the DODAG, any DAO with one or more of the two highest preference path control bits set are always assigned to the higher preference DAO Parent; DAOs with the lower preference path control bits sets are propagated to the other DAO Parent. Correspondingly, DAOs with more than 2 path control bits set will be split across the two DAO Parents with higher order path control bits set in the DAO send to the higher preference DAO Parent. Each node will apply a fixed-assignment rule according to its current number of DAO Parents and the DODAG PSC. Thus even as multiple DAOs arrive with different delays at a common ancestor, each is received and asynchronously assigned according to the fixed-assignment rule. Where a later arriving DAO is to be sent to a DAO Parent to which an earlier DAO has been propagated, the path control bits are aggregated representing the new combined information and the new DAO propagated forward. =20 Note: Other fixed-assignment rules may also be possible. For example, the highest preference path control DAO assigned to the highest preference DAO Parent and all other PSC-allowed path control DAOs distributed across the remaining DAO Parents. NAV> I think there may be a need for defining a mask to identify the fixed-assignment rule you described above, especially in cases where a node is more than 1-bit in the path control set. This would help the common ancestor node receiving the individual DAO messages from the nodes below to figure out the width of the path control bits in the received DAO(s) for aggregation. For example, if there are two nodes below a common ancestor and are using 2-bits per DAO parent as the assignment rule, they may send DAOs with bit settings as b'01' and b'10'. The common ancestor would somehow need to know to aggregate this as b'1001' otherwise it may just aggregate it as b'01' | b'10' =3D=3D b'11'. [RA] The selection of a particular fixed-assignment rule versus even the choice of maintaining assignment state should be left to individual implementations. However, the rule for aggregation of DAO path control bits is important to the RPL operation and is already specified in the -10 version (Section 8.9) through the defined bit-wise ORing. =09 =09 2. On a related topic, since there is a preference associated with each path for a prefix, a node does not allow for loadbalancing if there are multiple paths reported for a prefix. Right? =09 [RA] Downward path load balancing at a common ancestor is still possible for a given prefix though that load balancing need not be uniform. =20 NAV> I see...makes sense. It can be weighted where the preferred path (single Parent, tree-equivalent path) is one of the next hop options, or it can be uniform where the preferred path is not a member of the next hop options. Load balancing can also consider diversity that may be derived from the number of paths (path control bits) associated with a given next hop route. As indicated in the original note, path control only guarantees that the preferred path can always be distinguished from others. Th preference ordering of other paths are softer and more loosely maintained as a function of the local application of preference. NAV> I did not understand this part....are you saying that load balancing can be weighted along the lines of the path preference or it can be made uniform across all paths, ignoring the path preference? [RA] It can be either. Here again when a node has multiple downward path next hop options for a given Prefix, the particular load balancing approach, if any, can be left to individual implementations. In some cases at a common ancestor the preferred path (as given by the highest preference path control bit) does not pass through the given node. Instead the next hop options may be for other paths. In that case there can be weighted or uniform load balancing among paths. In other cases the downward path from the common ancestor does include the preferred path as well as other lower preference path. Again in this case weighted load balancing in favor of the preferred path may be applied. Alternatively, the node can implement uniform load balancing independent of the presence of the preferred path within the next hop options. A node selects multiple DAO Parents to gain some amount of diversity (even though only guaranteed). The common ancestor knows the preferred path from other paths and can make a choice on how to exercise its local downward diversity to the target destination node.=20 =20 Thx Regards, Navneet=20 =09 =09 Thx =09 Regards, Navneet =09 =09 ________________________________ =09 From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com ] Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 =20 =09 Hi Navneet, =20 =20 =20 Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group).=20 =20 One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root. =20 =20 Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. =20 =20 Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO. =20 =20 If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries. =20 =20 =20 Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. =20 =20 =20 To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. =20 =20 =20 Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents. =20 =20 =20 There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. =20 =20 =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and downward paths. =20 =20 =20 The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. =20 =20 =20 This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10. =20 =20 =20 Make sense? See also a specific related comment below. =20 =20 =20 Regards, =20 =20 =20 Roger =20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org > ] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =20 =20 =20 Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =20 =20 =20 Scenario-1: =20 =20 =20 A B =20 \ / =20 \ / =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. =20 Assume path control allows two paths. =20 D and E have learnt a common prefix for a node below them, Pfx =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will set x10 in Path control of DAO sent to A =20 C will set x01 in Path control of DAO sent to B =20 =20 =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =20 =20 =20 Scenario-2: =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will send a DAO with path control x11 to A =20 A will send a DAO with path control x01 to F =20 A will send a DAO with path control x10 to G =20 =20 =20 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =20 =20 =20 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =20 =20 =20 Scenario-3 =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 Suppose G is preferred over F. =20 Suppose path from E to D is down. =20 D sends DAO with path control x10 to C =20 C sends DAO with path control x10 to A =20 A sends DAO with path control x10 to G =20 =20 =20 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. =20 C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =20 =20 [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. =20 =20 =20 =20 =20 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =20 =20 [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. =20 =20 =20 =20 =20 Thanks =20 =20 =20 Regards, =20 Navneet =20 =20 =20 =20 =20 =20 =09 =20 ------_=_NextPart_001_01CB2392.FF87D41B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] no-Path DAO and fan-out

Hi Navneet,

 

See below.

 

Regards,

 

Roger

 

From:= Navneet = Agarwal (navagar) [mailto:navagar@cisco.com]
Sent: Wednesday, July 14, 2010 12:39 PM
To: Alexander, Roger; ROLL WG
Subject: RE: [Roll] no-Path DAO and fan-out

 

Hi Roger:

Pls see my comments below...

 

Thanks

 

Regards,

Navneet

 

From: Alexander, Roger = [mailto:Roger.Alexander@cooperindustries.com]
Sent: Wednesday, July 14, 2010 9:00 AM
To: Navneet Agarwal (navagar); ROLL WG
Subject: RE: [Roll] no-Path DAO and fan-out

Hi Navneet,

See additional comments below.

Regards,

Roger



-----Original Message-----
From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]
Sent: Tue 7/13/2010 1:16 PM
To: Alexander, Roger; ROLL WG
Subject: RE: [Roll] no-Path DAO and fan-out

Hi Alexander:
Thanks a lot for the detailed explanation...appreciate it...this helps = clears the path control operation.

I think it would be good if some additional text related to below is = added to the RFC.

Some comments:

1.  "Correspondingly, only new or changed routing/path = information that originates from the Prefix owner and hence indicated by an = incremented Path Sequence number must always be passed along to the root."

[RA] Agreed. More generally “any new or changed routing/path = information that is received at a node must be passed to its DAO Parent(s)”. = In addition to incremented Path Sequence that new information may include = an existing Prefix with an unchanged Path Sequence but with different Path = Control bits.



I guess this should apply to all DAOs (Path as well as no-Path).
[RA] Agreed.


I do see some issues when a node has multiple DAO parents and they are = received and processed at a common ancestor.

[RA] There may be issues related to dynamic changes in the DAO Parent = set of an ancestor node but these should be transient and normalized in the course = of subsequent DAO updates (with and without incremented Path Sequence) - = where a common ancestor receiving the very same DAO information from multiple = children maintains the most recent update.

Where a common ancestor receives DAOs along different paths from a node = with multiple DAO Parents a consistent rule will ensure that assignments can = be made without needing to maintain per-DAO state information. As an = implementation choice, a node can maintain a fixed-assignment rule in which DAOs with = particular path control bits set are always divided across the existing DAO Parent = set in a given way. For example, if the node has 2 DAO Parents and a maximum = path control size (PCS) of 4 is configured for the DODAG, any DAO with one or = more of the two highest preference path control bits set are always assigned = to the higher preference DAO Parent; DAOs with the lower preference path = control bits sets are propagated to the other DAO Parent. Correspondingly, DAOs with = more than 2 path control bits set will be split across the two DAO Parents = with higher order path control bits set in the DAO send to the higher = preference DAO Parent. Each node will apply a fixed-assignment rule according to its = current number of DAO Parents and the DODAG PSC. Thus even as multiple DAOs = arrive with different delays at a common ancestor, each is received and = asynchronously assigned according to the fixed-assignment rule. Where a later arriving = DAO is to be sent to a DAO Parent to which an earlier DAO has been propagated, = the path control bits are aggregated representing the new combined information = and the new DAO propagated forward.
   
Note: Other fixed-assignment rules may also be possible. For example, = the highest preference path control DAO assigned to the highest preference = DAO Parent and all other PSC-allowed path control DAOs distributed across = the remaining DAO Parents.
NAV>  I think there may be a need for defining = a mask to identify the fixed-assignment rule you described above, especially in = cases where a node is more than 1-bit in the path control set. This would help = the common ancestor node receiving the individual DAO messages from the = nodes below to figure out the width of the path control bits in the = received DAO(s) for aggregation. For example, if there are two nodes below a common = ancestor and are using 2-bits per DAO parent as the assignment rule, they may = send DAOs with bit settings as b'01' and b'10'. The common ancestor would somehow = need to know to aggregate this as b'1001' otherwise it may just aggregate it as = b'01' | b'10' =3D=3D b'11'.

[RA] The selection of a particular fixed-assignment rule = versus even the choice of maintaining assignment state should be left to = individual implementations. However, the rule for aggregation of DAO path control bits is important = to the RPL operation and is already specified in the -10 version (Section 8.9) = through the defined bit-wise ORing.



2. On a related topic, since there is a preference associated with each = path for a prefix, a node does not allow for loadbalancing if there are = multiple paths reported for a prefix. Right?

[RA] Downward path load balancing at a common ancestor is still possible = for a given prefix though that load balancing need not be = uniform. &n= bsp;

NA= V> I see...makes sense.

 It can be weighted where the = preferred path (single Parent, tree-equivalent path) is one of the next hop = options, or it can be uniform where the preferred path is not a member of the next = hop options. Load balancing can also consider diversity that may be derived = from the number of paths (path control bits) associated with a given next hop route.  As indicated in the original note, path control only = guarantees that the preferred path can always be distinguished from others. Th = preference ordering of other paths are softer and more loosely maintained as a = function of the local application of preference.
 NAV> I did not understand this = part....are you saying that load balancing can be weighted along the lines of the path preference or it can be made uniform across all paths, ignoring the path preference?

[RA] It can be either. Here again when a node has = multiple downward path next hop options for a given Prefix, the particular load balancing approach, if any, can be left to individual implementations. In some = cases at a common ancestor the preferred path (as given by the highest preference = path control bit) does not pass through the given node. Instead the next hop = options may be for other paths. In that case there can be weighted or uniform = load balancing among paths. In other cases the downward path from the common ancestor does include the preferred path as well as other lower = preference path. Again in this case weighted load balancing in favor of the = preferred path may be applied. Alternatively, the node can implement uniform load = balancing independent of the presence of the preferred path within the next hop = options. A node selects multiple DAO Parents to gain some amount of diversity (even = though only guaranteed). The common ancestor knows the preferred path from = other paths and can make a choice on how to exercise its local downward diversity to = the target destination node.

 

Th= x

Re= gards,

Na= vneet 


Thx

Regards,
Navneet


________________________________

        From: Alexander, Roger = [mailto:Roger.Alexander@cooperindustries.com]
        Sent: Tuesday, July 13, 2010 = 8:25 AM
        To: Navneet Agarwal = (navagar); ROLL WG
        Subject: RE: [Roll] no-Path = DAO and fan-out
       
       

        Hi Navneet,
       
       
       
        Thanks for the scenario = examples which provide a good opportunity to highlight/clarify the role of the = Path Sequence in the DAO exchanges. Below is an explanation of how I = envisaged it would/should operate and would also be interested in the WG's feedback. = (Note: I am assuming your reference to Prefix is as used in the generic RPL = sense of identifying an IPv6 destination address, prefix, or multicast = group). 
       
        One advantage accruing to = storing nodes, in addition to DAO aggregation, is the ability to further reduce = routing overhead by removing the requirement for sub-DAG changes to always be = conveyed all the way to the root. In all of the scenarios you have defined, when = a common ancestor receives a no-Path DAO that is not originated by the = Prefix owner (and hence should not carry an incremented Path Sequence), there = is no requirement for that information to be conveyed beyond the common = ancestor (node C in your examples). Loss of downward path diversity below the = common ancestor does not mean that path diversity above needs to be eliminated. = Since the common ancestor still has a downward table entry to the Prefix via = alternate path(s), its ancestors do not need to be further updated. With the = maintained Path Sequence in the no-Path DAO, only nodes that have a singular = downward route to the affected Prefix need to update their individual DAO = Parent(s). Correspondingly, only new or changed routing/path information that = originates from the Prefix owner and hence indicated by an incremented Path = Sequence number must always be passed along to the root.
       
       
        Note: The implementation = option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing = nodes - though the few bits needed to fully support incremental/partial updates = within the DAO would be still needed.
       
       
        Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity = (neighbor unreachability detection, NUD) to the node that owns the Prefix, the = Path Sequence used in the no-Path DAO will be the one maintained by the = ancestor node (only the owner of the Prefix can increment the Path Sequence for = that Prefix). This would be the same as the Path Sequence maintained by all = nodes along the path to the common ancestor. The first common ancestor = receiving such a no-Path DAO should mark the affected downward path for deletion and = should take no further action with regard to upward forwarding of the DAO.
       
       
        If the owner of the Prefix = discovers the loss of connection to an existing DAO Parent and wishes to update = its path connections, including potentially re-selecting a different preference = set of DAO Parents, the node must increment the Path Sequence and transmit DAOs = to new desired DAO Parents - a no-Path DAO is not required. The incremented = Path Sequence will necessitate that the updated DAOs be conveyed all the way = to the root - in the process updating routing tables at intermediate nodes. = Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries = that are no longer on the re-established downward paths will be purged = through the normal expiration of the associated downward route entries.
       
       
       
        Note: If the node that owns = the Prefix chooses to maintain its existing DAO Parents and preferences = (even with the lost connectivity to, or desired removal of, a single DAO Parent), = it can do so by sending normal periodic or triggered DAO updates to the = connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO = to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only = to the first common ancestor.
       
       
       
        To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs = must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will = ensure that the routing change is conveyed to the root and recognized by = ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the = particular Prefix, the information is cached and the new DAO information conveyed = towards the root.
       
       
       
        Based on the above defined = operation there is no benefit to the node owner of the Prefix sending a no-Path = DAO with an incremented Path Sequence. This will travel all the way to the root = and will have the effect of outdating and marking for deletion all existing = downward routes for that Prefix. Instead, to re-establish desired downward paths, = DAOs with incremented Path Sequences should be sent to the desired/maintained = DAO Parents.
       
       
       
        There would be some benefit = to being able to send a no-Path DAO to delete a single DAO Parent path all the = way to the root but the incremented Path Sequence will make stale all other = valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only = local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor = should be seen in the context of the local guarantees that are provided.
       
       
       
        SUMMARY: If a no-Path DAO is = sent by the Prefix owner to a connected DAO Parent to delete the single downward = path while maintaining the others, the Path Sequence should be maintained = (not incremented) indicating that all established paths (and preferences) = with the exception of the identified DAO Parent path is being maintained. The = path through the particular DAO Parent, only to the first common ancestor, = will be deleted. Where the no-Path DAO is being proactively sent by an ancestor = node due to recognition of NUD, the same would apply as the Path Sequence = number will be the one currently maintained by the ancestor node. The prefix = owner should never send a no-Path DAO with an incremented Path Sequence but = should instead send updated DAOs with incremented Path Sequence to re-establish = or re-order DAO Parents and downward paths.
       
       
       
        The operation for non-storing = nodes would be the same. However, in the case of non-storing nodes the first = common ancestor is always the root node. If in the non-storing case a no-path = DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive = response to NUD), the no-Path DAO with an un-incremented Path Sequence will = directly allow the root to update existing downward paths (removing the = identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the = storing case, a no-Path DAO with an incremented Path Sequence would mark all = other downward paths from the root as potentially outdated (and marked for = deletion) and so should similarly not be issued.
       
       
       
        This is the operation as I = believe it should work but I look forward to understanding whether this = envisaged operation can fit within the model given in -10.
       
       
       
        Make sense? See also a = specific related comment below.
       
       
       
        Regards,
       
       
       
        Roger
       
       
       
        From: roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org <mailto:roll-bounces@ietf.org> ] On Behalf Of Navneet Agarwal = (navagar)
        Sent: Friday, July 09, 2010 = 1:26 PM
        To: ROLL WG
        Subject: [Roll] no-Path DAO = and fan-out
       
       
       
        Hi WG:
        I am trying to get some clarifications on expected behavior. Have read the Path Control document = on path ctl field usage (attached). I have put several setups and flows, = assuming storing nodes but should apply for non-storing scenario as well. I could = not figure out from the reading the doc or the RFC.
       
       
       
        Scenario-1:
       
       
       
        A     = B
       
        = \      /
       
         \   /
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        A, B - DAO Parents.....C - Node........D,E- nodes in subdag.
       
        Assume path control allows = two paths.
       
        D and E have learnt a common = prefix for a node below them, Pfx
       
        D will set x10 in Path = control of DAO sent to C
       
        E will set x01 in Path = control of DAO sent to C
       
        C will set x10 in Path = control of DAO sent to A
       
        C will set x01 in Path = control of DAO sent to B
       
       
       
        Suppose E sends a no-Path DAO = to C for Pfx with path control x01. What does C do? I would think that C will = need to send a no-Path. But it has to remember that it had sent a DAO with = path control x01 to B. If this has to happen then C would have to remember = for each prefix what path control was sent to which parent, which does not seem = correct as it would not scale as the prefixes at C scale, each having its own = path control settings.
       
       
       
        Scenario-2:
       
       
       
        F     = G
       
        \    /
       
         \  /
       
           A
       
            |
       
            |
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        D will set x10 in Path = control of DAO sent to C
       
        E will set x01 in Path = control of DAO sent to C
       
        C will send a DAO with path = control x11 to A
       
        A will send a DAO with path = control x01 to F
       
        A will send a DAO with path = control x10 to G
       
       
       
        Suppose E sends a no-Path to = C (path control x01). What does C do? It will likely send a DAO to A with path = control x10. What will A do when it receives a DAO with this path control when = its previous path control was x11?
       
       
       
        I see couple of other flows = where path control settings may change due to sub-nodes going away and coming = back up...for example:
       
       
       
        Scenario-3
       
       
       
        F     = G
       
        \    /
       
         \  /
       
           A
       
            |
       
            |
       
           C
       
          /  \
       
         /    = \
       
        D     = E
       
       
       
        Suppose G is preferred over = F.
       
        Suppose path from E to D is = down.
       
        D sends DAO with path control = x10 to C
       
        C sends DAO with path control = x10 to A
       
        A sends DAO with path control = x10 to G
       
       
       
        After some time E comes up = and sends a DAO with path control x01 (higher path preference than D to C) to = C.
       
        C merges this and sends a DAO = with path control x11 to A. What does A do since is has indicated a path = control of x10 to G. In normal terms, if A had received a DAO with path control x11 = from C, it would have notified DAO to F with path control x10 and DAO to G = with path control x01 but due to transient conditions it could be reversed.
       
       
        [RA] In the case of receipt = of the first updated DAO (with incremented Path Sequence) only the new = information with single path control should be forwarded since all prior path = information is effectively obsolete by the incremented Path Sequence. When = subsequent DAO updates are received with the new, incremented Path Sequence, only then = can the combined path control information be forwarded.
       
       
       
       
       
        Will appreciate if it can be = clarified if the above flows are reasonable and what should happen...in general I = dont think path control should mandate which path control bits are tied to = which DAO parent etc...
       
       
        [RA] Hopefully the above = discussion supports the view that Path Control can operate as specified without the = need to maintain state on which DAO with which Path Control was sent to which = DAO Parent.
       
       
       
       
       
        Thanks
       
       
       
        Regards,
       
        Navneet
       
       
       
       
       
       

       

------_=_NextPart_001_01CB2392.FF87D41B-- From navagar@cisco.com Wed Jul 14 20:41:40 2010 Return-Path: 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 032C93A68C8 for ; Wed, 14 Jul 2010 20:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=-3.675, 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 hrxpEtLGx3LE for ; Wed, 14 Jul 2010 20:41:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 91A123A68BE for ; Wed, 14 Jul 2010 20:41:13 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAGcgPkxAaHtegWdsb2JhbACBRJ4yFQEBFiIipWiaa4JdgkcEg3yHCA X-IronPort-AV: E=Sophos;i="4.55,205,1278288000"; d="scan'208,217";a="9070699" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 15 Jul 2010 02:58:31 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6F3fAZR012041; Thu, 15 Jul 2010 03:41:17 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 09:11:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB23CF.9392448A" Date: Thu, 15 Jul 2010 09:11:13 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB0196C32B@XMB-BGL-41C.cisco.com> In-Reply-To: <9BB070DB2D281946859EA89837931EEE19C5DE@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] no-Path DAO and fan-out Thread-Index: Acsfi70p6QoAwUHxS1eCnhzlyogSeQCVgU8gABVACUkAF9ay8AAbrhwtABsLhuAAAZYZgAAV25Qg References: <3EF472F4AD7D824EA24D3197C56B61DB0189F071@XMB-BGL-41C.cisco.com> <03CBBD5D7D22764D8DDFA2295A19D68E08350A42@EVS4.nam.ci.root> <9BB070DB2D281946859EA89837931EEE19980A@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196BFE1@XMB-BGL-41C.cisco.com> <9BB070DB2D281946859EA89837931EEE19980D@EVS4.nam.ci.root> <3EF472F4AD7D824EA24D3197C56B61DB0196C268@XMB-BGL-41C.cisco.com> <9BB070DB2D281946859EA89837931EEE19C5DE@EVS4.nam.ci.root> From: "Navneet Agarwal (navagar)" To: "Alexander, Roger" , "ROLL WG" X-OriginalArrivalTime: 15 Jul 2010 03:41:15.0447 (UTC) FILETIME=[93C3B470:01CB23CF] Subject: Re: [Roll] no-Path DAO and fan-out 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: , X-List-Received-Date: Thu, 15 Jul 2010 03:41:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB23CF.9392448A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roger: Thanks for the comments...it helped clear the issue. =20 So, every node operates on the full (PCS + 1) bit width and chooses to set/reset the bits based on the fixed assignment rule (local implementation) when sending DAOs. On reception, aggregation/processing is done on the full (PCS + 1) set. Section 8.9 helped clarify it. =20 Regards, Navneet ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Thursday, July 15, 2010 1:57 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 =09 Hi Navneet, =20 See below.=20 =20 Regards, =20 Roger =20 From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]=20 Sent: Wednesday, July 14, 2010 12:39 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 Hi Roger: Pls see my comments below... =20 Thanks =20 Regards, Navneet =20 ________________________________ From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]=20 Sent: Wednesday, July 14, 2010 9:00 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out Hi Navneet, =09 See additional comments below. =09 Regards, =09 Roger =09 =09 =09 -----Original Message----- From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com ] Sent: Tue 7/13/2010 1:16 PM To: Alexander, Roger; ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =09 Hi Alexander: Thanks a lot for the detailed explanation...appreciate it...this helps clears the path control operation. =09 I think it would be good if some additional text related to below is added to the RFC. =09 Some comments: =09 1. "Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root." =09 [RA] Agreed. More generally "any new or changed routing/path information that is received at a node must be passed to its DAO Parent(s)". In addition to incremented Path Sequence that new information may include an existing Prefix with an unchanged Path Sequence but with different Path Control bits. =09 =09 =09 I guess this should apply to all DAOs (Path as well as no-Path). [RA] Agreed. =09 =09 I do see some issues when a node has multiple DAO parents and they are received and processed at a common ancestor. =09 [RA] There may be issues related to dynamic changes in the DAO Parent set of an ancestor node but these should be transient and normalized in the course of subsequent DAO updates (with and without incremented Path Sequence) - where a common ancestor receiving the very same DAO information from multiple children maintains the most recent update. =09 Where a common ancestor receives DAOs along different paths from a node with multiple DAO Parents a consistent rule will ensure that assignments can be made without needing to maintain per-DAO state information. As an implementation choice, a node can maintain a fixed-assignment rule in which DAOs with particular path control bits set are always divided across the existing DAO Parent set in a given way. For example, if the node has 2 DAO Parents and a maximum path control size (PCS) of 4 is configured for the DODAG, any DAO with one or more of the two highest preference path control bits set are always assigned to the higher preference DAO Parent; DAOs with the lower preference path control bits sets are propagated to the other DAO Parent. Correspondingly, DAOs with more than 2 path control bits set will be split across the two DAO Parents with higher order path control bits set in the DAO send to the higher preference DAO Parent. Each node will apply a fixed-assignment rule according to its current number of DAO Parents and the DODAG PSC. Thus even as multiple DAOs arrive with different delays at a common ancestor, each is received and asynchronously assigned according to the fixed-assignment rule. Where a later arriving DAO is to be sent to a DAO Parent to which an earlier DAO has been propagated, the path control bits are aggregated representing the new combined information and the new DAO propagated forward. =20 Note: Other fixed-assignment rules may also be possible. For example, the highest preference path control DAO assigned to the highest preference DAO Parent and all other PSC-allowed path control DAOs distributed across the remaining DAO Parents. NAV> I think there may be a need for defining a mask to identify the fixed-assignment rule you described above, especially in cases where a node is more than 1-bit in the path control set. This would help the common ancestor node receiving the individual DAO messages from the nodes below to figure out the width of the path control bits in the received DAO(s) for aggregation. For example, if there are two nodes below a common ancestor and are using 2-bits per DAO parent as the assignment rule, they may send DAOs with bit settings as b'01' and b'10'. The common ancestor would somehow need to know to aggregate this as b'1001' otherwise it may just aggregate it as b'01' | b'10' =3D=3D b'11'. [RA] The selection of a particular fixed-assignment rule versus even the choice of maintaining assignment state should be left to individual implementations. However, the rule for aggregation of DAO path control bits is important to the RPL operation and is already specified in the -10 version (Section 8.9) through the defined bit-wise ORing. =09 =09 2. On a related topic, since there is a preference associated with each path for a prefix, a node does not allow for loadbalancing if there are multiple paths reported for a prefix. Right? =09 [RA] Downward path load balancing at a common ancestor is still possible for a given prefix though that load balancing need not be uniform. =20 NAV> I see...makes sense. It can be weighted where the preferred path (single Parent, tree-equivalent path) is one of the next hop options, or it can be uniform where the preferred path is not a member of the next hop options. Load balancing can also consider diversity that may be derived from the number of paths (path control bits) associated with a given next hop route. As indicated in the original note, path control only guarantees that the preferred path can always be distinguished from others. Th preference ordering of other paths are softer and more loosely maintained as a function of the local application of preference. NAV> I did not understand this part....are you saying that load balancing can be weighted along the lines of the path preference or it can be made uniform across all paths, ignoring the path preference? [RA] It can be either. Here again when a node has multiple downward path next hop options for a given Prefix, the particular load balancing approach, if any, can be left to individual implementations. In some cases at a common ancestor the preferred path (as given by the highest preference path control bit) does not pass through the given node. Instead the next hop options may be for other paths. In that case there can be weighted or uniform load balancing among paths. In other cases the downward path from the common ancestor does include the preferred path as well as other lower preference path. Again in this case weighted load balancing in favor of the preferred path may be applied. Alternatively, the node can implement uniform load balancing independent of the presence of the preferred path within the next hop options. A node selects multiple DAO Parents to gain some amount of diversity (even though only guaranteed). The common ancestor knows the preferred path from other paths and can make a choice on how to exercise its local downward diversity to the target destination node. =20 Thx Regards, Navneet=20 =09 =09 Thx =09 Regards, Navneet =09 =09 ________________________________ =09 From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com ] Sent: Tuesday, July 13, 2010 8:25 AM To: Navneet Agarwal (navagar); ROLL WG Subject: RE: [Roll] no-Path DAO and fan-out =20 =20 =09 Hi Navneet, =20 =20 =20 Thanks for the scenario examples which provide a good opportunity to highlight/clarify the role of the Path Sequence in the DAO exchanges. Below is an explanation of how I envisaged it would/should operate and would also be interested in the WG's feedback. (Note: I am assuming your reference to Prefix is as used in the generic RPL sense of identifying an IPv6 destination address, prefix, or multicast group).=20 =20 One advantage accruing to storing nodes, in addition to DAO aggregation, is the ability to further reduce routing overhead by removing the requirement for sub-DAG changes to always be conveyed all the way to the root. In all of the scenarios you have defined, when a common ancestor receives a no-Path DAO that is not originated by the Prefix owner (and hence should not carry an incremented Path Sequence), there is no requirement for that information to be conveyed beyond the common ancestor (node C in your examples). Loss of downward path diversity below the common ancestor does not mean that path diversity above needs to be eliminated. Since the common ancestor still has a downward table entry to the Prefix via alternate path(s), its ancestors do not need to be further updated. With the maintained Path Sequence in the no-Path DAO, only nodes that have a singular downward route to the affected Prefix need to update their individual DAO Parent(s). Correspondingly, only new or changed routing/path information that originates from the Prefix owner and hence indicated by an incremented Path Sequence number must always be passed along to the root. =20 =20 Note: The implementation option of limiting when the Path Sequence number is incremented by a Prefix owner provides a capability to further reduce routing overhead for storing nodes - though the few bits needed to fully support incremental/partial updates within the DAO would be still needed. =20 =20 Where the transmission of the no-Path DAO is being proactively initiated by a DAO Parent or other intermediate ancestor node that discovers the loss of connectivity (neighbor unreachability detection, NUD) to the node that owns the Prefix, the Path Sequence used in the no-Path DAO will be the one maintained by the ancestor node (only the owner of the Prefix can increment the Path Sequence for that Prefix). This would be the same as the Path Sequence maintained by all nodes along the path to the common ancestor. The first common ancestor receiving such a no-Path DAO should mark the affected downward path for deletion and should take no further action with regard to upward forwarding of the DAO. =20 =20 If the owner of the Prefix discovers the loss of connection to an existing DAO Parent and wishes to update its path connections, including potentially re-selecting a different preference set of DAO Parents, the node must increment the Path Sequence and transmit DAOs to new desired DAO Parents - a no-Path DAO is not required. The incremented Path Sequence will necessitate that the updated DAOs be conveyed all the way to the root - in the process updating routing tables at intermediate nodes. Where new downward paths are established as a result of the updated DAOs, existing intermediate routing tables are directly updated. Routing table entries that are no longer on the re-established downward paths will be purged through the normal expiration of the associated downward route entries. =20 =20 =20 Note: If the node that owns the Prefix chooses to maintain its existing DAO Parents and preferences (even with the lost connectivity to, or desired removal of, a single DAO Parent), it can do so by sending normal periodic or triggered DAO updates to the connected DAO Parents without incrementing the Path Sequence in the DAO updates. Where connectivity exists, the owner of the Prefix may also send a no-Path DAO to delete the path through a given DAO Parent. By not incrementing the Path Sequence the path through the particular DAO Parent will be removed only to the first common ancestor. =20 =20 =20 To redefine DAO Parents and preferences (including where necessary to maintain fan-out limits), DAOs must be sent with an incremented Path Sequence number to the newly desired/re-ordered DAO Parents. The incremented Path Sequence DAOs will ensure that the routing change is conveyed to the root and recognized by ancestor nodes that can delete downward path entries. Where the updated DAOs are received at nodes that do not currently have routing entries for the particular Prefix, the information is cached and the new DAO information conveyed towards the root. =20 =20 =20 Based on the above defined operation there is no benefit to the node owner of the Prefix sending a no-Path DAO with an incremented Path Sequence. This will travel all the way to the root and will have the effect of outdating and marking for deletion all existing downward routes for that Prefix. Instead, to re-establish desired downward paths, DAOs with incremented Path Sequences should be sent to the desired/maintained DAO Parents. =20 =20 =20 There would be some benefit to being able to send a no-Path DAO to delete a single DAO Parent path all the way to the root but the incremented Path Sequence will make stale all other valid routing paths (as well as introduce the difficulties raised in your assessments). Note once again that multiple DAO Parents guarantee only local diversity. Therefore the fact that deleting a single DAO Parent using an un-incremented Path Sequence removes diversity only to a common ancestor should be seen in the context of the local guarantees that are provided. =20 =20 =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected DAO Parent to delete the single downward path while maintaining the others, the Path Sequence should be maintained (not incremented) indicating that all established paths (and preferences) with the exception of the identified DAO Parent path is being maintained. The path through the particular DAO Parent, only to the first common ancestor, will be deleted. Where the no-Path DAO is being proactively sent by an ancestor node due to recognition of NUD, the same would apply as the Path Sequence number will be the one currently maintained by the ancestor node. The prefix owner should never send a no-Path DAO with an incremented Path Sequence but should instead send updated DAOs with incremented Path Sequence to re-establish or re-order DAO Parents and downward paths. =20 =20 =20 The operation for non-storing nodes would be the same. However, in the case of non-storing nodes the first common ancestor is always the root node. If in the non-storing case a no-path DAO is issued by the owner of the Prefix or by a DAO Parent (due to proactive response to NUD), the no-Path DAO with an un-incremented Path Sequence will directly allow the root to update existing downward paths (removing the identified DAO Parent while maintaining ordering of remaining DAO Parents). As in the storing case, a no-Path DAO with an incremented Path Sequence would mark all other downward paths from the root as potentially outdated (and marked for deletion) and so should similarly not be issued. =20 =20 =20 This is the operation as I believe it should work but I look forward to understanding whether this envisaged operation can fit within the model given in -10. =20 =20 =20 Make sense? See also a specific related comment below. =20 =20 =20 Regards, =20 =20 =20 Roger =20 =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org > ] On Behalf Of Navneet Agarwal (navagar) Sent: Friday, July 09, 2010 1:26 PM To: ROLL WG Subject: [Roll] no-Path DAO and fan-out =20 =20 =20 Hi WG: I am trying to get some clarifications on expected behavior. Have read the Path Control document on path ctl field usage (attached). I have put several setups and flows, assuming storing nodes but should apply for non-storing scenario as well. I could not figure out from the reading the doc or the RFC. =20 =20 =20 Scenario-1: =20 =20 =20 A B =20 \ / =20 \ / =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 A, B - DAO Parents.....C - Node........D,E- nodes in subdag. =20 Assume path control allows two paths. =20 D and E have learnt a common prefix for a node below them, Pfx =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will set x10 in Path control of DAO sent to A =20 C will set x01 in Path control of DAO sent to B =20 =20 =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. What does C do? I would think that C will need to send a no-Path. But it has to remember that it had sent a DAO with path control x01 to B. If this has to happen then C would have to remember for each prefix what path control was sent to which parent, which does not seem correct as it would not scale as the prefixes at C scale, each having its own path control settings. =20 =20 =20 Scenario-2: =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 D will set x10 in Path control of DAO sent to C =20 E will set x01 in Path control of DAO sent to C =20 C will send a DAO with path control x11 to A =20 A will send a DAO with path control x01 to F =20 A will send a DAO with path control x10 to G =20 =20 =20 Suppose E sends a no-Path to C (path control x01). What does C do? It will likely send a DAO to A with path control x10. What will A do when it receives a DAO with this path control when its previous path control was x11? =20 =20 =20 I see couple of other flows where path control settings may change due to sub-nodes going away and coming back up...for example: =20 =20 =20 Scenario-3 =20 =20 =20 F G =20 \ / =20 \ / =20 A =20 | =20 | =20 C =20 / \ =20 / \ =20 D E =20 =20 =20 Suppose G is preferred over F. =20 Suppose path from E to D is down. =20 D sends DAO with path control x10 to C =20 C sends DAO with path control x10 to A =20 A sends DAO with path control x10 to G =20 =20 =20 After some time E comes up and sends a DAO with path control x01 (higher path preference than D to C) to C. =20 C merges this and sends a DAO with path control x11 to A. What does A do since is has indicated a path control of x10 to G. In normal terms, if A had received a DAO with path control x11 from C, it would have notified DAO to F with path control x10 and DAO to G with path control x01 but due to transient conditions it could be reversed. =20 =20 [RA] In the case of receipt of the first updated DAO (with incremented Path Sequence) only the new information with single path control should be forwarded since all prior path information is effectively obsolete by the incremented Path Sequence. When subsequent DAO updates are received with the new, incremented Path Sequence, only then can the combined path control information be forwarded. =20 =20 =20 =20 =20 Will appreciate if it can be clarified if the above flows are reasonable and what should happen...in general I dont think path control should mandate which path control bits are tied to which DAO parent etc... =20 =20 [RA] Hopefully the above discussion supports the view that Path Control can operate as specified without the need to maintain state on which DAO with which Path Control was sent to which DAO Parent. =20 =20 =20 =20 =20 Thanks =20 =20 =20 Regards, =20 Navneet =20 =20 =20 =20 =20 =20 =09 =20 ------_=_NextPart_001_01CB23CF.9392448A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Roll] no-Path DAO and fan-out
Hi Roger:
Thanks for the comments...it helped = clear the=20 issue.
 
So, every node operates on the full (PCS + 1) bit = width and=20 chooses to set/reset the bits based on the fixed assignment rule (local=20 implementation) when sending DAOs. On reception, aggregation/processing = is done=20 on the full (PCS + 1) set. Section 8.9 helped clarify = it.
 
Regards,
Navneet

From: Alexander, Roger=20 [mailto:Roger.Alexander@cooperindustries.com]
Sent: = Thursday, July=20 15, 2010 1:57 AM
To: Navneet Agarwal (navagar); ROLL=20 WG
Subject: RE: [Roll] no-Path DAO and = fan-out

Hi=20 Navneet,

 

See=20 below.

 

Regards,

 

Roger

 

From: Navneet = Agarwal=20 (navagar) [mailto:navagar@cisco.com]
Sent: Wednesday, July = 14, 2010=20 12:39 PM
To: Alexander, Roger; ROLL WG
Subject: = RE: [Roll]=20 no-Path DAO and fan-out

 

Hi=20 Roger:

Pls=20 see my comments below...

 

Thanks

 

Regards,

Navneet

 

From: = Alexander,=20 Roger [mailto:Roger.Alexander@cooperindustries.com]
Sent: = Wednesday, July 14, 2010 9:00 AM
To: Navneet Agarwal = (navagar);=20 ROLL WG
Subject: RE: [Roll] no-Path DAO and=20 fan-out

Hi Navneet,

See additional = comments=20 below.

Regards,

Roger



-----Original=20 Message-----
From: Navneet Agarwal (navagar) [mailto:navagar@cisco.com]
Sent: Tue 7/13/2010 1:16 PM
To: = Alexander,=20 Roger; ROLL WG
Subject: RE: [Roll] no-Path DAO and = fan-out

Hi=20 Alexander:
Thanks a lot for the detailed explanation...appreciate = it...this helps clears the path control operation.

I think it = would=20 be good if some additional text related to below is added to the=20 RFC.

Some comments:

1.  "Correspondingly, only = new or=20 changed routing/path information that originates from the Prefix = owner and=20 hence indicated by an incremented Path Sequence number must always = be passed=20 along to the root."

[RA] Agreed. More generally “any = new or changed=20 routing/path information that is received at a node must be passed = to its=20 DAO Parent(s)”. In addition to incremented Path Sequence that = new=20 information may include an existing Prefix with an unchanged Path = Sequence=20 but with different Path Control bits.



I guess this = should=20 apply to all DAOs (Path as well as no-Path).
[RA] = Agreed.


I do=20 see some issues when a node has multiple DAO parents and they are = received=20 and processed at a common ancestor.

[RA] There may be issues = related=20 to dynamic changes in the DAO Parent set of an ancestor node but = these=20 should be transient and normalized in the course of subsequent DAO = updates=20 (with and without incremented Path Sequence) - where a common = ancestor=20 receiving the very same DAO information from multiple children = maintains the=20 most recent update.

Where a common ancestor receives DAOs = along=20 different paths from a node with multiple DAO Parents a consistent = rule will=20 ensure that assignments can be made without needing to maintain = per-DAO=20 state information. As an implementation choice, a node can maintain = a=20 fixed-assignment rule in which DAOs with particular path control = bits set=20 are always divided across the existing DAO Parent set in a given = way. For=20 example, if the node has 2 DAO Parents and a maximum path control = size (PCS)=20 of 4 is configured for the DODAG, any DAO with one or more of the = two=20 highest preference path control bits set are always assigned to the = higher=20 preference DAO Parent; DAOs with the lower preference path control = bits sets=20 are propagated to the other DAO Parent. Correspondingly, DAOs with = more than=20 2 path control bits set will be split across the two DAO Parents = with higher=20 order path control bits set in the DAO send to the higher preference = DAO=20 Parent. Each node will apply a fixed-assignment rule according to = its=20 current number of DAO Parents and the DODAG PSC. Thus even as = multiple DAOs=20 arrive with different delays at a common ancestor, each is received = and=20 asynchronously assigned according to the fixed-assignment rule. = Where a=20 later arriving DAO is to be sent to a DAO Parent to which an earlier = DAO has=20 been propagated, the path control bits are aggregated representing = the new=20 combined information and the new DAO propagated=20 forward.
   
Note: Other fixed-assignment rules = may=20 also be possible. For example, the highest preference path control = DAO=20 assigned to the highest preference DAO Parent and all other = PSC-allowed path=20 control DAOs distributed across the remaining DAO = Parents.
NAV>  I=20 think there may be a need for defining a mask to identify the=20 fixed-assignment rule you described above, especially in cases where = a node=20 is more than 1-bit in the path control set. This would help the = common=20 ancestor node receiving the individual DAO messages from the nodes = below to=20 figure out the width of the path control bits in the = received DAO(s)=20 for aggregation. For example, if there are two nodes below a common = ancestor=20 and are using 2-bits per DAO parent as the assignment rule, they may = send=20 DAOs with bit settings as b'01' and b'10'. The common ancestor would = somehow=20 need to know to aggregate this as b'1001' otherwise it may just = aggregate it=20 as b'01' | b'10' =3D=3D b'11'.

[RA]=20 The selection of a particular fixed-assignment rule versus even the = choice=20 of maintaining assignment state should be left to individual=20 implementations. However, the rule for aggregation of DAO path = control bits=20 is important to the RPL operation and is already specified in the = -10=20 version (Section 8.9) through the defined bit-wise=20 ORing.



2. On a related topic, = since there=20 is a preference associated with each path for a prefix, a node does = not=20 allow for loadbalancing if there are multiple paths reported for a = prefix.=20 Right?

[RA] Downward path load balancing at a common ancestor = is=20 still possible for a given prefix though that load balancing need = not be=20 uniform.  

NAV>=20 I see...makes sense.

 It can be weighted where = the=20 preferred path (single Parent, tree-equivalent path) is one of the = next hop=20 options, or it can be uniform where the preferred path is not a = member of=20 the next hop options. Load balancing can also consider diversity = that may be=20 derived from the number of paths (path control bits) associated with = a given=20 next hop route.  As indicated in the original note, path = control only=20 guarantees that the preferred path can always be distinguished from = others.=20 Th preference ordering of other paths are softer and more loosely = maintained=20 as a function of the local application of = preference.
 NAV>=20 I did not understand this part....are you saying that load = balancing can be weighted along the lines of the path preference or = it can=20 be made uniform across all paths, ignoring the path = preference?

[RA]=20 It can be either. Here again when a node has multiple downward path = next hop=20 options for a given Prefix, the particular load balancing approach, = if any,=20 can be left to individual implementations. In some cases at a common = ancestor the preferred path (as given by the highest preference path = control=20 bit) does not pass through the given node. Instead the next hop = options may=20 be for other paths. In that case there can be weighted or uniform = load=20 balancing among paths. In other cases the downward path from the = common=20 ancestor does include the preferred path as well as other lower = preference=20 path. Again in this case weighted load balancing in favor of the = preferred=20 path may be applied. Alternatively, the node can implement uniform = load=20 balancing independent of the presence of the preferred path within = the next=20 hop options. A node selects multiple DAO Parents to gain some amount = of=20 diversity (even though only guaranteed). The common ancestor knows = the=20 preferred path from other paths and can make a choice on how to = exercise its=20 local downward diversity to the target destination node.=20

 

Thx

Regards,

Navneet 


Thx

Regards,
Navneet


_______= _________________________

      &nbs= p;=20 From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com]
       =20 Sent: Tuesday, July 13, 2010 8:25=20 AM
        To: Navneet Agarwal = (navagar); ROLL WG
        = Subject:=20 RE: [Roll] no-Path DAO and=20 = fan-out
       
  &nbs= p;    

      &nb= sp;=20 Hi=20 = Navneet,
       
  &nb= sp;    
       =
       =20 Thanks for the scenario examples which provide a good opportunity to = highlight/clarify the role of the Path Sequence in the DAO = exchanges. Below=20 is an explanation of how I envisaged it would/should operate and = would also=20 be interested in the WG's feedback. (Note: I am assuming your = reference to=20 Prefix is as used in the generic RPL sense of identifying an IPv6=20 destination address, prefix, or multicast=20 = group). 
       
 &nbs= p;     =20 One advantage accruing to storing nodes, in addition to DAO = aggregation, is=20 the ability to further reduce routing overhead by removing the = requirement=20 for sub-DAG changes to always be conveyed all the way to the root. = In all of=20 the scenarios you have defined, when a common ancestor receives a = no-Path=20 DAO that is not originated by the Prefix owner (and hence should not = carry=20 an incremented Path Sequence), there is no requirement for that = information=20 to be conveyed beyond the common ancestor (node C in your examples). = Loss of=20 downward path diversity below the common ancestor does not mean that = path=20 diversity above needs to be eliminated. Since the common ancestor = still has=20 a downward table entry to the Prefix via alternate path(s), its = ancestors do=20 not need to be further updated. With the maintained Path Sequence in = the=20 no-Path DAO, only nodes that have a singular downward route to the = affected=20 Prefix need to update their individual DAO Parent(s). = Correspondingly, only=20 new or changed routing/path information that originates from the = Prefix=20 owner and hence indicated by an incremented Path Sequence number = must always=20 be passed along to the=20 = root.
       
   =     
       =20 Note: The implementation option of limiting when the Path Sequence = number is=20 incremented by a Prefix owner provides a capability to further = reduce=20 routing overhead for storing nodes - though the few bits needed to = fully=20 support incremental/partial updates within the DAO would be still=20 = needed.
       
  &nbs= p;    
        = Where the transmission of the no-Path DAO is being proactively = initiated by=20 a DAO Parent or other intermediate ancestor node that discovers the = loss of=20 connectivity (neighbor unreachability detection, NUD) to the node = that owns=20 the Prefix, the Path Sequence used in the no-Path DAO will be the = one=20 maintained by the ancestor node (only the owner of the Prefix can = increment=20 the Path Sequence for that Prefix). This would be the same as the = Path=20 Sequence maintained by all nodes along the path to the common = ancestor. The=20 first common ancestor receiving such a no-Path DAO should mark the = affected=20 downward path for deletion and should take no further action with = regard to=20 upward forwarding of the=20 = DAO.
       
   &= nbsp;   
       =20 If the owner of the Prefix discovers the loss of connection to an = existing=20 DAO Parent and wishes to update its path connections, including = potentially=20 re-selecting a different preference set of DAO Parents, the node = must=20 increment the Path Sequence and transmit DAOs to new desired DAO = Parents - a=20 no-Path DAO is not required. The incremented Path Sequence will = necessitate=20 that the updated DAOs be conveyed all the way to the root - in the = process=20 updating routing tables at intermediate nodes. Where new downward = paths are=20 established as a result of the updated DAOs, existing intermediate = routing=20 tables are directly updated. Routing table entries that are no = longer on the=20 re-established downward paths will be purged through the normal = expiration=20 of the associated downward route=20 = entries.
       
  &nb= sp;    
       =
       =20 Note: If the node that owns the Prefix chooses to maintain its = existing DAO=20 Parents and preferences (even with the lost connectivity to, or = desired=20 removal of, a single DAO Parent), it can do so by sending normal = periodic or=20 triggered DAO updates to the connected DAO Parents without = incrementing the=20 Path Sequence in the DAO updates. Where connectivity exists, the = owner of=20 the Prefix may also send a no-Path DAO to delete the path through a = given=20 DAO Parent. By not incrementing the Path Sequence the path through = the=20 particular DAO Parent will be removed only to the first common=20 = ancestor.
       
  &n= bsp;    
       = ;
       =20 To redefine DAO Parents and preferences (including where necessary = to=20 maintain fan-out limits), DAOs must be sent with an incremented Path = Sequence number to the newly desired/re-ordered DAO Parents. The = incremented=20 Path Sequence DAOs will ensure that the routing change is conveyed = to the=20 root and recognized by ancestor nodes that can delete downward path = entries.=20 Where the updated DAOs are received at nodes that do not currently = have=20 routing entries for the particular Prefix, the information is cached = and the=20 new DAO information conveyed towards the=20 = root.
       
   =     
              =20 Based on the above defined operation there is no benefit to the node = owner=20 of the Prefix sending a no-Path DAO with an incremented Path = Sequence. This=20 will travel all the way to the root and will have the effect of = outdating=20 and marking for deletion all existing downward routes for that = Prefix.=20 Instead, to re-establish desired downward paths, DAOs with = incremented Path=20 Sequences should be sent to the desired/maintained DAO=20 = Parents.
       
  &nb= sp;    
       =
       =20 There would be some benefit to being able to send a no-Path DAO to = delete a=20 single DAO Parent path all the way to the root but the incremented = Path=20 Sequence will make stale all other valid routing paths (as well as = introduce=20 the difficulties raised in your assessments). Note once again that = multiple=20 DAO Parents guarantee only local diversity. Therefore the fact that = deleting=20 a single DAO Parent using an un-incremented Path Sequence removes = diversity=20 only to a common ancestor should be seen in the context of the local = guarantees that are=20 = provided.
       
  &n= bsp;    
       = ;
       =20 SUMMARY: If a no-Path DAO is sent by the Prefix owner to a connected = DAO=20 Parent to delete the single downward path while maintaining the = others, the=20 Path Sequence should be maintained (not incremented) indicating that = all=20 established paths (and preferences) with the exception of the = identified DAO=20 Parent path is being maintained. The path through the particular DAO = Parent,=20 only to the first common ancestor, will be deleted. Where the = no-Path DAO is=20 being proactively sent by an ancestor node due to recognition of = NUD, the=20 same would apply as the Path Sequence number will be the one = currently=20 maintained by the ancestor node. The prefix owner should never send = a=20 no-Path DAO with an incremented Path Sequence but should instead = send=20 updated DAOs with incremented Path Sequence to re-establish or = re-order DAO=20 Parents and downward=20 = paths.
       
   = ;    
              =20 The operation for non-storing nodes would be the same. However, in = the case=20 of non-storing nodes the first common ancestor is always the root = node. If=20 in the non-storing case a no-path DAO is issued by the owner of the = Prefix=20 or by a DAO Parent (due to proactive response to NUD), the no-Path = DAO with=20 an un-incremented Path Sequence will directly allow the root to = update=20 existing downward paths (removing the identified DAO Parent while=20 maintaining ordering of remaining DAO Parents). As in the storing = case, a=20 no-Path DAO with an incremented Path Sequence would mark all other = downward=20 paths from the root as potentially outdated (and marked for = deletion) and so=20 should similarly not be=20 = issued.
       
  &nbs= p;    
       <= BR>       =20 This is the operation as I believe it should work but I look forward = to=20 understanding whether this envisaged operation can fit within the = model=20 given in=20 = -10.
       
   &= nbsp;   
       
=        =20 Make sense? See also a specific related comment=20 = below.
       
   = ;    
              =20 = Regards,
       
  &nb= sp;    
       =
       =20 = Roger
       
   =     
              =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org <mailto:roll-bounces@ietf.org> ] On Behalf Of Navneet Agarwal=20 (navagar)
        Sent: = Friday, July=20 09, 2010 1:26 PM
        To: = ROLL=20 WG
        Subject: [Roll] = no-Path DAO=20 and=20 = fan-out
       
  &nbs= p;    
       <= BR>       =20 Hi WG:
        I am trying to = get some=20 clarifications on expected behavior. Have read the Path Control = document on=20 path ctl field usage (attached). I have put several setups and = flows,=20 assuming storing nodes but should apply for non-storing scenario as = well. I=20 could not figure out from the reading the doc or the=20 = RFC.
       
   &= nbsp;   
       
=        =20 = Scenario-1:
       
  =      
      &nb= sp;
       =20 A    =20 = B
       
   &nbs= p;   =20 \     =20 = /
       
   &nbs= p;    =20 \  =20 = /
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 A, B - DAO Parents.....C - Node........D,E- nodes in=20 = subdag.
       
  &nbs= p;    =20 Assume path control allows two=20 = paths.
       
   = ;    =20 D and E have learnt a common prefix for a node below them,=20 = Pfx
       
   &n= bsp;   =20 D will set x10 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 E will set x01 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 C will set x10 in Path control of DAO sent to=20 = A
       
   &nbs= p;   =20 C will set x01 in Path control of DAO sent to=20 = B
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose E sends a no-Path DAO to C for Pfx with path control x01. = What does=20 C do? I would think that C will need to send a no-Path. But it has = to=20 remember that it had sent a DAO with path control x01 to B. If this = has to=20 happen then C would have to remember for each prefix what path = control was=20 sent to which parent, which does not seem correct as it would not = scale as=20 the prefixes at C scale, each having its own path control=20 = settings.
       
  &n= bsp;    
       = ;
       =20 = Scenario-2:
       
  =      
      &nb= sp;
       =20 F    =20 = G
       
   &nbs= p;   =20 \   =20 = /
       
   &nbs= p;    =20 \ =20 = /
       
   &nbs= p;   =20   =20 = A
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 D will set x10 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 E will set x01 in Path control of DAO sent to=20 = C
       
   &nbs= p;   =20 C will send a DAO with path control x11 to=20 = A
       
   &nbs= p;   =20 A will send a DAO with path control x01 to=20 = F
       
   &nbs= p;   =20 A will send a DAO with path control x10 to=20 = G
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose E sends a no-Path to C (path control x01). What does C do? = It will=20 likely send a DAO to A with path control x10. What will A do when it = receives a DAO with this path control when its previous path control = was=20 = x11?
       
   &= nbsp;   
       
=        =20 I see couple of other flows where path control settings may change = due to=20 sub-nodes going away and coming back up...for=20 = example:
       
  &nb= sp;    
       =
       =20 = Scenario-3
       
  &= nbsp;    
      &nbs= p;
       =20 F    =20 = G
       
   &nbs= p;   =20 \   =20 = /
       
   &nbs= p;    =20 \ =20 = /
       
   &nbs= p;   =20   =20 = A
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20    =20 = |
       
   &nbs= p;   =20   =20 = C
       
   &nbs= p;   =20   / =20 = \
       
   &nbs= p;    =20 /   =20 = \
       
   &nbs= p;   =20 D    =20 = E
       
   &nbs= p;   
       
&nb= sp;      =20 Suppose G is preferred over=20 = F.
       
   &nb= sp;   =20 Suppose path from E to D is=20 = down.
       
   =     =20 D sends DAO with path control x10 to=20 = C
       
   &nbs= p;   =20 C sends DAO with path control x10 to=20 = A
       
   &nbs= p;   =20 A sends DAO with path control x10 to=20 = G
       
   &nbs= p;   
       
&nb= sp;      =20 After some time E comes up and sends a DAO with path control x01 = (higher=20 path preference than D to C) to=20 = C.
       
   &nb= sp;   =20 C merges this and sends a DAO with path control x11 to A. What does = A do=20 since is has indicated a path control of x10 to G. In normal terms, = if A had=20 received a DAO with path control x11 from C, it would have notified = DAO to F=20 with path control x10 and DAO to G with path control x01 but due to=20 transient conditions it could be=20 = reversed.
       
  &n= bsp;    
       = ;=20 [RA] In the case of receipt of the first updated DAO (with = incremented Path=20 Sequence) only the new information with single path control should = be=20 forwarded since all prior path information is effectively obsolete = by the=20 incremented Path Sequence. When subsequent DAO updates are received = with the=20 new, incremented Path Sequence, only then can the combined path = control=20 information be=20 = forwarded.
       
  &= nbsp;    
      &nbs= p;
       
   &nb= sp;   
       =20 Will appreciate if it can be clarified if the above flows are = reasonable and=20 what should happen...in general I dont think path control should = mandate=20 which path control bits are tied to which DAO parent=20 = etc...
       
   = ;    
       =20 [RA] Hopefully the above discussion supports the view that Path = Control can=20 operate as specified without the need to maintain state on which DAO = with=20 which Path Control was sent to which DAO=20 = Parent.
       
  &nbs= p;    
       <= BR>       
    =    
       =20 = Thanks
       
   = ;    
              =20 = Regards,
       
  &nb= sp;    =20 = Navneet
       
  &nbs= p;    
       <= BR>       
    =    
       

&= nbsp;      

------_=_NextPart_001_01CB23CF.9392448A-- From Eric.Gnoske@atmel.com Wed Jul 14 22:57:23 2010 Return-Path: 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 E22423A6A58 for ; Wed, 14 Jul 2010 22:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 A8fRn7pEP3AG for ; Wed, 14 Jul 2010 22:57:23 -0700 (PDT) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id C1B3E3A6872 for ; Wed, 14 Jul 2010 22:57:19 -0700 (PDT) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id o6F5t3vV007112; Wed, 14 Jul 2010 22:55:10 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB23E2.8E566B0C" Date: Wed, 14 Jul 2010 23:57:06 -0600 Message-ID: <7941B2693F32294AAF16C26B679A258D0D18DE34@csomb01.corp.atmel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ticket #57 Thread-Index: Acsj4o4rxeEPs5OcSFCA9fhlW+Ofcg== From: "Gnoske, Eric" To: , Subject: [Roll] ticket #57 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: , X-List-Received-Date: Thu, 15 Jul 2010 05:57:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB23E2.8E566B0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, ROLLers, Can you explain how the route to a new node is aggregated if the DAO = messages are not processed at each hop?! Thanks, Eric Gnoske ------_=_NextPart_001_01CB23E2.8E566B0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ticket #57

Hi Richard, ROLLers,

Can you explain how the route to a new node is aggregated if the DAO = messages are not processed at each hop?!

Thanks,

Eric Gnoske

------_=_NextPart_001_01CB23E2.8E566B0C-- From jpv@cisco.com Wed Jul 14 23:01:54 2010 Return-Path: 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 8A3DB3A68C0 for ; Wed, 14 Jul 2010 23:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.34 X-Spam-Level: X-Spam-Status: No, score=-10.34 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 cR4Xq6a2iISg for ; Wed, 14 Jul 2010 23:01:51 -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 737E43A684A for ; Wed, 14 Jul 2010 23:01:50 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADdBPkxAZnwM/2dsb2JhbACfdHGkV5pyhSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,206,1278288000"; d="scan'208,217";a="132584233" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 06:02:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6F620Ct017241; Thu, 15 Jul 2010 06:02:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 08:02:00 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 08:01:59 +0200 Message-Id: <230DEAA3-BE68-40BF-B061-D66973FBABDC@cisco.com> From: JP Vasseur To: "Gnoske, Eric" In-Reply-To: <7941B2693F32294AAF16C26B679A258D0D18DE34@csomb01.corp.atmel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-12-218807988 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 08:01:58 +0200 References: <7941B2693F32294AAF16C26B679A258D0D18DE34@csomb01.corp.atmel.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 06:01:59.0519 (UTC) FILETIME=[3CD2D6F0:01CB23E3] Cc: roll@ietf.org Subject: Re: [Roll] ticket #57 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: , X-List-Received-Date: Thu, 15 Jul 2010 06:01:54 -0000 --Apple-Mail-12-218807988 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jul 15, 2010, at 7:57 AM, Gnoske, Eric wrote: > Hi Richard, ROLLers, > > Can you explain how the route to a new node is aggregated if the DAO > messages are not processed at each hop?! > > They are not, at least once the DOA has been generated (of course a node sourcing the DAO can aggregate). Cheers. JP. > Thanks, > > Eric Gnoske > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-12-218807988 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi,

On Jul 15, 2010, at 7:57 AM, Gnoske, Eric wrote:

Hi Richard, ROLLers,

Can you explain how the route to a new node is aggregated if the DAO messages are not processed at each hop?!

They are not, at least once the DOA has been generated (of course a node sourcing the DAO can aggregate).

Cheers.

JP.

Thanks,

Eric Gnoske

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

--Apple-Mail-12-218807988-- From trac@tools.ietf.org Wed Jul 14 23:15:59 2010 Return-Path: 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 CE9B53A681A for ; Wed, 14 Jul 2010 23:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 0WUW7choe7O2 for ; Wed, 14 Jul 2010 23:15:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BE2D43A67FB for ; Wed, 14 Jul 2010 23:15:50 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZHjk-0002rb-0H; Wed, 14 Jul 2010 23:16:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 06:15:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/61 Message-ID: <055.bbdb8d9755758aa3da64c3a71b0fb674@tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #61: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:16:00 -0000 #61: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Two set of comments were sent with regards to the Manageability section during WG Last Call. First in attached document, second set below: Email from Mathilde Durvy on July 13: Hi All, Just reviewed Section 16, here is some feedback that might help clarify: - In 16.2.3, 16.2.4 It is not very clear which parameters are configured versus negotiated dynamically through messages. - In 16.2.4 “A RPL implementation SHOULD allow configuring whether a non- storing node provides the transit information in DAO messages.†Shouldn’t a node always include the transit info in DAO messages? Aren’t the 2 first bullet related to the DAO mechanism and hence more appropriate in Section 16.2.6 (or maybe we should just remove Section 16.2.6) - In 16.2.5, T flag has not been removed - In 16.2.6, this section contains legacy text (already mentioned in previous email thread) - In 16.6, is the DODAGID necessarily part of the policy? - In 16.7/16.9 or 16.4. Maybe it would help to further specify what services RPL expects to be handled by other protocols such as ND. I’m talking of course of services that RPL directly relies on to operate. NUD is mentioned but what about address resolution, etc. I guess this is kind of standard so not sure if we should include it. - In general, Sections 16.3 to 16.5 can be difficult to implement on constrained nodes without interface or file system. I would emphasize that it is expected that constrained nodes do not implement these parts. Best, Mathilde -- Ticket URL: roll From trac@tools.ietf.org Wed Jul 14 23:21:06 2010 Return-Path: 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 CB1FE3A681A for ; Wed, 14 Jul 2010 23:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 6MgGCtKYeKWS for ; Wed, 14 Jul 2010 23:21:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE9873A684A for ; Wed, 14 Jul 2010 23:21:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZHoq-0008K6-9d; Wed, 14 Jul 2010 23:21:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 06:21:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/62 Message-ID: <055.638b33db2c7879f10ca6cadb23d7af37@tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #62: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:21:06 -0000 #62: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Two set of comments were sent with regards to the Manageability section during WG Last Call. First set send with a file attached on the mailing list on July 13. Second set below: Email from Mathilde Durvy on July 13: Hi All, Just reviewed Section 16, here is some feedback that might help clarify: - In 16.2.3, 16.2.4 It is not very clear which parameters are configured versus negotiated dynamically through messages. - In 16.2.4 “A RPL implementation SHOULD allow configuring whether a non- storing node provides the transit information in DAO messages.†Shouldn’t a node always include the transit info in DAO messages? Aren’t the 2 first bullet related to the DAO mechanism and hence more appropriate in Section 16.2.6 (or maybe we should just remove Section 16.2.6) - In 16.2.5, T flag has not been removed - In 16.2.6, this section contains legacy text (already mentioned in previous email thread) - In 16.6, is the DODAGID necessarily part of the policy? - In 16.7/16.9 or 16.4. Maybe it would help to further specify what services RPL expects to be handled by other protocols such as ND. I’m talking of course of services that RPL directly relies on to operate. NUD is mentioned but what about address resolution, etc. I guess this is kind of standard so not sure if we should include it. - In general, Sections 16.3 to 16.5 can be difficult to implement on constrained nodes without interface or file system. I would emphasize that it is expected that constrained nodes do not implement these parts. Best, Mathilde -- Ticket URL: roll From trac@tools.ietf.org Wed Jul 14 23:21:26 2010 Return-Path: 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 B14863A6990 for ; Wed, 14 Jul 2010 23:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 fB8fNVe2S1EK for ; Wed, 14 Jul 2010 23:21:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A38D83A68CF for ; Wed, 14 Jul 2010 23:21:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZHpA-0000p8-AE; Wed, 14 Jul 2010 23:21:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 06:21:36 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/63 Message-ID: <055.2d8835ae40d7ed72be48f522fd248099@tools.ietf.org> X-Trac-Ticket-ID: 63 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #63: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:21:26 -0000 #63: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Two set of comments were sent with regards to the Manageability section during WG Last Call. First set send with a file attached on the mailing list on July 13. Second set below: Email from Mathilde Durvy on July 13: Hi All, Just reviewed Section 16, here is some feedback that might help clarify: - In 16.2.3, 16.2.4 It is not very clear which parameters are configured versus negotiated dynamically through messages. - In 16.2.4 “A RPL implementation SHOULD allow configuring whether a non- storing node provides the transit information in DAO messages.†Shouldn’t a node always include the transit info in DAO messages? Aren’t the 2 first bullet related to the DAO mechanism and hence more appropriate in Section 16.2.6 (or maybe we should just remove Section 16.2.6) - In 16.2.5, T flag has not been removed - In 16.2.6, this section contains legacy text (already mentioned in previous email thread) - In 16.6, is the DODAGID necessarily part of the policy? - In 16.7/16.9 or 16.4. Maybe it would help to further specify what services RPL expects to be handled by other protocols such as ND. I’m talking of course of services that RPL directly relies on to operate. NUD is mentioned but what about address resolution, etc. I guess this is kind of standard so not sure if we should include it. - In general, Sections 16.3 to 16.5 can be difficult to implement on constrained nodes without interface or file system. I would emphasize that it is expected that constrained nodes do not implement these parts. Best, Mathilde -- Ticket URL: roll From trac@tools.ietf.org Wed Jul 14 23:23:29 2010 Return-Path: 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 4A91E3A6A0A for ; Wed, 14 Jul 2010 23:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 FYIh7kKj94Eq for ; Wed, 14 Jul 2010 23:23:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 435213A681A for ; Wed, 14 Jul 2010 23:23:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZHr8-0000z6-VC; Wed, 14 Jul 2010 23:23:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 06:23:38 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/61#comment:1 Message-ID: <064.3343c78a294fa12bfe17456f48617e78@tools.ietf.org> References: <055.bbdb8d9755758aa3da64c3a71b0fb674@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <055.bbdb8d9755758aa3da64c3a71b0fb674@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #61: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:23:29 -0000 #61: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: duplicate Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => duplicate -- Ticket URL: roll From trac@tools.ietf.org Wed Jul 14 23:23:58 2010 Return-Path: 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 2FF753A681A for ; Wed, 14 Jul 2010 23:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 f2krhIaYvlN5 for ; Wed, 14 Jul 2010 23:23:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2CA0B3A67AE for ; Wed, 14 Jul 2010 23:23:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZHrb-0002ny-SC; Wed, 14 Jul 2010 23:24:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 06:24:07 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/62#comment:1 Message-ID: <064.36d68b2868fd13e0415e446466bdbb48@tools.ietf.org> References: <055.638b33db2c7879f10ca6cadb23d7af37@tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <055.638b33db2c7879f10ca6cadb23d7af37@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #62: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 06:23:58 -0000 #62: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: duplicate Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => duplicate -- Ticket URL: roll From trac@tools.ietf.org Thu Jul 15 01:21:27 2010 Return-Path: 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 37C283A6878 for ; Thu, 15 Jul 2010 01:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 VwM1g+RRSvnB for ; Thu, 15 Jul 2010 01:21:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 48F1C3A67ED for ; Thu, 15 Jul 2010 01:21:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZJhG-00029U-Fs; Thu, 15 Jul 2010 01:21:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 08:21:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/64 Message-ID: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> X-Trac-Ticket-ID: 64 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 08:21:27 -0000 #64: RPL Instance ID in flow label or RPL option -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from JP: Section 4 says: For data packets, the RPLInstanceID may be indicated in the flow label by the source of the packet. If it is not, then it is inferred and added by the RPL network ingress router in the RPL Hop-by-hop option ([I-D.hui-6man-rpl-option]) as further described in Section 10.2 We need to choose ... if the packet is originated from outside of the RPL domain it has to be in the flow label unless the BR makes the selection. We should clarify this and indicate when carried in the flow label and when carried in the RPL option. Suggest to be consistent and put in flow label. -- Ticket URL: roll From daniel.gavelle@jennic.com Thu Jul 15 01:37:01 2010 Return-Path: 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 68A5F3A67F7 for ; Thu, 15 Jul 2010 01:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 hIA9BMcAnob2 for ; Thu, 15 Jul 2010 01:37:00 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id C596E3A67B7 for ; Thu, 15 Jul 2010 01:36:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id C79EB9BE50E; Thu, 15 Jul 2010 09:37:08 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCe3kZnWbWZW; Thu, 15 Jul 2010 09:37:08 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id B156D9BE508; Thu, 15 Jul 2010 09:37:08 +0100 (BST) Message-ID: <4C3EC8B4.3010409@jennic.com> Date: Thu, 15 Jul 2010 09:37:08 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Alexander, Roger" References: <4C3D8E54.6020101@sics.se> <9BB070DB2D281946859EA89837931EEE19C5CC@EVS4.nam.ci.root> In-Reply-To: <9BB070DB2D281946859EA89837931EEE19C5CC@EVS4.nam.ci.root> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] DODAG Default Path Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 08:37:01 -0000 Alexander, I think this is a good idea. The number of nodes on a network may well be limited by the memory available to store the per-node information on the root. Daniel. Alexander, Roger wrote: > Hi WG, > > I would like to recommend use of a DODAG-defined Default Path Lifetime > as opposed to the current model in which Path Lifetime is specified per > prefix using the Transit Information Option. > > As in other routing protocols, such as RIP for example, the validity > period of an advertised prefix is defined not per destination address > but is specified through a protocol configuration element such as the > route-timeout timer. In the same vein, a default validity period can be > defined for all advertised destinations through a Default Path Lifetime > specified within the DODAG Configuration option. This default value will > apply to all advertised prefixes unless otherwise specified using an > optional Path Lifetime information element within the Transit > Information option. The benefit of a Default Path Lifetime is that it > will allow 4-bytes to be saved per advertised DAO destination unless a > specific, dedicated Path Lifetime is needed for a given prefix. The > Lifetime for a destination address will continue to apply from the time > of receipt at a node. > > No additional control bits will be required within the Transit > Information Option as the presence or absence of the Path Lifetime > information element can be directly deduced from the value of the Option > Length. > > Thanks. > > Roger > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From nicolas.dejean.ietf@googlemail.com Thu Jul 15 02:25:01 2010 Return-Path: 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 A760D3A6805 for ; Thu, 15 Jul 2010 02:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.506, 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 dh0CbWhTxl+S for ; Thu, 15 Jul 2010 02:25:00 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 09FA93A67F7 for ; Thu, 15 Jul 2010 02:24:59 -0700 (PDT) Received: by eyb7 with SMTP id 7so140376eyb.31 for ; Thu, 15 Jul 2010 02:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OKBEppTjq5FX3zUJfP5js9bELDiT9qKKGIGKBPF5z6A=; b=Ry2vo8UnDP5LorFn+fSoXvSSc2P0izW7pNh5kEujrB5bbQ2W9Ug/dziyz7TWlReqrv XIAtf627uI03ERf8AA6sm09v4YSEZ4BY5B++IQoD727b4MlRWI+TSZRYtY4CEI2aX0tH linwfWTiaNhRAo5mdpwBE7O8KNWQRqIDhDqQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BXrSHgC+zQ52RpRYmB+OoZHtfh9xi3fSd4n0tSSQR9Iqr843CiV8+IVI9Bu20Iuyds STlin2qvWUd3dsMrjK42/szVUhvAqK7x47o39WUM2d83tVAY44DtqIbHslqrgzamqGRe xe7jHk6aDUZWgRlSBGbrTZOiTLpHu4GVD0ScM= MIME-Version: 1.0 Received: by 10.213.3.70 with SMTP id 6mr2532427ebm.8.1279185906735; Thu, 15 Jul 2010 02:25:06 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Thu, 15 Jul 2010 02:25:06 -0700 (PDT) In-Reply-To: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> Date: Thu, 15 Jul 2010 11:25:06 +0200 Message-ID: From: Nicolas DEJEAN To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Thu, 15 Jul 2010 09:25:01 -0000 Hello Phil, WG, 2010/7/14 Philip Levis : > > On Jul 14, 2010, at 1:58 AM, Nicolas DEJEAN wrote: > >> Hello Phil, >> >> 2010/7/13 Philip Levis : >>> >>> On Jul 13, 2010, at 7:17 AM, Nicolas DEJEAN wrote: >>> >>>> Hello Phil, >>>> >>>>> A couple of thoughts/opinions: >>>> >>>>> 1) I personally don't think these optimizations matter much. >>>> >>>> Dominique had explained and documented in >>>> http://www.ietf.org/mail-archive/web/roll/current/msg03306.html that >>>> these optimizations do matter in our application domain. Please find >>>> at the bottom of this message the description of an even more critical >>>> case extracted from real life deployment. >>> >>> I'm confused: the message you reference describes the need for filtering who responds to a DIS, mechanisms which are in the draft currently. There's no mention for need of U and R bits. >>> >> You are right, this message in particular does not describe the >> proposed flags but presents the impact of over-hearing in a well >> identified case taken from real-life deployments. >> >> http://www.ietf.org/mail-archive/web/roll/current/msg03810.html >> presents a solution proposal for solving this critical case. >> >> This proposal uses both DIS filtering and flags for avoiding increased >> control traffic and thus over-hearing during deployment phases. > > I'm still confused: is your concern that the requirement (scoping responses to DIS messages) isn't satisfied in the current draft, or are you insisting that RPL include your proposal without any changes? > The starting point is the critical case that was described. One solution for solving this case is the mechanism I proposed (it is not new, it has been validated in the field). This proposal is more an example than a requirement. My issue today is that the current draft completely forbids the implementation of the mechanism I described as a multicast DIS reception always: - triggers the Reset of the Trickle Timer, - implies answers sent in multicast. These two consequences will clearly increase control traffic and thus over-hearing phenomenon. Implementation of the proposed mechanism requires some modifications into the draft for having the ability to: - keep the same behavior as the one currently described into the Draft for reaching consistency (R=1, U=0 allows that), - implement the proposed mechanism for leaf nodes deployment (R=0, U=1 allows this case). For instance, in rpl-10, the text from 7.3 might be changed like this for managing the Reset of the Trickle Timer: ---------------------- o When a node receives a multicast DIS message *with the R flag set and* without a Solicited Information option. o When a node receives a multicast DIS *with the R flag set and* with a Solicited Information option and the node matches all of the predicates in the Solicited Information option. ----------------------- A sentence like the following is also required: ----------------------- When a node receives a multicast DIS *with the R flag clear*, it MUST NOT reset its Trickle Timer. ----------------------- Also, a sentence might be added for managing the transmission mode of answered DIOs: ---------------------- When a node receives a DIS (unicast or multicast) with the U flag set, it MUST unicast a DIO to the sender in response. ---------------------- Clearly, some use case have to be described for specifying when to set or not R and U flags: - default operational mode for network consistency: R=1 and U=0, - specific leaf node deployment: R=0 and U=1. As a conclusion, the goal of the proposed R and U flags is not to modify the well-known behavior that allows the network reaching consistency but to extend the possible usage of DIS/DIOs to energy-efficient leaf node deployment. > Phil For answering directly your question, I do not expect that RPL includes the proposed mechanism. It might be described in a separate document if the WG shows some interest for it. However, adding these two flags to the Draft is one solution for allowing this mechanism to be implemented. Is my concern clearer now? In these conditions, does the integration of R and U flags seem acceptable now? Thanks, Nicolas. From pthubert@cisco.com Thu Jul 15 02:38:47 2010 Return-Path: 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 913363A6875 for ; Thu, 15 Jul 2010 02:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JWC0i+Nr9iXJ for ; Thu, 15 Jul 2010 02:38:46 -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 A793E3A699D for ; Thu, 15 Jul 2010 02:38:45 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIt0PkxAZnwN/2dsb2JhbACfanGjMZp1hSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208";a="132670454" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2010 09:38:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6F9cIOb007175; Thu, 15 Jul 2010 09:38:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 11:38:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 11:38:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574462@XMB-AMS-107.cisco.com> In-Reply-To: <4C3D8E54.6020101@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New link-local RPL multicast address and 6lowpan-HC thread-index: AcsjPaAfaoZ2l/spQtaQv1zv9f6eVAAw5BGQ References: <4C3D8E54.6020101@sics.se> From: "Pascal Thubert (pthubert)" To: "Joakim Eriksson" , "roll" X-OriginalArrivalTime: 15 Jul 2010 09:38:23.0212 (UTC) FILETIME=[77B52AC0:01CB2401] Subject: Re: [Roll] New link-local RPL multicast address and 6lowpan-HC 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: , X-List-Received-Date: Thu, 15 Jul 2010 09:38:47 -0000 Great point Joakim;=20 1A is actually free in http://www.iana.org/assignments/ipv6-multicast-addresses/=20 let's try and get that value? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Joakim Eriksson > Sent: Wednesday, July 14, 2010 12:16 PM > To: roll > Subject: [Roll] New link-local RPL multicast address and 6lowpan-HC >=20 > Hello, >=20 > The new RPL all routers address ff02::1:a is going to cause much worse > compression (3 bytes vs 1 byte) of the destination address in 6lowpan based > networks. Is there any plans for "fixing" the HC or are we ok with this? (I like > small messages ;-) >=20 > Would it be impossible to get a ff02::1a address from IANA instead? >=20 >=20 > Best regards > -- Joakim Eriksson, SICS > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Thu Jul 15 04:08:31 2010 Return-Path: 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 A7A583A6403 for ; Thu, 15 Jul 2010 04:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 07tpTVsjAM1j for ; Thu, 15 Jul 2010 04:08:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C77BB3A69DC for ; Thu, 15 Jul 2010 04:08:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZMIy-0004xv-SJ; Thu, 15 Jul 2010 04:08:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 11:08:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/65 Message-ID: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> X-Trac-Ticket-ID: 65 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #65: Move some references as normative X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:08:31 -0000 #65: Move some references as normative -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- The following references should normative (in rev-11): [I-D.ietf-6man-rpl-option] Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Information in Data-Plane Datagrams", draft-hui-6man-rpl-option-01 (work in progress), June 2010. [I-D.ietf-6man-rpl-routing-header] Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Header for Source Routes with RPL", draft-hui-6man-rpl-routing-header-02 (work in progress), June 2010. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-01 (work in progress), April 2010. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-07 (work in progress), June 2010. -- Ticket URL: roll From yoav@yitran.com Thu Jul 15 04:12:00 2010 Return-Path: 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 9FF7E3A695D for ; Thu, 15 Jul 2010 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wU7MaUtIgUvL for ; Thu, 15 Jul 2010 04:11:59 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id E81433A69F1 for ; Thu, 15 Jul 2010 04:11:58 -0700 (PDT) Received: from source ([209.85.161.52]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTD7tCG+JIN0yZaP17PyaFNQmA0YR4vOs@postini.com; Thu, 15 Jul 2010 04:12:10 PDT Received: by fxm8 with SMTP id 8so375604fxm.39 for ; Thu, 15 Jul 2010 04:12:07 -0700 (PDT) Received: by 10.239.177.197 with SMTP id w5mr1583259hbf.167.1279192327085; Thu, 15 Jul 2010 04:12:07 -0700 (PDT) From: Yoav Ben-Yehezkel References: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> In-Reply-To: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskDhkiXLGBl1fRS/qHR0C1S3HSYQAADUzQ Date: Thu, 15 Jul 2010 14:12:02 +0300 Message-ID: <018b49564246ecc42377d326ddceace9@mail.gmail.com> To: roll@ietf.org, wintert@acm.org, jpv@cisco.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] [roll] #65: Move some references as normative 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:12:00 -0000 Also note that some of the draft versions have changed (for example, trickle). Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of rol= l issue tracker Sent: Thursday, July 15, 2010 2:09 PM To: wintert@acm.org; jpv@cisco.com Cc: roll@ietf.org Subject: [Roll] [roll] #65: Move some references as normative #65: Move some references as normative -----------------------------+---------------------------------------------= - Reporter: jpv@=85 | Owner: wintert@=85 Type: defect | Status: new Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------= - The following references should normative (in rev-11): [I-D.ietf-6man-rpl-option] Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Information in Data-Plane Datagrams", draft-hui-6man-rpl-option-01 (work in progress), June 2010. [I-D.ietf-6man-rpl-routing-header] Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Header for Source Routes with RPL", draft-hui-6man-rpl-routing-header-02 (work in progress), June 2010. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-01 (work in progress), April 2010. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-07 (work in progress), June 2010. --=20 Ticket URL: roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu Jul 15 04:14:48 2010 Return-Path: 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 1469B3A6858 for ; Thu, 15 Jul 2010 04:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 1HJTXAOzrnDS for ; Thu, 15 Jul 2010 04:14:44 -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 4F60F3A69F1 for ; Thu, 15 Jul 2010 04:14:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABSLPkxAZnwM/2dsb2JhbACfZ3GjC5p5hSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208,217";a="132681363" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 11:14:42 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FBEgT9005904 for ; Thu, 15 Jul 2010 11:14:42 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 13:14:42 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 13:14:41 +0200 Message-Id: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-25-237569712 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 13:14:40 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 11:14:41.0455 (UTC) FILETIME=[EBCF13F0:01CB240E] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17506.005 X-TM-AS-Result: No--6.164800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:14:48 -0000 --Apple-Mail-25-237569712 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Section 7.4 7.4. DODAG Selection The DODAG selection is implementation and OF dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. I would advocate for a MUST there. Thought? JP. --Apple-Mail-25-237569712 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Section 7.4

7.4.  DODAG Selection

   The DODAG selection is implementation and OF dependent.  Nodes SHOULD
   prefer to join DODAGs for RPLInstanceIDs advertising OCPs and
   destinations compatible with their implementation specific
   objectives.

I would advocate for a MUST there.

Thought?

JP.
--Apple-Mail-25-237569712-- From jpv@cisco.com Thu Jul 15 04:17:30 2010 Return-Path: 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 8E0ED3A6858 for ; Thu, 15 Jul 2010 04:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Q9uNdAN85yem for ; Thu, 15 Jul 2010 04:17:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8951D3A67F2 for ; Thu, 15 Jul 2010 04:17:29 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM+KPkyrR7Ht/2dsb2JhbACfZ3GjEZp6hSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208";a="226697656" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 11:17:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FBHaA6028526; Thu, 15 Jul 2010 11:17:39 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 13:17:37 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 13:17:37 +0200 Message-Id: <65CF4096-FAD2-43DB-9824-028B6E4490D2@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <018b49564246ecc42377d326ddceace9@mail.gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 13:17:35 +0200 References: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> <018b49564246ecc42377d326ddceace9@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 11:17:37.0531 (UTC) FILETIME=[54C224B0:01CB240F] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #65: Move some references as normative 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:17:30 -0000 On Jul 15, 2010, at 1:12 PM, Yoav Ben-Yehezkel wrote: > Also note that some of the draft versions have changed (for example, > trickle). Yes but this will be automatically updated when generating -11. Cheers. JP. > Yoav > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of roll > issue tracker > Sent: Thursday, July 15, 2010 2:09 PM > To: wintert@acm.org; jpv@cisco.com > Cc: roll@ietf.org > Subject: [Roll] [roll] #65: Move some references as normative > > #65: Move some references as normative > -----------------------------=20 > +---------------------------------------------- > Reporter: jpv@=85 | Owner: wintert@=85 > Type: defect | Status: new > Priority: minor | Milestone: > Component: rpl | Version: > Severity: In WG Last Call | Keywords: > -----------------------------=20 > +---------------------------------------------- > The following references should normative (in rev-11): > > [I-D.ietf-6man-rpl-option] > Hui, J. and J. Vasseur, "RPL Option for Carrying RPL > Information in Data-Plane Datagrams", > draft-hui-6man-rpl-option-01 (work in progress), > June 2010. > > [I-D.ietf-6man-rpl-routing-header] > Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing > Header for Source Routes with RPL", > draft-hui-6man-rpl-routing-header-02 (work in progress), > June 2010. > > [I-D.ietf-roll-trickle] > Levis, P., Clausen, T., Hui, J., and J. Ko, "The Trickle > Algorithm", draft-ietf-roll-trickle-01 (work in =20 > progress), > April 2010. > > [I-D.ietf-roll-routing-metrics] > Vasseur, J., Kim, M., Networks, D., and H. Chong, =20 > "Routing > Metrics used for Path Calculation in Low Power and Lossy > Networks", draft-ietf-roll-routing-metrics-07 (work in > progress), June 2010. > > --=20 > Ticket URL: > 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 yoav@yitran.com Thu Jul 15 04:30:30 2010 Return-Path: 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 8CDDD3A683C for ; Thu, 15 Jul 2010 04:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 d92BQ8qjl87C for ; Thu, 15 Jul 2010 04:30:23 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id D17563A6858 for ; Thu, 15 Jul 2010 04:30:21 -0700 (PDT) Received: from source ([209.85.161.53]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTD7xV/dtkaVgSZ6d4LnxamOSm/Ucxrdc@postini.com; Thu, 15 Jul 2010 04:30:33 PDT Received: by mail-fx0-f53.google.com with SMTP id 19so336429fxm.12 for ; Thu, 15 Jul 2010 04:30:31 -0700 (PDT) Received: by 10.239.181.205 with SMTP id n13mr1603403hbg.88.1279193430801; Thu, 15 Jul 2010 04:30:30 -0700 (PDT) From: Yoav Ben-Yehezkel References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> In-Reply-To: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskDvsI0gIIGGrmTxuoqyUoSKaV2QAAMSQg Date: Thu, 15 Jul 2010 14:30:26 +0300 Message-ID: <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com> To: JP Vasseur , ROLL WG Content-Type: multipart/alternative; boundary=001485f7cc8e0abf9b048b6b6e88 Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:30:31 -0000 --001485f7cc8e0abf9b048b6b6e88 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I understand why joining based on RPLInstanceIDs should be must =96 this is= an application requirement. However, being able to support a certain OCP in an RPLInstance that is not required by my application, seems a little confusing to me. Also, I=92m not sure - where are =93destinations compatible with their =85= =94 advertised? Thanks, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *JP Vasseur *Sent:* Thursday, July 15, 2010 2:15 PM *To:* ROLL WG *Subject:* [Roll] Comment Section 7.4 Section 7.4 7.4. DODAG Selection The DODAG selection is implementation and OF dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. I would advocate for a MUST there. Thought? JP. --001485f7cc8e0abf9b048b6b6e88 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I understand why joining based on RPLInstanceIDs should be m= ust =96 this is an application requirement.

=A0

However, being able to support a certain OCP in an RPLInstan= ce that is not required by my application, seems a little confusing to me.

=A0

Also, I=92m not sure - where are =93destinations compatible with their =85=94 advertised?

=A0

Thanks,

Yoav

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of JP Vasseur
Sent: Thursday, July 15, 2010 2:15 PM
To: ROLL WG
Subject: [Roll] Comment Section 7.4

=A0

Section 7.4

=A0

7.4.=A0 DODA=
G Selection
=A0
=A0=A0 The DODAG selection is implement=
ation and OF dependent.=A0 Nodes SHOULD
=A0=A0 prefer to join DOD=
AGs for RPLInstanceIDs advertising OCPs and
=A0=A0 destinations compatible with their implementation specific
=A0=A0 objectives.

=A0

I would advocate for a MUST there.

=A0

Thought?

=A0

JP.

--001485f7cc8e0abf9b048b6b6e88-- From mdurvy@cisco.com Thu Jul 15 04:31:24 2010 Return-Path: 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 61E793A69CD for ; Thu, 15 Jul 2010 04:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.47 X-Spam-Level: X-Spam-Status: No, score=-9.47 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 rRRZYug-qGIG for ; Thu, 15 Jul 2010 04:31:16 -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 6826D3A67F2 for ; Thu, 15 Jul 2010 04:31:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.png, image002.gif, smime.p7s : 6281, 87, 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFKOPkxAZnwN/2dsb2JhbACBRIFbnEhxoniJL5FKAoQwcgSLBA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="gif'147?p7s'147?png'147,150?scan'147,150,208,217,147,150"; a="132711314" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2010 11:31:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6FBVMq5012052 for ; Thu, 15 Jul 2010 11:31:24 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 13:31:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jul 2010 13:31:21 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08A4_01CB2422.033D0610" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E8D4@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication Thread-Index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybwAG+67AAAQubjABIXlUQA== References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 15 Jul 2010 11:31:24.0111 (UTC) FILETIME=[41703DF0:01CB2411] Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:31:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08A4_01CB2422.033D0610 Content-Type: multipart/related; boundary="----=_NextPart_001_08A5_01CB2422.033D0610" ------=_NextPart_001_08A5_01CB2422.033D0610 Content-Type: multipart/alternative; boundary="----=_NextPart_002_08A6_01CB2422.033D0610" ------=_NextPart_002_08A6_01CB2422.033D0610 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, All, =20 Let me know if this is a correct summary of the possible cases. I also = put some comments to point things where I think a clarification is = needed. =20 1) RPL S =C3=A0 BR =C3=A0 D No tunnel, the RPL = source adds the HbH header, BR removes it 2) S =C3=A0 RPL R =C3=A0 BR =C3=A0 D Tunnel. R introduces new = IPv6 header with HbH header, R is the IPv6 source, BR the IPv6 dest. BR = removes this header.=20 Comment: If BR is the end of the tunnel, its address needs to be known = by R. How does that work? This would favor an approach where the DODAGID = must be the global IPv6 address of the root =20 3) RPL D =C3=9F BR =C3=9F S Tunnel. BR introduces = new IPv6 header with HbH header and RH (non-storing mode only), BR is = the IPv6 source, and RPL D the final dest in the RH.=20 =20 4) D =C3=9F RPL R =C3=9F BR =C3=9F S Tunnel. BR introduces = new IPv6 header with HbH header and RH (non-storing mode only), BR is = the IPv6 source, and RPL R the final dest in the RH. R decapsulates and = sends to D. Comment: This would work if R sends DAO with target D and transit = =E2=80=9Cthe parent of R=E2=80=9D: I think this is a bit different than = your approach in 5b. Also, I have the impression that according to = =E2=80=9CThe last entry, Address[n], is exempt from the strict source = route policy and may specify a destination outside the RPL = domain=E2=80=9D, D address could be the last address in the RH but = I=E2=80=99m not sure how this would work. If this text does not apply to = tunnel mode as you point below, we should say so. =20 5) S =C3=A0 RPL R1 =C3=A0 BR =C3=A0 RPL R2 =C3=A0 D = Tunnel. R1 introduces new IPv6 header with HbH header, R1 is the IPv6 = source,=20 BR the IPv6 dest. BR removes this header. Encapsulates with new IPv6 = header with HbH header and RH (non-storing mode only), BR is the IPv6 = source, and RPL R2 the final dest in the RH.=20 Comment: I guess this vision contradicts your point 5a. Seems simpler to = me, but maybe I=E2=80=99m missing something. =20 Note that if the above is correct, the only information needed by RPL = nodes is the global address of the BR (i.e. the root). So it seems that = 2 below might not be needed =20 Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: vendredi, 9. juillet 2010 17:43 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] Use of tunnels and end point determication =20 =20 =20 =20 Anyway it appears that the spec could be clearer in: 1. Explaining why IP in IP is used in general 2. Specifying the rules to determine if a destination is inside = the RPL network 3. Specifying tunnel mode operation 4. Specifying transport mode operation and when it can be used 5. Specifying how to determine the tunnel endpoint in tunnel mode =20 Proposal: =20 1) RPL needs an instance ID in the flow label, and HbH header, and = eventually a routing header in every packet for routing and = inconsistency determination. The HbH and RH are nonsensical outside the = RPL network and can only be present inside the RPL network. The only = clean way to insert and remove those headers is to use a tunnel mode (IP = in IP encapsulation) whereby the router places the RPL headers before = the inner header, leaving the original packet untouched. a. A source inside the RPL network (router or leaf) places the RPL = headers and flow label in the packet, either in tunnel or transport = mode. Aren=E2=80=99t the flow label and HbH header mutually exclusive? = Shouldn=E2=80=99t we force the use of the HbH within the RPL network? = More alternatives mean more complexity. Why would a source inside RPL = use tunnel mode? (see also comments below)=20 [Pascal] -10 allows both but it seems redundant. Since the instance has = to be in the flow label for an end point to indicate it, then why not = let it there all the time? If the ingress router has to figure out the = instance ID by some magic, in any fashion it can place the result in the = flow label. =20 b. For packets originated outside the RPL network, the first RPL = router (called ingress router) has to place this information in the = packet in tunnel mode c. Further RPL routers find the information and use it. They do = not re-encapsulate, they do not change the flow label, they happen to = modify the RPL headers. In non-storing mode, how does this scenario work? Host =E2=80=93 RPL ingress router (must include HbH)=E2=80=A6 RPL = routers =E2=80=A6 RPL root (must include source route in addition to = HbH, can it do it in the same IPv6 header?) =E2=80=A6 RPL router = =E2=80=A6 RPL route (decapsulation) =E2=80=93 Host [Pascal] In non-storing, the nodes will always tunnel to the root. The = root decaps, and route the packet; if the destination is in the RPL = network, the root reencaps, this time with a routing header. d. The tunnel endpoint decapsulates before forwarding the inner = packet. This strips the RPL information from the packet. If the packet = is reinserted into the RPL network then there is a risk of a loop.=20 =20 =20 =20 2) A destination is in the same RPL network if: a. The destination is the root of the DODAG (all modes) b. The destination is in the same Subnet as the source (derived = from a PIO) (storing mode only)=20 c. The node is a router that has a DAO state indicating that the = destination is a child (storing mode only) d. The destination has been seen as tunnel endpoint and thus is a = DAO ancestor (storing mode only). Not sure what you mean by the last point.=20 [Pascal] trick, and actually not tunnel endpoint but transport mode = endpoint. A node does not know its ancestors, so it would tunnel if they = are not in the same subnet. But the ancestor knows the grand grand = child, so it would use transport mode. So we end up with a triangular = routing where the child tunnels to the root, the root tunnel to the = ancestor, and the ancestor uses transport mode down. if someone uses = transport mode with you, you can use transport mode with him=E2=80=A6 If = you care to implement such optimization. =20 =20 3) A RPL router that injects a packet without the HbH option into = the RPL network is an ingress router. =20 a. An ingress router MUST place the RPL information in the packet = in tunnel mode b. An ingress router MUST place the instance ID in the flow label = of the outer header c. An ingress router MUST use one of its global addresses from the = RPL domain as source d. An ingress router MUST use a tunnel endpoint that is in the same = RPL network (rules above). Doesn=E2=80=99t d. contradicts =E2=80=9CThe last entry, Address[n], is = exempt from the strict source route policy and may specify a destination = outside the RPL domain=E2=80=9D from the rpl-routing-header draft? I = think this also impact your point 4 and 5=E2=80=A6 [Pascal] The texts does not apply to RPL but is apparently safe in = routing headers at large. RPL cannot use transport mode to an external = destination because of the use of the hop by hop option. =20 =20 4) A RPL node MUST place the RPL information in every packet that = is sources. It can safely use tunnel mode for all packets. It MAY use = transport mode when it determines that the destination is a RPL leaf or = router within the same RPL network. In transport mode, the outer headers = are built as follows:=20 a. The source MUST place the instance ID in the flow label of the = IPv6 header b. The source MUST use one of its global addresses from the RPL = domain as source c. The destination MUST be is in the same RPL network (rules = above). =20 5) The tunnel endpoint is determined as follows: a. If the destination is in the RPL network (rules above) then the = endpoint is the destination b. If the destination is a host attached to a RPL router then the = endpoint is that RPL router c. Else the endpoint is the root =20 It appears that the b) is not supported correctly with the current spec = since we do not have a way to inject a route to an external host while = indicating that the host is not a leaf. Probably the router would present itself as parent in a transit option, = with a bit saying that the targets as non rpl hosts. =20 [Pascal] Thanks a bunch for your comments. Let=E2=80=99s keep the pipe = more open than ever since we are in last call now! =20 Opinions? =20 =20 =09 Pascal Thubert IPv6 Engineering Product Development pthubert@cisco.com Phone: +33 4 9723 2634 Mobile: +33 6 1998 2985 Cisco Systems France Village d'Entreprises Green Side 400 Avenue de Roumanille=20 Batiment T 3=20 06410=20 BIOT - SOPHIA ANTIPOLIS France Cisco.com =20 =20 Think before you print.Think before you print. Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 responsabiit=C3=A9 = limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum = Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, = 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel = Givone, For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html =20 =20 ------=_NextPart_002_08A6_01CB2422.033D0610 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Pascal, All,

 

Let me know if this is a correct summary of the possible cases. I also put = some comments to point things where I think a clarification is = needed.

 

1)    = RPL S = =C2=A0=C3=A0 BR =C3=A0 = D=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 No tunnel, the RPL source adds the HbH header, BR removes = it

2)    = S =C3=A0 RPL R =C3=A0 BR =C3=A0 D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tunnel. R = introduces new IPv6 header with HbH header, R is the IPv6 source, BR the IPv6 dest. BR removes this header. =

Comment: If BR is the end of the tunnel, its address needs = to be known by R. How does that work? This would favor an approach where the = DODAGID must be the global IPv6 address of the root

 

3)    = RPL D =C3=9F BR =C3=9F S = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Tunnel. BR introduces new IPv6 header with HbH header and RH (non-storing mode = only), BR is the IPv6 source, and RPL D the final dest in the RH. =

 

4)    = D =C3=9F RPL R =C3=9F BR =C3=9F S =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tunnel. BR = introduces new IPv6 header with HbH header and RH (non-storing mode only), BR is the IPv6 source, and RPL R the = final dest in the RH. R decapsulates and sends to D.

Comment: This would work if R sends DAO with target D and = transit =E2=80=9Cthe parent of R=E2=80=9D: I think this is a bit different than your approach = in 5b. Also, I have the impression that according to =E2=80=9CThe last entry, = Address[n], is exempt from the strict source route policy and may specify a destination = outside the RPL domain=E2=80=9D, D address could be the last address in the RH but = I=E2=80=99m not sure how this would work. If this text does not apply to tunnel mode as you point = below, we should say so.

 

5)    = S =C3=A0 RPL R1 =C3=A0 BR =C3=A0 RPL R2 =C3=A0 D = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Tunnel. R1 introduces new IPv6 header with HbH header, R1 is the IPv6 source, =

BR the IPv6 dest. BR removes this header. Encapsulates with = new IPv6 header with HbH header and RH (non-storing mode only), BR is the IPv6 = source, and RPL R2 the final dest in the RH.

Comment: I guess this vision contradicts your point 5a. = Seems simpler to me, but maybe I=E2=80=99m missing = something.

 

Note that if the above is correct, the only information needed by RPL nodes = is the global address of the BR (i.e. the root). So it seems that 2 below might = not be needed

 

Best,

Mathilde=

 

From:= Pascal = Thubert (pthubert)
Sent: vendredi, 9. juillet 2010 17:43
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] Use of tunnels and end point = determication

 

 

 

 

Anyway it appears that the spec could be clearer = in:

1.       Explaining why IP in IP is used in = general

2.       Specifying the rules to determine if a = destination is inside the RPL network

3.       Specifying tunnel mode operation

4.       Specifying transport mode operation and when it = can be used

5.       Specifying how to determine the tunnel endpoint = in tunnel mode

 

Proposal:

 

1)      RPL needs an instance ID in the flow label, and = HbH header, and eventually a routing header in every packet for routing and inconsistency determination. The HbH and RH are nonsensical outside the = RPL network and can only be present inside the RPL network. The only clean = way to insert and remove those headers is to use a tunnel mode (IP in IP encapsulation) whereby the router places the RPL headers before the = inner header, leaving the original packet untouched.

a.       A source inside the RPL network (router or leaf) places the RPL headers = and flow label in the packet, either in tunnel or transport mode.

Aren=E2=80=99t the flow label and HbH header mutually exclusive? Shouldn=E2=80=99t we = force the use of the HbH within the RPL network? More alternatives mean more complexity. = Why would a source inside RPL use tunnel mode? (see also comments below) =

[Pascal] -10 = allows both but it seems redundant. Since the instance has to be in the flow label = for an end point to indicate it, then why not let it there all the time? If the ingress router has to figure out the instance ID by some magic, in any = fashion it can place the result in the flow label.

 

b.      = For packets originated outside the RPL network, the first RPL router (called ingress router) has to place this information in the packet in tunnel = mode

c.       = Further RPL routers find the information and use it. They do not re-encapsulate, = they do not change the flow label, they happen to modify the RPL = headers.

In non-storing mode, how does this scenario work?

Host =E2=80=93 RPL ingress router (must include HbH)=E2=80=A6 RPL routers = =E2=80=A6 RPL root (must include source route in addition to HbH, can it do it in the same IPv6 header?) = =E2=80=A6 RPL router =E2=80=A6 RPL route (decapsulation) =E2=80=93 Host

[Pascal] In = non-storing, the nodes will always tunnel to the root. The root decaps, and route the packet; if the destination is in the RPL network, the root reencaps, = this time with a routing header.

d.      = The tunnel endpoint decapsulates before forwarding the inner packet. This = strips the RPL information from the packet. If the packet is reinserted into = the RPL network then there is a risk of a loop.

 

 

 

2)      A destination is in the same RPL network = if:

a.       The destination is the root of the DODAG (all modes)

b.      = The destination is in the same Subnet as the source (derived from a PIO)  (storing mode only)

c.       The node is a router that has a DAO state indicating that the destination is = a child (storing mode only)

d.      = The destination has been seen as tunnel endpoint and thus is a DAO ancestor (storing mode only).

Not sure what you mean by the last point.

[Pascal] trick, = and actually not tunnel endpoint but transport mode endpoint. A node does not know = its ancestors, so it would tunnel if they are not in the same subnet. But = the ancestor knows the grand grand child, so it would use transport mode. So = we end up with a triangular routing where the child tunnels to the root, the = root tunnel to the ancestor, and the ancestor uses transport mode down. if = someone uses transport mode with you, you can use transport mode with = him=E2=80=A6 If you care to implement such optimization.

 

 

3)      A RPL router that injects a packet without the = HbH option into the RPL network is an ingress router.  

a.       An ingress router MUST place the RPL information in the packet in tunnel = mode

b.      = An ingress router MUST place the instance ID in the flow label of the outer = header

c.       An ingress router MUST use one of its global addresses from the RPL domain = as source

d.      = An ingress router MUST use a tunnel endpoint that is in the same RPL = network (rules above).

Doesn=E2=80=99t d. contradicts =E2=80=9CThe last entry, Address[n], is exempt from the = strict source route policy and may specify a destination outside the RPL = domain=E2=80=9D from the rpl-routing-header draft? I think this also impact your point 4 and = 5=E2=80=A6

[Pascal] The = texts does not apply to RPL but is apparently safe in routing headers at large. RPL = cannot use transport mode to an external destination because of the use of the = hop by hop option.  

 

4)      A RPL node MUST place the RPL information in = every packet that is sources. It can safely use tunnel mode for all packets. = It MAY use transport mode when it determines that the destination is a RPL leaf = or router within the same RPL network. In transport mode, the outer headers = are built as follows:

a.       The source MUST place the instance ID in the flow label of the IPv6 = header

b.      = The source MUST use one of its global addresses from the RPL domain as = source

c.       The destination MUST be is in the same RPL network (rules = above).

 

5)      The tunnel endpoint is determined as = follows:

a.       If the destination is in the RPL network (rules above) then the endpoint is = the destination

b.      = If the destination is a host attached to a RPL router then the endpoint is = that RPL router

c.       = Else the endpoint is the root

 

It appears that the b) = is not supported correctly with the current spec since we do not have a way to = inject a route to an external host while indicating that the host is not a = leaf.

Probably the router = would present itself as parent in a transit option, with a bit saying that the targets = as non rpl hosts.

 

[Pascal] Thanks = a bunch for your comments. Let=E2=80=99s keep the pipe more open than ever since = we are in last call now!

 

Opinions?

 

 

= Pascal Thubert
IPv6 Engineering
Product Development
pthubert@cisco.com
Phone: +33 4 9723 2634
Mobile: +33 6 1998 2985

= Cisco Systems France
Village d'Entreprises Green Side
400 Avenue de Roumanille
Batiment T 3
06410
BIOT - SOPHIA ANTIPOLIS
France
Cisco.com=

 

 

3D"Think= Think before you print.

Cisco Systems France, Soci=C3=A9t=C3=A9 =C3=A0 = responsabiit=C3=A9 limit=C3=A9e, Rue Camille Desmoulins =E2=80=93 Imm Atlantis Zac Forum Seine Ilot 7 = 92130 Issy les Moulineaux, Au capital de 91.470 =E2=82=AC, 349 166 561 RCS = Nanterre, Directeur de la publication: Jean-Luc Michel Givone, For corporate legal = information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.h= tml=

 

 

------=_NextPart_002_08A6_01CB2422.033D0610-- ------=_NextPart_001_08A5_01CB2422.033D0610 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahAST7V/3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L8OpvbV6Ly3WpD7HxVvyWoZOWD40gGTtkZFfTJGnok8g 3137O00SA6kuTJ/LAAKpaX9aaLCRpGWGEziLfjMSgVNvUklRM/uCfUXleQTkkv2mYjExjM98vRH7 TwwskFN+3COA5M/KZrsvINk/5i15BWUVEkixOmllsjPOUfMxn1AkZOT0GkSEJKTivXUHxE1/eoG6 MK8cVQ4UkFoOvnhhyWZhshmEr/cY9wpkdV09QsksWpCp58VSVVfXK5DLfjcT42AgWRMfsPUaMCC9 zicIrcj3hWv37Gf7RffsznCQlZSZh+Onw+AWFosiCg6HwK76PxZIjgJt/MJFILFglyF2UATa226c oQRkI5k6X/Jf2S+cv9NARLfeEQlQ9LABeKgByWmn3465YiHd938fOAqr06FCOdzQQF4iU8d+1eUJ 2oTXl+/AUa9glQCSc4jbLZzF659b/AueI8A2mdj3qCWHGpDc18QVuzCGxjF60UbhLydl5d3YQCZn FWDmFi08/Nlq4bONJGdfx+mMSgBZQ0CuJe342Bdq1Pc6PPq5GlZpHhOVGFUA0pgifPZjH5+7lu7/ T5ix4Qji0rJvbCBTcgoxb6e+CFIYgrHLtsDILUAlgKwlIH8hjciwMGC8Z5HNN+cbVQFITnGN//c2 oQT4Gp9v0xGbgm94IOfs0CPtuFZA8MLSzTB09e/x9cHxqe1R9oLBi7JH9SPKZiA3GNsJEBmwp6n/ NXonegXyyij790GJstXps6r3GWVzkn7ct1sxgoDkzzp7q7Y4EHdDA3kxuxBfbtfFE3PWipv+/JJN MHDpDcihk4dkINcbnRLjGCW0zDqo6dr0CORg5yE9WvOQT/YzD2nmESws0oiFl3fTzyLXiQOdGxpI zoHxacAxpC1YK/GBJusz4T2+PuJipjgXI6oR1GYMcKXmqGeIKBuKSs3Xv+BHrZ4rNZyeYqDGf7tN vH7c0i3YZeUqUkHdyeVKzQkKfjaJSgpXagxdAwYMyMDYi5i5WUuMhfv/bKuOSEn1JLyBhM8bjfpq PZ75aqOItFNyCm5sIHljhI7jGUxXPyRA4E0HIWSWexKuZe+ydBU3kuHdYGTXq99ztUD6xySLieGx sJNv6BKAsh5q2by7xjEoCnN36Ito9YttujgVEIGGHvKorDnNPILw8UYNTCRXg4/mno5MHDAgL2Tl Y4upA976ca/QjnzCMjWn51p2eFI6VlIQxn74++sOknXwQUHpH54g/2OBrG1oQBCZYU6XLD9kCTPP oF7PHnM1xD0sDmt0T1BEe1wAV1RROWBA8hFZPv/8/UELbDNzFMdOe0rUc7ktISMPh0564bsD5vjd xgNx6dk9Ph2DE9F8wIw3PfyH+tdz9sOlXjY/XMtuH8fgKKwmrf6TtjX51tFi+1xPwnsyLbxDxM6m jbSw/WMuoKbuD38QwdCo1PiSr8N7BC9k5fVaqeGaMQcHbgSlU3C0MPm97YfkU4cvdzh1+H4fpw45 t5iQnotT/ufhH933fkg2zwy4rd85hCWloaq250oNA8wPKQiITRZP0Yjr40kUfOrwQ3HqcK0InMb1 cepQ0fqkC+eQGLiSX80PSWhs6rnG3tDYSD58PuwDI+ETkSisVXPzDV6pUUopTRRvKOWb1Ke07oou 6MeOcceQKHL09wgNyVByJBmVktnre9jk8mSW9XPbWQ1BmVNUiqoefMfutHxOUVmfdXsOML78VZei d3WhISet2A1bArmvBV7QtmO8b7i4qsQLvPSPr9AMLSCVGqT/r+3f69kf5ceQcL6Nj8OqG5zs1x7B q63pDsbrM8hfZlPK4+bAadFuIwTEXOzXfby6ezmkDjv8uU8d8g5wbQdfEZl/s8cYNhTBD4F6bb+E 3QXWiEtoQbGmPEJBx6Xcoj/rVN0YQFbX1+Mc+Xi6TmdEhJtMPlPDAB1JGGxhc3qRomRzz2CRiQjt w0eVQKqAsDli3463taUQjIpG1YCxDUoKVFJzCoQ/yWmjIWZeJZDXPLEEYmOTajwX8kppoki5QcUW kgRSigRSihQJpBQJ5FCWpro6NNbUoImiafF9dTVaBtFX5Osor9d4nddrVijE+5tqa0Xj75sbrr50 J96rHBN9VVRVoUV1fU7VA5LjzCaauKqsLGT7+CDNwQEZLi5Id3Ki5oyiyEgxMS3d1ZT5T2zQxDWU l6OuuFg0/p5hbunlKGtzYxOq8/KQc+ZM+/WcnZHu6IiCc+fQUFmF5n6C2Uyw1JWUIC84RIw5w9VV tDT6Pi8wUIypP0Dx9apzc5HNY6JxiDGJ5oqiqCjxmSSQg60RFY0oTknFBTt7BG/7FW7z5sH+rbdw auJEnJowAQ7/mg6/1auRameHusLCTiAqNSpP4Fl1dbjNnAlXasFqashwd0dDRfc7Xero5xkBgQjd tx/uCxe1Xc+OmuP778Pn++WIMTFFceKFXrUlp2wqc/OQ5u2NcwcOwHPJUjh+OAP2770vGo/de+ky xBsYojQhkYBr7nFBcj85gUGI0dGF97ffwf6dd2hMk2BH/bh8MQdBGzYilRZO2aVLaFKRvzqhckDW k9ZLP+2LgLXrcJJuvNnIUdC/915o0vAPtzatm2+G2ajR8P1hJUoSEroAqaisRLyhIazHjcMBev3v 1KxGj0bUwYOoKei6F7CKJj7xuDXcF30N8xfGQv+v90OD3nOo9Xp8bd37H4DNm5ORdNwGjT3UpxvJ POfHxOLcoSNwmj0bFi+8CIMHHoT2rbeK/rhp0tiNHn0MzrM/Q4qDI7kEXWvjjGjRhWREamrBkxbH CYLQ+LHHoUXvP9I6Hv17/wrzMc/Cafp0BG/ajAzfM+JzSyAHSJilOrqhKR4ecFu0CEb33Qdtmjxd GrZ2a9Np/coTo3PHHXD84kvkR0R06YsnJtHMDKcmTRKTxyDYjB+PGC0t1BR1LsvVV1Uj2d4B9h9+ BP177hHX4MbX1Rs2DHoEk95tt0HjlltgRAsj6vARKBSKbrS6Ajlk1v02boLFuPHQoffpdBiz8nvN 1v9bEWQxZkehuOJBUax9C2PjELx9B4699jr07rhTjKXjZ9fq0Kce3SPjx/4Oj0VfIZ1cgoYKlYBy 6ANZT85+iocnXOfOJa3ygJg4rQ4wGhAspqQtTZ58SkwQ/85+1izknT/fVUOSw59kbg67yZPbJtH2 tdcQq6OD2iuAZE0U8MsmmDzyqABXqxVG85Ejcep/34MdmVtu5i+NFxovzsCoi5llPy+XfFrfn3+G 2egx0CKQO45d7847YfzEkzAbMQp6d90lfmfx6muINjahsbbX3Hn0ZWlpCFr3M0yffho6tBA69tO2 MIfd2gVQo4ceggdp00w/f+HySCCvU0oupuC02loYPviQgFGn9UazdrImTeH17+8Q/OsOAY87+5TT P4Cf+noUKU12h0fK9hdIDjxSvX3gNIcWAWkiASNdz3zMGASsX49Udw/yBX1wydMbscamiDiiibzQ cAqMOpf26ihgCj+iAbMXx3ZaSLq33Q6L51+A64KFCCCzyuP3WvYtHD/6GB70NZlNdofjtHU07sST drAhWA937Ie04NGnR8Bh2jR4z5sPD/r8J96YDCNauErNy4vJ5O+PI5Q0a0V6hgTyeoRTI6nOLjgx 5S1ok2lUmkxd0ia25LdF6ukjLzoGFdnZKCUHPvfceaS4uSHd5zSq8wuuGcjG+gYy146wJ0CUQLI2 s546FbGmZqgpKRWmWIyRIGwgbaaore0UqQsTS36j+1dfQ/d/7mo3+bffAStaSEE7dyEjKBhlBEl5 Zhby6XOk+fggxdUNRXHxaOrgjxbGxcFnxUoBltIkM9RWpJn91TfgEpnk0thY5J89i2gjYziSH2pE vq0OActjN7j9drh88gnS3dwlkNcjFTnZCNv9G0zJ2VdqR30C0/bttxFF0WgVBSLKIwMiHUQQMBgM SHM35qnfGpL6zPDyhvuXX8Ko1ZTq0nWNyfy5z1+IWHNLZIWEoDInp8cjC7VlZUi0PoGTU6Z08nUt xo4VMBYlJ3cKgrgfBaekaIyNDHfrIuJ/OWI+PnYcNG+97bJ/eNPNMH/+RQRt2UqWIFF8Zl50zY0K VBcWId7qGOw/+EC4M8rrmj/7HKK1dXpNb0kg+xCOTE+v+AFGd98jgORmQKYzkHypiryrPyHXG5BX BjWlBEyg2hro0/UOdQg+TB76G6wnTITzp5+KFFPCseMoy+y6C521dtiBg6TFXmgPuG6+CW7kBuRG RPZ7zA2krWP1DWD24IPCXGuLRTmMFsYCZIV2f8aGNW7Yvn2weOaZNvOuf/+Dwmy3DO1NJkMbyGwy wZ7kIxrdc6+4sewPGZLpjNPSvqb+rgbIBtI6yba2ODV5CvTJf9XpECi0TfLdd8PmrbcRums3iuMT hO+plLL0dATTz4+OHt32Hl0CMkhNTSTS+yu15RWI0tTC0UcvB1fKRRmyYSOqCrvfsKuoq0eykxNs 33ijPSC7626c3bxZAjkYQMbr6Q06kGwqawoLkeLoCO8fVpKJfF6Y7SsjW23yCS2eegrh5FqUZ2V3 BbJVSymj9OC1a7vNMfYKpIZm90AWFPYMJI3bdtKkdiD/8hcJ5PVKPjnzvitXdTbZ5KCHbduG2tKS q+7vaoBse09DA7kOMYg1MYEfjcV15iwcI8j0WoHUaP3q+PEnuESRd0trZaSC/MvwQ4dh9eKL7Sab mvfX34jMQX+lvrZOVGRMSUsrI2z9YcPg881iFEZFdfueitw8hB08CMsxz7YtBr377sNZum8SyOuQ 8qwshFIAYPrY39sSx5yUdvrkUzJJzqjv5q8McO6PI+A2573DLutrAbKjcBCVExyC0C1bYDFylKi0 6LSmX46TXxljZCI2XVzWbOXCv7TloIZ+r9SoNhMmiOxAZV7XR9/x4S8euzD9ynInfZ5k25M4xqkj up4y3WPzyiuIOnCgPZvQKuxqXHR2pUh7Ngzv+2vbdY1Ji587eEgCeT3SQMAlWtvgxJSposKh3Wr2 OP3hsWSpSJFw8FBXVi6AKk9LR35kFAqiY1BPUe7lWW7uV9qnE5AcsfJuHN6Jc8UOHAYmOyAQDp/O hF5rFMtjsnr5FUSSJmuovpzQ5hpyFsHLuUY98jWVKSsDgsRuxkeIPWqOkpRU1JaUoo5aBZn7wrgE 5J6PoKAks5M/yp+J863GjzzSXt2543acevNNJFhYojwjA/Vk2vl9XNHy+n45TB9/XIArFjHdO9t/ TkMSgT3Ej0EMbSA50VwYGwvfFStgQlGm0uzxjTYhrWk/7V0ErN+A89o6IqINIL/K8z/fI3jHTpQk JbVryKvMQ7J2rSDtnO57hibxFC66uiMrLAw5ERHIpwg5ljSc9auviTKlEhCrV15FlJ4BFNXtFZaq /HyE790Ly2efbYvSuRnefz9s334HvmvWIvywBs4d0RApHM418s9SXFwvp3JahRdckpUVbF9+uc1F EPlF8qdPvvEm/Fb9iLC9+0VxwHHmTJgNHy7ukbIkafzwI/Bf9zMKO9b3JZDXqCUrKpBC0a7jv6ZD lyZA84qgwvjRx0S5zXzsOBjTROiT828/azZyw8I6abyrAVKU/MLDEbR5K+xnfAx78hs9li4TzYt8 NzuKXg1I67T5Z1w/J42Z4uLWSaOKfoKC4LNsmSjhaXTwJTlpbchj59Lj+Jdh8vQIGJAGtJw4SeRY OR/Z4QOgPDkZAatWweChh7qUT9k0m416BibDn4IeBVlaHaDVv/c+OM3+DJfc3NFQM+T/kJJq7Pap zssn7aMvEuIGd7VXPbS621xB0Dp+/gXyzve8ueLkxIntmyteeklsrrgyMZ7l5wcv3szBEf4tw0Q+ Utn0Omg7vdtuxzHSjudIQ3P+78q/fMmbJHj3jsucuTB8/Anq65a28XbZXEG/s5wwCTGmZl02V7AJ T/cPEK6KCe8UojHpdFPP1u5QVuRyqyMtJnZ7aopLhvo0qw6QLBU02fHmFnCnKNX8pZdFOU6jddvV kQ5b0HTvuBNui5eQPxbfFUjStvFGRrAePx4H6bW8Bc2KIuaoQ4dEiqddobYgkzSb6/z5YnL3t245 69j42kYPPwy76R/i7O49KIyJExt5u5Pa0lKkkobyXbMOx96YDIMH/9Zp7Nx4PBoEmc277yGR3ITG bp77U09mPIv81wAy69Zk8g3IjdHs0IcyLcT50WOvvw6v777HhVP2qC0uVoUpVi0gxcRSoJIZFIwI HT2cJsfd8Z13YE/m12HqVNhTNMum2HPefAFuFWnVK4W3++f4+yOMomTPOXPgQe3s+vXI9PJCwxV7 BkvT04VWdp0xQwQPfA1l4+s4krYOUFPDBXsHFJM5bVL0/qweRW0d8mJiKZixQID6ejiTibejYM2B xs3tJPXpPOszEQkX0Ot6Kkky9EWJSYg/bg2/n36C07RpbfdA9EXj8l68GNFk9rNDw1BXPmT+Bs2f D0ihvWiimkh7VFF0nePri0xXV2QRUJkUXWa4uaE4KupyLbiHIwwieuazJwQgN/6ef3alqeX3sxnP CwgQRwz4GsrG1+HjE5UU3bIp7W/g2tKa1qkjjZkfGir6yfL0FI2vkR8SIn7X13EIUbenfqpzcsSx io73INPdvfd7IIEcPGEY+FgCBxLioFd9/YBfo6XjNZSNrtPch0bse/DNnfvlcz3XkCPscg84D6q6 T7iQx2ClSCClSJFASpFASpEigZQigZQiRQIpRQIpRYoEUooEUooUCaQUKRJIKRJIKVIkkFIkkFKk SCClSCClSJFASpFASpEigZQigZQi5Q+U3RJIKUMSyF2yyTYE2nsCSP5HNtmGSvs/hQgkdONYbE8A AAAASUVORK5CYII= ------=_NextPart_001_08A5_01CB2422.033D0610 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------=_NextPart_001_08A5_01CB2422.033D0610-- ------=_NextPart_000_08A4_01CB2422.033D0610 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxNTExMzEyMVowIwYJKoZIhvcNAQkEMRYEFOQbKhoSbjtH3vAK pYoSEkijheDvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAADnfcLkrGa0ZJOxmhOgJl2KnJa3HxMz+ CYBli5+Kip6H4q+VrWDGEaqL06IIMPCNh07wpzAIOF+AAZSVC2Y+bLpgl1rPJIxJqXvDJXd8vgPz lSbYmo9WOa69rRKpVsjbdIsMsZS4mfp1tsnpCT+d3AE0elQGif35Y6mpRAhCcp0AAAAAAAA= ------=_NextPart_000_08A4_01CB2422.033D0610-- From yoav@yitran.com Thu Jul 15 04:36:31 2010 Return-Path: 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 02D803A687D for ; Thu, 15 Jul 2010 04:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 lmneIgkGGEFm for ; Thu, 15 Jul 2010 04:36:29 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 6782F3A68BD for ; Thu, 15 Jul 2010 04:36:29 -0700 (PDT) Received: from source ([209.85.161.50]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTD7yxzwQ2K5hCdO0OJFLdtS+Y60M3aHt@postini.com; Thu, 15 Jul 2010 04:36:40 PDT Received: by mail-fx0-f50.google.com with SMTP id 9so410941fxm.37 for ; Thu, 15 Jul 2010 04:36:39 -0700 (PDT) Received: by 10.239.144.140 with SMTP id o12mr1418413hba.119.1279193799554; Thu, 15 Jul 2010 04:36:39 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskEfsTogP/oKQQQVaHr6aSHNRFfA== Date: Thu, 15 Jul 2010 14:36:35 +0300 Message-ID: <12cf580a3e0d76cc82bcd02df6ae3390@mail.gmail.com> To: ROLL WG Content-Type: multipart/alternative; boundary=001485f5cdf80576f6048b6b84c8 Subject: [Roll] question about DODAGID field 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: , X-List-Received-Date: Thu, 15 Jul 2010 11:36:31 -0000 --001485f5cdf80576f6048b6b84c8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, From: =93 5.3.1. Format of the DIO Base Object =85 DODAGID: 128-bit unsigned integer set by a DODAG root which uniquely identifies a DODAG. Possibly derived from the IPv6 address of the DODAG root. =93 Seems like quite a lot of information to specify the ID of the DODAG (I don=92t expect so many DODAGs will be used per RPLInstanceID). Is it too la= te to request a way to shrink this field? BTW =96 is it worth mentioning that in case the DODAG root is replaced, it might be that the DODAGID will need to change, so the IP address to derive from should be from the IP address of the node that originally formed the DODAG. I realize it says =93possibly derived=94, but this use-case could be something that is a little annoying to discover after deployments are out. Thanks, Yoav --001485f5cdf80576f6048b6b84c8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

From:

=93
5.3.1.=A0 F=
ormat of the DIO Base Object

=85

=A0=A0 DODAGID:=A0 128-bit unsigned integer set by a DODAG root which uniquely

=A0=A0=A0=A0=A0=A0=A0=A0 identifies a DODAG.=A0 Possibly derived from the IPv6 address of

=A0=A0=A0=A0=A0=A0=A0=A0 the DODAG root.

=93

=A0

Seems like quite a lot of information to specify the= ID of the DODAG (I don=92t expect so many DODAGs will be used per RPLInstanceID). Is it too late to request a way to shrink this field?

=A0

BTW =96 is it worth mentioning that in case the DODA= G root is replaced, it might be that the DODAGID will need to change, so the IP address to derive from should be from the IP address of the node that originally formed the DODAG. I realize it says =93possibly derived=94, but this use-case could be something that is a little annoying to discover after deployments are out.

=A0

Thanks,

Yoav

=A0

--001485f5cdf80576f6048b6b84c8-- From m.pouillot@watteco.com Thu Jul 15 05:09:18 2010 Return-Path: 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 A69B33A67B5 for ; Thu, 15 Jul 2010 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.578 X-Spam-Level: **** X-Spam-Status: No, score=4.578 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DC_GIF_UNO_LARGO=2.275, DC_IMAGE_SPAM_TEXT=0.001, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_32=1.778, HTML_IMAGE_RATIO_04=0.172, 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 3vVVvUJT7um4 for ; Thu, 15 Jul 2010 05:09:17 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 0A0353A683A for ; Thu, 15 Jul 2010 05:09:16 -0700 (PDT) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id XTY18724 for ; Thu, 15 Jul 2010 14:09:24 +0200 Message-ID: <4C3EFA71.70207@watteco.com> Date: Thu, 15 Jul 2010 14:09:21 +0200 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org Content-Type: multipart/alternative; boundary="------------030001000005000602080102" Subject: [Roll] multi gateway in a RPL nwk X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 12:09:18 -0000 This is a multi-part message in MIME format. --------------030001000005000602080102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello All, We are working on an architecture on which it is necessary to have two gateways to link our RPL-(W)SN and a LAN. The goal is to have a redundancy of gateway if one of them crashes, And to select the way the most efficient according to the selected constraints. In the scenario where we have only one root, we are not able to go out through the no-root gateway: all exterior addresses of the RPL nwk is routed through the Dag Root. I see just the solution with a multidag ( each gateway is a Dag Root) involves more memories... Are there other possibilities? best regards, Mathieu -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com --------------030001000005000602080102 Content-Type: multipart/related; boundary="------------020308060900070900030102" --------------020308060900070900030102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello All,

We are working on an architecture on which it is necessary to have two gateways to link our RPL-(W)SN and a LAN.


The goal is to have a redundancy of gateway if one of them crashes, And to select the way the most efficient according to the selected constraints.

In the scenario where we have only one root, we are not able to go out through the no-root gateway: all exterior addresses of the RPL nwk is routed through the Dag Root.

I see just the solution with a multidag ( each gateway is a Dag Root) involves more memories... Are there other possibilities?

best regards,

Mathieu
-- 
Mathieu Pouillot
R&D Engineer
m.pouillot@watteco.com

Tel : +33(0)4 98 01 60 05 (Poste 43)
Fax : +33(0)4 94 14 10 80
1766 Chemin de la Planquette
83130 LA GARDE - France
www.watteco.com<http://www.watteco.com/>
--------------020308060900070900030102 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhoAJaAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALFMA GAAiAjEBhQAAAAAAAAoEAAAECg0IBAMGCw0KCAMAAAAAAwgKDQMABAoLDQsGAwADCAsLDQQE BA0LCwgDAAAABA0LCgQAAAQABAoLCgQAAwQIDQMAAwMDCAsLCwgDAwsLCggICAoEAwMDAwAE CAMDBAQDAAMGCgAEBAoKCAgGAwoLCwgDBAMECgQGCAMGCAsKCAQDCAgGBP///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwb/QIBwSCwaj8ikcslsOo2B qHRKpT6v2Kx2y+16v+CwuFmNjs/otHrNVlJh8Lh8Pre27/i8fs9nRulwZn2DhIWGU4CJinRT ho6PkJFsAYuBAU4CA0MEAQVDmQYHUwgJQ6FRmkWnUp5PBgoLkrJ5UpW2t5aXs7u8vZF/uLpL DA0OQgIPqRARBa+xQgSkAAQSscupprBCExStvt96tbjjwYLg5+jpXJTkMMJJzgATFRYVsRMX CfFCyxjcGKYylMr2bFo1dQjDAGvH8Ja5hBAjpmPX7t2RfwAMaNjAoRSBYvsA9KNW8EhIfKW4 BTgYr1+8VQDlUVhZUiKkhQ1z2npos6fP/0M5LR4R4IlB0aKaQpL8aAyeNn4RMPQDQMzBVI0O nGF0NrXqz0MUdYrdKfSr2bNowlZcQkCTAIBM32YUJUUaUyUhXWpDSVWT0Yyw7hKUlw/tHpxj E1fiabix4ytq1+LV0MGePHqWQ2466LQgylUBpGnkWMqZV1N0Qw9sU6a16yqPIiuerajs49u4 icgmZ5sfBw8ajEH4HRxwTZkxkRNRWk2zkA/AjTkTLMT5nd1BwdLe7rB3btRTvH1Xhz3YEgEg vDF40Mo6VWnLii1/ys3T1aec2sPaKvD+8TTlMeQda9wV6NB4nW3TTR7uIehEgAcqEc1qnMTU ICeoGAFaAMmpJP/NNpYZN1cUMXm4GoHuvKYiMAOuAaGBBrZ4G3P/odGgg34kJiOOW7DzYm2B DPIjjAXu2NhJhWEYQCqnhBCVKiKM0JwoH55Ciok8YjFkbVkCGIhYPvaxJZHcGYlWXlFhNCFG DHCoygEAqVmNnAvc2CUSYzJy5xk+ghnkYWQGuliWaCZHWAJ3YbScQCJ+tlc+du5ZRJ51SCpG nzqFGY6gnHKJI5Kl0UWKV1PNF8tdI8mnV42WTgpmqwp9memfeFDaKW1m/kSjAYyilCgFhooY j6P3QPoUrEnYSiuy68ga1LKT3CotILn2tE99BsUiwJXAUuWmqcqRRCevJzILRXbmdoH/6bPu 0DLtu3FUa9OGMS0TBQlPnlJCYeCOWCWVpdgbbLpDUCovwUKs25CmKMIL78EI8oWwGnlCjLDC AkJLscMOW/wYudlO7CJvIvfo7MIap8Uxxx471qZqJbv4YssEY1xRynyu3HHMPMuciBQ9Z2Ez bzhfqjPLQSc9RmtKC31yxu1Ge/TDPq1odSNNZw3O0OMwvPHU79IM1Gxia222yu74GfXXMDoD yIRxhFJA3LCQWTYhyup59t6S+Hi1a0WDkbctbs+xTDJxH1ANHIUTebeYKf5dRuB8V+4urlK3 Xfccr5iw+SsnzA1D4zA+zgcleXtt+eqAYj4ykaTDwcAAMBDF/7gCKKSwwOibO94T6mqbzvrw bkhuNZ9vwN47HCjBwBTvC7QFfaBARwT8rGsTrz3binlchqvK7y7H8/9AP5w+y8eYMGNbp429 8NtvP3ilkMG2xPyLkG7vFLS7bYAKsSvSpNjHi+uxC37xIx7+Asc0p4VPDo0jV+EEsIL0CfAI 1fOFAVGWvQR6sFmuA8D3jKY58cEhE3MgSuFCsTjf3Y+AsXHfAT9IQ5PhCmuvM9CGWJCPOVDD cyZkQAtL94QM/kKGHERgDc22QMrlDGzTqpYRgZI6Jy7xik3sYK2geCuLTRFyVdTiFcdYsO0o MVlc7BTNvuiuMJ6RjDHL4hvxlEZO3f8Nh1t0Ixz3KEIzjq2ORKQYDJeGRKjNkY/pMt6KHJFF QMphjmw0mh4RScmqOfKCtBhksyZZyU5a75IhPJ0mtZQLRbLIk6iESCPTeMjirTGUqYzlN1bJ xVb6YZRugKUsd7kLWk7NlkXEJRRM6RpeGrMXvlwZMIUmzD6S7ZjQ7GUyo7jMdWhSjtHMpiym qUaJsFGOxdSmOFsHykVUE3nCkKM5zzlOYyKmnJZAizjIFqF22jOH8BTjT9RpHko2856T4Gb3 2Jm57klmj6gD6C8EGhSCNkxHC+Oj6hRaiHcq06EPHYutMNolilRrQyxJDYmWI1LxMCFSErVo F//5SVxlioz/aslVSAQAkmNpiD4LougwGRovlnqTmIB76RgjY6aQOONGNNIpnuZZpkjybHAc dZBsinqso9pUFceSmEpYoo1lVDAWMFEQTWKZvIY6NWnzi+p3sGOkmSZFpNiozrGm0pViXEUD LdhPt7jypNPsEqhqNUtal1ieHW1IP6wqVKMKMzuqNCMw8hmMxOwZ2NwMloYBMqw2QmGhq/br UCOKgmg20hHTRLY6qfnQPSt7m8t+EEIy2seERISEpFoHOsGZzmlpq1TWOgaqNZxZE2Za08Ti tBX+gUYnjMOfBCSXor41DHBf27WTZpUCA0CqSA2FJRCBdbN0KdFMVAtdzL6KutVV/2rVzIsu D44puuqFDHsFhN6Dxteb9SVZfvV7X/y6177xAyx8+0uG/ZpThAROcN9eC9uCDVjBAH3wVyz6 RQlDuJ0W3qf9lnrhDp8Oi0X0sIhrRdj6jfjEFAuu0FDM4qVhVgs+bbGMJ/Vaa874xlqqsbpw zOMCJ7BlMe7xiDNsPYUI+chQCPCliIzkF2vvcUxusnufnJYoS1l+CkzxlXssLwFveMIy2zKP pajL37FGzDjOld+AakXyXMfKaK6cmTZoSHnSIs4yNhKdb6ZP/9YKznhm4oMKyWdA4+nDgR7y oDkJZlEmWsQy2jPR+lxkIT3awy2SdNfaPJGKGvrScbwfof8n/ekkHwLUEPaOpoPBaXRgNMio PmZvVu2QVp8jqrCO9V/pyOh9blPX9y0LrXdi663NItfARqVQhr2YYs+ygMnurat6vd4Cllpd dog2Qt7BbHM6W4PPxpE4WIRsbR+mjNQ28yyvPeh4nYzdidYF6gT8bWS6eq11eFq5zX2dhJXZ JhneNzLz7W76DQUb+flEdkWq2lXEVSMtEGlIqWCow14Bpf29RBPhnbBt/5bgjzS4EU6DDGUw Qyl2Ocg1hmAU4mbFs4ORiUm3rNKIniXKAj8iyAv+yNruBTPFQl9B+qGojDDqfEaFBVKPRRI8 e/nLvlblzXcecpEPYSuk9UhxhzD/Es4UYQIueHlBrGpczxRmq9+1RlReEl6xel29G5fuT/dJ 9ar3fChHcWxfeLuU3W4iKcfKRGgz9Nl+1NUq+cqtXgHCV4D4VadxlzvALWl3aln97wCQS1wY z3CtN6UIcrE4b2869LU/qhSN/YtuP7/YckXYj5IHOKBjSuy7q4IylplHPdJuhKZ/PTPg7WzZ rw6p1JYm68Z5PGjI+/p/V/v52647Iy4vEuIIx/qjV1CHgNUWuT5jtksvCEluGx3jUCf70IV9 Y+Cd88s9DUjxQgJ61MMe7x+BAfCJQDEYIPxPbN3nz4Atz5VwzLVX/ZEvMCdO6sRxuiFPROZR k6ZPs6Vc//13BEqiCedjfwqSXQk4eN8iEzDjXfYXViDIfBhmRvF3c3j0OytYQDxXa/XGb09E TylYNeQWOT8VU+2nMhUTgzIYKy5FfdHnbmGxg9exGNFVc97GgGMWhEI4EXYXUxPxI76lhOv0 g4z0dIhALd60c1LYPvy1TYCFhYJ1YAlBe5Xng0cIYDfRXmRIeT9zhtNXd/BlMC7Ihm/YUmbo anNIhwPnhn0ThnnYhfUEhi/oh710XsfWT4P4O4xoiO+Xhqw1XdJ0hY3oiOk1S9IniYmoiNZW hEZ4iaeDh4t4iD/zhHijUa52VqJIHvSliaZ4ijWoc0LVioQFiPWjha8Ri7Kohv8ziIu2GGC6 KDlbFInwR2lCoorBWEmGxjXwN4nKuIwSZYMoA42eKI0wRY0LU4XXiI0gxoJA9Yc2543ZSHfj 2ImkSI46Zo6CWIrpqI5KVobtiI6PCI8qJlhWGH8Slo++aI9odXNlZIkIdmtI6I9DJVgDRFQW EXCIwYoGmWUIiUHZRmPk0YIP6WRRt2MXGW8R+QVMuJEQmZEeCZJoxn4uRpI012gniZJIxm7w 85E3MYwsSWIiyScKpH4zqWXQByDDg0056SI1yZOss2Zshow/qZGTR5OW44wwCJNOF5RAuZTG yGpR4x4TOBfeYB0OB5KlBkxOOYqjtmlV6VmHgw0s9Az/ztF0K8cGGDdmO3lnfMOUtacLWqkA QCRXoaOB2hcQrjcGbZlm6iYmcjaVTamXLOcW+pE7vLcZNWIlARMBKyAKC7ck1fcChPcSCmAB 45USM8ESUfJ2LdaVFRWXhDmXhgladzEdgFcS53d13UIS8eEA3AASBzgnC4KZddJVfQUScMJl gYk3eyOXzTaWNfErjAcLSGdTrWl/KEFXT2J4T7J3uImbhwIygJmUjHQ2wultxEkE+yMFq5kR AKScoAkNqhIVzgkQ0BkTTDGd4FUXQueWfhYbTFSaw0mXNmVUArEPFGRTRbcVp5eeIoGe0dlY 7rmYp8lin6ZWX4kik6QZgkcE/yr0FGdZBPj3mPJBJwIKncWAEWzSHEeHgLnJKpCGnb+gNdv5 jKg1BTxULj90LEJ0HBdIUjCzoQT6AFGgHlHAAvYgMCVYGh2IaSa6YE2TorL4YKWSbLMHbkpj pJZnlI6QpLrWjOEWNE46h0gancC2pFXaM1dKcA0qZFxqbFbaU0UZpr5ZabdWps53lCEmdW72 VDjppisGpx4XR8OIptd5p2cYR3NKp/Jlp30qMpEHqDAmqIjKLIVqqDk2qL+JLD7JqI0ap1C5 J5EqqW/Kp29pqX+KqX7gqCopKZfqqT5GqQApqp1Kqm6gqXZ2J6OqqvcDqrHHI4sKq596ayM0 Ybm6Vv8yaasPsjUqFYrhEKx66quWpkGFOISDYqwoemjIWo98CK3MiqfOeoeZGK3XOq1+Kmzi OI/W6q3aai4eRZH0+I60+IrhejG213Hfaq5tCIzpCitfOJDliq7daq/xKq96Q6/uCK/neo75 2ipTxa/9CrAFi68By6k/U4fR2K4Im7BZUliwWIsO664Qa1nLWrHg+q4Ue7G0mqyB2I3b1LAe K1XSyrH+irIGW7L4drKMRLL1urEsu34yW1Edq7EgO7O48V44uxMEmbI6K08rG0MP27OeErQY O7REm62QmLNIu37heK976Irl0FF5Kqkap4dTq6xmWKy6kaozmU7Ww1YLSqz/DShuZkpMf+Ic 38kkB5CVNiWlWFUSk3UFEToNy3UMkwmf4EGZvLSQOQh14DiR7GqyYUmV+FkTEbpyFTp6crsE dfsEJJcMUPFY4pdyahdXqbRskIe2h1uYozdZVpWXjqulTRC5TjAsQFedc5Um3VIdjEJW1Rph hvugcRsBmgsYilm6OJq3BvCZd4kh+xIqAeAk4jVWRIB1pDEN/zegGOB77pQs0jYeX1p1ift1 M+G35heeXKd/srlXvakV3XKhbOImhwd6efcXBsp01bCcmxurnduytlsjKrGayVkSpSJ4ILN6 h2KcrVcE3ad5xRB6nce8rCe7t6pQelq9BXe98LCf/5s1nvhboOFpWsaAEqSSL8Z3e5VxD6tr HdArSzvitb8lv8FjmNC7KsfwVd4ZnUQhLJB1wfngvzcyHOVnw8VhHf/5uswYqAqctPPbwpFV FfvQuFDBm8eZdmzCLY5nviJqBPPHcvWHfu+BoQeMUHX6w61ln9xJlyV1DFIgHyERoy3cu4gl LKLQoiMyvGJlgtOgWhWSoMpFeD18qFr8GAwsK/CFuorWI+WFx1ysorIAMiF8Yl4UvzT7uaY5 Cy/jxkLqBSS8fh+nyPdJkmITya0qXYF8pFy5kquVyOkGj1D2x1MXOWe6kcKDyacqj8/0kAik yh3Jjt3jymdGu/jYq/74Rv+wXKmqBLbLCEmkDHC+HIyttMu8jK2zTLi26JV33Ms3pIPG/I3n Zsty6IQL24rnFM1D+rM06LONSFDaPJ/cDFFMK4OvRs3jTM7lrG24hs7P2s3rHG3tnMDvO7EG pbRT+mvF87calKc3q6S9lEvhHNBJ+8+xloR01I892bIGjWp1eC6z6EmCy8pAy5Fd6kwRnVIK mcgN/WgWlk77mlIFWcodHWgP6G8hDVPx7MwlHWc4x1YIZbHIjM9pNiA4t7XBRdNQKLJiqmos HYdDVdEzXbMzNlGFS7UZO19FW806XdQpY2VUiEU8zdREnWfretQ77bQ3OdVcu9I3RlRn29VJ /WP/MEuIXv3V+wpnPGtgMr2K3SFmu5G1P33WpMnVWsuFJVkbUC3UwVnWNrgQFtmSOL2KxMTW VZ2D8ebNP0iJTxuQgy3Pfq2zUY2FqdPYjq3VU9rSHrslAy2VTQ2xFUOGoW3ZKN3WiX3YCTuG lD3ZpI2SSiisrW3OOOGQsX2Rgd03V1vbyzzMum3OpWRKGd3bb5jH7tPZwv1km/ykxn3cPZnc WMrc3+zcYDq3RdC2qAW3EzwwMbcN/IIFIAVWIvWB0C0/0m291C2hJvdWnKEZj6sEfGxdBUFT Yjfet0jJXXze3L0ao3vG3avdSfDeS5B0I0rfOW3fgrzdA5q7r7C77B0B/2ZcHcCrDcJbGE0S nWiH32RH4OzVa86hEtqrmqXboeCbxEucAOWrnrvJem7lgbmr4Z7N4QlYv8Zxvy0cE/rLKPzr Kxm6V6dHo6wgxy4+lOXdwPhtEhAMVhJc40KwvmnnFRh8npzHt4PBWUAe5C9+wp8VMlCBAfzJ wv19DJ6Am4kywzuexAAIDaIRpFbe1wbOyVkem0v+f0Y8oEgMwwtQ4ifuvKPncn+55k065Hr8 JuEBxlEgxjD6doeToyP4nmqsL/zSXdvNDRxIon5en22u3OcA4JUuUYBe3L1AyOW56f7028AN pYTQyH0p6oj0qqp+2q3c6qCWp8sN6yXD6rQO12m8fetHZuu6LmW83uuC3abALqZmNOvDrq9B aOzHjqrdrOzL3lHWbOrPjmkoeNXTnmf+nNLXrqRHu+3cDtTevqVjHe4ejdnkTnPmfu5NNiTO ru7I7rLuvuumHe8oZof07uuffe9DptrIEgQAOw== --------------020308060900070900030102-- --------------030001000005000602080102-- From jpv@cisco.com Thu Jul 15 05:16:59 2010 Return-Path: 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 E9B9A3A6A15 for ; Thu, 15 Jul 2010 05:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6ZiPUj1ok7NX for ; Thu, 15 Jul 2010 05:16: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 881F83A69F1 for ; Thu, 15 Jul 2010 05:15:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABqZPkxAZnwM/2dsb2JhbACfZ3GjDpp8hSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208,217";a="132703204" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 12:15:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FCFham005257 for ; Thu, 15 Jul 2010 12:15:55 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:15:55 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:15:54 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-30-241243255 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 14:15:53 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 12:15:54.0965 (UTC) FILETIME=[79643850:01CB2417] Subject: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Thu, 15 Jul 2010 12:16:59 -0000 --Apple-Mail-30-241243255 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 8.8. Storing Mode In storing mode, RPL routes messages downward by the IPv6 destination address. The following rule apply to nodes that are in storing mode: 1. The Parent Address field of a Transmit Information option MUST be empty. 2. On receiving a unicast DAO, a node MUST compute if the DAO would change the set of prefixes that the node itself advertises. If so, the node MUST generate a new DAO and transmit it, following the rules in Section 8.4. Such a change includes receiving a No- Path DAO. 3. When a node generates a new DAO, it SHOULD unicast it to each of its DAO parents. It MUST NOT unicast the DAO to nodes that are not DAO parents. 4. When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO (Section 5.4.3) to that removed DAO parent to invalidate the existing route. => Bullet 4. I would suggest a MUST here. Otherwise, this leads to potential loops, ... yes we have mechanisms to clean up, but having a MUST would IMO leads to less interop issue. Thought ? JP. --Apple-Mail-30-241243255 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit 
8.8.  Storing Mode

   In storing mode, RPL routes messages downward by the IPv6 destination
   address.  The following rule apply to nodes that are in storing mode:

   1.  The Parent Address field of a Transmit Information option MUST be
       empty.

   2.  On receiving a unicast DAO, a node MUST compute if the DAO would
       change the set of prefixes that the node itself advertises.  If
       so, the node MUST generate a new DAO and transmit it, following
       the rules in Section 8.4.  Such a change includes receiving a No-
       Path DAO.

   3.  When a node generates a new DAO, it SHOULD unicast it to each of
       its DAO parents.  It MUST NOT unicast the DAO to nodes that are
       not DAO parents.

   4.  When a node removes a node from its DAO parent set, it SHOULD
       send a No-Path DAO (Section 5.4.3) to that removed DAO parent to
       invalidate the existing route.

=> Bullet 4. I would suggest a MUST here. Otherwise, this leads to potential loops, ... yes we
have mechanisms to clean up, but having a MUST would IMO leads to less interop issue.

Thought ?

JP.
--Apple-Mail-30-241243255-- From mdurvy@cisco.com Thu Jul 15 05:42:50 2010 Return-Path: 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 F399E3A696C for ; Thu, 15 Jul 2010 05:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 sDQR-A7Oh9Ij for ; Thu, 15 Jul 2010 05:42:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 219F83A6976 for ; Thu, 15 Jul 2010 05:42:35 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="p7s'?scan'208,217";a="226746439" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 12:42:43 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6FCga97027000; Thu, 15 Jul 2010 12:42:41 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:42:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jul 2010 14:42:37 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08EC_01CB242B.F7FEDDA0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option Thread-Index: AcsihFYlXYO/2+RXTJGncvBulgiTnABla1qA References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "JP Vasseur" X-OriginalArrivalTime: 15 Jul 2010 12:42:39.0973 (UTC) FILETIME=[360D0150:01CB241B] Cc: roll@ietf.org Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Thu, 15 Jul 2010 12:42:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08EC_01CB242B.F7FEDDA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_08ED_01CB242B.F7FEDDA0" ------=_NextPart_001_08ED_01CB242B.F7FEDDA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, To answer your question: - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? [Pascal] The sequence that we are talking about now is probably the path sequence, right? Can you please elaborate on the issue? My point was not so much about the "sequence". What I meant is that if the path control has 1 bit set and you have 2 parents, you will send a DAO to one parent without sending "to all other parents" no? Best, Mathilde From: Pascal Thubert (pthubert) Sent: mardi, 13. juillet 2010 14:10 To: Mathilde Durvy (mdurvy); JP Vasseur Cc: roll@ietf.org Subject: RE: [Roll] Issue 59 on Transit information option Hi Mathilde Thanks for your great help; I hope more people will follow your example so we can deeply clean up the spec during the round. please find below: Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it's more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. [Pascal] Yes; at the end of the day the path control really had to be in the transit with the parent. Leaving the target without any bit allows us to add more headers that would also qualify that target and thus factorise. - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint). [Pascal] We have to see that. ecmp should be acceptable. We have an active thread on path control, lets deal with that there. - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? [Pascal] The sequence that we are talking about now is probably the path sequence, right? Can you please elaborate on the issue? - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. [Pascal] Yes - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn't it redundant? [Pascal] I expect not. But the node may have a stale state from that needs to be deprecated. By deprecated I mean that the router should stop forwarding through a node child that has last presented path sequence 21 as soon as another child presents sequence 22 or more for a same target. This indicates that in a DAG, a new path sequence should rapidly cause a DAO. In a tree, that is less urgent. - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? [Pascal] the lifetime is important for 2 things at least: - Flush. A lifetime of 0 is a route flush. That is how we do no-path. - Seq number validation. The path lifetime covers the path sequence so that in normal operations, the path sequence should not be incremented by 16 during a lifetime, so we should never see path sequence numbers that are out of sync by more than 16. It's a lot of questions, but I hope it will help make the DAO part clearer to everybody! [Pascal] including the editors since the doc belongs to the group. Best, Mathilde From: Pascal Thubert (pthubert) Sent: mercredi, 7. juillet 2010 09:22 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Mathilde, 1) In storing mode, the transit information "parent address" is not used You're correct on that with the current spec. I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. Pascal From: Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option Hi Pascal, My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. Does this make sense? Best, Mathilde From: Pascal Thubert (pthubert) Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option Hi Mathilde: Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+. I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router. What do you think? Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option Hi All, I didn't see these comments addressed in the new draft. Any reason? For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option Hi All, I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. Best, Mathilde From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: Hi Phil, Thanks a lot for your answer. Here are my comments: A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address = A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? These are good questions. Currently the draft is a bit unclear on whether 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information. 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice. Similar to Phil I'm getting worried about the increased complexity. But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? ICMP error. Phil ------=_NextPart_001_08ED_01CB242B.F7FEDDA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

To answer your question:

- It seems to me that the path control usage is incompatible = with the sentence “If a node sends a DAO to one DAO parent, it MUST = send a DAO with the same DAOSequence to all other DAO parents”. = No?

[Pascal] The sequence that we are talking about now is = probably the path sequence, right? Can you please elaborate on the = issue?

My point was not so much about the “sequence”. What I meant is = that if the path control has 1 bit set and you have 2 parents, you will send a = DAO to one parent without sending “to all other parents” = no?

 

Best,

Mathilde=

 

 

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 13. juillet 2010 14:10
To: Mathilde Durvy (mdurvy); JP Vasseur
Cc: roll@ietf.org
Subject: RE: [Roll] Issue 59 on Transit information = option

 

Hi Mathilde

 

Thanks for your great help; I hope more people will = follow your example so we can deeply clean up the spec during the round. please find = below:

 

Thanks again for your reply. What you say makes sense = although I still think that the separation of the fields between the target and = transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it’s more important to clarify the specs with respect to the = meaning / usage of the path sequence, control, and lifetime.

[Pascal] Yes; at the end of the day the path control = really had to be in the transit with the parent. Leaving the target without any bit = allows us to add more headers that would also qualify that target and thus = factorise.

 

- In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred = (since path control bits sent to different parents have to be disjoint). =

[Pascal] We have to see that. ecmp should be acceptable. = We have an active thread on path control, lets deal with that = there.

 

- It seems to me that the path control usage is incompatible = with the sentence “If a node sends a DAO to one DAO parent, it MUST = send a DAO with the same DAOSequence to all other DAO parents”. = No?

[Pascal] The sequence that we are talking about now is = probably the path sequence, right? Can you please elaborate on the = issue?

 

- In the non storing mode, the path control is not used to = limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I = guess it can be used as a preference by the root when it computes the source = routes.

[Pascal] Yes

 

- How is the path sequence processed? Given that we have = already a DAO sequence is it possible to receive a stale path sequence? = Isn’t it redundant?

[Pascal] I expect not. But the node may have a stale = state from that needs to be deprecated. By deprecated I mean that the router should = stop forwarding through a node child that has last presented path sequence 21 = as soon as  another child presents sequence  22 or more for a = same target. This indicates that in a DAG, a new path sequence should rapidly = cause a DAO. In a tree, that is less urgent.

 

- What does the lifetime represent concretely? Is it a = measure of the lifetime of the link between the target and the = transit?

 

[Pascal] the lifetime is important for 2 things at = least:

-          Flush. A lifetime of 0 is a route flush. That is how we = do no-path.

-          Seq number validation. The path lifetime covers the path sequence so that in normal operations, the path sequence should not be incremented by 16 during a lifetime, so we should never see path = sequence numbers that are out of sync by more than 16.

 

It’s a lot of questions, but I hope it will help make = the DAO part clearer to everybody!

 

[Pascal] including the editors since the doc belongs to = the group.

 

Best,

Mathilde

 

 

From:= Pascal = Thubert (pthubert)
Sent: mercredi, 7. juillet 2010 09:22
To: Mathilde Durvy (mdurvy); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde,

 

1) In storing mode, the transit information “parent address” is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing = the info for the tunnel endpoint and that it might become handy to indicate = a RPL router to which a target host is attached.

 

2)    = He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ for = non-storing.

 

We want to factorise: in non-storing mode, the target can = have multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can = place multiple targets for all its addresses and then only one transit info = that is common to them all.

 

Pascal

 

From:= = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Pascal,

 

My point is a bit different.

In storing mode, the transit information “parent address” is not used. The only fields that are relevant in the = transit information are the path control, sequence, and lifetime, which actually = relate to the target prefix. So why not put these fields in the target option = and use only the transit option when we are in non-storing mode and hence need = to specify a parent address?

Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing.

 

Does this make sense?

Best,

Mathilde

 

From:= Pascal = Thubert (pthubert)
Sent: mardi, 6. juillet 2010 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination = and the transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. = AS Phil pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode = to indicate the tunnel end point for targets outside the RPL network, like = the proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 PM
To: ROLL WG
Subject: [Roll] FW: Transit information = option

 

Hi All,

 

I didn’t see these comments addressed in the new draft. Any reason? =

For point 2, I would go even further and propose to put the path sequence, = control, and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add that the sentence “In a DIO, the RPL Target Option = identifies a resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 11:09
To: Philip Levis
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi All,

 

I just looked at the updated draft and most of the comments = below have been addresses / clarified. Just a few rather minor = points:

- Section 5.7.7. RPL Target. Based on the discussion below I = would change “A set of one or more Transit Information options MAY directly = follow the Target option in a DAO message” to “a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information = Option ”.

- If the Path-Sequence / Control fields are indeed used both = in storing (where I have doubts they are really needed) and non-storing = mode, why not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length option.

 

Best,

Mathilde

 

 

From:= Philip = Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On Jun 11, 2010, at 7:26 AM, Mathilde Durvy = (mdurvy) wrote:

 

Hi Phil,

 

Thanks a lot for your answer. Here are my = comments:

 =

A few items that might be worth clarifying in version = 09:

- “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path sequence / control = / lifetime are not specified (which seems to contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. = Storing mode seems like it is a MUST as well...

I think we all = agree.

- “A non-storing node that has more than one DAO parent MAY include = a Transit Information option for each DAO parent as part of the = non-storing Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn’t he send one DAO with transit information A (i.e. parent = address =3D A) to DAO parent A and another DAO with transit information B to DAO = parent B? Otherwise how this would work over multiple hop? Maybe an example of = DAO would help.

- In section 7.1.5 point 2, I assume the node should add a transit = information with its parent before passing the content of the received DAO. Also do = the operation specified on the path control field in the previous section = for storing node also apply in the non-storing case?

 

These are good questions. Currently the draft is a = bit unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, or 

2) the DODAG Root receives just the last downward = hops of each node, and stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that = if it's 2), then in non-storing mode node needs to send a DAO to just one DAO = parent, and this DAO can contain the full set of last-hops. What are your = thoughts?

 

Indeed, I think the = current draft is a bit unclear. My interpretation when reading was 1 (probably due = mostly to the history of the draft). Now from your comments I understand what the = draft is proposing, namely 2. Thanks for explaining.

What triggered this = change?

It seems to me that if = proper aggregation of the routes is performed (in particular if in the record = route case you can avoid transmitting routes which are sub-routes of others) = the two schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit on = the topology. What is quite clear is that 2 requires more processing power = than 1 as it needs to reassemble routes from the received = information.

Also concerning your = last comment, I agree. The DAO produced will be slightly larger but we send only one = DAO instead of one DAO per DAO parent. I think if we do that we might not = really need the path control field, correct?

 

-09 has a rewrite of the Downward Routes section = that should make all of this much clearer. The answer is 2), for reasons Richard = brought up a few months ago. In particular, if you use 1), then when a node changes = its parent set it entire sub-DODAG must resend DAOs. This is a significant = cost. If you use 2), then only that node needs to send a new DAO.

 

 

 

- Has the advantage of having multiple DAO parents been assessed with = respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent = set. The concern is that the vagaries and unreliability of wireless links call = for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward = routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger = to the entire sub-DODAG.

I understand how this would work in the storing case but in = the non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

------=_NextPart_001_08ED_01CB242B.F7FEDDA0-- ------=_NextPart_000_08EC_01CB242B.F7FEDDA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxNTEyNDIzN1owIwYJKoZIhvcNAQkEMRYEFIes7yxc3r5VhVEc lJyrZ1XvuSZWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAhF2eGeUDTt/9f67SeN6668KExAAs/Wck xIAAf/GBsA3gOqnMURnXH1NsV6UNNpYhU34AdOvD1/zIuePMq1UvyQLt6hzaf1YLerHBXTdm8kgO x7BPz9fnuLKa2JROodLr76jZjPm+lrGFVX6PP/F5Z9ik/OCVaCTymTYX3xy+LeQAAAAAAAA= ------=_NextPart_000_08EC_01CB242B.F7FEDDA0-- From jpv@cisco.com Thu Jul 15 05:43:50 2010 Return-Path: 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 D3E373A6A1E for ; Thu, 15 Jul 2010 05:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 4lv1Z3ociKw4 for ; Thu, 15 Jul 2010 05:43:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BC8623A6A1A for ; Thu, 15 Jul 2010 05:43:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALuePkyrR7Hu/2dsb2JhbACfZ3Gidpp+hSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="scan'208,217";a="226747182" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2010 12:43:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6FChi0G029020 for ; Thu, 15 Jul 2010 12:43:59 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:43:57 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:43:57 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-31-242926094 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 14:43:56 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 12:43:57.0335 (UTC) FILETIME=[64298270:01CB241B] Subject: [Roll] Ticket #64 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: , X-List-Received-Date: Thu, 15 Jul 2010 12:43:51 -0000 --Apple-Mail-31-242926094 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 10.2.2. Router Operation 10.2.2.1. Instance Forwarding Instance IDs are used to avoid loops between DODAGs from different origins. DODAGs that constructed for antagonistic constraints might contain paths that, if mixed together, would yield loops. Those loops are avoided by forwarding a packet along the DODAG that is associated to a given instance. The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For traffic originating outside of the RPL domain there may be a mapping occurring at the gateway JP> Do not use "gateway". It is called LBR in the terminology ID. into the RPL domain, possibly based on an encoding within the flow label. This aspect of RPL operation is to be clarified in a future version of this specification. JP> in rev-11. Note that the LBR may use policy to compute itself the RPLInstanceID. We do not need to mandate the source outside of the RPL domain to carry it in the flow label. --Apple-Mail-31-242926094 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 
10.2.2.  Router Operation

10.2.2.1.  Instance Forwarding

   Instance IDs are used to avoid loops between DODAGs from =
different
   origins.  DODAGs that constructed for =
antagonistic constraints might
   contain paths that, if mixed together, would yield loops.  Those
   loops are avoided by forwarding a packet along the DODAG that is
   associated to a given instance.

   The RPLInstanceID is associated by the source with the packet.  This
   RPLInstanceID MUST match the RPL Instance onto which the packet is
   placed by any node, be it a host or router.  For traffic originating
   outside of the RPL domain there may be a mapping occurring at the
   gateway 
JP> Do not =
use "gateway". It is called LBR in the terminology =
ID.
into the RPL =
domain, possibly based on an encoding within the
   flow label.  This aspect of RPL operation is to be clarified in a
   future version of this specification.

JP> in rev-11. Note that the LBR may use policy to compute =
itself the RPLInstanceID.
We do not need to mandate the source =
outside of the RPL domain to carry it in =
the 
flow =
label.
= --Apple-Mail-31-242926094-- From mdurvy@cisco.com Thu Jul 15 05:46:32 2010 Return-Path: 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 D35BD3A67F8 for ; Thu, 15 Jul 2010 05:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 U1SMN7fM7xyb for ; Thu, 15 Jul 2010 05:46:30 -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 824853A685F for ; Thu, 15 Jul 2010 05:46:29 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="p7s'?scan'208,217";a="132736970" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2010 12:46:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FCkbLw018926; Thu, 15 Jul 2010 12:46:39 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:46:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Jul 2010 14:46:37 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08F4_01CB242C.8710FEB0" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94E@XMB-AMS-103.cisco.com> In-Reply-To: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comment Section 7.4 Thread-Index: AcskDv7Ulmk4x7jgRgyG1PjB35bTqQADIYdA References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 15 Jul 2010 12:46:39.0009 (UTC) FILETIME=[C4870110:01CB241B] Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Thu, 15 Jul 2010 12:46:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08F4_01CB242C.8710FEB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_08F5_01CB242C.8710FEB0" ------=_NextPart_001_08F5_01CB242C.8710FEB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 But would remove the "and destinations" as they are not part of the policy. Best, Mathilde From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: jeudi, 15. juillet 2010 13:15 To: ROLL WG Subject: [Roll] Comment Section 7.4 Section 7.4 7.4. DODAG Selection The DODAG selection is implementation and OF dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. I would advocate for a MUST there. Thought? JP. ------=_NextPart_001_08F5_01CB242C.8710FEB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

But would remove the “and destinations” as they = are not part of the policy.

 

Best,

Mathilde

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: jeudi, 15. juillet 2010 13:15
To: ROLL WG
Subject: [Roll] Comment Section 7.4

 

Section 7.4

 

7.4.  DODAG =
Selection
 
   =
The DODAG selection is implementation and OF dependent.  Nodes =
SHOULD
   prefer to join DODAGs for =
RPLInstanceIDs advertising OCPs and
   =
destinations compatible with their implementation =
specific
   =
objectives.

 

I would advocate for a MUST there.

 

Thought?

 

JP.

------=_NextPart_001_08F5_01CB242C.8710FEB0-- ------=_NextPart_000_08F4_01CB242C.8710FEB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxNTEyNDYzN1owIwYJKoZIhvcNAQkEMRYEFIeJ4rrpMXv8+/7m sD3zjYSplBLPMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGACFp6/jWQBn6KmmzBByXomUiE94VfQFGj gWDImKKEqMIS8vC6fK2K4Esu3FjwtsnFS+cB0yR6mvtq+8ItIcR7txTeKgpYpbW0+blByaW9gTop m+FbSGhko+Qpy3876aupSnAJRNVwjSQMQpZ1Blo9h6n3BWFhJDKvPCJSdQycKDYAAAAAAAA= ------=_NextPart_000_08F4_01CB242C.8710FEB0-- From jpv@cisco.com Thu Jul 15 05:50:19 2010 Return-Path: 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 E33CD3A6A13 for ; Thu, 15 Jul 2010 05:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.383 X-Spam-Level: X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 D0bhdtcCV9r4 for ; Thu, 15 Jul 2010 05:50:18 -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 5D0563A687C for ; Thu, 15 Jul 2010 05:50:18 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAE6hPkxAZnwM/2dsb2JhbACBRJ4kcaJsmwCFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="scan'208,217";a="132714416" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 12:50:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FCoPGp021461 for ; Thu, 15 Jul 2010 12:50:28 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:50:27 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 14:50:27 +0200 Message-Id: <95B52E96-217A-46C8-9D8C-AFE182D50A02@cisco.com> From: JP Vasseur To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94E@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-33-243316121 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 14:50:26 +0200 References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94E@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 12:50:27.0421 (UTC) FILETIME=[4CABE8D0:01CB241C] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Thu, 15 Jul 2010 12:50:20 -0000 --Apple-Mail-33-243316121 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 15, 2010, at 2:46 PM, Mathilde Durvy (mdurvy) wrote: > +1 > But would remove the =93and destinations=94 as they are not part of = the =20 > policy. > Yes > Best, > Mathilde > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of JP Vasseur > Sent: jeudi, 15. juillet 2010 13:15 > To: ROLL WG > Subject: [Roll] Comment Section 7.4 > > Section 7.4 > > 7.4. DODAG Selection > > The DODAG selection is implementation and OF dependent. Nodes =20 > SHOULD > prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > destinations compatible with their implementation specific > objectives. > > I would advocate for a MUST there. > > Thought? > > JP. --Apple-Mail-33-243316121 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 15, 2010, = at 2:46 PM, Mathilde Durvy (mdurvy) wrote:

+1
But would remove the =93and destinations=94 as they are = not part of the policy.
Best,
Mathilde
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: jeudi, 15. juillet 2010 = 13:15
To: ROLL= WG
Subject: [Roll] Comment Section = 7.4
Section = 7.4
7.4.  DODAG Selection
   The DODAG selection is =
implementation and OF dependent.  Nodes SHOULD
   destinations compatible with their =
implementation specific
   =
objectives.
I would advocate for a = MUST there.
something that is a little annoying to discover after deployments are out. What is the difficulty with having the DODAGID change when the root device is replaced? Using the same DODAGID would seem to be operationally more complicated and more likely to run into difficulties. -Richard Kelsey From richard.kelsey@ember.com Thu Jul 15 07:31:02 2010 Return-Path: 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 4F71C3A6ABD for ; Thu, 15 Jul 2010 07:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 j2GZoBRHcfvS for ; Thu, 15 Jul 2010 07:30:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 087233A6AAE for ; Thu, 15 Jul 2010 07:30:48 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 10:30:59 -0400 Date: Thu, 15 Jul 2010 10:32:41 -0400 Message-Id: <871vb4hl2u.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> (message from JP Vasseur on Thu, 15 Jul 2010 13:14:40 +0200) From: Richard Kelsey References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> X-OriginalArrivalTime: 15 Jul 2010 14:30:59.0646 (UTC) FILETIME=[582865E0:01CB242A] Cc: roll@ietf.org Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Thu, 15 Jul 2010 14:31:02 -0000 > From: JP Vasseur > Date: Thu, 15 Jul 2010 13:14:40 +0200 > Section 7.4 > > 7.4. DODAG Selection > > The DODAG selection is implementation and OF dependent. Nodes > SHOULD > prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > destinations compatible with their implementation specific > objectives. > > I would advocate for a MUST there. I don't think there is any point in this sentence, whether it is a SHOULD or a MUST. Given that the "implementation specific objectives" are entirely implementation specific, what would it mean to require that the node act compatibly with them? This sentence is equivalent to: Implementations SHOULD/MUST act in a fashion compatible with their objectives. While I would hope this to be true, we cannot meaningfully require it. -Richard Kelsey From pthubert@cisco.com Thu Jul 15 08:06:31 2010 Return-Path: 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 6DDD63A697F for ; Thu, 15 Jul 2010 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 UhckPw5L644a for ; Thu, 15 Jul 2010 08:06:15 -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 EC5183A67F3 for ; Thu, 15 Jul 2010 08:06:13 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="scan'208,217";a="132799362" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2010 15:06:23 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FF6KCT013040; Thu, 15 Jul 2010 15:06:23 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 17:06:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB242F.48E56039" Date: Thu, 15 Jul 2010 17:06:16 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option thread-index: AcsihFYlXYO/2+RXTJGncvBulgiTnABla1qAAAU3RVA= References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "JP Vasseur" X-OriginalArrivalTime: 15 Jul 2010 15:06:22.0020 (UTC) FILETIME=[4930F840:01CB242F] Cc: roll@ietf.org Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Thu, 15 Jul 2010 15:06:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB242F.48E56039 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ho! I think the confusion is that not all the parents are necessarily DAO parents. The DAO parents are the subset of parents to which DAO are sent (in storing) or about whom DAO are sent (in non storing). So in your example there would be only one. But the sentence can be improved by saying that all DAOs sent at the same time are sent with the same sequence in order to build multiple paths. =20 Pascal =20 From: Mathilde Durvy (mdurvy)=20 Sent: Thursday, July 15, 2010 2:43 PM To: Pascal Thubert (pthubert); 'JP Vasseur' Cc: 'roll@ietf.org' Subject: RE: [Roll] Issue 59 on Transit information option =20 Hi Pascal, =20 To answer your question: - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? [Pascal] The sequence that we are talking about now is probably the path sequence, right? Can you please elaborate on the issue? My point was not so much about the "sequence". What I meant is that if the path control has 1 bit set and you have 2 parents, you will send a DAO to one parent without sending "to all other parents" no? =20 Best, Mathilde =20 =20 =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 13. juillet 2010 14:10 To: Mathilde Durvy (mdurvy); JP Vasseur Cc: roll@ietf.org Subject: RE: [Roll] Issue 59 on Transit information option =20 Hi Mathilde =20 Thanks for your great help; I hope more people will follow your example so we can deeply clean up the spec during the round. please find below: =20 Thanks again for your reply. What you say makes sense although I still think that the separation of the fields between the target and transit options is somewhat arbitrary J However this is not a major issue and maybe at this point it's more important to clarify the specs with respect to the meaning / usage of the path sequence, control, and lifetime. [Pascal] Yes; at the end of the day the path control really had to be in the transit with the parent. Leaving the target without any bit allows us to add more headers that would also qualify that target and thus factorise. =20 - In storing mode, the path control is used to limit the DAO fan-out. It can also be used to set a preference between routes with the limitation that it cannot specify two routes which are equally preferred (since path control bits sent to different parents have to be disjoint).=20 [Pascal] We have to see that. ecmp should be acceptable. We have an active thread on path control, lets deal with that there. =20 - It seems to me that the path control usage is incompatible with the sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents". No? [Pascal] The sequence that we are talking about now is probably the path sequence, right? Can you please elaborate on the issue? =20 - In the non storing mode, the path control is not used to limit the DAO fan-out as nodes send DAOs to only one of their DAO parents. I guess it can be used as a preference by the root when it computes the source routes. [Pascal] Yes =20 - How is the path sequence processed? Given that we have already a DAO sequence is it possible to receive a stale path sequence? Isn't it redundant?=20 [Pascal] I expect not. But the node may have a stale state from that needs to be deprecated. By deprecated I mean that the router should stop forwarding through a node child that has last presented path sequence 21 as soon as another child presents sequence 22 or more for a same target. This indicates that in a DAG, a new path sequence should rapidly cause a DAO. In a tree, that is less urgent. =20 - What does the lifetime represent concretely? Is it a measure of the lifetime of the link between the target and the transit? =20 [Pascal] the lifetime is important for 2 things at least: - Flush. A lifetime of 0 is a route flush. That is how we do no-path. - Seq number validation. The path lifetime covers the path sequence so that in normal operations, the path sequence should not be incremented by 16 during a lifetime, so we should never see path sequence numbers that are out of sync by more than 16.=20 =20 It's a lot of questions, but I hope it will help make the DAO part clearer to everybody! =20 [Pascal] including the editors since the doc belongs to the group. =20 Best, Mathilde =20 =20 From: Pascal Thubert (pthubert)=20 Sent: mercredi, 7. juillet 2010 09:22 To: Mathilde Durvy (mdurvy); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option =20 Hi Mathilde, =20 1) In storing mode, the transit information "parent address" is not used =20 You're correct on that with the current spec.=20 I'm pointing out that in some cases we are missing the info for the tunnel endpoint and that it might become handy to indicate a RPL router to which a target host is attached. =20 2) Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 We want to factorise: in non-storing mode, the target can have multiple parents each one with a different path control. =20 In storing mode, a router with multiple interfaces can place multiple targets for all its addresses and then only one transit info that is common to them all. =20 Pascal =20 From: Mathilde Durvy (mdurvy)=20 Sent: Tuesday, July 06, 2010 4:47 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] FW: Transit information option =20 Hi Pascal, =20 My point is a bit different. In storing mode, the transit information "parent address" is not used. The only fields that are relevant in the transit information are the path control, sequence, and lifetime, which actually relate to the target prefix. So why not put these fields in the target option and use only the transit option when we are in non-storing mode and hence need to specify a parent address? Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ for non-storing. =20 Does this make sense? Best, Mathilde =20 From: Pascal Thubert (pthubert)=20 Sent: mardi, 6. juillet 2010 15:44 To: Mathilde Durvy (mdurvy); ROLL WG Subject: RE: [Roll] FW: Transit information option =20 Hi Mathilde: =20 Pls note that the target identifies the final destination and the transit tells you about how you get there. So you can factorize optimally depending on what you are doing. =20 We have issue 55 that should cover your proposed change. AS Phil pointed out, The pattern is really (Target+, Transit+)+.=20 =20 I tend to think that the parent is needed in storing mode to indicate the tunnel end point for targets outside the RPL network, like the proverbial dumb host attached to a RPL router.=20 =20 What do you think? =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: Tuesday, July 06, 2010 3:25 PM To: ROLL WG Subject: [Roll] FW: Transit information option =20 Hi All, =20 I didn't see these comments addressed in the new draft. Any reason?=20 For point 2, I would go even further and propose to put the path sequence, control, and lifetime fields in the Target option and keep only the parent address field in the Transit option. Let me add that the sentence "In a DIO, the RPL Target Option identifies a resource that the root is trying to reach" should be removed if I believe the list of options allowed for DIO. =20 Best, Mathilde =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) Sent: vendredi, 18. juin 2010 11:09 To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 Hi All, =20 I just looked at the updated draft and most of the comments below have been addresses / clarified. Just a few rather minor points: - Section 5.7.7. RPL Target. Based on the discussion below I would change "A set of one or more Transit Information options MAY directly follow the Target option in a DAO message" to "a RPL Target Option in a unicast DAO MUST be followed by a set of one or more Transit Information Option ". - If the Path-Sequence / Control fields are indeed used both in storing (where I have doubts they are really needed) and non-storing mode, why not put them in the target option rather than in the transit option. This way we could maybe only use only the target option in storing mode and the target+transit option in non-storing mode. This would have the additional benefit of making the parent address mandatory in the transit information option and thus avoid a variable length option. =20 Best, Mathilde =20 =20 From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: vendredi, 11. juin 2010 18:10 To: Mathilde Durvy (mdurvy) Cc: roll@ietf.org Subject: Re: [Roll] Transit information option =20 =20 On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: =20 Hi Phil, =20 Thanks a lot for your answer. Here are my comments: =20 A few items that might be worth clarifying in version 09: - "Transit Information options MAY directly follow the Target option" Is it really a MAY? If not included it means the path sequence / control / lifetime are not specified (which seems to contradict section 7.1.4.2). In non-storing mode, it is definitely a MUST. Storing mode seems like it is a MUST as well... I think we all agree. - "A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing Destination Advertisement operation." Why would a node do that? If a node is sending a DAO for a specific target to e.g. 2 DAO parents (A and B) shouldn't he send one DAO with transit information A (i.e. parent address =3D A) to DAO parent A and another DAO with transit information B to DAO parent B? Otherwise how this would work over multiple hop? Maybe an example of DAO would help. - In section 7.1.5 point 2, I assume the node should add a transit information with its parent before passing the content of the received DAO. Also do the operation specified on the path control field in the previous section for storing node also apply in the non-storing case? =20 These are good questions. Currently the draft is a bit unclear on whether=20 1) a DAO's transit option contains the full source route when it arrives at the DODAG Root, or=20 2) the DODAG Root receives just the last downward hops of each node, and stitches together source routes with this information.=20 1) seems like a much better idea to me. Note that if it's 2), then in non-storing mode node needs to send a DAO to just one DAO parent, and this DAO can contain the full set of last-hops. What are your thoughts? =20 Indeed, I think the current draft is a bit unclear. My interpretation when reading was 1 (probably due mostly to the history of the draft). Now from your comments I understand what the draft is proposing, namely 2. Thanks for explaining. What triggered this change? It seems to me that if proper aggregation of the routes is performed (in particular if in the record route case you can avoid transmitting routes which are sub-routes of others) the two schemes could actually be quite similar in terms of overhead. This would need to be confirmed by a careful study as it could depend quite on bit on the topology. What is quite clear is that 2 requires more processing power than 1 as it needs to reassemble routes from the received information. Also concerning your last comment, I agree. The DAO produced will be slightly larger but we send only one DAO instead of one DAO per DAO parent. I think if we do that we might not really need the path control field, correct? =20 -09 has a rewrite of the Downward Routes section that should make all of this much clearer. The answer is 2), for reasons Richard brought up a few months ago. In particular, if you use 1), then when a node changes its parent set it entire sub-DODAG must resend DAOs. This is a significant cost. If you use 2), then only that node needs to send a new DAO. =20 =20 =20 - Has the advantage of having multiple DAO parents been assessed with respect to the added complexity? One could argue that since we take so much care in selecting a preferred this should be a good enough choice... Similar to Phil I'm getting worried about the increased complexity. =20 But note that in upward routes, there's a parent set. The concern is that the vagaries and unreliability of wireless links call for supporting some degree of path diversity. Most protocols today maintain multiple candidate next hops for this exact reason. Because downward routes start at the endpoints, there needs to be some way to establish multiple routes. Otherwise, when one link breaks and you have to issue a trigger to the entire sub-DODAG. I understand how this would work in the storing case but in the non-storing case how would you know at the root that the path failed? =20 ICMP error. =20 Phil ------_=_NextPart_001_01CB242F.48E56039 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ho! I think the confusion is that not all the parents are necessarily = DAO parents. The DAO parents are the subset of parents to which DAO are = sent (in storing) or about whom DAO are sent (in non storing). So in = your example there would be only one. But the sentence can be improved = by saying that all DAOs sent at the same time are sent with the same = sequence in order to build multiple paths.

 

Pascal

 

From:= = Mathilde Durvy (mdurvy)
Sent:= Thursday, = July 15, 2010 2:43 PM
To: Pascal Thubert (pthubert); 'JP = Vasseur'
Cc: 'roll@ietf.org'
Subject: RE: [Roll] = Issue 59 on Transit information = option

 

Hi = Pascal,

 

To answer = your question:

- = It seems to me that the path control usage is incompatible with the = sentence “If a node sends a DAO to one DAO parent, it MUST send a = DAO with the same DAOSequence to all other DAO parents”. = No?

[Pascal] The sequence that we are talking about now is probably the = path sequence, right? Can you please elaborate on the = issue?

My point was = not so much about the “sequence”. What I meant is that if = the path control has 1 bit set and you have 2 parents, you will send a = DAO to one parent without sending “to all other parents” = no?

 

Best,

Mathilde=

 

 

 

From:= = Pascal Thubert (pthubert)
Sent: mardi, 13. juillet 2010 = 14:10
To: Mathilde Durvy (mdurvy); JP Vasseur
Cc: = roll@ietf.org
Subject: RE: [Roll] Issue 59 on Transit = information option

 

Hi Mathilde

 

Thanks for your great help; I hope more people will follow your = example so we can deeply clean up the spec during the round. please find = below:

 

Th= anks again for your reply. What you say makes sense although I still = think that the separation of the fields between the target and transit = options is somewhat arbitrary J = However this is not a major issue and maybe at this point it’s = more important to clarify the specs with respect to the meaning / usage = of the path sequence, control, and lifetime.

[Pascal] Yes; at the end of the day the path control really had to be = in the transit with the parent. Leaving the target without any bit = allows us to add more headers that would also qualify that target and = thus factorise.

 

- = In storing mode, the path control is used to limit the DAO fan-out. It = can also be used to set a preference between routes with the limitation = that it cannot specify two routes which are equally preferred (since = path control bits sent to different parents have to be disjoint). =

[Pascal] We have to see that. ecmp should be acceptable. We have an = active thread on path control, lets deal with that = there.

 

- = It seems to me that the path control usage is incompatible with the = sentence “If a node sends a DAO to one DAO parent, it MUST send a = DAO with the same DAOSequence to all other DAO parents”. = No?

[Pascal] The sequence that we are talking about now is probably the = path sequence, right? Can you please elaborate on the = issue?

 

- = In the non storing mode, the path control is not used to limit the DAO = fan-out as nodes send DAOs to only one of their DAO parents. I guess it = can be used as a preference by the root when it computes the source = routes.

[Pascal] Yes

 

- = How is the path sequence processed? Given that we have already a DAO = sequence is it possible to receive a stale path sequence? Isn’t it = redundant?

[Pascal] I expect not. But the node may have a stale state from that = needs to be deprecated. By deprecated I mean that the router should stop = forwarding through a node child that has last presented path sequence 21 = as soon as  another child presents sequence  22 or more for a = same target. This indicates that in a DAG, a new path sequence should = rapidly cause a DAO. In a tree, that is less = urgent.

 

- = What does the lifetime represent concretely? Is it a measure of the = lifetime of the link between the target and the = transit?

 

[Pascal] the lifetime is important for 2 things at = least:

-          = Flush. A lifetime of 0 is a route flush. That is how we do = no-path.

-          = Seq number validation. The path lifetime covers the path sequence so = that in normal operations, the path sequence should not be incremented = by 16 during a lifetime, so we should never see path sequence numbers = that are out of sync by more than 16.

 

It= ’s a lot of questions, but I hope it will help make the DAO part = clearer to everybody!

 

[Pascal] including the editors since the doc belongs to the = group.

 

Be= st,

Ma= thilde

 

 

From:= = Pascal Thubert (pthubert)
Sent: mercredi, 7. juillet 2010 = 09:22
To: Mathilde Durvy (mdurvy); 'ROLL = WG'
Subject: RE: [Roll] FW: Transit information = option

 

Hi Mathilde,

 

1)= In storing mode, the transit information “parent address” = is not used

 

You’re correct on that with the current spec. =

I’m pointing out that in some cases we are missing the info for = the tunnel endpoint and that it might become handy to indicate a RPL = router to which a target host is attached.

 

2)    He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

We want to factorise: in non-storing mode, the target can have = multiple parents each one with a different path control. =  

In storing mode, a router with multiple interfaces can place multiple = targets for all its addresses and then only one transit info that is = common to them all.

 

Pascal

 

From:= Mathilde = Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 4:47 = PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: = RE: [Roll] FW: Transit information = option

 

Hi= Pascal,

 

My= point is a bit different.

In= storing mode, the transit information “parent address” is = not used. The only fields that are relevant in the transit information = are the path control, sequence, and lifetime, which actually relate to = the target prefix. So why not put these fields in the target option and = use only the transit option when we are in non-storing mode and hence = need to specify a parent address?

He= nce the pattern would be (Target+) for storing and (Target+,Transit+)+ = for non-storing.

 

Do= es this make sense?

Be= st,

Ma= thilde

 

From:= = Pascal Thubert (pthubert)
Sent: mardi, 6. juillet 2010 = 15:44
To: Mathilde Durvy (mdurvy); ROLL WG
Subject: = RE: [Roll] FW: Transit information = option

 

Hi Mathilde:

 

Pls note that the target identifies the final destination and the = transit tells you about how you get there. So you can factorize = optimally depending on what you are doing.

 

We have issue 55 that should cover your proposed change. AS Phil = pointed out, The pattern is really (Target+, Transit+)+. =

 

I tend to think that the parent is needed in storing mode to indicate = the tunnel end point for targets outside the RPL network, like the = proverbial dumb host attached to a RPL router.

 

What do you think?

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: Tuesday, July 06, 2010 3:25 = PM
To: ROLL WG
Subject: [Roll] FW: Transit = information option

 

Hi = All,

 

I = didn’t see these comments addressed in the new draft. Any reason? =

For point 2, = I would go even further and propose to put the path sequence, control, = and lifetime fields in the Target option and keep only the parent = address field in the Transit option.

Let me add = that the sentence “In a DIO, the RPL Target Option identifies a = resource that the root is trying to reach” should be removed if I = believe the list of options allowed for DIO.

 

Best,

Mathilde=

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy)
Sent: vendredi, 18. juin 2010 = 11:09
To: Philip Levis
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

Hi= All,

 

I = just looked at the updated draft and most of the comments below have = been addresses / clarified. Just a few rather minor = points:

- = Section 5.7.7. RPL Target. Based on the discussion below I would change = “A set of one or more Transit Information options MAY directly = follow the Target option in a DAO message” to “a RPL Target = Option in a unicast DAO MUST be followed by a set of one or more Transit = Information Option ”.

- = If the Path-Sequence / Control fields are indeed used both in storing = (where I have doubts they are really needed) and non-storing mode, why = not put them in the target option rather than in the transit option. = This way we could maybe only use only the target option in storing mode = and the target+transit option in non-storing mode. This would have the = additional benefit of making the parent address mandatory in the transit = information option and thus avoid a variable length = option.

 

Be= st,

Ma= thilde

 

 

From:= = Philip Levis [mailto:pal@cs.stanford.edu]
Sent: vendredi, 11. = juin 2010 18:10
To: Mathilde Durvy (mdurvy)
Cc: = roll@ietf.org
Subject: Re: [Roll] Transit information = option

 

 

On = Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) = wrote:

 

Hi= Phil,

&n= bsp;

Th= anks a lot for your answer. Here are my = comments:

 =

A few items = that might be worth clarifying in version = 09:

- = “Transit Information options MAY directly follow the Target = option” Is it really a MAY? If not included it means the path = sequence / control / lifetime are not specified (which seems to = contradict section = 7.1.4.2).

In non-storing mode, it is definitely a MUST. Storing = mode seems like it is a MUST as well...

I = think we all = agree.

- “A = non-storing node that has more than one DAO parent MAY include a Transit = Information option for each DAO parent as part of the non-storing = Destination Advertisement operation.” Why would a node do that? If = a node is sending a DAO for a specific target to e.g. 2 DAO parents (A = and B) shouldn’t he send one DAO with transit information A (i.e. = parent address =3D A) to DAO parent A and another DAO with transit = information B to DAO parent B? Otherwise how this would work over = multiple hop? Maybe an example of DAO would = help.

- In section = 7.1.5 point 2, I assume the node should add a transit information with = its parent before passing the content of the received DAO. Also do the = operation specified on the path control field in the previous section = for storing node also apply in the non-storing = case?

 

These are good questions. Currently the draft is a bit = unclear on whether 

1) a DAO's transit option contains the full source = route when it arrives at the DODAG Root, = or 

2) the = DODAG Root receives just the last downward hops of each node, and = stitches together source routes with this = information. 

1) seems like a much better idea to me. Note that if = it's 2), then in non-storing mode node needs to send a DAO to just one = DAO parent, and this DAO can contain the full set of last-hops. What are = your thoughts?

 

Indeed, I think the current = draft is a bit unclear. My interpretation when reading was 1 (probably = due mostly to the history of the draft). Now from your comments I = understand what the draft is proposing, namely 2. Thanks for = explaining.

What triggered this = change?

It seems to me that if proper aggregation of the = routes is performed (in particular if in the record route case you can = avoid transmitting routes which are sub-routes of others) the two = schemes could actually be quite similar in terms of overhead. This would = need to be confirmed by a careful study as it could depend quite on bit = on the topology. What is quite clear is that 2 requires more processing = power than 1 as it needs to reassemble routes from the received = information.

Also concerning your last comment, I agree. The DAO = produced will be slightly larger but we send only one DAO instead of one = DAO per DAO parent. I think if we do that we might not really need the = path control field, = correct?

 

-09 has a rewrite of the Downward Routes section that = should make all of this much clearer. The answer is 2), for reasons = Richard brought up a few months ago. In particular, if you use 1), then = when a node changes its parent set it entire sub-DODAG must resend DAOs. = This is a significant cost. If you use 2), then only that node needs to = send a new DAO.

 

 

<= p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'> 

=

- Has the = advantage of having multiple DAO parents been assessed with respect to = the added complexity? One could argue that since we take so much care in = selecting a preferred this should be a good enough choice… Similar = to Phil I’m getting worried about the increased = complexity.

 

But note that in upward routes, there's a parent set. = The concern is that the vagaries and unreliability of wireless links = call for supporting some degree of path diversity. Most protocols today = maintain multiple candidate next hops for this exact reason. Because = downward routes start at the endpoints, there needs to be some way to = establish multiple routes. Otherwise, when one link breaks and you have = to issue a trigger to the entire sub-DODAG.

I = understand how this would work in the storing case but in the = non-storing case how would you know at the root that the path = failed?

 

ICMP error.

 

Phil

= ------_=_NextPart_001_01CB242F.48E56039-- From trac@tools.ietf.org Thu Jul 15 09:00:12 2010 Return-Path: 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 28D7D3A6A51 for ; Thu, 15 Jul 2010 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 Q+WmXGJ-luxD for ; Thu, 15 Jul 2010 09:00:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CA9B83A690A for ; Thu, 15 Jul 2010 09:00:10 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZQrF-0007PH-TQ; Thu, 15 Jul 2010 09:00:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 16:00:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/66 Message-ID: <055.a09c55694a404838dee3f73fe8b58883@tools.ietf.org> X-Trac-Ticket-ID: 66 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #66: New link-local RPL multicast address and 6lowpan-HC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 16:00:12 -0000 #66: New link-local RPL multicast address and 6lowpan-HC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Thursday, July 15, 2010 11:38 AM To: Joakim Eriksson; roll Subject: Re: [Roll] New link-local RPL multicast address and 6lowpan-HC Great point Joakim; 1A is actually free in http://www.iana.org/assignments/ipv6-multicast-addresses/ let's try and get that value? Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Joakim Eriksson Sent: Wednesday, July 14, 2010 12:16 PM To: roll Subject: [Roll] New link-local RPL multicast address and 6lowpan-HC Hello, The new RPL all routers address ff02::1:a is going to cause much worse compression (3 bytes vs 1 byte) of the destination address in 6lowpan based networks. Is there any plans for "fixing" the HC or are we ok with this? (I like small messages ;-) Would it be impossible to get a ff02::1a address from IANA instead? Best regards -- Joakim Eriksson, SICS _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -- Ticket URL: roll From trac@tools.ietf.org Thu Jul 15 09:35:53 2010 Return-Path: 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 00AC53A6B4E for ; Thu, 15 Jul 2010 09:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 lmpy-LwpBxo7 for ; Thu, 15 Jul 2010 09:35:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AF5343A6AB2 for ; Thu, 15 Jul 2010 09:35:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZRPR-0004EZ-UX; Thu, 15 Jul 2010 09:35:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 16:35:41 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/67 Message-ID: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> X-Trac-Ticket-ID: 67 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #67: DODAG Default Path Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 16:35:53 -0000 #67: DODAG Default Path Lifetime -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email sent from Roger July 14 Subject: [Roll] DODAG Default Path Lifetime Date: Wed, 14 Jul 2010 16:02:20 -0400 From: Alexander, Roger To: roll Hi WG, I would like to recommend use of a DODAG-defined Default Path Lifetime as opposed to the current model in which Path Lifetime is specified per prefix using the Transit Information Option. As in other routing protocols, such as RIP for example, the validity period of an advertised prefix is defined not per destination address but is specified through a protocol configuration element such as the route-timeout timer. In the same vein, a default validity period can be defined for all advertised destinations through a Default Path Lifetime specified within the DODAG Configuration option. This default value will apply to all advertised prefixes unless otherwise specified using an optional Path Lifetime information element within the Transit Information option. The benefit of a Default Path Lifetime is that it will allow 4-bytes to be saved per advertised DAO destination unless a specific, dedicated Path Lifetime is needed for a given prefix. The Lifetime for a destination address will continue to apply from the time of receipt at a node. No additional control bits will be required within the Transit Information Option as the presence or absence of the Path Lifetime information element can be directly deduced from the value of the Option Length. Thanks. Roger -- Ticket URL: roll From wintert@acm.org Thu Jul 15 09:37:50 2010 Return-Path: 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 0536C3A6AA3 for ; Thu, 15 Jul 2010 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qfzonvhV6vYY for ; Thu, 15 Jul 2010 09:37:45 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id F234B3A6ACB for ; Thu, 15 Jul 2010 09:37:44 -0700 (PDT) Received: (qmail 63785 invoked from network); 15 Jul 2010 16:37:50 -0000 Received: from [10.56.17.107] (wintert@71.178.253.216 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 15 Jul 2010 09:37:50 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: yEz2BOMVM1l_VCCPjVuoFXL66tK4JqRsv_nZ9iiOfM4f5MB 8zE1QNBlYUe1XJb1B9jU2SdxVK3hjEHEHxwUpvlC16P_L95Qln90Pkm8G3pa zHPWJM6.WywlzIoBOZMbhZLQsVmI6yvh9Q67YzlzFR2AM2KwHs8izjqBpINP XMYL9JRSUcR6ZLpb4so89vYamcI1tkkp0cEAj3LXI5YtVCcw16JJjX.3yGMw 8qkRSxNE9K1YLbRl.EI7zOMvQHXBcJCm0csZOdNKZ_gUTPvn7Pmy1QuRycC3 btoS4h8s86rhUCiWeG5GSOE2L X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3F395D.1050409@acm.org> Date: Thu, 15 Jul 2010 12:37:49 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Thu, 15 Jul 2010 16:37:50 -0000 On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > Ho! I think the confusion is that not all the parents are necessarily > DAO parents. The DAO parents are the subset of parents to which DAO are > sent (in storing) or about whom DAO are sent (in non storing). So in > your example there would be only one. But the sentence can be improved > by saying that all DAOs sent at the same time are sent with the same > sequence in order to build multiple paths. Yes, and it should also be clarified that if you have more DAO Parents than you can allocate Path Control bits for a given Target, then some of those Parents will be left out of getting a DAO for that Target. -Tim > > Pascal > > *From:* Mathilde Durvy (mdurvy) > *Sent**:* Thursday, July 15, 2010 2:43 PM > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > *Cc:* 'roll@ietf.org' > *Subject:* RE: [Roll] Issue 59 on Transit information option > > Hi Pascal, > > To answer your question: > > - It seems to me that the path control usage is incompatible with the > sentence “If a node sends a DAO to one DAO parent, it MUST send a DAO > with the same DAOSequence to all other DAO parents”. No? > > */[Pascal] The sequence that we are talking about now is probably the > path sequence, right? Can you please elaborate on the issue?/* > > My point was not so much about the “sequence”. What I meant is that if > the path control has 1 bit set and you have 2 parents, you will send a > DAO to one parent without sending “to all other parents” no? > > Best, > > Mathilde > > */ /* > > *From:* Pascal Thubert (pthubert) > *Sent:* mardi, 13. juillet 2010 14:10 > *To:* Mathilde Durvy (mdurvy); JP Vasseur > *Cc:* roll@ietf.org > *Subject:* RE: [Roll] Issue 59 on Transit information option > > Hi Mathilde > > Thanks for your great help; I hope more people will follow your example > so we can deeply clean up the spec during the round. please find below: > > Thanks again for your reply. What you say makes sense although I still > think that the separation of the fields between the target and transit > options is somewhat arbitrary J However this is not a major issue and > maybe at this point it’s more important to clarify the specs with > respect to the meaning / usage of the path sequence, control, and lifetime. > > */[Pascal] Yes; at the end of the day the path control really had to be > in the transit with the parent. Leaving the target without any bit > allows us to add more headers that would also qualify that target and > thus factorise./* > > - In storing mode, the path control is used to limit the DAO fan-out. It > can also be used to set a preference between routes with the limitation > that it cannot specify two routes which are equally preferred (since > path control bits sent to different parents have to be disjoint). > > */[Pascal] We have to see that. ecmp should be acceptable. We have an > active thread on path control, lets deal with that there./* > > - It seems to me that the path control usage is incompatible with the > sentence “If a node sends a DAO to one DAO parent, it MUST send a DAO > with the same DAOSequence to all other DAO parents”. No? > > */[Pascal] The sequence that we are talking about now is probably the > path sequence, right? Can you please elaborate on the issue?/* > > - In the non storing mode, the path control is not used to limit the DAO > fan-out as nodes send DAOs to only one of their DAO parents. I guess it > can be used as a preference by the root when it computes the source routes. > > */[Pascal] Yes/* > > - How is the path sequence processed? Given that we have already a DAO > sequence is it possible to receive a stale path sequence? Isn’t it > redundant? > > */[Pascal] I expect not. But the node may have a stale state from that > needs to be deprecated. By deprecated I mean that the router should stop > forwarding through a node child that has last presented path sequence 21 > as soon as another child presents sequence 22 or more for a same target. > This indicates that in a DAG, a new path sequence should rapidly cause a > DAO. In a tree, that is less urgent./* > > - What does the lifetime represent concretely? Is it a measure of the > lifetime of the link between the target and the transit? > > */[Pascal] the lifetime is important for 2 things at least:/* > > - Flush. A lifetime of 0 is a route flush. That is how we do no-path. > > - Seq number validation. The path lifetime covers the path sequence so > that in normal operations, the path sequence should not be incremented > by 16 during a lifetime, so we should never see path sequence numbers > that are out of sync by more than 16. > > It’s a lot of questions, but I hope it will help make the DAO part > clearer to everybody! > > */[Pascal] including the editors since the doc belongs to the group./* > > Best, > > Mathilde > > *From:* Pascal Thubert (pthubert) > *Sent:* mercredi, 7. juillet 2010 09:22 > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > *Subject:* RE: [Roll] FW: Transit information option > > Hi Mathilde, > > 1) In storing mode, the transit information “parent address” is not used > > You’re correct on that with the current spec. > > I’m pointing out that in some cases we are missing the info for the > tunnel endpoint and that it might become handy to indicate a RPL router > to which a target host is attached. > > 2) Hence the pattern would be (Target+) for storing and > (Target+,Transit+)+ for non-storing. > > We want to factorise: in non-storing mode, the target can have multiple > parents each one with a different path control. > > In storing mode, a router with multiple interfaces can place multiple > targets for all its addresses and then only one transit info that is > common to them all. > > Pascal > > *From:* Mathilde Durvy (mdurvy) > *Sent:* Tuesday, July 06, 2010 4:47 PM > *To:* Pascal Thubert (pthubert); 'ROLL WG' > *Subject:* RE: [Roll] FW: Transit information option > > Hi Pascal, > > My point is a bit different. > > In storing mode, the transit information “parent address” is not used. > The only fields that are relevant in the transit information are the > path control, sequence, and lifetime, which actually relate to the > target prefix. So why not put these fields in the target option and use > only the transit option when we are in non-storing mode and hence need > to specify a parent address? > > Hence the pattern would be (Target+) for storing and (Target+,Transit+)+ > for non-storing. > > Does this make sense? > > Best, > > Mathilde > > *From:* Pascal Thubert (pthubert) > *Sent:* mardi, 6. juillet 2010 15:44 > *To:* Mathilde Durvy (mdurvy); ROLL WG > *Subject:* RE: [Roll] FW: Transit information option > > Hi Mathilde: > > Pls note that the target identifies the final destination and the > transit tells you about how you get there. So you can factorize > optimally depending on what you are doing. > > We have issue 55 that should cover your proposed change. AS Phil pointed > out, The pattern is really (Target+, Transit+)+. > > I tend to think that the parent is needed in storing mode to indicate > the tunnel end point for targets outside the RPL network, like the > proverbial dumb host attached to a RPL router. > > What do you think? > > Pascal > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Mathilde Durvy (mdurvy) > *Sent:* Tuesday, July 06, 2010 3:25 PM > *To:* ROLL WG > *Subject:* [Roll] FW: Transit information option > > Hi All, > > I didn’t see these comments addressed in the new draft. Any reason? > > For point 2, I would go even further and propose to put the path > sequence, control, and lifetime fields in the Target option and keep > only the parent address field in the Transit option. > > Let me add that the sentence “In a DIO, the RPL Target Option identifies > a resource that the root is trying to reach” should be removed if I > believe the list of options allowed for DIO. > > Best, > > Mathilde > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Mathilde Durvy (mdurvy) > *Sent:* vendredi, 18. juin 2010 11:09 > *To:* Philip Levis > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] Transit information option > > Hi All, > > I just looked at the updated draft and most of the comments below have > been addresses / clarified. Just a few rather minor points: > > - Section 5.7.7. RPL Target. Based on the discussion below I would > change “A set of one or more Transit Information options MAY directly > follow the Target option in a DAO message” to “a RPL Target Option in a > unicast DAO MUST be followed by a set of one or more Transit Information > Option ”. > > - If the Path-Sequence / Control fields are indeed used both in storing > (where I have doubts they are really needed) and non-storing mode, why > not put them in the target option rather than in the transit option. > This way we could maybe only use only the target option in storing mode > and the target+transit option in non-storing mode. This would have the > additional benefit of making the parent address mandatory in the transit > information option and thus avoid a variable length option. > > Best, > > Mathilde > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > *Sent:* vendredi, 11. juin 2010 18:10 > *To:* Mathilde Durvy (mdurvy) > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] Transit information option > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > Hi Phil, > > Thanks a lot for your answer. Here are my comments: > > A few items that might be worth clarifying in version 09: > > - “Transit Information options MAY directly follow the Target option” Is > it really a MAY? If not included it means the path sequence / control / > lifetime are not specified (which seems to contradict section 7.1.4.2). > > In non-storing mode, it is definitely a MUST. Storing mode seems like it > is a MUST as well... > > I think we all agree. > > - “A non-storing node that has more than one DAO parent MAY include a > Transit Information option for each DAO parent as part of the > non-storing Destination Advertisement operation.” Why would a node do > that? If a node is sending a DAO for a specific target to e.g. 2 DAO > parents (A and B) shouldn’t he send one DAO with transit information A > (i.e. parent address = A) to DAO parent A and another DAO with transit > information B to DAO parent B? Otherwise how this would work over > multiple hop? Maybe an example of DAO would help. > > - In section 7.1.5 point 2, I assume the node should add a transit > information with its parent before passing the content of the received > DAO. Also do the operation specified on the path control field in the > previous section for storing node also apply in the non-storing case? > > These are good questions. Currently the draft is a bit unclear on whether > > 1) a DAO's transit option contains the full source route when it arrives > at the DODAG Root, or > > 2) the DODAG Root receives just the last downward hops of each node, and > stitches together source routes with this information. > > 1) seems like a much better idea to me. Note that if it's 2), then in > non-storing mode node needs to send a DAO to just one DAO parent, and > this DAO can contain the full set of last-hops. What are your thoughts? > > Indeed, I think the current draft is a bit unclear. My interpretation > when reading was 1 (probably due mostly to the history of the draft). > Now from your comments I understand what the draft is proposing, namely > 2. Thanks for explaining. > > What triggered this change? > > It seems to me that if proper aggregation of the routes is performed (in > particular if in the record route case you can avoid transmitting routes > which are sub-routes of others) the two schemes could actually be quite > similar in terms of overhead. This would need to be confirmed by a > careful study as it could depend quite on bit on the topology. What is > quite clear is that 2 requires more processing power than 1 as it needs > to reassemble routes from the received information. > > Also concerning your last comment, I agree. The DAO produced will be > slightly larger but we send only one DAO instead of one DAO per DAO > parent. I think if we do that we might not really need the path control > field, correct? > > -09 has a rewrite of the Downward Routes section that should make all of > this much clearer. The answer is 2), for reasons Richard brought up a > few months ago. In particular, if you use 1), then when a node changes > its parent set it entire sub-DODAG must resend DAOs. This is a > significant cost. If you use 2), then only that node needs to send a new > DAO. > > - Has the advantage of having multiple DAO parents been assessed with > respect to the added complexity? One could argue that since we take so > much care in selecting a preferred this should be a good enough choice… > Similar to Phil I’m getting worried about the increased complexity. > > But note that in upward routes, there's a parent set. The concern is > that the vagaries and unreliability of wireless links call for > supporting some degree of path diversity. Most protocols today maintain > multiple candidate next hops for this exact reason. Because downward > routes start at the endpoints, there needs to be some way to establish > multiple routes. Otherwise, when one link breaks and you have to issue a > trigger to the entire sub-DODAG. > > I understand how this would work in the storing case but in the > non-storing case how would you know at the root that the path failed? > > ICMP error. > > Phil > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From joakime@sics.se Thu Jul 15 09:40:47 2010 Return-Path: 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 498493A6B32 for ; Thu, 15 Jul 2010 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 DsX5obOhTziw for ; Thu, 15 Jul 2010 09:40:43 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 875CE3A6A95 for ; Thu, 15 Jul 2010 09:40:42 -0700 (PDT) Received: from [192.168.0.211] (c-4f667a6a-74736162.cust.telenor.se [79.102.122.106]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 69BBA4010C; Thu, 15 Jul 2010 18:40:50 +0200 (CEST) Message-ID: <4C3F3802.4080102@sics.se> Date: Thu, 15 Jul 2010 18:32:02 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4C3D8E54.6020101@sics.se> <6A2A459175DABE4BB11DE2026AA50A5D02574462@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574462@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll Subject: Re: [Roll] New link-local RPL multicast address and 6lowpan-HC 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: , X-List-Received-Date: Thu, 15 Jul 2010 16:40:48 -0000 Exactly, it is free, and is a good replacement for 1:a! And, yes, we should take it if we can! Best regards, -- Joakim Eriksson, SICS Pascal Thubert (pthubert) skrev 2010-07-15 11:38: > Great point Joakim; > > 1A is actually free in > http://www.iana.org/assignments/ipv6-multicast-addresses/ > let's try and get that value? > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Joakim Eriksson >> Sent: Wednesday, July 14, 2010 12:16 PM >> To: roll >> Subject: [Roll] New link-local RPL multicast address and 6lowpan-HC >> >> Hello, >> >> The new RPL all routers address ff02::1:a is going to cause much worse >> compression (3 bytes vs 1 byte) of the destination address in 6lowpan > based >> networks. Is there any plans for "fixing" the HC or are we ok with > this? (I like >> small messages ;-) >> >> Would it be impossible to get a ff02::1a address from IANA instead? >> >> >> Best regards >> -- Joakim Eriksson, SICS >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Thu Jul 15 10:31:20 2010 Return-Path: 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 3CD633A6A3C for ; Thu, 15 Jul 2010 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 r4SXYpiPavlH for ; Thu, 15 Jul 2010 10:31:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C5F53A69CA for ; Thu, 15 Jul 2010 10:31:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZSHP-0004Or-TL; Thu, 15 Jul 2010 10:31:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 17:31:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/68 Message-ID: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-Trac-Ticket-ID: 68 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #68: RPL security comments received during LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:31:20 -0000 #68: RPL security comments received during LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Find below a list of comments/suggestions/questions provided by Michael Richardson during RPL WG LC, along with PROPOSED resolution TO BE CONFIRMED on the mailing list. #1: "When KIM is 11, a key source *MAY* be present and a key index *MAY* be present. How is this determined? I think it may come out of the security level, but I don't quite see how." answer: "Key source and index are present if there is encryption, denoted by LVL field. The draft explicitly states this now." #2: "It appears that the RPL security fields are not a multiple of 64-bits, and block-mode AES requires 16-byte blocks, while CCM mode is happy with any increment of bits. Assuming that someone will define a second cipher at some point, we need to know how to padd properly. But, I don't see any statement about how padding is to be used." answer: "Padding is defined by the individual security algorithm: there is not one-size-fits-all approach. Since the currently supported security mode does not require padding, there is no statement about it. Future algorithms, if specified in other documents, can state how they pad." #3: "I also see no way for a node to tell if it is joining an authenticated network or a pre-installed network. How does a node which is authenticated know which set of keys (pre-installed or authenticated) to use to authenticate a message from a new prospective node? Is this an inate property of the keys themselves indicated by the Key Source and Key Index?" answer: Authenticate vs. preinstalled is denoted by the 'A' flag of the DODAG Configuration option. Which key to use is stated in the security section. #4: "The entire Compressed Counter mechanism seems like a waste of code space. I see no savings by doing this in the resulting packets due to required padding. The ensuing CC process that is needed to deal with this seems like a further waste. I'd rather define a standard compression algorithm that we can apply before encryption instead. " answer: Counter compression has been removed. #5: "Making it Unix epoch (Jan. 1, 1970) would be simpler. As the specification says we are supposed to keep 6 bytes (48 bits) of resolution, this is 274877906944s, or 8700 years. If we go to Jan. 1970, then this changes the lifetime of RPL from 8716 years to 8675 years." answer: The draft now uses UNIX time. #6: "I can't tell from the specification if the contents of the "Security Section" are protected in any way by the integrity check. Section 9.6 was not helpful, as it says "entire IPv6 packet". I guess this means the layer-3, but someone will get it wrong, and include layer-2 too. When the integrity check is calculated, what is the value in the security section for the MAC code? " answer: Coverage is now repeated in the packet format section. MAC/integrity covers the entire packet, confidentiality is all payload following the security section. #7: "well, no. The replay check SHOULD be preformed before authentication of the packet. If the replay counter says "old", then you discard without further processing (do not waste your time/energy verifying old packets!). If the replay says "new", then you can authenticate first, and update the counters if it checks out." answer: Replay protection now comes before authentication. -- Ticket URL: roll From trac@tools.ietf.org Thu Jul 15 10:33:44 2010 Return-Path: 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 A65BC3A6B62 for ; Thu, 15 Jul 2010 10:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 v1-Dr1QBYhzs for ; Thu, 15 Jul 2010 10:33:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5FF043A6A55 for ; Thu, 15 Jul 2010 10:33:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZSJd-0004Sm-Bk; Thu, 15 Jul 2010 10:33:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 17:33:45 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/69 Message-ID: <055.bb6b45a8a7494e138975e1d7539726e2@tools.ietf.org> X-Trac-Ticket-ID: 69 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #69: milliseconds in time-based counters X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:33:45 -0000 #69: milliseconds in time-based counters -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Question received on the ML: Are the milliseconds in time-based counters decimal milliseconds (1000Hz) or binary milliseconds (1024Hz)? -- Ticket URL: roll From trac@tools.ietf.org Thu Jul 15 10:34:06 2010 Return-Path: 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 0EA403A6A64 for ; Thu, 15 Jul 2010 10:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 FQhm2o7eF6IC for ; Thu, 15 Jul 2010 10:34:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9E7A53A6B4E for ; Thu, 15 Jul 2010 10:34:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZSK4-0004TA-HR; Thu, 15 Jul 2010 10:34:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 17:34:12 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/69#comment:1 Message-ID: <064.ad2a5c8969ba38948ea28a508522f1bf@tools.ietf.org> References: <055.bb6b45a8a7494e138975e1d7539726e2@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <055.bb6b45a8a7494e138975e1d7539726e2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #69: milliseconds in time-based counters X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:34:06 -0000 #69: milliseconds in time-based counters -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Changes (by jpv@…): * type: defect => task Old description: > Question received on the ML: Are the milliseconds in time-based counters > decimal milliseconds (1000Hz) or binary milliseconds (1024Hz)? New description: Question received on the ML: Are the milliseconds in time-based counters decimal milliseconds (1000Hz) or binary milliseconds (1024Hz)? -- Comment: answer: Binary milliseconds. This is now clearly stated in the draft. -- Ticket URL: roll From trac@tools.ietf.org Thu Jul 15 10:49:17 2010 Return-Path: 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 D76573A6AB5 for ; Thu, 15 Jul 2010 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 6G01JaTN1pB7 for ; Thu, 15 Jul 2010 10:49:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1556E3A6A95 for ; Thu, 15 Jul 2010 10:49:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZSYq-0007tp-3N; Thu, 15 Jul 2010 10:49:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 17:49:28 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/69#comment:2 Message-ID: <064.ce728714b19b1e0a772e2f35d8e78cdf@tools.ietf.org> References: <055.bb6b45a8a7494e138975e1d7539726e2@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <055.bb6b45a8a7494e138975e1d7539726e2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #69: milliseconds in time-based counters X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:49:18 -0000 #69: milliseconds in time-based counters -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: More precisely, it will be clearly stated in revision -11. -- Ticket URL: roll From pal@cs.stanford.edu Thu Jul 15 10:51:09 2010 Return-Path: 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 AFC4E3A6B4C for ; Thu, 15 Jul 2010 10:51:09 -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 aabNLISfJI3i for ; Thu, 15 Jul 2010 10:51:07 -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 54E1E3A6961 for ; Thu, 15 Jul 2010 10:51:07 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OZSaa-0002Cb-QK; Thu, 15 Jul 2010 10:51:18 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 15 Jul 2010 10:51:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu> References: To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: ROLL WG Subject: Re: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Thu, 15 Jul 2010 17:51:10 -0000 On Jul 15, 2010, at 5:15 AM, JP Vasseur wrote: >=20 >=20 > =3D> Bullet 4. I would suggest a MUST here. Otherwise, this leads to = potential loops, ... yes we > have mechanisms to clean up, but having a MUST would IMO leads to less = interop issue. >=20 > Thought ? Given that DAO parents are a subset of DODAG parents, this implies = there's a loop in the DODAG. Wouldn't it make more sense to more = narrowly define this to the case of moving downward in the DODAG? Phil= From trac@tools.ietf.org Thu Jul 15 13:19:37 2010 Return-Path: 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 00E2D3A685E for ; Thu, 15 Jul 2010 13:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 qZrMa9+GjhZj for ; Thu, 15 Jul 2010 13:19:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5D5793A67D9 for ; Thu, 15 Jul 2010 13:19:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZUuE-00061F-Uq; Thu, 15 Jul 2010 13:19:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 15 Jul 2010 20:19:42 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/70 Message-ID: <055.d823261b419b55d9dd0dde82abf7f82f@tools.ietf.org> X-Trac-Ticket-ID: 70 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #70: Comments during RPL LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 20:19:37 -0000 #70: Comments during RPL LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Email from JP on July 15: Hi, Being a co-author, I tried to make another pass while reading it as a first time reader, with more comments/suggestions. There is a combination of (1) minor editorial changes, (2) required changes, ... ** No major issue ** SEE FILE ATTACHED -- Ticket URL: roll From jpv@cisco.com Thu Jul 15 13:21:12 2010 Return-Path: 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 D13323A698E for ; Thu, 15 Jul 2010 13:21:12 -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 H4nslwfd9H9g for ; Thu, 15 Jul 2010 13:21:12 -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 8180E3A67F5 for ; Thu, 15 Jul 2010 13:21:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,210,1278288000"; d="scan'208,217";a="132926475" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2010 20:21:16 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6FKLEvr010339; Thu, 15 Jul 2010 20:21:15 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 22:21:14 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 22:21:05 +0200 Message-Id: <2423AC71-01D7-48F4-A281-2E41BFD9AB71@cisco.com> From: JP Vasseur To: ROLL WG , Tim Winter , "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=Apple-Mail-51-270354032 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 22:21:04 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Jul 2010 20:21:05.0719 (UTC) FILETIME=[40C0C470:01CB245B] X-Mailman-Approved-At: Thu, 15 Jul 2010 13:24:57 -0700 Subject: [Roll] LC Detailed review RPL Rev 10 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: , X-List-Received-Date: Thu, 15 Jul 2010 20:21:13 -0000 --Apple-Mail-51-270354032 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, Being a co-author, I tried to make another pass while reading it as a first time reader, with more comments/suggestions. There is a =20 combination of (1) minor editorial changes, (2) required changes, ... No major issue I put all comment in ticket #70 See JP> ROLL T. Winter, Ed. Internet-Draft Intended status: Standards Track P. Thubert, Ed. Expires: December 30, 2010 Cisco Systems RPL Author =20 Team IETF ROLL =20= WG Jun 28, =20 2010 RPL: IPv6 Routing Protocol for Low power and Lossy Networks draft-ietf-roll-rpl-10 Abstract Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint- to-point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to- point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six =20 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." This Internet-Draft will expire on December 30, 2010. Winter, et al. Expires December 30, 2010 [Page 1] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with =20 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. =20 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Design =20 Principles . . . . . . . . . . . . . . . . . . . 6 1.2. Expectations of Link Layer =20 Type . . . . . . . . . . . . 7 2. =20 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . =20= 11 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . =20= 11 3.1.1. Topology Identifiers . . . . . . . . . . . . . . . . =20= 11 3.2. Instances, DODAGs, and DODAG Versions . . . . . . . . . =20= 11 3.3. Upward Routes and DODAG Construction . . . . . . . . . . =20= 13 3.3.1. Objective Function (OF) . . . . . . . . . . . . . . . =20= 14 3.3.2. DODAG Repair . . . . . . . . . . . . . . . . . . . . =20= 14 3.3.3. Security . . . . . . . . . . . . . . . . . . . . . . =20= 14 3.3.4. Grounded and Floating DODAGs . . . . . . . . . . . . =20= 14 3.3.5. Local DODAGs . . . . . . . . . . . . . . . . . . . . =20= 14 3.3.6. Administrative Preference . . . . . . . . . . . . . . =20= 15 3.3.7. Datapath Validation and Loop Detection . . . . . . . =20= 15 3.3.8. Distributed Algorithm Operation . . . . . . . . . . . =20= 15 3.4. Downward Routes and Destination Advertisement . . . . . =20= 15 3.5. Local DODAGs Route Discovery . . . . . . . . . . . . . . =20= 16 3.6. Routing Metrics and Constraints Used By RPL . . . . . . =20= 16 3.6.1. Loop Avoidance . . . . . . . . . . . . . . . . . . . =20= 17 3.6.2. Rank Properties . . . . . . . . . . . . . . . . . . . =20= 18 3.7. Traffic Flows Supported by RPL . . . . . . . . . . . . . =20= 20 3.7.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . =20= 21 3.7.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . =20= 21 3.7.3. Point-to-Point Traffic . . . . . . . . . . . . . . . =20= 21 4. RPL Instance . . . . . . . . . . . . . . . . . . . . . . . . =20= 22 4.1. RPL Instance ID . . . . . . . . . . . . . . . . . . . . =20= 22 5. ICMPv6 RPL Control Message . . . . . . . . . . . . . . . . . =20= 24 5.1. RPL Security Fields . . . . . . . . . . . . . . . . . . =20= 25 Winter, et al. Expires December 30, 2010 [Page 2] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 5.2. DODAG Information Solicitation (DIS) . . . . . . . . . . =20= 30 5.2.1. Format of the DIS Base Object . . . . . . . . . . . . =20= 30 5.2.2. Secure DIS . . . . . . . . . . . . . . . . . . . . . =20= 31 5.2.3. DIS Options . . . . . . . . . . . . . . . . . . . . . =20= 31 5.3. DODAG Information Object (DIO) . . . . . . . . . . . . . =20= 31 5.3.1. Format of the DIO Base Object . . . . . . . . . . . . =20= 31 5.3.2. Secure DIO . . . . . . . . . . . . . . . . . . . . . =20= 33 5.3.3. DIO Options . . . . . . . . . . . . . . . . . . . . . =20= 33 5.4. Destination Advertisement Object (DAO) . . . . . . . . . =20= 33 5.4.1. Format of the DAO Base Object . . . . . . . . . . . . =20= 34 5.4.2. Secure DAO . . . . . . . . . . . . . . . . . . . . . =20= 34 5.4.3. DAO Options . . . . . . . . . . . . . . . . . . . . . =20= 35 5.5. Destination Advertisement Object Acknowledgement (DAO-ACK) . . . . . . . . . . . . . . . . . . . . . . . =20= 35 5.5.1. Format of the DAO-ACK Base Object . . . . . . . . . . =20= 35 5.5.2. Secure DAO-ACK . . . . . . . . . . . . . . . . . . . =20= 36 5.5.3. DAO-ACK Options . . . . . . . . . . . . . . . . . . . =20= 36 5.6. Consistency Check (CC) . . . . . . . . . . . . . . . . . =20= 36 5.6.1. Format of the CC Base Object . . . . . . . . . . . . =20= 36 5.6.2. CC Options . . . . . . . . . . . . . . . . . . . . . =20= 38 5.7. RPL Control Message Options . . . . . . . . . . . . . . =20= 38 5.7.1. RPL Control Message Option Generic Format . . . . . . =20= 38 5.7.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . =20= 39 5.7.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . =20= 39 5.7.4. Metric Container . . . . . . . . . . . . . . . . . . =20= 40 5.7.5. Route Information . . . . . . . . . . . . . . . . . . =20= 40 5.7.6. DODAG Configuration . . . . . . . . . . . . . . . . . =20= 42 5.7.7. RPL Target . . . . . . . . . . . . . . . . . . . . . =20= 43 5.7.8. Transit Information . . . . . . . . . . . . . . . . . =20= 45 5.7.9. Solicited Information . . . . . . . . . . . . . . . . =20= 46 5.7.10. Prefix Information . . . . . . . . . . . . . . . . . =20= 48 6. Sequence Counters . . . . . . . . . . . . . . . . . . . . . . =20= 51 7. Upward Routes . . . . . . . . . . . . . . . . . . . . . . . . =20= 53 7.1. DIO Base Rules . . . . . . . . . . . . . . . . . . . . . =20= 53 7.2. Upward Route Discovery and Maintenance . . . . . . . . . =20= 53 7.2.1. Neighbors and Parents within a DODAG Version . . . . =20= 53 7.2.2. Neighbors and Parents across DODAG Versions . . . . . =20= 54 7.2.3. DIO Message Communication . . . . . . . . . . . . . . =20= 58 7.3. DIO Transmission . . . . . . . . . . . . . . . . . . . . =20= 59 7.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . =20= 60 7.4. DODAG Selection . . . . . . . . . . . . . . . . . . . . =20= 60 7.5. Operation as a Leaf Node . . . . . . . . . . . . . . . . =20= 60 7.6. Administrative Rank . . . . . . . . . . . . . . . . . . =20= 61 8. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . =20= 62 8.1. Destination Advertisement Parents . . . . . . . . . . . =20= 62 8.2. Downward Route Discovery and Maintenance . . . . . . . . =20= 62 8.3. DAO Base Rules . . . . . . . . . . . . . . . . . . . . . =20= 63 8.4. DAO Transmission Scheduling . . . . . . . . . . . . . . =20= 64 Winter, et al. Expires December 30, 2010 [Page 3] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 8.5. Triggering DAO Messages . . . . . . . . . . . . . . . . =20= 64 8.6. Structure of DAO Messages . . . . . . . . . . . . . . . =20= 65 8.7. Non-storing Mode . . . . . . . . . . . . . . . . . . . . =20= 65 8.8. Storing Mode . . . . . . . . . . . . . . . . . . . . . . =20= 66 8.9. Path Control . . . . . . . . . . . . . . . . . . . . . . =20= 67 8.10. Multicast Destination Advertisement Messages . . . . . . =20= 68 9. Security Mechanisms . . . . . . . . . . . . . . . . . . . . . =20= 69 9.1. Security Overview . . . . . . . . . . . . . . . . . . . =20= 69 9.2. Installing Keys . . . . . . . . . . . . . . . . . . . . =20= 70 9.3. Joining a Secure Network . . . . . . . . . . . . . . . . =20= 70 9.4. Counter and Counter Compression . . . . . . . . . . . . =20= 71 9.4.1. Timestamp Counters . . . . . . . . . . . . . . . . . =20= 72 9.5. Functional Description of Packet Protection . . . . . . =20= 72 9.5.1. Transmission of Outgoing Packets . . . . . . . . . . =20= 72 9.5.2. Reception of Incoming Packets . . . . . . . . . . . . =20= 74 9.5.3. Cryptographic Mode of Operation . . . . . . . . . . . =20= 76 9.6. Coverage of Integrity and Confidentiality . . . . . . . =20= 77 10. Packet Forwarding and Loop Avoidance/Detection . . . . . . . =20= 78 10.1. Suggestions for Packet Forwarding . . . . . . . . . . . =20= 78 10.2. Loop Avoidance and Detection . . . . . . . . . . . . . . =20= 79 10.2.1. Source Node Operation . . . . . . . . . . . . . . . . =20= 80 10.2.2. Router Operation . . . . . . . . . . . . . . . . . . =20= 80 11. Multicast Operation . . . . . . . . . . . . . . . . . . . . . =20= 83 12. Maintenance of Routing Adjacency . . . . . . . . . . . . . . =20= 85 13. Guidelines for Objective Functions . . . . . . . . . . . . . =20= 86 13.1. Objective Function Behavior . . . . . . . . . . . . . . =20= 86 14. Suggestions for Interoperation with Neighbor Discovery . . . =20= 88 15. RPL Constants and Variables . . . . . . . . . . . . . . . . . =20= 89 16. Manageability Considerations . . . . . . . . . . . . . . . . =20= 91 16.1. Introduction . . . . . . . . . . . . . . . . . . . . . . =20= 91 16.2. Configuration Management . . . . . . . . . . . . . . . . =20= 92 16.2.1. Initialization Mode . . . . . . . . . . . . . . . . . =20= 92 16.2.2. DIO and DAO Base Message and Options Configuration . =20= 92 16.2.3. Protocol Parameters to be configured on every router in the LLN . . . . . . . . . . . . . . . . . . =20= 93 16.2.4. Protocol Parameters to be configured on every non-root router in the LLN . . . . . . . . . . . . . =20= 93 16.2.5. Parameters to be configured on the DODAG root . . . . =20= 94 16.2.6. Configuration of RPL Parameters related to DAO-based mechanisms . . . . . . . . . . . . . . . . =20= 95 16.2.7. Default Values . . . . . . . . . . . . . . . . . . . =20= 96 16.3. Monitoring of RPL Operation . . . . . . . . . . . . . . =20= 96 16.3.1. Monitoring a DODAG parameters . . . . . . . . . . . . =20= 96 16.3.2. Monitoring a DODAG inconsistencies and loop detection . . . . . . . . . . . . . . . . . . . . . . =20= 97 16.4. Monitoring of the RPL data structures . . . . . . . . . =20= 98 16.4.1. Candidate Neighbor Data Structure . . . . . . . . . . =20= 98 16.4.2. Destination Oriented Directed Acyclic Graph (DAG) Winter, et al. Expires December 30, 2010 [Page 4] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Table . . . . . . . . . . . . . . . . . . . . . . . . =20= 98 16.4.3. Routing Table and DAO Routing Entries . . . . . . . . =20= 99 16.5. Fault Management . . . . . . . . . . . . . . . . . . . . =20= 100 16.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . =20= 100 16.7. Liveness Detection and Monitoring . . . . . . . . . . . =20= 101 16.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . =20= 102 16.9. Impact on Other Protocols . . . . . . . . . . . . . . . =20= 102 16.10. Performance Management . . . . . . . . . . . . . . . . . =20= 102 17. Security Considerations . . . . . . . . . . . . . . . . . . . =20= 104 17.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . =20= 104 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . =20= 106 18.1. RPL Control Message . . . . . . . . . . . . . . . . . . =20= 106 18.2. New Registry for RPL Control Codes . . . . . . . . . . . =20= 106 18.3. New Registry for the Mode of Operation (MOP) DIO Control Field . . . . . . . . . . . . . . . . . . . . . =20= 107 18.4. RPL Control Message Option . . . . . . . . . . . . . . . =20= 107 18.5. Objective Code Point (OCP) Registry . . . . . . . . . . =20= 108 18.6. ICMPv6: Error in Source Routing Header . . . . . . . . . =20= 108 18.7. Link-Local Scope multicast address . . . . . . . . . . . =20= 108 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =20= 110 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . =20= 111 21. References . . . . . . . . . . . . . . . . . . . . . . . . . =20= 113 21.1. Normative References . . . . . . . . . . . . . . . . . . =20= 113 21.2. Informative References . . . . . . . . . . . . . . . . . =20= 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . =20= 117 Winter, et al. Expires December 30, 2010 [Page 5] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 1. Introduction Low power and Lossy Networks (LLNs) consist of largely of =20 constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated). JP> or make use of energy scavenging These routers are interconnected by lossy links, typically supporting only low data rates, that are usually unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply point-to-point, but in many cases point-to-multipoint or multipoint-to-point. Furthermore such networks may potentially comprise up to thousands of nodes. These characteristics offer unique challenges to a routing solution: the IETF ROLL Working Group has defined application-specific routing requirements for a Low =20 power and Lossy Network (LLN) routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. This document specifies the IPv6 Routing Protocol for Low power and lossy networks (RPL). Note that although RPL was specified =20 according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications. 1.1. Design Principles RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. A network may run multiple instances of RPL concurrently. Each such instance may serve different and potentially antagonistic =20 constraints or performance criteria. This document defines how a single =20 instance operates. In order to be useful in a wide range of LLN application domains, =20= RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives include minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing objective functions. A RPL implementation, in support of a particular LLN application, will include the necessary objective function(s) as required by the application. A set of companion documents to this specification will provide further guidance in the form of applicability statements =20 specifying a set of operating points appropriate to the Building Automation, Home Automation, Industrial, and Urban application scenarios. Winter, et al. Expires December 30, 2010 [Page 6] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 1.2. Expectations of Link Layer Type In compliance with the layered architecture of IP, RPL does not rely on any particular features of a specific link layer technology. RPL is designed to be able to operate over a variety of different link layers, including but not limited to, low power wireless or PLC (Power Line Communication) technologies. Implementers may find [RFC3819] a useful reference when designing a link layer interface between RPL and a particular link layer technology. Winter, et al. Expires December 30, 2010 [Page 7] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in =20= RFC 2119 [RFC2119]. Additionally, this document uses terminology from [I-D.ietf-roll-terminology], and introduces the following terminology: DAG: Directed Acyclic Graph. A directed graph having the property that all edges are oriented in such a way that no cycles =20 exist. All edges are contained in paths oriented toward and terminating at one or more root nodes. DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition all DAGs must have at least one DAG root and all paths terminate at a DAG root. Destination Oriented DAG (DODAG): A DAG rooted at a single destination, i.e. at a single DAG root (the DODAG root) with =20= no outgoing edges. DODAG root: A DODAG root is the DAG root of a DODAG. Up: Up refers to the direction from leaf nodes towards DODAG =20 roots, following DODAG edges. This follows the common terminology used in graphs and depth-first-search, where vertices further from the root are "deeper," or "down," and vertices closer to the root are "shallower," or "up." Down: Down refers to the direction from DODAG roots towards leaf nodes, in the reverse direction of DODAG edges. This follows the common terminology used in graphs and depth-first-search, where vertices further from the root are "deeper," or "down," and vertices closer to the root are "shallower," or "up." Rank: A node's Rank defines the node's individual position relative to other nodes with respect to a DODAG root. Rank strictly increases in the down direction and strictly decreases in the up direction. The exact way Rank is computed depends on the DAG's Objective Function (OF). The Rank may analogously track a simple topological distance, may be calculated as a function of link metrics, and may consider other properties such as constraints. Winter, et al. Expires December 30, 2010 [Page 8] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Objective Function (OF): Defines which routing metrics, =20 optimization objectives, and related functions a DAG uses to compute Rank. JP> Add: "Furthermore, the OF dictates how parents in the DODAG are selected and thus the DODAG formation itself." Objective Code Point (OCP): An identifier that indicates which Objective Function the DODAG uses. RPLInstanceID: A unique identifier within a network. Two DODAGs with the same RPLInstanceID share the same Objective Function. RPL Instance: A set of one or more DODAGs that share a RPLInstanceID. A RPL node can belong to at most one DODAG =20 in a RPL Instance. Each RPL Instance operates independently of other RPL Instances. This document describes operation within a single RPL Instance. DODAGID: The identifier of a DODAG root. The DODAGID must be =20 unique within the scope of a RPL Instance in the LLN. JP> s/must be unique/is unique The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. DODAG Version: A specific sequence number iteration ("version") =20 of a DODAG with a given DODAGID. DODAGVersionNumber: A sequential counter that is incremented by the root to form a new Version of a DODAG. A DODAG Version is identified uniquely by the (RPLInstanceID, DODAGID, DODAGVersionNumber) tuple. Goal: The Goal is a JP> s/a/an application specific goal that is defined outside the scope of RPL. Any node that roots a DODAG will need to know about this Goal to decide if the Goal can be satisfied or not. A typical Goal is to construct the DODAG according to a specific objective function and to keep connectivity to a set of hosts (e.g. to use an objective function that minimizes ETX and to be connected to a specific database host to store the collected data). Grounded: A DODAG is grounded when the DODAG root can satisfy the Goal. Floating: A DODAG is floating if is not Grounded. A floating DODAG is not expected to have the properties required to satisfy the goal. It may, however, provide connectivity to other nodes within the DODAG. DODAG parent: A parent of a node within a DODAG is one of the immediate successors of the node on a path towards the DODAG root. A DODAG parent's Rank is lower than the node's. (See Section 3.6.2.1). Winter, et al. Expires December 30, 2010 [Page 9] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Sub-DODAG The sub-DODAG of a node is the set of other nodes whose paths to the DODAG root pass through that node. Nodes in the sub-DODAG of a node have a greater Rank than that node itself. (See Section 3.6.2.1) As they form networks, LLN devices often mix the roles of 'host' and 'router' when compared to traditional IP networks. In this =20 document, 'host' refers to an LLN device that can generate but does not =20 forward RPL traffic, 'router' refers to an LLN device that can forward as well as generate RPL traffic, and 'node' refers to any RPL device, either a host or a router. Winter, et al. Expires December 30, 2010 [Page 10] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3. Protocol Overview The aim of this section is to describe RPL in the spirit of [RFC4101]. Protocol details can be found in further sections. 3.1. Topology This section describes how the basic RPL topologies, and the rules =20= by which these are constructed, i.e. the rules governing DODAG JP> DODAG: expand terms when first used. formation. 3.1.1. Topology Identifiers RPL uses four identifiers to maintain the topology: o The first is a RPLInstanceID. A RPLInstanceID identifies a set =20= of one or more DODAGs. All DODAGs in the same RPL Instance use the same Objective Function. JP> s/Objective Function/Objective Function (OF) A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different OFs and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance. o The second is a DODAGID. The scope of a DODAGID is a RPL Instance. The combination of RPLInstanceID and DODAGID uniquely identifies a single DODAG in the network. A RPL Instance may =20 have multiple DODAGs, each of which has an unique DODAGID. o The third is a DODAGVersionNumber. The scope of a DODAGVersionNumber is a DODAG. A DODAG is sometimes =20 reconstructed from the DODAG root, by incrementing the DODAGVersionNumber. The combination of RPLInstanceID, DODAGID, and DODAGVersionNumber uniquely identifies a DODAG Version. o The fourth is Rank. The scope of Rank is a DODAG Version. Rank establishes a partial order over a DODAG Version, defining individual node positions with respect to the DODAG root. JP> I don't think that the rank is a DODAG identifier. 3.2. Instances, DODAGs, and DODAG Versions A RPL Instance contains one or more Destination Oriented DAG (DODAG) JP> s/Destination Oriented DAG (DODAG)/DODAG since it must have been expanded before. roots. A RPL Instance may provide routes to certain destination prefixes, reachable via the DODAG roots or alternate paths within =20= the DODAG. These roots may operate independently, or may coordinate =20 over a non-LLN backchannel. A RPL Instance may comprise: Winter, et al. Expires December 30, 2010 [Page 11] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o a single DODAG with a single root * For example, a DODAG optimized to minimize latency rooted at a single centralized lighting controller in a home automation application. o multiple uncoordinated DODAGs with independent roots (differing DODAGIDs) * For example, multiple data collection points in an urban data collection application that do not have an always-on backbone suitable to coordinate to form a single DODAG, JP> The reason for multiple DODAG might not be because the network does not have an always-on backbone ... but just to partition the =20 network (the "and" that follows may be confusing). and further use the formation of multiple DODAGs as a means to dynamically and autonomously partition the network. o a single DODAG with a single virtual root JP> Let's avoid using the term "virtual root" since this is not a RPL =20= terms. coordinating LLN sinks (with the same DODAGID) over some non-LLN backbone * For example, multiple border routers operating with a reliable backbone, e.g. in support of a 6LowPAN application, that are capable to act as logically equivalent sinks to the same =20 DODAG. o a combination of the above as suited to some application =20 scenario. Each RPL packet has meta-data that associates it with a particular RPLInstanceID and therefore RPL Instance.(Section 4). JP> s/.(Section 4)/(see Section 4). The provisioning or automated discovery of a mapping between a RPLInstanceID and a type or service of application traffic is beyond the scope of this specification. Figure 1 depicts an example of a RPL Instance comprising three =20 DODAGs with DODAG Roots R1, R2, and R3. Figure 2 depicts how a DODAG version number increment leads to a new DODAG Version. Winter, et al. Expires December 30, 2010 [Page 12] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 +----------------------------------------------------------------+ | | | +--------------+ | | | | | | | (R1) | (R2) (R3) | | | / \ | /| \ / | \ | | | / \ | / | \ / | \ | | | (A) (B) | (C) | (D) ... (F) (G) (H) | | | /|\ |\ | / | |\ | | | | | | : : : : : | : (E) : : : : : | | | | / \ | | +--------------+ : : | | DODAG | | | +----------------------------------------------------------------+ RPL Instance Figure 1: RPL Instance +----------------+ +----------------+ | | | | | (R1) | | (R1) | | / \ | | / | | / \ | | / | | (A) (B) | \ | (A) | | /|\ |\ | ------\ | /|\ | | : : (C) : : | \ | : : (C) | | | / | \ | | | ------/ | \ | | | / | (B) | | | | |\ | | | | : : | | | | | +----------------+ +----------------+ Version N Version N+1 Figure 2: DODAG Version JP> Just indicate that a new DODAG Version does not always imply a new =20= DODAG topology (this is an example). 3.3. Upward Routes and DODAG Construction RPL provisions routes up towards DODAG roots, forming a DODAG optimized according to an Objective Function (OF). RPL nodes construct and maintain these DODAGs through DODAG Information Object (DIO) messages. Winter, et al. Expires December 30, 2010 [Page 13] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3.3.1. Objective Function (OF) The Objective Function (OF) defines how RPL nodes select and =20 optimize routes within a RPL Instance. The OF is identified by an Objective Code Point (OCP) within the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints, which are themselves defined in [I-D.ietf-roll-routing-metrics], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 13, [I-D.ietf-roll-routing-metrics], [I-D.ietf-roll-of0], and related companion specifications. 3.3.2. DODAG Repair A DODAG Root institutes a global repair operation by incrementing =20= the DODAG Version Number. This initiates a new DODAG version. Nodes in the new DODAG version can choose a new position whose Rank is not constrained by their Rank within the old DODAG Version. RPL also supports mechanisms which may be used for local repair within the DODAG version. The DIO message specifies the necessary parameters as configured from the DODAG root, as controlled by =20 policy at the root. 3.3.3. Security RPL supports message confidentiality and integrity. It is designed such that link-layer mechanisms can be used when available and appropriate, yet in their absence RPL can use its own mechanisms. 3.3.4. Grounded and Floating DODAGs DODAGs can be grounded or floating: the DODAG root advertises which is the case. A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal. A floating DODAG is not expected to satisfy the goal and in most cases only provides routes to nodes within the DODAG. Floating DODAGs may be used, for example, to preserve inner connectivity during repair. 3.3.5. Local DODAGs RPL nodes can optimize routes to a destination within an LLN by forming a local DODAG whose DODAG Root is the desired destination. Unlike global DAGs, which can consist of multiple DODAGs, local DAGs have one and only one DODAG and therefore one DODAG Root. Local DODAGs can be constructed on-demand. JP> Need to add the notion of local and global DAG to the terminology =20= section. Winter, et al. Expires December 30, 2010 [Page 14] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3.3.6. Administrative Preference An implementation/deployment may specify that some DODAG roots =20 should be used over others through an administrative preference. Administrative preference offers a way to control traffic and engineer DODAG formation in order to better support application requirements or needs. 3.3.7. Datapath Validation and Loop Detection RPL uses a hop-by-hop IPv6 header to detect possible loops within a DODAG. Each data packet includes the Rank of the transmitter. An inconsistency between the routing decision for a packet (upward or downward) and the Rank relationship between the two nodes =20 indicates a possible loop. On receiving such a packet, a node institutes a =20 local repair operation. JP> Add: "For example if a node receives a packet flagged as moving in =20= the UP direction and should send it to a node with a higher rank according =20= to its routing table, then it can conclude of a DODAG inconsistencies." 3.3.8. Distributed Algorithm Operation A high level overview of the distributed algorithm, which constructs the DODAG, is as follows: o Some nodes are configured to be DODAG roots, with associated =20 DODAG configurations. o Nodes advertise their presence, affiliation with a DODAG, routing cost, and related metrics by sending link-local multicast DIO messages. o Nodes listen for DIOs and use their information to join a new DODAG, or to maintain an existing DODAG, as according to the specified Objective Function and Rank of their neighbors. o Nodes provision routing table entries, for the destinations specified by the DIO, via their DODAG parents in the DODAG version. Nodes MUST provision a DODAG parent as a default route for the associated instance. JP> Add "if it decides to join a DODAG" It is up to the end-to-end application to select the RPL instance to be associated to its traffic (should there be more than one instance) and thus the default route upwards when no longer-match exists. 3.4. Downward Routes and Destination Advertisement RPL uses Destination Advertisement Object (DAO) messages to =20 establish downward routes from DODAG roots. JP> Not just from DODAG roots ... DAO messages are an optional feature for applications that require P2MP or P2P traffic. RPL supports two modes of downward traffic: storing (fully stateful) or non-storing (fully source routed). Any given RPL Instance is either Winter, et al. Expires December 30, 2010 [Page 15] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 storing or non-storing. In both cases, P2P packets travel up to a DODAG Root JP> Or a common ancestor in the case of storing nodes then down to the final destination (unless the destination is on the upward route). JP> with regards to the last sentence, indicate that this is with the =20= default mode of RPL specified in this specification. 3.5. Local DODAGs Route Discovery A RPL network can optionally support on-demand discovery of DODAGs =20= to specific destinations within an LLN. Such local DODAGs behave slightly differently than global DODAGs. 3.6. Routing Metrics and Constraints Used By RPL Routing metrics are used by routing protocols to compute shortest paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) and OSPF ([RFC4915]) use static link metrics. Such link metrics can simply reflect the bandwidth or can also be computed according to a polynomial function of several metrics defining different link characteristics. Some routing protocols support more than one metric: in the vast majority of the cases, one metric is used per (sub)topology. Less often, a second metric may be used as a tie- breaker in the presence of Equal Cost Multiple Paths (ECMP). The optimization of multiple metrics is known as an NP complete problem and is sometimes supported by some centralized path computation engine. In contrast, LLNs do require the support of both static and dynamic metrics. Furthermore, both link and node metrics are required. In the case of RPL, it is virtually impossible to define one metric, or even a composite metric, that will satisfy all use cases. In addition, RPL supports constrained-based routing where =20 constraints may be applied to both link and nodes. If a link or a node does not satisfy a required constraint, it is 'pruned' from the candidate list, thus leading to a constrained shortest path. An Objective Function specifies the objectives used to compute the (constrained) path. JP> Add: "Furthermore nodes are configured to support a set of metrics and constraint and select their parents in the DODAG according to the metrics and constraints advertised in the DIO messages". Upstream and Downstream metrics may be merged or advertised separately depending on the OF and the metrics. When =20 they are advertised separately, it may happen that the set of DIO parents is different from the set of DAO parents (a DAO parent is a node to which unicast DAO messages are sent). Yet, all are DODAG parents with regards to the rules for Rank computation. The Objective Function itself is decoupled from the routing metrics and constraints used by RPL. Indeed, whereas the OF dictates rules such as DODAG parents selection, load balancing and so on, the set =20= of metrics and/or constraints used to select a DODAG parent and thus determine the preferred path are based on the information carried Winter, et al. Expires December 30, 2010 [Page 16] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 within the DAG container option in DIO messages. The set of supported link/node constraints and metrics is specified in [I-D.ietf-roll-routing-metrics]. Example 1: Shortest path: path offering the shortest end-to-end =20 delay Example 2: Constrained shortest path: the path that does not =20 traverse any battery-operated node and that optimizes the path reliability 3.6.1. Loop Avoidance RPL guarantees neither loop free path selection nor tight delay convergence times. In order to reduce control overhead, however, such as the cost of the count-to-infinity problem, RPL avoids creating loops when undergoing topology changes. Furthermore, RPL includes rank-based datapath validation mechanisms for detecting loops when they do occur. JP> Add "see Section 10 for more details" RPL uses this loop detection to ensure that packets make forward progress within the DODAG version and trigger repairs when necessary. 3.6.1.1. Greediness and Rank-based Instabilities A node is greedy if it attempts to move deeper in the DODAG version, in order to increase the size of the parent set or improve some =20 other metric. Moving deeper in within a DODAG version in this manner =20 could result in instability and be detrimental to other nodes. Once a node has joined a DODAG version, RPL disallows certain behaviors, including greediness, in order to prevent resulting instabilities in the DODAG version. Suppose a node is willing to receive and process a DIO messages from a node in its own sub-DODAG, and in general a node deeper than itself. In this case, a possibility exists that a feedback loop is created, wherein two or more nodes continue to try and move in the DODAG version while attempting to optimize against each other. In some cases, this will result in instability. It is for this reason that RPL limits the cases where a node may process DIO messages from deeper nodes to some forms of local repair. This approach creates =20= an 'event horizon', whereby a node cannot be influenced beyond some limit into an instability by the action of nodes that may be in its own sub-DODAG. JP> Tim, we had a simple example illustrating this. I would suggest to =20= add it back. Winter, et al. Expires December 30, 2010 [Page 17] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3.6.1.2. DODAG Loops A DODAG loop may occur when a node detaches from the DODAG and reattaches to a device in its prior sub-DODAG. This may happen in particular when DIO messages are missed. Strict use of the DODAG Version Number can eliminate this type of loop, but this type of =20 loop may possibly be encountered when using some local repair mechanisms. JP> Add a short example, illustrating this. 3.6.1.3. DAO Loops A DAO loop may occur when the parent has a route installed upon receiving and processing a DAO message from a child, but the child has subsequently cleaned up the related DAO state. This loop =20 happens when a No-Path (a DAO message that invalidates a previously =20 announced prefix) was missed and persists until all state has been cleaned up. RPL includes an optional mechanism to acknowledge DAO messages, =20 which may mitigate the impact of a single DAO message being missed. RPL includes loop detection mechanisms that may mitigate the impact of DAO loops and trigger their repair. 3.6.2. Rank Properties The rank of a node is a scalar representation of the location of =20 that node within a DODAG version. The rank is used to avoid and detect loops, and as such must demonstrate certain properties. The exact calculation of the rank is left to the Objective Function, and may depend on parents, link JP> s/link/link or node metrics, and the node configuration and policies. The rank is not a cost metric, JP> s/cost metric/path cost although its value can be derived from and influenced by metrics. The rank has properties of its own that are not necessarily those of all metrics: Type: The rank is an abstract numeric value. Function: The rank is the expression of a relative position =20 within a DODAG version with regard to neighbors and is not =20 necessarily a good indication or a proper expression of a distance or a cost to the root. JP> s/cost to the rout/path cost to the root Stability: The stability of the rank determines the stability of =20= the routing topology. Some dampening or filtering might be JP> s/might be/is RECOMMENDED applied to keep the topology stable, and thus the rank does not necessarily change as fast as some physical metrics JP> s/physical metrics/link/node metrics would. A new DODAG version would be a good opportunity to reconcile the discrepancies that might form over time =20 between metrics and ranks within a DODAG version. Winter, et al. Expires December 30, 2010 [Page 18] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Properties: The rank is strictly monotonic, and can be used to validate a progression from or towards the root. A metric, like bandwidth or jitter, does not necessarily exhibit this property. Abstract: The rank does not have a physical unit, but rather a =20 range of increment per hop, where the assignment of each increment is to be determined by the Objective Function. The rank value feeds into DODAG parent selection, according to the RPL loop-avoidance strategy. Once a parent has been added, and a rank value for the node within the DODAG has been advertised, the nodes further options with regard to DODAG parent selection and movement within the DODAG are restricted in favor of loop avoidance. 3.6.2.1. Rank Comparison (DAGRank()) Rank may be thought of as a fixed point number, where the position =20= of the radix point between the integer part and the fractional part is determined by MinHopRankIncrease. MinHopRankIncrease is the minimum increase in rank between a node and any of its DODAG parents. When an objective function computes rank, the objective function operates on the entire (i.e. 16-bit) rank quantity. When rank is compared, e.g. for determination of parent relationships or loop detection, =20= the integer portion of the rank is to be used. The integer portion of the Rank is computed by the DAGRank() macro as follows, where floor(x) is the function that evaluates to the greatest integer less than or equal to x: DAGRank(rank) =3D floor(rank/MinHopRankIncrease) JP> An short example will help the reader MinHopRankIncrease is provisioned at the DODAG Root and propagated =20= in the DIO message. The default value of MinHopRankIncrease is DEFAULT_MIN_HOP_RANK_INCREASE. For efficient implementation the MinHopRankIncrease MUST be a power of 2. An implementation may configure a value MinHopRankIncrease as appropriate to balance between the loop avoidance logic of RPL (i.e. selection of eligible parents) and the metrics in use. JP> Previous sentence requires additional information. A further effect of MinHopRankIncrease is to impact the number increments that are allowed before INFINITE_RANK is reached, i.e. to control how long it may take to count-to-infinity. By convention in this document, using the macro DAGRank(node) may be interpreted as DAGRank(node.rank), where node.rank is the rank value as maintained by the node. Winter, et al. Expires December 30, 2010 [Page 19] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B). A node A has a rank equal to the rank of a node B if DAGRank(A) is equal to DAGRank(B). A node A has a rank greater than the rank of a node B if DAGRank(A) is greater than DAGRank(B). 3.6.2.2. Rank Relationships The computation of the rank MUST be done in such a way so as to maintain the following properties for any nodes M and N that are neighbors in the LLN: DAGRank(M) is less than DAGRank(N): In this case, the position of M is closer to the DODAG root than the position of N. Node M may safely be a DODAG parent for Node N without risk of creating a loop. Further, for a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N). In other words, the rank presented by a node N MUST be greater than that presented by any of its parents. DAGRank(M) equals DAGRank(N): In this case the positions of M and N within the DODAG and with respect to the DODAG root are similar (identical). In some cases, Node M may be used as a successor by Node N, which however entails the chance of creating a loop (which must be detected and resolved by some other means). DAGRank(M) is greater than DAGRank(N): In this case, the position =20= of M is farther from the DODAG root than the position of N. Further, Node M may in fact be in the sub-DODAG of Node N. =20= If node N selects node M as DODAG parent there is a risk to create a loop. As an example, the rank could be computed in such a way so as to closely track ETX (Expected Transmission Count, a fairly common routing metric used in LLN and defined in [I-D.ietf-roll-routing-metrics]) when the objective function is to minimize ETX, or latency when the objective function is to minimize latency, or in a more complicated way as appropriate to the =20 objective function being used within the DODAG. 3.7. Traffic Flows Supported by RPL RPL supports three basic traffic flows: Multipoint-to-Point (MP2P), Point-to-Multipoint (P2MP), and Point-to-Point (P2P). Winter, et al. Expires December 30, 2010 [Page 20] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3.7.1. Multipoint-to-Point Traffic Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). The destinations of MP2P flows are designated nodes that have some application significance, such as providing connectivity to the larger Internet or core private IP network. RPL supports MP2P traffic by allowing MP2P destinations to be reached via DODAG roots. 3.7.2. Point-to-Multipoint Traffic Point-to-multipoint (P2MP) is a traffic pattern required by several LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]). RPL supports P2MP traffic by using a destination advertisement mechanism that provisions routes JP> Use the term "down route" to be consistent with rest of the =20 document. toward destinations (prefixes, addresses, or multicast groups), and away from roots. Destination advertisements can update routing tables as the underlying DODAG topology changes. 3.7.3. Point-to-Point Traffic RPL DODAGs provide a basic structure for point-to-point (P2P) traffic. For a RPL network to support P2P traffic, a root must be able to route packets to a destination. Nodes within the network =20= may also have routing tables to destinations. A packet flows towards a root until it reaches an ancestor that has a known route to the destination. As pointed out later in this document, in the most constrained case (when nodes cannot store routes), that common ancestor may be the DODAG root. In other cases it may be a node closer to both the source and destination. RPL also supports the case where a P2P destination is a 'one-hop' neighbor. RPL neither specifies nor precludes additional mechanisms for computing and installing potentially more optimal routes to support arbitrary P2P traffic. Winter, et al. Expires December 30, 2010 [Page 21] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 4. RPL Instance Within a given LLN, there may be multiple, logically independent RPL instances. A RPL node may belong to multiple RPL instances, and may act as a router in some and as a leaf in others. This document describes how a single instance behaves. There are two types of RPL Instances: local and global. Local RPL Instances are always a single DODAG whose singular root owns the corresponding DODAGID. Local RPL Instances can be used for constructing DODAGs that may be used by future on-demand routing solutions that are outside of the scope of this document. Global =20= RPL Instances have one or more DODAGs and are typically long-lived. RPL divides the RPLInstanceID space between global and local instances =20= to allow for both coordinated and unilateral allocation of RPLInstanceIDs. The definition and provisioning of RPL instances are beyond the =20 scope of this specification. Those operations are expected to be such =20 that data packets coming from the outside of the RPL network can unambiguously be associated to at least one RPL instance, and be safely routed over any instance that would match the packet. Information used to match a packet to a RPL instance can typically =20= be taken from fields in the IPv6 header, like the flow label, TOS bits, JP> Use the term DS Bytes (IPv6) instead of TOS bits or destination address. Control and data packets within RPL network are tagged to unambiguously identify what RPL Instance they are part of. Every RPL control message has a RPLInstanceID field. Some RPL control messages, when referring to a local RPLInstanceID as defined below, may also include a DODAGID. For data packets, the RPLInstanceID may be indicated in the flow label by the source of the packet. If it is not, then it is =20 inferred and added by the RPL network ingress router in the RPL Hop-by-hop option ([I-D.hui-6man-rpl-option]) as further described in Section 10.2 JP> Both "6man" IDs listed here have been accepted as WG doc. Will be =20= resubmitted as such on July 26 4.1. RPL Instance ID A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms for allocating and provisioning global RPLInstanceID are out of =20 scope for this document. There can be up to 128 global instance in the whole network, and up 64 local instances per DODAGID. JP> Since I heard the comment several times, need to clarify what "local instance per DODAGID means" A global RPLinstanceID is encoded in a RPLinstanceID field as follows: Winter, et al. Expires December 30, 2010 [Page 22] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLinstanceID in 0..127 +-+-+-+-+-+-+-+-+ Figure 3: RPL Instance ID field format for global instances A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it MUST be unique for that DODAGID. In that case, the DODAGID MUST be a valid address JP> s/valid address/reachable IPv6 address of the root that is used as an endpoint of all communications within that instance. A local RPLinstanceID is encoded in a RPLinstanceID field as =20 follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|D| ID | Local RPLInstanceID in 0..63 +-+-+-+-+-+-+-+-+ Figure 4: RPL Instance ID field format for local instances The D flag in a Local RPLInstanceID is always set to 0 in RPL =20 control messages. It is used in data packets to indicate whether the =20 DODAGID is the source or the destination of the packet. JP> Requires more explanations If the D flag is set to 1 then the destination address of the IPv6 packet MUST be the DODAGID. If the D flag is clear then the source address of the IPv6 packet MUST be the DODAGID. Winter, et al. Expires December 30, 2010 [Page 23] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 5. ICMPv6 RPL Control Message This document defines the RPL Control Message, a new ICMPv6 message. A RPL Control Message is identified by a code, and composed of a =20 base that depends on the code, and a series of options. A RPL Control Message has the scope of a link. The source address =20= is a link local address. The destination address is either the RPL routers multicast address or a link local address. JP> just a placeholder: we need somewhere to indicate when to use a =20 link local or RPL routers multicast address. The RPL routers multicast address is a new address with a requested value of FF02::1:A (to be confirmed by IANA). In accordance with [RFC4443], the RPL Control Message consists of an ICMPv6 header followed by a message body. The message body is comprised of a message base and possibly a number of options as illustrated in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type | Code | =20 Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . =20 Base . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . =20 Option(s) . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 5: RPL Control Message The RPL Control message is an ICMPv6 information message with a requested Type of 155 (to be confirmed by IANA). The Code field identifies the type of RPL Control Message. This document defines codes for the following RPL Control Message types (all codes are to be confirmed by the IANA Section 18.2): o 0x00: DODAG Information Solicitation (Section 5.2) o 0x01: DODAG Information Object (Section 5.3) o 0x02: Destination Advertisement Object (Section 5.4) Winter, et al. Expires December 30, 2010 [Page 24] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o 0x03: Destination Advertisement Object Acknowledgment (Section 5.5) o 0x80: Secure DODAG Information Solicitation (Section 5.2.2) o 0x81: Secure DODAG Information Object (Section 5.3.2) o 0x82: Secure Destination Advertisement Object (Section 5.4.2) o 0x83: Secure Destination Advertisement Object Acknowledgment (Section 5.5.2) o 0x8A: Consistency Check (Section 5.6) The high order bit (0x80) of the code denotes whether the RPL =20 message has security enabled. Secure RPL messages have a format to support confidentiality and integrity, illustrated in Figure 6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type | Code | =20 Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . =20 Security . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . =20 Base . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . =20 Option(s) . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 6: Secure RPL Control Message The remainder of this section describes the currently defined RPL Control Message Base formats followed by the currently defined RPL Control Message Options. 5.1. RPL Security Fields Each RPL message has a secure version. The secure versions provide integrity and replay protection as well as optional confidentiality and delay protection. Because security covers the base message as Winter, et al. Expires December 30, 2010 [Page 25] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 well as options, in secured messages the security information lies between the checksum and base, as shown in Figure Figure 6. The format of the security section is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ |C|T| Rsrvd |Sec|KIM|Rsrvd| LVL =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 + + | =20 Counter | . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . Message Authentication =20 Code . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . Key =20 Identifier . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 7: Security Section JP>s/Security Section/Security Header All fields are considered as packet payload from a security processing perspective. The exact placement and format of message integrity/authentication codes has not yet been determined. JP> It is. Use of the Security section JP> want to replace "Security section" by Security header" everywhere? is further detailed in Section 17. Security Control Field: The Security Control Field has one flag and three fields: Counter Compression (C): If the Counter Compression flag is set then the Counter field is compressed from 4 bytes into 1 byte. If the Counter Compression flag is clear JP>s/clear/cleared then the Counter field is 4 bytes and uncompressed. Counter is Time (T): If the Counter is Time flag is set then the Counter field is a timestamp. If the flag is =20 cleared then the Counter is an incrementing counter. Section =20= 9.4 describes the details of the 'T' flag and Counter field. Winter, et al. Expires December 30, 2010 [Page 26] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Security Mode (Sec): The security algorithm field specifies what security mode and algorithms the network uses. Supported values of this field are as follows: +----+-----+-------------------+ | ID | Sec | Algorithm | +----+-----+-------------------+ | 0 | 00 | CCM* with AES-128 | | 1 | 01 | Reserved | | 2 | 10 | Reserved | | 3 | 11 | Reserved | +----+-----+-------------------+ Security Mode (Sec) Encoding JP> Need a Table number Key Identifier Mode (KIM): The Key Identifier Mode field indicates whether the key used for packet protection is determined implicitly or explicitly and indicates the particular representation of the Key Identifier field. The Key Identifier Mode is set JP> s/set/set to one of the non-reserved values from the table below: Winter, et al. Expires December 30, 2010 [Page 27] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 +------+-----+-----------------------------+------------+ | Mode | KIM | Meaning | Key | | | | | Identifier | | | | | Length | | | | | (octets) | +------+-----+-----------------------------+------------+ | 0 | 00 | Group key used. | 1 | | | | Key determined by Key Index | | | | | field. | | | | | | | | | | Key Source is not present. | | | | | Key Index is present. | | +------+-----+-----------------------------+------------+ | 1 | 01 | Per-pair key used. | 0 | | | | Key determined by source | | | | | and destination of packet. | | | | | | | | | | Key Source is not present. | | | | | Key Index is not present. | | +------+-----+-----------------------------+------------+ | 2 | 10 | Group key used. | 9 | | | | Key determined by Key Index | | | | | and Key Source Identifier. | | | | | | | | | | Key Source is present. | | | | | Key Index is present. | | +------+-----+-----------------------------+------------+ | 3 | 11 | Node's signature key used. | 0/9 | | | | If packet is encrypted, | | | | group key used. Group key | | | | | determined by Key Index and | | | | | Key Source Identifier. | | | | | | | | | | Key Source may be present. | | | | | Key Index may be present. | | +------+-----+-----------------------------+------------+ Key Identifier Mode (KIM) Encoding JP> Need a table number Security Level (LVL): The Security Level field indicates the provided packet protection. This value can be adapted =20= on a per-packet basis and allows for varying levels of data authenticity and, optionally, for data confidentiality. The KIM field indicates whether signatures are used. =20= The Security Level is set to one of the non-reserved values in the table below: Winter, et al. Expires December 30, 2010 [Page 28] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 +---------------------------+--------------------+ | Without Signatures | With Signatures | +----+-----+--------------------+------+--------------+-----+ | ID | LVL | Attributes | Auth | Attributes | Sig | | | | | Len | | Len | +----+-----+--------------------+------+--------------+-----+ | 0 | 000 | Reserved | N/A | Reserved | N/A | | 1 | 001 | MAC-32 | 4 | Sign-32 | 40 | | 2 | 010 | MAC-64 | 8 | Sign-64 | 44 | | 3 | 011 | Reserved | N/A | Sign-128 | 52 | | 4 | 100 | Reserved | N/A | Reserved | N/A | | 5 | 101 | ENC-MAC-32 | 4 | ENC-Sign-32 | 40 | | 6 | 110 | ENC-MAC-64 | 8 | ENC-Sign-64 | 44 | | 7 | 111 | Reserved | N/A | ENC-Sign-128 | 52 | +----+-----+--------------------+------+-------------+------+ Security Level (LVL) Encoding JP> Need a table number Counter: The Counter field indicates the non-repeating value =20 (nonce) used with the cryptographic mechanism that implements packet protection and allows for the provision of semantic security. This value is compressed from 4 octets to 1 octet if the Counter Compression field of the Security Control Field is set to one. Message Authentication Code: The Message Authentication Code field contains a cryptographic MAC. The length of the MAC is =20 defined by a combination of the LVL and Sec fields: it can be 0, 4, or 8 octets long. In the case of Security Modes where the MAC is computed as part of the ciphertext (as in Security Mode 0, CCM*), the MAC field is zero bytes long. Key Identifier: The Key Identifier field indicates which key was used to protect the packet. This field provides various =20 levels of granularity of packet protection, including peer-to-peer keys, group keys, and signature keys. This field is represented as indicated by the Key Identifier Mode field and is formatted as follows: Winter, et al. Expires December 30, 2010 [Page 29] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . Key =20 Source . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . Key =20 Index . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 8: Key Identifier Key Source: The Key Source field, when present, indicates the logical identifier of the originator of a group key. When present this field is 8 bytes in length. Key Index: The Key Index field, when present, allows unique identification of different keys with the same originator. It is the responsibility of each key originator to make sure that actively used keys that it issues have distinct key indices and that all key =20 indices have a value unequal to 0x00. Value 0x00 is reserved =20= for a pre-installed, shared key. When present this field is 1 byte in length. Unassigned bits of the Security section are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.2. DODAG Information Solicitation (DIS) The DODAG Information Solicitation (DIS) message may be used to solicit a DODAG Information Object from a RPL node. Its use is analogous to that of a Router Solicitation as specified in IPv6 Neighbor Discovery; a node may use DIS to probe its neighborhood for nearby DODAGs. Section 7.3 describes how nodes respond to a DIS. 5.2.1. Format of the DIS Base Object 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Winter, et al. Expires December 30, 2010 [Page 30] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Figure 9: The DIS Base Object Unassigned bits of the DIS Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.2.2. Secure DIS A Secure DIS message follows the format in Figure Figure 6, where =20= the base format is the DIS message shown in Figure Figure 9. JP> Typo: duplicates "Figure" 5.2.3. DIS Options The DIS message MAY carry valid options. This specification allows for the DIS message to carry the following options: 0x00 Pad1 0x01 PadN 0x07 Solicited Information 5.3. DODAG Information Object (DIO) The DODAG Information Object carries information that allows a node to discover a RPL Instance, learn its configuration parameters, select a DODAG parent set, and maintain the upward routing topology. JP> I'd rather say "maintain DODAG" (upward routing topology may be =20 misleading). 5.3.1. Format of the DIO Base Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | RPLInstanceID | Version | =20 Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ |G|0| MOP | Prf | DTSN | =20 Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 DODAGID + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 10: The DIO Base Object Winter, et al. Expires December 30, 2010 [Page 31] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Control Field: The DAG Control Field has three flags and two =20 fields: Grounded (G): The Grounded (G) flag indicates whether the DODAG advertised can satisfy the application-defined goal. If the flag is set, the DODAG is grounded. If =20= the flag is cleared, the DODAG is floating. Mode of Operation (MOP): The Mode of Operation (MOP) field identifies the mode of operation of the RPL Instance as administratively provisioned at and distributed by the DODAG Root. All nodes who join the DODAG must be able =20= to honor the MOP in order to fully participate as a router, or else they must only join as a leaf. MOP is encoded =20= as in the table below: +-----=20 +-------------------------------------------------+ | MOP | =20 Meaning | +-----=20 +-------------------------------------------------+ | 000 | No downward routes maintained by =20 RPL | | 001 | Non storing =20 mode | | 010 | Storing without multicast =20 support | | 011 | Storing with multicast =20 support | | =20 | | | | All other values are =20 reserved | +-----=20 +-------------------------------------------------+ A value of 000 indicates that destination advertisement messages are disabled and the DODAG maintains only =20 upward routes Mode of Operation (MOP) Encoding JP> indicate that similarly to the supported set of OF, metrics, ... =20 if a node does not comply with the advertised MOP it can join as a leaf node. DODAGPreference (Prf): A 3-bit unsigned integer that defines how preferable the root of this DODAG is compared to other DODAG roots within the instance. DAGPreference ranges from 0x00 (least preferred) to 0x07 (most preferred). The default is 0 (least preferred). Section 7.2 describes how DAGPreference affects DIO processing. Version Number: 8-bit unsigned integer set by the DODAG root. Section 7.2 describes the rules for version numbers and how they affect DIO processing. Winter, et al. Expires December 30, 2010 [Page 32] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Rank: 16-bit unsigned integer indicating the DODAG rank of the node sending the DIO message. Section 7.2 describes how Rank is =20= set and how it affects DIO processing. RPLInstanceID: 8-bit field set by the DODAG root that indicates which RPL Instance the DODAG is part of. Destination Advertisement Trigger Sequence Number (DTSN): 8-bit unsigned integer set by the node issuing the DIO message. The Destination Advertisement Trigger Sequence Number (DTSN) flag is used as part of the procedure to maintain downward routes. The details of this process are described in Section 8. DODAGID: 128-bit unsigned integer set by a DODAG root which =20 uniquely identifies a DODAG. Possibly derived from the IPv6 address of the DODAG root. JP> has to be a reachable IPv6 address in some cases (non storing with =20= DAO, ...) Unassigned bits of the DIO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.3.2. Secure DIO A Secure DIO message follows the format in Figure Figure 6, where =20= the base format is the DIS message shown in Figure Figure 10. 5.3.3. DIO Options The DIO message MAY carry valid options. This specification allows for the DIO message to carry the following options: 0x00 Pad1 0x01 PadN 0x02 Metric Container 0x03 Routing Information 0x04 DODAG Configuration 0x08 Prefix Information 5.4. Destination Advertisement Object (DAO) The Destination Advertisement Object (DAO) is used to propagate destination information upwards along the DODAG. The DAO message is unicast by the child to the selected parent(s). The DAO message may optionally, upon explicit request or error, be acknowledged by the parent with a Destination Advertisement Acknowledgement (DAO-ACK) message back to the child. Winter, et al. Expires December 30, 2010 [Page 33] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 5.4.1. Format of the DAO Base Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | RPLInstanceID |K|D| Reserved | =20 DAOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 DODAGID* + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 11: The DAO Base Object JP> Indicate that the * in the Figure 11 (after DODAG) means "not =20 always present" RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. K: The 'K' flag indicates that the parent is expected to send a DAO-ACK back. JP> Placeholder: we need to explain what a child does if it does not =20 receive a reply to a DAO with K set (e.g. try a limited number of retries and then =20 stop, detach ). D: The 'D' flag indicates that the DODAGID field is present. =20 This flag MUST be set when a local RPLInstanceID is used. DAOSequence: Incremented at each unique DAO message, echoed in the DAO-ACK message. DODAGID (optional): 128-bit unsigned integer set by a DODAG root which uniquely identifies a DODAG. This field is only present when the 'D' flag is set. This field is typically only =20 present when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use this field need not be present. JP> The refers to a previous comment about the local instance. By =20 regrouping the pieces together, the reader can understand how this works, but we should have =20= a section with an example describing the mode of operation of local DODAG. That's missing. Unassigned bits of the DAO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.4.2. Secure DAO A Secure DAO message follows the format in Figure Figure 6, where =20= the base format is the DAO message shown in Figure Figure 11. Winter, et al. Expires December 30, 2010 [Page 34] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 5.4.3. DAO Options The DAO message MAY carry valid options. This specification allows for the DAO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information A special case of the DAO message, termed a No-Path, is used to =20 clear downward routing state that has been provisioned through DAO operation. The No-Path carries a RPL Transit Information option, which identifies the destination to which the DAO is associated, =20 with a lifetime of 0x00000000 to indicate a loss of reachability. 5.5. Destination Advertisement Object Acknowledgement (DAO-ACK) The DAO-ACK message is sent as a unicast packet by a DAO parent in response to a unicast DAO message from a child. 5.5.1. Format of the DAO-ACK Base Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | RPLInstanceID |D| Reserved | DAOSequence | =20 Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 DODAGID* + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 12: The DAO ACK Base Object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. Winter, et al. Expires December 30, 2010 [Page 35] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 D: The 'D' flag indicates that the DODAGID field is present. =20 This would typically only be set when a local RPLInstanceID is =20 used. DAOSequence: Incremented at each DAO message from a given child, echoed in the DAO-ACK by the parent. The DAOSequence serves =20= in the parent-child communication and is not to be confused with the Transit Information option Sequence that is associated =20 to a given target down the DODAG. Status: Indicates the completion. 0 is unqualified acceptance, =20 above 128 are rejection code indicating that the node should select an alternate parent. JP> In between values are undetermined DODAGID (optional): 128-bit unsigned integer set by a DODAG root which uniquely identifies a DODAG. This field is only present when the 'D' flag is set. This field is typically only =20 present when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use this field need not be present. Unassigned bits of the DAO-ACK Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.5.2. Secure DAO-ACK A Secure DAO-ACK message follows the format in Figure Figure 6, =20 where the base format is the DAO-ACK message shown in Figure Figure 12. 5.5.3. DAO-ACK Options This specification does not define any options to be carried by the DAO-ACK message. 5.6. Consistency Check (CC) The CC message is used to check secure message counters and issue challenge/responses. A CC message MUST be sent as a secured RPL message. A CC message (request or response) MUST NOT set the 'C' bit of the security section: CC messages always have full counters. 5.6.1. Format of the CC Base Object Winter, et al. Expires December 30, 2010 [Page 36] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | RPLInstanceID |R| Reserved | =20 Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 DODAGID + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Destination =20 Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 13: The CC Base Object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. R: The 'R' flag indicates whether the CC message is a =20 response. A message with the 'R' flag cleared is a request; a message with the 'R' flag set is a response. A CC message with the R bit set MUST NOT compress the security Counter field: the C bit of the security section MUST be 0. Nonce: 16-bit unsigned integer set by a CC request. The corresponding CC response includes the same nonce value as the request. Destination Counter: 32-bit unsigned integer value indicating the sender's estimate of the destination's current security =20 Counter value. If the sender does not have an estimate, it SHOULD set the Destination Counter field to zero. Unassigned bits of the CC Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. The Destination Counter value allows new or recovered nodes to resynchronize through CC message exchanges. This is important to ensure that a Counter value is not repeated for a given security key even in the event of devices recovering from a failure that =20 created a loss of Counter state. For example, where a CC request or other RPL message is received with an initialized Counter within the message security section, the provision of the Incoming Counter within the =20= CC Winter, et al. Expires December 30, 2010 [Page 37] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 response message allows the requesting node to reset its Outgoing Counter to a value greater than the last value received by the responding node; the Incoming Counter will also be updated from the received CC response. 5.6.2. CC Options The CC message MAY carry valid options. In the scope of this specification, there are no valid options for a CC message. This specification allows for the CC message to carry the following options: 0x00 Pad1 0x01 PadN 5.7. RPL Control Message Options 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in =20= the message. RPL message options may have alignment requirements. Following the convention in IPv6, options with alignment requirements are aligned in a packet such that multi-octet values within the Option Data =20 field Winter, et al. Expires December 30, 2010 [Page 38] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n =3D 1, 2, 4, or 8). 5.7.2. Pad1 The Pad1 option may be present in DIS, DIO, DAO, and DAO-ACK messages, and its format is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type =3D 0 | +-+-+-+-+-+-+-+-+ Figure 15: Format of the Pad 1 Option The Pad1 option is used to insert one or two octets of padding into the message to enable options alignment. If more than one octet of padding is required, the PadN option should be used rather than multiple Pad1 options. NOTE! the format of the Pad1 option is a special case - it has neither Option Length nor Option Data fields. 5.7.3. PadN The PadN option may be present in DIS, DIO, DAO, and DAO-ACK messages, and its format is as follows: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Type =3D 1 | Option Length | 0x00 Padding... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 16: Format of the Pad N Option The PadN option is used to insert two or more octets of padding into the message to enable options alignment. PadN Option data MUST be ignored by the receiver. Winter, et al. Expires December 30, 2010 [Page 39] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Option Type: 0x01 (to be confirmed by IANA) Option Length: For N (N > 1) octets of padding, the Option Length field contains the value N-2. Option Data: For N (N > 1) octets of padding, the Option Data consists of N-2 zero-valued octets. 5.7.4. Metric Container The Metric Container option may be present in DIO messages, and its format is as follows: JP> s/may/MAY 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Type =3D 2 | Option Length | Metric Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 17: Format of the Metric Container Option The Metric Container is used to report metrics along the DODAG. The Metric Container may contain a number of discrete node, link, and aggregate path metrics and constraints specified in [I-D.ietf-roll-routing-metrics] as chosen by the implementer. The Metric Container MAY appear more than once in the same RPL control message, for example to accommodate a use case where the Metric Data is longer than 256 bytes. More information is in [I-D.ietf-roll-routing-metrics] JP> "." missing The processing and propagation of the Metric Container is governed =20= by implementation specific policy functions. Option Type: 0x02 (to be confirmed by IANA) Option Length: The Option Length field contains the length in =20 octets of the Metric Data. Metric Data: The order, content, and coding of the Metric Container data is as specified in [I-D.ietf-roll-routing-metrics]. 5.7.5. Route Information The Route Information option may JP> s/may/MAY be present in DIO messages, and is equivalent in function to the IPv6 ND JP> Expand ND: Neighbor Discovery Route Information option as defined in [RFC4191]. The format of the option is modified slightly Winter, et al. Expires December 30, 2010 [Page 40] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 (Type, Length, Prefix) in order to be carried as a RPL option as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 3 | Option Length | Prefix Length |Resvd|Prf|=20 Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Route =20 Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | . Prefix (Variable =20 Length) . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 18: Format of the Route Information Option The Route Information option is used to indicate that connectivity =20= to the specified destination prefix is available from the DODAG root. In the event that a RPL Control Message may need to specify connectivity to more than one destination, the Route Information option may be repeated. [RFC4191] should be consulted as the authoritative reference with respect to the Route Information option. The field descriptions are transcribed here for convenience: Option Type: 0x03 (to be confirmed by IANA) Option Length: Variable, length of the option in octets excluding the Type and Length fields. Note that this length is =20 expressed in units of single-octets, unlike in IPv6 ND. Prefix Length 8-bit unsigned integer. The number of leading bits =20= in the Prefix that are valid. The value ranges from 0 to 128. The Prefix field has the number of bytes inferred from the Option Length field, that must be at least the Prefix Length. Note that in RPL this means that the Prefix field may have lengths other than 0, 8, or 16. Prf: 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. If the Reserved (10) value is received, the Route Information Option MUST be ignored. JP> Explain the use of Reserved Value=3D10 Winter, et al. Expires December 30, 2010 [Page 41] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Resvd: Two 3-bit unused fields. They MUST be initialized to zero =20= by the sender and MUST be ignored by the receiver. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix =20= of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix =20 after the prefix length (if any) are reserved and MUST be =20 initialized to zero by the sender and ignored by the receiver. Note that in RPL this field may have lengths other than 0, 8, or 16. JP> need to say that Route Information can be inserted by any node =20 along the DODAG. Unassigned bits of the Route Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on =20 reception. 5.7.6. DODAG Configuration The DODAG Configuration option may JP> s/may/MAY be present in DIO messages, and its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 4 | Option Length | Resrvd|A| PCS | =20 DIOIntDoubl. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | DIOIntMin. | DIORedun. | =20 MaxRankIncrease | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | MinHopRankIncrease | =20 OCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 19: Format of the DODAG Configuration Option The DODAG Configuration option is used to distribute configuration information for DODAG Operation through the DODAG. The information communicated in this option is generally static and unchanging within the DODAG, therefore it is not necessary to =20 include in every DIO. This information is configured at the DODAG Root and distributed throughout the DODAG with the DODAG Configuration =20 Option. Nodes other than the DODAG Root MUST NOT modify this information =20 when propagating the DODAG Configuration option. This option MAY be included occasionally by the DODAG Root (as determined by the DODAG Root), and MUST be included in response to a unicast request, e.g. a unicast DODAG Information Solicitation (DIS) message. Winter, et al. Expires December 30, 2010 [Page 42] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Option Type: 0x04 (to be confirmed by IANA) Option Length: 8 bytes Authentication Enabled (A): One bit describing the security mode of the network. The bit describe whether a node must =20 authenticate with a key authority before joining the network as a router. If the DIO is not a secure DIO, the 'A' bit MUST be zero. Path Control Size (PCS): 3-bit unsigned integer used to configure the number of bits that may be allocated to the Path Control field (see Section 8.9). Note that as used a value of 1 is added to this field, i.e. a PCS value of 0 results in 1 active bit in the Path Control field. The default value of PCS is DEFAULT_PATH_CONTROL_SIZE. DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax of the DIO trickle timer (see Section 7.3.1). DIOIntervalMin: 8-bit unsigned integer used to configure Imin of =20= the DIO trickle timer (see Section 7.3.1). DIORedundancyConstant: 8-bit unsigned integer used to configure k =20= of the DIO trickle timer (see Section 7.3.1). JP> Add a reference to the default values MaxRankIncrease: 16-bit unsigned integer used to configure DAGMaxRankIncrease, the allowable increase in rank in support of local repair. If DAGMaxRankIncrease is 0 then this mechanism is disabled. MinHopRankInc 16-bit unsigned integer used to configure MinHopRankIncrease as described in Section 3.6.2.1. Objective Code Point (OCP) 16-bit unsigned integer. The OCP field identifies the OF and is managed by the IANA. JP> s/the IANA/IANA 5.7.7. RPL Target The RPL Target option format is as follows: JP> ADD: "The RPL Target option MAY be present either in DIO or DAO =20 messages." Winter, et al. Expires December 30, 2010 [Page 43] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 5 | Option Length | Reserved | Prefix =20 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + | Target Prefix (Variable =20 Length) | . = . . = . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 20: Format of the RPL Target Option The RPL Target Option is used to indicate a target IPv6 address, prefix, or multicast group that is reachable or queried along the DODAG. In a DIO, the RPL Target Option identifies a resource that the root is trying to reach. JP> I would add a sentence to indicate that in DIO this for a query by =20= contrast with Route information. In a DAO, the RPL Target option indicates reachability. A set of one or more Transit Information options JP> Add "defined in Section 5.7.8" MAY directly follow the Target option in a DAO message in support of constructing source routes in a non-storing mode of operation [I-D.hui-6man-rpl-routing-header]. When the same set of Transit Information options apply equally to a set of DODAG Target options, the group of Target options MUST appear first, followed by the Transit Information options which apply to those Targets. JP> Not very clear ... example please The RPL Target option may be repeated as necessary to indicate multiple targets. Option Type: 0x05 (to be confirmed by IANA) Option Length: Variable, length of the option in octets excluding the Type and Length fields. Prefix Length: 8-bit unsigned integer. Number of valid leading =20 bits in the IPv6 Prefix. Target Prefix: Variable-length field identifying an IPv6 =20 destination address, prefix, or multicast group. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be set to zero on transmission and MUST be ignored on receipt. Winter, et al. Expires December 30, 2010 [Page 44] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 5.7.8. Transit Information The Transit Information option may JP> s/may/MAY be present in DAO messages, and its format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 6 | Option Length | Path Sequence | Path =20 Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Path =20 Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + Parent =20 Address* + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Figure 21: Format of the Transit Information option The Transit Information option is used for a node to indicate attributes for a path to one or more destinations. The destinations are indicated as by one or more Target options that immediately precede the Transit Information option(s). The Transit Information option can used for a node to indicate its DODAG parents to an ancestor that is collecting DODAG routing information, typically for the purpose of constructing source =20 routes. In the non-storing mode of operation this ancestor will be the DODAG Root, and this option is carried by the DAO message. The option length is used to determine whether the Parent Address is present or not. JP> Why is the Parent Address optional ? A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non- storing Destination Advertisement JP> Why capitalized D and A ? operation. The node may code the Path Control field in order to signal a preference among parents. One or more Transit Information options MUST be preceded by one or more RPL Target options. In this manner the RPL Target option indicates the child node, and the Transit Information option(s) enumerate the DODAG parents. JP> This is the ideal place to add an example (with two DAO parents) Winter, et al. Expires December 30, 2010 [Page 45] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 A typical non-storing node will use multiple Transit Information options, and it will send the DAO thus formed to only one parent =20 that will forward it to the root. A typical storing node with JP> s/with/will use one Transit Information option with no parent field, and will send the DAO thus formed to multiple parents. JP> Two comments: 1) This is where we explain when there is no Parent address (again an =20= example with both cases will help the reader) 2) This may be sent to *one* parent too. Option Type: 0x06 (to be confirmed by IANA) Option Length: Variable, depending on whether or not Parent Address is present. Path-Sequence: 8-bit unsigned integer. When a RPL Target option is issued by the node that owns the Target Prefix (i.e. in a DAO message), that node sets the Path-Sequence and increments the Path-Sequence each time it issues a RPL Target option. Path Control: 8-bit bitfield. The Path Control field limits the number of DAO-Parents to which a DAO message advertising connectivity to a specific destination may be sent, as well as providing some indication of relative preference. The limit provides some bound on overall DAO fan-out in the LLN. The leftmost bit is associated with a path that contains a most- preferred link, and the subsequent bits are ordered down to =20= the rightmost bit which is least preferred. JP> No comment here since there is already a thread on this (ticket #60) Path Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xFFFFFFFF) represents infinity. A value of all zero bits (0x00000000) indicates a loss of reachability. This is referred as a No-Path in this document. Parent Address (optional): IPv6 Address of the DODAG Parent of the node originally issuing the Transit Information Option. This field may not be present, as according to the DODAG Mode of Operation JP> Add (storing versus non-storing mode) and indicated by the Transit Information option length. Unassigned bits of the Transit Information option are reserved. =20 They MUST be set to zero on transmission and MUST be ignored on =20 reception. 5.7.9. Solicited Information The Solicited Information option may be present in DIS messages, and its format is as follows: Winter, et al. Expires December 30, 2010 [Page 46] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 7 | Option Length | RPLInstanceID |V|I|D| =20 Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 DODAGID + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Version | +-+-+-+-+-+-+-+-+ Figure 22: Format of the Solicited Information Option The Solicited Information option is used for a node to request DIO messages from a subset of neighboring nodes. The Solicited Information option may specify a number of predicate criteria to be matched by a receiving node. JP> This is used to limit the number of replies from "non-interesting" =20= node for the requester. These predicates affect whether a node resets its DIO trickle timer, as described in Section 7.3 Option Type: 0x07 (to be confirmed by IANA) Option Length: 19 bytes Control Field: The Solicited Information option Control Field has three flags: V: If the V flag is set then the Version field is valid and a node matches the predicate if its DODAGVersionNumber matches the requested version. If the V flag is clear then the Version field is not valid and the Version =20 field MUST be set to zero on transmission and ignored upon receipt. JP> Why not just not include the Version field if V=3D0 I: If the I flag is set then the RPLInstanceID field is valid and a node matches the predicate if it matches the requested RPLInstanceID. If the I flag is clear then =20= the RPLInstanceID field is not valid and the RPLInstanceID field MUST be set to zero on transmission and ignored upon receipt. Winter, et al. Expires December 30, 2010 [Page 47] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 D: If the D flag is set then the DODAGID field is valid and a node matches the predicate if it matches the requested DODAGID. If the D flag is clear JP>s/clear/cleared then the DODAGID field is not valid and the DODAGID field MUST be set to zero =20= on transmission and ignored upon receipt. Version: 8-bit unsigned integer containing the DODAG Version number that is being solicited when valid. RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID that is being solicited when valid. DODAGID: 128-bit unsigned integer containing the DODAGID that is being solicited when valid. Unassigned bits of the Solicited Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 5.7.10. Prefix Information The Prefix Information option may JP>s/may/MAY be present in DIO messages, and is equivalent in function to the IPv6 ND Prefix Information option as defined in [RFC4861]. The format of the option is modified slightly (Type, Length, Prefix) in order to be carried as a RPL option as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Type =3D 8 | Option Length | Prefix Length |L|A| =20 Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Valid =20 Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | Preferred =20 Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | =20 Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | =20 + + =20 | | + =20 Prefix + =20 | | =20 + + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ Winter, et al. Expires December 30, 2010 [Page 48] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Figure 23: Format of the Prefix Information Option The Prefix Information option may be used to distribute the prefix =20= in use inside the DODAG, e.g. for address autoconfiguration. [RFC4861] should be consulted as the authoritative reference with respect to the Prefix Information option. The field descriptions =20= are transcribed here for convenience: Option Type: 0x08 (to be confirmed by IANA) Option Length: 30. Note that this length is expressed in units of single-octets, unlike in IPv6 ND. Prefix Length 8-bit unsigned integer. The number of leading bits =20= in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on- link determination (when combined with the L flag in the =20 prefix information option). It also assists with address autoconfiguration as specified in [RFC4862], for which there may be more restrictions on the prefix length. L 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determination. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the L flag is =20= not set a host MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link. A 1-bit autonomous address-configuration flag. When set indicates that this prefix can be used for stateless address configuration as specified in [RFC4862]. Reserved1 6-bit unused field. It MUST be initialized to zero by =20= the sender and MUST be ignored by the receiver. Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [RFC4862]. Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [RFC4862]. A value of all one bits (0xffffffff) represents infinity. See [RFC4862]. Winter, et al. Expires December 30, 2010 [Page 49] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no =20 longer valid. Reserved2 This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix An IP address or a prefix of an IP address. JP>s/IP/IPv6 The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix and a host SHOULD ignore such a prefix option. A non-storing node SHOULD refrain from advertising a prefix till it owns an address of that prefix, and then it SHOULD advertise its full address in this field, =20= to be used by its children in the Parent Address field of the Transit Information Option JP> Not clear ... "to be used by its children in the Parent Address =20 field of the Transit Information Option" Unassigned bits of the Prefix Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on =20 reception. Winter, et al. Expires December 30, 2010 [Page 50] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 6. Sequence Counters This section describes the general scheme for bootstrap and =20 operation of sequence counters in RPL, such as the DODAGVersionNumber in the DIO message, the DAOSequence in the DAO message, and the Path- Sequence in the Transit Information option. RPL sequence counters are subdivided in a 'lollipop' fashion ([Perlman83]), where the values from 128 and greater are used as a linear sequence to indicate a restart and bootstrap the counter, and the values less than or equal to 127 used as a circular sequence number space of size 128 as in [RFC1982]. Consideration is given to the mode of operation when transitioning from the linear region to the circular region. Finally, when operating in the circular =20 region, if sequence numbers are detected to be too far apart then they are not comparable, as detailed below. A window of comparison, SEQUENCE_WINDOW =3D 16, is configured based = on a value of 2^N, where N=3D4. JP> Is N advertised, locally configured, ... For a given sequence counter, 1. The sequence counter SHOULD be initialized to an implementation defined value which is 128 or greater prior to use. A recommended value is 240 (256 - SEQUENCE_WINDOW). 2. When a sequence counter increment would cause the sequence counter to increment beyond its maximum value, the sequence counter MUST wrap back to zero. When incrementing a sequence counter greater than or equal to 128, the maximum value is 255. When incrementing a sequence counter less than 128, the maximum value is 127. 3. When comparing two sequence counters, the following rules MUST =20= be applied: 1. When a first sequence counter A is in the interval [0..127] and a second sequence counter B is in [128..255]: 1. If B-A is less than or equal to SEQUENCE_WINDOW, then B is greater than A, A is less than B, and the two are not equal. 2. If B-A is greater than SEQUENCE_WINDOW, then A is =20 greater than B, B is less than A, and the two are not equal. Winter, et al. Expires December 30, 2010 [Page 51] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 2. In the case where both sequence counters to be compared are less than or equal to 127, and in the case where both sequence counters to be compared are greater than or equal =20= to 128: 1. If the absolute magnitude of difference between the two sequence counters is less than or equal to SEQUENCE_WINDOW, then a comparison as described in [RFC1982] is used to determine the relationships greater than, less than, and equal 2. If the absolute magnitude of difference of the two sequence counters is greater than SEQUENCE_WINDOW, =20 then a desynchronization has occurred and the two sequence numbers are not comparable. 4. If two sequence numbers are determined to be not comparable, =20 i.e. the results of the comparison are not defined, then a node =20 should consider the comparison as if it has evaluated in such a way so as to give precedence to the sequence number that has most recently been observed to increment. Failing this, the node should consider the comparison as if it has evaluated in such a way so as to minimize the resulting changes to its own state. Winter, et al. Expires December 30, 2010 [Page 52] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 7. Upward Routes This section describes how RPL discovers and maintains upward =20 routes. It describes the use of DODAG Information Objects (DIOs), the messages used to discover and maintain these routes. It specifies how RPL generates and responds to DIOs. It also describes DODAG Information Solicitation (DIS) messages, which are used to trigger DIO transmissions. 7.1. DIO Base Rules 1. For the following DIO Base fields, a node that is not a DODAG root MUST advertise the same values as its preferred DODAG =20 parent (defined in Section 7.2.1). Therefore, if a DODAG root does not change these values, every node in a route to that DODAG root eventually advertises the same values for these fields. JP> Previous sentence not clear ... These fields are: 1. Grounded (G) 2. Mode of Operation (MOP) 3. DAGPreference (Prf) 4. Version 5. RPLInstanceID 6. DODAGID 2. A node MAY update the following fields at each hop: 1. Rank 2. DTSN 3. The DODAGID field each root sets MUST be unique within the RPL Instance. JP> Add: "As a reminder, DODAGID management is outside of the scope of =20= this document". 7.2. Upward Route Discovery and Maintenance Upward route discovery allows a node to join a DODAG by discovering neighbors that are members of the DODAG of interest and =20 identifying a set of parents. The exact policies for selecting neighbors and parents is implementation-dependent and driven by the OF. This section specifies the set of rules those policies must follow for interoperability. 7.2.1. Neighbors and Parents within a DODAG Version RPL's upward route discovery algorithms and processing are in terms of three logical sets of link-local nodes. First, the candidate neighbor set is a subset of the nodes that can be reached via link- local multicast. The selection of this set is implementation- dependent and OF-dependent. Second, the parent set is a restricted subset of the candidate neighbor set. Finally, the preferred =20 parent, Winter, et al. Expires December 30, 2010 [Page 53] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 a set of size one, is an element of the parent set that is the preferred next hop in upward routes. JP> There may be more than one element in the preferred parent set (e.g. load balancing) depending on the OF. More precisely: 1. The DODAG parent set MUST be a subset of the candidate neighbor set. 2. A DODAG root MUST have a DODAG parent set of size zero. 3. A node that is not a DODAG root MAY maintain a DODAG parent set of size greater than or equal to one. 4. A node's preferred DODAG parent MUST be a member of its DODAG parent set. 5. A node's rank MUST be greater than all elements of its DODAG parent set. 6. When Neighbor Unreachability Detection (NUD), JP> Add ref or an equivalent mechanism, determines that a neighbor is no longer reachable, a RPL node MUST NOT consider this node in the candidate neighbor set when calculating and advertising routes until it determines that it is again reachable. Routes through an unreachable neighbor MUST be removed from the routing table. These rules ensure that there is a consistent partial order on nodes within the DODAG. As long as node ranks do not change, following =20= the above rules ensures that every node's route to a DODAG root is loop- free, as rank decreases on each hop to the root. The OF can guide candidate neighbor set and parent set selection, as discussed in [I-D.ietf-roll-routing-metrics] and [I-D.ietf-roll-=20 of0]. 7.2.2. Neighbors and Parents across DODAG Versions The above rules govern a single DODAG version. The rules in this section define how RPL operates when there are multiple DODAG versions: 7.2.2.1. DODAG Version 1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely defines a DODAG Version. Every element of a node's DODAG parent set, as conveyed by the last heard DIO message from each DODAG parent, MUST belong to the same DODAG version. Elements of a node's candidate neighbor set MAY belong to different DODAG Versions. Winter, et al. Expires December 30, 2010 [Page 54] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 2. A node is a member of a DODAG version if every element of its DODAG parent set belongs to that DODAG version, or if that node is the root of the corresponding DODAG. 3. A node MUST NOT send DIOs for DODAG versions of which it is =20 not a member. 4. DODAG roots MAY increment the DODAGVersionNumber that they advertise and thus move to a new DODAG version. When a DODAG root increments its DODAGVersionNumber, it MUST follow the conventions of Serial Number Arithmetic as described in Section 6. JP> Add: Events triggering the increment of the DODAGVersionNumber are =20= discussed later in this section and in Section 16. 5. Within a given DODAG, a node that is a not a root MUST NOT advertise a DODAGVersionNumber higher than the highest DODAGVersionNumber it has heard. Higher is defined as the greater-than operator in Section 6. 6. Once a node has advertised a DODAG version by sending a DIO, it MUST NOT be member JP>s/be member/be a member? of a previous DODAG version of the same DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a lower DODAGVersionNumber). Lower is defined as the less-than operator in Section 6. When the DODAG parent set becomes empty on a node that is not a =20 root, (i.e. the last parent has been removed, causing the node to no =20 longer be associated with that DODAG), then the DODAG information should =20= not be suppressed until after the expiration of an implementation- specific local timer in order to observe if the DODAGVersionNumber has been incremented, should any new parents appear for the DODAG. This will help protect against the possibility of loops that may occur of JP> s/of/if that node were to inadvertently rejoin the old DODAG version in its own prior sub-DODAG. JP> need to add a few sentence to better explain this case. This was =20 discussed on the list but should be reminded here. As the DODAGVersionNumber is incremented, a new DODAG Version =20 spreads outward from the DODAG root. A parent that advertises the new DODAGVersionNumber cannot belong to the sub-DODAG of a node advertising an older DODAGVersionNumber. Therefore a node can =20 safely add a parent of any Rank with a newer DODAGVersionNumber without forming a loop. Exactly when a DODAG Root increments the DODAGVersionNumber is implementation and application-dependent and outside the scope of this document. Examples include incrementing the DODAGVersionNumber periodically, upon administrative intervention, or on application- level detection of lost connectivity or DODAG inefficiency. After a node transitions to and advertises a new DODAG Version, the Winter, et al. Expires December 30, 2010 [Page 55] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 rules above make it unable to advertise the previous DODAG Version (prior DODAGVersionNumber) once it has committed to advertising the new DODAG Version. 7.2.2.2. DODAG Roots 1. A DODAG root without possibility to satisfy the application- defined goal MUST NOT set the Grounded bit. 2. A DODAG root MUST advertise a rank of ROOT_RANK. 3. A node whose DODAG parent set is empty MAY become the DODAG Root of a floating DODAG. It MAY also set its DAGPreference such =20 that it is less preferred. In a deployment that uses a backbone link to federate a number of =20= LLN roots, it is possible to run RPL over that backbone and use one router as a "backbone root". The backbone root is the virtual root of the DODAG, and exposes a rank of BASE_RANK over the backbone. =20= All the LLN roots that are parented to that backbone root, including the backbone root if it also serves as LLN root itself, expose a rank of ROOT_RANK to the LLN. These virtual roots are part of the same =20 DODAG and advertise the same DODAGID. They coordinate DODAGVersionNumbers and other DODAG parameters with the virtual root over the backbone. JP> how to they coordinate? 7.2.2.3. DODAG Selection The objective function JP> And the set of advertised routing metrics and constraints of a DAG determines how a node selects its neighbor set, parent set, and preferred parents. This selection implicitly also decides JP> "decides" ? the DODAG within a DAG. Such selection can include administrative preference (Prf) as well as metrics or other considerations. If a node has the option to join a more preferred DODAG while still meeting other optimization objectives, then the node will generally seek to join the more preferred DODAG as determined by the OF. All else being equal, it is left to the implementation to determine =20 which DODAG is most preferred. JP> "since as a reminder a node can only join one DODAG" 7.2.2.4. Rank and Movement within a DODAG Version 1. A node MUST NOT advertise a Rank less than or equal to any =20 member of its parent set within the DODAG Version. 2. A node MAY advertise a Rank lower than its prior advertisement within the DODAG Version. Winter, et al. Expires December 30, 2010 [Page 56] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 3. Let L be the lowest rank within a DODAG version that a given =20 node has advertised. Within the same DODAG Version, that node MUST NOT advertise an effective rank higher than L + DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: a node MAY advertise an INFINITE_RANK within a DODAG version without restriction. If a node's Rank would be higher than allowed by L + DAGMaxRankIncrease, when it advertises Rank it MUST advertise its Rank as INFINITE_RANK. 4. A node MAY, at any time, choose to join a different DODAG within a RPL Instance. Such a join has no rank restrictions, unless that different DODAG is a DODAG Version of which this node has previously been a member, in which case the rule of the previous bullet (3) must be observed. JP> Need to explain a bit more this case Until a node transmits a DIO indicating its new DODAG membership, it MUST forward packets along the previous DODAG. 5. A node MAY, at any time after hearing the next =20 DODAGVersionNumber advertised from suitable DODAG parents, choose to migrate to the next DODAG Version within the DODAG. Conceptually, an implementation is maintaining a DODAG parent set within the DODAG Version. Movement entails changes to the DODAG parent set. Moving up does not present the risk to create a loop =20= but moving down might, so that operation is subject to additional constraints. When a node migrates to the next DODAG Version, the DODAG parent set needs to be rebuilt for the new version. An implementation could defer to migrate for some reasonable amount of time, to see if some other neighbors with potentially better metrics but higher rank announce themselves. Similarly, when a node jumps into a new DODAG it needs to construct new a DODAG parent set for this new DODAG. If a node needs to move down a DODAG that it is attached to, increasing its Rank, then it MAY poison its routes and delay before moving as described in Section 7.2.2.5. 7.2.2.5. Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set. JP> Explain why rule 2. Although an implementation may advertise INFINITE_RANK for the purposes of poisoning, doing so is not the same as setting Rank to INFINITE_RANK. For example, a node may continue to send data =20 packets Winter, et al. Expires December 30, 2010 [Page 57] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 whose meta-data JP> Need to define the term "meta-data" include a Rank that is not INFINITE_RANK yet still advertise INFINITE_RANK in its DIOs. 7.2.2.6. Detaching 1. A node unable JP> What do we mean by "unable" ? to stay connected to a DODAG within a given DODAG version MAY detach from this DODAG version. A node that =20 detaches becomes root of its own floating DODAG and SHOULD immediately advertise this new situation in a DIO as an alternate to poisoning. JP> Remove the "1." if there is no 2. 7.2.2.7. Following a Parent 1. If a node receives a DIO from one of its DODAG parents, indicating that the parent has left the DODAG, that node SHOULD stay in its current DODAG through an alternative DODAG parent, =20= if possible. It MAY follow the leaving parent. JP> Remove 1. A DODAG parent may have moved, migrated to the next DODAG Version, =20= or jumped to a different DODAG. A node should JP> s/should/SHOULD give some preference to remaining in the current DODAG, if possible via an alternate parent, but ought to follow the parent if there are no other options. 7.2.3. DIO Message Communication When an DIO message is received, the receiving node must first determine whether or not the DIO message should be accepted for further processing, and subsequently present the DIO message for further processing if eligible. 1. If the DIO message is malformed, then the DIO message is not eligible for further processing and a node MUST silently discard it. JP> Add: See Section 16 for error logging. 2. If the sender of the DIO message is a member of the candidate neighbor set and the DIO message is not malformed, the node MUST process the DIO. 7.2.3.1. DIO Message Processing As DIO messages are received from candidate neighbors, the neighbors may be promoted to DODAG parents by following the rules of DODAG discovery as described in Section 7.2. When a node places a =20 neighbor into the DODAG parent set, the node becomes attached to the DODAG through the new DODAG parent node. The most preferred parent should be used to restrict which other nodes may become DODAG parents. Some nodes in the DODAG parent set Winter, et al. Expires December 30, 2010 [Page 58] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 may be of a rank less than or equal to the most preferred DODAG parent. (This case may occur, for example, if an energy constrained device is at a lesser rank but should be avoided as per an optimization objective, resulting in a more preferred parent at a greater rank). 7.3. DIO Transmission RPL nodes transmit DIOs using a Trickle timer ([I-D.ietf-roll-trickle]). A DIO from a sender with a lower DAGRank that causes no changes to the recipient's parent set, preferred parent, or Rank SHOULD be considered consistent with respect to the Trickle timer. The following packets and events MUST be considered inconsistencies with respect to the Trickle timer, and cause the Trickle timer to reset: o When a node detects an inconsistency when forwarding a packet, as detailed in Section 10.2. o When a node receives a multicast DIS message without a Solicited Information option. o When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the =20 Solicited Information option. o When a node joins a new DODAG Version (e.g. by updating its DODAGVersionNumber, joining a new RPL Instance, etc.) Note that this list is not exhaustive, and an implementation MAY consider other messages or events to be inconsistencies. A node SHOULD NOT reset its DIO trickle timer in response to unicast DIS messages. When a node receives a unicast DIS without a =20 Solicited Information option, it MUST unicast a DIO to the sender in response. This DIO MUST include a DODAG Configuration option. When a node receives a unicast DIS message with a Solicited Information option, if it satisfies the predicates of the Solicited Information option =20= it MUST unicast a DIO to the sender in response. This unicast DIO MUST include a DODAG Configuration Option. Thus a node may JP> s/may/MAY transmit a unicast DIS message to a potential DODAG parent in order to probe =20= for DODAG Configuration and other parameters. Winter, et al. Expires December 30, 2010 [Page 59] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 7.3.1. Trickle Parameters The configuration parameters of the trickle timer are specified as follows: Imin: learned from the DIO message as (2^DIOIntervalMin)ms. The default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN. Imax: learned from the DIO message as DIOIntervalDoublings. The default value of DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS. k: learned from the DIO message as DIORedundancyConstant. The default value of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value of 0x00 this is to be treated as a redundancy constant of infinity in RPL, i.e. Trickle never suppresses messages. 7.4. DODAG Selection The DODAG selection is implementation and OF dependent. Nodes =20 SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. JP> Shouldn't we have a MUST here ? See thread of the list. In order to limit erratic movements, and all metrics being equal, nodes SHOULD keep their previous selection. Also, =20 nodes SHOULD provide a means to filter out a parent whose availability is detected as fluctuating, at least when more stable choices are available. When connection to a grounded DODAG is not possible or preferable =20= for security or other reasons, scattered DODAGs MAY aggregate as much as possible into larger DODAGs in order to allow connectivity within =20= the LLN. A node SHOULD verify that bidirectional connectivity and adequate link quality is available with a candidate neighbor before it considers that candidate as a DODAG parent. 7.5. Operation as a Leaf Node In some cases a RPL node may attach to a DODAG as a leaf node only. One example of such a case is when a node does not understand JP> or does not support (policy) the RPL Instance's OF or advertised metric/constraint. As specified in Section 16.6 related to policy function, the node may either join =20= the DODAG as a leaf node or may not join the DODAG. As mentioned in Section 16.5, it is then recommended to log a fault. A leaf node does not extend DODAG connectivity but in some cases the Winter, et al. Expires December 30, 2010 [Page 60] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 leaf node may still need to transmit DIOs on occasion, in particular when the leaf node may not have always been acting as a leaf node =20= and an inconsistency is detected. A node operating as a leaf node must obey the following rules: 1. It MUST NOT transmit DIOs containing the DAG Metric Container. 2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK. 3. It MAY suppress DIO transmission, except DIO transmission MUST NOT be suppressed when DIO transmission has been triggered due =20= to detection of inconsistency when a packet is being forwarded or =20= in response to a unicast DIS message. 4. It MAY transmit unicast DAOs as described in Section 8.2. 5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as described in Section 8.10. A particular case that requires a leaf node to send a DIO is if that leaf node was a prior member of another DODAG and another node forwards a message assuming the old topology, triggering an inconsistency. The leaf node needs to transmit a DIO in order to repair the inconsistency. Note that due to the lossy nature of =20 LLNs, even though the leaf node may have optimistically poisoned its =20 routes by advertising a rank of INFINITE_RANK in the old DODAG prior to becoming a leaf node, that advertisement may have become lost and a leaf node must be capable to send a DIO later in order to repair the inconsistency. In general it is not expected that such a leaf node would advertise itself as a router. JP> I'd rather: "In general, the leaf node must not advertise itself =20 as a router (i.e. send DIOs). 7.6. Administrative Rank In some cases it might be beneficial to adjust the rank advertised =20= by a node beyond that computed by the OF based on some implementation specific policy and properties of the node. For example, a node =20 that has limited battery should be a leaf unless there is no other =20 choice, and may then augment the rank computation specified by the OF in order to expose an exaggerated rank. Winter, et al. Expires December 30, 2010 [Page 61] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 8. Downward Routes This section describes how RPL discovers and maintains downward routes. RPL constructs and maintains downward routes with Destination Advertisement Object (DAO) messages. Downward routes support of P2MP flows, from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow to a DODAG Root JP> Or common ancestor (storing nodes) through an upward route, then away from the DODAG Root to a destination through a downward route. This specification describes the two modes a RPL Instance may choose from for maintaining downward routes. In the first mode, call "storing," nodes store downward routing tables for their sub-DODAG. Each hop on a downward route in a storing network examines its routing table to decide on the next hop. In the second mode, called "non-storing," nodes do not store downward routing tables. Downward packets are routed with source routes populated by a DODAG Root. JP> Add reference to RH4 RPL allows a simple one-hop P2P optimization for both storing and non-storing networks. A node may send a P2P packet destined to a one-hop neighbor directly to that node. 8.1. Destination Advertisement Parents To establish downward routes, RPL nodes send DAO messages upwards. The next hop destinations of these DAO messages are called DAO parents. The collection of a node's DAO parents is called the DAO parent set. o A node's DAO parent set MUST be a subset of its DODAG parent set. o A node MUST NOT unicast DAOs to nodes that are not DAO parents. o A node MAY link-local multicast DAO messages. JP> s/link-local multicast/A node MAY send DAO messages using link-=20 local address. Indicate that this is for one-hop routing. o The IPv6 Source Address of a DAO message MUST be the link local address of the sending node. o If a node sends a DAO to one DAO parent, it MUST send a DAO with the same DAOSequence to all other DAO parents. The selection of DAO parents is implementation and objective =20 function specific. 8.2. Downward Route Discovery and Maintenance Destination Advertisement may be configured to be entirely disabled, or operate in either a storing or non-storing mode, as reported in Winter, et al. Expires December 30, 2010 [Page 62] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 the MOP in the DIO message. 1. All nodes who join a DODAG MUST abide by the MOP setting from =20= the root. Nodes that do not have the capability to fully =20 participate as a router MAY join the DODAG as a leaf. JP> A node that does not match the advertised MOP may decide to join =20 as a leaf. It is worth being spelled out. 2. If the MOP is 000, indicating no downward routing, nodes MUST =20= NOT transmit DAO messages, and MAY ignore DAO messages. 3. In non-storing mode, the DODAG Root MUST store source routing table entries for all destinations learned from DAOs. JP> I do not think that I would mandate for "all destinations", it =20 could be for a subset according to some policy (remember the route tag ?). 4. In storing mode, all non-root, non-leaf nodes MUST store routing table entries for all destinations learned from DAOs. JP> Same comments A DODAG can have one of several possible modes of operation, as defined by the MOP field. Either it does not support downward routes, it supports downward routes through source routing from =20 DODAG Roots, or it supports downward routes through in-network routing tables. When downward routes are supported through in-network routing tables, the multicast operation defined in this =20 specification may or may not be supported, also as indicated by the MOP field. As of this specification RPL does not support mixed-mode operation, where some nodes source route and other store routing tables: future extensions to RPL may support this mode of operation. 8.3. DAO Base Rules 1. Each time a node generates a new DAO, the DAOSequence field MUST increment by at least one since the last generated DAO. 2. Each time a node link-local multicasts a DAO, the DAOSequence field MUST increment JP> s/MUST increment/MUST be incremented by one by one since the last link local multicast DAO. 3. The RPLInstanceID and DODAGID fields of a DAO MUST be the same value as the members of the node's parent set and the DIOs it transmits. 4. A node MAY set the K flag in a unicast DAO message to solicit a unicast DAO-ACK in response in order to confirm the attempt. A node receiving a unicast DAO message with the K flag set SHOULD respond with a DAO-ACK. A node receiving a DAO message without the K flag set MAY respond with a DAO-ACK, especially to report an error condition. 5. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST NOT process them further. Winter, et al. Expires December 30, 2010 [Page 63] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Unlike the Version field of a DIO, which is incremented only by a DODAG Root and repeated unchanged by other nodes, DAOSequence values are unique to each node. The sequence number space for unicast and multicast DAO messages can be either the same or distinct. JP> We do not need a SHOULD or MUST here since there is no interop issue but I would suggest to RECOMMEND to use the same sequence number space. 8.4. DAO Transmission Scheduling Because DAOs flow upwards, receiving a unicast DAO can trigger sending a unicast DAO. 1. On receiving a unicast DAO with a new DAOSequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO immediately. It SHOULD delay sending the DAO in order to aggregate DAO information from other nodes for which it is a DAO parent. 2. A node SHOULD delay sending a DAO with a timer (DelayDAO). Receiving a DAO starts the DelayDAO timer. DAOs received while the DelayDAO timer is active do not reset the timer. When the DelayDAO timer expires, the node sends a DAO. 3. When a node adds a node to its DAO parent set, it SHOULD =20 schedule a DAO transmission. DelayDAO's value and calculation is implementation-dependent. 8.5. Triggering DAO Messages Nodes can trigger their sub-DODAG to send DAO messages. Each node maintains a DAO Trigger Sequence Number (DTSN), which it =20 communicates through DIO messages. 1. If a node hears one of its DAO parents increment its DTSN, the node MUST schedule a DAO transmission using rules in Section 8.3 and Section 8.4. 2. In non-storing mode, if a node hears one of its DAO parents increment its DTSN, the node MUST increment its own DTSN. In a storing mode of operation, a storing node MAY increment DTSN in order to reliably trigger a set of DAO updates from its immediate children, as part of routine routing table updates and maintenance. In a storing mode of operation it is not necessary to trigger DAO updates from the entire sub-DODAG, since that state information will percolate hop-by-hop up the DODAG in the storing mode of operation. JP> mmm ... not sure to correctly parse the previous sentence. In a non-storing mode of operation, a DTSN increment will also cause the immediate children of a node to increment their DTSN in turn, triggering a set of DAO updates from the entire sub-DODAG. In a =20 non- Winter, et al. Expires December 30, 2010 [Page 64] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 storing mode of operation typically only the root would =20 independently increment the DTSN when a DAO refresh is needed but a global repair (such as by incrementing DODAGVersionNumber) is not desired. In a non-storing mode of operation typically all non-root nodes would =20 only increment their DTSN when their parent(s) are observed to do so. In the case of triggered DAOs, selecting a proper DAODelay can greatly reduce the number of DAOs transmitted. The trigger flows down the DODAG; in the best case the DAOs flow up the DODAG such =20 that leaves send DAOs first, with each node sending a DAO only once. =20 Such a scheduling could be approximated by setting DAODelay inversely proportional to Rank. Note that this suggestion is intended as an optimization to allow efficient aggregation -- it is not required =20= for correct operation in the general case. JP> Suppress the "--" and replace by parenthesis. 8.6. Structure of DAO Messages DAOs follow a common structure in both storing and non-storing networks. Later sections describe further details for each mode of operation. 1. RPL nodes MUST include one or more RPL Target Options in each =20= DAO they transmit. One RPL Target Option MUST have a prefix that includes the node's IPv6 address if that node needs the DODAG to provision downward routes to that node. 2. A RPL Target Option in a unicast DAO MUST be followed by a Transit Information Option. 3. Multicast DAOs MUST NOT include Transit Information options. 4. If a node receives a DAO that does not follow the above three rules, it MUST discard the DAO without further processing. 8.7. Non-storing Mode In non-storing mode, RPL routes messages downward using source routing. JP> s/source routing/IP source routing The following rule applies to nodes that are in non-storing mode. Storing mode has a separate set of rules, described in Section 8.8. 1. The Parent Address field of a Transit Information Option MUST contain one or more addresses. All of these addresses MUST be addresses of DAO parents of the sender. 2. On receiving a unicast DAO, a node MUST forward the DAO upwards. This forwarding MAY use any parent in the parent set. Note that this forwarding may be delayed in support of aggregation as Winter, et al. Expires December 30, 2010 [Page 65] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 described below, but that such a delay is not required if a node's resources do not support it. 3. When a node removes a node from its DAO parent set, it MAY generate a new DAO with an updated Transit Information option. In non-storing mode, a node uses DAOs to report its DAO parents to the DODAG Root. The DODAG Root can piece together a downward route to a node by using DAO parent sets from each node in the route. The purpose of this per-hop route calculation is to minimize traffic =20 when DAO parents change. If nodes reported complete source routes, then on a DAO parent change the entire sub-DODAG would have to send new DAOs to the DODAG Root. Therefore, in non-storing mode, a node can send a a single DAO, although it might choose to send more than one DAO to each of multiple DAO parents. Nodes aggregate DAOs by sending a single DAO with multiple RPL =20 Target Options. JP> didn't we mean "pack" instead of "aggregate" since one could =20 aggregate and send one RPL Target option. Each RPL Target Option has its own, immediately following, Transit Information options. 8.8. Storing Mode In storing mode, RPL routes messages downward by the IPv6 =20 destination address. The following rule apply to nodes that are in storing =20 mode: 1. The Parent Address field of a Transmit Information option MUST =20= be empty. 2. On receiving a unicast DAO, JP> Let's make sure to replace all "DAO" by "DAO message" a node MUST compute if the DAO would change the set of prefixes that the node itself advertises. If so, the node MUST generate a new DAO and transmit it, following the rules in Section 8.4. Such a change includes receiving a =20= No- Path DAO. 3. When a node generates a new DAO, it SHOULD unicast it to each of its DAO parents. It MUST NOT unicast the DAO to nodes that are not DAO parents. 4. When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO (Section 5.4.3) to that removed DAO parent to invalidate the existing route. JP> Suggest a MUST in bullet 4. (see thread on the mailing list). 5. If messages to an advertised downwards address suffer from a forwarding error, neighbor unreachable detected (NUD), or =20 similar failure, a node MAY mark the address as unreachable and generate an appropriate No-Path DAO. DAOs advertise what destination addresses and prefixes a node has Winter, et al. Expires December 30, 2010 [Page 66] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 routes to. Unlike in non-storing mode, these DAOs do not =20 communicate information about the routes themselves: that information is stored within the network and is implicit from the IPv6 source address. When a storing node generates a DAO, it uses the stored state of =20 DAOs it has received to produce a set of RPL Target options and their associated Transmit Information options. Because this information is stored within a network, JP> The term "within a network" is a bit misleading. I would suggest =20 in nodes' routing tables. in storing mode DAOs are communicated directly to DAO parents, who store this information. 8.9. Path Control A DAO message from a node contains one or more Target Options. Each Target Option specifies either the node's prefix, a prefix of addresses reachable outside the LLN, or a destination in the node's sub-DODAG. The Path Control field of the Transit Information option allows nodes to request JP> To request or to allow for ... since parents (depending on their =20 policy) may decide to use one route. multiple downward routes. A node constructs the Path Control field of a Transit Information option as follows: 1. The bit width of the path control field MUST be equal to the value (PCS + 1), where PCS is specified in the control field of the DODAG Configuration Option. Bits greater than or equal to the value (PCS + 1) MUST be cleared on transmission and MUST be ignored on reception. Bits below that value are considered "active" bits. 2. For a RPL Target option describing a node's own address or a prefix outside the LLN, at least one active bit of the Path Control field MUST be set. More active bits of the Path Control field MAY be set. 3. If a node receives multiple DAOs with the same RPL Target =20 option, it MUST bitwise-OR the Path Control fields it receives. This aggregated bitwise-OR represents the number of downward routes the prefix requests. 4. When a node sends a DAO to one of its DAO parents, it MUST =20 select one or more of the set, active bits in the aggregated Path Control field. The DAO it transmits to its parent MUST have these active bits set and all other active bits cleared. 5. For the RPL Target option and DAOSequence number, the DAOs a =20 node sends to different DAO parents MUST have disjoint sets of active Path Control bits. A node MUST NOT set the same active bit on DAOs to two different DAO parents. Winter, et al. Expires December 30, 2010 [Page 67] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 6. Path control bits SHOULD be allocated in order of preference, such that the most significant bits, or groupings of bits, are allocated to the most preferred DAO parents as determined by the node. 7. In a non-storing mode of operation, a node MAY pass DAOs through without performing any further processing on the Path Control field. 8. A node MUST NOT unicast a DAO that has no active bits in the =20 Path Control field set. The Path Control field allows a node to bound how many downward routes will be generated to it. It sets a number of bits in the =20 Path Control field equal to the maximum number of downward routes it prefers. Each bit is sent to at most one DAO parent; clusters of bits can be sent to a single DAO parent for it to divide among its own DAO parents. JP> Section about PC to be reworked according to ticket #60. An example would be a good idea. 8.10. Multicast Destination Advertisement Messages A special case of DAO operation, distinct from unicast DAO =20 operation, is multicast DAO operation which may be used to populate '1-hop' routing table entries. 1. A node MAY multicast a DAO message to the link-local scope all- nodes multicast address FF02::1. JP> ALL RPL Routers address ? 2. A multicast DAO message MUST be used only to advertise information about self, i.e. prefixes directly connected to or owned by this node, such as a multicast group that the node is subscribed to or a global address owned by the node. 3. A multicast DAO message MUST NOT be used to relay connectivity information learned (e.g. through unicast DAO) from another =20 node. 4. Information obtained from a multicast DAO MAY be installed in =20= the routing table and MAY be propagated by a node in unicast DAOs. JP> any contradiction between 3. and 4.? 5. A node MUST NOT perform any other DAO related processing on a received multicast DAO, in particular a node MUST NOT perform =20= the actions of a DAO parent upon receipt of a multicast DAO. o The multicast DAO may be used to enable direct P2P communication, without needing the RPL routing structure JP> s/RPL routing structure/DODAG to relay the packets. o The multicast DAO does not presume any DODAG relationship between the emitter JP> s/emitter/sender. Isn't the last bullet redundant with the =20 previous one? and the receiver. Winter, et al. Expires December 30, 2010 [Page 68] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 9. Security Mechanisms JP> I skip that section for the time being since there are few =20 discussions on the ML. Will comment afterwards. See Ticket #68 This section describes the generation and processing of secure RPL messages. The high order bit of the RPL message code identifies whether a RPL message is secure or not. In addition to secure versions of basic control messages (DIS, DIO, DAO, DAO-Ack), RPL has several messages which are relevant only in networks with security enabled. 9.1. Security Overview RPL supports three security modes: o Insecure. In this security mode, RPL uses insecure DIS, DIO, =20 DAO, and DAO-Ack messages. o Pre-installed. In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a pre-installed key. Nodes use this to provide message confidentiality, integrity, and authenticity. A node may, using this preinstalled key, join the RPL network as either a host or a router. o Authenticated. In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a pre-installed key. Node use this key to provide message confidentiality, integrity, and authenticity. Using this preinstalled key, a node may join the network as a host only. To join the network as a router, a node must obtain a second key from a key authority. This key authority can authenticate that the requester is allowed to be a router before providing it with the second key. Whether or not the RPL Instance uses insecure mode is signaled by whether it uses secure RPL messages. Whether a secured network uses the pre-installed or authenticated mode is signaled by the 'A' bit =20= of the DAG Configuration option. RPL uses CCM* -- Counter with CBC-MAC (Cipher Block Chaining Message Authentication Code) -- as the cryptographic basis for its security[RFC3610]. In this specification, CCM uses AES-128 as its underlying cryptographic algorithm. There are bits reserved in the security section to specify other algorithms in the future. All secured RPL messages have a message authentication code (MAC). Secured RPL messages optionally also have encryption protection for confidentiality. Secured RPL message formats support both =20 integrated encryption/authentication schemes (e.g., CCM*) as well as schemes that separately encrypt and authenticate packets. Winter, et al. Expires December 30, 2010 [Page 69] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 9.2. Installing Keys Authenticated mode requires a would-be router to dynamically install new keys once they have joined a network as a host. The exact message exchange to obtain such keys is TBD. It will involve communication with a key authority, possibly, using the pre- installed shared key. The key authority can apply a security policy to decide whether to grant the would-be-router a new key. These =20 keys may have lifetimes (start and end times) associated with them, which nodes that support timestamps (described in Section 9.4.1) can use. 9.3. Joining a Secure Network RPL security assumes that a node wishing to join a secured network has been preconfigured with a shared key for communicating with neighbors and the RPL root. To join a secure RPL network, a node either listens for secure DIOs or triggers secure DIOs by sending a secure DIS. In addition to the DIO/DIS rules in Section 7, secure DIO and DIS messages have these rules: 1. If sent, this initial secure DIS MUST NOT set the C bit, MUST =20= set the KIM field to 0 (00), and MUST set the LVL field to 1 (001). The key used MUST be the preconfigured group key (Key Index 0x00). 2. When a node resets its Trickle timer in response to a secure DIS (Section 7.3), the next DIO it transmits MUST be a secure DIO with the same security configuration as the secure DIS. If a node receives multiple secure DIS messages before it transmits a DIO, the secure DIO MUST have the same security configuration as the last DIS it is responding to. 3. When a node sends a DIO in response to a unicast secure DIS (Section 7.3), the DIO MUST be a secure DIO. The above rules allow a node to join a secured RPL Instance using =20= the preconfigured shared key. Once a node has joined the DODAG using =20= the preconfigured shared key, the 'A' bit of the Configuration option determines its capabilities. If the 'A' bit of the Configuration is cleared, then nodes can use this preinstalled, shared key to =20 exchange messages normally: it can issue DIOs, DAOs, etc. If the 'A' bit of the Configuration option is set: 1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure DIOs secured with Key Index 0x00. If a node receives a secure DIO that advertises a Rank besides INFINITE_RANK and is secured Winter, et al. Expires December 30, 2010 [Page 70] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 with Key Index 0x00, it MUST discard the message without further processing. 2. Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target option with a prefix besides the node's address. If a node receives a secured DAO using the preinstalled, shared key where the RPL Target option does not match the IPv6 source address, it MUST discard the secured DAO without further processing. The above rules mean that in RPL Instances where the 'A' bit is set, using Key Index 0x00 a node can join the RPL Instance as a host but not a router. A node must communicate with a key authority to =20 obtain a key that will enable it to act as a router. Obtaining this key might require authentication on one or both ends. This message exchange is TBD. 9.4. Counter and Counter Compression Every secured RPL packet has a Counter field. Depending on whether the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL =20 nodes send CC messages to force uncompressed Counter values, protect against replay attacks and synchronize counters. 1. If a node is sending a secured RPL packet, and the Counter value of the packet is more than 255 greater than the last secured packet to the destination address, the node MUST NOT set the 'C' bit of the security section of the packet. 2. If a node receives a secure RPL message with the C bit set and =20= is uncertain of the 32-bit counter value, it MAY send a CC message with the R bit cleared to obtain an uncompressed counter value. The Nonce field of the CC message SHOULD be a random or pseudorandom number. 3. If a node receives a unicast CC message with the R bit cleared, and it is a member of or is in the process of joining the associated DODAG, it SHOULD respond with a unicast CC message to the sender. This response MUST have the C bit of the security section cleared, MUST have the R bit set, and MUST have the same Nonce, RPLInstanceID and DODAGID fields as the message it received. 4. If a node receives a multicast CC message, it MUST discard the message with no further processing. These rules allow nodes to compress the Counter when destinations =20= who received the prior packet can determine the full counter value. =20 If a node cannot determine the full counter value, it can request the =20 full Winter, et al. Expires December 30, 2010 [Page 71] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 counter with a CC message. 9.4.1. Timestamp Counters In the simplest case, the Counter value is an unsigned integer =20 that a node increments by one or more on each secured RPL transmission. =20= The Counter MAY represent a timestamp that has the following properties: 1. The timestamp MUST be at least six octets long. 2. The timestamp MUST be in 1kHz (millisecond) granularity. 3. The timestamp start time MUST be January 1, 2010, 12:00:00AM =20 UTC. 4. If the Counter represents such as timestamp, the Counter value MUST be a value computed as follows. Let T be the timestamp, S be the start time of the key in use, and E be the end time of =20= the key in use. Both S and E are represented using the same 3 rules as the timestamp described above. If E > T < S, then the =20 Counter is invalid and a node MUST NOT generate a packet. Otherwise, =20= the Counter value is equal to T-S. 5. If the Counter represents such a timestamp, a node MAY set the 'T' flag of the security section of secured RPL packets. 6. If the Counter field does not present such a timestamp, then a node MUST NOT set the 'T' flag. 7. If a node does not have a local timestamp that satisfies the above requirements, it MUST ignore the 'T' flag. If a node supports such timestamps and it receives a message with =20= the 'T' flag set, it MAY apply the temporal check on the received =20 message described in Section 9.5.2.1. If a node receives a message without the 'T' flag set, it MUST NOT apply this temporal check. A node's security policy MAY, for application reasons, include rejecting all messages without the 'T' flag set. 9.5. Functional Description of Packet Protection 9.5.1. Transmission of Outgoing Packets Given an outgoing RPL control packet and required security protection, this section describes how RPL generates the secured packet to transmit. It also describes the order of cryptographic operations to provide the required protection. The requirement for security protection and the level of security to Winter, et al. Expires December 30, 2010 [Page 72] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 be applied to an outgoing RPL packet shall be determined by the node's security policy database. The configuration of this security policy database for outgoing packet processing is TBD (it may, for example, be defined through DIO Configuration or through out-of-band administrative router configuration). Where secured RPL messages are to be transmitted, a RPL node MUST =20= set the security section (C, T, Sec, KIM, and LVL) in the outgoing RPL packet to describe the protection level and security settings that are applied (see Section 5.1). The Security subfield bit of the RPL message Code field MUST be set to indicate the secure RPL message. The Counter value used in constructing the Nonce to secure the outgoing packet MUST be an increment of the last Counter transmitted to the particular destination address. Where a Counter for the intended destination address has not been established, the Counter value MUST be initialized to zero and sent as a Full Counter for the initial RPL message transmission. Where a Counter is currently maintained for outgoing messages to the intended destination address, the Compressed Counter (indicated with the 'C' bit set) MUST be transmitted within the secured RPL message, provided the message is not a RPL Consistency Check message. The current Full Counter (indicated with the 'C' bit cleared) for the given destination address SHALL always be used when the outgoing packet is a Consistency Check (challenge or response) message. =20 Where a Counter for the intended destination address does not exist, the initialized (zero-value), Full Counter MUST be transmitted within =20= the initial RPL control message. Where security policy specifies the application of delay protection, the Timestamp Counter used in constructing the Nonce to secure the outgoing packet MUST be incremented according to the rules in Section 9.4.1. Where a Timestamp Counter is applied (indicated with the 'T' flag set) the locally maintained Time Counter MUST be included as part of the transmitted secured RPL message. The cryptographic algorithm used in securing the outgoing packet shall be specified by the node's security policy database and MUST =20= be indicated in the value of the Sec field set within the outgoing message. The security policy for the outgoing packet shall determine the applicable Key Identifier Mode (KIM) and Key Identifier specifying the security key to be used for the cryptographic packet processing, including the optional use of signature keys (see Section 5.1). The security policy will also specify the level of protection (LVL) in the form of authentication or authentication and encryption, and potential use of signatures that shall apply to the outgoing packet. Winter, et al. Expires December 30, 2010 [Page 73] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Where encryption is applied, a node MUST replace the original packet payload with that payload encrypted using the security protection, key, and nonce specified in the security section of the packet. All secured RPL messages include integrity protection. In conjunction with the security algorithm processing, a node derives a Message Authentication Code (MAC) that MUST be included as part of the outgoing secured RPL packet. 9.5.2. Reception of Incoming Packets This section describes the reception and processing of a secured RPL packet. Given an incoming secured RPL packet, where the Security subfield bit of the RPL message Code field is set, this section describes how RPL generates an unencrypted version of the packet and validates its integrity. The receiver uses the RPL security control fields to determine the necessary packet security processing. If the described level of security for the message type and originator does not meet locally maintained security policies, a node MAY discard the packet without further processing. These policies can include security levels, =20 keys used, source identifiers, or the lack of timestamp-based counters =20= (as indicated by the 'T' flag). The configuration of the security =20 policy database for incoming packet processing is TBD (it may, for example, be defined through DIO Configuration or through out-of-band administrative router configuration). Where the message security level (LVL) indicates an encrypted RPL message, the node uses the key information identified through the =20= KIM field as well as the Nonce as input to the message payload =20 decryption processing. The Nonce shall be derived from the message Counter field and other received and locally maintained information (see Section 9.5.3.1). The plaintext message contents shall be obtained by invoking the inverse cryptographic mode of operation specified by the Sec field of the received packet. The receiver shall use the Nonce and identified key information to check the integrity of the incoming packet. If the integrity check fails against the received message authentication code (MAC), a node MUST discard the packet. If a Compressed Counter is received and the node does not currently have an incoming Counter currently maintained for the originator of the message, the node MUST send a Consistency Check request to the message source to update the Counters. If an initialized (zero value) Full Counter is received in a secured Winter, et al. Expires December 30, 2010 [Page 74] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 RPL message and the receiving node currently has an incoming Counter currently maintained for the originator of the message, the node =20 MUST initiate a Counter resynchronization by sending a Consistency Check response message (see Section 5.6.1) to the message source. The Consistency Check response message shall be protected with the current full outgoing Counter maintained for the particular node address. That outgoing Counter will be included within the security section of the message while the incoming Counter will be included within the Consistency Check message payload. Based on the specified security policy a node MAY apply replay protection for a received RPL message. The replay check MUST be performed following the authentication of the received packet. The full Counter, as obtained from the incoming packet or as derived =20 from the received Compressed Counter shall be compared against the watermark of the incoming Counter maintained for the given origination node address. If the received message Counter value is non-zero and less than the maintained incoming Counter watermark a potential packet replay is indicated and the node MUST discard the incoming packet. If delay protection is specified as part of the incoming packet security policy checks, the Timestamp Counter is used to validate =20= the timeliness of the received RPL message. If the incoming message Timestamp Counter value indicates a message transmission time prior to the locally maintained transmission time Counter for the originator address, a replay violation is indicated and the node =20 MUST discard the incoming packet. If the received Timestamp Counter =20 value indicates a message transmission time that is earlier than the Current time less the acceptable packet delay, a delay violation is indicated and the node MUST discard the incoming packet. Once a message has been decrypted, where applicable, and has successfully passed its integrity check, replay, and optionally =20 delay protection checks, the node can update its local security information, such as the source's expected Counter value for counter compression and replay comparison. A node MUST NOT update its security information on receipt of a message that fails security policy checks or other applied =20 integrity, replay, or delay checks. 9.5.2.1. Timestamp Key Checks If the 'T' flag of a message is set and a node has a local timestamp that follows the requirements in Section 9.4.1, then a node MAY =20 check the temporal consistency of the message. The node computes the transmit time of the message by adding the Counter value to the =20 start Winter, et al. Expires December 30, 2010 [Page 75] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 time of the associated key. If this transmit time is past the end time of the key, the node MAY discard the message without further processing. If the transmit time is too far in the past or future compared to the local time on the receiver, it MAY discard the message without further processing. 9.5.3. Cryptographic Mode of Operation The cryptographic mode of operation used is based on the CCM mode of operation and the block-cipher AES-128[RFC3610]. This mode of operation is widely supported by existing implementations and coincides with the CCM* mode of operation[CCMStar]. CCM mode requires a nonce. 9.5.3.1. Nonce A RPL node constructs a CCM nonce as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ =20 | | + Source =20 Identifier + =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ | =20 Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ |Reserved | LVL | +-+-+-+-+-+-+-+-+ Figure 24: CCM* Nonce Source Identifier: 8 bytes. Source Identifier is set to the =20 logical identifier of the originator of the protected packet. Counter: 4 bytes. Counter is set to the (uncompressed) value of =20= the corresponding field in the Security option of the RPL control message. Security Level (LVL): 3 bits. Security Level is set to the value =20= of the corresponding field in the Security option of the RPL control message. Unassigned bits of the nonce are reserved. They MUST be set to zero when constructing the nonce. Winter, et al. Expires December 30, 2010 [Page 76] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 All fields of the nonce shall be represented is most-significant- octet and most-significant-bit first order. 9.5.3.2. Signatures If the Key Identification Mode (KIM) mode indicates the use of signatures (a value of 3), then a node appends a signature to the data payload of the packet. The Security Level (LVL) field =20 describes the length of this signature. The signature scheme in RPL for Security Mode 00 is an instantiation of the ECPVS signature scheme[X9.92]. It uses as an elliptic curve the named curve K-283[X9.92]. It uses CCM* mode[CCMStar] as the encryption scheme with M=3D0 (as a stream-cipher). It uses the =20 Matyas- Meyer-Oseas unkeyed hash function[AppliedCryptography]. It uses the key derivation function based on this unkeyed hash function =20 specified in Section 5.6.3 of [X9.63-2001], and the message encoding rule of Section 7.8 or ANSI X9.92 [X9.92]. PadLen is a non-negative integer set to M-OctCurve, where OctCurve is the byte-length of the curve in question (with K-283, one has OctCurve=3D36). Let 'a' be a concatenation of a six-byte representation of Counter and the message header. The packet payload is a concatenation of packet data 'c' and the signature 's'. This signature scheme is invoked with visible and recoverable message parts a and c, whereas the signature verification is invoked with as received visible and message representative a, c, and with signature s. 9.6. Coverage of Integrity and Confidentiality For a RPL ICMPv6 message, the entire packet is within the scope of RPL security. The message authentication code is calculated over =20= the entire IPv6 packet. This calculation is done before any compression that lower layers may apply. The IPv6 and ICMPv6 headers are never encrypted. The body of the RPL ICMPv6 message MAY be encrypted, starting from the first byte after the security section and continuing to the end of the packet. Winter, et al. Expires December 30, 2010 [Page 77] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 10. Packet Forwarding and Loop Avoidance/Detection 10.1. Suggestions for Packet Forwarding When forwarding a packet to a destination, precedence is given to selection of a next-hop successor as follows: 1. This specification only covers how a successor is selected from the DODAG version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded. Routing outside the instance can be done as long as additional rules are put in =20 place such as strict ordering of instances and routing protocols to protect against loops. JP> Add: "Such rules may be defined in a separate document" 2. If a local administrative preference favors a route that has =20 been learned from a different routing protocol than RPL, then use =20 that successor. 3. If the packet header specifies a source route, then use that route [I-D.hui-6man-rpl-routing-header]. JP> s/specifies a source route/specifies a source route by including a =20= RH4 header as specified in ... If the node fails to forward the packet with that specified source route, then that packet SHOULD be dropped. The node MAY log an error. The node MAY send an ICMPv6 Error in Source Routing Header message to the source of the packet Section 18.6. JP> s/Section 18.6/(See Section 18.6) 4. If there is an entry in the routing table matching the destination that has been learned from a multicast destination advertisement (e.g. the destination is a one-hop neighbor), then use that successor. 5. If there is an entry in the routing table matching the destination that has been learned from a unicast destination advertisement (e.g. the destination is located down the sub- DODAG), then use that successor. If there are DAO Path Control bits associated with multiple successors, then consult the Path Control bits to order the successors by preference when =20 choosing. 6. If there is a DODAG version offering a route to a prefix =20 matching the destination, then select one of those DODAG parents as a successor according to the OF and routing metrics. 7. Any other as-yet-unattempted DODAG parent may be chosen for the next attempt to forward a unicast packet when no better match exists. 8. Finally the packet is dropped. ICMP Destination Unreachable may be invoked (an inconsistency is detected). JP>s/may/MAY Winter, et al. Expires December 30, 2010 [Page 78] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 TTL must be decremented when forwarding. JP>s/must/MUST Note that the chosen successor MUST NOT be the neighbor that was the predecessor of the packet (split horizon), except in the case where it is intended for the packet to change from an up to an down flow, JP> s/an/a such as switching from DIO routes to DAO routes as the destination =20= is neared. JP> It may be worh explaining when such change (from up to down) may =20 occur because as written it would be sent to a different node (not the =20 sender). 10.2. Loop Avoidance and Detection RPL loop avoidance mechanisms are kept simple and designed to minimize churn and states. Loops may form for a number of reasons, e.g. control packet loss. RPL includes a reactive loop detection technique that protects from meltdown and triggers repair of broken paths. RPL loop detection uses information that is placed into the packet. A future version of this specification will detail how this information is carried with the packet (e.g. a hop-by-hop option ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow label). JP> As discussed, section to be updated according to ticket # 64 =20 (insert the RPLInstanceID in flow label and all other information in the RPL option as defined in I-=20 D.ietf-6man-rpl-option ?) For the purpose of RPL operations, the information carried with a packet is constructed follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ |O|R|F|0|0|0|0|0| RPLInstanceID | =20 SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= +-+ RPL Packet Information JP> Figure number is missing. Down 'O' bit: 1-bit flag indicating whether the packet is expected to progress up or down. A router sets the 'O' bit when the packet is expect to progress down (using DAO routes), and resets it when forwarding towards the root of the DODAG version. JP> when forwarding toward the DODAG root (to a node with a lower rank). A host or RPL leaf node MUST set the bit to 0. JP> s/the bit/the 'O' bit Rank-Error 'R' bit: 1-bit flag indicating whether a rank error was detected. A rank error is detected when there is a mismatch =20= in the relative ranks and the direction as indicated in the 'O' bit. A host or RPL leaf node MUST set the bit to 0. JP> s/the bit/the 'R' bit Forwarding-Error 'F' bit: 1-bit flag indicating that this node can not forward the packet further towards the destination. The 'F' bit might be set by a child node that does not have a =20 route to destination for a packet with the down 'O' bit set. A host Winter, et al. Expires December 30, 2010 [Page 79] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 or RPL leaf node MUST set the bit to 0. JP>s/the bit/the 'F' bit RPLInstanceID: 8-bit field indicating the DODAG instance along =20 which the packet is sent. JP> To be updated according to ticket #64 SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL =20 network. 10.2.1. Source Node Operation If the source is aware of the RPLInstanceID that is preferred for =20= the packet, then it MUST set the RPLInstanceID field associated with the packet accordingly, otherwise it MUST set it to the RPL_DEFAULT_INSTANCE. 10.2.2. Router Operation 10.2.2.1. Instance Forwarding Instance IDs JP>RPLInstanceID are used to avoid loops between DODAGs from different origins. DODAGs that constructed for antagonistic constraints might contain paths that, if mixed together, would yield loops. Those loops are avoided by forwarding a packet along the DODAG that is associated to a given instance. The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For traffic originating outside of the RPL domain there may be a mapping occurring at the gateway JP> Do not use "gateway". It is called LBR in the terminology ID. into the RPL domain, possibly based on an encoding within the flow label. This aspect of RPL operation is to be clarified in a future version of this specification. JP> in rev-11. See thread on mailing list. The source of the packet might be aware of the RPL network, of the constraints imposed on OFs, and of associated Instance IDs. JP> to be accurate: RPL instance IDs. In that case, the source of the packet MAY tag the flow label with the RPLInstanceID, in which case it is used in that form within the RPL network. A router that injects a data packet into the RPL network MUST tag =20= the packet by inserting a RPL Hop-by-hop option as specified in [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the =20= RPL Hop-by-hop option. A router that forwards a packet to outside the RPL network MUST remove the RPL Hop-by-hop option. Winter, et al. Expires December 30, 2010 [Page 80] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 When a router receives a packet that specifies a given RPLInstanceID and the node can forward the packet along the DODAG associated to that instance, then the router MUST do so and leave the =20 RPLInstanceID value unchanged. If any node can not forward a packet along the DODAG associated to the RPLInstanceID, then the node SHOULD discard the packet and send an ICMP error message. JP> Section above to be updated according to resolution of ticket #64. 10.2.2.2. DAG Inconsistency Loop Detection The DODAG is inconsistent if the direction of a packet does not =20 match the rank relationship. A receiver detects an inconsistency if it receives a packet with either: the 'O' bit set (to down) from a node of a higher rank. the 'O' bit reset (for up) from a node of a lesser rank. When the DODAG root increments the DODAGVersionNumber a temporary rank discontinuity may form between the next version and the prior version, in particular if nodes are adjusting their rank in the next version and deferring their migration into the next version. A router that is still a member of the prior version may choose to forward a packet to a (future) parent that is in the next version. In some cases this could cause the parent to detect an inconsistency because the rank-ordering in the prior version is not necessarily =20= the same as in the next version and the packet may be judged to not be making forward progress. If the sending router is aware that the chosen successor has already joined the next version, then the sending router MUST update the SenderRank to INFINITE_RANK as it forwards the packets across the discontinuity into the next DODAG version in order to avoid a false detection of rank inconsistency. One inconsistency along the path is not considered as a critical error and the packet may continue. But a second detection along the path of a same packet should not occur and the packet is dropped. JP> "is dropped" or "MUST be dropped" This process is controlled by the Rank-Error bit associated with the packet. When an inconsistency is detected on a packet, if the Rank- Error bit was not set then the Rank-Error bit is set. If it was set the packet is discarded and the trickle timer is reset. JP> replace the last "is" by "MUST be" 10.2.2.3. DAO Inconsistency Loop Detection and Recovery A DAO inconsistency happens when router that has an down DAO JP>s/an down/a down route via a child that is a remnant from an obsolete state that is not matched in the child. With DAO inconsistency loop recovery, a =20 packet Winter, et al. Expires December 30, 2010 [Page 81] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 can be used to recursively explore and cleanup the obsolete DAO states along a sub-DODAG. In a general manner, a packet that goes down should never go up again. If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet back to the parent that passed it with the Forwarding-Error 'F' bit set and the 'O' bit left untouched. Otherwise the router MUST silently discard the packet. 10.2.2.4. Forward Path Recovery Upon receiving a packet with a Forwarding-Error bit set, the node MUST remove the routing states that caused forwarding to that neighbor, clear the Forwarding-Error bit and attempt to send the packet again. The packet may be sent to an alternate neighbor. JP> after the expiration of a user configurable timer (implementation-=20= specific). =3D> To avoid a burst of traffic should the parent have a number of =20 children that used to advertise the prefix. If that alternate neighbor still has an inconsistent DAO state via this node, the process will recurse, this node will set the Forwarding- Error 'F' bit and the routing state in the alternate neighbor will =20= be cleaned up as well. Winter, et al. Expires December 30, 2010 [Page 82] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 11. Multicast Operation This section describes further the multicast routing operations over an IPv6 RPL network, and specifically how unicast DAOs can be used =20= to relay group registrations up. Wherever the following text mentions Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) =20= or MLDv2 ([RFC3810]). Nodes that support the RPL storing mode of operation SHOULD also support multicast DAO operations as described below. Nodes that =20 only support the non-storing mode of operation are not expected to =20 support this section. The multicast operation is controlled by the MOP field in the DIO. If the MOP field requires multicast support, then a node that joins the RPL network as a router must operate as described in this section for multicast signaling and forwarding within the =20= RPL network. A node that does not support the multicast operation required by the MOP field can only join as a leaf. If the MOP field does not require multicast support, then multicast is handled by some other way that is out of scope for this specification. (Examples may include as a series of unicast copies or limited-scope flooding) JP> Add a "." As is traditional, a listener uses a protocol such as MLD with a router to register to a multicast group. Along the path between the router and the DODAG root, MLD requests are mapped and transported as DAO messages within the RPL protocol; JP> s/the RPL protocol/RPL each hop coalesces the multiple requests for a same group as a =20 single DAO message to the parent(s), in a fashion similar to proxy IGMP, =20= but recursively between child router and parent up to the root. JP> s/root/DODAG root A router might select to pass a listener registration DAO message to its preferred parent only, in which case multicast packets coming back might be lost for all of its sub-DODAG if the transmission =20 fails over that link. Alternatively the router might select to copy additional parents as it would do for DAO messages advertising unicast destinations, in which case there might be duplicates that the router will need to prune. As a result, multicast routing states are installed in each router =20= on the way from the listeners to the root, JP> Same comment as above enabling the root to copy a multicast packet to all its children routers that had issued a DAO message including a DAO for that multicast group, as well as all the attached nodes that registered over MLD. Winter, et al. Expires December 30, 2010 [Page 83] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 For unicast traffic, it is expected that the grounded root of an DODAG JP> s/root of an DODAG/DODAG root terminates RPL JP> I would suggest "Acts as a LBR" instead of "terminates RPL" and MAY redistribute the RPL routes over the external infrastructure using whatever routing protocol is used in the other routing domain. For multicast traffic, the root MAY proxy MLD for all the nodes attached to the RPL domain (this would be needed if the multicast source is located in the external infrastructure). For such a source, the packet will be replicated =20= as it flows down the DODAG based on the multicast routing table entries installed from the DAO message. For a source inside the DODAG, the packet JP> which packet? is passed to the preferred parents, and if that fails then to the alternates in the DODAG. The packet is also copied to all the registered children, except for the one that passed the packet. Finally, if there is a listener in the external infrastructure then the DODAG root has to further propagate the packet into the external infrastructure. As a result, the DODAG Root acts as an automatic proxy Rendezvous Point for the RPL network, and as source towards the Internet JP> s/Internet/non RPL domain for all multicast flows started in the RPL LLN. JP> s/RPL LLN/RPL domain So regardless of whether the root is actually attached to the Internet, JP> Same comment as above and regardless of whether the DODAG is grounded or floating, the root can serve inner =20 multicast streams at all times. Winter, et al. Expires December 30, 2010 [Page 84] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 JP> See also ticket#66 12. Maintenance of Routing Adjacency The selection of successors, along the default paths up along the DODAG, or along the paths learned from destination advertisements down along the DODAG, leads to the formation of routing adjacencies that require maintenance. In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance =20= of a routing adjacency involves the use of Keepalive mechanisms =20 (Hellos) or other protocols such as BFD ([RFC5880]) and MANET Neighborhood Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]). Unfortunately, =20 such an approach is not desirable in constrained environments such as LLN and would lead to excessive control traffic in light of the data traffic with a negative impact on both link loads and nodes resources. Overhead to maintain the routing adjacency should be minimized. Furthermore, it is not always possible to rely on the link or transport layer to provide information of the associated =20 link state. The network layer needs to fall back on its own mechanism. Thus RPL makes use of a different approach consisting of probing the neighbor using a Neighbor Solicitation message (see [RFC4861]). The reception of a Neighbor Advertisement (NA) message with the "Solicited Flag" set is used to verify the validity of the routing adjacency. Such mechanism MAY be used prior to sending a data packet. This allows for detecting whether or not the routing adjacency is still valid, and should it not be the case, select another feasible successor to forward the packet. JP> We can add: "under specific circumstances and according to the =20 network resources, a RPL implementation MAY decide to augment this mechanism with Keep-=20 Alive messages." Winter, et al. Expires December 30, 2010 [Page 85] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 13. Guidelines for Objective Functions An Objective Function (OF) allows for the selection of a DODAG to join, and a number of peers in that DODAG as parents. JP> Routing metrics and constraints also contribute to DODAG parents =20 selection. The OF is used to compute an ordered list of parents. The OF is also responsible =20= to compute the rank of the device within the DODAG version. The Objective Function is indicated in the DIO message using an Objective Code Point (OCP), and indicates the method that must be used to construct the DODAG. The Objective Code Points are =20 specified in [I-D.ietf-roll-of0], and related companion specifications. 13.1. Objective Function Behavior Most Objective Functions are expected to follow the same abstract behavior: o The parent selection is triggered each time an event indicates that a potential next hop information is updated. This might happen upon the reception of a DIO message, a timer elapse, all DODAG parents are unavailable, or a trigger indicating that the state of a candidate neighbor has changed. o An OF scans all the interfaces on the device. Although there may typically be only one interface in most application scenarios, there might be multiple of them and an interface might be configured to be usable or not for RPL operation. An interface can also be configured with a preference or dynamically learned =20= to be better than another by some heuristics that might be link-=20 layer dependent and are out of scope. Finally an interface might or =20= not match a required criterion for an Objective Function, for =20 instance a degree of security. As a result some interfaces might be completely excluded from the computation JP> Add: "For example if it does not satisfy some advertised =20 constraints" , while others might be more or less preferred. o An OF scans all the candidate neighbors on the possible =20 interfaces to check whether they can act as a router for a DODAG. There might be multiple of them and a candidate neighbor might need to pass some validation tests before it can be used. In particular, some link layers require experience on the activity with a router to enable the router as a next hop. o An OF computes self's rank by adding to the rank of the candidate a value representing the relative locations of self and the candidate in the DODAG version. * The increase in rank must be at least MinHopRankIncrease. Winter, et al. Expires December 30, 2010 [Page 86] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 * To keep loop avoidance and metric optimization in alignment, the increase in rank should reflect any increase in the metric value. For example, with a purely additive metric such as =20 ETX, the increase in rank can be made proportional to the increase in the metric. * Candidate neighbors that would cause self's rank to increase are not considered for parent selection o Candidate neighbors that advertise an OF incompatible with the =20= set of OF specified by the policy functions are ignored. o As it scans all the candidate neighbors, the OF keeps the current best parent and compares its capabilities with the current candidate neighbor. The OF defines a number of tests that are critical to reach the objective. A test between the routers determines an order relation. * If the routers are equal for that relation then the next test is attempted between the routers, * Else the best of the two routers becomes the current best parent and the scan continues with the next candidate neighbor * Some OFs may include a test to compare the ranks that would result if the node joined either router o When the scan is complete, the preferred parent is elected and self's rank is computed as the preferred parent rank plus the =20 step in rank with that parent. o Other rounds of scans might be necessary to elect alternate parents. In the next rounds: * Candidate neighbors that are not in the same DODAG are ignored * Candidate neighbors that are of greater rank than self are ignored * Candidate neighbors of an equal rank to self are ignored for parent selection * Candidate neighbors of a lesser rank than self are preferred Winter, et al. Expires December 30, 2010 [Page 87] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 14. Suggestions for Interoperation with Neighbor Discovery This specification directly borrows the Prefix Information Option (PIO) and the Routing Information Option (RIO) from IPv6 ND. It is envisioned that as future specifications build on this base that there may be additional cause to leverage parts of IPv6 ND. This section provides some suggestions for future specifications. First and foremost RPL is a routing protocol. One should take great care to preserve architecture when mapping functionalities between RPL and ND. RPL is for routing only. That said, there may be persuading technical reasons to allow for sharing options between =20= RPL and IPv6 ND in a particular implementation/deployment. In general the following guidelines apply: o RPL Type codes must be allocated from the RPL Control Message Options registry. o RPL Length fields must be expressed in units of single octets, as opposed to ND Length fields which are expressed in units of 8 octets. o RPL Options are generally not required to be aligned to 8 octet boundaries. o When mapping/transposing an IPv6 ND option for redistribution =20 as a RPL option, any padding octets should be removed when possible. For example, the Prefix Length field in the PIO is sufficient to describe the length of the Prefix field. When mapping/=20 transposing a RPL option for redistribution as an IPv6 ND option, any such padding octets should be restored. This procedure must be unambiguous. Winter, et al. Expires December 30, 2010 [Page 88] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 15. RPL Constants and Variables Following is a summary of RPL constants and variables: BASE_RANK This is the rank for a virtual root that might be used to coordinate multiple roots. BASE_RANK has a value of 0. ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value of MinHopRankIncrease (as advertised by the DODAG root), such that DAGRank(ROOT_RANK) is 1. INFINITE_RANK This is the constant maximum for the rank. INFINITE_RANK has a value of 0xFFFF. RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this protocol by a node without any overriding policy. RPL_DEFAULT_INSTANCE has a value of 0. DEFAULT_PATH_CONTROL_SIZE This is the default value used to configure PCS in the DODAG Configuration Option, which =20 dictates the number of significant bits in the Path Control field of =20= the Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a value of 0. This configures the simplest case-- limiting the JP> Remove "--" fan-out to 1 and limiting a node to send a DAO message to only one parent. DEFAULT_DIO_INTERVAL_MIN This is the default value used to =20 configure Imin for the DIO trickle timer. DEFAULT_DIO_INTERVAL_MIN =20 has a value of 3. This configuration results in Imin of 8ms. DEFAULT_DIO_INTERVAL_DOUBLINGS This is the default value used to configure Imax for the DIO trickle timer. DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This configuration results in a maximum interval of 2.3 hours. DEFAULT_DIO_REDUNDANCY_CONSTANT This is the default value used to configure k for the DIO trickle timer. DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This configuration is a conservative value for trickle suppression mechanism. DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. This configuration results in an 8-bit wide integer part of Rank. Winter, et al. Expires December 30, 2010 [Page 89] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 DIO Timer One instance per DODAG that a node is a member of. =20 Expiry triggers DIO message transmission. Trickle timer with =20 variable interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See Section 7.3.1 DAG Version Increment Timer Up to one instance per DODAG that the node is acting as DODAG root of. May not be supported in all implementations. Expiry triggers increment of DODAGVersionNumber, causing a new series of updated DIO =20 message to be sent. Interval should be chosen appropriate to propagation time of DODAG and as appropriate to application requirements (e.g. response time vs. overhead). DelayDAO Timer Up to one instance JP> s/instance/timer per DAO parent (the subset of DODAG parents chosen to receive destination advertisements) =20= per DODAG. Expiry triggers sending of DAO message to the DAO parent. See Section 8.4 RemoveTimer Up to one instance JP> Same comment as above per DAO entry per neighbor (i.e. those neighbors that have given DAO messages to this node as a DODAG parent) Expiry triggers a change in state for the DAO entry, setting up to do unreachable (No-Path) advertisements =20= or immediately deallocating the DAO entry if there are no DAO parents. JP> Suggest rewording the last sentence a bit. Winter, et al. Expires December 30, 2010 [Page 90] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 16. Manageability Considerations JP> Will skip that section - See separate email related to Ticket #63 The aim of this section is to give consideration to the =20 manageability of RPL, and how RPL will be operated in a LLN. The scope of this section is to consider the following aspects of manageability: configuration, monitoring, fault management, accounting, and performance of the protocol in light of the recommendations set =20 forth in [RFC5706]. 16.1. Introduction Most of the existing IETF management standards are Structure of Management Information (SMI) based data models (MIB modules) to monitor and manage networking devices. For a number of protocols, the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols. As pointed out in [RFC5706], the common policy in terms of operation and management has been expanded to a policy that is more open to a set of tools and management protocols rather than strictly relying =20= on a single protocol such as SNMP. In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration. One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410]. In the case of LLNs, it must be noted that at =20= the time of writing, the CoRE Working Group is actively working on resource management of devices in LLNs. Still, it is felt that this section provides important guidance on how RPL should be deployed, operated, and managed. As stated in [RFC5706], "A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are =20 allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified". =20 These aspects are discussed in detail in the following sections. RPL will be used on a variety of devices that may have resources =20 such as memory varying from a very few Kbytes to several hundreds of Kbytes and even Mbytes. When memory is highly constrained, it may Winter, et al. Expires December 30, 2010 [Page 91] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 not be possible to satisfy all the requirements listed in this section. Still it is worth listing all of these in an exhaustive fashion, and implementers will then determine which of these requirements could be satisfied according to the available resources on the device. 16.2. Configuration Management 16.2.1. Initialization Mode "Architectural Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid options and parameters whenever possible. Any =20 options and parameters should be configured or negotiated dynamically rather than manually. This especially true in LLNs where the number of devices may be large and manual configuration is infeasible. This has been taken into account in the design of RPL whereby the DODAG root provides a number of parameters to the devices joining the DODAG, thus avoiding cumbersome configuration on the routers and potential sources of misconfiguration (e.g. values of trickle =20 timers, ...). Still there are additional RPL parameters that a RPL implementation should allow to be configured, which are discussed in this section. 16.2.1.1. DIS mode of operation upon boot-up When a node is first powered up: 1. The node may decide to stay silent, waiting to receive DIO messages from DODAG of interest (advertising a supported OF and metrics/constraints) and not send any multicast DIO messages until it has joined a DODAG. 2. The node may decide to send one or more DIS messages (optionally requesting DIO for a specific DODAG) message as an initial probe for nearby DODAGs, and in the absence of DIO messages in reply after some configurable period of time, the node may decide to root a floating DODAG and start sending multicast DIO messages. A RPL implementation SHOULD allow configuring the preferred mode of operation listed above along with the required parameters (in the second mode: the number of DIS messages and related timer). 16.2.2. DIO and DAO Base Message and Options Configuration RPL specifies a number of protocol parameters considering the large spectrum of applications where it will be used. That said, particular attention has been given to limiting the number of these parameters that must be configured on each RPL router. Instead, a Winter, et al. Expires December 30, 2010 [Page 92] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 number of the default values can be used, and when required these parameters can be provided by the DODAG root thus allowing for dynamic parameter setting. A RPL implementation SHOULD allow configuring the following routing protocol parameters. As pointed out above, note that a large set of parameters is configured on the DODAG root. 16.2.3. Protocol Parameters to be configured on every router in the LLN o RPLInstanceID [DIO message, in DIO base message]. Although the RPLInstanceID must be configured on the DODAG root, it must also be configured as a policy on every node in order to determine whether or not the node should join a particular DODAG. Note =20 that a second RPLInstance can be configured on the node, should it become root of a floating DODAG. o Objective Code Point (OCP) o List of supported metrics: [I-D.ietf-roll-routing-metrics] specifies a number of metrics and constraints used for the DODAG formation. Thus a RPL implementation should allow configuring =20= the list of metrics that a node can accept and understand. If a DIO is received with a metric and/or constraint that is not =20 understood or supported, as specified in Section 7.5, the node would join as a leaf node. o DODAGID [DIO, DIO base option] and [DAO message when the D flag =20= of the DAO message is set). o Route Information (and preference) [DIO message, in Route Information option] o Solicited Information [DIS message, in Solicited Information option]. Note that an RPL implementation SHOULD allow =20 configuring when such messages should be sent and under which circumstances, along with the value of the RPLInstance ID, V/I/D flags. o K flag [DAO message, in DAO base message]. o MOP (Mode of Operation) [DIO message, in DIO base message] 16.2.4. Protocol Parameters to be configured on every non-root router in the LLN o Target prefix [DAO, in RPL Target option and DIO messages] Winter, et al. Expires December 30, 2010 [Page 93] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o Transit information [DAO, Transit information option]: A RPL implementation SHOULD allow configuring whether a non-storing =20 node provides the transit information in DAO messages. A node whose DODAG parent set is empty may become the DODAG root =20 of a floating DODAG. It may also set its DAGPreference such that it is less preferred. Thus a RPL implementation MUST allow configuring =20= the set of actions that the node should initiate in this case: o Start its own (floating) DODAG: the new DODAGID must be =20 configured in addition to its DAGPreference o Poison the broken path (see procedure in Section 7.2.2.5) o Trigger a local repair 16.2.5. Parameters to be configured on the DODAG root In addition, several other parameters are configured only on the DODAG root and advertised in options carried in DIO messages. As specified in Section 7.3, a RPL implementation makes use of trickle timers to govern the sending of DIO messages. The operation of the trickle algorithm is determined by a set of configurable parameters, which MUST be configurable and that are then advertised by the DODAG root along the DODAG in DIO messages. o DIOIntervalDoublings [DIO, in DODAG configuration option] o DIOIntervalMin [DIO, in DODAG configuration option] o DIORedundancyConstant [DIO, in DODAG configuration option] In addition, a RPL implementation SHOULD allow for configuring the following set of RPL parameters: o Path Control Size [DIO, in DODAG configuration option] o MinHopRankIncrease [DIO, in DODAG configuration option] o The following fields: MOP (Mode of Operation), DODAGPreference field [DIO message, DIO Base object] o Route information (list of prefixes with preference) [DIO =20 message, in Route Information option] o The T flag allows for triggering a refresh of the downward =20 routes. A RPL implementation SHOULD support manual setting of the T flag Winter, et al. Expires December 30, 2010 [Page 94] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 or upon the occurrence of a set of event such as the expiration =20= of a configurable periodic timer. o List of metrics and constraints used for the DODAG. o Prefix information along with valid and preferred lifetime and =20= the L and A flags. [DIO message, Prefix Information option]. A RPL implementation SHOULD allow configuring if the Prefix Information Option must be carried with the DIO message to distribute the prefix information for auto-configuration. In that case, the RPL implementation MUST allow the list of prefixes to be advertised =20= in the Prefix Information Option along with the corresponding flags. DAG Root behavior: in some cases, a node may not want to permanently act as a floating DODAG root if it cannot join a grounded DODAG. =20= For example a battery-operated node may not want to act as a floating DODAG root for a long period of time. Thus a RPL implementation MAY support the ability to configure whether or not a node could act =20 as a floating DODAG root for a configured period of time. DAG Version Number Increment: a RPL implementation may allow by configuration at the DODAG root to refresh the DODAG states by updating the DODAGVersionNumber. A RPL implementation SHOULD allow configuring whether or not periodic or event triggered mechanisms =20= are used by the DODAG root to control DODAGVersionNumber change (which triggers a global repair as specified in Section 3.3.2. 16.2.6. Configuration of RPL Parameters related to DAO-based mechanisms DAO messages are optional and used in DODAGs that require downward routing operation. This section deals with the set of parameters related to DAO message and provides recommendations on their configuration. An implementation SHOULD bound the time that the entry is allocated in the UNREACHABLE state. Upon the equivalent expiry of the related timer (RemoveTimer), the entry SHOULD be suppressed. Thus a RPL implementation MAY allow for the configuration of the RemoveTimer. While the entry is in the UNREACHABLE state a node SHOULD make a reasonable attempt to report a No-Path to each of the DAO parents. That number of attempts MAY be configurable. When the associated Retry Counter for a REACHABLE(Pending) entry reaches a maximum threshold, the entry is placed into the =20 UNREACHABLE state and No-Path should be scheduled to send to the node's DAO Parents. The maximum threshold MAY be configurable. Winter, et al. Expires December 30, 2010 [Page 95] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 An implementation should support rate-limiting the sending of DAO messages. The related parameters MAY be configurable. When scheduling to send a DAO, an implementation should equivalently start a timer (DelayDAO) to delay sending the DAO, thus helping to potentially aggregate DAOs. The DelayDAO timer MAY be configurable. 16.2.7. Default Values This document specifies default values for the following set of RPL variables: DEFAULT_PATH_CONTROL_SIZE DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_REDUNDANCY_CONSTANT DEFAULT_MIN_HOP_RANK_INCREASE It is recommended to specify default values in protocols; that being said, as discussed in [RFC5706], default values may make less and less sense. RPL is a routing protocol that is expected to be used =20= in a number of contexts where network characteristics such as the =20 number of nodes, link and nodes types are expected to vary significantly. Thus, these default values are likely to change with the context and as the technology will evolve. Indeed, LLNs' related technology (e.g. hardware, link layers) have been evolving dramatically over =20= the past few years and such technologies are expected to change and evolve considerably in the coming years. The proposed values are not based on extensive best current =20 practices and are considered to be conservative. 16.3. Monitoring of RPL Operation Several RPL parameters should be monitored to verify the correct operation of the routing protocol and the network itself. This section lists the set of monitoring parameters of interest. 16.3.1. Monitoring a DODAG parameters A RPL implementation SHOULD provide information about the following parameters: o DODAG Version number [DIO message, in DIO base message] o Status of the G flag [DIO message, in DIO base message] o Status of the MOP field [DIO message, in DIO base message] Winter, et al. Expires December 30, 2010 [Page 96] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o Value of the DTSN [DIO message, in DIO base message] o Value of the rank [DIO message, in DIO base message] o DAOSequence: Incremented at each unique DAO message, echoed in =20= the DAO-ACK message [DAO and DAO-ACK messages] o Route Information [DIO message, Route Information option] (list =20= of IPv6 prefixes per parent along with lifetime and preference] o Trickle parameters: * DIOIntervalDoublings [DIO, in DODAG configuration option] * DIOIntervalMin [DIO, in DODAG configuration option] * DIORedundancyConstant [DIO, in DODAG configuration option] o Path Control Size [DIO, in DODAG configuration option] o MinHopRankIncrease [DIO, in DODAG configuration option] Values that may be monitored only on the DODAG root o Transit Information [DAO, Transit Information option]: A RPL implementation SHOULD allow configuring whether the set of received Transit Information options should be displayed on the DODAG root. In this case, the RPL database of received Transit Information should also contain: the path-sequence, path control, path lifetime and parent address. 16.3.2. Monitoring a DODAG inconsistencies and loop detection Detection of DODAG inconsistencies is particularly critical in RPL networks. Thus it is recommended for a RPL implementation to =20 provide appropriate monitoring tools. A RPL implementation SHOULD provide a counter reporting the number of a times the node has detected an inconsistency with respect to a DODAG parent, e.g. if the DODAGID =20= has changed. When possible more granular information about inconsistency =20 detection should be provided. A RPL implementation MAY provide counters reporting the number of following inconsistencies: o Packets received with O bit set (to down) from a node with a higher rank Winter, et al. Expires December 30, 2010 [Page 97] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o Packets received with O bit reset (to up) from a node with a =20 lower rank o Number of packets with the F bit set o Number of packets with the R bit set 16.4. Monitoring of the RPL data structures 16.4.1. Candidate Neighbor Data Structure A node in the candidate neighbor list is a node discovered by the some means and qualified to potentially become a parent (with high enough local confidence). A RPL implementation SHOULD provide a way to monitor the candidate neighbor list with some metric reflecting local confidence (the degree of stability of the neighbors) as measured by some metrics. A RPL implementation MAY provide a counter reporting the number of times a candidate neighbor has been ignored, should the number of candidate neighbors exceeds the maximum authorized value. 16.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table For each DODAG, a RPL implementation is expected to keep track of =20= the following DODAG table values: o RPLInstanceID o DODAGID o DODAGVersionNumber o Rank o Objective Code Point o A set of DODAG Parents o A set of prefixes offered upwards along the DODAG o Trickle timers used to govern the sending of DIO messages for the DODAG o List of DAO parents o DTSN Winter, et al. Expires December 30, 2010 [Page 98] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o Node status (router versus leaf) A RPL implementation SHOULD allow for monitoring the set of parameters listed above. 16.4.3. Routing Table and DAO Routing Entries A RPL implementation maintains several information elements related to the DODAG and the DAO entries (for storing nodes). In the case =20= of a non storing node, a limited amount of information is maintained (the routing table is mostly reduced to a set of DODAG parents along with characteristics of the DODAG as mentioned above) whereas in the case of storing nodes, this information is augmented with routing entries. A RPL implementation SHOULD provide the ability to monitor the following parameters: o Next Hop (DODAG parent) o Next Hop Interface o Path metrics value for each DODAG parent A DAO Routing Table Entry conceptually contains the following elements (for storing nodes only): o Advertising Neighbor Information o IPv6 Address o Interface ID to which DAO Parents has this entry been reported o Retry Counter o Logical equivalent of DAO Content: * DAO Sequence * DAO Lifetime * DAO Path Control o Destination Prefix (or Address or Mcast Group) A RPL implementation SHOULD provide information about the state of each DAO Routing Table entry states. Winter, et al. Expires December 30, 2010 [Page 99] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 16.5. Fault Management Fault management is a critical component used for troubleshooting, verification of the correct mode of operation of the protocol, network design, and is also a key component of network performance monitoring. A RPL implementation SHOULD allow providing the following information related to fault managements: o Memory overflow along with the cause (e.g. routing tables overflow, ...) o Number of times a packet could not be sent to a DODAG parent flagged as valid o Number of times a packet has been received for which the router did not have a corresponding RPLInstanceID o Number of times a local repair procedure was triggered o Number of times a global repair was triggered by the DODAG root o Number of received malformed messages o Number of seconds with packets to forward and no next hop (DODAG parent) o Number of seconds without next hop (DODAG parent) o Number of times a node has joined a DODAG as a leaf because it received a DIO with metric/constraint not understood and it was configured to join as a leaf node in this case (see Section =20 16.6). It is RECOMMENDED to report faults via at least error log messages. Other protocols may be used to report such faults. 16.6. Policy Policy rules can be used by a RPL implementation to determine =20 whether or not the node is allowed to join a particular DODAG advertised =20 by a neighbor by means of DIO messages. This document specifies operation within a single DODAG. A DODAG is characterized by the following tuple (RPLInstanceID, DODAGID). Furthermore, as pointed out above, DIO messages are used to =20 advertise other DODAG characteristics such as the routing metrics and constraints used to build to the DODAG and the Objective Function in use (specified by OCP). Winter, et al. Expires December 30, 2010 [Page 100] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 The first policy rules consists of specifying the following conditions that a RPL node must satisfy to join a DODAG: o RPLInstanceID o DODAGID o List of supported routing metrics and constraints o Objective Function (OCP values) A RPL implementation MUST allow configuring these parameters and SHOULD specify whether the node must simply ignore the DIO if the advertised DODAG is not compliant with the local policy or whether the node should join as the leaf node if only the list of supported routing metrics and constraints, and the OF is not supported. A RPL implementation SHOULD allow configuring the set of acceptable or preferred Objective Functions (OF) referenced by their Objective Codepoints (OCPs) for a node to join a DODAG, and what action should be taken if none of a node's candidate neighbors advertise one of =20= the configured allowable Objective Functions, or if the advertised metrics/constraint is not understood/supported. Two actions can be taken in this case: o The node joins the DODAG as a leaf node as specified in Section 7.5 o The node does not join the DODAG A node in an LLN may learn routing information from different =20 routing protocols including RPL. It is in this case desirable to control =20= via administrative preference which route should be favored. An implementation SHOULD allow for specifying an administrative preference for the routing protocol from which the route was =20 learned. Internal Data Structures: some RPL implementations may limit the =20 size of the candidate neighbor list in order to bound the memory usage, =20= in which case some otherwise viable candidate neighbors may not be considered and simply dropped from the candidate neighbor list. A RPL implementation MAY provide an indicator on the size of the candidate neighbor list. 16.7. Liveness Detection and Monitoring By contrast with several other routing protocols, RPL does not =20 define any 'keep-alive' mechanisms to detect routing adjacency failure: =20 this Winter, et al. Expires December 30, 2010 [Page 101] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 is in most cases, because such a mechanism may be too expensive in terms of bandwidth and even more importantly energy (a battery operated device could not afford to send periodic Keep alive). =20 Still RPL requires mechanisms to detect that a neighbor is no longer reachable: this can be performed by using mechanisms such as NUD (Neighbor Unreachability Detection) or even some form of Keep-alive that are outside of this document. 16.8. Fault Isolation It is RECOMMENDED to quarantine neighbors that start emitting malformed messages at unacceptable rates. 16.9. Impact on Other Protocols RPL has very limited impact on other protocols. Where more than one routing protocol is required on a router such as a LBR, it is expected for the device to support routing redistribution functions between the routing protocols to allow for reachability between the two routing domains. Such redistribution SHOULD be governed by the use of user configurable policy. With regards to the impact in terms of traffic on the network, RPL has been designed to limit the control traffic thanks to mechanisms such as Trickle timers (Section 7.3). Thus the impact of RPL on other protocols should be extremely limited. 16.10. Performance Management Performance management is always an important aspect of a protocol and RPL is not an exception. Several metrics of interest have been specified by the IP Performance Monitoring (IPPM) Working Group: =20 that being said, they will be hardly applicable to LLN considering the cost of monitoring these metrics in terms of resources on the =20 devices and required bandwidth. Still, RPL implementation MAY support some of these, and other parameters of interest are listed below: o Number of repairs and time to repair in seconds (average, variance) o Number of times and duration during which a devices could not forward a packet because of a lack of reachable neighbor in its routing table o Monitoring of resources consumption by RPL itself in terms of bandwidth and required memory Winter, et al. Expires December 30, 2010 [Page 102] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 o Number of RPL control messages sent and received Winter, et al. Expires December 30, 2010 [Page 103] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 17. Security Considerations 17.1. Overview =46rom a security perspective, RPL networks are no different from = any other network. They are vulnerable to passive eavesdropping attacks and potentially even active tampering when physical access to a wire is not required to participate in communications. The very nature =20= of ad hoc networks and their cost objectives impose additional security constraints, which perhaps make these networks the most difficult environments to secure. Devices are low-cost and have limited capabilities in terms of computing power, available storage, and power drain; and it cannot always be assumed they have neither a trusted computing base nor a high-quality random number generator aboard. Communications cannot rely on the online availability of a fixed infrastructure and might involve short-term relationships between devices that may never have communicated before. These constraints might severely limit the choice of cryptographic algorithms and protocols and influence the design of the security architecture because the establishment and maintenance of trust relationships between devices need to be addressed with care. In addition, battery lifetime and cost constraints put severe limits on the security overhead these networks can tolerate, something that is of far less concern with higher bandwidth networks. Most of these security architectural elements can be implemented at higher layers and may, therefore, be considered to be outside the scope of this standard. Special care, however, needs to be exercised with respect to interfaces to these higher layers. The security mechanisms in this standard are based on symmetric-key and public-key cryptography and use keys that are to be provided by higher layer processes. The establishment and maintenance of these keys are outside the scope of this standard. The mechanisms =20 assume a secure implementation of cryptographic operations and secure and authentic storage of keying material. The security mechanisms specified provide particular combinations of the following security services: Data confidentiality: Assurance that transmitted information is =20 only disclosed to parties for which it is intended. Data authenticity: Assurance of the source of transmitted information (and, hereby, that information was not modified in transit). Winter, et al. Expires December 30, 2010 [Page 104] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Replay protection: Assurance that a duplicate of transmitted information is detected. Timeliness (delay protection): Assurance that transmitted information was received in a timely manner. The actual protection provided can be adapted on a per-packet basis and allows for varying levels of data authenticity (to minimize security overhead in transmitted packets where required) and for optional data confidentiality. When nontrivial protection is required, replay protection is always provided. Replay protection is provided via the use of a non-repeating value (nonce) in the packet protection process and storage of some status information for each originating device on the receiving device, which allows detection of whether this particular nonce value was used previously by the originating device. In addition, so-called delay protection is provided amongst those devices that have a loosely synchronized clock on board. The acceptable time delay can be adapted on a per-packet basis and allows for varying latencies =20= (to facilitate longer latencies in packets transmitted over a multi-hop communication path). Cryptographic protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and application-specific tradeoffs between key storage and key maintenance costs versus the cryptographic protection provided. If a group key is used for peer- to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key- sharing group. Data authenticity may be provided using symmetric-key based or public-key based techniques. With public-key based techniques (via signatures), one corroborates evidence as to the unique originator =20= of transmitted information, whereas with symmetric-key based techniques data authenticity is only provided relative to devices in a key- sharing group. Thus, public-key based authentication may be useful in scenarios that require a more fine-grained authentication than =20= can be provided with symmetric-key based authentication techniques =20 alone, such as with group communications (broadcast, multicast), or in scenarios that require non-repudiation. Winter, et al. Expires December 30, 2010 [Page 105] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 18. IANA Considerations 18.1. RPL Control Message The RPL Control Message is an ICMP information message type that is to be used carry DODAG Information Objects, DODAG Information Solicitations, and Destination Advertisement Objects in support of RPL operation. IANA has defined an ICMPv6 Type Number Registry. The suggested type value for the RPL Control Message is 155, to be confirmed by IANA. 18.2. New Registry for RPL Control Codes IANA is requested to create a registry, RPL Control Codes, for the Code field of the ICMPv6 RPL Control Message. New codes may be allocated only by an IETF Consensus action. Each code should be tracked with the following qualities: o Code o Description o Defining RFC Three codes are currently defined: +------+----------------------------------------------=20 +-------------+ | Code | Description | =20 Reference | +------+----------------------------------------------=20 +-------------+ | 0x00 | DODAG Information Solicitation | =20 This | | | | =20 document | | | =20 | | | 0x01 | DODAG Information Object | =20 This | | | | =20 document | | | =20 | | | 0x02 | Destination Advertisement Object | =20 This | | | | =20 document | | | =20 | | | 0x03 | Destination Advertisement Object | =20 This | | | Acknowledgment | =20 document | | | =20 | | | 0x80 | Secure DODAG Information Solicitation | =20 This | | | | =20 document | | | =20 | | | 0x81 | Secure DODAG Information Object | =20 This | | | | =20 document | Winter, et al. Expires December 30, 2010 [Page 106] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 | 0x82 | Secure Destination Advertisement Object | =20 This | | | | =20 document | | | =20 | | | 0x83 | Secure Destination Advertisement Object | =20 This | | | Acknowledgment | =20 document | +------+----------------------------------------------=20 +-------------+ RPL Control Codes 18.3. New Registry for the Mode of Operation (MOP) DIO Control Field IANA is requested to create a registry for the Mode of Operation (MOP) DIO Control Field, which is contained in the DIO Base. New fields may be allocated only by an IETF Consensus action. Each field should be tracked with the following qualities: o Mode of Operation o Capability description o Defining RFC Three values are currently defined: +-----+----------------------------------------------=20 +--------------+ | MOP | Description | =20 Reference | +-----+----------------------------------------------=20 +--------------+ | 000 | No downward routes maintained by RPL | =20 This | | | | =20 document | | | =20 | | | 001 | Non-Storing mode of operation | =20 This | | | | =20 document | | | =20 | | | 010 | Storing mode of operation with no multicast | =20 This | | | support | =20 document | | | =20 | | | 011 | Storing mode of operation with multicast | =20 This | | | support | =20 document | +-----+----------------------------------------------=20 +--------------+ DIO Base Flags 18.4. RPL Control Message Option IANA is requested to create a registry for the RPL Control Message Options Winter, et al. Expires December 30, 2010 [Page 107] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 +-------+-----------------------+---------------+ | Value | Meaning | Reference | +-------+-----------------------+---------------+ | 0 | Pad1 | This document | | | | | | 1 | PadN | This document | | | | | | 2 | DAG Metric Container | This Document | | | | | | 3 | Routing Information | This Document | | | | | | 4 | DODAG Configuration | This Document | | | | | | 5 | RPL Target | This Document | | | | | | 6 | Transit Information | This Document | | | | | | 7 | Solicited Information | This Document | | | | | | 8 | Prefix Information | This Document | +-------+-----------------------+---------------+ RPL Control Message Options 18.5. Objective Code Point (OCP) Registry IANA is requested to create a registry to manage the codespace of =20= the Objective Code Point (OCP) field. No OCP codepoints are defined in this specification. 18.6. ICMPv6: Error in Source Routing Header In some cases RPL will return an ICMPv6 error message when a message cannot be delivered as specified by its source routing header. This ICMPv6 error message is "Error in Source Routing Header" JP> "." missing IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message Types. ICMPv6 Message Type 1 describes "Destination Unreachable" codes. The "Error in Source Routing Header" code is suggested to be allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, with a suggested code value of 7, to be confirmed by IANA. 18.7. Link-Local Scope multicast address The rules for assigning new IPv6 multicast addresses are defined in [RFC3307]. This specification requires the allocation of a new permanent multicast address with a link local scope for RPL routers, Winter, et al. Expires December 30, 2010 [Page 108] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 with a suggested value of FF02::1:A, to be confirmed by IANA. Winter, et al. Expires December 30, 2010 [Page 109] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 19. Acknowledgements The authors would like to acknowledge the review, feedback, and comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Mischa Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, =20 Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph Reddy, Don Sturek, Joydeep Tripathi, and Nicolas Tsiftes. The authors would like to acknowledge the guidance and input =20 provided by the ROLL Chairs, David Culler and JP Vasseur. The authors would like to acknowledge prior contributions of Robert Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom have provided useful design considerations to RPL. RPL Security Design, found in Section 9, Section 17, and elsewhere throughout the document, is primarily the contribution of the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip Levis, Kris Pister, and Rene Struik. Winter, et al. Expires December 30, 2010 [Page 110] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 20. Contributors RPL is the result of the contribution of the following members of =20= the RPL Author Team, including the editors, and additional contributors as listed below: JP Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins Issy Les Moulineaux, 92782 France Email: jpv@cisco.com Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/ Philip Levis Stanford University 358 Gates Hall, Stanford University Stanford, CA 94305-9030 USA Email: pal@cs.stanford.edu Richard Kelsey Ember Corporation Boston, MA USA Phone: +1 617 951 1225 Email: kelsey@ember.com Jonathan W. Hui Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, CA 94107 USA Email: jhui@archrock.com Winter, et al. Expires December 30, 2010 [Page 111] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, 94544 USA Email: kpister@dustnetworks.com Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen, DK-2100 Denmark Email: abr@sdesigns.dk R. Struik Email: rstruik.ext@gmail.com Stephen Dawson-Haggerty UC Berkeley Soda Hall, UC Berkeley Berkeley, CA 94720 USA Email: stevedh@cs.berkeley.edu Winter, et al. Expires December 30, 2010 [Page 112] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 21. References 21.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 21.2. Informative References [AppliedCryptography] Menzes, AJ., van Oorschot, PC., and SA. Vanstone, "Handbook of Applied Cryptography", CRC Press , 1997. [CCMStar] IEEE, "IEEE Std. 802.15.4-2006, IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks - Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs)", IEEE Press Revision of IEEE Std 802.15.4-2003, 2006. [I-D.hui-6man-rpl-option] Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Information in Data-Plane Datagrams", draft-hui-6man-rpl-option-01 (work in progress), June 2010. JP> Above reference must be normative [I-D.hui-6man-rpl-routing-header] Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Header for Source Routes with RPL", draft-hui-6man-rpl-routing-header-02 (work in progress), June 2010. JP> Above reference must be normative [I-D.ietf-manet-nhdp] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-12 (work in progress), March 2010. [I-D.ietf-roll-of0] Thubert, P., "RPL Objective Function 0", draft-ietf-roll-of0-02 (work in progress), June 2010. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Networks, D., and H. Chong, =20 "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-07 (work in progress), June 2010. JP> Above reference must be normative Winter, et al. Expires December 30, 2010 [Page 113] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-03 (work in progress), March 2010. [I-D.ietf-roll-trickle] Levis, P., Clausen, T., Hui, J., and J. Ko, "The Trickle Algorithm", draft-ietf-roll-trickle-01 (work in =20 progress), April 2010. JP> Above reference must be normative [Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks 7: 395-405, 1983, . [RFC1958] Carpenter, B., "Architectural Principles of the =20 Internet", RFC 1958, June 1996. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC =20 1982, August 1996. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and =20= L. Winter, et al. Expires December 30, 2010 [Page 114] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC =20 4101, June 2005. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5706] Harrington, D., "Guidelines for Considering Operations =20= and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power =20= and Lossy Networks", RFC 5867, June 2010. Winter, et al. Expires December 30, 2010 [Page 115] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [X9.63-2001] "ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key Agreement and Key Transport Using Elliptic Curve Cryptography", 2001. [X9.92] "ANSI X9.92, Public Key Cryptography for the Financial Services Industry - Digital Signature Algorithms Giving Partial Message Recovery - Part 1: Elliptic Curve =20 Pintsov- Vanstone Signatures (ECPVS)", 2009. Winter, et al. Expires December 30, 2010 [Page 116] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Authors' Addresses Tim Winter (editor) Email: wintert@acm.org Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com RPL Author Team IETF ROLL WG Email: rpl-authors@external.cisco.com Winter, et al. Expires December 30, 2010 [Page 117] =0C --Apple-Mail-51-270354032 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

Being a = co-author, I tried to make another pass while reading it as = a
first time reader, with more comments/suggestions. = There is a combination
of (1) minor editorial changes, (2) = required changes, ... 

No major = issue

I put all comment in ticket = #70

See JP>

ROLL            =
                                          T. Winter, Ed.
Internet-Draft
Intended status: Standards Track                         P. Thubert, Ed.
Expires: December 30, 2010                                 Cisco Systems
                                                         RPL Author Team
                                                            IETF ROLL WG
                                                            Jun 28, 2010


      RPL: IPv6 Routing Protocol for Low power and Lossy Networks
                         draft-ietf-roll-rpl-10

Abstract

   Low power and Lossy Networks (LLNs) are a class of network in which
   both the routers and their interconnect are constrained: LLN routers
   typically operate with constraints on (any subset of) processing
   power, memory and energy (battery), and their interconnects are
   characterized by (any subset of) high loss rates, low data rates and
   instability.  LLNs are comprised of anything from a few dozen and up
   to thousands of routers, and support point-to-point traffic (between
   devices inside the LLN), point-to-multipoint traffic (from a central
   control point to a subset of devices inside the LLN) and multipoint-
   to-point traffic (from devices inside the LLN towards a central
   control point).  This document specifies the IPv6 Routing Protocol
   for LLNs (RPL), which provides a mechanism whereby multipoint-to-
   point traffic from devices inside the LLN towards a central control
   point, as well as point-to-multipoint traffic from the central
   control point to the devices inside the LLN, is supported.  Support
   for point-to-point traffic is also available.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ie=
tf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 30, 2010.




Winter, et al.          Expires December 30, 2010               [Page 1]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.1.   Design Principles  . . . . . . . . . . . . . . . . . . .   6
     1.2.   Expectations of Link Layer Type  . . . . . . . . . . . .   7
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  11
     3.1.   Topology . . . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.1.  Topology Identifiers  . . . . . . . . . . . . . . . .  11
     3.2.   Instances, DODAGs, and DODAG Versions  . . . . . . . . .  11
     3.3.   Upward Routes and DODAG Construction . . . . . . . . . .  13
       3.3.1.  Objective Function (OF) . . . . . . . . . . . . . . .  14
       3.3.2.  DODAG Repair  . . . . . . . . . . . . . . . . . . . .  14
       3.3.3.  Security  . . . . . . . . . . . . . . . . . . . . . .  14
       3.3.4.  Grounded and Floating DODAGs  . . . . . . . . . . . .  14
       3.3.5.  Local DODAGs  . . . . . . . . . . . . . . . . . . . .  14
       3.3.6.  Administrative Preference . . . . . . . . . . . . . .  15
       3.3.7.  Datapath Validation and Loop Detection  . . . . . . .  15
       3.3.8.  Distributed Algorithm Operation . . . . . . . . . . .  15
     3.4.   Downward Routes and Destination Advertisement  . . . . .  15
     3.5.   Local DODAGs Route Discovery . . . . . . . . . . . . . .  16
     3.6.   Routing Metrics and Constraints Used By RPL  . . . . . .  16
       3.6.1.  Loop Avoidance  . . . . . . . . . . . . . . . . . . .  17
       3.6.2.  Rank Properties . . . . . . . . . . . . . . . . . . .  18
     3.7.   Traffic Flows Supported by RPL . . . . . . . . . . . . .  20
       3.7.1.  Multipoint-to-Point Traffic . . . . . . . . . . . . .  21
       3.7.2.  Point-to-Multipoint Traffic . . . . . . . . . . . . .  21
       3.7.3.  Point-to-Point Traffic  . . . . . . . . . . . . . . .  21
   4.  RPL Instance  . . . . . . . . . . . . . . . . . . . . . . . .  22
     4.1.   RPL Instance ID  . . . . . . . . . . . . . . . . . . . .  22
   5.  ICMPv6 RPL Control Message  . . . . . . . . . . . . . . . . .  24
     5.1.   RPL Security Fields  . . . . . . . . . . . . . . . . . .  25



Winter, et al.          Expires December 30, 2010               [Page 2]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


     5.2.   DODAG Information Solicitation (DIS) . . . . . . . . . .  30
       5.2.1.  Format of the DIS Base Object . . . . . . . . . . . .  30
       5.2.2.  Secure DIS  . . . . . . . . . . . . . . . . . . . . .  31
       5.2.3.  DIS Options . . . . . . . . . . . . . . . . . . . . .  31
     5.3.   DODAG Information Object (DIO) . . . . . . . . . . . . .  31
       5.3.1.  Format of the DIO Base Object . . . . . . . . . . . .  31
       5.3.2.  Secure DIO  . . . . . . . . . . . . . . . . . . . . .  33
       5.3.3.  DIO Options . . . . . . . . . . . . . . . . . . . . .  33
     5.4.   Destination Advertisement Object (DAO) . . . . . . . . .  33
       5.4.1.  Format of the DAO Base Object . . . . . . . . . . . .  34
       5.4.2.  Secure DAO  . . . . . . . . . . . . . . . . . . . . .  34
       5.4.3.  DAO Options . . . . . . . . . . . . . . . . . . . . .  35
     5.5.   Destination Advertisement Object Acknowledgement
            (DAO-ACK)  . . . . . . . . . . . . . . . . . . . . . . .  35
       5.5.1.  Format of the DAO-ACK Base Object . . . . . . . . . .  35
       5.5.2.  Secure DAO-ACK  . . . . . . . . . . . . . . . . . . .  36
       5.5.3.  DAO-ACK Options . . . . . . . . . . . . . . . . . . .  36
     5.6.   Consistency Check (CC) . . . . . . . . . . . . . . . . .  36
       5.6.1.  Format of the CC Base Object  . . . . . . . . . . . .  36
       5.6.2.  CC Options  . . . . . . . . . . . . . . . . . . . . .  38
     5.7.   RPL Control Message Options  . . . . . . . . . . . . . .  38
       5.7.1.  RPL Control Message Option Generic Format . . . . . .  38
       5.7.2.  Pad1  . . . . . . . . . . . . . . . . . . . . . . . .  39
       5.7.3.  PadN  . . . . . . . . . . . . . . . . . . . . . . . .  39
       5.7.4.  Metric Container  . . . . . . . . . . . . . . . . . .  40
       5.7.5.  Route Information . . . . . . . . . . . . . . . . . .  40
       5.7.6.  DODAG Configuration . . . . . . . . . . . . . . . . .  42
       5.7.7.  RPL Target  . . . . . . . . . . . . . . . . . . . . .  43
       5.7.8.  Transit Information . . . . . . . . . . . . . . . . .  45
       5.7.9.  Solicited Information . . . . . . . . . . . . . . . .  46
       5.7.10. Prefix Information  . . . . . . . . . . . . . . . . .  48
   6.  Sequence Counters . . . . . . . . . . . . . . . . . . . . . .  51
   7.  Upward Routes . . . . . . . . . . . . . . . . . . . . . . . .  53
     7.1.   DIO Base Rules . . . . . . . . . . . . . . . . . . . . .  53
     7.2.   Upward Route Discovery and Maintenance . . . . . . . . .  53
       7.2.1.  Neighbors and Parents within a DODAG Version  . . . .  53
       7.2.2.  Neighbors and Parents across DODAG Versions . . . . .  54
       7.2.3.  DIO Message Communication . . . . . . . . . . . . . .  58
     7.3.   DIO Transmission . . . . . . . . . . . . . . . . . . . .  59
       7.3.1.  Trickle Parameters  . . . . . . . . . . . . . . . . .  60
     7.4.   DODAG Selection  . . . . . . . . . . . . . . . . . . . .  60
     7.5.   Operation as a Leaf Node . . . . . . . . . . . . . . . .  60
     7.6.   Administrative Rank  . . . . . . . . . . . . . . . . . .  61
   8.  Downward Routes . . . . . . . . . . . . . . . . . . . . . . .  62
     8.1.   Destination Advertisement Parents  . . . . . . . . . . .  62
     8.2.   Downward Route Discovery and Maintenance . . . . . . . .  62
     8.3.   DAO Base Rules . . . . . . . . . . . . . . . . . . . . .  63
     8.4.   DAO Transmission Scheduling  . . . . . . . . . . . . . .  64



Winter, et al.          Expires December 30, 2010               [Page 3]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


     8.5.   Triggering DAO Messages  . . . . . . . . . . . . . . . .  64
     8.6.   Structure of DAO Messages  . . . . . . . . . . . . . . .  65
     8.7.   Non-storing Mode . . . . . . . . . . . . . . . . . . . .  65
     8.8.   Storing Mode . . . . . . . . . . . . . . . . . . . . . .  66
     8.9.   Path Control . . . . . . . . . . . . . . . . . . . . . .  67
     8.10.  Multicast Destination Advertisement Messages . . . . . .  68
   9.  Security Mechanisms . . . . . . . . . . . . . . . . . . . . .  69
     9.1.   Security Overview  . . . . . . . . . . . . . . . . . . .  69
     9.2.   Installing Keys  . . . . . . . . . . . . . . . . . . . .  70
     9.3.   Joining a Secure Network . . . . . . . . . . . . . . . .  70
     9.4.   Counter and Counter Compression  . . . . . . . . . . . .  71
       9.4.1.  Timestamp Counters  . . . . . . . . . . . . . . . . .  72
     9.5.   Functional Description of Packet Protection  . . . . . .  72
       9.5.1.  Transmission of Outgoing Packets  . . . . . . . . . .  72
       9.5.2.  Reception of Incoming Packets . . . . . . . . . . . .  74
       9.5.3.  Cryptographic Mode of Operation . . . . . . . . . . .  76
     9.6.   Coverage of Integrity and Confidentiality  . . . . . . .  77
   10. Packet Forwarding and Loop Avoidance/Detection  . . . . . . .  78
     10.1.  Suggestions for Packet Forwarding  . . . . . . . . . . .  78
     10.2.  Loop Avoidance and Detection . . . . . . . . . . . . . .  79
       10.2.1. Source Node Operation . . . . . . . . . . . . . . . .  80
       10.2.2. Router Operation  . . . . . . . . . . . . . . . . . .  80
   11. Multicast Operation . . . . . . . . . . . . . . . . . . . . .  83
   12. Maintenance of Routing Adjacency  . . . . . . . . . . . . . .  85
   13. Guidelines for Objective Functions  . . . . . . . . . . . . .  86
     13.1.  Objective Function Behavior  . . . . . . . . . . . . . .  86
   14. Suggestions for Interoperation with Neighbor Discovery  . . .  88
   15. RPL Constants and Variables . . . . . . . . . . . . . . . . .  89
   16. Manageability Considerations  . . . . . . . . . . . . . . . .  91
     16.1.  Introduction . . . . . . . . . . . . . . . . . . . . . .  91
     16.2.  Configuration Management . . . . . . . . . . . . . . . .  92
       16.2.1. Initialization Mode . . . . . . . . . . . . . . . . .  92
       16.2.2. DIO and DAO Base Message and Options Configuration  .  92
       16.2.3. Protocol Parameters to be configured on every
               router in the LLN . . . . . . . . . . . . . . . . . .  93
       16.2.4. Protocol Parameters to be configured on every
               non-root router in the LLN  . . . . . . . . . . . . .  93
       16.2.5. Parameters to be configured on the DODAG root . . . .  94
       16.2.6. Configuration of RPL Parameters related to
               DAO-based mechanisms  . . . . . . . . . . . . . . . .  95
       16.2.7. Default Values  . . . . . . . . . . . . . . . . . . .  96
     16.3.  Monitoring of RPL Operation  . . . . . . . . . . . . . .  96
       16.3.1. Monitoring a DODAG parameters . . . . . . . . . . . .  96
       16.3.2. Monitoring a DODAG inconsistencies and loop
               detection . . . . . . . . . . . . . . . . . . . . . .  97
     16.4.  Monitoring of the RPL data structures  . . . . . . . . .  98
       16.4.1. Candidate Neighbor Data Structure . . . . . . . . . .  98
       16.4.2. Destination Oriented Directed Acyclic Graph (DAG)



Winter, et al.          Expires December 30, 2010               [Page 4]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


               Table . . . . . . . . . . . . . . . . . . . . . . . .  98
       16.4.3. Routing Table and DAO Routing Entries . . . . . . . .  99
     16.5.  Fault Management . . . . . . . . . . . . . . . . . . . . 100
     16.6.  Policy . . . . . . . . . . . . . . . . . . . . . . . . . 100
     16.7.  Liveness Detection and Monitoring  . . . . . . . . . . . 101
     16.8.  Fault Isolation  . . . . . . . . . . . . . . . . . . . . 102
     16.9.  Impact on Other Protocols  . . . . . . . . . . . . . . . 102
     16.10. Performance Management . . . . . . . . . . . . . . . . . 102
   17. Security Considerations . . . . . . . . . . . . . . . . . . . 104
     17.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . 104
   18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
     18.1.  RPL Control Message  . . . . . . . . . . . . . . . . . . 106
     18.2.  New Registry for RPL Control Codes . . . . . . . . . . . 106
     18.3.  New Registry for the Mode of Operation (MOP) DIO
            Control Field  . . . . . . . . . . . . . . . . . . . . . 107
     18.4.  RPL Control Message Option . . . . . . . . . . . . . . . 107
     18.5.  Objective Code Point (OCP) Registry  . . . . . . . . . . 108
     18.6.  ICMPv6: Error in Source Routing Header . . . . . . . . . 108
     18.7.  Link-Local Scope multicast address . . . . . . . . . . . 108
   19. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 110
   20. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . 111
   21. References  . . . . . . . . . . . . . . . . . . . . . . . . . 113
     21.1.  Normative References . . . . . . . . . . . . . . . . . . 113
     21.2.  Informative References . . . . . . . . . . . . . . . . . 113
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 117


























Winter, et al.          Expires December 30, 2010               [Page 5]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


1.  Introduction

   Low power and Lossy Networks (LLNs) consist of largely of constrained
   nodes (with limited processing power, memory, and sometimes energy
   when they are battery operated).  
JP> or make use of energy scavenging 
These routers =
are interconnected by
   lossy links, typically supporting only low data rates, that are
   usually unstable with relatively low packet delivery rates.  Another
   characteristic of such networks is that the traffic patterns are not
   simply point-to-point, but in many cases point-to-multipoint or
   multipoint-to-point.  Furthermore such networks may potentially
   comprise up to thousands of nodes.  These characteristics offer
   unique challenges to a routing solution: the IETF ROLL Working Group
   has defined application-specific routing requirements for a Low power
   and Lossy Network (LLN) routing protocol, specified in [RFC5867],
   [RFC5826], [RFC5673], and [RFC5548].

   This document specifies the IPv6 Routing Protocol for Low power and
   lossy networks (RPL).  Note that although RPL was specified according
   to the requirements set forth in the aforementioned requirement
   documents, its use is in no way limited to these applications.

1.1.  Design Principles

   RPL was designed with the objective to meet the requirements spelled
   out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].

   A network may run multiple instances of RPL concurrently.  Each such
   instance may serve different and potentially antagonistic constraints
   or performance criteria.  This document defines how a single instance
   operates.

   In order to be useful in a wide range of LLN application domains, RPL
   separates packet processing and forwarding from the routing
   optimization objective.  Examples of such objectives include
   minimizing energy, minimizing latency, or satisfying constraints.
   This document describes the mode of operation of RPL.  Other
   companion documents specify routing objective functions.  A RPL
   implementation, in support of a particular LLN application, will
   include the necessary objective function(s) as required by the
   application.

   A set of companion documents to this specification will provide
   further guidance in the form of applicability statements specifying a
   set of operating points appropriate to the Building Automation, Home
   Automation, Industrial, and Urban application scenarios.




Winter, et al.          Expires December 30, 2010               [Page 6]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


1.2.  Expectations of Link Layer Type

   In compliance with the layered architecture of IP, RPL does not rely
   on any particular features of a specific link layer technology.  RPL
   is designed to be able to operate over a variety of different link
   layers, including but not limited to, low power wireless or PLC
   (Power Line Communication) technologies.

   Implementers may find [RFC3819] a useful reference when designing a
   link layer interface between RPL and a particular link layer
   technology.








































Winter, et al.          Expires December 30, 2010               [Page 7]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Additionally, this document uses terminology from
   [I-D.ietf-roll-terminology], and introduces the following
   terminology:

   DAG:  Directed Acyclic Graph.  A directed graph having the property
         that all edges are oriented in such a way that no cycles exist.
         All edges are contained in paths oriented toward and
         terminating at one or more root nodes.

   DAG root:  A DAG root is a node within the DAG that has no outgoing
         edge.  Because the graph is acyclic, by definition all DAGs
         must have at least one DAG root and all paths terminate at a
         DAG root.

   Destination Oriented DAG (DODAG):  A DAG rooted at a single
         destination, i.e. at a single DAG root (the DODAG root) with no
         outgoing edges.

   DODAG root:  A DODAG root is the DAG root of a DODAG.

   Up:   Up refers to the direction from leaf nodes towards DODAG roots,
         following DODAG edges.  This follows the common terminology
         used in graphs and depth-first-search, where vertices further
         from the root are "deeper," or "down," and vertices closer to
         the root are "shallower," or "up."

   Down: Down refers to the direction from DODAG roots towards leaf
         nodes, in the reverse direction of DODAG edges.  This follows
         the common terminology used in graphs and depth-first-search,
         where vertices further from the root are "deeper," or "down,"
         and vertices closer to the root are "shallower," or "up."

   Rank: A node's Rank defines the node's individual position relative
         to other nodes with respect to a DODAG root.  Rank strictly
         increases in the down direction and strictly decreases in the
         up direction.  The exact way Rank is computed depends on the
         DAG's Objective Function (OF).  The Rank may analogously track
         a simple topological distance, may be calculated as a function
         of link metrics, and may consider other properties such as
         constraints.




Winter, et al.          Expires December 30, 2010               [Page 8]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Objective Function (OF):  Defines which routing metrics, optimization
         objectives, and related functions a DAG uses to compute =
Rank.
JP> Add: "Furthermore, =
the OF dictates how parents in the DODAG are 
selected and thus the DODAG formation =
itself."
   Objective Code Point (OCP):  An identifier that indicates =
which
         Objective Function the DODAG uses.

   RPLInstanceID:  A unique identifier within a network.  Two DODAGs
         with the same RPLInstanceID share the same Objective Function.

   RPL Instance:  A set of one or more DODAGs that share a
         RPLInstanceID.  A RPL node can belong to at most one DODAG in a
         RPL Instance.  Each RPL Instance operates independently of
         other RPL Instances.  This document describes operation within
         a single RPL Instance.

   DODAGID:  The identifier of a DODAG root.  The DODAGID must be unique
         within the scope of a RPL Instance in the LLN.  
JP> s/must be unique/is =
unique

The tuple
         (RPLInstanceID, DODAGID) uniquely identifies a DODAG.

   DODAG Version:  A specific sequence number iteration ("version") of a
         DODAG with a given DODAGID.

   DODAGVersionNumber:  A sequential counter that is incremented by the
         root to form a new Version of a DODAG.  A DODAG Version is
         identified uniquely by the (RPLInstanceID, DODAGID,
         DODAGVersionNumber) tuple.

   Goal: The Goal is a 
JP> s/a/an
application specific goal that is defined =
outside
         the scope of RPL.  Any node that roots a DODAG will need to
         know about this Goal to decide if the Goal can be satisfied or
         not.  A typical Goal is to construct the DODAG according to a
         specific objective function and to keep connectivity to a set
         of hosts (e.g. to use an objective function that minimizes ETX
         and to be connected to a specific database host to store the
         collected data).

   Grounded:  A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating:  A DODAG is floating if is not Grounded.  A floating DODAG
         is not expected to have the properties required to satisfy the
         goal.  It may, however, provide connectivity to other nodes
         within the DODAG.

   DODAG parent:  A parent of a node within a DODAG is one of the
         immediate successors of the node on a path towards the DODAG
         root.  A DODAG parent's Rank is lower than the node's.  (See
         Section 3.6.2.1).



Winter, et al.          Expires December 30, 2010               [Page 9]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Sub-DODAG  The sub-DODAG of a node is the set of other nodes whose
         paths to the DODAG root pass through that node.  Nodes in the
         sub-DODAG of a node have a greater Rank than that node itself.
         (See Section 3.6.2.1)

   As they form networks, LLN devices often mix the roles of 'host' and
   'router' when compared to traditional IP networks.  In this document,
   'host' refers to an LLN device that can generate but does not forward
   RPL traffic, 'router' refers to an LLN device that can forward as
   well as generate RPL traffic, and 'node' refers to any RPL device,
   either a host or a router.








































Winter, et al.          Expires December 30, 2010              [Page 10]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


3.  Protocol Overview

   The aim of this section is to describe RPL in the spirit of
   [RFC4101].  Protocol details can be found in further sections.

3.1.  Topology

   This section describes how the basic RPL topologies, and the rules by
   which these are constructed, i.e. the rules governing DODAG
JP> DODAG: expand terms when first =
used.
   formation.

3.1.1.  Topology Identifiers

   RPL uses four identifiers to maintain the topology:

   o  The first is a RPLInstanceID.  A RPLInstanceID identifies a set of
      one or more DODAGs.  All DODAGs in the same RPL Instance use the
      same Objective Function.  
JP> =
s/Objective Function/Objective Function =
(OF)

A network may have multiple
      RPLInstanceIDs, each of which defines an independent set of
      DODAGs, which may be optimized for different OFs and/or
      applications.  The set of DODAGs identified by a RPLInstanceID is
      called a RPL Instance.

   o  The second is a DODAGID.  The scope of a DODAGID is a RPL
      Instance.  The combination of RPLInstanceID and DODAGID uniquely
      identifies a single DODAG in the network.  A RPL Instance may have
      multiple DODAGs, each of which has an unique DODAGID.

   o  The third is a DODAGVersionNumber.  The scope of a
      DODAGVersionNumber is a DODAG.  A DODAG is sometimes reconstructed
      from the DODAG root, by incrementing the DODAGVersionNumber.  The
      combination of RPLInstanceID, DODAGID, and DODAGVersionNumber
      uniquely identifies a DODAG Version.

   o  The fourth is Rank.  The scope of Rank is a DODAG Version.  Rank
      establishes a partial order over a DODAG Version, defining
      individual node positions with respect to the DODAG root.

JP> I don't think that the rank is a DODAG =
identifier.
3.2.  =
Instances, DODAGs, and DODAG Versions

   A RPL Instance contains one or more Destination Oriented DAG =
(DODAG)
JP> s/Destination Oriented DAG (DODAG)/DODAG since it must =
have been 
expanded =
before.
   roots.  A RPL Instance may =
provide routes to certain destination
   prefixes, reachable via the DODAG roots or alternate paths within the
   DODAG.  These roots may operate independently, or may coordinate over
   a non-LLN backchannel.

   A RPL Instance may comprise:




Winter, et al.          Expires December 30, 2010              [Page 11]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  a single DODAG with a single root

      *  For example, a DODAG optimized to minimize latency rooted at a
         single centralized lighting controller in a home automation
         application.

   o  multiple uncoordinated DODAGs with independent roots (differing
      DODAGIDs)

      *  For example, multiple data collection points in an urban data
         collection application that do not have an always-on backbone
         suitable to coordinate to form a single DODAG, 
JP> The reason for multiple DODAG might not be because the =
network
does not have an always-on backbone ... =
but just to partition the network
(the "and" =
that follows may be confusing).
and further use
         the formation of multiple DODAGs as a means to dynamically and
         autonomously partition the network.

   o  a single DODAG with a single virtual root 
JP> Let's avoid using the term =
"virtual root" since this is not a RPL terms.
coordinating LLN sinks
      (with the same DODAGID) over some non-LLN backbone

      *  For example, multiple border routers operating with a reliable
         backbone, e.g. in support of a 6LowPAN application, that are
         capable to act as logically equivalent sinks to the same DODAG.

   o  a combination of the above as suited to some application scenario.

   Each RPL packet has meta-data that associates it with a particular
   RPLInstanceID and therefore RPL Instance.(Section 4). =
 
JP> s/.(Section 4)/(see Section =
4).

The
   provisioning or automated discovery of a mapping between a
   RPLInstanceID and a type or service of application traffic is beyond
   the scope of this specification.

   Figure 1 depicts an example of a RPL Instance comprising three DODAGs
   with DODAG Roots R1, R2, and R3.  Figure 2 depicts how a DODAG
   version number increment leads to a new DODAG Version.


















Winter, et al.          Expires December 30, 2010              [Page 12]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


     +----------------------------------------------------------------+
     |                                                                |
     | +--------------+                                               |
     | |              |                                               |
     | |     (R1)     |            (R2)                   (R3)        |
     | |     /  \     |            /| \                  / |  \       |
     | |    /    \    |           / |  \                /  |   \      |
     | |  (A)    (B)  |         (C) |  (D)     ...    (F) (G)  (H)    |
     | |  /|\     |\  |         /   |   |\             |   |    |     |
     | | : : :    : : |        :   (E)  : :            :   :    :     |
     | |              |            / \                                |
     | +--------------+           :   :                               |
     |      DODAG                                                     |
     |                                                                |
     +----------------------------------------------------------------+
                                RPL Instance

                          Figure 1: RPL Instance



            +----------------+                +----------------+
            |                |                |                |
            |      (R1)      |                |      (R1)      |
            |      /  \      |                |      /         |
            |     /    \     |                |     /          |
            |   (A)    (B)   |         \      |   (A)          |
            |   /|\     |\   |    ------\     |   /|\          |
            |  : : (C)  : :  |           \    |  : : (C)       |
            |                |           /    |        \       |
            |                |    ------/     |         \      |
            |                |         /      |         (B)    |
            |                |                |          |\    |
            |                |                |          : :   |
            |                |                |                |
            +----------------+                +----------------+
                Version N                        Version N+1


                          Figure 2: DODAG Version

JP> Just indicate that a new DODAG Version does not always =
imply a new DODAG topology
(this is an =
example).
3.3.  Upward Routes and DODAG =
Construction

   RPL provisions routes up towards DODAG roots, forming a DODAG
   optimized according to an Objective Function (OF).  RPL nodes
   construct and maintain these DODAGs through DODAG Information Object
   (DIO) messages.




Winter, et al.          Expires December 30, 2010              [Page 13]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


3.3.1.  Objective Function (OF)

   The Objective Function (OF) defines how RPL nodes select and optimize
   routes within a RPL Instance.  The OF is identified by an Objective
   Code Point (OCP) within the DIO Configuration option.  An OF defines
   how nodes translate one or more metrics and constraints, which are
   themselves defined in [I-D.ietf-roll-routing-metrics], into a value
   called Rank, which approximates the node's distance from a DODAG
   root.  An OF also defines how nodes select parents.  Further details
   may be found in Section 13, [I-D.ietf-roll-routing-metrics],
   [I-D.ietf-roll-of0], and related companion specifications.

3.3.2.  DODAG Repair

   A DODAG Root institutes a global repair operation by incrementing the
   DODAG Version Number.  This initiates a new DODAG version.  Nodes in
   the new DODAG version can choose a new position whose Rank is not
   constrained by their Rank within the old DODAG Version.

   RPL also supports mechanisms which may be used for local repair
   within the DODAG version.  The DIO message specifies the necessary
   parameters as configured from the DODAG root, as controlled by policy
   at the root.

3.3.3.  Security

   RPL supports message confidentiality and integrity.  It is designed
   such that link-layer mechanisms can be used when available and
   appropriate, yet in their absence RPL can use its own mechanisms.

3.3.4.  Grounded and Floating DODAGs

   DODAGs can be grounded or floating: the DODAG root advertises which
   is the case.  A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal.  A floating
   DODAG is not expected to satisfy the goal and in most cases only
   provides routes to nodes within the DODAG.  Floating DODAGs may be
   used, for example, to preserve inner connectivity during repair.

3.3.5.  Local DODAGs

   RPL nodes can optimize routes to a destination within an LLN by
   forming a local DODAG whose DODAG Root is the desired destination.
   Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
   have one and only one DODAG and therefore one DODAG Root.  Local
   DODAGs can be constructed on-demand.
JP> Need =
to add the notion of local and global DAG to the terminology =
section.






Winter, et al.          Expires December 30, 2010              [Page 14]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


3.3.6.  Administrative Preference

   An implementation/deployment may specify that some DODAG roots should
   be used over others through an administrative preference.
   Administrative preference offers a way to control traffic and
   engineer DODAG formation in order to better support application
   requirements or needs.

3.3.7.  Datapath Validation and Loop Detection

   RPL uses a hop-by-hop IPv6 header to detect possible loops within a
   DODAG.  Each data packet includes the Rank of the transmitter.  An
   inconsistency between the routing decision for a packet (upward or
   downward) and the Rank relationship between the two nodes indicates a
   possible loop.  On receiving such a packet, a node institutes a local
   repair operation.
JP> Add: =
"For example if a node receives a packet flagged as moving in =
the
UP direction and should send it to a node with a higher rank =
according to its
routing table, then it can conclude of a =
DODAG inconsistencies."
3.3.8.  =
Distributed Algorithm Operation

   A high level overview of the distributed algorithm, which constructs
   the DODAG, is as follows:

   o  Some nodes are configured to be DODAG roots, with associated DODAG
      configurations.

   o  Nodes advertise their presence, affiliation with a DODAG, routing
      cost, and related metrics by sending link-local multicast DIO
      messages.

   o  Nodes listen for DIOs and use their information to join a new
      DODAG, or to maintain an existing DODAG, as according to the
      specified Objective Function and Rank of their neighbors.

   o  Nodes provision routing table entries, for the destinations
      specified by the DIO, via their DODAG parents in the DODAG
      version.  Nodes MUST provision a DODAG parent as a default route
      for the associated instance.  
JP> Add =
"if it decides to join a DODAG"
It is up to the =
end-to-end
      application to select the RPL instance to be associated to its
      traffic (should there be more than one instance) and thus the
      default route upwards when no longer-match exists.

3.4.  Downward Routes and Destination Advertisement

   RPL uses Destination Advertisement Object (DAO) messages to establish
   downward routes from DODAG roots.  
JP> Not =
just from DODAG roots ... 
DAO messages =
are an optional
   feature for applications that require P2MP or P2P traffic.  RPL
   supports two modes of downward traffic: storing (fully stateful) or
   non-storing (fully source routed).  Any given RPL Instance is either



Winter, et al.          Expires December 30, 2010              [Page 15]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   storing or non-storing.  In both cases, P2P packets travel up to a
   DODAG Root 
JP> Or a =
common ancestor in the case of storing =
nodes
then down to the final destination =
(unless the destination
   is on the upward route).
JP> with =
regards to the last sentence, indicate that this is with the =
default
mode of RPL specified in this =
specification.


3.5.  Local DODAGs Route Discovery

   A RPL network can optionally support on-demand discovery of DODAGs to
   specific destinations within an LLN.  Such local DODAGs behave
   slightly differently than global DODAGs.

3.6.  Routing Metrics and Constraints Used By RPL

   Routing metrics are used by routing protocols to compute shortest
   paths.  Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120])
   and OSPF ([RFC4915]) use static link metrics.  Such link metrics can
   simply reflect the bandwidth or can also be computed according to a
   polynomial function of several metrics defining different link
   characteristics.  Some routing protocols support more than one
   metric: in the vast majority of the cases, one metric is used per
   (sub)topology.  Less often, a second metric may be used as a tie-
   breaker in the presence of Equal Cost Multiple Paths (ECMP).  The
   optimization of multiple metrics is known as an NP complete problem
   and is sometimes supported by some centralized path computation
   engine.

   In contrast, LLNs do require the support of both static and dynamic
   metrics.  Furthermore, both link and node metrics are required.  In
   the case of RPL, it is virtually impossible to define one metric, or
   even a composite metric, that will satisfy all use cases.

   In addition, RPL supports constrained-based routing where constraints
   may be applied to both link and nodes.  If a link or a node does not
   satisfy a required constraint, it is 'pruned' from the candidate
   list, thus leading to a constrained shortest path.

   An Objective Function specifies the objectives used to compute the
   (constrained) path.  
JP> Add: =
"Furthermore nodes are configured to support a set of =
metrics
and constraint and select their parents =
in the DODAG according to the
metrics and constraints advertised in =
the DIO messages".
Upstream and =
Downstream metrics may be merged or
   advertised separately depending on the OF and the metrics.  When they
   are advertised separately, it may happen that the set of DIO parents
   is different from the set of DAO parents (a DAO parent is a node to
   which unicast DAO messages are sent).  Yet, all are DODAG parents
   with regards to the rules for Rank computation.

   The Objective Function itself is decoupled from the routing metrics
   and constraints used by RPL.  Indeed, whereas the OF dictates rules
   such as DODAG parents selection, load balancing and so on, the set of
   metrics and/or constraints used to select a DODAG parent and thus
   determine the preferred path are based on the information carried



Winter, et al.          Expires December 30, 2010              [Page 16]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   within the DAG container option in DIO messages.

   The set of supported link/node constraints and metrics is specified
   in [I-D.ietf-roll-routing-metrics].

   Example 1: Shortest path: path offering the shortest end-to-end delay

   Example 2: Constrained shortest path: the path that does not traverse
              any battery-operated node and that optimizes the path
              reliability

3.6.1.  Loop Avoidance

   RPL guarantees neither loop free path selection nor tight delay
   convergence times.  In order to reduce control overhead, however,
   such as the cost of the count-to-infinity problem, RPL avoids
   creating loops when undergoing topology changes.  Furthermore, RPL
   includes rank-based datapath validation mechanisms for detecting
   loops when they do occur.
JP> Add =
"see Section 10 for more details"
  RPL uses this =
loop detection to ensure
   that packets make forward progress within the DODAG version and
   trigger repairs when necessary.

3.6.1.1.  Greediness and Rank-based Instabilities

   A node is greedy if it attempts to move deeper in the DODAG version,
   in order to increase the size of the parent set or improve some other
   metric.  Moving deeper in within a DODAG version in this manner could
   result in instability and be detrimental to other nodes.

   Once a node has joined a DODAG version, RPL disallows certain
   behaviors, including greediness, in order to prevent resulting
   instabilities in the DODAG version.

   Suppose a node is willing to receive and process a DIO messages from
   a node in its own sub-DODAG, and in general a node deeper than
   itself.  In this case, a possibility exists that a feedback loop is
   created, wherein two or more nodes continue to try and move in the
   DODAG version while attempting to optimize against each other.  In
   some cases, this will result in instability.  It is for this reason
   that RPL limits the cases where a node may process DIO messages from
   deeper nodes to some forms of local repair.  This approach creates an
   'event horizon', whereby a node cannot be influenced beyond some
   limit into an instability by the action of nodes that may be in its
   own sub-DODAG.
JP> Tim, we had a simple example =
illustrating this. I would suggest to add it =
back.








Winter, et al.          Expires December 30, 2010              [Page 17]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


3.6.1.2.  DODAG Loops

   A DODAG loop may occur when a node detaches from the DODAG and
   reattaches to a device in its prior sub-DODAG.  This may happen in
   particular when DIO messages are missed.  Strict use of the DODAG
   Version Number can eliminate this type of loop, but this type of loop
   may possibly be encountered when using some local repair mechanisms.

JP> Add a short example, illustrating =
this.
3.6.1.3.  DAO Loops

   A DAO loop may occur when the parent has a route installed upon
   receiving and processing a DAO message from a child, but the child
   has subsequently cleaned up the related DAO state.  This loop happens
   when a No-Path (a DAO message that invalidates a previously announced
   prefix) was missed and persists until all state has been cleaned up.
   RPL includes an optional mechanism to acknowledge DAO messages, which
   may mitigate the impact of a single DAO message being missed.  RPL
   includes loop detection mechanisms that may mitigate the impact of
   DAO loops and trigger their repair.

3.6.2.  Rank Properties

   The rank of a node is a scalar representation of the location of that
   node within a DODAG version.  The rank is used to avoid and detect
   loops, and as such must demonstrate certain properties.  The exact
   calculation of the rank is left to the Objective Function, and may
   depend on parents, link 
JP> =
s/link/link or node
metrics, and =
the node configuration and
   policies.

   The rank is not a cost metric, 
JP> s/cost =
metric/path cost
although its value can be derived =
from
   and influenced by metrics.  The rank has properties of its own that
   are not necessarily those of all metrics:

   Type:   The rank is an abstract numeric value.

   Function:  The rank is the expression of a relative position within a
           DODAG version with regard to neighbors and is not necessarily
           a good indication or a proper expression of a distance or a
           cost to the root.
JP> s/cost =
to the rout/path cost to the root


   Stability:  The stability of the rank determines the stability of the
           routing topology.  Some dampening or filtering might =
be
JP> s/might be/is RECOMMENDED

           applied to keep the topology stable, and thus the rank does
           not necessarily change as fast as some physical =
metrics
JP> s/physical metrics/link/node =
metrics

           would.  A new DODAG version would be a good opportunity to
           reconcile the discrepancies that might form over time between
           metrics and ranks within a DODAG version.




Winter, et al.          Expires December 30, 2010              [Page 18]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Properties:  The rank is strictly monotonic, and can be used to
           validate a progression from or towards the root.  A metric,
           like bandwidth or jitter, does not necessarily exhibit this
           property.

   Abstract:  The rank does not have a physical unit, but rather a range
           of increment per hop, where the assignment of each increment
           is to be determined by the Objective Function.

   The rank value feeds into DODAG parent selection, according to the
   RPL loop-avoidance strategy.  Once a parent has been added, and a
   rank value for the node within the DODAG has been advertised, the
   nodes further options with regard to DODAG parent selection and
   movement within the DODAG are restricted in favor of loop avoidance.

3.6.2.1.  Rank Comparison (DAGRank())

   Rank may be thought of as a fixed point number, where the position of
   the radix point between the integer part and the fractional part is
   determined by MinHopRankIncrease.  MinHopRankIncrease is the minimum
   increase in rank between a node and any of its DODAG parents.  When
   an objective function computes rank, the objective function operates
   on the entire (i.e. 16-bit) rank quantity.  When rank is compared,
   e.g. for determination of parent relationships or loop detection, the
   integer portion of the rank is to be used.  The integer portion of
   the Rank is computed by the DAGRank() macro as follows, where
   floor(x) is the function that evaluates to the greatest integer less
   than or equal to x:


              DAGRank(rank) =3D floor(rank/MinHopRankIncrease)


JP> An short example will help the =
reader
   MinHopRankIncrease is =
provisioned at the DODAG Root and propagated in
   the DIO message.  The default value of MinHopRankIncrease is
   DEFAULT_MIN_HOP_RANK_INCREASE.  For efficient implementation the
   MinHopRankIncrease MUST be a power of 2.  An implementation may
   configure a value MinHopRankIncrease as appropriate to balance
   between the loop avoidance logic of RPL (i.e. selection of eligible
   parents) and the metrics in use.  
JP> =
Previous sentence requires additional =
information.
A further effect of
   MinHopRankIncrease is to impact the number increments that are
   allowed before INFINITE_RANK is reached, i.e. to control how long it
   may take to count-to-infinity.

   By convention in this document, using the macro DAGRank(node) may be
   interpreted as DAGRank(node.rank), where node.rank is the rank value
   as maintained by the node.




Winter, et al.          Expires December 30, 2010              [Page 19]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   A node A has a rank less than the rank of a node B if DAGRank(A) is
   less than DAGRank(B).

   A node A has a rank equal to the rank of a node B if DAGRank(A) is
   equal to DAGRank(B).

   A node A has a rank greater than the rank of a node B if DAGRank(A)
   is greater than DAGRank(B).

3.6.2.2.  Rank Relationships

   The computation of the rank MUST be done in such a way so as to
   maintain the following properties for any nodes M and N that are
   neighbors in the LLN:

   DAGRank(M) is less than DAGRank(N):  In this case, the position of M
           is closer to the DODAG root than the position of N. Node M
           may safely be a DODAG parent for Node N without risk of
           creating a loop.  Further, for a node N, all parents in the
           DODAG parent set must be of rank less than DAGRank(N).  In
           other words, the rank presented by a node N MUST be greater
           than that presented by any of its parents.

   DAGRank(M) equals DAGRank(N):  In this case the positions of M and N
           within the DODAG and with respect to the DODAG root are
           similar (identical).  In some cases, Node M may be used as a
           successor by Node N, which however entails the chance of
           creating a loop (which must be detected and resolved by some
           other means).

   DAGRank(M) is greater than DAGRank(N):  In this case, the position of
           M is farther from the DODAG root than the position of N.
           Further, Node M may in fact be in the sub-DODAG of Node N. If
           node N selects node M as DODAG parent there is a risk to
           create a loop.

   As an example, the rank could be computed in such a way so as to
   closely track ETX (Expected Transmission Count, a fairly common
   routing metric used in LLN and defined in
   [I-D.ietf-roll-routing-metrics]) when the objective function is to
   minimize ETX, or latency when the objective function is to minimize
   latency, or in a more complicated way as appropriate to the objective
   function being used within the DODAG.

3.7.  Traffic Flows Supported by RPL

   RPL supports three basic traffic flows: Multipoint-to-Point (MP2P),
   Point-to-Multipoint (P2MP), and Point-to-Point (P2P).



Winter, et al.          Expires December 30, 2010              [Page 20]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


3.7.1.  Multipoint-to-Point Traffic

   Multipoint-to-Point (MP2P) is a dominant traffic flow in many LLN
   applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]).  The
   destinations of MP2P flows are designated nodes that have some
   application significance, such as providing connectivity to the
   larger Internet or core private IP network.  RPL supports MP2P
   traffic by allowing MP2P destinations to be reached via DODAG roots.

3.7.2.  Point-to-Multipoint Traffic

   Point-to-multipoint (P2MP) is a traffic pattern required by several
   LLN applications ([RFC5867], [RFC5826], [RFC5673], [RFC5548]).  RPL
   supports P2MP traffic by using a destination advertisement mechanism
   that provisions routes 
JP> Use =
the term "down route" to be consistent with rest of the =
document.
toward destinations (prefixes, =
addresses, or
   multicast groups), and away from roots.  Destination advertisements
   can update routing tables as the underlying DODAG topology changes.

3.7.3.  Point-to-Point Traffic

   RPL DODAGs provide a basic structure for point-to-point (P2P)
   traffic.  For a RPL network to support P2P traffic, a root must be
   able to route packets to a destination.  Nodes within the network may
   also have routing tables to destinations.  A packet flows towards a
   root until it reaches an ancestor that has a known route to the
   destination.  As pointed out later in this document, in the most
   constrained case (when nodes cannot store routes), that common
   ancestor may be the DODAG root.  In other cases it may be a node
   closer to both the source and destination.

   RPL also supports the case where a P2P destination is a 'one-hop'
   neighbor.

   RPL neither specifies nor precludes additional mechanisms for
   computing and installing potentially more optimal routes to support
   arbitrary P2P traffic.















Winter, et al.          Expires December 30, 2010              [Page 21]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


4.  RPL Instance

   Within a given LLN, there may be multiple, logically independent RPL
   instances.  A RPL node may belong to multiple RPL instances, and may
   act as a router in some and as a leaf in others.  This document
   describes how a single instance behaves.

   There are two types of RPL Instances: local and global.  Local RPL
   Instances are always a single DODAG whose singular root owns the
   corresponding DODAGID.  Local RPL Instances can be used for
   constructing DODAGs that may be used by future on-demand routing
   solutions that are outside of the scope of this document.  Global RPL
   Instances have one or more DODAGs and are typically long-lived.  RPL
   divides the RPLInstanceID space between global and local instances to
   allow for both coordinated and unilateral allocation of
   RPLInstanceIDs.

   The definition and provisioning of RPL instances are beyond the scope
   of this specification.  Those operations are expected to be such that
   data packets coming from the outside of the RPL network can
   unambiguously be associated to at least one RPL instance, and be
   safely routed over any instance that would match the packet.
   Information used to match a packet to a RPL instance can typically be
   taken from fields in the IPv6 header, like the flow label, TOS =
bits,
JP> Use the term DS Bytes (IPv6) instead of TOS =
bits
   or destination address.

   Control and data packets within RPL network are tagged to
   unambiguously identify what RPL Instance they are part of.

   Every RPL control message has a RPLInstanceID field.  Some RPL
   control messages, when referring to a local RPLInstanceID as defined
   below, may also include a DODAGID.

   For data packets, the RPLInstanceID may be indicated in the flow
   label by the source of the packet.  If it is not, then it is inferred
   and added by the RPL network ingress router in the RPL Hop-by-hop
   option ([I-D.hui-6man-rpl-option]) as further described in
   Section 10.2
JP> Both "6man" IDs listed here have =
been accepted as WG doc. Will be resubmitted
as such on =
July 26


4.1.  RPL Instance ID

   A global RPLInstanceID MUST be unique to the whole LLN.  Mechanisms
   for allocating and provisioning global RPLInstanceID are out of scope
   for this document.  There can be up to 128 global instance in the
   whole network, and up 64 local instances per DODAGID.

JP> Since I heard the comment several times, need to =
clarify what "local
instance per DODAGID =
means"

   A global RPLinstanceID is encoded in a RPLinstanceID field as
   follows:



Winter, et al.          Expires December 30, 2010              [Page 22]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |0|     ID      |  Global RPLinstanceID in 0..127
       +-+-+-+-+-+-+-+-+


        Figure 3: RPL Instance ID field format for global instances

   A local RPLInstanceID is autoconfigured by the node that owns the
   DODAGID and it MUST be unique for that DODAGID.  In that case, the
   DODAGID MUST be a valid address 
JP> =
s/valid address/reachable IPv6 =
address
of the root that is used as an
   endpoint of all communications within that instance.

   A local RPLinstanceID is encoded in a RPLinstanceID field as follows:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |1|D|   ID      |  Local RPLInstanceID in 0..63
       +-+-+-+-+-+-+-+-+

        Figure 4: RPL Instance ID field format for local instances

   The D flag in a Local RPLInstanceID is always set to 0 in RPL control
   messages.  It is used in data packets to indicate whether the DODAGID
   is the source or the destination of the packet.  
JP> Requires more =
explanations
If the D flag is set
   to 1 then the destination address of the IPv6 packet MUST be the
   DODAGID.  If the D flag is clear then the source address of the IPv6
   packet MUST be the DODAGID.























Winter, et al.          Expires December 30, 2010              [Page 23]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


5.  ICMPv6 RPL Control Message

   This document defines the RPL Control Message, a new ICMPv6 message.
   A RPL Control Message is identified by a code, and composed of a base
   that depends on the code, and a series of options.

   A RPL Control Message has the scope of a link.  The source address is
   a link local address.  The destination address is either the RPL
   routers multicast address or a link local address.  
JP> just a placeholder: we need somewhere to indicate when =
to use a link local
or RPL routers multicast =
address.
The RPL routers
   multicast address is a new address with a requested value of
   FF02::1:A (to be confirmed by IANA).

   In accordance with [RFC4443], the RPL Control Message consists of an
   ICMPv6 header followed by a message body.  The message body is
   comprised of a message base and possibly a number of options as
   illustrated in Figure 5.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                             Base                              .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                           Option(s)                           .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 5: RPL Control Message

   The RPL Control message is an ICMPv6 information message with a
   requested Type of 155 (to be confirmed by IANA).

   The Code field identifies the type of RPL Control Message.  This
   document defines codes for the following RPL Control Message types
   (all codes are to be confirmed by the IANA Section 18.2):

   o  0x00: DODAG Information Solicitation (Section 5.2)

   o  0x01: DODAG Information Object (Section 5.3)

   o  0x02: Destination Advertisement Object (Section 5.4)





Winter, et al.          Expires December 30, 2010              [Page 24]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  0x03: Destination Advertisement Object Acknowledgment
      (Section 5.5)

   o  0x80: Secure DODAG Information Solicitation (Section 5.2.2)

   o  0x81: Secure DODAG Information Object (Section 5.3.2)

   o  0x82: Secure Destination Advertisement Object (Section 5.4.2)

   o  0x83: Secure Destination Advertisement Object Acknowledgment
      (Section 5.5.2)

   o  0x8A: Consistency Check (Section 5.6)

   The high order bit (0x80) of the code denotes whether the RPL message
   has security enabled.  Secure RPL messages have a format to support
   confidentiality and integrity, illustrated in Figure 6.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                           Security                            .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                             Base                              .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                           Option(s)                           .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6: Secure RPL Control Message

   The remainder of this section describes the currently defined RPL
   Control Message Base formats followed by the currently defined RPL
   Control Message Options.

5.1.  RPL Security Fields

   Each RPL message has a secure version.  The secure versions provide
   integrity and replay protection as well as optional confidentiality
   and delay protection.  Because security covers the base message as



Winter, et al.          Expires December 30, 2010              [Page 25]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   well as options, in secured messages the security information lies
   between the checksum and base, as shown in Figure Figure 6.

   The format of the security section is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |C|T| Rsrvd |Sec|KIM|Rsrvd| LVL |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                            Counter                            |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                  Message Authentication Code                  .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                        Key Identifier                         .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 7: Security Section
JP>s/Security Section/Security =
Header


   All fields are considered as packet payload from a security
   processing perspective.  The exact placement and format of message
   integrity/authentication codes has not yet been determined.

JP> It is.
   Use of the =
Security section 
JP> want =
to replace "Security section" by Security header" =
everywhere?
is further detailed in Section 17.

   Security Control Field:  The Security Control Field has one flag and
         three fields:

         Counter Compression (C):  If the Counter Compression flag is
               set then the Counter field is compressed from 4 bytes
               into 1 byte.  If the Counter Compression flag is =
clear
JP>s/clear/cleared

               then the Counter field is 4 bytes and uncompressed.

         Counter is Time (T):  If the Counter is Time flag is set then
               the Counter field is a timestamp.  If the flag is cleared
               then the Counter is an incrementing counter.  Section 9.4
               describes the details of the 'T' flag and Counter field.







Winter, et al.          Expires December 30, 2010              [Page 26]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


         Security Mode (Sec):  The security algorithm field specifies
               what security mode and algorithms the network uses.
               Supported values of this field are as follows:


                         +----+-----+-------------------+
                         | ID | Sec |     Algorithm     |
                         +----+-----+-------------------+
                         |  0 |  00 | CCM* with AES-128 |
                         |  1 |  01 |      Reserved     |
                         |  2 |  10 |      Reserved     |
                         |  3 |  11 |      Reserved     |
                         +----+-----+-------------------+

                           Security Mode (Sec) Encoding

JP> Need a Table number


         Key Identifier Mode (KIM):  The Key Identifier Mode field
               indicates whether the key used for packet protection is
               determined implicitly or explicitly and indicates the
               particular representation of the Key Identifier field.
               The Key Identifier Mode is set 
JP> s/set/set to
one of the =
non-reserved
               values from the table below:




























Winter, et al.          Expires December 30, 2010              [Page 27]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


          +------+-----+-----------------------------+------------+
          | Mode | KIM |           Meaning           |    Key     |
          |      |     |                             | Identifier |
          |      |     |                             |   Length   |
          |      |     |                             |  (octets)  |
          +------+-----+-----------------------------+------------+
          |  0   | 00  | Group key used.             |     1      |
          |      |     | Key determined by Key Index |            |
          |      |     | field.                      |            |
          |      |     |                             |            |
          |      |     | Key Source is not present.  |            |
          |      |     | Key Index is present.       |            |
          +------+-----+-----------------------------+------------+
          |  1   | 01  | Per-pair key used.          |     0      |
          |      |     | Key determined by source    |            |
          |      |     | and destination of packet.  |            |
          |      |     |                             |            |
          |      |     | Key Source is not present.  |            |
          |      |     | Key Index is not present.   |            |
          +------+-----+-----------------------------+------------+
          |  2   | 10  | Group key used.             |     9      |
          |      |     | Key determined by Key Index |            |
          |      |     | and Key Source Identifier.  |            |
          |      |     |                             |            |
          |      |     | Key Source is present.      |            |
          |      |     | Key Index is present.       |            |
          +------+-----+-----------------------------+------------+
          |  3   | 11  | Node's signature key used.  |    0/9     |
          |      |     | If packet is encrypted,     |
          |      |     | group key used. Group key   |            |
          |      |     | determined by Key Index and |            |
          |      |     | Key Source Identifier.      |            |
          |      |     |                             |            |
          |      |     | Key Source may be present.  |            |
          |      |     | Key Index may be present.   |            |
          +------+-----+-----------------------------+------------+


                          Key Identifier Mode (KIM) Encoding

JP> Need a table number


         Security Level (LVL):  The Security Level field indicates the
               provided packet protection.  This value can be adapted on
               a per-packet basis and allows for varying levels of data
               authenticity and, optionally, for data confidentiality.
               The KIM field indicates whether signatures are used.  The
               Security Level is set to one of the non-reserved values
               in the table below:



Winter, et al.          Expires December 30, 2010              [Page 28]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


                     +---------------------------+--------------------+
                     |      Without Signatures   |   With Signatures  |
          +----+-----+--------------------+------+--------------+-----+
          | ID | LVL |     Attributes     | Auth |  Attributes  | Sig |
          |    |     |                    | Len  |              | Len |
          +----+-----+--------------------+------+--------------+-----+
          |  0 | 000 |      Reserved      | N/A  |   Reserved   | N/A |
          |  1 | 001 |       MAC-32       |  4   |    Sign-32   | 40  |
          |  2 | 010 |       MAC-64       |  8   |    Sign-64   | 44  |
          |  3 | 011 |      Reserved      | N/A  |   Sign-128   | 52  |
          |  4 | 100 |      Reserved      | N/A  |   Reserved   | N/A |
          |  5 | 101 |     ENC-MAC-32     |  4   |  ENC-Sign-32 | 40  |
          |  6 | 110 |     ENC-MAC-64     |  8   |  ENC-Sign-64 | 44  |
          |  7 | 111 |      Reserved      | N/A  | ENC-Sign-128 | 52  |
          +----+-----+--------------------+------+-------------+------+

                         Security Level (LVL) Encoding

JP> Need a table number


   Counter:  The Counter field indicates the non-repeating value (nonce)
         used with the cryptographic mechanism that implements packet
         protection and allows for the provision of semantic security.
         This value is compressed from 4 octets to 1 octet if the
         Counter Compression field of the Security Control Field is set
         to one.

   Message Authentication Code:  The Message Authentication Code field
         contains a cryptographic MAC.  The length of the MAC is defined
         by a combination of the LVL and Sec fields: it can be 0, 4, or
         8 octets long.  In the case of Security Modes where the MAC is
         computed as part of the ciphertext (as in Security Mode 0,
         CCM*), the MAC field is zero bytes long.

   Key Identifier:  The Key Identifier field indicates which key was
         used to protect the packet.  This field provides various levels
         of granularity of packet protection, including peer-to-peer
         keys, group keys, and signature keys.  This field is
         represented as indicated by the Key Identifier Mode field and
         is formatted as follows:












Winter, et al.          Expires December 30, 2010              [Page 29]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                          Key Source                           .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                           Key Index                           .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                            Figure 8: Key Identifier

         Key Source:  The Key Source field, when present, indicates the
               logical identifier of the originator of a group key.
               When present this field is 8 bytes in length.

         Key Index:  The Key Index field, when present, allows unique
               identification of different keys with the same
               originator.  It is the responsibility of each key
               originator to make sure that actively used keys that it
               issues have distinct key indices and that all key indices
               have a value unequal to 0x00.  Value 0x00 is reserved for
               a pre-installed, shared key.  When present this field is
               1 byte in length.

   Unassigned bits of the Security section are reserved.  They MUST be
   set to zero on transmission and MUST be ignored on reception.

5.2.  DODAG Information Solicitation (DIS)

   The DODAG Information Solicitation (DIS) message may be used to
   solicit a DODAG Information Object from a RPL node.  Its use is
   analogous to that of a Router Solicitation as specified in IPv6
   Neighbor Discovery; a node may use DIS to probe its neighborhood for
   nearby DODAGs.  Section 7.3 describes how nodes respond to a DIS.

5.2.1.  Format of the DIS Base Object


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reserved            |   Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Winter, et al.          Expires December 30, 2010              [Page 30]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


                       Figure 9: The DIS Base Object

   Unassigned bits of the DIS Base are reserved.  They MUST be set to
   zero on transmission and MUST be ignored on reception.

5.2.2.  Secure DIS

   A Secure DIS message follows the format in Figure Figure 6, where the
   base format is the DIS message shown in Figure Figure 9.
JP> Typo: duplicates =
"Figure"
5.2.3.  DIS Options

   The DIS message MAY carry valid options.

   This specification allows for the DIS message to carry the following
   options:
      0x00 Pad1
      0x01 PadN
      0x07 Solicited Information

5.3.  DODAG Information Object (DIO)

   The DODAG Information Object carries information that allows a node
   to discover a RPL Instance, learn its configuration parameters,
   select a DODAG parent set, and maintain the upward routing =
topology.
JP> I'd rather say "maintain DODAG" =
(upward routing topology may be misleading).


5.3.1.  Format of the DIO Base Object


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |    Version    |             Rank              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |G|0| MOP | Prf |     DTSN      |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID                            +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Option(s)...
       +-+-+-+-+-+-+-+-+

                      Figure 10: The DIO Base Object



Winter, et al.          Expires December 30, 2010              [Page 31]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Control Field:  The DAG Control Field has three flags and two fields:

         Grounded (G):  The Grounded (G) flag indicates whether the
               DODAG advertised can satisfy the application-defined
               goal.  If the flag is set, the DODAG is grounded.  If the
               flag is cleared, the DODAG is floating.

         Mode of Operation (MOP):  The Mode of Operation (MOP) field
               identifies the mode of operation of the RPL Instance as
               administratively provisioned at and distributed by the
               DODAG Root.  All nodes who join the DODAG must be able to
               honor the MOP in order to fully participate as a router,
               or else they must only join as a leaf.  MOP is encoded as
               in the table below:


               +-----+-------------------------------------------------+
               | MOP | Meaning                                         |
               +-----+-------------------------------------------------+
               | 000 | No downward routes maintained by RPL            |
               | 001 | Non storing mode                                |
               | 010 | Storing without multicast support               |
               | 011 | Storing with multicast support                  |
               |     |                                                 |
               |     | All other values are reserved                   |
               +-----+-------------------------------------------------+

               A value of 000 indicates that destination advertisement
               messages are disabled and the DODAG maintains only upward
               routes

                           Mode of Operation (MOP) Encoding
JP> indicate that similarly to the supported set of OF, =
metrics, ... if a node does not comply
with the =
advertised MOP it can join as a leaf node.


         DODAGPreference (Prf):  A 3-bit unsigned integer that defines
               how preferable the root of this DODAG is compared to
               other DODAG roots within the instance.  DAGPreference
               ranges from 0x00 (least preferred) to 0x07 (most
               preferred).  The default is 0 (least preferred).
               Section 7.2 describes how DAGPreference affects DIO
               processing.

   Version Number:  8-bit unsigned integer set by the DODAG root.
         Section 7.2 describes the rules for version numbers and how
         they affect DIO processing.







Winter, et al.          Expires December 30, 2010              [Page 32]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Rank: 16-bit unsigned integer indicating the DODAG rank of the node
         sending the DIO message.  Section 7.2 describes how Rank is set
         and how it affects DIO processing.

   RPLInstanceID:  8-bit field set by the DODAG root that indicates
         which RPL Instance the DODAG is part of.

   Destination Advertisement Trigger Sequence Number (DTSN):  8-bit
         unsigned integer set by the node issuing the DIO message.  The
         Destination Advertisement Trigger Sequence Number (DTSN) flag
         is used as part of the procedure to maintain downward routes.
         The details of this process are described in Section 8.

   DODAGID:  128-bit unsigned integer set by a DODAG root which uniquely
         identifies a DODAG.  Possibly derived from the IPv6 address of
         the DODAG root.
JP> has to be a reachable IPv6 =
address in some cases (non storing with DAO, ...)


   Unassigned bits of the DIO Base are reserved.  They MUST be set to
   zero on transmission and MUST be ignored on reception.

5.3.2.  Secure DIO

   A Secure DIO message follows the format in Figure Figure 6, where the
   base format is the DIS message shown in Figure Figure 10.

5.3.3.  DIO Options

   The DIO message MAY carry valid options.

   This specification allows for the DIO message to carry the following
   options:
      0x00 Pad1
      0x01 PadN
      0x02 Metric Container
      0x03 Routing Information
      0x04 DODAG Configuration
      0x08 Prefix Information

5.4.  Destination Advertisement Object (DAO)

   The Destination Advertisement Object (DAO) is used to propagate
   destination information upwards along the DODAG.  The DAO message is
   unicast by the child to the selected parent(s).  The DAO message may
   optionally, upon explicit request or error, be acknowledged by the
   parent with a Destination Advertisement Acknowledgement (DAO-ACK)
   message back to the child.





Winter, et al.          Expires December 30, 2010              [Page 33]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


5.4.1.  Format of the DAO Base Object


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |K|D|         Reserved          | DAOSequence   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID*                           +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Option(s)...
       +-+-+-+-+-+-+-+-+

                      Figure 11: The DAO Base Object

JP> Indicate that the * in the Figure 11 (after DODAG) =
means "not always present"

   RPLInstanceID:  8-bit field indicating the topology instance
         associated with the DODAG, as learned from the DIO.

   K:    The 'K' flag indicates that the parent is expected to send a
         DAO-ACK back.
JP> =
Placeholder: we need to explain what a child does if it does not receive =
a reply
to a DAO with K set (e.g. try a limited =
number of retries and then stop, detach =
).
   D:    The 'D' flag indicates that the =
DODAGID field is present.  This
         flag MUST be set when a local RPLInstanceID is used.

   DAOSequence:  Incremented at each unique DAO message, echoed in the
         DAO-ACK message.

   DODAGID (optional):  128-bit unsigned integer set by a DODAG root
         which uniquely identifies a DODAG.  This field is only present
         when the 'D' flag is set.  This field is typically only present
         when a local RPLInstanceID is in use, in order to identify the
         DODAGID that is associated with the RPLInstanceID.  When a
         global RPLInstanceID is in use this field need not be present.

JP> The refers to a previous comment about the local =
instance. By regrouping the pieces 
together, the =
reader can understand how this works, but we should have a section with =
an
example describing the mode of operation of local DODAG. =
That's missing.
   Unassigned bits of the DAO Base =
are reserved.  They MUST be set to
   zero on transmission and MUST be ignored on reception.

5.4.2.  Secure DAO

   A Secure DAO message follows the format in Figure Figure 6, where the
   base format is the DAO message shown in Figure Figure 11.




Winter, et al.          Expires December 30, 2010              [Page 34]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


5.4.3.  DAO Options

   The DAO message MAY carry valid options.

   This specification allows for the DAO message to carry the following
   options:
      0x00 Pad1
      0x01 PadN
      0x05 RPL Target
      0x06 Transit Information

   A special case of the DAO message, termed a No-Path, is used to clear
   downward routing state that has been provisioned through DAO
   operation.  The No-Path carries a RPL Transit Information option,
   which identifies the destination to which the DAO is associated, with
   a lifetime of 0x00000000 to indicate a loss of reachability.

5.5.  Destination Advertisement Object Acknowledgement (DAO-ACK)

   The DAO-ACK message is sent as a unicast packet by a DAO parent in
   response to a unicast DAO message from a child.

5.5.1.  Format of the DAO-ACK Base Object


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |D|  Reserved   | DAOSequence   |   Status      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID*                           +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Option(s)...
       +-+-+-+-+-+-+-+-+

                    Figure 12: The DAO ACK Base Object

   RPLInstanceID:  8-bit field indicating the topology instance
         associated with the DODAG, as learned from the DIO.






Winter, et al.          Expires December 30, 2010              [Page 35]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   D:    The 'D' flag indicates that the DODAGID field is present.  This
         would typically only be set when a local RPLInstanceID is used.

   DAOSequence:  Incremented at each DAO message from a given child,
         echoed in the DAO-ACK by the parent.  The DAOSequence serves in
         the parent-child communication and is not to be confused with
         the Transit Information option Sequence that is associated to a
         given target down the DODAG.

   Status:  Indicates the completion. 0 is unqualified acceptance, above
         128 are rejection code indicating that the node should select
         an alternate parent.
JP> In =
between values are undetermined
   DODAGID =
(optional):  128-bit unsigned integer set by a DODAG root
         which uniquely identifies a DODAG.  This field is only present
         when the 'D' flag is set.  This field is typically only present
         when a local RPLInstanceID is in use, in order to identify the
         DODAGID that is associated with the RPLInstanceID.  When a
         global RPLInstanceID is in use this field need not be present.

   Unassigned bits of the DAO-ACK Base are reserved.  They MUST be set
   to zero on transmission and MUST be ignored on reception.

5.5.2.  Secure DAO-ACK

   A Secure DAO-ACK message follows the format in Figure Figure 6, where
   the base format is the DAO-ACK message shown in Figure Figure 12.

5.5.3.  DAO-ACK Options

   This specification does not define any options to be carried by the
   DAO-ACK message.

5.6.  Consistency Check (CC)

   The CC message is used to check secure message counters and issue
   challenge/responses.  A CC message MUST be sent as a secured RPL
   message.

   A CC message (request or response) MUST NOT set the 'C' bit of the
   security section: CC messages always have full counters.

5.6.1.  Format of the CC Base Object








Winter, et al.          Expires December 30, 2010              [Page 36]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RPLInstanceID |R|    Reserved |            Nonce              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID                            +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Destination Counter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Option(s)...
       +-+-+-+-+-+-+-+-+

                       Figure 13: The CC Base Object

   RPLInstanceID:  8-bit field indicating the topology instance
         associated with the DODAG, as learned from the DIO.

   R:    The 'R' flag indicates whether the CC message is a response.  A
         message with the 'R' flag cleared is a request; a message with
         the 'R' flag set is a response.  A CC message with the R bit
         set MUST NOT compress the security Counter field: the C bit of
         the security section MUST be 0.

   Nonce:  16-bit unsigned integer set by a CC request.  The
         corresponding CC response includes the same nonce value as the
         request.

   Destination Counter:  32-bit unsigned integer value indicating the
         sender's estimate of the destination's current security Counter
         value.  If the sender does not have an estimate, it SHOULD set
         the Destination Counter field to zero.

   Unassigned bits of the CC Base are reserved.  They MUST be set to
   zero on transmission and MUST be ignored on reception.

   The Destination Counter value allows new or recovered nodes to
   resynchronize through CC message exchanges.  This is important to
   ensure that a Counter value is not repeated for a given security key
   even in the event of devices recovering from a failure that created a
   loss of Counter state.  For example, where a CC request or other RPL
   message is received with an initialized Counter within the message
   security section, the provision of the Incoming Counter within the CC



Winter, et al.          Expires December 30, 2010              [Page 37]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   response message allows the requesting node to reset its Outgoing
   Counter to a value greater than the last value received by the
   responding node; the Incoming Counter will also be updated from the
   received CC response.

5.6.2.  CC Options

   The CC message MAY carry valid options.  In the scope of this
   specification, there are no valid options for a CC message.

   This specification allows for the CC message to carry the following
   options:
      0x00 Pad1
      0x01 PadN

5.7.  RPL Control Message Options

5.7.1.  RPL Control Message Option Generic Format

   RPL Control Message Options all follow this format:

        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |  Option Type  | Option Length | Option Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                   Figure 14: RPL Option Generic Format

   Option Type:  8-bit identifier of the type of option.  The Option
         Type values are to be confirmed by the IANA Section 18.4.

   Option Length:  8-bit unsigned integer, representing the length in
         octets of the option, not including the Option Type and Length
         fields.

   Option Data:  A variable length field that contains data specific to
         the option.

   When processing a RPL message containing an option for which the
   Option Type value is not recognized by the receiver, the receiver
   MUST silently ignore the unrecognized option and continue to process
   the following option, correctly handling any remaining options in the
   message.

   RPL message options may have alignment requirements.  Following the
   convention in IPv6, options with alignment requirements are aligned
   in a packet such that multi-octet values within the Option Data field



Winter, et al.          Expires December 30, 2010              [Page 38]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   of each option fall on natural boundaries (i.e., fields of width n
   octets are placed at an integer multiple of n octets from the start
   of the header, for n =3D 1, 2, 4, or 8).

5.7.2.  Pad1

   The Pad1 option may be present in DIS, DIO, DAO, and DAO-ACK
   messages, and its format is as follows:


        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |   Type =3D 0    |
       +-+-+-+-+-+-+-+-+

                   Figure 15: Format of the Pad 1 Option

   The Pad1 option is used to insert one or two octets of padding into
   the message to enable options alignment.  If more than one octet of
   padding is required, the PadN option should be used rather than
   multiple Pad1 options.

   NOTE! the format of the Pad1 option is a special case - it has
   neither Option Length nor Option Data fields.

5.7.3.  PadN

   The PadN option may be present in DIS, DIO, DAO, and DAO-ACK
   messages, and its format is as follows:


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type =3D 1    | Option Length | 0x00 Padding...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                   Figure 16: Format of the Pad N Option

   The PadN option is used to insert two or more octets of padding into
   the message to enable options alignment.  PadN Option data MUST be
   ignored by the receiver.








Winter, et al.          Expires December 30, 2010              [Page 39]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Option Type:  0x01 (to be confirmed by IANA)

   Option Length:  For N (N > 1) octets of padding, the Option Length
         field contains the value N-2.

   Option Data:  For N (N > 1) octets of padding, the Option Data
         consists of N-2 zero-valued octets.

5.7.4.  Metric Container

   The Metric Container option may be present in DIO messages, and its
   format is as follows:

JP> s/may/MAY


        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |   Type =3D 2    | Option Length | Metric Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

             Figure 17: Format of the Metric Container Option

   The Metric Container is used to report metrics along the DODAG.  The
   Metric Container may contain a number of discrete node, link, and
   aggregate path metrics and constraints specified in
   [I-D.ietf-roll-routing-metrics] as chosen by the implementer.

   The Metric Container MAY appear more than once in the same RPL
   control message, for example to accommodate a use case where the
   Metric Data is longer than 256 bytes.  More information is in
   [I-D.ietf-roll-routing-metrics]

JP> "." missing
   The =
processing and propagation of the Metric Container is governed by
   implementation specific policy functions.

   Option Type:  0x02 (to be confirmed by IANA)

   Option Length:  The Option Length field contains the length in octets
         of the Metric Data.

   Metric Data:  The order, content, and coding of the Metric Container
         data is as specified in [I-D.ietf-roll-routing-metrics].

5.7.5.  Route Information

   The Route Information option may
JP> =
s/may/MAY
 be present in DIO messages, and is
   equivalent in function to the IPv6 ND 
JP> Expand ND: Neighbor =
Discovery
Route Information option as
   defined in [RFC4191].  The format of the option is modified slightly



Winter, et al.          Expires December 30, 2010              [Page 40]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   (Type, Length, Prefix) in order to be carried as a RPL option as
   follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 3    | Option Length | Prefix Length =
|Resvd|Prf|Resvd|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Route Lifetime                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                   Prefix (Variable Length)                    .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 18: Format of the Route Information Option

   The Route Information option is used to indicate that connectivity to
   the specified destination prefix is available from the DODAG root.

   In the event that a RPL Control Message may need to specify
   connectivity to more than one destination, the Route Information
   option may be repeated.

   [RFC4191] should be consulted as the authoritative reference with
   respect to the Route Information option.  The field descriptions are
   transcribed here for convenience:

   Option Type:  0x03 (to be confirmed by IANA)

   Option Length:  Variable, length of the option in octets excluding
         the Type and Length fields.  Note that this length is expressed
         in units of single-octets, unlike in IPv6 ND.

   Prefix Length  8-bit unsigned integer.  The number of leading bits in
         the Prefix that are valid.  The value ranges from 0 to 128.
         The Prefix field has the number of bytes inferred from the
         Option Length field, that must be at least the Prefix Length.
         Note that in RPL this means that the Prefix field may have
         lengths other than 0, 8, or 16.

   Prf:  2-bit signed integer.  The Route Preference indicates whether
         to prefer the router associated with this prefix over others,
         when multiple identical prefixes (for different routers) have
         been received.  If the Reserved (10) value is received, the
         Route Information Option MUST be ignored.


JP> Explain the use of Reserved =
Value=3D10



Winter, et al.          Expires December 30, 2010              [Page 41]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Resvd:  Two 3-bit unused fields.  They MUST be initialized to zero by
         the sender and MUST be ignored by the receiver.

   Route Lifetime  32-bit unsigned integer.  The length of time in
         seconds (relative to the time the packet is sent) that the
         prefix is valid for route determination.  A value of all one
         bits (0xffffffff) represents infinity.

   Prefix  Variable-length field containing an IP address or a prefix of
         an IP address.  The Prefix Length field contains the number of
         valid leading bits in the prefix.  The bits in the prefix after
         the prefix length (if any) are reserved and MUST be initialized
         to zero by the sender and ignored by the receiver.  Note that
         in RPL this field may have lengths other than 0, 8, or 16.

JP> need to say that Route Information can be inserted by =
any node along the DODAG.

   Unassigned bits of the Route Information option are reserved.  They
   MUST be set to zero on transmission and MUST be ignored on reception.

5.7.6.  DODAG Configuration

   The DODAG Configuration option may 
JP> =
s/may/MAY
be present in DIO messages, and
   its format is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 4    | Option Length | Resrvd|A| PCS | DIOIntDoubl.  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  DIOIntMin.   |   DIORedun.   |        MaxRankIncrease        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      MinHopRankIncrease       |              OCP              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 19: Format of the DODAG Configuration Option

   The DODAG Configuration option is used to distribute configuration
   information for DODAG Operation through the DODAG.

   The information communicated in this option is generally static and
   unchanging within the DODAG, therefore it is not necessary to include
   in every DIO.  This information is configured at the DODAG Root and
   distributed throughout the DODAG with the DODAG Configuration Option.
   Nodes other than the DODAG Root MUST NOT modify this information when
   propagating the DODAG Configuration option.  This option MAY be
   included occasionally by the DODAG Root (as determined by the DODAG
   Root), and MUST be included in response to a unicast request, e.g. a
   unicast DODAG Information Solicitation (DIS) message.



Winter, et al.          Expires December 30, 2010              [Page 42]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Option Type:  0x04 (to be confirmed by IANA)

   Option Length:  8 bytes

   Authentication Enabled (A):  One bit describing the security mode of
         the network.  The bit describe whether a node must authenticate
         with a key authority before joining the network as a router.
         If the DIO is not a secure DIO, the 'A' bit MUST be zero.

   Path Control Size (PCS):  3-bit unsigned integer used to configure
         the number of bits that may be allocated to the Path Control
         field (see Section 8.9).  Note that as used a value of 1 is
         added to this field, i.e. a PCS value of 0 results in 1 active
         bit in the Path Control field.  The default value of PCS is
         DEFAULT_PATH_CONTROL_SIZE.

   DIOIntervalDoublings:  8-bit unsigned integer used to configure Imax
         of the DIO trickle timer (see Section 7.3.1).

   DIOIntervalMin:  8-bit unsigned integer used to configure Imin of the
         DIO trickle timer (see Section 7.3.1).

   DIORedundancyConstant:  8-bit unsigned integer used to configure k of
         the DIO trickle timer (see Section 7.3.1).

JP> Add a reference to the default =
values
   MaxRankIncrease:  16-bit =
unsigned integer used to configure
         DAGMaxRankIncrease, the allowable increase in rank in support
         of local repair.  If DAGMaxRankIncrease is 0 then this
         mechanism is disabled.

   MinHopRankInc  16-bit unsigned integer used to configure
         MinHopRankIncrease as described in Section 3.6.2.1.

   Objective Code Point (OCP)  16-bit unsigned integer.  The OCP field
         identifies the OF and is managed by the IANA.

JP> s/the IANA/IANA
5.7.7.  RPL =
Target

   The RPL Target option format is as follows:


JP> ADD: "The RPL Target option MAY be present either in =
DIO or DAO messages."











Winter, et al.          Expires December 30, 2010              [Page 43]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 5    | Option Length |   Reserved    | Prefix Length =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                Target Prefix (Variable Length)                |
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 20: Format of the RPL Target Option

   The RPL Target Option is used to indicate a target IPv6 address,
   prefix, or multicast group that is reachable or queried along the
   DODAG.  In a DIO, the RPL Target Option identifies a resource that
   the root is trying to reach.  
JP> I =
would add a sentence to indicate that in DIO this for a query by =
contrast with Route information.
In a DAO, the =
RPL Target option
   indicates reachability.

   A set of one or more Transit Information options 
JP> Add "defined in Section =
5.7.8"
MAY directly follow
   the Target option in a DAO message in support of constructing source
   routes in a non-storing mode of operation
   [I-D.hui-6man-rpl-routing-header].  When the same set of Transit
   Information options apply equally to a set of DODAG Target options,
   the group of Target options MUST appear first, followed by the
   Transit Information options which apply to those Targets.

JP> Not very clear ... example =
please
   The RPL Target option may be =
repeated as necessary to indicate
   multiple targets.

   Option Type:  0x05 (to be confirmed by IANA)

   Option Length:  Variable, length of the option in octets excluding
         the Type and Length fields.

   Prefix Length:  8-bit unsigned integer.  Number of valid leading bits
         in the IPv6 Prefix.

   Target Prefix:  Variable-length field identifying an IPv6 destination
         address, prefix, or multicast group.  The Prefix Length field
         contains the number of valid leading bits in the prefix.  The
         bits in the prefix after the prefix length (if any) are
         reserved and MUST be set to zero on transmission and MUST be
         ignored on receipt.






Winter, et al.          Expires December 30, 2010              [Page 44]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


5.7.8.  Transit Information

   The Transit Information option may 
JP> =
s/may/MAY

be present in DAO messages, and
   its format is as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 6    | Option Length | Path Sequence | Path Control  =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Path Lifetime                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                        Parent Address*                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Figure 21: Format of the Transit Information option

   The Transit Information option is used for a node to indicate
   attributes for a path to one or more destinations.  The destinations
   are indicated as by one or more Target options that immediately
   precede the Transit Information option(s).

   The Transit Information option can used for a node to indicate its
   DODAG parents to an ancestor that is collecting DODAG routing
   information, typically for the purpose of constructing source routes.
   In the non-storing mode of operation this ancestor will be the DODAG
   Root, and this option is carried by the DAO message.  The option
   length is used to determine whether the Parent Address is present or
   not.
JP> Why is the Parent Address optional =
?
   A non-storing node that has more than one =
DAO parent MAY include a
   Transit Information option for each DAO parent as part of the non-
   storing Destination Advertisement 
JP> Why =
capitalized D and A ?
operation.  The =
node may code the
   Path Control field in order to signal a preference among parents.

   One or more Transit Information options MUST be preceded by one or
   more RPL Target options.  In this manner the RPL Target option
   indicates the child node, and the Transit Information option(s)
   enumerate the DODAG parents.


JP> This is the ideal place to add an example (with two DAO =
parents)



Winter, et al.          Expires December 30, 2010              [Page 45]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   A typical non-storing node will use multiple Transit Information
   options, and it will send the DAO thus formed to only one parent that
   will forward it to the root.  A typical storing node =
with 
JP> =
s/with/will
use one
   Transit Information option with no parent field, and will send the
   DAO thus formed to multiple parents.
JP> Two =
comments:
1) This is where we explain when there =
is no Parent address (again an example with
both cases =
will help the reader)
2) This may be sent to *one* parent =
too.
   Option Type:  0x06 (to be =
confirmed by IANA)

   Option Length:  Variable, depending on whether or not Parent Address
         is present.

   Path-Sequence:  8-bit unsigned integer.  When a RPL Target option is
         issued by the node that owns the Target Prefix (i.e. in a DAO
         message), that node sets the Path-Sequence and increments the
         Path-Sequence each time it issues a RPL Target option.

   Path Control:  8-bit bitfield.  The Path Control field limits the
         number of DAO-Parents to which a DAO message advertising
         connectivity to a specific destination may be sent, as well as
         providing some indication of relative preference.  The limit
         provides some bound on overall DAO fan-out in the LLN.  The
         leftmost bit is associated with a path that contains a most-
         preferred link, and the subsequent bits are ordered down to the
         rightmost bit which is least preferred.

JP> No comment here since there is already a thread on this =
(ticket #60)
   Path Lifetime:  32-bit unsigned =
integer.  The length of time in
         seconds (relative to the time the packet is sent) that the
         prefix is valid for route determination.  A value of all one
         bits (0xFFFFFFFF) represents infinity.  A value of all zero
         bits (0x00000000) indicates a loss of reachability.  This is
         referred as a No-Path in this document.

   Parent Address (optional):  IPv6 Address of the DODAG Parent of the
         node originally issuing the Transit Information Option.  This
         field may not be present, as according to the DODAG Mode of
         Operation 
JP> Add =
(storing versus non-storing mode)
and indicated =
by the Transit Information option
         length.

   Unassigned bits of the Transit Information option are reserved.  They
   MUST be set to zero on transmission and MUST be ignored on reception.

5.7.9.  Solicited Information

   The Solicited Information option may be present in DIS messages, and
   its format is as follows:






Winter, et al.          Expires December 30, 2010              [Page 46]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 7    | Option Length | RPLInstanceID |V|I|D|  Rsvd   =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            DODAGID                            +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Version    |
       +-+-+-+-+-+-+-+-+


           Figure 22: Format of the Solicited Information Option

   The Solicited Information option is used for a node to request DIO
   messages from a subset of neighboring nodes.  The Solicited
   Information option may specify a number of predicate criteria to be
   matched by a receiving node.  
JP> This =
is used to limit the number of replies from "non-interesting" node for =
the requester.

These predicates affect whether a =
node
   resets its DIO trickle timer, as described in Section 7.3

   Option Type:  0x07 (to be confirmed by IANA)

   Option Length:  19 bytes

   Control Field:  The Solicited Information option Control Field has
         three flags:

         V:    If the V flag is set then the Version field is valid and
               a node matches the predicate if its DODAGVersionNumber
               matches the requested version.  If the V flag is clear
               then the Version field is not valid and the Version field
               MUST be set to zero on transmission and ignored upon
               receipt.
JP> Why =
not just not include the Version field if =
V=3D0
         I:    If the I flag is set =
then the RPLInstanceID field is
               valid and a node matches the predicate if it matches the
               requested RPLInstanceID.  If the I flag is clear then the
               RPLInstanceID field is not valid and the RPLInstanceID
               field MUST be set to zero on transmission and ignored
               upon receipt.






Winter, et al.          Expires December 30, 2010              [Page 47]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


         D:    If the D flag is set then the DODAGID field is valid and
               a node matches the predicate if it matches the requested
               DODAGID.  If the D flag is clear 
JP>s/clear/cleared

then the =
DODAGID field
               is not valid and the DODAGID field MUST be set to zero on
               transmission and ignored upon receipt.

   Version:  8-bit unsigned integer containing the DODAG Version number
         that is being solicited when valid.

   RPLInstanceID:  8-bit unsigned integer containing the RPLInstanceID
         that is being solicited when valid.

   DODAGID:  128-bit unsigned integer containing the DODAGID that is
         being solicited when valid.

   Unassigned bits of the Solicited Information option are reserved.
   They MUST be set to zero on transmission and MUST be ignored on
   reception.

5.7.10.  Prefix Information

   The Prefix Information option may 
be present in DIO messages, and is
   equivalent in function to the IPv6 ND Prefix Information option as
   defined in [RFC4861].  The format of the option is modified slightly
   (Type, Length, Prefix) in order to be carried as a RPL option as
   follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 8    | Option Length | Prefix Length |L|A| Reserved1 =
|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Valid Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Preferred Lifetime                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Reserved2                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                            Prefix                             +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Winter, et al.          Expires December 30, 2010              [Page 48]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


            Figure 23: Format of the Prefix Information Option

   The Prefix Information option may be used to distribute the prefix in
   use inside the DODAG, e.g. for address autoconfiguration.

   [RFC4861] should be consulted as the authoritative reference with
   respect to the Prefix Information option.  The field descriptions are
   transcribed here for convenience:

   Option Type:  0x08 (to be confirmed by IANA)

   Option Length:  30.  Note that this length is expressed in units of
         single-octets, unlike in IPv6 ND.

   Prefix Length  8-bit unsigned integer.  The number of leading bits in
         the Prefix that are valid.  The value ranges from 0 to 128.
         The prefix length field provides necessary information for on-
         link determination (when combined with the L flag in the prefix
         information option).  It also assists with address
         autoconfiguration as specified in [RFC4862], for which there
         may be more restrictions on the prefix length.

   L     1-bit on-link flag.  When set, indicates that this prefix can
         be used for on-link determination.  When not set the
         advertisement makes no statement about on-link or off-link
         properties of the prefix.  In other words, if the L flag is not
         set a host MUST NOT conclude that an address derived from the
         prefix is off-link.  That is, it MUST NOT update a previous
         indication that the address is on-link.

   A     1-bit autonomous address-configuration flag.  When set
         indicates that this prefix can be used for stateless address
         configuration as specified in [RFC4862].

   Reserved1  6-bit unused field.  It MUST be initialized to zero by the
         sender and MUST be ignored by the receiver.

   Valid Lifetime  32-bit unsigned integer.  The length of time in
         seconds (relative to the time the packet is sent) that the
         prefix is valid for the purpose of on-link determination.  A
         value of all one bits (0xffffffff) represents infinity.  The
         Valid Lifetime is also used by [RFC4862].

   Preferred Lifetime  32-bit unsigned integer.  The length of time in
         seconds (relative to the time the packet is sent) that
         addresses generated from the prefix via stateless address
         autoconfiguration remain preferred [RFC4862].  A value of all
         one bits (0xffffffff) represents infinity.  See [RFC4862].



Winter, et al.          Expires December 30, 2010              [Page 49]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


         Note that the value of this field MUST NOT exceed the Valid
         Lifetime field to avoid preferring addresses that are no longer
         valid.

   Reserved2  This field is unused.  It MUST be initialized to zero by
         the sender and MUST be ignored by the receiver.

   Prefix  An IP address or a prefix of an IP address.  
JP>s/IP/IPv6

The Prefix
         Length field contains the number of valid leading bits in the
         prefix.  The bits in the prefix after the prefix length are
         reserved and MUST be initialized to zero by the sender and
         ignored by the receiver.  A router SHOULD NOT send a prefix
         option for the link-local prefix and a host SHOULD ignore such
         a prefix option.  A non-storing node SHOULD refrain from
         advertising a prefix till it owns an address of that prefix,
         and then it SHOULD advertise its full address in this field, to
         be used by its children in the Parent Address field of the
         Transit Information Option
JP> Not =
clear ... "to be used by its children in the Parent Address field of =
the 
Transit Information =
Option"


   Unassigned bits of the Prefix Information option are reserved.  They
   MUST be set to zero on transmission and MUST be ignored on reception.






























Winter, et al.          Expires December 30, 2010              [Page 50]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


6.  Sequence Counters

   This section describes the general scheme for bootstrap and operation
   of sequence counters in RPL, such as the DODAGVersionNumber in the
   DIO message, the DAOSequence in the DAO message, and the Path-
   Sequence in the Transit Information option.

   RPL sequence counters are subdivided in a 'lollipop' fashion
   ([Perlman83]), where the values from 128 and greater are used as a
   linear sequence to indicate a restart and bootstrap the counter, and
   the values less than or equal to 127 used as a circular sequence
   number space of size 128 as in [RFC1982].  Consideration is given to
   the mode of operation when transitioning from the linear region to
   the circular region.  Finally, when operating in the circular region,
   if sequence numbers are detected to be too far apart then they are
   not comparable, as detailed below.

   A window of comparison, SEQUENCE_WINDOW =3D 16, is configured based =
on
   a value of 2^N, where N=3D4.

JP> Is N advertised, locally configured, =
... 
   For a given sequence counter,

   1.  The sequence counter SHOULD be initialized to an implementation
       defined value which is 128 or greater prior to use.  A
       recommended value is 240 (256 - SEQUENCE_WINDOW).

   2.  When a sequence counter increment would cause the sequence
       counter to increment beyond its maximum value, the sequence
       counter MUST wrap back to zero.  When incrementing a sequence
       counter greater than or equal to 128, the maximum value is 255.
       When incrementing a sequence counter less than 128, the maximum
       value is 127.

   3.  When comparing two sequence counters, the following rules MUST be
       applied:

       1.  When a first sequence counter A is in the interval [0..127]
           and a second sequence counter B is in [128..255]:

           1.  If B-A is less than or equal to SEQUENCE_WINDOW, then B
               is greater than A, A is less than B, and the two are not
               equal.

           2.  If B-A is greater than SEQUENCE_WINDOW, then A is greater
               than B, B is less than A, and the two are not equal.






Winter, et al.          Expires December 30, 2010              [Page 51]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


       2.  In the case where both sequence counters to be compared are
           less than or equal to 127, and in the case where both
           sequence counters to be compared are greater than or equal to
           128:

           1.  If the absolute magnitude of difference between the two
               sequence counters is less than or equal to
               SEQUENCE_WINDOW, then a comparison as described in
               [RFC1982] is used to determine the relationships greater
               than, less than, and equal

           2.  If the absolute magnitude of difference of the two
               sequence counters is greater than SEQUENCE_WINDOW, then a
               desynchronization has occurred and the two sequence
               numbers are not comparable.

   4.  If two sequence numbers are determined to be not comparable, i.e.
       the results of the comparison are not defined, then a node should
       consider the comparison as if it has evaluated in such a way so
       as to give precedence to the sequence number that has most
       recently been observed to increment.  Failing this, the node
       should consider the comparison as if it has evaluated in such a
       way so as to minimize the resulting changes to its own state.




























Winter, et al.          Expires December 30, 2010              [Page 52]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


7.  Upward Routes

   This section describes how RPL discovers and maintains upward routes.
   It describes the use of DODAG Information Objects (DIOs), the
   messages used to discover and maintain these routes.  It specifies
   how RPL generates and responds to DIOs.  It also describes DODAG
   Information Solicitation (DIS) messages, which are used to trigger
   DIO transmissions.

7.1.  DIO Base Rules

   1.  For the following DIO Base fields, a node that is not a DODAG
       root MUST advertise the same values as its preferred DODAG parent
       (defined in Section 7.2.1).  Therefore, if a DODAG root does not
       change these values, every node in a route to that DODAG root
       eventually advertises the same values for these fields. =
 
JP> Previous sentence not clear =
...
These
       fields are:
       1.  Grounded (G)
       2.  Mode of Operation (MOP)
       3.  DAGPreference (Prf)
       4.  Version
       5.  RPLInstanceID
       6.  DODAGID

   2.  A node MAY update the following fields at each hop:
       1.  Rank
       2.  DTSN

   3.  The DODAGID field each root sets MUST be unique within the RPL
       Instance.

JP> Add: "As a reminder, DODAGID management is outside of =
the scope of this document".
7.2.  Upward =
Route Discovery and Maintenance

   Upward route discovery allows a node to join a DODAG by discovering
   neighbors that are members of the DODAG of interest and identifying a
   set of parents.  The exact policies for selecting neighbors and
   parents is implementation-dependent and driven by the OF.  This
   section specifies the set of rules those policies must follow for
   interoperability.

7.2.1.  Neighbors and Parents within a DODAG Version

   RPL's upward route discovery algorithms and processing are in terms
   of three logical sets of link-local nodes.  First, the candidate
   neighbor set is a subset of the nodes that can be reached via link-
   local multicast.  The selection of this set is implementation-
   dependent and OF-dependent.  Second, the parent set is a restricted
   subset of the candidate neighbor set.  Finally, the preferred parent,



Winter, et al.          Expires December 30, 2010              [Page 53]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   a set of size one, is an element of the parent set that is the
   preferred next hop in upward routes.
JP> There =
may be more than one element in the preferred parent =
set
(e.g. load balancing) depending on the =
OF.


   More precisely:

   1.  The DODAG parent set MUST be a subset of the candidate neighbor
       set.

   2.  A DODAG root MUST have a DODAG parent set of size zero.

   3.  A node that is not a DODAG root MAY maintain a DODAG parent set
       of size greater than or equal to one.

   4.  A node's preferred DODAG parent MUST be a member of its DODAG
       parent set.

   5.  A node's rank MUST be greater than all elements of its DODAG
       parent set.

   6.  When Neighbor Unreachability Detection (NUD), 
JP> Add ref
or an =
equivalent
       mechanism, determines that a neighbor is no longer reachable, a
       RPL node MUST NOT consider this node in the candidate neighbor
       set when calculating and advertising routes until it determines
       that it is again reachable.  Routes through an unreachable
       neighbor MUST be removed from the routing table.

   These rules ensure that there is a consistent partial order on nodes
   within the DODAG.  As long as node ranks do not change, following the
   above rules ensures that every node's route to a DODAG root is loop-
   free, as rank decreases on each hop to the root.

   The OF can guide candidate neighbor set and parent set selection, as
   discussed in [I-D.ietf-roll-routing-metrics] and [I-D.ietf-roll-of0].

7.2.2.  Neighbors and Parents across DODAG Versions

   The above rules govern a single DODAG version.  The rules in this
   section define how RPL operates when there are multiple DODAG
   versions:

7.2.2.1.  DODAG Version

   1.  The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely
       defines a DODAG Version.  Every element of a node's DODAG parent
       set, as conveyed by the last heard DIO message from each DODAG
       parent, MUST belong to the same DODAG version.  Elements of a
       node's candidate neighbor set MAY belong to different DODAG
       Versions.



Winter, et al.          Expires December 30, 2010              [Page 54]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   2.  A node is a member of a DODAG version if every element of its
       DODAG parent set belongs to that DODAG version, or if that node
       is the root of the corresponding DODAG.

   3.  A node MUST NOT send DIOs for DODAG versions of which it is not a
       member.

   4.  DODAG roots MAY increment the DODAGVersionNumber that they
       advertise and thus move to a new DODAG version.  When a DODAG
       root increments its DODAGVersionNumber, it MUST follow the
       conventions of Serial Number Arithmetic as described in
       Section 6.

JP> Add: Events triggering the increment of the =
DODAGVersionNumber are discussed later in 
this section =
and in Section 16.
   5.  Within a =
given DODAG, a node that is a not a root MUST NOT
       advertise a DODAGVersionNumber higher than the highest
       DODAGVersionNumber it has heard.  Higher is defined as the
       greater-than operator in Section 6.

   6.  Once a node has advertised a DODAG version by sending a DIO, it
       MUST NOT be member 
JP>s/be =
member/be a member?
of a previous =
DODAG version of the same DODAG
       (i.e. with the same RPLInstanceID, the same DODAGID, and a lower
       DODAGVersionNumber).  Lower is defined as the less-than operator
       in Section 6.

   When the DODAG parent set becomes empty on a node that is not a root,
   (i.e. the last parent has been removed, causing the node to no longer
   be associated with that DODAG), then the DODAG information should not
   be suppressed until after the expiration of an implementation-
   specific local timer in order to observe if the DODAGVersionNumber
   has been incremented, should any new parents appear for the DODAG.
   This will help protect against the possibility of loops that may
   occur of 
JP> =
s/of/if
that node were to inadvertently =
rejoin the old DODAG version
   in its own prior sub-DODAG.

JP> need to add a few sentence to better explain this case. =
This was discussed on the list
but should be reminded =
here.
   As the DODAGVersionNumber is =
incremented, a new DODAG Version spreads
   outward from the DODAG root.  A parent that advertises the new
   DODAGVersionNumber cannot belong to the sub-DODAG of a node
   advertising an older DODAGVersionNumber.  Therefore a node can safely
   add a parent of any Rank with a newer DODAGVersionNumber without
   forming a loop.

   Exactly when a DODAG Root increments the DODAGVersionNumber is
   implementation and application-dependent and outside the scope of
   this document.  Examples include incrementing the DODAGVersionNumber
   periodically, upon administrative intervention, or on application-
   level detection of lost connectivity or DODAG inefficiency.

   After a node transitions to and advertises a new DODAG Version, the



Winter, et al.          Expires December 30, 2010              [Page 55]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   rules above make it unable to advertise the previous DODAG Version
   (prior DODAGVersionNumber) once it has committed to advertising the
   new DODAG Version.

7.2.2.2.  DODAG Roots

   1.  A DODAG root without possibility to satisfy the application-
       defined goal MUST NOT set the Grounded bit.

   2.  A DODAG root MUST advertise a rank of ROOT_RANK.

   3.  A node whose DODAG parent set is empty MAY become the DODAG Root
       of a floating DODAG.  It MAY also set its DAGPreference such that
       it is less preferred.

   In a deployment that uses a backbone link to federate a number of LLN
   roots, it is possible to run RPL over that backbone and use one
   router as a "backbone root".  The backbone root is the virtual root
   of the DODAG, and exposes a rank of BASE_RANK over the backbone.  All
   the LLN roots that are parented to that backbone root, including the
   backbone root if it also serves as LLN root itself, expose a rank of
   ROOT_RANK to the LLN.  These virtual roots are part of the same DODAG
   and advertise the same DODAGID.  They coordinate DODAGVersionNumbers
   and other DODAG parameters with the virtual root over the =
backbone.
JP> how to they =
coordinate?


7.2.2.3.  DODAG Selection

   The objective function 
JP> And =
the set of advertised routing metrics and =
constraints
of a DAG determines how a node =
selects its
   neighbor set, parent set, and preferred parents.  This selection
   implicitly also decides 
JP> =
"decides" ?
the DODAG within a DAG.  Such =
selection can
   include administrative preference (Prf) as well as metrics or other
   considerations.

   If a node has the option to join a more preferred DODAG while still
   meeting other optimization objectives, then the node will generally
   seek to join the more preferred DODAG as determined by the OF.  All
   else being equal, it is left to the implementation to determine which
   DODAG is most preferred.

JP> "since as a reminder a node can only join one =
DODAG"
7.2.2.4.  Rank and Movement within =
a DODAG Version

   1.  A node MUST NOT advertise a Rank less than or equal to any member
       of its parent set within the DODAG Version.

   2.  A node MAY advertise a Rank lower than its prior advertisement
       within the DODAG Version.





Winter, et al.          Expires December 30, 2010              [Page 56]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   3.  Let L be the lowest rank within a DODAG version that a given node
       has advertised.  Within the same DODAG Version, that node MUST
       NOT advertise an effective rank higher than L +
       DAGMaxRankIncrease.  INFINITE_RANK is an exception to this rule:
       a node MAY advertise an INFINITE_RANK within a DODAG version
       without restriction.  If a node's Rank would be higher than
       allowed by L + DAGMaxRankIncrease, when it advertises Rank it
       MUST advertise its Rank as INFINITE_RANK.

   4.  A node MAY, at any time, choose to join a different DODAG within
       a RPL Instance.  Such a join has no rank restrictions, unless
       that different DODAG is a DODAG Version of which this node has
       previously been a member, in which case the rule of the previous
       bullet (3) must be observed.  
JP> Need =
to explain a bit more this case
Until a node =
transmits a DIO
       indicating its new DODAG membership, it MUST forward packets
       along the previous DODAG.

   5.  A node MAY, at any time after hearing the next DODAGVersionNumber
       advertised from suitable DODAG parents, choose to migrate to the
       next DODAG Version within the DODAG.

   Conceptually, an implementation is maintaining a DODAG parent set
   within the DODAG Version.  Movement entails changes to the DODAG
   parent set.  Moving up does not present the risk to create a loop but
   moving down might, so that operation is subject to additional
   constraints.

   When a node migrates to the next DODAG Version, the DODAG parent set
   needs to be rebuilt for the new version.  An implementation could
   defer to migrate for some reasonable amount of time, to see if some
   other neighbors with potentially better metrics but higher rank
   announce themselves.  Similarly, when a node jumps into a new DODAG
   it needs to construct new a DODAG parent set for this new DODAG.

   If a node needs to move down a DODAG that it is attached to,
   increasing its Rank, then it MAY poison its routes and delay before
   moving as described in Section 7.2.2.5.

7.2.2.5.  Poisoning

   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.
JP> =
Explain why rule 2.


   Although an implementation may advertise INFINITE_RANK for the
   purposes of poisoning, doing so is not the same as setting Rank to
   INFINITE_RANK.  For example, a node may continue to send data packets



Winter, et al.          Expires December 30, 2010              [Page 57]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   whose meta-data 
JP> Need =
to define the term "meta-data"
include a Rank =
that is not INFINITE_RANK yet still
   advertise INFINITE_RANK in its DIOs.

7.2.2.6.  Detaching

   1.  A node unable 
JP> What =
do we mean by "unable" ?
to stay =
connected to a DODAG within a given DODAG
       version MAY detach from this DODAG version.  A node that detaches
       becomes root of its own floating DODAG and SHOULD immediately
       advertise this new situation in a DIO as an alternate to
       poisoning.
JP> Remove the "1." if there is no =
2.


7.2.2.7.  Following a Parent

   1.  If a node receives a DIO from one of its DODAG parents,
       indicating that the parent has left the DODAG, that node SHOULD
       stay in its current DODAG through an alternative DODAG parent, if
       possible.  It MAY follow the leaving parent.

JP> Remove 1.

   A DODAG parent may have moved, migrated to the next DODAG Version, or
   jumped to a different DODAG.  A node should 
JP> s/should/SHOULD
give some =
preference to
   remaining in the current DODAG, if possible via an alternate parent,
   but ought to follow the parent if there are no other options.

7.2.3.  DIO Message Communication

   When an DIO message is received, the receiving node must first
   determine whether or not the DIO message should be accepted for
   further processing, and subsequently present the DIO message for
   further processing if eligible.

   1.  If the DIO message is malformed, then the DIO message is not
       eligible for further processing and a node MUST silently discard
       it.
JP> Add: See Section 16 for error =
logging.


   2.  If the sender of the DIO message is a member of the candidate
       neighbor set and the DIO message is not malformed, the node MUST
       process the DIO.

7.2.3.1.  DIO Message Processing

   As DIO messages are received from candidate neighbors, the neighbors
   may be promoted to DODAG parents by following the rules of DODAG
   discovery as described in Section 7.2.  When a node places a neighbor
   into the DODAG parent set, the node becomes attached to the DODAG
   through the new DODAG parent node.

   The most preferred parent should be used to restrict which other
   nodes may become DODAG parents.  Some nodes in the DODAG parent set



Winter, et al.          Expires December 30, 2010              [Page 58]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   may be of a rank less than or equal to the most preferred DODAG
   parent.  (This case may occur, for example, if an energy constrained
   device is at a lesser rank but should be avoided as per an
   optimization objective, resulting in a more preferred parent at a
   greater rank).

7.3.  DIO Transmission

   RPL nodes transmit DIOs using a Trickle timer
   ([I-D.ietf-roll-trickle]).  A DIO from a sender with a lower DAGRank
   that causes no changes to the recipient's parent set, preferred
   parent, or Rank SHOULD be considered consistent with respect to the
   Trickle timer.

   The following packets and events MUST be considered inconsistencies
   with respect to the Trickle timer, and cause the Trickle timer to
   reset:

   o  When a node detects an inconsistency when forwarding a packet, as
      detailed in Section 10.2.

   o  When a node receives a multicast DIS message without a Solicited
      Information option.

   o  When a node receives a multicast DIS with a Solicited Information
      option and the node matches all of the predicates in the Solicited
      Information option.

   o  When a node joins a new DODAG Version (e.g. by updating its
      DODAGVersionNumber, joining a new RPL Instance, etc.)

   Note that this list is not exhaustive, and an implementation MAY
   consider other messages or events to be inconsistencies.

   A node SHOULD NOT reset its DIO trickle timer in response to unicast
   DIS messages.  When a node receives a unicast DIS without a Solicited
   Information option, it MUST unicast a DIO to the sender in response.
   This DIO MUST include a DODAG Configuration option.  When a node
   receives a unicast DIS message with a Solicited Information option,
   if it satisfies the predicates of the Solicited Information option it
   MUST unicast a DIO to the sender in response.  This unicast DIO MUST
   include a DODAG Configuration Option.  Thus a node =
may 

transmit a
   unicast DIS message to a potential DODAG parent in order to probe for
   DODAG Configuration and other parameters.







Winter, et al.          Expires December 30, 2010              [Page 59]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


7.3.1.  Trickle Parameters

   The configuration parameters of the trickle timer are specified as
   follows:

   Imin: learned from the DIO message as (2^DIOIntervalMin)ms.  The
         default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.

   Imax: learned from the DIO message as DIOIntervalDoublings.  The
         default value of DIOIntervalDoublings is
         DEFAULT_DIO_INTERVAL_DOUBLINGS.

   k:    learned from the DIO message as DIORedundancyConstant.  The
         default value of DIORedundancyConstant is
         DEFAULT_DIO_REDUNDANCY_CONSTANT.  In RPL, when k has the value
         of 0x00 this is to be treated as a redundancy constant of
         infinity in RPL, i.e.  Trickle never suppresses messages.

7.4.  DODAG Selection

   The DODAG selection is implementation and OF dependent.  Nodes SHOULD
   prefer to join DODAGs for RPLInstanceIDs advertising OCPs and
   destinations compatible with their implementation specific
   objectives.  
JP> =
Shouldn't we have a MUST here ? See thread of the =
list.
In order to limit erratic =
movements, and all metrics
   being equal, nodes SHOULD keep their previous selection.  Also, nodes
   SHOULD provide a means to filter out a parent whose availability is
   detected as fluctuating, at least when more stable choices are
   available.

   When connection to a grounded DODAG is not possible or preferable for
   security or other reasons, scattered DODAGs MAY aggregate as much as
   possible into larger DODAGs in order to allow connectivity within the
   LLN.

   A node SHOULD verify that bidirectional connectivity and adequate
   link quality is available with a candidate neighbor before it
   considers that candidate as a DODAG parent.

7.5.  Operation as a Leaf Node

   In some cases a RPL node may attach to a DODAG as a leaf node only.
   One example of such a case is when a node does not =
understand 
JP> or does not support =
(policy)

the RPL
   Instance's OF or advertised metric/constraint.  As specified in
   Section 16.6 related to policy function, the node may either join the
   DODAG as a leaf node or may not join the DODAG.  As mentioned in
   Section 16.5, it is then recommended to log a fault.

   A leaf node does not extend DODAG connectivity but in some cases the



Winter, et al.          Expires December 30, 2010              [Page 60]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   leaf node may still need to transmit DIOs on occasion, in particular
   when the leaf node may not have always been acting as a leaf node and
   an inconsistency is detected.

   A node operating as a leaf node must obey the following rules:

   1.  It MUST NOT transmit DIOs containing the DAG Metric Container.

   2.  Its DIOs MUST advertise a DAGRank of INFINITE_RANK.

   3.  It MAY suppress DIO transmission, except DIO transmission MUST
       NOT be suppressed when DIO transmission has been triggered due to
       detection of inconsistency when a packet is being forwarded or in
       response to a unicast DIS message.

   4.  It MAY transmit unicast DAOs as described in Section 8.2.

   5.  It MAY transmit multicast DAOs to the '1 hop' neighborhood as
       described in Section 8.10.

   A particular case that requires a leaf node to send a DIO is if that
   leaf node was a prior member of another DODAG and another node
   forwards a message assuming the old topology, triggering an
   inconsistency.  The leaf node needs to transmit a DIO in order to
   repair the inconsistency.  Note that due to the lossy nature of LLNs,
   even though the leaf node may have optimistically poisoned its routes
   by advertising a rank of INFINITE_RANK in the old DODAG prior to
   becoming a leaf node, that advertisement may have become lost and a
   leaf node must be capable to send a DIO later in order to repair the
   inconsistency.

   In general it is not expected that such a leaf node would advertise
   itself as a router.

JP> I'd rather: "In general, the leaf node must not =
advertise itself as a router
(i.e. send =
DIOs).
7.6.  Administrative Rank

   In some cases it might be beneficial to adjust the rank advertised by
   a node beyond that computed by the OF based on some implementation
   specific policy and properties of the node.  For example, a node that
   has limited battery should be a leaf unless there is no other choice,
   and may then augment the rank computation specified by the OF in
   order to expose an exaggerated rank.









Winter, et al.          Expires December 30, 2010              [Page 61]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


8.  Downward Routes

   This section describes how RPL discovers and maintains downward
   routes.  RPL constructs and maintains downward routes with
   Destination Advertisement Object (DAO) messages.  Downward routes
   support of P2MP flows, from the DODAG roots toward the leaves.
   Downward routes also support P2P flows: P2P messages can flow to a
   DODAG Root 
through an upward route, then away =
from the DODAG Root to
   a destination through a downward route.

   This specification describes the two modes a RPL Instance may choose
   from for maintaining downward routes.  In the first mode, call
   "storing," nodes store downward routing tables for their sub-DODAG.
   Each hop on a downward route in a storing network examines its
   routing table to decide on the next hop.  In the second mode, called
   "non-storing," nodes do not store downward routing tables.  Downward
   packets are routed with source routes populated by a DODAG Root.

JP> Add reference to =
RH4
   RPL allows a simple one-hop P2P optimization =
for both storing and
   non-storing networks.  A node may send a P2P packet destined to a
   one-hop neighbor directly to that node.

8.1.  Destination Advertisement Parents

   To establish downward routes, RPL nodes send DAO messages upwards.
   The next hop destinations of these DAO messages are called DAO
   parents.  The collection of a node's DAO parents is called the DAO
   parent set.

   o  A node's DAO parent set MUST be a subset of its DODAG parent set.

   o  A node MUST NOT unicast DAOs to nodes that are not DAO parents.

   o  A node MAY link-local multicast DAO messages.

JP> s/link-local multicast/A node MAY send DAO =
messages using link-local address.
Indicate that =
this is for one-hop routing.
   o  The IPv6 =
Source Address of a DAO message MUST be the link local
      address of the sending node.

   o  If a node sends a DAO to one DAO parent, it MUST send a DAO with
      the same DAOSequence to all other DAO parents.

   The selection of DAO parents is implementation and objective function
   specific.

8.2.  Downward Route Discovery and Maintenance

   Destination Advertisement may be configured to be entirely disabled,
   or operate in either a storing or non-storing mode, as reported in



Winter, et al.          Expires December 30, 2010              [Page 62]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   the MOP in the DIO message.

   1.  All nodes who join a DODAG MUST abide by the MOP setting from the
       root.  Nodes that do not have the capability to fully participate
       as a router MAY join the DODAG as a leaf.

JP> A node that does not match the advertised MOP may =
decide to join as a leaf.
It is worth being spelled =
out.
   2.  If the MOP is 000, =
indicating no downward routing, nodes MUST NOT
       transmit DAO messages, and MAY ignore DAO messages.

   3.  In non-storing mode, the DODAG Root MUST store source routing
       table entries for all destinations learned from DAOs.

JP> I do not think that I would mandate for "all =
destinations", it could be for a subset 
according to =
some policy (remember the route tag =
?).
   4.  In storing mode, all non-root, non-leaf =
nodes MUST store routing
       table entries for all destinations learned from DAOs.

JP> Same comments
   A DODAG can =
have one of several possible modes of operation, as
   defined by the MOP field.  Either it does not support downward
   routes, it supports downward routes through source routing from DODAG
   Roots, or it supports downward routes through in-network routing
   tables.  When downward routes are supported through in-network
   routing tables, the multicast operation defined in this specification
   may or may not be supported, also as indicated by the MOP field.  As
   of this specification RPL does not support mixed-mode operation,
   where some nodes source route and other store routing tables: future
   extensions to RPL may support this mode of operation.

8.3.  DAO Base Rules

   1.  Each time a node generates a new DAO, the DAOSequence field MUST
       increment by at least one since the last generated DAO.

   2.  Each time a node link-local multicasts a DAO, the DAOSequence
       field MUST increment 
JP> s/MUST =
increment/MUST be incremented by =
one

by one since the last link local multicast
       DAO.

   3.  The RPLInstanceID and DODAGID fields of a DAO MUST be the same
       value as the members of the node's parent set and the DIOs it
       transmits.

   4.  A node MAY set the K flag in a unicast DAO message to solicit a
       unicast DAO-ACK in response in order to confirm the attempt.  A
       node receiving a unicast DAO message with the K flag set SHOULD
       respond with a DAO-ACK.  A node receiving a DAO message without
       the K flag set MAY respond with a DAO-ACK, especially to report
       an error condition.

   5.  Nodes SHOULD ignore DAOs without newer sequence numbers and MUST
       NOT process them further.



Winter, et al.          Expires December 30, 2010              [Page 63]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Unlike the Version field of a DIO, which is incremented only by a
   DODAG Root and repeated unchanged by other nodes, DAOSequence values
   are unique to each node.  The sequence number space for unicast and
   multicast DAO messages can be either the same or distinct.
JP> We do not need a SHOULD or MUST here since there is no =
interop issue
but I would suggest to RECOMMEND to use =
the same sequence number space.
8.4.  DAO Transmission Scheduling

   Because DAOs flow upwards, receiving a unicast DAO can trigger
   sending a unicast DAO.

   1.  On receiving a unicast DAO with a new DAOSequence, a node SHOULD
       send a DAO.  It SHOULD NOT send this DAO immediately.  It SHOULD
       delay sending the DAO in order to aggregate DAO information from
       other nodes for which it is a DAO parent.

   2.  A node SHOULD delay sending a DAO with a timer (DelayDAO).
       Receiving a DAO starts the DelayDAO timer.  DAOs received while
       the DelayDAO timer is active do not reset the timer.  When the
       DelayDAO timer expires, the node sends a DAO.

   3.  When a node adds a node to its DAO parent set, it SHOULD schedule
       a DAO transmission.

   DelayDAO's value and calculation is implementation-dependent.

8.5.  Triggering DAO Messages

   Nodes can trigger their sub-DODAG to send DAO messages.  Each node
   maintains a DAO Trigger Sequence Number (DTSN), which it communicates
   through DIO messages.

   1.  If a node hears one of its DAO parents increment its DTSN, the
       node MUST schedule a DAO transmission using rules in Section 8.3
       and Section 8.4.

   2.  In non-storing mode, if a node hears one of its DAO parents
       increment its DTSN, the node MUST increment its own DTSN.

   In a storing mode of operation, a storing node MAY increment DTSN in
   order to reliably trigger a set of DAO updates from its immediate
   children, as part of routine routing table updates and maintenance.
   In a storing mode of operation it is not necessary to trigger DAO
   updates from the entire sub-DODAG, since that state information will
   percolate hop-by-hop up the DODAG in the storing mode of =
operation.

JP> mmm ... not sure to correctly =
parse the previous sentence.


   In a non-storing mode of operation, a DTSN increment will also cause
   the immediate children of a node to increment their DTSN in turn,
   triggering a set of DAO updates from the entire sub-DODAG.  In a non-



Winter, et al.          Expires December 30, 2010              [Page 64]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   storing mode of operation typically only the root would independently
   increment the DTSN when a DAO refresh is needed but a global repair
   (such as by incrementing DODAGVersionNumber) is not desired.  In a
   non-storing mode of operation typically all non-root nodes would only
   increment their DTSN when their parent(s) are observed to do so.

   In the case of triggered DAOs, selecting a proper DAODelay can
   greatly reduce the number of DAOs transmitted.  The trigger flows
   down the DODAG; in the best case the DAOs flow up the DODAG such that
   leaves send DAOs first, with each node sending a DAO only once.  Such
   a scheduling could be approximated by setting DAODelay inversely
   proportional to Rank.  Note that this suggestion is intended as an
   optimization to allow efficient aggregation -- it is not required for
   correct operation in the general case.
JP> =
Suppress the "--" and replace by parenthesis.


8.6.  Structure of DAO Messages

   DAOs follow a common structure in both storing and non-storing
   networks.  Later sections describe further details for each mode of
   operation.

   1.  RPL nodes MUST include one or more RPL Target Options in each DAO
       they transmit.  One RPL Target Option MUST have a prefix that
       includes the node's IPv6 address if that node needs the DODAG to
       provision downward routes to that node.

   2.  A RPL Target Option in a unicast DAO MUST be followed by a
       Transit Information Option.

   3.  Multicast DAOs MUST NOT include Transit Information options.

   4.  If a node receives a DAO that does not follow the above three
       rules, it MUST discard the DAO without further processing.

8.7.  Non-storing Mode

   In non-storing mode, RPL routes messages downward using source
   routing.  
JP> =
s/source routing/IP source routing

The following =
rule applies to nodes that are in non-storing
   mode.  Storing mode has a separate set of rules, described in
   Section 8.8.

   1.  The Parent Address field of a Transit Information Option MUST
       contain one or more addresses.  All of these addresses MUST be
       addresses of DAO parents of the sender.

   2.  On receiving a unicast DAO, a node MUST forward the DAO upwards.
       This forwarding MAY use any parent in the parent set.  Note that
       this forwarding may be delayed in support of aggregation as



Winter, et al.          Expires December 30, 2010              [Page 65]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


       described below, but that such a delay is not required if a
       node's resources do not support it.

   3.  When a node removes a node from its DAO parent set, it MAY
       generate a new DAO with an updated Transit Information option.

   In non-storing mode, a node uses DAOs to report its DAO parents to
   the DODAG Root.  The DODAG Root can piece together a downward route
   to a node by using DAO parent sets from each node in the route.  The
   purpose of this per-hop route calculation is to minimize traffic when
   DAO parents change.  If nodes reported complete source routes, then
   on a DAO parent change the entire sub-DODAG would have to send new
   DAOs to the DODAG Root.  Therefore, in non-storing mode, a node can
   send a a single DAO, although it might choose to send more than one
   DAO to each of multiple DAO parents.

   Nodes aggregate DAOs by sending a single DAO with multiple RPL Target
   Options.  
JP> didn't =
we mean "pack" instead of "aggregate" since one could aggregate and =
send
one RPL Target =
option.
Each RPL Target Option has its own, =
immediately following,
   Transit Information options.

8.8.  Storing Mode

   In storing mode, RPL routes messages downward by the IPv6 destination
   address.  The following rule apply to nodes that are in storing mode:

   1.  The Parent Address field of a Transmit Information option MUST be
       empty.

   2.  On receiving a unicast DAO, 
JP> Let's =
make sure to replace all "DAO" by "DAO =
message"

a node MUST compute if the DAO =
would
       change the set of prefixes that the node itself advertises.  If
       so, the node MUST generate a new DAO and transmit it, following
       the rules in Section 8.4.  Such a change includes receiving a No-
       Path DAO.

   3.  When a node generates a new DAO, it SHOULD unicast it to each of
       its DAO parents.  It MUST NOT unicast the DAO to nodes that are
       not DAO parents.

   4.  When a node removes a node from its DAO parent set, it SHOULD
       send a No-Path DAO (Section 5.4.3) to that removed DAO parent to
       invalidate the existing route.
JP> =
Suggest a MUST in bullet 4. (see thread on the mailing =
list).


   5.  If messages to an advertised downwards address suffer from a
       forwarding error, neighbor unreachable detected (NUD), or similar
       failure, a node MAY mark the address as unreachable and generate
       an appropriate No-Path DAO.

   DAOs advertise what destination addresses and prefixes a node has



Winter, et al.          Expires December 30, 2010              [Page 66]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   routes to.  Unlike in non-storing mode, these DAOs do not communicate
   information about the routes themselves: that information is stored
   within the network and is implicit from the IPv6 source address.
   When a storing node generates a DAO, it uses the stored state of DAOs
   it has received to produce a set of RPL Target options and their
   associated Transmit Information options.

   Because this information is stored within a network, 
JP> The term "within a network" is a bit misleading. I =
would suggest in nodes' routing =
tables.
in storing mode
   DAOs are communicated directly to DAO parents, who store this
   information.

8.9.  Path Control

   A DAO message from a node contains one or more Target Options.  Each
   Target Option specifies either the node's prefix, a prefix of
   addresses reachable outside the LLN, or a destination in the node's
   sub-DODAG.  The Path Control field of the Transit Information option
   allows nodes to request 
JP> To =
request or to allow for ... since parents (depending on their policy) =
may decide to use
one =
route.
multiple downward routes.  A node =
constructs
   the Path Control field of a Transit Information option as follows:

   1.  The bit width of the path control field MUST be equal to the
       value (PCS + 1), where PCS is specified in the control field of
       the DODAG Configuration Option.  Bits greater than or equal to
       the value (PCS + 1) MUST be cleared on transmission and MUST be
       ignored on reception.  Bits below that value are considered
       "active" bits.

   2.  For a RPL Target option describing a node's own address or a
       prefix outside the LLN, at least one active bit of the Path
       Control field MUST be set.  More active bits of the Path Control
       field MAY be set.

   3.  If a node receives multiple DAOs with the same RPL Target option,
       it MUST bitwise-OR the Path Control fields it receives.  This
       aggregated bitwise-OR represents the number of downward routes
       the prefix requests.

   4.  When a node sends a DAO to one of its DAO parents, it MUST select
       one or more of the set, active bits in the aggregated Path
       Control field.  The DAO it transmits to its parent MUST have
       these active bits set and all other active bits cleared.

   5.  For the RPL Target option and DAOSequence number, the DAOs a node
       sends to different DAO parents MUST have disjoint sets of active
       Path Control bits.  A node MUST NOT set the same active bit on
       DAOs to two different DAO parents.





Winter, et al.          Expires December 30, 2010              [Page 67]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   6.  Path control bits SHOULD be allocated in order of preference,
       such that the most significant bits, or groupings of bits, are
       allocated to the most preferred DAO parents as determined by the
       node.

   7.  In a non-storing mode of operation, a node MAY pass DAOs through
       without performing any further processing on the Path Control
       field.

   8.  A node MUST NOT unicast a DAO that has no active bits in the Path
       Control field set.

   The Path Control field allows a node to bound how many downward
   routes will be generated to it.  It sets a number of bits in the Path
   Control field equal to the maximum number of downward routes it
   prefers.  Each bit is sent to at most one DAO parent; clusters of
   bits can be sent to a single DAO parent for it to divide among its
   own DAO parents.

JP> Section about PC to be reworked according to ticket =
#60. An example
would be a good =
idea.
8.10.  Multicast Destination =
Advertisement Messages

   A special case of DAO operation, distinct from unicast DAO operation,
   is multicast DAO operation which may be used to populate '1-hop'
   routing table entries.

   1.  A node MAY multicast a DAO message to the link-local scope all-
       nodes multicast address FF02::1.

JP> ALL RPL Routers address =
?
   2.  A multicast DAO message MUST be used =
only to advertise
       information about self, i.e. prefixes directly connected to or
       owned by this node, such as a multicast group that the node is
       subscribed to or a global address owned by the node.

   3.  A multicast DAO message MUST NOT be used to relay connectivity
       information learned (e.g. through unicast DAO) from another node.

   4.  Information obtained from a multicast DAO MAY be installed in the
       routing table and MAY be propagated by a node in unicast DAOs.

JP> any contradiction between 3. and =
4.?
   5.  A node MUST NOT perform any other DAO =
related processing on a
       received multicast DAO, in particular a node MUST NOT perform the
       actions of a DAO parent upon receipt of a multicast DAO.

   o  The multicast DAO may be used to enable direct P2P communication,
      without needing the RPL routing structure 
JP> s/RPL routing =
structure/DODAG
to relay the packets.

   o  The multicast DAO does not presume any DODAG relationship between
      the emitter 
JP> =
s/emitter/sender. Isn't the last bullet redundant with the previous =
one?
and the receiver.



Winter, et al.          Expires December 30, 2010              [Page 68]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


9.  Security Mechanisms

JP> I skip that section for the time being since there are =
few discussions on the ML.
Will comment afterwards. See Ticket =
#68
   This section describes the generation and processing of secure RPL
   messages.  The high order bit of the RPL message code identifies
   whether a RPL message is secure or not.  In addition to secure
   versions of basic control messages (DIS, DIO, DAO, DAO-Ack), RPL has
   several messages which are relevant only in networks with security
   enabled.

9.1.  Security Overview

   RPL supports three security modes:

   o  Insecure.  In this security mode, RPL uses insecure DIS, DIO, DAO,
      and DAO-Ack messages.

   o  Pre-installed.  In this security mode, RPL uses secure messages.
      To join a RPL Instance, a node must have a pre-installed key.
      Nodes use this to provide message confidentiality, integrity, and
      authenticity.  A node may, using this preinstalled key, join the
      RPL network as either a host or a router.

   o  Authenticated.  In this security mode, RPL uses secure messages.
      To join a RPL Instance, a node must have a pre-installed key.
      Node use this key to provide message confidentiality, integrity,
      and authenticity.  Using this preinstalled key, a node may join
      the network as a host only.  To join the network as a router, a
      node must obtain a second key from a key authority.  This key
      authority can authenticate that the requester is allowed to be a
      router before providing it with the second key.

   Whether or not the RPL Instance uses insecure mode is signaled by
   whether it uses secure RPL messages.  Whether a secured network uses
   the pre-installed or authenticated mode is signaled by the 'A' bit of
   the DAG Configuration option.

   RPL uses CCM* -- Counter with CBC-MAC (Cipher Block Chaining Message
   Authentication Code) -- as the cryptographic basis for its
   security[RFC3610].  In this specification, CCM uses AES-128 as its
   underlying cryptographic algorithm.  There are bits reserved in the
   security section to specify other algorithms in the future.

   All secured RPL messages have a message authentication code (MAC).
   Secured RPL messages optionally also have encryption protection for
   confidentiality.  Secured RPL message formats support both integrated
   encryption/authentication schemes (e.g., CCM*) as well as schemes
   that separately encrypt and authenticate packets.




Winter, et al.          Expires December 30, 2010              [Page 69]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


9.2.  Installing Keys

   Authenticated mode requires a would-be router to dynamically install
   new keys once they have joined a network as a host.

   The exact message exchange to obtain such keys is TBD.  It will
   involve communication with a key authority, possibly, using the pre-
   installed shared key.  The key authority can apply a security policy
   to decide whether to grant the would-be-router a new key.  These keys
   may have lifetimes (start and end times) associated with them, which
   nodes that support timestamps (described in Section 9.4.1) can use.

9.3.  Joining a Secure Network

   RPL security assumes that a node wishing to join a secured network
   has been preconfigured with a shared key for communicating with
   neighbors and the RPL root.  To join a secure RPL network, a node
   either listens for secure DIOs or triggers secure DIOs by sending a
   secure DIS.  In addition to the DIO/DIS rules in Section 7, secure
   DIO and DIS messages have these rules:

   1.  If sent, this initial secure DIS MUST NOT set the C bit, MUST set
       the KIM field to 0 (00), and MUST set the LVL field to 1 (001).
       The key used MUST be the preconfigured group key (Key Index
       0x00).

   2.  When a node resets its Trickle timer in response to a secure DIS
       (Section 7.3), the next DIO it transmits MUST be a secure DIO
       with the same security configuration as the secure DIS.  If a
       node receives multiple secure DIS messages before it transmits a
       DIO, the secure DIO MUST have the same security configuration as
       the last DIS it is responding to.

   3.  When a node sends a DIO in response to a unicast secure DIS
       (Section 7.3), the DIO MUST be a secure DIO.

   The above rules allow a node to join a secured RPL Instance using the
   preconfigured shared key.  Once a node has joined the DODAG using the
   preconfigured shared key, the 'A' bit of the Configuration option
   determines its capabilities.  If the 'A' bit of the Configuration is
   cleared, then nodes can use this preinstalled, shared key to exchange
   messages normally: it can issue DIOs, DAOs, etc.

   If the 'A' bit of the Configuration option is set:

   1.  A node MUST NOT advertise a Rank besides INFINITE_RANK in secure
       DIOs secured with Key Index 0x00.  If a node receives a secure
       DIO that advertises a Rank besides INFINITE_RANK and is secured



Winter, et al.          Expires December 30, 2010              [Page 70]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


       with Key Index 0x00, it MUST discard the message without further
       processing.

   2.  Secure DAOs using Key Index 0x00 MUST NOT have a RPL Target
       option with a prefix besides the node's address.  If a node
       receives a secured DAO using the preinstalled, shared key where
       the RPL Target option does not match the IPv6 source address, it
       MUST discard the secured DAO without further processing.

   The above rules mean that in RPL Instances where the 'A' bit is set,
   using Key Index 0x00 a node can join the RPL Instance as a host but
   not a router.  A node must communicate with a key authority to obtain
   a key that will enable it to act as a router.  Obtaining this key
   might require authentication on one or both ends.  This message
   exchange is TBD.

9.4.  Counter and Counter Compression

   Every secured RPL packet has a Counter field.  Depending on whether
   the 'C' bit is set, this Counter field can be 1 or 4 bits.  RPL nodes
   send CC messages to force uncompressed Counter values, protect
   against replay attacks and synchronize counters.

   1.  If a node is sending a secured RPL packet, and the Counter value
       of the packet is more than 255 greater than the last secured
       packet to the destination address, the node MUST NOT set the 'C'
       bit of the security section of the packet.

   2.  If a node receives a secure RPL message with the C bit set and is
       uncertain of the 32-bit counter value, it MAY send a CC message
       with the R bit cleared to obtain an uncompressed counter value.
       The Nonce field of the CC message SHOULD be a random or
       pseudorandom number.

   3.  If a node receives a unicast CC message with the R bit cleared,
       and it is a member of or is in the process of joining the
       associated DODAG, it SHOULD respond with a unicast CC message to
       the sender.  This response MUST have the C bit of the security
       section cleared, MUST have the R bit set, and MUST have the same
       Nonce, RPLInstanceID and DODAGID fields as the message it
       received.

   4.  If a node receives a multicast CC message, it MUST discard the
       message with no further processing.

   These rules allow nodes to compress the Counter when destinations who
   received the prior packet can determine the full counter value.  If a
   node cannot determine the full counter value, it can request the full



Winter, et al.          Expires December 30, 2010              [Page 71]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   counter with a CC message.

9.4.1.  Timestamp Counters

   In the simplest case, the Counter value is an unsigned integer that a
   node increments by one or more on each secured RPL transmission.  The
   Counter MAY represent a timestamp that has the following properties:

   1.  The timestamp MUST be at least six octets long.

   2.  The timestamp MUST be in 1kHz (millisecond) granularity.

   3.  The timestamp start time MUST be January 1, 2010, 12:00:00AM UTC.

   4.  If the Counter represents such as timestamp, the Counter value
       MUST be a value computed as follows.  Let T be the timestamp, S
       be the start time of the key in use, and E be the end time of the
       key in use.  Both S and E are represented using the same 3 rules
       as the timestamp described above.  If E > T < S, then the =
Counter
       is invalid and a node MUST NOT generate a packet.  Otherwise, the
       Counter value is equal to T-S.

   5.  If the Counter represents such a timestamp, a node MAY set the
       'T' flag of the security section of secured RPL packets.

   6.  If the Counter field does not present such a timestamp, then a
       node MUST NOT set the 'T' flag.

   7.  If a node does not have a local timestamp that satisfies the
       above requirements, it MUST ignore the 'T' flag.

   If a node supports such timestamps and it receives a message with the
   'T' flag set, it MAY apply the temporal check on the received message
   described in Section 9.5.2.1.  If a node receives a message without
   the 'T' flag set, it MUST NOT apply this temporal check.  A node's
   security policy MAY, for application reasons, include rejecting all
   messages without the 'T' flag set.

9.5.  Functional Description of Packet Protection

9.5.1.  Transmission of Outgoing Packets

   Given an outgoing RPL control packet and required security
   protection, this section describes how RPL generates the secured
   packet to transmit.  It also describes the order of cryptographic
   operations to provide the required protection.

   The requirement for security protection and the level of security to



Winter, et al.          Expires December 30, 2010              [Page 72]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   be applied to an outgoing RPL packet shall be determined by the
   node's security policy database.  The configuration of this security
   policy database for outgoing packet processing is TBD (it may, for
   example, be defined through DIO Configuration or through out-of-band
   administrative router configuration).

   Where secured RPL messages are to be transmitted, a RPL node MUST set
   the security section (C, T, Sec, KIM, and LVL) in the outgoing RPL
   packet to describe the protection level and security settings that
   are applied (see Section 5.1).  The Security subfield bit of the RPL
   message Code field MUST be set to indicate the secure RPL message.

   The Counter value used in constructing the Nonce to secure the
   outgoing packet MUST be an increment of the last Counter transmitted
   to the particular destination address.  Where a Counter for the
   intended destination address has not been established, the Counter
   value MUST be initialized to zero and sent as a Full Counter for the
   initial RPL message transmission.

   Where a Counter is currently maintained for outgoing messages to the
   intended destination address, the Compressed Counter (indicated with
   the 'C' bit set) MUST be transmitted within the secured RPL message,
   provided the message is not a RPL Consistency Check message.  The
   current Full Counter (indicated with the 'C' bit cleared) for the
   given destination address SHALL always be used when the outgoing
   packet is a Consistency Check (challenge or response) message.  Where
   a Counter for the intended destination address does not exist, the
   initialized (zero-value), Full Counter MUST be transmitted within the
   initial RPL control message.  Where security policy specifies the
   application of delay protection, the Timestamp Counter used in
   constructing the Nonce to secure the outgoing packet MUST be
   incremented according to the rules in Section 9.4.1.  Where a
   Timestamp Counter is applied (indicated with the 'T' flag set) the
   locally maintained Time Counter MUST be included as part of the
   transmitted secured RPL message.

   The cryptographic algorithm used in securing the outgoing packet
   shall be specified by the node's security policy database and MUST be
   indicated in the value of the Sec field set within the outgoing
   message.

   The security policy for the outgoing packet shall determine the
   applicable Key Identifier Mode (KIM) and Key Identifier specifying
   the security key to be used for the cryptographic packet processing,
   including the optional use of signature keys (see Section 5.1).  The
   security policy will also specify the level of protection (LVL) in
   the form of authentication or authentication and encryption, and
   potential use of signatures that shall apply to the outgoing packet.



Winter, et al.          Expires December 30, 2010              [Page 73]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Where encryption is applied, a node MUST replace the original packet
   payload with that payload encrypted using the security protection,
   key, and nonce specified in the security section of the packet.

   All secured RPL messages include integrity protection.  In
   conjunction with the security algorithm processing, a node derives a
   Message Authentication Code (MAC) that MUST be included as part of
   the outgoing secured RPL packet.

9.5.2.  Reception of Incoming Packets

   This section describes the reception and processing of a secured RPL
   packet.  Given an incoming secured RPL packet, where the Security
   subfield bit of the RPL message Code field is set, this section
   describes how RPL generates an unencrypted version of the packet and
   validates its integrity.

   The receiver uses the RPL security control fields to determine the
   necessary packet security processing.  If the described level of
   security for the message type and originator does not meet locally
   maintained security policies, a node MAY discard the packet without
   further processing.  These policies can include security levels, keys
   used, source identifiers, or the lack of timestamp-based counters (as
   indicated by the 'T' flag).  The configuration of the security policy
   database for incoming packet processing is TBD (it may, for example,
   be defined through DIO Configuration or through out-of-band
   administrative router configuration).

   Where the message security level (LVL) indicates an encrypted RPL
   message, the node uses the key information identified through the KIM
   field as well as the Nonce as input to the message payload decryption
   processing.  The Nonce shall be derived from the message Counter
   field and other received and locally maintained information (see
   Section 9.5.3.1).  The plaintext message contents shall be obtained
   by invoking the inverse cryptographic mode of operation specified by
   the Sec field of the received packet.

   The receiver shall use the Nonce and identified key information to
   check the integrity of the incoming packet.  If the integrity check
   fails against the received message authentication code (MAC), a node
   MUST discard the packet.

   If a Compressed Counter is received and the node does not currently
   have an incoming Counter currently maintained for the originator of
   the message, the node MUST send a Consistency Check request to the
   message source to update the Counters.

   If an initialized (zero value) Full Counter is received in a secured



Winter, et al.          Expires December 30, 2010              [Page 74]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   RPL message and the receiving node currently has an incoming Counter
   currently maintained for the originator of the message, the node MUST
   initiate a Counter resynchronization by sending a Consistency Check
   response message (see Section 5.6.1) to the message source.  The
   Consistency Check response message shall be protected with the
   current full outgoing Counter maintained for the particular node
   address.  That outgoing Counter will be included within the security
   section of the message while the incoming Counter will be included
   within the Consistency Check message payload.

   Based on the specified security policy a node MAY apply replay
   protection for a received RPL message.  The replay check MUST be
   performed following the authentication of the received packet.  The
   full Counter, as obtained from the incoming packet or as derived from
   the received Compressed Counter shall be compared against the
   watermark of the incoming Counter maintained for the given
   origination node address.  If the received message Counter value is
   non-zero and less than the maintained incoming Counter watermark a
   potential packet replay is indicated and the node MUST discard the
   incoming packet.

   If delay protection is specified as part of the incoming packet
   security policy checks, the Timestamp Counter is used to validate the
   timeliness of the received RPL message.  If the incoming message
   Timestamp Counter value indicates a message transmission time prior
   to the locally maintained transmission time Counter for the
   originator address, a replay violation is indicated and the node MUST
   discard the incoming packet.  If the received Timestamp Counter value
   indicates a message transmission time that is earlier than the
   Current time less the acceptable packet delay, a delay violation is
   indicated and the node MUST discard the incoming packet.

   Once a message has been decrypted, where applicable, and has
   successfully passed its integrity check, replay, and optionally delay
   protection checks, the node can update its local security
   information, such as the source's expected Counter value for counter
   compression and replay comparison.

   A node MUST NOT update its security information on receipt of a
   message that fails security policy checks or other applied integrity,
   replay, or delay checks.

9.5.2.1.  Timestamp Key Checks

   If the 'T' flag of a message is set and a node has a local timestamp
   that follows the requirements in Section 9.4.1, then a node MAY check
   the temporal consistency of the message.  The node computes the
   transmit time of the message by adding the Counter value to the start



Winter, et al.          Expires December 30, 2010              [Page 75]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   time of the associated key.  If this transmit time is past the end
   time of the key, the node MAY discard the message without further
   processing.  If the transmit time is too far in the past or future
   compared to the local time on the receiver, it MAY discard the
   message without further processing.

9.5.3.  Cryptographic Mode of Operation

   The cryptographic mode of operation used is based on the CCM mode of
   operation and the block-cipher AES-128[RFC3610].  This mode of
   operation is widely supported by existing implementations and
   coincides with the CCM* mode of operation[CCMStar].  CCM mode
   requires a nonce.

9.5.3.1.  Nonce

   A RPL node constructs a CCM nonce as follows:


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                       Source Identifier                       +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Counter                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Reserved | LVL |
       +-+-+-+-+-+-+-+-+


                           Figure 24: CCM* Nonce

   Source Identifier:  8 bytes.  Source Identifier is set to the logical
         identifier of the originator of the protected packet.

   Counter:  4 bytes.  Counter is set to the (uncompressed) value of the
         corresponding field in the Security option of the RPL control
         message.

   Security Level (LVL):  3 bits.  Security Level is set to the value of
         the corresponding field in the Security option of the RPL
         control message.

   Unassigned bits of the nonce are reserved.  They MUST be set to zero
   when constructing the nonce.




Winter, et al.          Expires December 30, 2010              [Page 76]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   All fields of the nonce shall be represented is most-significant-
   octet and most-significant-bit first order.

9.5.3.2.  Signatures

   If the Key Identification Mode (KIM) mode indicates the use of
   signatures (a value of 3), then a node appends a signature to the
   data payload of the packet.  The Security Level (LVL) field describes
   the length of this signature.

   The signature scheme in RPL for Security Mode 00 is an instantiation
   of the ECPVS signature scheme[X9.92].  It uses as an elliptic curve
   the named curve K-283[X9.92].  It uses CCM* mode[CCMStar] as the
   encryption scheme with M=3D0 (as a stream-cipher).  It uses the =
Matyas-
   Meyer-Oseas unkeyed hash function[AppliedCryptography].  It uses the
   key derivation function based on this unkeyed hash function specified
   in Section 5.6.3 of [X9.63-2001], and the message encoding rule of
   Section 7.8 or ANSI X9.92 [X9.92].  PadLen is a non-negative integer
   set to M-OctCurve, where OctCurve is the byte-length of the curve in
   question (with K-283, one has OctCurve=3D36).

   Let 'a' be a concatenation of a six-byte representation of Counter
   and the message header.  The packet payload is a concatenation of
   packet data 'c' and the signature 's'.  This signature scheme is
   invoked with visible and recoverable message parts a and c, whereas
   the signature verification is invoked with as received visible and
   message representative a, c, and with signature s.

9.6.  Coverage of Integrity and Confidentiality

   For a RPL ICMPv6 message, the entire packet is within the scope of
   RPL security.  The message authentication code is calculated over the
   entire IPv6 packet.  This calculation is done before any compression
   that lower layers may apply.  The IPv6 and ICMPv6 headers are never
   encrypted.  The body of the RPL ICMPv6 message MAY be encrypted,
   starting from the first byte after the security section and
   continuing to the end of the packet.














Winter, et al.          Expires December 30, 2010              [Page 77]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


10.  Packet Forwarding and Loop Avoidance/Detection

10.1.  Suggestions for Packet Forwarding

   When forwarding a packet to a destination, precedence is given to
   selection of a next-hop successor as follows:

   1.  This specification only covers how a successor is selected from
       the DODAG version that matches the RPLInstanceID marked in the
       IPv6 header of the packet being forwarded.  Routing outside the
       instance can be done as long as additional rules are put in place
       such as strict ordering of instances and routing protocols to
       protect against loops.
JP> Add: =
"Such rules may be defined in a separate =
document"
   2.  If a local administrative =
preference favors a route that has been
       learned from a different routing protocol than RPL, then use that
       successor.

   3.  If the packet header specifies a source route, then use that
       route [I-D.hui-6man-rpl-routing-header].  
JP> s/specifies a source route/specifies a source route by =
including a RH4 header as specified in =
...
If the node fails to
       forward the packet with that specified source route, then that
       packet SHOULD be dropped.  The node MAY log an error.  The node
       MAY send an ICMPv6 Error in Source Routing Header message to the
       source of the packet Section 18.6.
JP> =
s/Section 18.6/(See Section 18.6)


   4.  If there is an entry in the routing table matching the
       destination that has been learned from a multicast destination
       advertisement (e.g. the destination is a one-hop neighbor), then
       use that successor.

   5.  If there is an entry in the routing table matching the
       destination that has been learned from a unicast destination
       advertisement (e.g. the destination is located down the sub-
       DODAG), then use that successor.  If there are DAO Path Control
       bits associated with multiple successors, then consult the Path
       Control bits to order the successors by preference when choosing.

   6.  If there is a DODAG version offering a route to a prefix matching
       the destination, then select one of those DODAG parents as a
       successor according to the OF and routing metrics.

   7.  Any other as-yet-unattempted DODAG parent may be chosen for the
       next attempt to forward a unicast packet when no better match
       exists.

   8.  Finally the packet is dropped.  ICMP Destination Unreachable may
       be invoked (an inconsistency is detected).

JP>s/may/MAY




Winter, et al.          Expires December 30, 2010              [Page 78]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   TTL must be decremented when forwarding.

JP>s/must/MUST
   Note that =
the chosen successor MUST NOT be the neighbor that was the
   predecessor of the packet (split horizon), except in the case where
   it is intended for the packet to change from an up to an down =
flow,
JP> s/an/a
   such as =
switching from DIO routes to DAO routes as the destination is
   neared.
JP> It may be worh explaining when =
such change (from up to down) may occur
because as =
written it would be sent to a different node (not the =
sender).


10.2.  Loop Avoidance and Detection

   RPL loop avoidance mechanisms are kept simple and designed to
   minimize churn and states.  Loops may form for a number of reasons,
   e.g. control packet loss.  RPL includes a reactive loop detection
   technique that protects from meltdown and triggers repair of broken
   paths.

   RPL loop detection uses information that is placed into the packet.
   A future version of this specification will detail how this
   information is carried with the packet (e.g. a hop-by-hop option
   ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow
   label).  
JP> As discussed, section to be =
updated according to ticket # 64 (insert the RPLInstanceID in flow =
label 
and all other information in the RPL =
option as defined in I-D.ietf-6man-rpl-option =
?)
   For the purpose of RPL operations, the =
information carried
   with a packet is constructed follows:



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |O|R|F|0|0|0|0|0| RPLInstanceID |          SenderRank           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          RPL Packet Information
JP> Figure number is =
missing.
   Down 'O' bit:  1-bit flag =
indicating whether the packet is expected
         to progress up or down.  A router sets the 'O' bit when the
         packet is expect to progress down (using DAO routes), and
         resets it when forwarding towards the root of the DODAG
         version.  
JP> when =
forwarding toward the DODAG root (to a node with a lower =
rank).
A host or RPL leaf node MUST set =
the bit to 0.
JP> s/the bit/the 'O' =
bit
   Rank-Error 'R' bit:  1-bit flag indicating =
whether a rank error was
         detected.  A rank error is detected when there is a mismatch in
         the relative ranks and the direction as indicated in the 'O'
         bit.  A host or RPL leaf node MUST set the bit to 0.

JP> s/the bit/the 'R' =
bit
   Forwarding-Error 'F' bit:  1-bit flag =
indicating that this node can
         not forward the packet further towards the destination.  The
         'F' bit might be set by a child node that does not have a route
         to destination for a packet with the down 'O' bit set.  A host



Winter, et al.          Expires December 30, 2010              [Page 79]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


         or RPL leaf node MUST set the bit to 0.

JP>s/the bit/the 'F' =
bit
   RPLInstanceID:  8-bit field indicating the =
DODAG instance along which
         the packet is sent.

JP> To be updated according to ticket =
#64
   SenderRank:  16-bit field set to zero by the =
source and to
         DAGRank(rank) by a router that forwards inside the RPL network.

10.2.1.  Source Node Operation

   If the source is aware of the RPLInstanceID that is preferred for the
   packet, then it MUST set the RPLInstanceID field associated with the
   packet accordingly, otherwise it MUST set it to the
   RPL_DEFAULT_INSTANCE.

10.2.2.  Router Operation

10.2.2.1.  Instance Forwarding

   Instance IDs 
are used to =
avoid loops between DODAGs from different
   origins.  DODAGs that constructed for antagonistic constraints might
   contain paths that, if mixed together, would yield loops.  Those
   loops are avoided by forwarding a packet along the DODAG that is
   associated to a given instance.

   The RPLInstanceID is associated by the source with the packet.  This
   RPLInstanceID MUST match the RPL Instance onto which the packet is
   placed by any node, be it a host or router.  For traffic originating
   outside of the RPL domain there may be a mapping occurring at the
   gateway 
JP> Do not use "gateway". It is =
called LBR in the terminology ID.
into the RPL =
domain, possibly based on an encoding within the
   flow label.  This aspect of RPL operation is to be clarified in a
   future version of this specification.

JP> in rev-11. See thread on mailing =
list.
   The source of the packet might =
be aware of the RPL network, of the
   constraints imposed on OFs, and of associated Instance IDs. =
 
JP> to be accurate: RPL instance =
IDs.
In that
   case, the source of the packet MAY tag the flow label with the
   RPLInstanceID, in which case it is used in that form within the RPL
   network.

   A router that injects a data packet into the RPL network MUST tag the
   packet by inserting a RPL Hop-by-hop option as specified in
   [I-D.hui-6man-rpl-option].  If the RPLInstanceID is not present in
   flow label of the data packet, the ingress router that injects the
   packet into the RPL network MUST add a RPLInstanceID field to the RPL
   Hop-by-hop option.

   A router that forwards a packet to outside the RPL network MUST
   remove the RPL Hop-by-hop option.



Winter, et al.          Expires December 30, 2010              [Page 80]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   When a router receives a packet that specifies a given RPLInstanceID
   and the node can forward the packet along the DODAG associated to
   that instance, then the router MUST do so and leave the RPLInstanceID
   value unchanged.

   If any node can not forward a packet along the DODAG associated to
   the RPLInstanceID, then the node SHOULD discard the packet and send
   an ICMP error message.
JP> =
Section above to be updated according to resolution of ticket =
#64.
10.2.2.2.  DAG Inconsistency Loop =
Detection

   The DODAG is inconsistent if the direction of a packet does not match
   the rank relationship.  A receiver detects an inconsistency if it
   receives a packet with either:

      the 'O' bit set (to down) from a node of a higher rank.

      the 'O' bit reset (for up) from a node of a lesser rank.

   When the DODAG root increments the DODAGVersionNumber a temporary
   rank discontinuity may form between the next version and the prior
   version, in particular if nodes are adjusting their rank in the next
   version and deferring their migration into the next version.  A
   router that is still a member of the prior version may choose to
   forward a packet to a (future) parent that is in the next version.
   In some cases this could cause the parent to detect an inconsistency
   because the rank-ordering in the prior version is not necessarily the
   same as in the next version and the packet may be judged to not be
   making forward progress.  If the sending router is aware that =
the
  =
 chosen successor has already joined the next version, then =
the
  =
 sending router MUST update the SenderRank to INFINITE_RANK as it
   forwards the packets across the discontinuity into the next DODAG
   version in order to avoid a false detection of rank inconsistency.

   One inconsistency along the path is not considered as a critical
   error and the packet may continue.  But a second detection along the
   path of a same packet should not occur and the packet is dropped.

JP> "is dropped" or "MUST be =
dropped"
   This process is controlled by =
the Rank-Error bit associated with the
   packet.  When an inconsistency is detected on a packet, if the Rank-
   Error bit was not set then the Rank-Error bit is set.  If it was set
   the packet is discarded and the trickle timer is reset.

JP> replace the last "is" by "MUST =
be"
10.2.2.3.  DAO Inconsistency Loop Detection and =
Recovery

   A DAO inconsistency happens when router that has an down =
DAO 
JP>s/an down/a =
down
route
   via a child that is a remnant from an obsolete state that is not
   matched in the child.  With DAO inconsistency loop recovery, a packet



Winter, et al.          Expires December 30, 2010              [Page 81]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   can be used to recursively explore and cleanup the obsolete DAO
   states along a sub-DODAG.

   In a general manner, a packet that goes down should never go up
   again.  If DAO inconsistency loop recovery is applied, then the
   router SHOULD send the packet back to the parent that passed it with
   the Forwarding-Error 'F' bit set and the 'O' bit left untouched.
   Otherwise the router MUST silently discard the packet.

10.2.2.4.  Forward Path Recovery

   Upon receiving a packet with a Forwarding-Error bit set, the node
   MUST remove the routing states that caused forwarding to that
   neighbor, clear the Forwarding-Error bit and attempt to send the
   packet again.  The packet may be sent to an alternate neighbor. =
 
JP> after the expiration of a user configurable timer =
(implementation-specific).
=3D> To avoid a burst of traffic =
should the parent have a number of children that =
used
to advertise the =
prefix.
If
   that alternate neighbor still has an inconsistent DAO state via this
   node, the process will recurse, this node will set the Forwarding-
   Error 'F' bit and the routing state in the alternate neighbor will be
   cleaned up as well.
































Winter, et al.          Expires December 30, 2010              [Page 82]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


11.  Multicast Operation

   This section describes further the multicast routing operations over
   an IPv6 RPL network, and specifically how unicast DAOs can be used to
   relay group registrations up.  Wherever the following text mentions
   Multicast Listener Discovery (MLD), one can read MLDv1 ([RFC2710]) or
   MLDv2 ([RFC3810]).

   Nodes that support the RPL storing mode of operation SHOULD also
   support multicast DAO operations as described below.  Nodes that only
   support the non-storing mode of operation are not expected to support
   this section.

   The multicast operation is controlled by the MOP field in the DIO.

      If the MOP field requires multicast support, then a node that
      joins the RPL network as a router must operate as described in
      this section for multicast signaling and forwarding within the RPL
      network.  A node that does not support the multicast operation
      required by the MOP field can only join as a leaf.

      If the MOP field does not require multicast support, then
      multicast is handled by some other way that is out of scope for
      this specification.  (Examples may include as a series of unicast
      copies or limited-scope flooding)
JP> Add a =
"."

   As is traditional, a listener uses a protocol such as MLD with a
   router to register to a multicast group.

   Along the path between the router and the DODAG root, MLD requests
   are mapped and transported as DAO messages within the RPL =
protocol;
JP> s/the RPL =
protocol/RPL
   each hop coalesces the =
multiple requests for a same group as a single
   DAO message to the parent(s), in a fashion similar to proxy IGMP, but
   recursively between child router and parent up to the root.
JP> s/root/DODAG root
   A router =
might select to pass a listener registration DAO message to
   its preferred parent only, in which case multicast packets coming
   back might be lost for all of its sub-DODAG if the transmission fails
   over that link.  Alternatively the router might select to copy
   additional parents as it would do for DAO messages advertising
   unicast destinations, in which case there might be duplicates that
   the router will need to prune.

   As a result, multicast routing states are installed in each router on
   the way from the listeners to the root, 
JP> Same comment as =
above
enabling the root to copy a
   multicast packet to all its children routers that had issued a DAO
   message including a DAO for that multicast group, as well as all the
   attached nodes that registered over MLD.



Winter, et al.          Expires December 30, 2010              [Page 83]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   For unicast traffic, it is expected that the grounded root of an
   DODAG 
JP> s/root of an DODAG/DODAG =
root

terminates RPL 
JP> I would suggest "Acts as a LBR" instead of =
"terminates RPL"
and MAY redistribute the RPL routes =
over the
   external infrastructure using whatever routing protocol is used in
   the other routing domain.  For multicast traffic, the root MAY proxy
   MLD for all the nodes attached to the RPL domain (this would be
   needed if the multicast source is located in the external
   infrastructure).  For such a source, the packet will be replicated as
   it flows down the DODAG based on the multicast routing table entries
   installed from the DAO message.

   For a source inside the DODAG, the packet 
JP> which packet?
is passed to =
the preferred
   parents, and if that fails then to the alternates in the DODAG.  The
   packet is also copied to all the registered children, except for the
   one that passed the packet.  Finally, if there is a listener in the
   external infrastructure then the DODAG root has to further propagate
   the packet into the external infrastructure.

   As a result, the DODAG Root acts as an automatic proxy Rendezvous
   Point for the RPL network, and as source towards the =
Internet 
JP> s/Internet/non RPL =
domain
for all
   multicast flows started in the RPL LLN. 
JP> s/RPL LLN/RPL =
domain
 So regardless of whether the
   root is actually attached to the Internet, 
JP> Same comment as =
above
and regardless of whether
   the DODAG is grounded or floating, the root can serve inner multicast
   streams at all times.




























Winter, et al.          Expires December 30, 2010              [Page 84]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

JP> See also ticket#66


12.  Maintenance of Routing Adjacency

   The selection of successors, along the default paths up along the
   DODAG, or along the paths learned from destination advertisements
   down along the DODAG, leads to the formation of routing adjacencies
   that require maintenance.

   In IGPs such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of
   a routing adjacency involves the use of Keepalive mechanisms (Hellos)
   or other protocols such as BFD ([RFC5880]) and MANET Neighborhood
   Discovery Protocol (NHDP [I-D.ietf-manet-nhdp]).  Unfortunately, such
   an approach is not desirable in constrained environments such as LLN
   and would lead to excessive control traffic in light of the data
   traffic with a negative impact on both link loads and nodes
   resources.  Overhead to maintain the routing adjacency should be
   minimized.  Furthermore, it is not always possible to rely on the
   link or transport layer to provide information of the associated link
   state.  The network layer needs to fall back on its own mechanism.

   Thus RPL makes use of a different approach consisting of probing the
   neighbor using a Neighbor Solicitation message (see [RFC4861]).  The
   reception of a Neighbor Advertisement (NA) message with the
   "Solicited Flag" set is used to verify the validity of the routing
   adjacency.  Such mechanism MAY be used prior to sending a data
   packet.  This allows for detecting whether or not the routing
   adjacency is still valid, and should it not be the case, select
   another feasible successor to forward the packet.



JP> We can add: "under specific circumstances and =
according to the network resources,
a RPL =
implementation MAY decide to augment this mechanism with Keep-Alive =
messages."






















Winter, et al.          Expires December 30, 2010              [Page 85]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


13.  Guidelines for Objective Functions

   An Objective Function (OF) allows for the selection of a DODAG to
   join, and a number of peers in that DODAG as parents. =
 
JP> Routing metrics and constraints also contribute to =
DODAG parents selection.
The OF is used
   to compute an ordered list of parents.  The OF is also responsible to
   compute the rank of the device within the DODAG version.

   The Objective Function is indicated in the DIO message using an
   Objective Code Point (OCP), and indicates the method that must be
   used to construct the DODAG.  The Objective Code Points are specified
   in [I-D.ietf-roll-of0], and related companion specifications.

13.1.  Objective Function Behavior

   Most Objective Functions are expected to follow the same abstract
   behavior:

   o  The parent selection is triggered each time an event indicates
      that a potential next hop information is updated.  This might
      happen upon the reception of a DIO message, a timer elapse, all
      DODAG parents are unavailable, or a trigger indicating that the
      state of a candidate neighbor has changed.

   o  An OF scans all the interfaces on the device.  Although there may
      typically be only one interface in most application scenarios,
      there might be multiple of them and an interface might be
      configured to be usable or not for RPL operation.  An interface
      can also be configured with a preference or dynamically learned to
      be better than another by some heuristics that might be link-layer
      dependent and are out of scope.  Finally an interface might or not
      match a required criterion for an Objective Function, for instance
      a degree of security.  As a result some interfaces might be
      completely excluded from the computation
JP> Add: "For example if it does not satisfy some =
advertised constraints"
, while others =
might be
      more or less preferred.

   o  An OF scans all the candidate neighbors on the possible interfaces
      to check whether they can act as a router for a DODAG.  There
      might be multiple of them and a candidate neighbor might need to
      pass some validation tests before it can be used.  In particular,
      some link layers require experience on the activity with a router
      to enable the router as a next hop.

   o  An OF computes self's rank by adding to the rank of the candidate
      a value representing the relative locations of self and the
      candidate in the DODAG version.

      *  The increase in rank must be at least MinHopRankIncrease.




Winter, et al.          Expires December 30, 2010              [Page 86]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


      *  To keep loop avoidance and metric optimization in alignment,
         the increase in rank should reflect any increase in the metric
         value.  For example, with a purely additive metric such as ETX,
         the increase in rank can be made proportional to the increase
         in the metric.

      *  Candidate neighbors that would cause self's rank to increase
         are not considered for parent selection

   o  Candidate neighbors that advertise an OF incompatible with the set
      of OF specified by the policy functions are ignored.

   o  As it scans all the candidate neighbors, the OF keeps the current
      best parent and compares its capabilities with the current
      candidate neighbor.  The OF defines a number of tests that are
      critical to reach the objective.  A test between the routers
      determines an order relation.

      *  If the routers are equal for that relation then the next test
         is attempted between the routers,

      *  Else the best of the two routers becomes the current best
         parent and the scan continues with the next candidate neighbor

      *  Some OFs may include a test to compare the ranks that would
         result if the node joined either router

   o  When the scan is complete, the preferred parent is elected and
      self's rank is computed as the preferred parent rank plus the step
      in rank with that parent.

   o  Other rounds of scans might be necessary to elect alternate
      parents.  In the next rounds:

      *  Candidate neighbors that are not in the same DODAG are ignored

      *  Candidate neighbors that are of greater rank than self are
         ignored

      *  Candidate neighbors of an equal rank to self are ignored for
         parent selection

      *  Candidate neighbors of a lesser rank than self are preferred








Winter, et al.          Expires December 30, 2010              [Page 87]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


14.  Suggestions for Interoperation with Neighbor Discovery

   This specification directly borrows the Prefix Information Option
   (PIO) and the Routing Information Option (RIO) from IPv6 ND.  It is
   envisioned that as future specifications build on this base that
   there may be additional cause to leverage parts of IPv6 ND.  This
   section provides some suggestions for future specifications.

   First and foremost RPL is a routing protocol.  One should take great
   care to preserve architecture when mapping functionalities between
   RPL and ND.  RPL is for routing only.  That said, there may be
   persuading technical reasons to allow for sharing options between RPL
   and IPv6 ND in a particular implementation/deployment.

   In general the following guidelines apply:

   o  RPL Type codes must be allocated from the RPL Control Message
      Options registry.

   o  RPL Length fields must be expressed in units of single octets, as
      opposed to ND Length fields which are expressed in units of 8
      octets.

   o  RPL Options are generally not required to be aligned to 8 octet
      boundaries.

   o  When mapping/transposing an IPv6 ND option for redistribution as a
      RPL option, any padding octets should be removed when possible.
      For example, the Prefix Length field in the PIO is sufficient to
      describe the length of the Prefix field.  When mapping/transposing
      a RPL option for redistribution as an IPv6 ND option, any such
      padding octets should be restored.  This procedure must be
      unambiguous.


















Winter, et al.          Expires December 30, 2010              [Page 88]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


15.  RPL Constants and Variables

   Following is a summary of RPL constants and variables:

   BASE_RANK  This is the rank for a virtual root that might be used to
         coordinate multiple roots.  BASE_RANK has a value of 0.

   ROOT_RANK  This is the rank for a DODAG root.  ROOT_RANK has a value
         of MinHopRankIncrease (as advertised by the DODAG root), such
         that DAGRank(ROOT_RANK) is 1.

   INFINITE_RANK  This is the constant maximum for the rank.
         INFINITE_RANK has a value of 0xFFFF.

   RPL_DEFAULT_INSTANCE  This is the RPLInstanceID that is used by this
         protocol by a node without any overriding policy.
         RPL_DEFAULT_INSTANCE has a value of 0.

   DEFAULT_PATH_CONTROL_SIZE  This is the default value used to
         configure PCS in the DODAG Configuration Option, which dictates
         the number of significant bits in the Path Control field of the
         Transit Information option.  DEFAULT_PATH_CONTROL_SIZE has a
         value of 0.  This configures the simplest case-- limiting the

JP> Remove "--"
         =
fan-out to 1 and limiting a node to send a DAO message to only
         one parent.

   DEFAULT_DIO_INTERVAL_MIN  This is the default value used to configure
         Imin for the DIO trickle timer.  DEFAULT_DIO_INTERVAL_MIN has a
         value of 3.  This configuration results in Imin of 8ms.

   DEFAULT_DIO_INTERVAL_DOUBLINGS  This is the default value used to
         configure Imax for the DIO trickle timer.
         DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20.  This
         configuration results in a maximum interval of 2.3 hours.

   DEFAULT_DIO_REDUNDANCY_CONSTANT  This is the default value used to
         configure k for the DIO trickle timer.
         DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10.  This
         configuration is a conservative value for trickle suppression
         mechanism.

   DEFAULT_MIN_HOP_RANK_INCREASE  This is the default value of
         MinHopRankIncrease.  DEFAULT_MIN_HOP_RANK_INCREASE has a value
         of 256.  This configuration results in an 8-bit wide integer
         part of Rank.






Winter, et al.          Expires December 30, 2010              [Page 89]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   DIO Timer  One instance per DODAG that a node is a member of.  Expiry
         triggers DIO message transmission.  Trickle timer with variable
         interval in [0, DIOIntervalMin..2^DIOIntervalDoublings].  See
         Section 7.3.1

   DAG Version Increment Timer  Up to one instance per DODAG that the
         node is acting as DODAG root of.  May not be supported in all
         implementations.  Expiry triggers increment of
         DODAGVersionNumber, causing a new series of updated DIO message
         to be sent.  Interval should be chosen appropriate to
         propagation time of DODAG and as appropriate to application
         requirements (e.g. response time vs. overhead).

   DelayDAO Timer  Up to one instance 
JP> =
s/instance/timer
per DAO parent (the subset of
         DODAG parents chosen to receive destination advertisements) per
         DODAG.  Expiry triggers sending of DAO message to the DAO
         parent.  See Section 8.4

   RemoveTimer  Up to one instance 
JP> Same =
comment as above
per DAO entry per neighbor (i.e.
         those neighbors that have given DAO messages to this node as a
         DODAG parent) Expiry triggers a change in state for the DAO
         entry, setting up to do unreachable (No-Path) advertisements or
         immediately deallocating the DAO entry if there are no DAO
         parents.

JP> Suggest rewording the last =
sentence a bit.




























Winter, et al.          Expires December 30, 2010              [Page 90]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


16.  Manageability Considerations

JP> Will =
skip that section - See separate email related to Ticket =
#63


   The aim of this section is to give consideration to the manageability
   of RPL, and how RPL will be operated in a LLN.  The scope of this
   section is to consider the following aspects of manageability:
   configuration, monitoring, fault management, accounting, and
   performance of the protocol in light of the recommendations set forth
   in [RFC5706].

16.1.  Introduction

   Most of the existing IETF management standards are Structure of
   Management Information (SMI) based data models (MIB modules) to
   monitor and manage networking devices.

   For a number of protocols, the IETF community has used the IETF
   Standard Management Framework, including the Simple Network
   Management Protocol [RFC3410], the Structure of Management
   Information [RFC2578], and MIB data models for managing new
   protocols.

   As pointed out in [RFC5706], the common policy in terms of operation
   and management has been expanded to a policy that is more open to a
   set of tools and management protocols rather than strictly relying on
   a single protocol such as SNMP.

   In 2003, the Internet Architecture Board (IAB) held a workshop on
   Network Management [RFC3535] that discussed the strengths and
   weaknesses of some IETF network management protocols and compared
   them to operational needs, especially configuration.

   One issue discussed was the user-unfriendliness of the binary format
   of SNMP [RFC3410].  In the case of LLNs, it must be noted that at the
   time of writing, the CoRE Working Group is actively working on
   resource management of devices in LLNs.  Still, it is felt that this
   section provides important guidance on how RPL should be deployed,
   operated, and managed.

   As stated in [RFC5706], "A management information model should
   include a discussion of what is manageable, which aspects of the
   protocol need to be configured, what types of operations are allowed,
   what protocol-specific events might occur, which events can be
   counted, and for which events an operator should be notified".  These
   aspects are discussed in detail in the following sections.

   RPL will be used on a variety of devices that may have resources such
   as memory varying from a very few Kbytes to several hundreds of
   Kbytes and even Mbytes.  When memory is highly constrained, it may



Winter, et al.          Expires December 30, 2010              [Page 91]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   not be possible to satisfy all the requirements listed in this
   section.  Still it is worth listing all of these in an exhaustive
   fashion, and implementers will then determine which of these
   requirements could be satisfied according to the available resources
   on the device.

16.2.  Configuration Management

16.2.1.  Initialization Mode

   "Architectural Principles of the Internet" [RFC1958], Section 3.8,
   states: "Avoid options and parameters whenever possible.  Any options
   and parameters should be configured or negotiated dynamically rather
   than manually.  This especially true in LLNs where the number of
   devices may be large and manual configuration is infeasible.  This
   has been taken into account in the design of RPL whereby the DODAG
   root provides a number of parameters to the devices joining the
   DODAG, thus avoiding cumbersome configuration on the routers and
   potential sources of misconfiguration (e.g. values of trickle timers,
   ...).  Still there are additional RPL parameters that a RPL
   implementation should allow to be configured, which are discussed in
   this section.

16.2.1.1.  DIS mode of operation upon boot-up

   When a node is first powered up:

   1.  The node may decide to stay silent, waiting to receive DIO
       messages from DODAG of interest (advertising a supported OF and
       metrics/constraints) and not send any multicast DIO messages
       until it has joined a DODAG.

   2.  The node may decide to send one or more DIS messages (optionally
       requesting DIO for a specific DODAG) message as an initial probe
       for nearby DODAGs, and in the absence of DIO messages in reply
       after some configurable period of time, the node may decide to
       root a floating DODAG and start sending multicast DIO messages.

   A RPL implementation SHOULD allow configuring the preferred mode of
   operation listed above along with the required parameters (in the
   second mode: the number of DIS messages and related timer).

16.2.2.  DIO and DAO Base Message and Options Configuration

   RPL specifies a number of protocol parameters considering the large
   spectrum of applications where it will be used.  That said,
   particular attention has been given to limiting the number of these
   parameters that must be configured on each RPL router.  Instead, a



Winter, et al.          Expires December 30, 2010              [Page 92]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   number of the default values can be used, and when required these
   parameters can be provided by the DODAG root thus allowing for
   dynamic parameter setting.

   A RPL implementation SHOULD allow configuring the following routing
   protocol parameters.  As pointed out above, note that a large set of
   parameters is configured on the DODAG root.

16.2.3.  Protocol Parameters to be configured on every router in the LLN

   o  RPLInstanceID [DIO message, in DIO base message].  Although the
      RPLInstanceID must be configured on the DODAG root, it must also
      be configured as a policy on every node in order to determine
      whether or not the node should join a particular DODAG.  Note that
      a second RPLInstance can be configured on the node, should it
      become root of a floating DODAG.

   o  Objective Code Point (OCP)

   o  List of supported metrics: [I-D.ietf-roll-routing-metrics]
      specifies a number of metrics and constraints used for the DODAG
      formation.  Thus a RPL implementation should allow configuring the
      list of metrics that a node can accept and understand.  If a DIO
      is received with a metric and/or constraint that is not understood
      or supported, as specified in Section 7.5, the node would join as
      a leaf node.

   o  DODAGID [DIO, DIO base option] and [DAO message when the D flag of
      the DAO message is set).

   o  Route Information (and preference) [DIO message, in Route
      Information option]

   o  Solicited Information [DIS message, in Solicited Information
      option].  Note that an RPL implementation SHOULD allow configuring
      when such messages should be sent and under which circumstances,
      along with the value of the RPLInstance ID, V/I/D flags.

   o  K flag [DAO message, in DAO base message].

   o  MOP (Mode of Operation) [DIO message, in DIO base message]

16.2.4.  Protocol Parameters to be configured on every non-root router
         in the LLN

   o  Target prefix [DAO, in RPL Target option and DIO messages]





Winter, et al.          Expires December 30, 2010              [Page 93]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  Transit information [DAO, Transit information option]: A RPL
      implementation SHOULD allow configuring whether a non-storing node
      provides the transit information in DAO messages.

   A node whose DODAG parent set is empty may become the DODAG root of a
   floating DODAG.  It may also set its DAGPreference such that it is
   less preferred.  Thus a RPL implementation MUST allow configuring the
   set of actions that the node should initiate in this case:

   o  Start its own (floating) DODAG: the new DODAGID must be configured
      in addition to its DAGPreference

   o  Poison the broken path (see procedure in Section 7.2.2.5)

   o  Trigger a local repair

16.2.5.  Parameters to be configured on the DODAG root

   In addition, several other parameters are configured only on the
   DODAG root and advertised in options carried in DIO messages.

   As specified in Section 7.3, a RPL implementation makes use of
   trickle timers to govern the sending of DIO messages.  The operation
   of the trickle algorithm is determined by a set of configurable
   parameters, which MUST be configurable and that are then advertised
   by the DODAG root along the DODAG in DIO messages.

   o  DIOIntervalDoublings [DIO, in DODAG configuration option]

   o  DIOIntervalMin [DIO, in DODAG configuration option]

   o  DIORedundancyConstant [DIO, in DODAG configuration option]

   In addition, a RPL implementation SHOULD allow for configuring the
   following set of RPL parameters:

   o  Path Control Size [DIO, in DODAG configuration option]

   o  MinHopRankIncrease [DIO, in DODAG configuration option]

   o  The following fields: MOP (Mode of Operation), DODAGPreference
      field [DIO message, DIO Base object]

   o  Route information (list of prefixes with preference) [DIO message,
      in Route Information option]

   o  The T flag allows for triggering a refresh of the downward routes.
      A RPL implementation SHOULD support manual setting of the T flag



Winter, et al.          Expires December 30, 2010              [Page 94]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


      or upon the occurrence of a set of event such as the expiration of
      a configurable periodic timer.

   o  List of metrics and constraints used for the DODAG.

   o  Prefix information along with valid and preferred lifetime and the
      L and A flags.  [DIO message, Prefix Information option].  A RPL
      implementation SHOULD allow configuring if the Prefix Information
      Option must be carried with the DIO message to distribute the
      prefix information for auto-configuration.  In that case, the RPL
      implementation MUST allow the list of prefixes to be advertised in
      the Prefix Information Option along with the corresponding flags.

   DAG Root behavior: in some cases, a node may not want to permanently
   act as a floating DODAG root if it cannot join a grounded DODAG.  For
   example a battery-operated node may not want to act as a floating
   DODAG root for a long period of time.  Thus a RPL implementation MAY
   support the ability to configure whether or not a node could act as a
   floating DODAG root for a configured period of time.

   DAG Version Number Increment: a RPL implementation may allow by
   configuration at the DODAG root to refresh the DODAG states by
   updating the DODAGVersionNumber.  A RPL implementation SHOULD allow
   configuring whether or not periodic or event triggered mechanisms are
   used by the DODAG root to control DODAGVersionNumber change (which
   triggers a global repair as specified in Section 3.3.2.

16.2.6.  Configuration of RPL Parameters related to DAO-based mechanisms

   DAO messages are optional and used in DODAGs that require downward
   routing operation.  This section deals with the set of parameters
   related to DAO message and provides recommendations on their
   configuration.

   An implementation SHOULD bound the time that the entry is allocated
   in the UNREACHABLE state.  Upon the equivalent expiry of the related
   timer (RemoveTimer), the entry SHOULD be suppressed.  Thus a RPL
   implementation MAY allow for the configuration of the RemoveTimer.

   While the entry is in the UNREACHABLE state a node SHOULD make a
   reasonable attempt to report a No-Path to each of the DAO parents.
   That number of attempts MAY be configurable.

   When the associated Retry Counter for a REACHABLE(Pending) entry
   reaches a maximum threshold, the entry is placed into the UNREACHABLE
   state and No-Path should be scheduled to send to the node's DAO
   Parents.  The maximum threshold MAY be configurable.




Winter, et al.          Expires December 30, 2010              [Page 95]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   An implementation should support rate-limiting the sending of DAO
   messages.  The related parameters MAY be configurable.

   When scheduling to send a DAO, an implementation should equivalently
   start a timer (DelayDAO) to delay sending the DAO, thus helping to
   potentially aggregate DAOs.  The DelayDAO timer MAY be configurable.

16.2.7.  Default Values

   This document specifies default values for the following set of RPL
   variables:
      DEFAULT_PATH_CONTROL_SIZE
      DEFAULT_DIO_INTERVAL_MIN
      DEFAULT_DIO_INTERVAL_DOUBLINGS
      DEFAULT_DIO_REDUNDANCY_CONSTANT
      DEFAULT_MIN_HOP_RANK_INCREASE

   It is recommended to specify default values in protocols; that being
   said, as discussed in [RFC5706], default values may make less and
   less sense.  RPL is a routing protocol that is expected to be used in
   a number of contexts where network characteristics such as the number
   of nodes, link and nodes types are expected to vary significantly.
   Thus, these default values are likely to change with the context and
   as the technology will evolve.  Indeed, LLNs' related technology
   (e.g. hardware, link layers) have been evolving dramatically over the
   past few years and such technologies are expected to change and
   evolve considerably in the coming years.

   The proposed values are not based on extensive best current practices
   and are considered to be conservative.

16.3.  Monitoring of RPL Operation

   Several RPL parameters should be monitored to verify the correct
   operation of the routing protocol and the network itself.  This
   section lists the set of monitoring parameters of interest.

16.3.1.  Monitoring a DODAG parameters

   A RPL implementation SHOULD provide information about the following
   parameters:

   o  DODAG Version number [DIO message, in DIO base message]

   o  Status of the G flag [DIO message, in DIO base message]

   o  Status of the MOP field [DIO message, in DIO base message]




Winter, et al.          Expires December 30, 2010              [Page 96]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  Value of the DTSN [DIO message, in DIO base message]

   o  Value of the rank [DIO message, in DIO base message]

   o  DAOSequence: Incremented at each unique DAO message, echoed in the
      DAO-ACK message [DAO and DAO-ACK messages]

   o  Route Information [DIO message, Route Information option] (list of
      IPv6 prefixes per parent along with lifetime and preference]

   o  Trickle parameters:

      *  DIOIntervalDoublings [DIO, in DODAG configuration option]

      *  DIOIntervalMin [DIO, in DODAG configuration option]

      *  DIORedundancyConstant [DIO, in DODAG configuration option]

   o  Path Control Size [DIO, in DODAG configuration option]

   o  MinHopRankIncrease [DIO, in DODAG configuration option]

   Values that may be monitored only on the DODAG root

   o  Transit Information [DAO, Transit Information option]: A RPL
      implementation SHOULD allow configuring whether the set of
      received Transit Information options should be displayed on the
      DODAG root.  In this case, the RPL database of received Transit
      Information should also contain: the path-sequence, path control,
      path lifetime and parent address.

16.3.2.  Monitoring a DODAG inconsistencies and loop detection

   Detection of DODAG inconsistencies is particularly critical in RPL
   networks.  Thus it is recommended for a RPL implementation to provide
   appropriate monitoring tools.  A RPL implementation SHOULD provide a
   counter reporting the number of a times the node has detected an
   inconsistency with respect to a DODAG parent, e.g. if the DODAGID has
   changed.

   When possible more granular information about inconsistency detection
   should be provided.  A RPL implementation MAY provide counters
   reporting the number of following inconsistencies:

   o  Packets received with O bit set (to down) from a node with a
      higher rank





Winter, et al.          Expires December 30, 2010              [Page 97]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  Packets received with O bit reset (to up) from a node with a lower
      rank

   o  Number of packets with the F bit set

   o  Number of packets with the R bit set

16.4.  Monitoring of the RPL data structures

16.4.1.  Candidate Neighbor Data Structure

   A node in the candidate neighbor list is a node discovered by the
   some means and qualified to potentially become a parent (with high
   enough local confidence).  A RPL implementation SHOULD provide a way
   to monitor the candidate neighbor list with some metric reflecting
   local confidence (the degree of stability of the neighbors) as
   measured by some metrics.

   A RPL implementation MAY provide a counter reporting the number of
   times a candidate neighbor has been ignored, should the number of
   candidate neighbors exceeds the maximum authorized value.

16.4.2.  Destination Oriented Directed Acyclic Graph (DAG) Table

   For each DODAG, a RPL implementation is expected to keep track of the
   following DODAG table values:

   o  RPLInstanceID

   o  DODAGID

   o  DODAGVersionNumber

   o  Rank

   o  Objective Code Point

   o  A set of DODAG Parents

   o  A set of prefixes offered upwards along the DODAG

   o  Trickle timers used to govern the sending of DIO messages for the
      DODAG

   o  List of DAO parents

   o  DTSN




Winter, et al.          Expires December 30, 2010              [Page 98]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  Node status (router versus leaf)

   A RPL implementation SHOULD allow for monitoring the set of
   parameters listed above.

16.4.3.  Routing Table and DAO Routing Entries

   A RPL implementation maintains several information elements related
   to the DODAG and the DAO entries (for storing nodes).  In the case of
   a non storing node, a limited amount of information is maintained
   (the routing table is mostly reduced to a set of DODAG parents along
   with characteristics of the DODAG as mentioned above) whereas in the
   case of storing nodes, this information is augmented with routing
   entries.

   A RPL implementation SHOULD provide the ability to monitor the
   following parameters:

   o  Next Hop (DODAG parent)

   o  Next Hop Interface

   o  Path metrics value for each DODAG parent

   A DAO Routing Table Entry conceptually contains the following
   elements (for storing nodes only):

   o  Advertising Neighbor Information

   o  IPv6 Address

   o  Interface ID to which DAO Parents has this entry been reported

   o  Retry Counter

   o  Logical equivalent of DAO Content:

      *  DAO Sequence

      *  DAO Lifetime

      *  DAO Path Control

   o  Destination Prefix (or Address or Mcast Group)

   A RPL implementation SHOULD provide information about the state of
   each DAO Routing Table entry states.




Winter, et al.          Expires December 30, 2010              [Page 99]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


16.5.  Fault Management

   Fault management is a critical component used for troubleshooting,
   verification of the correct mode of operation of the protocol,
   network design, and is also a key component of network performance
   monitoring.  A RPL implementation SHOULD allow providing the
   following information related to fault managements:

   o  Memory overflow along with the cause (e.g. routing tables
      overflow, ...)

   o  Number of times a packet could not be sent to a DODAG parent
      flagged as valid

   o  Number of times a packet has been received for which the router
      did not have a corresponding RPLInstanceID

   o  Number of times a local repair procedure was triggered

   o  Number of times a global repair was triggered by the DODAG root

   o  Number of received malformed messages

   o  Number of seconds with packets to forward and no next hop (DODAG
      parent)

   o  Number of seconds without next hop (DODAG parent)

   o  Number of times a node has joined a DODAG as a leaf because it
      received a DIO with metric/constraint not understood and it was
      configured to join as a leaf node in this case (see Section 16.6).

   It is RECOMMENDED to report faults via at least error log messages.
   Other protocols may be used to report such faults.

16.6.  Policy

   Policy rules can be used by a RPL implementation to determine whether
   or not the node is allowed to join a particular DODAG advertised by a
   neighbor by means of DIO messages.

   This document specifies operation within a single DODAG.  A DODAG is
   characterized by the following tuple (RPLInstanceID, DODAGID).
   Furthermore, as pointed out above, DIO messages are used to advertise
   other DODAG characteristics such as the routing metrics and
   constraints used to build to the DODAG and the Objective Function in
   use (specified by OCP).




Winter, et al.          Expires December 30, 2010             [Page 100]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   The first policy rules consists of specifying the following
   conditions that a RPL node must satisfy to join a DODAG:

   o  RPLInstanceID

   o  DODAGID

   o  List of supported routing metrics and constraints

   o  Objective Function (OCP values)

   A RPL implementation MUST allow configuring these parameters and
   SHOULD specify whether the node must simply ignore the DIO if the
   advertised DODAG is not compliant with the local policy or whether
   the node should join as the leaf node if only the list of supported
   routing metrics and constraints, and the OF is not supported.

   A RPL implementation SHOULD allow configuring the set of acceptable
   or preferred Objective Functions (OF) referenced by their Objective
   Codepoints (OCPs) for a node to join a DODAG, and what action should
   be taken if none of a node's candidate neighbors advertise one of the
   configured allowable Objective Functions, or if the advertised
   metrics/constraint is not understood/supported.  Two actions can be
   taken in this case:

   o  The node joins the DODAG as a leaf node as specified in
      Section 7.5

   o  The node does not join the DODAG

   A node in an LLN may learn routing information from different routing
   protocols including RPL.  It is in this case desirable to control via
   administrative preference which route should be favored.  An
   implementation SHOULD allow for specifying an administrative
   preference for the routing protocol from which the route was learned.

   Internal Data Structures: some RPL implementations may limit the size
   of the candidate neighbor list in order to bound the memory usage, in
   which case some otherwise viable candidate neighbors may not be
   considered and simply dropped from the candidate neighbor list.

   A RPL implementation MAY provide an indicator on the size of the
   candidate neighbor list.

16.7.  Liveness Detection and Monitoring

   By contrast with several other routing protocols, RPL does not define
   any 'keep-alive' mechanisms to detect routing adjacency failure: this



Winter, et al.          Expires December 30, 2010             [Page 101]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   is in most cases, because such a mechanism may be too expensive in
   terms of bandwidth and even more importantly energy (a battery
   operated device could not afford to send periodic Keep alive).  Still
   RPL requires mechanisms to detect that a neighbor is no longer
   reachable: this can be performed by using mechanisms such as NUD
   (Neighbor Unreachability Detection) or even some form of Keep-alive
   that are outside of this document.

16.8.  Fault Isolation

   It is RECOMMENDED to quarantine neighbors that start emitting
   malformed messages at unacceptable rates.

16.9.  Impact on Other Protocols

   RPL has very limited impact on other protocols.  Where more than one
   routing protocol is required on a router such as a LBR, it is
   expected for the device to support routing redistribution functions
   between the routing protocols to allow for reachability between the
   two routing domains.  Such redistribution SHOULD be governed by the
   use of user configurable policy.

   With regards to the impact in terms of traffic on the network, RPL
   has been designed to limit the control traffic thanks to mechanisms
   such as Trickle timers (Section 7.3).  Thus the impact of RPL on
   other protocols should be extremely limited.

16.10.  Performance Management

   Performance management is always an important aspect of a protocol
   and RPL is not an exception.  Several metrics of interest have been
   specified by the IP Performance Monitoring (IPPM) Working Group: that
   being said, they will be hardly applicable to LLN considering the
   cost of monitoring these metrics in terms of resources on the devices
   and required bandwidth.  Still, RPL implementation MAY support some
   of these, and other parameters of interest are listed below:

   o  Number of repairs and time to repair in seconds (average,
      variance)

   o  Number of times and duration during which a devices could not
      forward a packet because of a lack of reachable neighbor in its
      routing table

   o  Monitoring of resources consumption by RPL itself in terms of
      bandwidth and required memory





Winter, et al.          Expires December 30, 2010             [Page 102]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   o  Number of RPL control messages sent and received


















































Winter, et al.          Expires December 30, 2010             [Page 103]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


17.  Security Considerations

17.1.  Overview

   =46rom a security perspective, RPL networks are no different from any
   other network.  They are vulnerable to passive eavesdropping attacks
   and potentially even active tampering when physical access to a wire
   is not required to participate in communications.  The very nature of
   ad hoc networks and their cost objectives impose additional security
   constraints, which perhaps make these networks the most difficult
   environments to secure.  Devices are low-cost and have limited
   capabilities in terms of computing power, available storage, and
   power drain; and it cannot always be assumed they have neither a
   trusted computing base nor a high-quality random number generator
   aboard.  Communications cannot rely on the online availability of a
   fixed infrastructure and might involve short-term relationships
   between devices that may never have communicated before.  These
   constraints might severely limit the choice of cryptographic
   algorithms and protocols and influence the design of the security
   architecture because the establishment and maintenance of trust
   relationships between devices need to be addressed with care.  In
   addition, battery lifetime and cost constraints put severe limits on
   the security overhead these networks can tolerate, something that is
   of far less concern with higher bandwidth networks.  Most of these
   security architectural elements can be implemented at higher layers
   and may, therefore, be considered to be outside the scope of this
   standard.  Special care, however, needs to be exercised with respect
   to interfaces to these higher layers.

   The security mechanisms in this standard are based on symmetric-key
   and public-key cryptography and use keys that are to be provided by
   higher layer processes.  The establishment and maintenance of these
   keys are outside the scope of this standard.  The mechanisms assume a
   secure implementation of cryptographic operations and secure and
   authentic storage of keying material.

   The security mechanisms specified provide particular combinations of
   the following security services:

   Data confidentiality:  Assurance that transmitted information is only
               disclosed to parties for which it is intended.

   Data authenticity:  Assurance of the source of transmitted
               information (and, hereby, that information was not
               modified in transit).






Winter, et al.          Expires December 30, 2010             [Page 104]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Replay protection:  Assurance that a duplicate of transmitted
               information is detected.

   Timeliness (delay protection):  Assurance that transmitted
               information was received in a timely manner.

   The actual protection provided can be adapted on a per-packet basis
   and allows for varying levels of data authenticity (to minimize
   security overhead in transmitted packets where required) and for
   optional data confidentiality.  When nontrivial protection is
   required, replay protection is always provided.

   Replay protection is provided via the use of a non-repeating value
   (nonce) in the packet protection process and storage of some status
   information for each originating device on the receiving device,
   which allows detection of whether this particular nonce value was
   used previously by the originating device.  In addition, so-called
   delay protection is provided amongst those devices that have a
   loosely synchronized clock on board.  The acceptable time delay can
   be adapted on a per-packet basis and allows for varying latencies (to
   facilitate longer latencies in packets transmitted over a multi-hop
   communication path).

   Cryptographic protection may use a key shared between two peer
   devices (link key) or a key shared among a group of devices (group
   key), thus allowing some flexibility and application-specific
   tradeoffs between key storage and key maintenance costs versus the
   cryptographic protection provided.  If a group key is used for peer-
   to-peer communication, protection is provided only against outsider
   devices and not against potential malicious devices in the key-
   sharing group.

   Data authenticity may be provided using symmetric-key based or
   public-key based techniques.  With public-key based techniques (via
   signatures), one corroborates evidence as to the unique originator of
   transmitted information, whereas with symmetric-key based techniques
   data authenticity is only provided relative to devices in a key-
   sharing group.  Thus, public-key based authentication may be useful
   in scenarios that require a more fine-grained authentication than can
   be provided with symmetric-key based authentication techniques alone,
   such as with group communications (broadcast, multicast), or in
   scenarios that require non-repudiation.









Winter, et al.          Expires December 30, 2010             [Page 105]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


18.  IANA Considerations

18.1.  RPL Control Message

   The RPL Control Message is an ICMP information message type that is
   to be used carry DODAG Information Objects, DODAG Information
   Solicitations, and Destination Advertisement Objects in support of
   RPL operation.

   IANA has defined an ICMPv6 Type Number Registry.  The suggested type
   value for the RPL Control Message is 155, to be confirmed by IANA.

18.2.  New Registry for RPL Control Codes

   IANA is requested to create a registry, RPL Control Codes, for the
   Code field of the ICMPv6 RPL Control Message.

   New codes may be allocated only by an IETF Consensus action.  Each
   code should be tracked with the following qualities:

   o  Code

   o  Description

   o  Defining RFC

   Three codes are currently defined:

   +------+----------------------------------------------+-------------+
   | Code | Description                                  | Reference   |
   +------+----------------------------------------------+-------------+
   | 0x00 | DODAG Information Solicitation               | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x01 | DODAG Information Object                     | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x02 | Destination Advertisement Object             | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x03 | Destination Advertisement Object             | This        |
   |      | Acknowledgment                               | document    |
   |      |                                              |             |
   | 0x80 | Secure DODAG Information Solicitation        | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x81 | Secure DODAG Information Object              | This        |
   |      |                                              | document    |



Winter, et al.          Expires December 30, 2010             [Page 106]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   | 0x82 | Secure Destination Advertisement Object      | This        |
   |      |                                              | document    |
   |      |                                              |             |
   | 0x83 | Secure Destination Advertisement Object      | This        |
   |      | Acknowledgment                               | document    |
   +------+----------------------------------------------+-------------+

                             RPL Control Codes

18.3.  New Registry for the Mode of Operation (MOP) DIO Control Field

   IANA is requested to create a registry for the Mode of Operation
   (MOP) DIO Control Field, which is contained in the DIO Base.

   New fields may be allocated only by an IETF Consensus action.  Each
   field should be tracked with the following qualities:

   o  Mode of Operation

   o  Capability description

   o  Defining RFC

   Three values are currently defined:

   +-----+----------------------------------------------+--------------+
   | MOP | Description                                  | Reference    |
   +-----+----------------------------------------------+--------------+
   | 000 | No downward routes maintained by RPL         | This         |
   |     |                                              | document     |
   |     |                                              |              |
   | 001 | Non-Storing mode of operation                | This         |
   |     |                                              | document     |
   |     |                                              |              |
   | 010 | Storing mode of operation with no multicast  | This         |
   |     | support                                      | document     |
   |     |                                              |              |
   | 011 | Storing mode of operation with multicast     | This         |
   |     | support                                      | document     |
   +-----+----------------------------------------------+--------------+

                              DIO Base Flags

18.4.  RPL Control Message Option

   IANA is requested to create a registry for the RPL Control Message
   Options




Winter, et al.          Expires December 30, 2010             [Page 107]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


             +-------+-----------------------+---------------+
             | Value | Meaning               | Reference     |
             +-------+-----------------------+---------------+
             |   0   | Pad1                  | This document |
             |       |                       |               |
             |   1   | PadN                  | This document |
             |       |                       |               |
             |   2   | DAG Metric Container  | This Document |
             |       |                       |               |
             |   3   | Routing Information   | This Document |
             |       |                       |               |
             |   4   | DODAG Configuration   | This Document |
             |       |                       |               |
             |   5   | RPL Target            | This Document |
             |       |                       |               |
             |   6   | Transit Information   | This Document |
             |       |                       |               |
             |   7   | Solicited Information | This Document |
             |       |                       |               |
             |   8   | Prefix Information    | This Document |
             +-------+-----------------------+---------------+

                        RPL Control Message Options

18.5.  Objective Code Point (OCP) Registry

   IANA is requested to create a registry to manage the codespace of the
   Objective Code Point (OCP) field.

   No OCP codepoints are defined in this specification.

18.6.  ICMPv6: Error in Source Routing Header

   In some cases RPL will return an ICMPv6 error message when a message
   cannot be delivered as specified by its source routing header.  This
   ICMPv6 error message is "Error in Source Routing Header"
JP> "." missing


   IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
   Types.  ICMPv6 Message Type 1 describes "Destination Unreachable"
   codes.  The "Error in Source Routing Header" code is suggested to be
   allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message
   Type 1, with a suggested code value of 7, to be confirmed by IANA.

18.7.  Link-Local Scope multicast address

   The rules for assigning new IPv6 multicast addresses are defined in
   [RFC3307].  This specification requires the allocation of a new
   permanent multicast address with a link local scope for RPL routers,



Winter, et al.          Expires December 30, 2010             [Page 108]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   with a suggested value of FF02::1:A, to be confirmed by IANA.


















































Winter, et al.          Expires December 30, 2010             [Page 109]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


19.  Acknowledgements

   The authors would like to acknowledge the review, feedback, and
   comments from Roger Alexander, Emmanuel Baccelli, Dominique Barthel,
   Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Mischa Dohler,
   Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi,
   Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Quentin
   Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph
   Reddy, Don Sturek, Joydeep Tripathi, and Nicolas Tsiftes.

   The authors would like to acknowledge the guidance and input provided
   by the ROLL Chairs, David Culler and JP Vasseur.

   The authors would like to acknowledge prior contributions of Robert
   Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
   Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
   Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
   Jim Bound, Yanick Pouffary, Henning Rogge and Arsalan Tavakoli, whom
   have provided useful design considerations to RPL.

   RPL Security Design, found in Section 9, Section 17, and elsewhere
   throughout the document, is primarily the contribution of the
   Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip
   Levis, Kris Pister, and Rene Struik.



























Winter, et al.          Expires December 30, 2010             [Page 110]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


20.  Contributors

   RPL is the result of the contribution of the following members of the
   RPL Author Team, including the editors, and additional contributors
   as listed below:

   JP Vasseur
   Cisco Systems, Inc
   11, Rue Camille Desmoulins
   Issy Les Moulineaux,   92782
   France

   Email: jpv@cisco.com


   Thomas Heide Clausen
   LIX, Ecole Polytechnique, France

   Phone: +33 6 6058 9349
   EMail: T.Clausen@computer.org
   URI:   http://www.ThomasClausen.org/


   Philip Levis
   Stanford University
   358 Gates Hall, Stanford University
   Stanford, CA  94305-9030
   USA

   Email: pal@cs.stanford.edu


   Richard Kelsey
   Ember Corporation
   Boston, MA
   USA

   Phone: +1 617 951 1225
   Email: kelsey@ember.com


   Jonathan W. Hui
   Arch Rock Corporation
   501 2nd St. Ste. 410
   San Francisco, CA  94107
   USA

   Email: jhui@archrock.com



Winter, et al.          Expires December 30, 2010             [Page 111]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   Kris Pister
   Dust Networks
   30695 Huntwood Ave.
   Hayward,   94544
   USA

   Email: kpister@dustnetworks.com


   Anders Brandt
   Sigma Designs
   Emdrupvej 26A, 1.
   Copenhagen, DK-2100
   Denmark

   Email: abr@sdesigns.dk


   R. Struik

   Email: rstruik.ext@gmail.com


   Stephen Dawson-Haggerty
   UC Berkeley
   Soda Hall, UC Berkeley
   Berkeley, CA  94720
   USA

   Email: stevedh@cs.berkeley.edu





















Winter, et al.          Expires December 30, 2010             [Page 112]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


21.  References

21.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

21.2.  Informative References

   [AppliedCryptography]
              Menzes, AJ., van Oorschot, PC., and SA. Vanstone,
              "Handbook of Applied Cryptography", CRC Press , 1997.

   [CCMStar]  IEEE, "IEEE Std. 802.15.4-2006, IEEE Standard for
              Information Technology - Telecommunications and
              Information Exchange between Systems - Local and
              Metropolitan Area Networks - Specific requirements Part
              15.4: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Low-Rate Wireless Personal
              Area Networks (WPANs)", IEEE Press Revision of IEEE Std
              802.15.4-2003, 2006.

   [I-D.hui-6man-rpl-option]
              Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
              Information in Data-Plane Datagrams",
              draft-hui-6man-rpl-option-01 (work in progress),
              June 2010.

JP> Above =
reference must be normative


   [I-D.hui-6man-rpl-routing-header]
              Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing
              Header for Source Routes with RPL",
              draft-hui-6man-rpl-routing-header-02 (work in progress),
              June 2010.
JP> Above reference must be =
normative
   =
[I-D.ietf-manet-nhdp]
              =
Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
              Network (MANET) Neighborhood Discovery Protocol (NHDP)",
              draft-ietf-manet-nhdp-12 (work in progress), March 2010.

   [I-D.ietf-roll-of0]
              Thubert, P., "RPL Objective Function 0",
              draft-ietf-roll-of0-02 (work in progress), June 2010.

   [I-D.ietf-roll-routing-metrics]
              Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing
              Metrics used for Path Calculation in Low Power and Lossy
              Networks", draft-ietf-roll-routing-metrics-07 (work in
              progress), June 2010.


JP> Above reference must be =
normative
JP> Above reference must be =
normative

   [Perlman83]
              Perlman, R., "Fault-Tolerant Broadcast of Routing
              Information", North-Holland Computer Networks 7: 395-405,
              1983, <http://www.cs.=
illinois.edu/~pbg/courses/cs598fa09/
              readings/p83.pdf>.

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3307]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
              Addresses", RFC 3307, August 2002.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [RFC3535]  Schoenwaelder, J., "Overview of the 2002 IAB Network
              Management Workshop", RFC 3535, May 2003.

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, September 2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.



Winter, et al.          Expires December 30, 2010             [Page 114]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, July 2004.

   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
              June 2005.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, June 2007.

   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions",
              RFC 5706, November 2009.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.




Winter, et al.          Expires December 30, 2010             [Page 115]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [X9.63-2001]
              "ANSI X9.63-2001, Public Key Cryptography for the
              Financial Services Industry - Key Agreement and Key
              Transport Using Elliptic Curve Cryptography", 2001.

   [X9.92]    "ANSI X9.92, Public Key Cryptography for the Financial
              Services Industry - Digital Signature Algorithms Giving
              Partial Message Recovery - Part 1: Elliptic Curve Pintsov-
              Vanstone Signatures (ECPVS)", 2009.







































Winter, et al.          Expires December 30, 2010             [Page 116]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


Authors' Addresses

   Tim Winter (editor)

   Email: wintert@acm.org


   Pascal Thubert (editor)
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com


   RPL Author Team
   IETF ROLL WG

   Email: rpl-authors@external.cisco.=
com




























Winter, et al.          Expires December 30, 2010             [Page 117]
=0C

= --Apple-Mail-51-270354032-- From pal@cs.stanford.edu Thu Jul 15 17:26:53 2010 Return-Path: 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 2A6793A67D1 for ; Thu, 15 Jul 2010 17:26:53 -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 gTWgpj-4dboF for ; Thu, 15 Jul 2010 17:26:52 -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 240313A679C for ; Thu, 15 Jul 2010 17:26:52 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OZX7U-0002El-Bv; Thu, 15 Jul 2010 15:41:33 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 15 Jul 2010 15:39:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 1a4cd7935245e7f84af030f069fa5aea Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Fri, 16 Jul 2010 00:26:53 -0000 On Jul 15, 2010, at 2:25 AM, Nicolas DEJEAN wrote: >=20 > Implementation of the proposed mechanism requires some modifications > into the draft for having the ability to: > - keep the same behavior as the one currently described into the Draft > for reaching consistency (R=3D1, U=3D0 allows that), > - implement the proposed mechanism for leaf nodes deployment (R=3D0, = U=3D1 > allows this case). >=20 >=20 > For instance, in rpl-10, the text from 7.3 might be changed like this > for managing the Reset of the Trickle Timer: > ---------------------- > o When a node receives a multicast DIS message *with the R flag > set and* without a Solicited > Information option. >=20 > o When a node receives a multicast DIS *with the R flag set and* > with a Solicited Information > option and the node matches all of the predicates in the = Solicited > Information option. > ----------------------- >=20 > A sentence like the following is also required: > ----------------------- > When a node receives a multicast DIS *with the R flag clear*, it MUST > NOT reset its Trickle Timer. > ----------------------- >=20 > Also, a sentence might be added for managing the transmission mode of > answered DIOs: > ---------------------- > When a node receives a DIS (unicast or multicast) with the U flag set, > it MUST unicast a DIO to the sender in response. > ---------------------- >=20 > Clearly, some use case have to be described for specifying when to set > or not R and U flags: > - default operational mode for network consistency: R=3D1 and U=3D0, > - specific leaf node deployment: R=3D0 and U=3D1. >=20 > As a conclusion, the goal of the proposed R and U flags is not to > modify the well-known behavior that allows the network reaching > consistency but to extend the possible usage of DIS/DIOs to > energy-efficient leaf node deployment. >=20 >> Phil >=20 > For answering directly your question, I do not expect that RPL > includes the proposed mechanism. > It might be described in a separate document if the WG shows some > interest for it. >=20 > However, adding these two flags to the Draft is one solution for > allowing this mechanism to be implemented. >=20 > Is my concern clearer now? >=20 > In these conditions, does the integration of R and U flags seem = acceptable now? >=20 Why doesn't the existing mechanism (unicast request obtains a unicast = response without resetting the timer) solve this problem?=20 The mechanism you describe has a serious flaw; I brought this up in = prior responses but you haven't explained why it isn't a problem. In = particular: "When a node receives a DIS (unicast or multicast) with the U flag set, = it MUST unicast a DIO to the sender in response." If a node sends a multicast DIS with the U flag, then it will cause all = neighbors to send a unicast DIO in response. Because the responses are = unicast, they will not suppress one another. This traffic pattern (a = flood response) is a terrible problem in low-power wireless, in part due = to the hidden terminal problem. Nodes will be possibly spending lots of = energy to transmit packets that just collide. I think it is a bad idea = to assume that an LLN node has an excellent enough understanding of the = network in order to carefully expand DIS predicates until a small number = of nodes respond. It's useful to note that if a message does not reset the timer, handling = suppression in a safe way becomes an open problem. That is, I do not = know of any existing solutions that have been evaluated in real = networks. E.g., let's say we're close to the end of an interval. If a = message does not reset the timer, then if there have already been enough = transmissions in the interval a node won't respond. Responding without = suppression can lead to a flood response. There might be ways out of = this (e.g., resetting the counter), but I'd consider such approaches = highly highly experimental. It sounds like you want to be able to send a multicast message and get = an immediate, single response from every neighbor? Your original mail = said: "Just to re-inforce this calculation, it has been our experience that node insertion into a dense low-power network, if done wrong, is a significant energy drain." So I guess I have 3 questions: 1) Why does the unicast/multicast distinction not solve the problem? 2) If the issue is discovery on inserting a new node, can you explain = how unicast responses from many neighbors (or an iterative DIS with = options search) is more efficient than suppression over a logarithmic = number of intervals? 3) If the issue is inserting many new nodes at the same time and many = triggering resets, why doesn't a simple DIO timeout (e.g., 5 minutes) = before issuing a DIS work? I feel like there's some very specific use case you're trying to = describe and I just don't understand it yet. Sorry to be slow. Phil= From m.pouillot@watteco.com Thu Jul 15 23:41:07 2010 Return-Path: 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 55C6B3A684A for ; Thu, 15 Jul 2010 23:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[AWL=3.413, 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 rZn9lMnwd9db for ; Thu, 15 Jul 2010 23:41:06 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 9E5183A6843 for ; Thu, 15 Jul 2010 23:41:05 -0700 (PDT) Received: from [192.168.4.247] ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id YNF68714 for ; Fri, 16 Jul 2010 08:41:14 +0200 Message-ID: <4C3FFF07.3090402@watteco.com> Date: Fri, 16 Jul 2010 08:41:11 +0200 From: Mathieu Pouillot User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <4C3EFA71.70207@watteco.com> <4C3F0E80.4050708@acm.org> In-Reply-To: <4C3F0E80.4050708@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] multi gateway in a RPL nwk X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: m.pouillot@watteco.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 06:41:07 -0000 Hi Tim, The second scenario is very interesting. But how to manage the packet sending from the LAN to a node. If the routing table is shared between the two gw then two packets will be sent on the LLN, if the routing table is not shared, we are an issue with DAO when the topology will change. This could be sent on the other gw and so the first gw will not update its routing table... regards, Mathieu Le 15/07/2010 15:34, Tim Winter a écrit : > Hi Mathieu, > > > On 07/15/2010 08:09 AM, Mathieu Pouillot wrote: >> Hello All, >> >> We are working on an architecture on which it is necessary to have two >> gateways to link our RPL-(W)SN and a LAN. >> >> >> The goal is to have a redundancy of gateway if one of them crashes, And >> to select the way the most efficient according to the selected >> constraints. >> >> In the scenario where we have only one root, we are not able to go out >> through the no-root gateway: all exterior addresses of the RPL nwk is >> routed through the Dag Root. >> >> I see just the solution with a multidag ( each gateway is a Dag Root) >> involves more memories... Are there other possibilities? > > There are two ways one could operate RPL in this scenario- depending > on your goals and your ability to ensure a reliable communication > between the two devices that are acting as DAG Roots. > > In the first scenario, each device acts as an independent DAG Root, > each with its own DODAGID but serving the same RPLInstanceID. In this > case, each node in the LLN will seek to join _one_ DODAG, thus > associate with _one_ DODAGID for that RPLInstanceID. The effect is > that the LLN (RPL-WSN) is partitioned, with some nodes associated with > one DAG Root only and the remainder with the other DAG Root only. In > terms of memory, the DAG Roots may be relieved somewhat since the size > of the partition that they are managing may be a subset of the entire > LLN. Similarly the nodes may be relieved (depending on > storing/non-storing, etc). If one DAG root fails then the nodes that > had joined that failed DODAG will begin to lose parents (starting with > the failed root) from that DODAGID, and then may join the second root > (a different DODAGID) in order to regain connectivity for that > RPLInstanceID. (some of the 'interior' nodes may not actually remove > a parent, but may end up following their existing parent to the new > DODAG). Of course, in the failed root case, the remaining root now > must now be able to allocate enough memory to support the entire LLN. > > In the second scenario, the two root devices coordinate (over the LAN > connection in your example) to operate as if they are one 'virtual' > DODAG root. In this case both nodes advertise the same DODAGID for > the same RPLInstanceID, and they coordinate with each other to stay > synchronized with any DODAG State, such as the VersionNumber. Each of > these root nodes MUST then issue DIOs at the same time, increment the > VersionNumber at the same time, ... in order to stay in synch over the > LLN. The mechanism/protocol for such synchronization is not defined > in the RPL base specification. Nodes could forward traffic to either > root devices, and change their preference at any time in response to > temporary link conditions, load balancing, etc. If one DAG root fails > then the nodes that were using that DAG root may begin to switch over > to begin forwarding traffic exclusively to the other DAG root without > any change in DODAGID. (some nodes may have no choice but to drop off > the DODAG and reattach at a different location in the sub-DODAG in > order to raise their Rank, depending on the exact topology, etc.) > > Regards, > > -Tim > >> >> best regards, >> >> Mathieu >> >> -- >> Mathieu Pouillot >> R&D Engineer >> m.pouillot@watteco.com >> >> Tel : +33(0)4 98 01 60 05 (Poste 43) >> Fax : +33(0)4 94 14 10 80 >> 1766 Chemin de la Planquette >> 83130 LA GARDE - France >> www.watteco.com >> >> >> >> _______________________________________________ >> 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 > -- Mathieu Pouillot R&D Engineer m.pouillot@watteco.com Tel : +33(0)4 98 01 60 05 (Poste 43) Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com From wwwrun@core3.amsl.com Thu Jul 15 15:13:38 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C808F3A6A7D; Thu, 15 Jul 2010 15:13:38 -0700 (PDT) To: pthubert@cisco.com,wintert@acm.org,rpl-authors@external.cisco.com, From: IETF Secretariat Message-Id: <20100715221338.C808F3A6A7D@core3.amsl.com> Date: Thu, 15 Jul 2010 15:13:38 -0700 (PDT) X-Mailman-Approved-At: Thu, 15 Jul 2010 23:42:24 -0700 Cc: culler@eecs.berkeley.edu, roll@ietf.org, housley@vigilsec.com, adrian.farrel@huawei.com, ipr-announce@ietf.org Subject: [Roll] IPR Disclosure: Rene Struik's Statement of IPR relating to draft-ietf-roll-rpl-10 and belonging to Certicom Corporation 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: , X-List-Received-Date: Thu, 15 Jul 2010 22:13:38 -0000 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-07-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1356/). The title of the IPR disclosure is "Rene Struik's Statement of IPR relating to draft-ietf-roll-rpl-10 and belonging to Certicom Corporation." The IETF Secretariat From jpv@cisco.com Fri Jul 16 00:08:14 2010 Return-Path: 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 E2B3F3A6872 for ; Fri, 16 Jul 2010 00:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Tiiw8HBNSlzX for ; Fri, 16 Jul 2010 00:08:13 -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 B4BF63A681A for ; Fri, 16 Jul 2010 00:08:11 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALehP0xAZnwN/2dsb2JhbACfaXGjdZpThSQEiFCCNIcK X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208,217";a="133096104" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 07:08:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6G78LfH012703; Fri, 16 Jul 2010 07:08:22 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:08:21 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:08:21 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-65-309189057 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:08:19 +0200 References: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 07:08:21.0294 (UTC) FILETIME=[AC8F3CE0:01CB24B5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17508.005 X-TM-AS-Result: No--14.281200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:08:15 -0000 --Apple-Mail-65-309189057 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jul 15, 2010, at 7:51 PM, Philip Levis wrote: > > On Jul 15, 2010, at 5:15 AM, JP Vasseur wrote: > >> >> >> => Bullet 4. I would suggest a MUST here. Otherwise, this leads to >> potential loops, ... yes we >> have mechanisms to clean up, but having a MUST would IMO leads to >> less interop issue. >> >> Thought ? > > Given that DAO parents are a subset of DODAG parents, this implies > there's a loop in the DODAG. I was referring to two things at the same time: 1) A MUST in the bullet above 4 - as reminder: 4. When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO (Section 5.4.3) to that removed DAO parent to invalidate the existing route. It should be a MUST here; otherwise the DAO parent may continue to send packet to that child 2) And the no-path DOA MUST have its K flag set. Make sense ? JP. > Wouldn't it make more sense to more narrowly define this to the case > of moving downward in the DODAG? > > Phil --Apple-Mail-65-309189057 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Jul = 15, 2010, at 7:51 PM, Philip Levis wrote:


On = Jul 15, 2010, at 5:15 AM, JP Vasseur wrote:



=3D> Bullet = 4. I would suggest a MUST here. Otherwise, this leads to potential = loops, ... yes we
have = mechanisms to clean up, but having a MUST would IMO leads to less = interop issue.

Thought = ?

Given that DAO parents are a subset of DODAG = parents, this implies there's a loop in the DODAG. =

I was referring to two things at = the same time:
1) A MUST in the bullet above 4 - as = reminder:

4.  When a node removes a node from its DAO =
parent set, it SHOULD
       send a No-Path DAO (Section 5.4.3) to that removed DAO parent to
       invalidate the existing route.
It should = be a MUST here; otherwise the DAO parent may continue to send packet to = that child

2) And the no-path DOA MUST have its = K flag set.

Make sense = ?

JP.

Wouldn't it make more sense to more narrowly define = this to the case of moving downward in the = DODAG?

Phil

= --Apple-Mail-65-309189057-- From jpv@cisco.com Fri Jul 16 00:09:51 2010 Return-Path: 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 02F923A6872 for ; Fri, 16 Jul 2010 00:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.396 X-Spam-Level: X-Spam-Status: No, score=-10.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 s6Ss4G6nzfnM for ; Fri, 16 Jul 2010 00:09:50 -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 D17E13A6829 for ; Fri, 16 Jul 2010 00:09:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO+iP0xAZnwN/2dsb2JhbACfZ3GjbppThSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208,217";a="133096490" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 07:10:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6G7A0VM013699 for ; Fri, 16 Jul 2010 07:10:00 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:10:00 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:09:59 +0200 Message-Id: <89DE0D01-5A7F-47E5-B930-A5804453AF58@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-66-309288028 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:09:58 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 07:09:59.0836 (UTC) FILETIME=[E74B8DC0:01CB24B5] Subject: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:09:51 -0000 --Apple-Mail-66-309288028 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Dear all, One comment: 8.2. Downward Route Discovery and Maintenance Destination Advertisement may be configured to be entirely disabled, or operate in either a storing or non-storing mode, as reported in Winter, et al. Expires December 30, 2010 [Page 62] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 the MOP in the DIO message. 1. All nodes who join a DODAG MUST abide by the MOP setting from =20= the root. Nodes that do not have the capability to fully =20 participate as a router MAY join the DODAG as a leaf. 2. If the MOP is 000, indicating no downward routing, nodes MUST =20= NOT transmit DAO messages, and MAY ignore DAO messages. 3. In non-storing mode, the DODAG Root MUST store source routing table entries for all destinations learned from DAOs. JP> I do not think that I would mandate for "all destinations", it =20 could be for a subset according to some policy (remember the route tag ?). At some point we had the possibility to add tags to route (to indicate =20= a priority, etc, ...). Note extensively used in other routing protocols too. Don't you think =20= that it would be wise adding them back (this is a simply field of flags). Thoughts ?= --Apple-Mail-66-309288028 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

One comment:

8.2.  Downward =
Route Discovery and Maintenance

   Destination Advertisement may be configured to be entirely disabled,
   or operate in either a storing or non-storing mode, as reported in



Winter, et al.          Expires December 30, 2010              [Page 62]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   the MOP in the DIO message.

   1.  All nodes who join a DODAG MUST abide by the MOP setting from the
       root.  Nodes that do not have the capability to fully participate
       as a router MAY join the DODAG as a leaf.

  =
 2.  If the MOP is 000, indicating no downward routing, nodes MUST NOT
       transmit DAO messages, and MAY ignore DAO messages.

   3.  In non-storing mode, the DODAG Root MUST store source routing
       table entries for all destinations learned from DAOs.

JP> I do not think that I would mandate for "all =
destinations", it could be for a subset 
according to =
some policy (remember the route tag ?).
At some point =
we had the possibility to add tags to route (to indicate a priority, =
etc, ...).
Note extensively used in other routing =
protocols too. Don't you think that it would be =
wise 
adding them back (this is a simply field =
of flags).

Thoughts =
?
= --Apple-Mail-66-309288028-- From pal@cs.stanford.edu Fri Jul 16 00:12:46 2010 Return-Path: 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 459AD3A680A for ; Fri, 16 Jul 2010 00:12:46 -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=[AWL=0.000, 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 mfQGJ-QBttXT for ; Fri, 16 Jul 2010 00:12: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 98E943A6872 for ; Fri, 16 Jul 2010 00:12:44 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OZf6N-0007CX-Ox; Fri, 16 Jul 2010 00:12:56 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 16 Jul 2010 00:12:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3860C7B6-4C70-4196-A8B6-30B9A2D47B46@cs.stanford.edu> References: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 6214ac49f2cb083a0c8190805312a710 Cc: ROLL WG Subject: Re: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:12:46 -0000 On Jul 16, 2010, at 12:08 AM, JP Vasseur wrote: > Hi, >=20 > On Jul 15, 2010, at 7:51 PM, Philip Levis wrote: >=20 >>=20 >> On Jul 15, 2010, at 5:15 AM, JP Vasseur wrote: >>=20 >>>=20 >>>=20 >>> =3D> Bullet 4. I would suggest a MUST here. Otherwise, this leads to = potential loops, ... yes we >>> have mechanisms to clean up, but having a MUST would IMO leads to = less interop issue. >>>=20 >>> Thought ? >>=20 >> Given that DAO parents are a subset of DODAG parents, this implies = there's a loop in the DODAG. >=20 > I was referring to two things at the same time: > 1) A MUST in the bullet above 4 - as reminder: >=20 > 4. When a node removes a node from its DAO parent set, it SHOULD > send a No-Path DAO (Section 5.4.3) to that removed DAO parent = to > invalidate the existing route. >=20 > It should be a MUST here; otherwise the DAO parent may continue to = send packet to that child >=20 > 2) And the no-path DOA MUST have its K flag set. >=20 > Make sense ? Sort of. The reason why it's a SHOULD and not a MUST is for the case = where a node removes another node from its DAO parent set due to the = link between them becoming terrible. If the link has failed, you don't = want to try send a No-Path DAO along it... Phil= From jpv@cisco.com Fri Jul 16 00:18:37 2010 Return-Path: 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 44C443A6895 for ; Fri, 16 Jul 2010 00:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 4Rq8t55pxUMf for ; Fri, 16 Jul 2010 00:18:34 -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 A2D2A3A680A for ; Fri, 16 Jul 2010 00:18:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6kP0xAZnwM/2dsb2JhbACfZ3GjbJpThSQEiFCCNIcK X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="133099244" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 07:18:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6G7IiAB021581; Fri, 16 Jul 2010 07:18:45 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:18:44 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:18:44 +0200 Message-Id: <725A70CB-FEE6-4264-AF4A-0A20CF7287C3@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <3860C7B6-4C70-4196-A8B6-30B9A2D47B46@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:18:43 +0200 References: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu> <3860C7B6-4C70-4196-A8B6-30B9A2D47B46@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 07:18:44.0139 (UTC) FILETIME=[1FCDD7B0:01CB24B7] Cc: ROLL WG Subject: Re: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:18:37 -0000 On Jul 16, 2010, at 9:12 AM, Philip Levis wrote: > > On Jul 16, 2010, at 12:08 AM, JP Vasseur wrote: > >> Hi, >> >> On Jul 15, 2010, at 7:51 PM, Philip Levis wrote: >> >>> >>> On Jul 15, 2010, at 5:15 AM, JP Vasseur wrote: >>> >>>> >>>> >>>> => Bullet 4. I would suggest a MUST here. Otherwise, this leads >>>> to potential loops, ... yes we >>>> have mechanisms to clean up, but having a MUST would IMO leads to >>>> less interop issue. >>>> >>>> Thought ? >>> >>> Given that DAO parents are a subset of DODAG parents, this implies >>> there's a loop in the DODAG. >> >> I was referring to two things at the same time: >> 1) A MUST in the bullet above 4 - as reminder: >> >> 4. When a node removes a node from its DAO parent set, it SHOULD >> send a No-Path DAO (Section 5.4.3) to that removed DAO parent >> to >> invalidate the existing route. >> >> It should be a MUST here; otherwise the DAO parent may continue to >> send packet to that child >> >> 2) And the no-path DOA MUST have its K flag set. >> >> Make sense ? > > Sort of. The reason why it's a SHOULD and not a MUST is for the case > where a node removes another node from its DAO parent set due to the > link between them becoming terrible. If the link has failed, you > don't want to try send a No-Path DAO along it... If you set K, then this is OK and much better than not let your parent know about the issue, right ? Otherwise, why sending the no-DOA in the first place. JP. > > Phil From jpv@cisco.com Fri Jul 16 00:25:21 2010 Return-Path: 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 E154D3A680A for ; Fri, 16 Jul 2010 00:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PPJc1y6mNhPo for ; Fri, 16 Jul 2010 00:25:21 -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 0150E3A67F1 for ; Fri, 16 Jul 2010 00:25:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGamP0xAZnwM/2dsb2JhbACfZnGjbJpThSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="133100692" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 07:25:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6G7PVFb025544; Fri, 16 Jul 2010 07:25:32 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:25:31 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:25:30 +0200 Message-Id: From: JP Vasseur To: ROLL WG , Richard Kelsey In-Reply-To: <871vb4hl2u.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:25:29 +0200 References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <871vb4hl2u.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 07:25:30.0803 (UTC) FILETIME=[1231D830:01CB24B8] Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:25:22 -0000 Hi Richard, On Jul 15, 2010, at 4:32 PM, Richard Kelsey wrote: >> From: JP Vasseur >> Date: Thu, 15 Jul 2010 13:14:40 +0200 >> Section 7.4 >> >> 7.4. DODAG Selection >> >> The DODAG selection is implementation and OF dependent. Nodes >> SHOULD >> prefer to join DODAGs for RPLInstanceIDs advertising OCPs and >> destinations compatible with their implementation specific >> objectives. >> >> I would advocate for a MUST there. > > I don't think there is any point in this sentence, whether > it is a SHOULD or a MUST. Given that the "implementation > specific objectives" are entirely implementation specific, > what would it mean to require that the node act compatibly > with them? This sentence is equivalent to: > Implementations SHOULD/MUST act in a fashion > compatible with their objectives. > While I would hope this to be true, we cannot meaningfully > require it. That was my point. We are stating the obvious so we should either: 1) Remove the sentence completely. 2) Make it a MUST Agree ? I guess that you choose 1). Others ? > -Richard Kelsey From jpv@cisco.com Fri Jul 16 00:26:40 2010 Return-Path: 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 D6D5C3A6949 for ; Fri, 16 Jul 2010 00:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 46omwwmn5dGE for ; Fri, 16 Jul 2010 00:26:25 -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 678823A6895 for ; Fri, 16 Jul 2010 00:26:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALGmP0xAZnwN/2dsb2JhbACBQ54icaNrmlOFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208,217";a="133076518" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2010 07:26:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6G7QXMd023768; Fri, 16 Jul 2010 07:26:34 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:26:33 +0200 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 09:26:32 +0200 Message-Id: <4E412745-A553-46AE-979E-04D5831ECB8A@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-74-310281001 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:26:31 +0200 References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 07:26:32.0611 (UTC) FILETIME=[3708FF30:01CB24B8] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 07:26:40 -0000 --Apple-Mail-74-310281001 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote: > I understand why joining based on RPLInstanceIDs should be must =96 =20= > this is an application requirement. > > However, being able to support a certain OCP in an RPLInstance that =20= > is not required by my application, seems a little confusing to me. > > Also, I=92m not sure - where are =93destinations compatible with their = =20 > =85=94 advertised? > Yes, please see the previous reply on the list. Tell us what you prefer. Thanks. JP. > Thanks, > Yoav > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of JP Vasseur > Sent: Thursday, July 15, 2010 2:15 PM > To: ROLL WG > Subject: [Roll] Comment Section 7.4 > > Section 7.4 > > 7.4. DODAG Selection > > The DODAG selection is implementation and OF dependent. Nodes =20 > SHOULD > prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > destinations compatible with their implementation specific > objectives. > > I would advocate for a MUST there. > > Thought? > > JP. --Apple-Mail-74-310281001 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi,

On Jul = 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote:

I understand why joining based on = RPLInstanceIDs should be must =96 this is an application = requirement.

 

Also, I=92m not sure - = where are =93destinations compatible with their =85=94 = advertised?

Thanks,
Yoav

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Thursday, July 15, 2010 = 2:15 PM
To: ROLL = WG
Subject: [Roll] Comment Section = 7.4

 

Section 7.4

 

   The DODAG =
selection is implementation and OF dependent.  Nodes =
SHOULD
   prefer to join DODAGs for RPLInstanceIDs =
advertising OCPs and
   destinations compatible with =
their implementation specific
   =
objectives.

I would advocate for a MUST = there.

 

Thought?

 

In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comment Section 7.4 thread-index: AcskuGO7ubxzjEGrTQ2L9J54CM3noQAEq5jA References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com><871vb4hl2u.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "ROLL WG" , "Richard Kelsey" X-OriginalArrivalTime: 16 Jul 2010 09:45:29.0352 (UTC) FILETIME=[A01EB880:01CB24CB] Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 09:45:20 -0000 I'd remove the uppercase and say that the application is expected to have some out of scope policy to decide which OCP/OF it should join, in terms such as white list, black list, preference and maximum number. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Friday, July 16, 2010 9:25 AM > To: ROLL WG; Richard Kelsey > Subject: Re: [Roll] Comment Section 7.4 >=20 > Hi Richard, >=20 > On Jul 15, 2010, at 4:32 PM, Richard Kelsey wrote: >=20 > >> From: JP Vasseur > >> Date: Thu, 15 Jul 2010 13:14:40 +0200 Section 7.4 > >> > >> 7.4. DODAG Selection > >> > >> The DODAG selection is implementation and OF dependent. Nodes > >> SHOULD > >> prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > >> destinations compatible with their implementation specific > >> objectives. > >> > >> I would advocate for a MUST there. > > > > I don't think there is any point in this sentence, whether it is a > > SHOULD or a MUST. Given that the "implementation specific objectives" > > are entirely implementation specific, what would it mean to require > > that the node act compatibly with them? This sentence is equivalent > > to: > > Implementations SHOULD/MUST act in a fashion compatible with their > > objectives. > > While I would hope this to be true, we cannot meaningfully require it. >=20 > That was my point. We are stating the obvious so we should either: > 1) Remove the sentence completely. > 2) Make it a MUST >=20 > Agree ? >=20 > I guess that you choose 1). >=20 > Others ? >=20 > > -Richard Kelsey >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 16 02:54:22 2010 Return-Path: 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 72D073A6952 for ; Fri, 16 Jul 2010 02:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.287 X-Spam-Level: X-Spam-Status: No, score=-10.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lwmIb52OYKNG for ; Fri, 16 Jul 2010 02:54: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 4D5B73A6816 for ; Fri, 16 Jul 2010 02:54:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="133116353" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2010 09:54:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6G9sHpn026731; Fri, 16 Jul 2010 09:54:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 11:54:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 11:54:20 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D025748F7@XMB-AMS-107.cisco.com> In-Reply-To: <725A70CB-FEE6-4264-AF4A-0A20CF7287C3@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comment Section 8.8 thread-index: Acskty0oCO3YrIbVRjG+mRvE5opJZAAFMYcQ References: <3C1289BE-1A87-4C92-87AC-5AB8A83A1590@cs.stanford.edu><3860C7B6-4C70-4196-A8B6-30B9A2D47B46@cs.stanford.edu> <725A70CB-FEE6-4264-AF4A-0A20CF7287C3@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Philip Levis" X-OriginalArrivalTime: 16 Jul 2010 09:54:23.0546 (UTC) FILETIME=[DE8641A0:01CB24CC] Cc: ROLL WG Subject: Re: [Roll] Comment Section 8.8 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: , X-List-Received-Date: Fri, 16 Jul 2010 09:54:22 -0000 Hi JP: This creates a loop if the node moves upwards (reduces its Rank) so it is good to send a no path.=20 If the node does not or fails trying, and if the path is used at all then datapath validation should discover and fix the issue.=20 I think that the "SHOULD" comes with the idea that there are numerous cases where the path is no more preferred and maintained but still works. My proposal is to be specific and make it a MUST in the case of the Rank reduction that makes the ex parent lower than self, leaving it a SHOULD or a MAY in the other cases. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Friday, July 16, 2010 9:19 AM > To: Philip Levis > Cc: ROLL WG > Subject: Re: [Roll] Comment Section 8.8 >=20 >=20 > On Jul 16, 2010, at 9:12 AM, Philip Levis wrote: >=20 > > > > On Jul 16, 2010, at 12:08 AM, JP Vasseur wrote: > > > >> Hi, > >> > >> On Jul 15, 2010, at 7:51 PM, Philip Levis wrote: > >> > >>> > >>> On Jul 15, 2010, at 5:15 AM, JP Vasseur wrote: > >>> > >>>> > >>>> > >>>> =3D> Bullet 4. I would suggest a MUST here. Otherwise, this leads to > >>>> potential loops, ... yes we have mechanisms to clean up, but having > >>>> a MUST would IMO leads to less interop issue. > >>>> > >>>> Thought ? > >>> > >>> Given that DAO parents are a subset of DODAG parents, this implies > >>> there's a loop in the DODAG. > >> > >> I was referring to two things at the same time: > >> 1) A MUST in the bullet above 4 - as reminder: > >> > >> 4. When a node removes a node from its DAO parent set, it SHOULD > >> send a No-Path DAO (Section 5.4.3) to that removed DAO parent > >> to > >> invalidate the existing route. > >> > >> It should be a MUST here; otherwise the DAO parent may continue to > >> send packet to that child > >> > >> 2) And the no-path DOA MUST have its K flag set. > >> > >> Make sense ? > > > > Sort of. The reason why it's a SHOULD and not a MUST is for the case > > where a node removes another node from its DAO parent set due to the > > link between them becoming terrible. If the link has failed, you don't > > want to try send a No-Path DAO along it... >=20 > If you set K, then this is OK and much better than not let your parent know > about the issue, right ? Otherwise, why sending the no-DOA in the first place. >=20 > JP. >=20 > > > > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 16 03:16:46 2010 Return-Path: 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 E75793A6884 for ; Fri, 16 Jul 2010 03:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vfpukVgIH5ZS for ; Fri, 16 Jul 2010 03:16:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2DF983A68A4 for ; Fri, 16 Jul 2010 03:16:39 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208,217";a="230848618" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2010 10:16:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6GAGd8o004017; Fri, 16 Jul 2010 10:16:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 12:16:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB24D0.0028BDA7" Date: Fri, 16 Jul 2010 12:16:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257491A@XMB-AMS-107.cisco.com> In-Reply-To: <89DE0D01-5A7F-47E5-B930-A5804453AF58@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC thread-index: Acskte7TSZTkhBxGSyO/l7/dTvqZoQAFx1hA References: <89DE0D01-5A7F-47E5-B930-A5804453AF58@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 16 Jul 2010 10:16:49.0032 (UTC) FILETIME=[007F2080:01CB24D0] Subject: Re: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC 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: , X-List-Received-Date: Fri, 16 Jul 2010 10:16:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB24D0.0028BDA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP: =20 JP> I do not think that I would mandate for "all destinations", it could be for a subset=20 according to some policy (remember the route tag ?). =20 [Pascal] The problem is that we do not know a priori whether a target is also a parent since that comes in another DAO. If it is a parent then we need to store it to be able to build the source route path to and via its children. If the root now has a policy to refuse a DAO, then it needs to indicate so in the DAO Ack so that the node can branch elsewhere. All this process including err codes would have to be documented. At the moment we expect that the network is dimensioned and operated in such a fashion that the root can accept all nodes that are able to join. =20 JP> At some point we had the possibility to add tags to route (to indicate a priority, etc, ...). Note extensively used in other routing protocols too. Don't you think that it would be wise=20 adding them back (this is a simply field of flags). =20 [Pascal] I'd love it. The thing is that the tag is used by the parent to indicate the next hop. Usually it is locally significant to the parent. At the moment, the child indicates its parents in the DAO but wouldn't know the tag that the parent would affect to it. =20 If we're taking the path of tagging, then we might need a flow to get the tag from the parent, for instance using an ND extension.=20 As the parent learns about the child and creates an NC Entry, it also assigns a tag associated to that Neighbor, and passes it to the child as a source or target tag option depending on the ND message being used. =20 For RPL, all we'd need to do is enable the tagging by adding room for a tag to the transit option. I'm really positive. =20 Votes?.=20 =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Friday, July 16, 2010 9:10 AM To: ROLL WG Subject: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC =20 Dear all, =20 One comment: =20 8.2. Downward Route Discovery and Maintenance =20 Destination Advertisement may be configured to be entirely disabled, or operate in either a storing or non-storing mode, as reported in =20 =20 =20 Winter, et al. Expires December 30, 2010 [Page 62] =20 Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 =20 =20 the MOP in the DIO message. =20 1. All nodes who join a DODAG MUST abide by the MOP setting from the root. Nodes that do not have the capability to fully participate as a router MAY join the DODAG as a leaf. 2. If the MOP is 000, indicating no downward routing, nodes MUST NOT transmit DAO messages, and MAY ignore DAO messages. =20 3. In non-storing mode, the DODAG Root MUST store source routing table entries for all destinations learned from DAOs. JP> I do not think that I would mandate for "all destinations", it could be for a subset=20 according to some policy (remember the route tag ?). At some point we had the possibility to add tags to route (to indicate a priority, etc, ...). Note extensively used in other routing protocols too. Don't you think that it would be wise=20 adding them back (this is a simply field of flags). =20 Thoughts ? ------_=_NextPart_001_01CB24D0.0028BDA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP:

 

JP> =
I do not think that I would mandate for "all destinations", it =
could be for a subset 
according =
to some policy (remember the route tag =
?).
 <=
/o:p>

[Pascal] The problem is that we do not know a priori whether a target = is also a parent since that comes in another DAO. If it is a parent then = we need to store it to be able to build the source route path to and via = its children. If the root now has a policy to refuse a DAO, then it = needs to indicate so in the DAO Ack so that the node can branch = elsewhere. All this process including err codes would have to be = documented. At the moment we expect that the network is dimensioned =  and operated in such a fashion that the root can accept all nodes = that are able to = join.

 
JP> At =
some point we had the possibility to add tags to route (to indicate a =
priority, etc, ...).
Note =
extensively used in other routing protocols too. Don't you think that it =
would be wise 
adding them =
back (this is a simply field of flags).

 

[Pascal] I’d love it. The thing is that the tag is used by the = parent to indicate the next hop. Usually it is locally significant to = the parent.

At the moment, the child indicates its parents in the DAO but = wouldn’t know the tag that the parent would affect to = it.

 

If we’re taking the path of tagging, then we might need a flow = to get the tag from the parent, for instance using an ND extension. =

As the parent learns about the child and creates an NC Entry, it also = assigns a tag associated to that Neighbor, and passes it to the child as = a source or target tag option depending on the ND message being = used.

 

For RPL, all we’d need to do is enable the tagging by adding = room for a tag to the transit option. I’m really = positive.

 

Votes?.

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of = JP = Vasseur
Sent: Friday, July 16, 2010 9:10 AM
To: ROLL = WG
Subject: [Roll] Comments on Route-Tags - RPL Version 10 - = WG LC

 

Dear = all,

 

One comment:

 

8.2.  Downward =
Route Discovery and =
Maintenance
 
  =
 Destination Advertisement may be configured to be entirely =
disabled,
   or operate in either a =
storing or non-storing mode, as reported =
in
 
 
 
Winter, et =
al.          Expires =
December 30, =
2010           &nb=
sp;  [Page =
62]
 
Internet-Draft =
          =
draft-ietf-roll-rpl-10        &nb=
sp;        Jun =
2010
 
 
   the MOP in the DIO =
message.
 
   =
1.  All nodes who join a DODAG MUST abide by the MOP setting from =
the
       =
root.  Nodes that do not have the capability to fully =
participate
       as =
a router MAY join the DODAG as a leaf.
   =
2.  If the MOP is 000, indicating no downward routing, nodes MUST =
NOT
       transmit =
DAO messages, and MAY ignore DAO =
messages.
 
   =
3.  In non-storing mode, the DODAG Root MUST store source =
routing
       table =
entries for all destinations learned from DAOs.
JP> =
I do not think that I would mandate for "all destinations", it =
could be for a subset 
according =
to some policy (remember the route tag =
?).
At some =
point we had the possibility to add tags to route (to indicate a =
priority, etc, ...).
Note =
extensively used in other routing protocols too. Don't you think that it =
would be wise 
adding them =
back (this is a simply field of =
flags).
 
Thoughts =
?
------_=_NextPart_001_01CB24D0.0028BDA7-- From jpv@cisco.com Fri Jul 16 04:10:18 2010 Return-Path: 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 D110B3A6987 for ; Fri, 16 Jul 2010 04:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qLSvQ4Trgsof for ; Fri, 16 Jul 2010 04:10: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 723C43A699A for ; Fri, 16 Jul 2010 04:10:17 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFACPbP0xAZnwN/2dsb2JhbACBQ54kcaMymmGFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208,217";a="133167154" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 11:10:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6GBASVZ004668; Fri, 16 Jul 2010 11:10:28 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 13:10:28 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 13:10:27 +0200 Message-Id: <7C104DFA-1D53-4F67-8943-EFD924594363@cisco.com> From: JP Vasseur To: Anders Brandt In-Reply-To: <0596CABF-7084-438B-9C09-3F426F3DDC4F@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-91-321520827 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 12:33:51 +0200 References: <6D9687E95918C04A8B30A7D6DA805A3E01CCD20E@zensys17.zensys.local> <0596CABF-7084-438B-9C09-3F426F3DDC4F@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 11:10:27.0734 (UTC) FILETIME=[7EFE1360:01CB24D7] Cc: ROLL WG Subject: Re: [Roll] Fwd: draft-ietf-roll-rpl-11 RC1 Comments [2/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: , X-List-Received-Date: Fri, 16 Jul 2010 11:10:19 -0000 --Apple-Mail-91-321520827 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Thanks for comments and review of Section 16. Just one thing: you asked in Section 16.2.4 if poisoning was about configuration: yes you may want to configure the node to poison (or not) broken path upon loosing all parents Thanks. JP. On Jul 13, 2010, at 11:33 AM, JP Vasseur wrote: > Thanks for your comments Anders. > WIll address them soon (see new ticket to be opened). > > Thanks. > > JP. > > Begin forwarded message: > >> From: "Anders Brandt" >> Date: July 6, 2010 12:35:35 PM CEDT >> To: >> Subject: Re: draft-ietf-roll-rpl-11 RC1 Comments [2/2] >> >> Cheers, >> Anders > <3805_046.pdf> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-91-321520827 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks for comments and review = of Section 16.
Just one thing: you asked in Section 16.2.4 if = poisoning was about configuration: yes you may want to configure
the = node to poison (or not) broken path upon loosing all = parents

Thanks.

JP.

On Jul 13, 2010, at 11:33 AM, JP Vasseur = wrote:

Thanks for your comments = Anders.
WIll address them soon (see new ticket to be = opened).

Thanks.

JP.
=

Begin forwarded message:

From: = "Anders Brandt" <abr@sdesigns.dk>
Date: = July 6, 2010 12:35:35 PM CEDT
Subject: Re: draft-ietf-roll-rpl-11 RC1 = Comments [2/2]

Cheers,
  Anders
=
<3805_046.pdf>

_________________________= ______________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-91-321520827-- From jpv@cisco.com Fri Jul 16 04:10:22 2010 Return-Path: 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 EEE573A698D for ; Fri, 16 Jul 2010 04:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 bTRxfjSDGMFF for ; Fri, 16 Jul 2010 04:10:17 -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 914013A69AA for ; Fri, 16 Jul 2010 04:10:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAF7bP0xAZnwM/2dsb2JhbACBQ5sEgyBxozOaYQKFIgSIUII0 X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="pdf'?scan'208,217";a="133142480" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2010 11:10:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GBAGjn005022 for ; Fri, 16 Jul 2010 11:10:24 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 13:10:23 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 13:10:23 +0200 Message-Id: From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-89-321512622 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 12:33:43 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 11:10:23.0656 (UTC) FILETIME=[7C8FD280:01CB24D7] X-Mailman-Approved-At: Fri, 16 Jul 2010 05:59:42 -0700 Cc: roll@ietf.org Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Fri, 16 Jul 2010 11:10:22 -0000 --Apple-Mail-89-321512622 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks for your comments - see in line, On Jul 13, 2010, at 1:47 PM, Mathilde Durvy (mdurvy) wrote: > Hi All, > > Just reviewed Section 16, here is some feedback that might help =20 > clarify: > > - In 16.2.3, 16.2.4 It is not very clear which parameters are =20 > configured versus negotiated dynamically through messages. All the parameters are the ones that a RPL MAY/SHOULD/MUST allow for =20 configuration only. I will add some text to clarify. > - In 16.2.4 =93A RPL implementation SHOULD allow configuring whether a = =20 > non-storing node provides the transit information in DAO messages.=94 =20= > Shouldn=92t a node always include the transit info in DAO messages? Correct, what I meant was the requirement to configure the MOP (this =20 was already in 16.2.5), which implies to send transit information for =20= non storing mode, but this was not clear indeed. I removed it from =20 there. By the way, I added the Route information and Prefix =20 information that were missing. > Aren=92t the 2 first bullet related to the DAO mechanism and hence =20 > more appropriate in Section 16.2.6 (or maybe we should just remove =20 > Section 16.2.6) Yes I updated 16.2.6, which was outdated after we removed the DAO FSM. =20= Thanks. > - In 16.2.5, T flag has not been removed Fixed (old text, good catch). I also added text on DTSN. > - In 16.2.6, this section contains legacy text (already mentioned in =20= > previous email thread) Fixed (old text, good catch) > - In 16.6, is the DODAGID necessarily part of the policy? Yes I agree, a MUST was too strong (I changed it or a SHOULD). > - In 16.7/16.9 or 16.4. Maybe it would help to further specify what =20= > services RPL expects to be handled by other protocols such as ND. =20 > I=92m talking of course of services that RPL directly relies on to =20 > operate. NUD is mentioned but what about address resolution, etc. I =20= > guess this is kind of standard so not sure if we should include it. I do not think, it will belong to the Arch ID David and I should have =20= started to work on ... Does not belong to this document. > - In general, Sections 16.3 to 16.5 can be difficult to implement on =20= > constrained nodes without interface or file system. I would =20 > emphasize that it is expected that constrained nodes do not =20 > implement these parts. Not sure is you saw it, but there is already pretty explicit text in =20 Section 16.1: RPL will be used on a variety of devices that may have resources =20 such as memory varying from a very few Kbytes to several hundreds of Kbytes and even Mbytes. When memory is highly constrained, it may not be possible to satisfy all the requirements listed in this section. Still it is worth listing all of these in an exhaustive fashion, and implementers will then determine which of these requirements could be satisfied according to the available resources on the device. Attached the changes. Let me know if you agree with the proposed =20 resolution and I'll close the ticket. Thanks. JP. > > Best, > Mathilde > > Durvy Mathilde > Software Engineer > Technology center > > mdurvy@cisco.com > Phone: +41 21 822 1725 > Mobile: +41 76 396 8116 > Cisco Systems International S=E0rl > Av. des Uttins, 5 > CH-1180 Rolle > > Cisco home page > > > Think before you print. > This e-mail may contain confidential and privileged material for the =20= > sole use of the intended recipient. Any review, use, distribution or =20= > disclosure by others is strictly prohibited. If you are not the =20 > intended recipient (or authorized to receive for the recipient), =20 > please contact the sender by reply e-mail and delete all copies of =20 > this message. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-89-321512622 Content-Type: multipart/mixed; boundary=Apple-Mail-90-321512623 --Apple-Mail-90-321512623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for your comments - see = in line,

On Jul 13, 2010, at 1:47 PM, Mathilde Durvy = (mdurvy) wrote:

Hi All,
Just reviewed Section 16, here is some = feedback that might help clarify:
- In 16.2.3, 16.2.4 It is not very = clear which parameters are configured versus negotiated dynamically = through = messages.

<= div>All the parameters are the ones that a RPL MAY/SHOULD/MUST allow for = configuration only. I will add some text to = clarify.

- In 16.2.4 =93A RPL implementation = SHOULD allow configuring whether a non-storing node provides the transit = information in DAO messages.=94 Shouldn=92t a node always include the = transit info in DAO messages? =

Correct, what = I meant was the requirement to configure the MOP (this was already in = 16.2.5), which implies to send transit information for non storing mode, = but this was not clear indeed. I removed it from there. By the way, I = added the Route information and Prefix information that were = missing.

Aren=92t the 2 first bullet related to = the DAO mechanism and hence more appropriate in Section 16.2.6 (or maybe = we should just remove Section = 16.2.6)

Yes I = updated 16.2.6, which was outdated after we removed the DAO FSM. = Thanks.

- = In 16.2.5, T flag has not been = removed

Fixed = (old text, good catch). I also added text on DTSN.

- = In 16.2.6, this section contains legacy text (already mentioned in = previous email = thread)

Fixed = (old text, good catch)

- = In 16.6, is the DODAGID necessarily part of the = policy?

Yes I = agree, a MUST was too strong (I changed it or a = SHOULD).

- = In 16.7/16.9 or 16.4. Maybe it would help to further specify what = services RPL expects to be handled by other protocols such as ND. I=92m = talking of course of services that RPL directly relies on to operate. = NUD is mentioned but what about address resolution, etc. I guess this is = kind of standard so not sure if we should include = it.

I do not = think, it will belong to the Arch ID David and I should have started to = work on ... Does not belong to this document.

- = In general, Sections 16.3 to 16.5 can be difficult to implement on = constrained nodes without interface or file system. I would emphasize = that it is expected that constrained nodes do not implement these = parts.

Not sure = is you saw it, but there is already pretty explicit text in Section = 16.1:

   RPL will be used on a variety of devices =
that may have resources such
   as memory varying from a very few Kbytes to several hundreds of
   Kbytes and even Mbytes.  When memory is highly constrained, it may
   not be possible to satisfy all the requirements listed in this
   section.  Still it is worth listing all of these in an exhaustive
   fashion, and implementers will then determine which of these
   requirements could be satisfied according to the available resources
   on the device.
Attached the changes. Let me = know if you agree with the proposed resolution and I'll close the = ticket.

= --Apple-Mail-90-321512623 Content-Disposition: inline; filename=section-16-for-RPL-rev-11.pdf Content-Type: application/pdf; x-mac-hide-extension=yes; x-unix-mode=0644; name="section-16-for-RPL-rev-11.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnVu33MQRhd/1K7TyNF7LCN0veQPHZJFgx7HPWjwAD2Ag kGBuhhD+fUqtr3tm62g0LY0PPvAgS9OX6qpdu6ov0vkp/Wf6U9pn9ZAWdZ21VVoPVdb2aVv1Wd+n P3+Vfpx+n7776HWRvnyd5u7/1y+tTp4VQ9Xm+fToeNfVWVXUeZ92ZZ319VAmL1+l79+kdeHqcrl5 lb77QZHlaZHefJ1+kh6KB+k7Q3pop0tmlzo9pHJ58iB5p7Cnn09lvp8u3P1ruvtKHn4x3X1rF6v3 3XRxd8nhl+nu96kIPT2yu6JMDz9MT+nitd316YFmvpx+o6efTagmyESjlLzVymfpzd/Sxzem81Wt J9u1XgyNKbsYgtZTp/VkTeujem/+HSGPQ0GyEwVFkzVNW0/yKAoSRcE2eRSVSZ5GojJvs7Kt2iV5 Ui9P4lGpAOTuZgRJnh6+ESDwI3AEAa+ALD8CiK+t4hHdYIbWqAjkqOfukgOQe2nVDY5rWKPeYmO/ mEzWO7JQEvehwn+XRka3c1AnK66RRroGQixKpupBBVR4ZXKeYYTksJERgkKNEcRPkzfJjlWZG9dW ZdqBwwh2jPaLHbwR2Lod2mzojLYv84axNfrXyyK6n48eYIz6bDRVkR4+mqD10C5HF1BGh2BpHL9w jSeH38ZmrDl+fM7trHV+9YVBNfzvLolvgRChuGIkP06yBqZfgPNXNjwLWyoy/RE9EIYxcocauDx1 w0gOmV2PWqHoKt3AE+qbP05CLY4pjntOHCB5s+lBVXRZNzRF6gF3bxyg77K2A/+rceoc/rEFaj/D 0g4uiowzLO2gABKBgpr5+8nMdEsr8+zEYZbqa1T6tTV2jAqnrhJCxcydGAQ0SxcO5ckBmdSBVCMU od4id/joqfTA3UZ6nyd8f56x/IYc2HKNC9lGaWTalWWTtudBNUs2okn+mpTc8J1VfROZkmMavSxC EFIBgljm14k9f7aLJMgn3LI29dgRzIqizerWgqsfZ1wwQ2wgCKwfChX7ROOHyeUoQ0XcivqMl9/U SbRRXA48oy48jzbRve/+vCOE5NAXhYXon+a0f1rDosGwjqGQRqtHjEkl/PJBEmntHaguh8FmqJb+ eWvfm0jSDlnZL84wZjOec5FEeRNE4WQBZm7e6c2teseWsQlAsjyVQQq6p18FewCNm7x/N8UQQKto 4SHw5jeYghRPMY+rreUrOj7k1PCL1D6SeHWpdxAz0SFiICIN4AguaIXckRBGYyr+3FqOBCli48Ut kgsrATvcoiqbrC7zNm0nGN4br2iGbBhnPvsnGIuI+mQC3XPj63Fi8MF4tcn5I+4bu1qC3k2XfLqw yvSZ3VnOk92lOYoqz/q8NpZi/PfHHnnW5TkLM29/oaiti6zOu0jaXFwu5KHZ8/Ys6sPpITkzjqjU Bg0Q+qC2c2wwOnByeSlvhwMX48rrkHep18i9QUxVZkVRxywRbMtmdy4ttmWZ9SWEsmvG9sRAMa4f QfLwuRL55jhEOPiftW3EA2eFpt0sS4lMZ1AA9fEomq2X3IxX4zPPa5IRJjFr4csxTwf52kj0uKSo yYRGR1yGhwwLoajHkjh64LcXjId+aWbR13joioS8lmawlEXXHYllEreDUdmSdT6Y/0Xjaxvcd65c t0WVNeWwiPfZZPJcXunxrgbmTifUPmPCijoRwBiBUx3SFzOeCXwBp1gf/GtuZY1G2nTP1LArs6Ed qlS1uBr2TIufHgy2Nnv16PUKZOSfPph+dvpIDqwlok98AwXiMGhOfQqtUC+dEhrvtiiJGrRGGq3u 54UVIZPD+3geXS+3i8/RLr3Q/HGUjryQ1uSKNNdiDExWt2uq0hZQmsG2IeNBf40TXlrQOS6T53VW Vm0dEZPPOeHMAGQkuMRRuWPwgCWxnHqtAmpqNPgZ7rro2bRGEUxNv36Jj6BH//8xBB33P6moUUvh yf4RY3o5BRcFVbYXPm717dL6W9lnRVmbt2OuM7t9ycke9HXwWYdzgE8z1NlQR+0+XidP5G5o0zdZ 2+T9FXD2iQk8RfBXyCrk4BrvB7oDcwr5xCdmhBaa2bsuAZ3pIhjAZwkCjNIRLP8YAr0Zr3kyT8V0 DcSPyl8ZLE6jXv67OYZ5Ob0hgkYPfqOVtZDC5mn8QFxOGUnhOyJuVfRZWeZN6jEWMfHfhvmd04am a7OquWaj5wWAADuLvPz5ZFvgrGT9ZKxv0w6tuEjWE4xCFgyM6BhweA+kL9rxAATSq8yuLgFI6Qt4 kxkARMbz7ZSqUFIjwppjeQXSkx8kjq1JCIN8OurM1ncYDq0fR+VS0BCv7nDZ2Q432cmnfkjBUQR1 RsN6h5sdQ0vbZXnbXLO+dg6XjqXm04MJwphjEZfPcBOs4gJE2IYjXCh5YnlM/onVNy95juU9zB9x X00eVtutkShrPyzwsbKnuF5HpB1TsOk2ZRDZ0B5JkKc5buQ0s6wqywXsyFYjlru0kIHGEBR/RF6s gf5QcQieLns/Z2OnxEgbf5ZEHWM71Unk4cGqsIOEXVcHndwb72o6mz9GLk6if72QTOApGCUkTW6W 6efcMDgmhiQpSv0YF0kO5eQbzXRhDbyf7hZdRCNSiFqCHAYym1ZSVkXnDmE9zTMSaoBZXJ8MhxqL WgqtXT4NiurQmcYnHrru3bmiHZ4ei+p8sOMAvaF6QtG9AXXd25GXq7ZkzuTiDjDYeZHisXMWTbA7 QuN4HCAv8jJt4scZHaodue3NQKvBjmH4rZdVwt8mz86Vxcb2qPJ+eeslcmXxPSOVMX6q/4IOgBC8 0eUTsBvuH6jm9NQTwY2S+H1oxUUsFssupApKgOQIugnoUoWws0uXi5MpxfNEaunBXwNNn07tVA9Q HQOhOT2HvjhI1Rgh3/erikeKEPqPWk0OCIPiaUZ5m+7DWGKzoB1OWpW2LZyXlgUJCFcXZrc5xV4n tZO63eB3u1ad9NxKH0ol0ijEvd2YJ1KGGpF52Mkup0NqWP5TMOgCC3anQ5yKh+xZcX50UfxFfwWZ 4IU2qY6HbnYBdUEaY5FDqUBH6xWLMOcz47knqEbODSkyS9jjCVWTdd3Qpo0g7x54QlFkjYXRhfd4 Is8zYSGwg2oxYqAqlzPwULVPkWOKeHdGKEz3ed3ZqtWOQS86DCPysNQyeP92f8edQLdTUNTUWn1l kfy/mebVGIsiahddqlTHoQcsyHKwxjp+w54a+dRftcjachMYMVnuDhxVaa/GuTw+GhzbQtXe/C0v szK/amc4kLXLFLChZiGAlEN+wANcLMAxrKVgGU2bMCzBgf7I9ygJyOgBARW/L8g6n47XMjk8Ga+2 ZPSM51k0GmZrFTGbTMVgLwwUtslk3Lim/j98k8neucyGYvmVu1k6fw08o/dM6350m6qNmPaey6Q+ NIOaXQPTuFhR2kNb+cvlUk13D6cKi7Sl0P1Q1rChJiU/uuUhRWj6PetonPg43koOil0cSBulCA/B vNIebuGXWPAgXICimk76vX8U5aWaWkgOxy18p0ed1+CL2iCdMcrjOrub1iAC+8L4JI0iLIxA/UV2 fuNvFjVZkduLzBvwFo3/HflcWJmvx39VV71aNxHc7d2P6d06tKtWQfOeErEnUObuNO9IwhQWnFNU 4X5hou28Lzkw38YXuWPBEbloVjMJ7cveHhj9GycCZXgPbsNDLgiuQA4ducYoghDUo4j6IMNHRaEV Rzkcl6MVVa31HpmBEHOSDS/XV8WQNX1Xpoqp1dlpNMZnMXB8XT/6teq6tTNz1eKm6izknKN4TzFY CKVCMRiD31C/Wp07bIJL6AIIRfhtysjD1ioVIdDH0PrNeL19/NLkiTTyDuIoejvXWpT2KYbzSr09 8UI3ANVrc40avAIUvwvUcFzdopNFamDVAC+iY8ThDufljrijhgvCOHdVV9bqk/ipX8+iojoxzng3 B7Wr8YMZQ1V4O0XkN9G+uAM2x3jTNNlQ2cc79r9poXSH1f32FJ6iplW/I/pTEZtgIVcv8bQOFkAU RcLs4DTrozEuIAMq0HSPIgBLZQFDBBXtj6mNTkgVdMgJr9AKMUJTOab2aImSOtrsLlmkbO2oWZ5b OhQPh2h4XrP7Uddt1tYxW6nbxNk5ea6rzo4D+U0wjaSRoesfY5CwsymAA/jhEVgeMIJXoKIlgbRW AH5n8p0FkvTMD7SVXRf92gmaHLQLRDPXjQx0p9lD7AmIvMrq2rKGNRvMIt3hnS0frdmGCXtrLiss 7G5CBGpTYoDxMCW6pAhmhuN0TYuSASzu3K1Sq6Y0c4M6QFCBdX+EoHdggYBKdTQNSbF058MsFa3D uwNEVdqSSrNqgDkcbKzx3zDaBodjQLXjxLkdJV5aAY+kCHSqxntBkvkU/ngyXt3y1XQYCTvGzLnS Q22VF85BuZWSzH6zdmmPy4fTQ3DBwzme2GR11TnHrcSiFLY4zI8mybhMgw2fiNDIDVaRApk8ApWg Qhk3Qt3joiJDQygqIDBeOB+2858j1E+0tvjwlrpOfONNL2/Y/mjnsk3QeG/STTvo27X+9MDqdtW5 uR9qxPre3nxbBxMtQssHu/gwtSOxdudI8rK23GDLSBXL3AFJMsYAfofhW2Aa/ZnRPzIfGlMMtPCc 28fj1VYfKfXxeNuGY/OQfMTrG3+lPWrQy6/TAowu5TEQzStwDpIVNWf4mJjzre+sJ6MiDTzejPR7 Ue5wToMKptUTx1v7qshpluJOb13+mEuVN1lZ2Av1av5bmeIfv85vx8psHeiaRRc0rWlHsL4jf4ro SzzgzXsq5gfc3IFx2vZF3W3iU2WQsubiEDXNRLxZRGPqcDwkBnF5Cuodls98fcvHaMU0KObycMJ0 6PjUm8NDB3v1GrIBhkZjqhJ9qyMiBh3dM9IjdhBiNZ5ntANjaS0IXKX+bXO5nWd26tyOD/dv7qTC Ip/pN4CwLxyp/KlgVSAHJDiwYDXvJLSmdAgw1NdO0RI+eUiiRKP0q/UYGdBjEIFNT2cRuq3jmZoa z/GgZ+PV4tBHdj0GLfxKW0A40K5p2GIWF/TmpEI1VEdiogmjocLD6KCwxwXGz3qMH/mJh9w2D9g5 VakGk6u/6igAOkXR6BRgKwHpxw9N37fTZUKCmtnD/BSS4eyahg0qZtG2tACfbPxicdH29iJG16Vr ynsb886qt4NXw/3ZyK/sJfoqv2oj/z2IQumPO2U47tSpNZyCLh5e/yWgUwgnhz+ZrG168CLTyxJ4 3at8dxdvC/vSWdNXBlAMELeyr57k5UafqC7Ej9MwxG/z5SDeUTGmtwRemYBQ46gjJHczhcErgc5d pIDHKQoOQsBwjH8rYEQqepbqxxzpGd9Z7Ttb6FFFv/1Uv2qr8VWGa1J9TIRtif+oHxUH05zGfwyN hShCY9iLxmiFh1xY38T46rA81EUxn2EsnAwI0z7tfoYzBKYr7tQX2Jsh3UAJOMYpB6The8NIQ8cM 2D0MQtET49bwSQW8jSLIHbTgXJCHlKRbE20b6LedKahs/aYxdlkB2VsJf40JVlyDeYygWTmqRe1Y hqRe6QgIAQwueIDaicZ4+IWcoOVh6MjxHk0DfWAFSPEjpF5LslZ8JawJMVyXIs+PvJ8B4mkex8gU zmwNgHh6YBBUYIDaAxXCyJgsOODzGxbgQmN+nGoC89RIr9iT4I9bEX3RpLY3eA6Fb8UpxkMHhd/c vxWZpr+qsf73C7w2Fxg2oCZ4jvvKKGY44zk+kN+dMQp7SSgv2jJ1Ry7C6NcXHN7ZsjO0bcGhqApb ALEVYZVHrTFDh619r4UGvEcJAc7gOCjoD+upp0SCadTdfMp3Si/hW6/UgJ2wMB1yUSIydzuZ3/1m HDcuSJ8PjAFLF+UOm0FKlTACTBK41Q3b2rw7uFXjPnDZVzPzrsPN5IvfiNwGt7ARWdkrQvZprKV9 yNtoQ2F60SiEgdEwiFgLOGoSDYUG3bszSTF+e7K1g4+bVACqiTdoYkZ/OAeKAc57PU71Q4fkFvMQ 6qZTVFBmVXnxaSSjMSxHmFRDLK6iYWNlcpJzJR0NskyCM3F+BnYzTub9H8IJBymRN95DZxM1d+r0 wge+xrdGy9xywxU4zHbmr1l+i37VYfxuXV5V13xgH0SEWOHmYtgEkIIWJXvqzXMrx9lh1uYyLeop yfOQi2IAc+MpgY9dYzRNBSRDFioA0jOtOAF1m4PGqAA6QS6NceGhd2nXYVh/IJ2mGR2ZahJBaY0B clTLkB9Ja7dwPJ6gXv8QW9nnWdNVlkjEAycayDuy3mOksW8ndLU/8nIPIl/e2VExf8jgUqKFyfXy fGQry1iejddbexUThMKxVIUZDS0SK0ys8OLVBeoprniIj3BHUqdODCwJyPiW7pzTND5CY+qTugul +7hITT16WJsX+JTSCZrMtvG1ouapdKH0RPca0yiCh8IFKih3qJ6S1vvoqHd01ts+1lSPf7aoAoj3 5fRNOdinLu0DJ3FLwlhBL4BOVewPe6N/b3fwho0Ui4sYZt0BKEOtysyAlzbpwXeIqMFbXNBRaC0K Q6OI7wMErf3dUUD4YC/DAP6LiOM3hKMZNIZ/LgqF3BoC8RPNvnFallYQgodH02wLRZuWAXNb+7ZD 46kiyv7Opx0itz/zaf8lNy+VeUOKNf0Zz8MPpnWbBOWpFbz8bfwd8Wn8NHfTVMNMyLcfn8retGcL FPu/kTBhMvUfkT6DSfeZdvUJfAqo8Bv4UUxSkiJPxhm87eQQ1c506E4gWw7E1D8SfztMW3SV7b1Y gI5XZXQmtJCZXXqzrbCvhBb2DeE1cQL8w3rbxyOx2J4hHo4VVO+e2fjR3wZmdStuWANTwZ5HGhit QR/8BqXyEL7RD8wSJ+kIoWgTfoNKYS0l7bV1AUrSClL7kdGaDSmgx/7uzRv+s4LjZ4TGDTLQc2/C c2dbt60/j3EPeKrLs7JbPlIwW0K6S+8K84yyzbOhvz8fxC6bwt7pi/0gtnd3dRTNIwjoDwOFjr6L 76u/aK5w5NyTVVfWpXCw+Mtjl/Ckh/CBJ1tEDXMdnB6ZlGT+Mla0SRM/alLuHVz3u2gO4SprwE6E 5dNFtVDKb+ELrqe7z/FDPFPS5YuLv/FahZ8Oon14lPFScRgFTfw3Zu1F9kBk63/IeyHuuBUBezXg +AfT3R9QD39MfZxf2Mc72tQjcSmlCIEnLRL78+niqf8H+fnEGgplbmRzdHJlYW0KZW5kb2JqCjUg MCBvYmoKNTM3NAplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9S ZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCj4+ CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjkgMCBvYmoK PDwgL0xlbmd0aCAxMCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBhZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT9StTtmXVTAli nX13nRxnp5ndLUUihOiYdYwuVkSHiE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+MDO/eZ7/+3y9 wwBVj1KOY0U0YMrOu8nemHZ6dEzb/BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqUsdb7NnyrdpkQ UDQqd2QDPix5PODjki/knTw1ZyQbE6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5MzHJdxIjvILUUj K2M+IOt22rTJ76U97RlT1LDfyDc5C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4RYPFQxfY96c9H 2fXKyxxq9sMp0Rhr+lAqfa8DNt8Afl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb7Gb85Br9i4Oe fFULsMA5jmwB+q8ANz8C+x8C2x8DiWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/onXwaIXWZxtN DVrKsjTf5Wmu8IRbFOkmTFkFztlf23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe06OomN5DvZ8ye PnI9r/cZt2c4YOWAme8bCjhyyrbiPBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334udSJBrqU9OZnr l5pd3Ns+MzHEM5KsWDMTnfHf/MYtJGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsYGuHARQ4Zekwq TFqlX9BqwsPkX5UWEuVdFhW9WOGeFX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l3983xtob7imXPP msara18ZV2aW1ci4QY0yvqwpiG+w2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8NdSlCGVqxDjj ya5l90WyxTfh51vL9q/pUft89klNJdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxroe5VD6p9aova Ck09prarbWoX346qA+Udw5yViQus22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0+Q9NuLmMaQnf Edw2cIeU/8NfswMN3gplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjc5MgplbmRvYmoKNyAwIG9i agpbIC9JQ0NCYXNlZCA5IDAgUiBdCmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3RoIDEzIDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnU2X3DZ2hvf8FUxW7XNkit9FeqeR4ol8 7EiROpmFxwtP2x7PRLLHlh0n+fV5AT4AedksFqpaLbe0qCaJj4t73/sFgOBP+b/nP+VD0Y551bZF 3+Tt2BT9kPfNUAxD/vO3+Z/yH/LHT99V+c27vPT/392oTllUY9OX5XRrvjq0RVO15ZAf6rYY2rHO bt7mf7jO28rX5ef6bf7406oo8yq//i6/yj/Kr/+e/8u1qNmlJ7sLPVVXdF3f5p6ebI+eL/Or5x/l H7f51Q/6GfOrX6arb6ern/XTxWfffpRR5Kv8+rOEQVzA1Kqsir4fq/zAIFKY+vH9MbUqJeWuayI9 aUx9JsZVdX4FA7+e2PmdfsRqeCwouKtcXPU/XF32883Uw89qTAK71d9lAssStKDq66Kvx3HFoFta kC21IFVgmwDKdrWy6jupZV+fomfSysxrpbTgb5MwwD0SkrzSGZedaT6qQ1+Uh8MundnKetyBb5Ll Pt8OQ3Hom3P5BsB/nOD3ZuKifu6Rb8NYdHU5W4hJIy3gPiTjxrqoS1nbYLG26MmDICPgYNw/IuPS ORYdVZbmqMSsojpUD4ZjddkUQ3dY21QrwdscqyZWldNPtJ7p9vJ92NnP1PuQX/06uUKcJrTUhsCZ 3ETJXuDy66Etqrpec3LX5SeHIN74ZheGRGVf1H3Tb+nCWjdTQ6INZ3DKqMUQrR/7YjwoVtsL0Sbd PI8/F4aM/XAo+sOQENzIN21CHehheH8xQcRfJiDizKiOpaHCuwnH/OD9qPdmasxWxyVSnTapTrhB ERrj2XdTY/87kaR6idqwIe28POH6D4odq6HO4W6CsMVdiJ9d1yIaY0Tfb/ETA05Q/NNU5NfpBxbE Ij60fqtnlSI9+GoDbs+tLIgaYiwnIYbqBHwIgpLRHnlTZ6mfGztPAtkZKVE99LLslZKqCd9bEvhd 1F/BTTN09RY9tx0NPLU/wBnu3yTj+AKrrry0G8tOXDRkZ2VRlq3yUJeKXt8ccZfkmb9I3Eo0fcF7 yTZHGbC6GVc0Klkuy3GiMTtF448/FPdMZFUqt28UZK84uZcSn2f/z/OPVaWZgMNwi2uGnpWCyES9 dpajiokjmrxpsXiG6pNbzqrvYhdw/ZtrVCkqFh1bZW0GRX1PWciR0ARK0jaW56+T/aPeEdPqjRPd khJTwfaOrlnNo2Ts1k9J2P6iFfShIa38z0QZphzKMNdxRJ4ymv7vqYKqn2cvwxRSSvJcD11Rentp NP2WapvkWYO9NYXUlkXXlGWTd6NaVBLX1sW4Nak1RUy9oqHuIEepHLRv60Fq2w3lUNZjPhblODon qgmo7+5vjkpzPIW8xZZBvo1/xGt/QA6SRISIFxH+aKL0RxLoPNFCPbCy6U2Dw/aRU3aFvoGn8JBL 2gHA3ESnoA3yfxNRTu+gcVOLN/XAwtpTnIVgYrPfQGLUFR+GQFukZrIC30+soqjcm7MUcJOi52hs 5qqrp8tUJ2X2tR6HYuwbmfYJSQmhdLJlv8Bnz5lGNxbjqHmUpMlXC2mubNgYI0tv6RCQLRIEvYlF iz4v2SwYfewfGLRKsJlE0BjKQ9YBTTxDL7kJSbZpqoMyflBWRkYFWgH61ruAeZuRRM3x3LJYp1sM O1f0AAu4GRMhPMjSyVjWM2iIgJ8UYWAQoZJOG7LT0dhm6rM/e9doCUKTiV3eA7+How5lcVDYegd1 gLfW/AG9zcwM7MB3xI2cJZNEm3SBEagkha6tZJM6M+pFUHwycP+2uO+YuKk0NTPK+VsiTQwak6Iz l608dM+LiWfL2VZFWx5SYoJkS76hSulzRk1dVFWbMmekGJ3pvn6KGiVEF2vU5soa+6d6toi/f5gc sLWeGDxrVrBRWDpwvVYSH8l+4boQGdRAg7iibbTkqAv5Kru3pb5RNqtzHhxG36vNKlxGPdStQt2m HttKkxTzX7srIzNA67oY6ouXebdj9KNmJsbodan16d6E6PWomd/DJSH6+2BDpfkJUZAgLunFtcNg GWNJ4IrbRCPeCftTvOjWl3Gb+/j26mWDBNq8mRqzqR3PZle8SIRjyLARHtOY1a7LddTHEdaRBcU7 V0ez1Yr9I/F5zm4IZyy3LUch46+T3UESe7xgApngBpZQgSvLLoigaaozTlrhKjAB+fhGY25DUQsZ ZEC/FKGnMLMRk0FvDIHVnNNsxAHbKrp0In7J7ZQSTRYj7ys5kEObN9phopQgqHBVdl5z5wmCqOqa Hupc7rBMx6VpB6n/Ben4KTITtrb02v5QN32bpuuweF9bvA5c4NE8vANQPG6iCoCiRI+2UJOoH97+ AB/ABBYBMVc2d0CF0IEiaGB2EbL8rqPbItOsb/BX8lIBWaU80aDooWo0gTNUa2idOW9zu9dU31jL FzSNJpzOAMpm8LateaedoxiheS/n1ecJrMs15oxNX52il7ENK5y//4prp6lERfSb0ertGbWEaJUi EdW4F29Ln09QB/9oEWrAFTppHdH/qZ4cPc/s9IG1GujiF6rgIlgezpndhoptbes7CqDjtq/qh6Js DmNuOfoAJKzJ2karQhtL2CsBb2rYFnuWno1dj8npUdcfirK/05raP0u6fX71xAlZyxsYXuuoI7g8 8DDDNkTcdCY2+Hi57CKuZIBfWqMn4hRr923wARpZ2gaqwH9zRuK5uheK6Y+SjIVRk/9xkyIwiB6+ nFp55caiCeRP3a8i66dco7CjLsfsqnM/+dWQPN+xgQWZw3c32XFVqTXZNGizXZ6EhbzKtANWKcFX Ik3ceDT9MLjXunIg2JQwolmaiLhW3kwDxU5pvG7YajvRQmjY5+7ca8qxqNz+pb1h/y4q2R00J745 gRIndOIGNPhuf8A58It22ssLyVDkE+UNc76x0mTCJOSF9DDedMgzr21Z2BK7Ief8ig6pB02okm3z H1MuQxEUi6sQOVoF44qiy56yq1UaQVE65oqB2magFEPCvDZt88NA1/PMHrsg2QrmiVePGPHO22mc EJa8XK8SL3XG8xK9yE5sQD9mDnY2xDeNW3ts2rybcJiQNCR7qgsceZy36dpBm63utCRzBHVeBZDz 3VAXzRkAwY0gPTwcPsmCHgwBQVb8cWlW+AnzFrQSe/ADpBWUBFxaPSD1oiTmA5DDGKK9dQ/etNAf qKZp6gXFpTU/siyEkHCEH6sVVv+hybpnbZdPdxNx223i+yGNJtoPlV4tCfh7MPrQjNoNdac1GcvN qB3LdbIgt/jQGzeQzM1N8Xn7F/UBuF07+7czjZgoxltm5PLUt+q6oj00Vd7BzgTxKvgBxrOr2aA8 MRk+RbunUCuDolApTa1QfSiqpqrGjnRZM1GOISe2eVzgCapeU8SNNqCcxxtsA7zBrnIzBuneJO3h B8QAUawAuKMxivxtimGwN9z8fIog+fk3hzsF27O8nMPdCg2ykL/YPqym2Gd0DG1BYf4yRTEUtVYX AytLvgGbrQzvFuBPT3E0WnAYG5mHILyEtdtNP74N46MBd5gF1ZJQ0erf7zCn02ildggrkLsZvzQZ vNgfPBnCIzwEZ0CYZxZRQfgA23qypYuPhhHbSQVgYqdARdr9waRS8tdVrbKgs7gGvUA/Bho+DFgx gZR402XA9XPiHO+cNoMCbLKNlujhlr12+m8NB3EVcmWAiJfq+4H+MpM66ujuT5LK4Iu289Y6Gf+b Cr9lgLz3uHBHgF7zKg7j9gr8Kr8+po/Ee1YoiDaqlUcG4rPOAOtN9f+SM5jXKW1JBA1mqQei6I9W wKyFLiCnTarb7bu2P4rYeJaOrBGKSPQww0LYxma3ssjpX+H6XrpfzczgEX0fx7Jj1AtewmBrzNaE L2PGZ3T5gt9w/QQS/nifBq1p3GvcvQI6A7tdN/Bh1MAtC2qN5fTE7zEtQCyImZ8IMm97mTuxJaP/ WmZpm/4LbANAa7mDWY/65jMBeqLGJgJ9BBhzPSrQU2gUahgMVxS1LpYElJ7od41GTxrPrBpZXrDS vcmLvwutTZyViYbBN22vUEb0/BYtiSZ/FaDP68rHZ26bUpP3bS2sH8eWpgxP7js/avHX78Xtv7k1 T9VoPa8utTltA+uJU5jBZrw4bkN8RP9Iz9sYTVneY40tfgAeOABGyPObKWY/Il2vPdj7W8G+h8US t1lINuhihXTAad0H5nw9w+NtKz1a9WG8EExPm04h3vTuw/IJsiGJHmiMbqmwHKDLppYL7jCWjqR1 5+H+nBfUmlqvLekdwVz29CjQVqHFeTbeAj95NU3HhxRjFc7suPUCyOq0Ahhuf8iXxf5E/l2QG44K EKtSdsPSu+sj5ZQsCBC0hSAg4N1TRoYCWkQBMxRg0wJTwS7QBT0C87SdpEfS0UzvfHtVPVuP/nyl ijqUA0qLadIB0184KxRzSWxL5IV/Rr9HBupVHL2HazAWQhku4ySEJXmkzVjPqzgVArsoQ2twTcbz /kCmU3V0Po8CsTNAdp6SXpiPtINODNJ2qC3vtDIaxyIx5G1//vzRhJAIhmVC+FrPEl/+Q/DLnODI rBQIQ6gWBjwj+uGHjNfqLGr2gyjUmqtFLZh65ajX/JlJIqLXxWRZarha4Y+e12hc+hE7fJrhJuRw c5O4zGU4iahehVxJLywN2rNV9oc8oChhvjgZ1ReY8hhzte6vJuwcOmXKYZ39WZkMxGrPEVjJE9Ag HissmlvCK0IGAwTGrWfAqgFZK3KeQRP1wjwuRSGGh9y0WQs3vTWNr1ExlnX05bXCeg3gC4WyopPx 9/oeiGFoMAG7zU07pg31za6iwvq2rZeDGG7yY2mih3mG6/40oqm1HlFpH3tA4IPRCJ0hVTYpO62O mXlrihAl/IbDZ296l3dIlMUF1qCq5doaBcZt8tiTjdOGsUyPi7XKNjZaRD2dEN6FHr/TaWdrw2ws W/fGdJ+AVEEjaZelD+AkW2cJjuy59M+e4UmfT0Vfu0vNyoGmybpGi4QRsI4du2aDRW5isqN7XR4j B5g3rHLsHsOiVu4PorVSNr1hp4MbJxlsQeJ2FMb4MNFwC5vOM340zAXx2vb2Pg+LrGu9WN8MimmT AXT18caL/lsTLheoe+32JtRaY7O8XLyoePL0jl8l7Hs9YaTW+mE/yjski/suFiDdIml5sunCbqLd TP0u9KRbJHnRUtvv00wSCmB//uRsiTbixsTB2ySrMjZy5hmas2ltotNbhug2RLI5JWYG0jBI9DDF RutXgjYjl9kUuaTkE6PUeyfAXqBFlT+DYJRFQgaTSdoNoc/DxKWJauUOcwwL2RajKxN5Hj2Xzm5p x6yCvBQvfiyi2nON1w6/8+YgjuQCSAlQDakJGF+uV8V4GqwRjgPuTeCDY5ALFUR7PNvoKG4xoWny FbplEFR/NE0h0XTIG2iU+hTlivpxvcFHFL5IDBlozeYUDBcqaIxZKm5S75locon+8yk8eZGsdxdE h3rjR2/96OzmNh1Xd8F5ui0WYTo75w6mGG7Gn+VMUIApjLdZHNJHwraIby27wvgiYfAZGo1inOZr JD8vzhB1PnHXCjf/6O/HbJxGbEhpMQcQocjCy2oFJIT5UkaEjlnQ0cwS5HHZxHZvIU+b9AQHrcdg IZSR2Y4YBCTRSmDVp441skLc9l3FDduqsggu9/zQhj54/O28h9HoBfqu73rpg8ffVmQcV8+m1zA+ iDo0Wi4YhtQ3xeHb/s+OPgAGJAYKMGBI+rFEpDTL34yGD9tIEdsKeLGQoggVNHnrk6Wl2OOrPhYp 1hXRDPVoDd9FSVsdYni29FL5VVBjsOy9x/q1CnhBM3a8UPHMq/fSinsrwAJ16MRaFxqi2VsGKBH2 F4RfjV4+PTRtnQecPZTwS3me3uOOi3kuq+LcxpNZVS5B3GtW5Y75FmlNboncjVmPxWSAhh+gZ3dA oTlEM5TkplUAkg+LToC3t6Ni0ybTCv1NqM6ugqUOKH/i0B6dWn5VJBvpC9BaOWOo10ot33//2Lw5 uFeotxe1otP4gEcjN9o7rjXmu5yNXEuuyv0kzsX0Oli4djJf5gq+KA8xrfh+rC8A80WyaGhBmLXC tgb2FrTbZ3bLDx1CRXQFnjRoojpFqMAzm/DwDD9IhWC67cPl0PKrZ441dRZC+Nfucj3DGJexIXLf +C9T/xDWQQH5PTYAHtlhwWJ8GSZEDE/0KBcFUnqBcuh0ZAcgfDCRVCdXV91FJ8BB/FkGUkAFNPwk uUt7MOfcRM5WXMDPHiEzoWgjhPDKSKZgYQhRXt4xtaBHcAIZVqVoDPDwjMZCPvrCgzqAe37ZfEpk 8quw9k61oCd22OQpANKGOEviYxJvb8Inbs5La47N1hdytUR+TCjgBMKCg/PLInfUip3Fj6buFWfV irOSUZicXlzgSONaTOO+4+ResPNrQ+8hgkFA2OY9qEbD61UFcSGZ9a5nr2lBK07BEdQ/EmrnbUG0 T2RlPQGIsRBDTeN87tLH0RjAoT/gTitoEjfhCoCDK9xcuYwwOp4eU6blISBWmVA06m+OzRorlGLT ObznJRy/d7Dt8wC7hFmeD6MGeu1aKoqrOi/ZyN2/e8443J5BvRYu82EINedNriallXAAU+AGoEEk EAAlQBh8vnXzkFIdC14QTRlgbt0HQMTt+S7i1nNUGpTZpq2DgjSQS3/sDoZeblpFso51pThLaxCT +k3lZmSxX6/4lt7Q9tdilPzP5QGst1DQrUMO7tH/uDz/0HQBQA9G8eQXS8293ZP/AUrIkh/4DZRQ Eq5AFCilAmK2+AImQJ7qp13UNMNv+6Yp65RQSTqFSsbjb66jPCBqG7Pm3xIbUMyHmBizHSVKT/eW ptWYnzt/O08Q8DR0AnW0wA/Nrv2X923a43uP6uDDMW2PdXGZw9+D0Qe9R3hok84VSHaMPom7cBXU veTStkmroMdmuJ647GHOgV+RTLzk9uf61c5w4AJeA2psaAKGwkML+Kgo3iRbFKPHqAZdvYaAf4Wg F/z+B7+fT8Y9qDS1gCzKYu1EWEWk6NJhxkWMkw4zpjObBmbvzG6YhY2AO/THFc9iEc8ra3cCd+EZ D6nPyHimtqOK6iyc97vbp3FHQpTKTAIEH4qKuq8mVDqP5A4uC/6tw54zN4wBPlTG2mams6xowa7d uWUXBTdRbr8BYp1IwDxUoHcEVrS2vBn3n/AsQtGHWXbehDZtkTike3QPtbZLlb3O+AiyTsCezB/y hM2QzVVQKwQDS6xaIkI4Eyb74II1Xr5+Nu82mhVx/9zSSyb03OuN7giUwAyyJJN8xFnuD7g0Wg/6 MlWf4rqPuSYYjhTsycs2jkImQYqbxlH7pOKEQ1KKQZ4UGkUvLSaYSJktbuxino97PnUcHNqKVtrz Y40L/KByM/KiPkU2+cA3kmkaQ0QFC+2orstUB0hPA48WAYUJs4nFwrukgzrxe67a+qJzfPSJY0C0 helVQn1evHXhLq/6oBNB3JclHshe7fpQFvUh9fBqNpj1wuO8dlSvrnzMIeEugAzinumm3f/Eyrkv u4HHGDaGmk9cC4o1X9ASDf+B2zRh1d6Xya6+cGXmSQ/K8ENFqy5H9MSPj2eBDjwDqgH80WkUjJ6o +NQPYL2/IiF4hNJ1T54o9RTjtXSNSj2qTcecH7TV+AzEJGvUXWa4615HMQ1hbXZ3hjuZnrtkVHWn L6yO4VWx3bXrY27rFeh+Caw/16/0Deh4IGUhGIm+zSfVIM/iaOkgYivgCPcDRtMcltfWDYcVacLQ UwSocrVMmvLwvThGFuMrj2ZagdDgRBmMdUIUtSrme1prGEXgE86LNmmFZ7AkRsN+iYJuN+cVrZek sdmiLDTzvU+6a07BnU0UoJcQzSarwp1UU19Y7PTG/h0yKeQFMiLY/aI5woDTK+wCqQ2Yxnlz32gE rc22gOkRa+vVcW3XPUBCumQRAomQD2ngjFFwc6ofT9+GKP0s4HNWIu5POtn9dk+t+H/sOiVDRlzW cin+Xx50MlsuG9QyCmSB8Bg2ylbImM1nilDh2lm6eceJZTtlaI1nUYO9rXh0OYO0cdQd4b2ztuu/ QNpqW1Jg0IPRr6YplLTdZaYimlwPaXBqPzqAKiBTEIkUqICErNgAtt2tyU2kh3aiSbSC6tAYUufZ vJTvHCLAstWxuPRgZz9syc3Djhgf1YPX4dJST2u+wxipUsTqP9RTYWWprAaReVFj03xtdjHr2sJS vG9H4w6dODhLAfAejCK4TzuWYXnXTFyskrzZcMFhfjb1AAgGEKRP7VgJWbWgw7AGa00lFSljkcFN G0B5SMXXFoApKkDT1vlghWlsrYDeh6FWkE1/AJp6r5y9Xh9ZEWNL32OMvCCDodE4RBXOGcR6NP58 uom22PcfLG0MRtZ/0YroXqjAnrO8ILbRFh+3n7rJ62TIJYdaG3N3yW9c1lLNQxXWWW/57uXZSJv0 HD2H1p/o/aU+cVmJq2X+zfTp7qev9c2lva8Fvn56y6F+rPcu9IUvffh+emv4oJNiukqxYVbX+s52 d9Bxa2VZ5W/zutInXDrlUaP+5W/y1z6Znas7j73dmjNIqq0P03R10brab93Zq/Pl1Njjp+/U8Tud nrszBnccW6XPkzWddqn3mrcpe30F/O3GvTe6V2lwWjNwXwvvtAHG3dKeDrfyHapm7t66uTf59zpb +suJteuz6LbH6DjW6ZtWnT98uPMjnK/e+LNm9SwwQDfcJ1cp7B4vC3+fOeY66VYuCOoGfXJ89KPQ aF3T9oaqj262uGtiGX2MTSzSizW9Np3VrTZgLu44Ebo9/qoWS3Ev4U62rKejdHuZeEdBaEqfUBCe DguadBJC51ZXA9nh+iZrxY+6ls3qw703emta36E+CGvxXqvPIOhIcA0mtL24MxGgpuZC063TN27U V2j5AANc/9O9LLBuQZFw5CQwk80NtRRHcqTMYqyxkkNZnf+WrpRalivLrOv0Ba9Jjdy1UMX1Gz13 6wbuRNxwT98402GJfasv1OqP6coR4JT6JrPXe1c3U91eC4S+b9eXGuxlELrxMKoletYpdXokstwf NzLJ7ou9+vON/hxKR4a/lHmZa+uRu6JtIcxc715Rtgtjct2orTBimTE6jRzxFMUrKIzX9qm5El3f e7O3a6GcxgYMaaT69NXgdHa+BdRkeRb3Ji29G9SE2KP4DLpHid/RZMCR5ejjrelA/1aYGvQ1Fr0Y qHMzZB0qnVwwtLLalVanO8FvHSNEU+mMdTn2g/Dn/JH+z5exWX0nbZgTNH173BXk5/rt5JVlefXN p6vPXub/+fW7d9/+qtBIbzf5T6Cf0wex+NxHI//ajlKHclq808kgdPVP99RDVZT0kB8eV/1jZfRV /Ync70tNvocxuX0ErT6rXbqJIcf3g9S00netu1o3BoUEg163WbN9YvFumg7TnaoPRR0/85fp68mu Nj+e63p7ZiJU6cAzF8pqScFFljq4mvyPKxe0ciyhnrFH0a0D6uxaRas2zjw9qmWEl7iQ1Q7KufSx oNWownCmUa2SHBPh/T+7KRQDCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNzExMwplbmRvYmoK MTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE0IDAgUiAv Q29udGVudHMgMTIgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxNCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+ IC9Gb250IDw8IC9GMS4wIDggMCBSCi9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgPj4gPj4KZW5k b2JqCjE5IDAgb2JqCjw8IC9MZW5ndGggMjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Aa1TPU/DMBDd/Sve6Ejg2rHj2CtQBiaQInWoOkAUEIhUtGHg53PxWUAqtYhSZXi6e/fx 7ine4A4bBOUijHPKW7holQ/wNqgQsO2wwBqzy8GgHaDTN7TUo5WJ1mvNqe+odsoapwPq0qngYina HhcNnEm9GZoes2ujNAyaR0gUaF4wb0jNQT3iP3pMparKOyQ94iR6kj/iSH+0V6W3nvVM/RFTf5aQ iwLnxkM+EzrINUGEfOeo42hLUEGecZI8HSu7QvyozMl7bnjlEjVpyCV7QIwz93Bp35yGGQP5wSve GLLsrDDpFXIgLnxNuxoby1FwOq1lMkf9SNLmByZzNo8DnUicZU4zTF0oJ5yZRLvX/HribkO6e08y DVvSPhJ4SzBak91/YhX5ltwfOZn1rgqs0NyklyEOvowjXqrVtYrGe9T5T/zrS/0EpKrP7wplbmRz dHJlYW0KZW5kb2JqCjIwIDAgb2JqCjMzMgplbmRvYmoKMTggMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDIxIDAgUiAvQ29udGVudHMgMTkgMCBSIC9NZWRpYUJv eApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoyMSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4wIDggMCBSCj4+ ID4+CmVuZG9iagoyMyAwIG9iago8PCAvTGVuZ3RoIDI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHNXduS5LaRfedXcN9aEVKJ94vexpqVLa+s0Upjb2zIfpBnJEuOHmmty3r9 93sSOAkgSRYLrK4e9XTEFAmCQCKRl4PEhf8o/7P8Rzmdurmsu+40tGU3t6dhKod2Ok1T+ePX5X+V 35fvf/hTXb76qazc30+v8E51qud2qCqfFO/G7tTWXTWVY9Odpm5uildvyt+8LLvavcufl2/K9z+q T1VZly+/Ke/Kd8qXfy///SWo2aWneAg9dX/q+6ErHT3FHj1flncfv1O+15V33+NnLu9+9ndf+7sf 8dOHZ1+/UzDLX8qXv89oxBVMrav6NAxzXY5sRA5T33s8ptYVernv20BPHlOfg3F1U96RgV95dn6D H7CaPIYoCB+Ly8JwDR8hk9U4zIHuDD5CGECTULj/U1zK8to391zjE+kpbquS9dCchmY+1Oq7x5Se oYeNGJrQC3nS853vBSohxQXCkzBuz5ZdYTvqcYC4jAs6rSkrFqYsl28b0ltU5a5prcfpNA7tkm+W nlLpKZxphfRS4H7w4nfvuYifTL6B0OKgD6in+dQ3VTRXvoMtoW+TcXNzaiqYfjWfW/ScZdz/BMbl cyx4zSLPa4JZp3qsnwzHmqo9Tf24NPC2B9ccqz2rKv+zby83TepFI5pR5u9R+1Te/eL9Mj0432sM gZHczJ69woY0U3eqm2bJyV38kY2HnBEprsRn1XBqhnbY0oWlboJ7WfjsCqMW8OIwD6d5BHDcw4ve qB3jz5X4dZjG0zBOD0AIFL1fvMy9gTzWQBF/9bcWS1I8aaOJiJhIT/dt8l6hWISYgoXxPeIq1kuD H+GV4JT/9YV95XWEWfgCC/sJWaBGJOKVv2PRVqlCixwQ5gssjKWwTJL7LgqLeMqWySwlKEOWfyKn IMa08QF5syb6N1bxD7wBxM7qHWYo1AVaKs6zt7yLZBvLUNxypNQ2DWBQM5f5kpYt+FcYqqiIgBnt 1DdeEXcN1TlsTJfJng2I18nHG+lSdC07g3LJO2a9KHtBAYLsuV5nl7J6FkalosgTRQbFcTQFoXNy yTL/5SVpT0z47LmT0uLuhfst7/x9efdM7uvy7rdMZ3ZLF8lL9bPQwRDF3uoSSyFzqbv8YWGqNt95 LaK6/g1kQDX4Po0F3wBNRtLPxwSuEC0EBIC/RNLzRStb1B/iAzGmPjVTjgs8J+mUHMoKGc2uUUln L9CEkv1nVMT1kL64oSLBlrGYaKiSOAVliaJue/8UOrq4EGzZcOYI4VwcobRdjfCRZ2yG88zu5yvk Lpq0fj7NM0ZOl2M/2fQ8SO766jRWFWNRFlUvsNc5wVPbQjn4nCbmM5qcT0TXg5WkJKhcUfZoMyhl +pC3lBqKEoGCFSyaDuYkIV+QgN+RoBf8/SN/P/GQAyYy095cI4bzeKoHOJmBfM6Qw8jnfcMKEAc8 wsZSpS0jaFjJcxpdmnCafves0OiitcvksUU8rM/a7GD6HVQiEdH0O19mlZ/FWAdE0ly9xd3KaFzb TYhmXLAWbdueunGO3XQG+hfXhIo3xabYtV7RXHT1qUOc8Aw9PnQd4itkqv3ZhCDsWvZUEB4HQdiZ LOWh3oFuAcY+AdosWy2HBVmskbRZ4EC6aRno8lgaX0iFKKgHNemvXuWZkziMhb1rKKS0MqetlvX9 7CEN1YM1MCezMJF3ZCwTKfpUOcbumXPTl/IZSYICZurDFe6qbapT1feASUb+dhH423FXbXOq625z aJ7prvIE2mmC7XZ2mBVWGimbGPTJYajvvdBlGOM9sQ6+zZlYUrZpmhXzv6Cf0/tncm/GAK4oa4Kt wENrH0/IGpnmmysImenUJyBkGA5PDSHaLiQ6JvM2/HMpxh59QN0ihj1v0nM28DmgszHCotltzF1r 7mhW+PMZhFWExEoFxY3CYcXbuovPKGTOyIUhAk3eAthlqFeo2OkjadwcaVuiqC1ndM4VxhZm6Zzz XcxpvcaP4BdmYO0I3TLPOiSWwixsUYA6aTP3dPwT34X8+fQx1bSFdg5VXw47YrgwvW9HLTDz27Q6 i27VdKEWD6HnEnQMatrP3Wnu2uEQwrfKR/0Kic4+fy4aBaCvmsU+/xjJiF1R0Ol/KDJUNz5zmlFo lIvvqVNgXV9mSxDQ7OFJuA6zhV09lsqiLTS7ECEMgpREUqzujBQvbAkZ4H6KOzIgYCtnC9/1HOP7 QeXcMyauqjRjLNodFs4aqc9XU/UXT9XJEMfSniFRjPG9fxgMgrMSFBZaFzaVgIDvhxdcG0Hp4znz tsU6jHHsFn386zvzfupPGHw/BDGSm/bHqmVxd51ahuBzUEsjcSrk7GSr5aTnvDcs7igjNARnvKET DvojSvNrCFyMz/7gASxLOSdbyQuqRqqyeu/luTgShd5UWso1Z2ZymESdpSKRj+BOUAiEIG+71KVt EVgbMW+tApjhF7L91BVDuuinsJSk7W+uD0sxdL7rCCjbE0NXmLW7FEMm8s6GDtjbtPSk5V9emPmC VRAmUgmWQM8ttbNAj0M7lkKtsR5h08/wBSpdeC/FpaSFos4XmBhecDxjFlbLMnWO11aPPEHi99c3 pkGrzJUjbTUiaAAPkC1g2fKeUsPVn9nDp34AWYNOIu7ixBh5JaP3fjS8acfgNihk+4Sl2c5nIo0r n1kDxztb0eZ7VjCYhdbuWy/4rIEehSrC9/jC32H921Kdh5UgZmEUnnebIRVSbbXPVkvl5RiKhT0X 0AO8+4K/ev9M7pPwxSZi+hSNlJctH6NGHpH+Y6tZWgyPxm4o98RtjXFt15IfSMyk8wo/0DYjZkAR dbGEPgGg1o+nediMdK/5RlnJ+LEO4ifIB5aSUCA23ZPVBQvzSgPzwrSJxWWskRrNOqIIyqiNiSFn OuxfOlI3zNuk9AyeS70Iq7VtonJk4Tnnea1xYmEs2gK0YGucZ1raGleYpYXmIV/k6QqKAxsBZNJ/ mFp4pmwRezueCePiYdS54Nt5JitBQXScXChYtvJI0MD+ssaTOsZEJ3NhNtcqF+WRPoUvMIv1BhSo vxks9jzf8D+eeWzq6jTU2H3Sm855AuaxnbEWKmui/u0IL8Y31fSgmUlKiDXiLygFFGJiEU6PUZat MFmcztI+ZDGsI7VZQXo1osY8FuiwDhb35zuUhzivUueLL0JQ7s/vZPvsDSxbVvvTwfVcnaYRLjuf 5w+RgfyQJ6YJMWueszI1m54rIE0c2tb1qa82J0oyIQRFwYrkJ+h7REMoH4QQVj74Hi0gX6czJOYl SLZDVEJfFrbprRcWm1lpsUmT04tC14p+AHoBMkgFQrty9/ERAT0c4Z0G2WEH9JvdA9nbejb05dLY z+36aDF9vUPOYoogiTefPMPIWvYJ2Y4OfkTfU2G569DC9zwJLjagorrQqWsuWihBLICfTLaht48K X9PUpwkj/KfCNuzsw2ZTzHac78VLbKPJoNBREgNoyuXlFaa06eZT3Y9Phpc9urZrp2O8zLaYYXU9 JmGMfN50dX0zCVJC6IIC8WQCwZXsRdN1BbsI91BgjA6Sjo72k8iNokw/aU0s3SXdVhhapCNQ6oV2 sB3o0PLw/Q2PXNzpi9aob/jSIBmWGqrgazNuYdNYIbOgMUaibrqKvUEMZ8AO8hJg50AXWuhABlvj wizsQjaeXGf/bIIUdih5YHtiMyTKojPGfIaNN1XMtsG+s2mEYpKNT0Uz4T5Oc61LG26nmd9AbgEF bS+pTmwO1K1QExm5vgujqJeAS3UVNkZZYbHqw7vP5Q2zoiGNf1EglSyaEQIJCp8+5C11zglvmPyn KLM42xASQolmYJ1Z2IB7zysbrSKPIqpJ2KnzASw7tQohUGjtHufsWaG1QmwSs7DMlSYZ3ThvYjYg 9KUhZ9vMp65vZ5zCkcribpAqe4y3Sc/+fo4wxusmnAqCdT8ZuprrtZxSsE8pLpQMyhDZTwFhJzLR iGLYLmU7k7LAQkNnunEZhc9qH2e2mcgXKBKkIo1ohLEeK+J7fMEWxiz8oQJRyWxzbSlBERy3KLOs wdLCtlsWbhZ28jrG9vHnYz/8sly2nHhOA8KsL7yvfZyDOlpB8TXg/AHBy1aEKxB6VAS5anVhy+2c BBfcW2Fln1JcrPBQZWwYzoqL2kZmpZxR9NnvtouNWvFIlrCclMWQDPu+Fcn3vTBRZ9gKKgRf5zO+ Z6WWL5A0VsucQVmcQtgm8YWQxWk6X7eMZWEkggaeLTqsZCyFP0CpD/EP+/a4xfE/84xBTUcxzLDH b0ctcKRLhRHjxt79zBgguW9/yFMrQexK9hOM6HX8dvuTLuxQqjEvUU/Q9u58+xBVSDcowf3Rrlvi KZXUZSrqu15RUl0K8UQmsrUs05oCyrbFN6GGDXhHuWfRX4hBx9y+LZSEsmzXiICk+OKIF+My997f 2bZYzWQNNAFW+6wbYw1qushD9jXRgnsjIOGsdROOXrAyU1Su8BA40OhU1fuislCFbM3cQG6XgrHR YfUwGS2OcttQzXVAjOzP+LGOgz3DCSM+s2Bir9dPj9kzOGLhNCNcWXaGFbu++1jXHFuzErumG04D Fq9s9MyvIintiCWKD5oYp7pa8XkuZmZzaZHf9PJbPv8Yvxgna3YWwokUTWWmF3wnGB0HB85kYkmM W1E4aVeDZXJ109pZYJ5awrD0nwvIWTTLpIi/BnFuHa8jatGAZ0I5jK62gCUskBep4w/XfXFYaklW S0lYx4ekhIWnxjhsSeAz5RlvqbPUZ7bLjofZyQhrZFrTDfN1abKzRQi6nQH/KZNPBuc0E5Y16nqA XROSOw52greKMWys686VHLfWKkiOE8VNyaFcMyf7n3cUI5Il8+wyD59vpje6/JLHqsdZzrhsys7w +AnEPmo5dm/MiX1ku40rAEZ0GxWCRKPuxr1KBqnC7HP+fI64QLKKk5jL4lZmpRWmlaHNYKEOrMeg P03IBqoMtpSF6moPvhGMaYpjaZk5IKCUsn7e2WcsJYydXWEqz6x4YaHZuEsG+qKaBd+UjkNJT2C5 uMawY2TF8isMbPaycYlj4AzOzkiT1bZfBYVUMuTS1SSYw6s6HDIs5wy/fHWBulL+ofdwVJ3LnX2E 7JFljVgUVFUNUBLISgg1xwkv+AZPcF5TyjA9dkZTnMRasaGm5cGURIZufa5s3516LJAiJ56Kj25l 3daUNcOaba+dP7sS5rcTYpmzzivtyvA5zLBpr78gkuRDTp18h1SgaBo83lkjHvCpy0lzt5RQJ3a0 pQpOz0iogxhWQo1JLfQ0baWY1k+LpeEm9OAP67LI5V0TumbjbM1aR+BKan1TroRZA1afxRXX1BVX HK/OebhE/zI2ux0xRS0mUCuJBh6QsGMSf+XZCe2Ikw2r7aNFHxJzOGP33DCLzygMe/t7PxW92d6t EoJK7Mwz00ROpCxMMQ5dto37se0nqCtu6aTAqtzTfnOsRTHUh7x17Qmimq+Aqga/Y2Nf8PePBHkk bDH6Y/mkiD/krA402VKnSgG5kO1EYmwndZeohlpjlRZZqB+PcBpd2/YnfIWgL1Uen4yHGlofK7x8 HN05j8BesD//ZOfuxQJoXtkpNIh8gaV5EQyBAr7Bn027zGd8n3cslPuYWSFlyhpbu6LIlpLqgcxI OWVnFquCtkzWR8HkMxZGUWQ4WgWb9FJANzmT+o9wWgs1gRWq/pIJNCSWUhZDapjz3cdVhRGn2Ygq UPSejCr02MCHAyMvx0APaYI1ZHYrPc0SZUh7n91uDT/zpIlBLfiME7C2QshCptu/IhBQC+yecJoq grX5vKOwkWradNrrjWaGWSEqyef0H5/JL8KXn+AXju1j/ABtUssuyvySeXxdvRBUQEojOX9iVe/7 VObl3XOaOuZlQ2hd2BnsaFJ1esw+cae8YwfTgT55O0hMTvuqs2Z/HkLPpXBuiF2JS8YCwAzrc07d Kbnsd0rnf1BULkjDtTp5mqt+mpoOHz3CCq2uhr2KV7tHSsoEMvYWTOWhhtutJGqhll7djTrYYsp4 cLlOOfdcLlWEr2ecqMAaaEZoEfl6ah/FcKSUZXbNGiU7mxIAuZqIZ+zpF/ILEE8K1Otal0qaXVuL O5oDZNmQg646YZ9XhV0gM1Yy4BMrHRbgrb9/pZJQxP6PV5AE6e9RZoHlbFP3NQPZFVN3YwOJ6adq nBDIwkesvtk/B+IKr4Dv+5wmfENBJe2QRzXD9Xhu+R6TwzqFlMllwmTpUWvQ6WLpLNhzasjPdOyF SbvsnjzL0QFfnejRPdJhWHjpemmSs8pxMjj2k+Bw8EfprmgRsRy6wmlvvr8uRfMvy3nSBU4Nl5ss DqxXVWGPxi4R+32zh6ByM1cQRtO63diXzC6tPjJyK7UEPfhemdADfzhOJeITiOFiHs/3d42T9h6l m2tZx9jCX1hG7HbzpiM+y4jtfVtBquWDZ7NanyjXE6DKozQ4yjXWw4xd1kzpZoPPfo7w2igszsnp uu2d0+t4PY2T/VlCDwdW/yCOCKDV28q4N5mv6qSWZmMZdjzKvHwWQLkb6vpyw6IyOjiOYOnF6X9p X1kMzayf6wp+dGHpCaq1EhJywco4uxK9abah9x7bVBnoumDnZVhwnKqrbR/s3NWQT05xnmuxfZS4 DLC7qQHbKn/ZkVX4zmUN/b6NK7ueEcEUNPOE7Y1hw/renF6IDuuHQUuIZP583oo511OPSZuqHTFB uqDeTPStyM12YStKMYRyi1HVcjf4HFYjI7dFN15pua9nROzGCZ+EHXK+53p57Ebcdjjou9eM/dMc 8DWvESdSzmXjm7GFj0N3hrP9aawsZKXVpbEk/qUNpvENwW5nw/m6DTypOeMbK4+wAW23fOJKkPZY tL+6vO4Bi1pBR0d6mvQHr+W8IhM5w8ERYb7TsuOGJb/dyosz/E7DUZHfb5+XQJc4vxkHax3iJQXl nEh4L4iZJXhDMgUnI2Y2TvCe+Y6nCkoC6s1Y9vw3npsBq+A6fN9zR5fOYiqiFDaVoXCKBtGNqgZv GZ1gj1PtNCDwUvAXNkJ+wcDApzYwYGtjuIj8ZaVW85jIWqyUMTEQ64AQY46siN1COMNn9vhKlslS +B4PZbKoKtKy0cfb8MD1cgqRtZfjIC65wiDOm3f0JCYIKnz4u+3w7ZwGq8vCyEgszDfOPVkHhdNH 5uYpwQwsIOyxgDADb8FBLY2K+9ghBS5IWjqzbA2cit8zit0LK3YMvdH+OQlbbpFlXXQfFC1Wwo6n nKo6MA+3ipFI+z6lSd/QX9ZFSU9FNUwtMwvroFraKTFKM0sJWuBijdTRTcNtSSRPyH+WEjhO7+E0 y3Lc8oQM5ntsEW2KbQoP+yEv996L/kIMLYteKrQTCVvDRmcH+WIpfMFygsu6STXZig44puxco+HW /eUqOz7D18CJyPHhdY91Gk7XQ2wy7owKYHTE0QcSpHo6YHSsTs04dHnKrnrAzrTiErrICR17gzl5 ZydsT5td9NjgDJ9HGbu5L5tDLac+P6OZ4u3ntFZ+Ni8co86nCyNChaX2U5KVo7wlnzg9T+ZZ5aQC Mier+oMQAmVT+v47pTNYTFbNHxak0yIsicaCD2ks+OwVZiRw/qilgC+wsdR9qjJft3ISzIMzAWwj a6BikxtsOJ+x2k1rxo9UW95aK8E79gJroECSQBZtD9kmEXbWiCTxmW0m28cfi9kjSY9vnAAu5wZz O22HVTI91nEGJAJwU2whEbzRSqhxYZ2uDN5fMqLncXEcKg+IAU25xyVY0bXC85ya+lLmu3NhLqRj o5se3UAhsNP2Y9kcajxlMMesUHg1pKomiJpIw0INZiIVK9XEsJ+diazZbqQP9uxXYGSDuCGANUZX +YzMPtfvhuECf2grZsUP0AngvRfpJQZCzNp93+m0Kcc7A590vaqq8bnhrQ588GnYAcs3Shw/i1Od dOATwNDtJ2qxpa2vUaGyLWPm70B8WGykGeavAotocCUTIQtreWVgUYvPsYrY1IdPz3Gx1/E5sC0D thrvHqEHc/w9TnzaCgWuwxc1LDGmtAf/A9GUQUJj7jpzR/vCmIOHWmHRIEEBjT3v6NV5Z22XQjUa NppN3qkptPiDd8waXbgf3aRjW5JK1eR7TLRE0TAuwZODzhY8sZQ4rJFq2TSWcsYCu8JItQ2d8L1Y ytt3cw2+bDTLJ5caSk/eCIRNVXf+ApIiy1f0/pnc1+YbPRtNu5Hlc02QqYUG3xl1H3PDOLAaW7gc ZxPGuW9Fr26/SMV94bTD8hplXobtg8ugLLDb+WNxUsiSSiKzRD3Y4OlZo1J+f2gvBg65b/AZFtuw /QUPkIlrFzy4ITqid2GADtFwZxMujTqCtI/SkxHqYt0MpshyjPq5aSHqxvLHGSibaAdkfMZe3hzo fOItMj86/ukmntiRgPLA9w7qFsrU49NTDTmSYRg2/foWPSvYdsTNyRoQzEdfXmKdTY7zukfAVg46 wPcixloXQu1qzgVBooGAeGzo+7YNXfFX0SMs4uaST0WP+P6MfNYL5zINU42zr4MB9VHzW3/fzO0+ HXAuGsJ3jlsZQgZuvRT3gtGjBQ9hpO+Ajd1awXADzSotqPX6/+d1i1poFpYUIaADR7fRCVsifkOZ wlnKUEV8ekS5lCH7UaYWYIq4iT/kYGSdtG5xBt62iJ1t35aIyVy2tKKWff4NhQxrp6tOF3ZkOmnU uj0cOK+RNc6ebGDGDunjuxAG4DsKw6ad/lyEEJhHkbCzzWEBUJ6IppVQzSmpFF/WzGcWZ7LvmGiB qQKxj6UdxcHTWZz+RJGQYQLF5S/XH5KytkDJSHZ39WWLRf+Yfz7UhZumP1OQV2CkRqh63Fh0qGDk S6zuqWEXqvK197AffgEl4IqrpJXR9n7xIfbOYr/93A5yFID8vRdvJxz9Xo44orSvRdNxUDMQJsIo Ba5rWOemBV6/L79wY/n42oVSxJzjTZRavinkXCTe+IICvVvqK+ssauECvkzsln72NUh6E9IKWQ7q 0u6RhiWiOPBAlqaibUKorCLvZHWqybYs7r78tvym+NKzMZ87fTuhRYD9cFUgKb0t7nGLMXFsaS90 amZ5mrwr9QtLpS9raXGPpe6yLQklYyl9B+4vUtA0jLexIBbjC82FFHGhsja3Rz9iiWqagjVQrSwc W6dlpaTvIZo8dV0nbQw1YvzT4zxFpChV+N7POALNKuV6j7MnsDoGp4jJSnGfByV1OLh/HiFhmoYU WesmrdGykxRPQYmyYi5StUpZ5zHv9Z4z4Gh8k/wrIlXsiYR2TUnbo2mxhdqDqxTQAKErm/KfB/QR wlAVWMs2QNzkGkqJ63tci+hjl4W7x252hDxrbL+QAaK/gw6jxngtV4VodpIWnuNIcSlTSmkmieyg W0INWMuPO6lbrl65H5SE63vJDn2TUancw3okJfAOSfKOe7L9H2SUz0GdlCnZtDWxBmm5r0auPB2+ /SHVk+V4ItwWFbtobBIhwEBQTMebIBhFuyMsyKUifFYMQKYKQhHUVlOiIq9TViYBjFFViyVFdTxr AEBBkouirymxfZoCU8I85j1yxqhMSHPBjqKTT18AOGI6CUYJu2lqRGvxLYymrGUHwTzPSxgXrJ9Y 4GoesMGHDiq5DcVixyZK1CUq+OKH+CD+vHxTvv8RVp3CmL78prz7/Wfln7766aevfwEG1zDBg+po 4SDxYZkaNbqqmpPQLlX92yPVEBtTju/Xw/sYgtT1BzD+zzDvq20KQ6RttKEjs13MsOmDszGDjKGg r+LgmwqK4zFDj8V712CGoulxWKy4VhytVPLGFxSiCYp1NumGJ8X6yxmHTBeNfOFJjNIbTcJCLSbd l25Jq1gs+N0W50giBQdKVgjtp5mWRTnYUB6GDR2GuEACrm3w7OktKpZTpOQpfGTvbgU1hbYvMiew QcY5wdXC/QOWoK3LlGg14GiZK+p6K41uuyJJwdlW8q3txGggwilJqzyrhPgSQFoNMCCALOaCGeix Vg4pihhqLCyuMJ2jROt9NJplyzSDGDRfNN1adkwhASlg8Enw8YozmGeVkL7E1qeWj1wL9r8InI12 XHmdNkXT1rk0JZZ0LVgQDzlDDjxwkOsULMi9d/NQkQQsiPIqGJBr5kmv4KSZOomY8hor7S1Y6Nzu DQELcqVOWq4jWCjcM+/mW5bAO5StYKDFdUyNV+E5qLuHwxewoK2JYEFaSkyCK6XDpqbPvy0OggWc tOiGKBEsuDVh0BQnqipiS1mJWqh9HlM2ZAVeNUBnau86ZW0HNrQ+1XGv9YlqUsijAmtb1nlUnyGq a1OhTEm1Jab5SZHg0HE2JMwv4EGCE3oMcGb1W2rzj+EEiSXHY0YfByewDkYQYx23wwm5NWzhhOYD qMZnx3GC8tsHCeBesjATjCh2Z3ecjoq8kFIcWMLYnGDpox9+fPPVzz9//Rq79BXD7NYB7zyOsjGb lawYHipJ+JBZNrzQhNXah8r+6Ifvf/7g2Y/ffXWPoF1OC3BwDHa0yR5Wz6UbNkDiC3Mv++UPlF1X mXRDueepl9DK7QmHvlcHefI/mKlSfu/C2VuFwLq2DSGwa+Gsorg3RY2Qht5lxsCaAcjUbYIJOJZJ EdrCpWL9HoasCNcHINsMYC8OAk6R7KowRbKIP74+EI5AO7ACR1uCoFx6D78n7UzBbC1nd4T87nny /tkoGPY/990wJVEwpjg8iRpcFEzT1CMBK2JipwHPkpQGcTEcE5t6NgQXJW2dayMleQ/Y4TRhPzia GcpvZvmuXY3vtiqmbRCEmfBBA8W04T5x7pqWYlpNC6EHbJ5k2QGeKgWAM6u0iGpDrlWe9L1WuZC6 avIviYIpjyPo0JSkPfL9BumvEOpAT7AHt967NgrWoc80CibXKbCVew9JOxisGAWDGqPVfIJruQL8 5BVAavocUS8FttjtuAC20ss+CiZXHlBivIrrCGyhGLj3kFRL8HcdylbgKtcxNVyFKJjQpFEwbU0E ttJSD1zlSoGtSWUUzD8/HAWrYG8GdGYEtsWesIRRUOj0tRiATBUElHVOWEKeWFJEtvpWRLaxpKCO 5w0AKEhyLQxAbN86T/qeciZVmZhmo2CyBxkdgLWRS3T7sCiYnMYRV0dvoK0IhK6Ogp2r43boNreG 2JgYBXur6FaM6RiOYy02+H0DdKuV3BAcdopuj5R9Nbo9UgmmuRXI7UH/gG6PlH0Y3R4pPJdwotsj Rb91dAtvHdDthAN8rgnWAl9WOE0RE7z14M4GcHeZ6FaGFY0MXuCBsX4Sk37w7EwT/+zT4I1xIkgl QQKEjE49TpITD43AAY6XQqg2zbcszyHc41O89eCDtaMAOhBl7gXhoq2CaH3b3b2L1/r8cp++fw7h 4iQ8nKUU8a2/R9sSHCk5otNCJBuTKUAOwUXhkCgEbwH9o4sqQto61zolvoeNcdiVLlNfEdsWzYgj gEcsC4g0YUJ/xmEkAdvqfXTvKIl5xEn66TGUxLSISLXsJIUUpNhWqdJcKIm5NCVSnr6nnEkcdeBf pMr1QQQd7IO0Lds5FMoAobs+elVch2iBFhsRMaJKXN8XcdZVnnncitVYCaKF6qLH+QTXW1f+eYGN MHFed8AmSBuqHTA15+uWK0WScp0iWrkXjIrSWIJHrFK2Ilq5jqnxSp8LzYpo2RpgVJ05lpZ6RCtX SodNTZ8vEO3miB/BqygiE2IZEhOPKTsCEgc/7N5Vd69EZplD76GOXkCCwvj7q9Q8HcJereaOE27Y yfi0HL4K3txzwbrGZhus0cQg287hutjsAr3itBf5y4wVhpMS/Hpag6YWu0aunsPVOlZg6mboNbuG bfSKuZErYrO7Qa/NudAr5nAHLNvSOdwZ68KugQUi9LLSCeomy0n8jS8oxJcvzeHC92JDANa99Fi2 5lZ/+RSZXvYp96Us551lBx0CGVg5IK6LU78m16IkjXshNn0k7tU1Lmw1SzQLXju9Rb0ySIcJ06Zy ytZldk/ju7jdnsHFFPppnGFqwwxuSEmtheaKzhw72uexjZM7EhAcBRyl3l3T4mtnU4yZwVKQWpbh RVQAn4VVV9ifm6ACzFDhcNZg43j7Kk5dwc+5HBESiOtzSdEka7lJCmtHSTpji2lxT1FOSuoC2F5j +jzrAkwBlGAfqP2OKSkoYK6keXvvHYMGYrTUJUsEJl6nwa5BDkV2i7UGhGNjsEvUV6EBrgEmRAMl NV7pc3zcAd3q00cRa0DLCD5GOe7eLfmSq1cMKMl1Cg3k3jt7LYF3KFtdv9QTU+UKIC55LtQpNNDW RGggLfWuX64UGmgqIMni+QIabNpFAw2wcbXGxgnR6SBjqhspesyXFSjQWn5yUqCwfhGoyiGENYHe lM2owiQpJijdG5q/YR8uvOf5gq5J+EJercACdHmQodltQ10QXBycsnLjGzN+1wa6ztRwO6Cw3YJl +WdgQv1kYYKsT39SMIEI4E0ZYELABBEmBOQQYULMpTAhpIjdPr7QizBBAFACExweijDBTYnh1gcK AmpI3oXanYEJPdx9je+hRZigKamx0LSo4xiKY4Flk9gBfEB5kgBMai00LXmPuVYpBidggIppN4nN xHxYDA/30ycmrMWxQxXmLNTM8d4YTM0jdoeLa7G4x78XLZGWnaR4CqSsYMeVqpyU9D1ywWAF8i+h SnkcTbumpA6AaQlY0Fxb710LFiRKo2BBrlOwIPd081ilHMGCKHEAA5jVZB6kxit9PrWyLtunTyLN BixMsojfgQW5UrAg1ylYkHsPBLQE3qFsBQtST0z1YEHS9LnQrGBhZGsiWJCWerAgVwoWNFXiWfb5 YbDALd8GLKjKpI7ygLAY4T8vGlvComqkIpZlABIFVco3DMCGmYiKvfke7GcLs2S44NOgRnbdl+jz iE07C7TgDlVPT984FllAKHjEBpxHhQvn6lg69KtXh0tAe7MVyxpuCRnCqBxjYndK5d60TAgQwbji 2AOYkDflb14+1rwYK8np1MzZmTgvdqBsNy/257vnX3/z1S/3P8up8FkzWFj6WcuqCGzDcry6YTNk Mxk++o0pkANlH1q3hg9loXsxdjtQQWYfYIuXnCeNsPKBsrOn9gYQPh/kTC7hODJiOsqUtz63N02C Pf1GjGuDeBrMelNICSGylbVEGhtN/TfWQ2QOs2hMQ0gvIGzZK93KoQVJUK8GgK97rJ4y+ZbluSDe 8am9uXdr0TQ8md7CSaGhOMVXDmbWwN0Ma5yE9dL8cHQJQE82cAJ/4CS3WWZX1T8zBa/E0bymRa8K 9I8tb9gKoRssG1k5ih0UrxJnzKRVnlVC6tPBcXycJ0Jz9AH28eJ7Hgk92AwAuQ4bMRq9T6GspkVo XoR8EWJr2UmKqz8F2J6iRY4kyOefp2+w4Sm8UIbFcYIyVcGSRK1cZwALapoARJ+WkxI2YeDr37l7 n4mE3RgtXkdELqs3sejYheYmTIxGRA7FBaV8guutK32Ohb9uttCF2AeEnw0in7EnwtctV4qE5TpF 5HLv0TZ2tkkJYJgkSdmKuOU6psYrfS40KyLX1igi9y31iFzarHTIdUyNVzs7NpM5PhO+8zsLZfFA lKYMWYmSsZaCY7ISS4LKMXynEnZM4VESFX5tA1b6vUowCu+2Ww5m/KqMWoFxaDUOD9hH43I+8jE0 jgmRCScM8+yQx5nnYx0rVLXEytej8dwafn00DotZz8rvx0LjrGTF8I2IbCagimj8QNkPReMHqsps RkTjB8q+Do0fqCCX+IDGD5R9HI0fKDyX8IDGD5SdonHZPd0helLJOZaya32Wg5Br2cHQIAVhLhw1 WjXL3Wgi7mGcnJ6qEhECR8lwwjjosJPla36YjFCWvMsftzkKK9385igcouQO0sEHguXIKJy5fe/P BeKdHNXWh2ev/YdC5WunrTs6yJ4UldGsdCGHOwA/o1lYLIKT8nCChGmWtsc3a7mO4xRHy4bhsrwM n9oyDB/rRk5bS762kkuZP3sA4GWUgLUeqbdF2dUMdycVBYYXZxie16wSHlXlaIUtEzlShu81K3x5 qawLOZHgvXMMxww7thbA1RsJb7EjO2E4KcO+IK7puSDhWKeBjWIUcMtvTxj4HT4JdUjALb/1KDR+ 9ioIuKxHyG4VeL7fqsBv3yq6ug21DS4/nn0Gs5Uc4yWnaEGHQ+JCXrCXd8bOfyyyuvzhXFXMcGCl NtkdmOc+TOlsFXqSJ+f9PyGfJ2kKZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iagoxMDYxMAplbmRv YmoKMjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDI1IDAg UiAvQ29udGVudHMgMjMgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoyNSAw IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBS ID4+IC9Gb250IDw8IC9GNC4wIDI2IDAgUgovRjEuMCA4IDAgUiAvRjMuMCAxNyAwIFIgL0YyLjEg MTYgMCBSID4+ID4+CmVuZG9iagoyOCAwIG9iago8PCAvTGVuZ3RoIDI5IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFWMlu3EYQvfMrKrcRELd6X3xLvAAxEMSLEB9kHxRZih2M vEgy4s/PK/ZCcoYz4dhyggGG7GJ3dVV1vVr6Ez2jTxSFTaSsFd6QTUb4SN5EESNdX9BLek/HD24U nd+QFEm6GLXFm9HJKhWHt+7mHLykUMl4KSX1vzYKVhhlZaSgrYg2aTq/op9PyKp+YnmcXNHxYyVk p+jkkk5pRUd0z+54fMC3NP72mk6e0KMT6LRXq+4QrWivVkkLbYO1Tatun1ZUtXoOyZWmVdHgc1bk Nut6UdXqWPN3mfg+Ey/zqKy7xsjR6goPhalneU5hUxb2U7tVWV/MeZrZPOSFEOOXPPytDMukyrbI c4OvkVY3Rx0/yl5/gogjKFNeH9HMEVgpnJHSkEtOSE3BapGya3ULXYsPITsQDG3grZaUCcLb5OFw LsqopONjvdx/8nfoz1opkbwZTn6BP7M3n/y14aF7zDNGXo8SmMF7kVyAFTWsqIwu+kudKAmddIj+ vzXEAGzlhHPeLjDEYmDPuNNcnLpLREshpdeBQlFnGaKfMnYUrQokCyAKXAsUvwA6Q7z6NmB3NXbc BbB7RBd8fzOwDz6LCmxlhZYIR8pY+FFx7GDTVwG7wmV3QtISGU5zPFp+0AcAeMsMVaIGYIVEqyWn Ug5gYwBzmPqXSLaT/W6FB6BKL7Q3PgO1m8/AOVfNKjyHwD6yjsN5VXeBPD4hpgWUBjO5s6sVwdfI M42fndyfy5t9fERqCbPiUBUnFyiHmWcqDgy0t7QYxAlRmOj0gkC0WJ5vcR/vkWhi8Z5p/fa/nJZL IiUkwhnv2TgupJ2XHKf9Zlk1rbxKDP8RU4fSs0T0W8TwgViC5TrPFJMF+yrX9m3MrBH7bR+xoEgo X/BE0viYHyVpTLNMH7k7PnsWrRZ1ReBzUFGvlVGt6f7I7Aq1sCsMTE5TMk+ZWkFnYvmmJqOp/G20 W8U2ZWznfcTTbPyaa2dTVVmfsmgmP+YL07k49hXAMDKgEvOe/MQTD4+rOyvBjnuwU0RAhfpa0pvc jz14gdSxpx+jFw+2+rF7Q3vWN30hGuEURxatUVQizBBelYuEHg6wSonW9KIvqoeV3NjNMwIGO6xO WK1QpWP1FSlp3DDO3Bb3k1phW839FbKl08hZLN4mbU2czJPX6C6VF9IiqzItiMgFRV3bgTaz9i1y 7Wm262ay2q2lklaJkV6s55Sy7jXnOTbin4c6jZcwhZd0zVhretsbmw9acXZwkWv6XgFtEOKutihr dFXgYZxpszqHFt6gEgcFp6C48aoEmYTyAbF7hrY9q1K6MLOOs7aLOBEWofD3CV2+ibxjEcqjQ3a4 JSialGF3TtahddY4nTpjTdYikgf4XiVZWE6xIo3viJJ3Z07DrCLREspoXdUO/tFWVtM1mdiJ+jNo gjfKSJlK67ZnbVPOcdyXpOnvA2CKRloCTej9Mrqm4zUZiTN3aK/bHCO1IhO0sP1L/xct7JY/RDvz Uj6yNfp9mC+4WMQElwLgXXexQXa9CHiBU2k0oMSvQJqOkrfshwguo9V5VHnzKv5axt1kNP3W74C5 BkLzDvxaFWv7NcVZGGCrmKoI18a9qDtGfDAc9GbCazdcfAGfg7tIhCfXI3REK2Db41ZddZgBD40y 41Yzs6pbDZy2w8ZMkBgwWz29gbjBYRIkin5jXarO69KsWKdExI2IRziQCbeHfEcTLayiEPgQo9Jm dm2BjgOvTD7Cu+vFYRtWtgFtiwylzAuubzDyY7PsfPKUfj+7ubn4jMKm3rcs36HU2cMOCGhIZl5h x77814Llxv3k6ofvwh/3n4U/hWPljxWG+r5U9PTXYb92wzlfNWxaOlu1NBzNtPmKtg2rpTm0m7Tb 0rYJ+PjD9dXZ7e3Fm/uDZHstjYQWAm7t8hZbpmaBaotVbbCQMzJORKlwAOfHH97f3n+1enhxefZ5 ffvqaNlGznihLF+R91a6QxUc7tzVYcb56frd2Rol+hIvd86KYA6yEIrpZZy9CB5XNstNotBCLGLt IXT6Hg7jcBETDzPHR/SJVehn/wDwDRV8CmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoKMTU0Mgpl bmRvYmoKMjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDMw IDAgUiAvQ29udGVudHMgMjggMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoz MCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9Gb250IDw8IC9GNC4wIDI2IDAgUgovRjEuMCA4IDAgUiAvRjIuMSAxNiAwIFIgPj4g Pj4KZW5kb2JqCjMyIDAgb2JqCjw8IC9MZW5ndGggMzMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Ad2dy5LcxpWG93gKzK4VYUG4X7SjJY9EhRSkyba9kL2QSWokuynJojSamaf3 n5lfJnBQqGpUdTfJmOgFGll5Pfmfa17wr/yP+b/ysWinvGrbom/ydmqKfsz7ZizGMf/5Vf6X/If8 o0/eVPmLN3np/968UJmyqKamL8uQNL8NbdFUbTnmQ90WYzvV2YvX+e+v87byZXlcv84/+s+qKPMq v/42v8o/yK//kf/hWr052Z/sLv2puqLr+jb3/clO9efr/OrxB/mHbX71gx5TfvVLeHsV3n7Wo0u/ vfogI8vf8usvdgziAqJWZVX0/VTlA4PYQ9QPH46oValZ7rom9WcfUT8V4ao6v4KA3wRyfquHSA2N BQX3louq/sHbZY+XoYWfVZkm7KC9yyYs28EFVV8XfT1NKwIdcEG25IK9E7YJoOwkV1Z9J7bs69v6 E7gy81wpLvg+TAa4Z4Y0X/sJl50pPqqhL8phONnPbCU97kA3zeVpug1jMfTNuXQD4D8G+N0EKurx gHQbp6Kry1lCBI60gHubhJvqoi4lbaPE2upPHicyAQ7C/ZQIt59iSVFl+xSViFVUQ/XeUKwum2Ls hrVMtTN4SLEqkKoMjyQ998vL+5CzX6j1Mb/6NahClCZ9qU0H5+7unNkLVH49tkVV12tKnlT5u00Q L3yzC02isi/qvum3eGHNm3tNog1lcJtQSyZaP/XFNMhWO2WiBd48jz4Xmoz9OBT9MGLclEVZtjIw nY15/eIIH0QDMpDLZ3wYM1J6YOrbJqePWyRbTaH0JyzwSCwgQRNf4Q+0AzYKOpYSv4mTnKX0XWAe sr4JbGazRqPqiWtEReJ7bPQzqqJmRCu2EPKWGq21S4Flo9nKSsM+IAsFqOy1649MOBrEePjfMCDM u5iH3qQfvfT6e8hKdS/0JhEDJWJB/2MWCUsbEI2C9CqS5TiZHPlSVVaD06o1UUnEfKUZjQTBlt3i y2wwrjykk9ZI003FJOkWQbjHC1C/Dlyrtiy6piybvJu6opRx09bFNB6VtL2kRDfUarUrlFWuXzeW Y1lP+VTUUz2MvRvLtw/nukkmFM3Y1YHpTsrxmemYEB7MEqYYU/dN0FdMK2CGCf4rAtVj8Xb0BH4t VOrAbcGXtOiJCN6AfhY9FXoLe9FpBrRky7XzxEh+0fDUGcudcSSP1FMnkz5zT4mNp7xbiQDZ8HHt bxAKxpy57QEVez8VjdSnxYPVDIdCmPH/qgHKlae7yAiIaQUHUwL5yJJoupxgEtXCww1ablvRVnW3 GvVJLjhPW19ozSggUdTi/Q3j4XASoKJ9gG+gwzxZuP4UWNQiL6HSzyi/2Swvw2yv+dEzxLWDepmU K8Cw7YIB+vvMlVgwyZeu9qQrQEHkaBSeHVz8kbHCO+BuUw7B7uSkI1+5join/0SHnrunuDgOCb1K 7+kCDyr8jaLUaPUqrXkCZ9H9RxRCJ+jMoClgpaVlJwmPndxxiUpshqIrWwUsAxovVYlb0c+jCnFH 9LN3qnpS4GBXtNGyBW8AEsRAUyaYuYQRKMCsM6MUYJ4smhLWPT/Y6UrSbynobJZZ1jv9AgR+DJwK 49kstGetWfAEOinHUL4PqouqGYMdke2nbc+CE5rZMZAlUcKPFtJRtZ2Aj4OQz253Ly6Ace19snLI I27eHxyXxSA/bAeO347SaauiLYe7aB1YwfLccwQpIEEiI+tITNj0WCHRAmglYz1+k57465UaURwa rrVi2cLZAhjp+tcPxBUqTz+iJfcEgR7fHzGUaNkJuAubNHGBX7WwbAO7kbhSFLH6w+Zk+i4Myceh uZidzkb9Z5WtJezfgwSxfTqun1J4elM/YbK+3G2aXcC1Tdsoql7KIAWV7w3XNnVRVdKKl2sfyx4J +l5hgBMSQa4o7exrHgCYCeYN7kjFl9qH31JDx3ksIsviPNvwYC4zO3at77hlilELpFobWFDauiIK 1i7Xd+Sabhqu4B2qgHcl7uz9BVZKXcrfn5zRZHr/HrgUdV2MNUaTJebKpThP2dh45P74aNVoUWXa 7M9hJH6TYyysyRJ9bX6EO95I/M0RrsQkS0bYjGwRJ0NXUec/Q2UWWzSPg2I1jnWIo6ry2i27ohoe thrb7gzfhTBInoNXX7YWBm+HG7UxWal0KUyyGAm0BYcghIqgg+oTb134zenUnYx2gYKoFWAfpCXy HiS9NwpCC/h1s2szxHmcdmEsoZvaYmp3rYwci/Btctq1Ztm5+oAUtwKDgQcgIwvghjl4s6YacMRG 5DdyUgt1Wk4D6sqyE3EXiPaqbxTKLSeFdpcUffeivVPwuO+215rehWzvpMGbbs/SlwDHqmV/uzxB 8oAGHk8ljJ2JDKjACG/RMgYyCDkLyqWTkdZgLODtagkNg1RyIioxQiwvJBHtPRRax5ajMlsLiXT3 uy3TPRpqTxwTbq5MhXSqgizEEWhN9e9klk3xfHpXTD0M2uQ2VPl+MJwnDa3dcdvyTlqX7fqhKPvu vdk613VDMfV38bkfCwJzqIgJhwFA2csAIYQkuOLNQu93oTJqgTeA7H8HFrULFjRkJfUMMNcza1kB RVogBn1P3Gurodu0dJpfPQmTs+v9dzq6g18ZvF1iTXT1ldGJxNLen1PV5zFgdsZm0aYUsNpRDLgb YXdhwN2Gf9eO2ogQo7fWEdlp+J8l/LJooDAhFpvMC8BBilvZzG/wUGKC5fqI5SjLNaps5yRfYpKM lVata02yoepJk2Q28pAAjBpSQB/MKxbqNmXFUnOmxT/LgvAQxee4kXNgaG+zE3GGHwdx9EQPp+Uo EtR6cp3oBw86YA1QfpMF8XBz0VSai7ZfTYUF+Duxxhqt7I4xzGz7s2K4uwiA/Rq40e6jceh3+Gsz VJl5Ho8cHmT0JQT6aBdvIBe5jdgHZck+8/J+U7Rju1mmeE6DtlLL9jDOsmB2ZZ3mRtUI+VbJAliG 9gyoP6XFL0MR1lkYRrRrGSr6h87FH3mlP/TVN5bMXKrb6Hl+Fauhe/9UPxRBoVJLeBt4JgvjoW4R /gE5r5wKHYnocu288dDaEZs9D+qXut61VnhcMPDydXzmzQpSQM2c3Mi6k5ll6W6xGSeTPNSWZnGO g6XYD9OHGGUWN5XfEvBpt8ym00J7dIJyKFugSCLNJgx5GwrmJXGPikhEoWX/SFuAjqmIxYoObV07 Zpx3NSRKe7pDGyt2oDDMYydjZrcFS2T3e1SoqQftEXexCiC4Q9ruZokLDJXZ/5KW7LQv7nKOmCXK YqKgcHI1Nozu0yy0VAjMOpMHe1lOsJXZ1iOzUQ3IBnskgnqQRHnLnbEayxnkwRqlNgIU1gGh+2Sx vEeD/EZYwPLXOf7S0hYmdEeXZtW0wPoZx+L2LBi5SHDdTxL/x7G1Wi/aDfULIh8z1LUUVJd3WuJA qDCVVqhEfCQMLbUAWTXrD0f3qq6KsZmGXPx8aqCrhTpr/cSVcDgXsAM+u3DylQv1SdH9yUljeQPP 3dNs0PJMvCtat1QotAmD22gdlD9A88KBAfBWncFZVjBQmWU+O7e4SJvFmWirbymOPFkraL8oRHtL OZQUo8rtBMgFQr9xS6Cyfk7h4114RDo5W0xVXKE56REd80A2Ja6dbaYLyz2aK08Ab3x/BIg/I52Z h3/RdTzsrllmHglLlk376R77ZZURnf3UMaYY8rHGIP6MQ+TXlZxCEfFgEEtTLItuXbEbm5tSWvv9 ZVTNp6f90dJ0stodZOrGQWeyd2Ahr7JzjlIf686eo93tqDPiWj58X+y11qmzJq4t7QwsMfM8gKZN PIIZIASMAS6cBE8g45bwz9LJHNpCiFuxbbEL5MAhnfs6uFKROVeAtprLVkcFsWTggblfR9j8HCPL qyxrAljJztitfiARQyIVWHouFPjbpey2x0Zr3LaYQScwLZ4OZO/SVngrRlqr09tls+mhv4vgWNt1 xdSM8ZzeLTcpWJbijRlPv/mpjrhcIZrXveyWXaFtvnLaSqJ+kwe+DmrgSJOJiXy/NiuIJQMTbR27 CwYgQ3whpj3Y3GMjfadsu8QTXnnhC+1iIgp472eTie7Zqa9HabOyldLaj5LdTHSBfZc8nbbti16h 79ud+t3d2dChu5eYWh1caLo7LTGtmchPdcTliomeYf6gpl4K/gryooLABYkoLRKR/nLbkw2uk433 Gwiq2klTo03dkSg7DAsZvZ84BpdJBx3oMMoSjrGOD4nw5E4Z4MnqZUAWzzpQQaT1bhkwH2FNVV0u A2DpZRQJSqwV6a0y4NR8XsBzTTVqd5kO4Mf5fF9i3W09amPF9jLTO3HyRKih3z7NsNLsx5w8+Bzw A0xYGIbmwaLRWpUsNUPSex4x1EKdz+C2p+5ZZVdfBhHCr+jI6EeBQDQxQif+yCtdxmGksVO9o6nn vgP51ed0KHJfCLmkjkXmtCShRzzglxjfISssiZbFmuW3c4xhT1mK2xU7VD11MuYUF54l7b0fqW7q zh0mlXY2yDvpMp2nDi9chWq1PCaze9PGXXHmMU5I0+bpfmSiQxAAtIJAOxvoD0BqNQZ48S2lYz2W MfIVY8AJwBs08DYzhBfitEXLZKU7nD7bcb3YBfK6mnTvRqVtynYW3gdUyJgc9yzEnAdSuy9vt83W TKX2C94pWA6C4HweQaSm/aFJHixV+7axQ1awQuVAn8qDuEyHef9PUnNeIyfPeZaQd4qswonC9gky Ob4/QlZ/RjrtJSnqR0hV/x8toVrXcuk6szq30Hn3nNVoU1anC23eF3eoGeqiKbcPAOy0hDZZazsI 8DneEEWQ0VGQI52BJRsYrJ0FgD3fpT1elLMK5DwOu5d4A47aA1xAUzdVUdcK+MTp2ueoJXZf2ppr dveiYHNhCyGH0mbOrPyxE3lqQ+DZEcTz9rPqDrdB92JG+rw37KVjIWUVI+QHEc3ltY930aS799cp 8lEM1b1HEK+dmtnYA+PdmV32oYsoJF0Jxqx9aHGLsYbKxdNKNptnZyRAlERPUIVR6fNzPHEXs4Fo arRLrvxGT6gg1osws1YkoslzUhoe1TBKnYTzZz9+p4eiptQaFXmsPb4HxZ7tvT5o6QrRM5pFNmiA Kb502uvZCLrdBrumlnMhuZXvh91uLrjA3E4hycZduVzpFPE9H9P+NqwQITA3Icr0njb8fKYs7bKk ItDNA2TBI2TZxtDj0K0IJbrwe8cP8+GoTe0JUlkq+4dKNEnrAiCUxNni3d9tvffKULeZxPlJduKs OF15q7uBtIHr/Y5Jo+t9683Y9sp4ukt3bmOzGde1TsdrY8U+6wAc2AcznhK9JI0GGj9iLDDzQI8S YB8hsxT96axF9L6XsjGtFtEE5ak0ymikPTEdEEs3yEp5K6IRzXhrdDjpEz/E/xG2FZi3rEadMUzF 2GjQ7j/yTaQh2iZ4s82vxbBvPuoC9oXskBLzXmzb9aWUyK4OpMSlMt8v556+K1HXz5da7hFbeCxu WWLvhDd0ndvQlu0deAM4pMdxp+EMhnns1P56VQIUg5izGMZ3ivLgHsACX8th++X2BQq3Gvti7Dvp f4i/Q+FuCsrtizMlubevOY8XZ+qDCIUOt7Rv/+ZMd8CudStrt1sYmwPeuhbNK6oLw7z1NBaVzoFt ceO7UJz1qM9c6Fr8jUXhdyEc6kG3uPe7vpmhKPhfnOXUJ5WFJLfqkE8fWIMMEW01FmoQ3VY4cZC8 ACtq0ttmlo3EP7iOysRDuaGjkANWHaEvaCJ6G3Q4+QpeSUVxZK+NojoqaNSy1GkZHpYKtfktXUy+ DLqePdJ1AS8F14meQujUp5Bm04ym4OQ6ml21ob/7JeWGRelNuBM7Dv2B3EpHvSMST3LGiS2HRyWl v6b/a13bXWmZq8xfhm/LfPI8K4up7MZRXlopW3Zqq2pc/Pf8k4ONiR/O2yb9B2wG7Urs9Jma11ld K+Kqi3t0gbi+iPA6rytd9NCVXX6TP/fO5VzSbbg8WpErOGUqWHSqpdHXccL/oZp0zvlkx2WkaEdM Wev24l7CRt/gyF6vU9Qv3XA8upvh3R3LfavMShp0814qpYRVPflN9p1uXf46kHG9i/T4oBrdlNn5 PaVdII9PyNwmU59w40aqHHGsjc5mL/K7n00FN/l3nqxuSiu3obVT0FuXQ7uhNE7Wv87XKTe6nkTx Z7njc65OHx7SN2UcCdR6407KkZL1ClYrki4xndKUi7SY61TKXC7rq7JoZQeInnPJUhPj1MDcK93U 34gNYsd51S30nY4R1Np10oek7CZvtXtlGoQwkpTglJwbSahX62opJbaumlIaI/FVxZKRBnPlkZpz D2LKslekZYe5DlNeaOK+zev8t52s5UxWXRteChmD44f4rxBRulMtk2OyQS/urLe7tbjUVV7hze27 cGB7Yd8z+6t9I+8oFEyT6nbNqGZJCdeUYtCx0UnmlXJMqk2di29qq3Z3d6X3G72LhdSrOU2SItY4 jPpdb7G9zJV3d4PEvrvy7j2OLNXmBu2bcv/Q6jJN8kj9CD8GVjkt6yQyZnAMkgduXfx1SpvZwWHv boBRXTDpITwOU8RGK9aeGXmuaWarCOJFygYjxxHOo8n6OS1cK9927hiPLr4X1+n8+phX2j43tu7D PHpK3FdrZZekkROM5dSPwkb8Vll6TdVK/FY6bYG2GzpphTLnYT9Sc/XF0/zP37x58+pXWRrxZv0z 28j0PbS5jUZkaqe+Uou+KZ1HkRx1e/n/47IWcC2Pt7D48NrwUdV/pJB5VX+seyyfKvocx5Q2+W2r 8uiGbahyEfxeVLkbh1iuzutW2gA1Xrea64v0uCvpFfmkGng5U5MrVluUXZs1lU6uqlfqFElyLUm6 UZLczcmFmyWYBndZrUvTtxPcEQWTb1Wb06QXKHR9giFo7lrf3Ss62RerFLWvMWvsadST+46cE8ih iM9gKlGKRJWWECMfRdZ3Y2orTUrS6illFgZ+5D5XZH2RTOaFO4cX1bwuTpW+dzy3kXaY6yBF8jml 1V2vQ1wynxZKvdYS0ziN7iMXmBqywbQYLyUVhFh8fTEry5i0UOoxKUnaVO8ihdZVU5THqUd7Uhby PlJlaQxE0iVbIFE8ieiUsrAFYto8vJgyWzEp5WJbQJBqhAWvev3/C2vAv3ulXUtUe83Lm1gH9S4u Ej85xe7+Cyre/xd/16UJmtaQY1Cc25kZSfXr3uyOtt1/L4Kq9akLde/fvfKuYw28qW7UvORMGxR8 +i/z/8XfXe8wAdJokgngR+rVvP8PIyClZuk/x4KN2jzXDmh0YeOgVWUxd0JUxIq6tUgLbLYDK2Kg Q/zsSUlmQESPwJqYLKbNzBnhm7g19XvBwTEtO8x1mLIsB10MDSKtbvgoTVTzjpd7+Ziz9dC7b8AN 0r2rD4smqbdHszunuZZWCEGkWe06GyIaD2j0S42HY03cm+2wt4Ft00FSfG06tJ0zu/RDL+p0tZRg pUuyu9qlyIYbuz5aEMmP9kbXyaA+E1mpClWa7gvNmsGX5eFprv0OgeYKlPkwkuJPLoykvW+EuHhz UTBdqs4bdxa4O9MbH/6yKxS3j2qJpJ3Liq2Oefa6AW01Km0iWYxqFR2dN8G6OLoGZYNM1yGRYJgL LimLAoRuNPMXDM4bzc4PAHfaydsP8vziHMEXZjQrvtBoXOBvCLFMEd6GJl2kUIk/aP1Yw1gs5umN IfpgoM6CMFTKUxASuQBppFR2tVzU0paRR/pRkcInergdJHOo8FwA3AnW+mpIPW8IuIVkxybZDXJN zmUgMpHTk+Nccobbd9TEkpzhEI4SXWxXj1P0VwDThZY/DrsBwC3k5+0Zs+Cio5qULxeHj3z8bhu4 +tSoQ50VLk9f/fzi1U+//PrNTf7z9wp0SAa10gBONkv29xJHnaJduqRZ8ZsF9T96/LrKP/1Rrf1R 4dLt9pbCbMn2OxllFmYSleMU9cepSV+v0dzer4vQ6D5E6kJcoV84xaZfR6WRFUP2DdxFVgUq7uoa MTfyN/7IKxgDTrcyd9qT/zwAxx8RETdHrvZHRPQuQDmUer2gV7pJ9U49aHuJfyRc+7X3kPWtCgR9 mc8tCIU52NJzSSFLhrr1EclQK+7S/gIvQ90KvEbuvtSqB8LTCgSyQJQ4cLfNQCUWSlM87BPDTpy5 NktN3pjIuWtvgYqKL7tLBcXY+6l49aGNgDwIh3UKXg0ygc7p2KwiYQZIeWQK/fRu0v5lmsg9U3Cp TFWgtZOrvaT8WxWpje63d55lsMmN7Dq0PaDT6YfXoMgsiM4UuMseZtNlpq/jF/QwVTN17uK5mZfs b1SNLIJt1tp8ucbqdiF548jz57na3EqLJD+tRKCHUVyiq59o2M5U0q97kLTUlhdpJR8BlumvI2xD 2utmZvZQK63UCXTkAY2Rd0g2fivW+1G3BcGSPZIJcLvJ0SoCNeh7wnEwDqYze2wZKW3n/H8xlMKM bSnlbEq4WO12B++N6rLqFcmM3wGTb7f8NrOZhRV/XeUCiILK9tvMqbcunFY3IkVyD2V16COfZXUX kLjr1rRWcNx0udg99AZpcg9Xm5a3R+VBEkd1DCXZoWHaus9hK2g7j2UfRtymlnh57VzCYOQ41VP/ Pnmj5bo33lAuT1+jnwxZt2lg6Ou4u2cbFeF74rP/inDhgUi1iddBZVkThL2J+u2I9DljjLdvJ3Q+ +lSNk98YcWKMy7th5jEilTEprdxhqCSSBRsUakQbDNlEiU1Rz28ommQceBWBoLPyLmXBxfZaxJqA dE1VO0pvhA/OoLTH074YjxZbtVIfz4hsgymFeBgGQhzS2ET3fSWpaVAEoaAwBSz11njzWhf17g6H S4XHmUFPx1coRvsUoXISadjtYR7TXcdrHbQL2ka8JKF5uxLSDgVxq1xmCL1SKUu394EmWI53VaVt 4rfMMOQ7/fBG2iPRVFEDcj7DTJljCW7i+PGYS+o9QGZjZUOc5ZIimjiKt60evIo+UA9L8Xv6q/Bd o+WnoZVouoSezwOxPodKT3gGTzlcpiByRdNPZLtM2p63X3TWKM7sGfXF+w07/tDaQz56nkqhKEx2 +A3uQz6CgtdiZneRDGzLDFMNiQhmStASCKE2/winq2aD3IrSc8SNx/K15mOG6zE9spiTfwMOVxjD CmVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKNjgyOQplbmRvYmoKMzEgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM0IDAgUiAvQ29udGVudHMgMzIgMCBSIC9N ZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagozNCAwIG9iago8PCAvUHJvY1NldCBbIC9Q REYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSCj4+IC9Gb250IDw8IC9GMS4wIDggMCBSIC9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgPj4g L1hPYmplY3QgPDwgL0ltMSAzNSAwIFIKPj4gPj4KZW5kb2JqCjM1IDAgb2JqCjw8IC9MZW5ndGgg MzYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOCAvSGVpZ2h0IDYg L0NvbG9yU3BhY2UKMzcgMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAzOCAwIFIgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAH7/x8nUCh5qVr1 SqMWgSBKgYImPa+tp7yBcIFsCAOoEijouuAthKvfBhWHcO2mQ9UDlUFEsJIAf2N5iQplbmRzdHJl YW0KZW5kb2JqCjM2IDAgb2JqCjYxCmVuZG9iagozOCAwIG9iago8PCAvTGVuZ3RoIDM5IDAgUiAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDggL0hlaWdodCA2IC9Db2xvclNw YWNlCi9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBm/YfDKZBKEwSJsHAMO3/NCACAFQUKvQKZW5k c3RyZWFtCmVuZG9iagozOSAwIG9iagoyNQplbmRvYmoKNDAgMCBvYmoKPDwgL0xlbmd0aCA0MSAw IFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBnZZ3VBTXF8ffzGwvtF2WImXpvbcFpC69SJUmCsvuAktZ1mUXsDdEBSKKiAhWJChiwGgo EiuiWAgIFuwBCSJKDEYRFZXMxhz19zsn+f1O3h93PvN995535977zhkAKAEhAmEOrABAtlAijvT3 ZsbFJzDxvQAGRIADNgBwuLmi0Ci/aICuQF82Mxd1kvFfCwLg9S2AWgCuWwSEM5l/6f/vQ5ErEksA gMLRADseP5eLciHKWfkSkUyfRJmekiljGCNjMZogyqoyTvvE5n/6fGJPGfOyhTzUR5aziJfNk3EX yhvzpHyUkRCUi/IE/HyUb6CsnyXNFqD8BmV6Np+TCwCGItMlfG46ytYoU8TRkWyU5wJAoKR9xSlf sYRfgOYJADtHtEQsSEuXMI25JkwbZ2cWM4Cfn8WXSCzCOdxMjpjHZOdkizjCJQB8+mZZFFCS1ZaJ FtnRxtnR0cLWEi3/5/WPm5+9/hlkvf3k8TLiz55BjJ4v2pfYL1pOLQCsKbQ2W75oKTsBaFsPgOrd L5r+PgDkCwFo7fvqexiyeUmXSEQuVlb5+fmWAj7XUlbQz+t/Onz2/Hv46jxL2Xmfa8f04adypFkS pqyo3JysHKmYmSvicPlMi/8e4n8d+FVaX+VhHslP5Yv5QvSoGHTKBMI0tN1CnkAiyBEyBcK/6/C/ DPsqBxl+mmsUaHUfAT3JEij00QHyaw/A0MgASdyD7kCf+xZCjAGymxerPfZp7lFG9/+0/2HgMvQV zhWkMWUyOzKayZWK82SM3gmZwQISkAd0oAa0gB4wBhbAFjgBV+AJfEEQCAPRIB4sAlyQDrKBGOSD 5WANKAIlYAvYDqrBXlAHGkATOAbawElwDlwEV8E1cBPcA0NgFDwDk+A1mIEgCA9RIRqkBmlDBpAZ ZAuxIHfIFwqBIqF4KBlKg4SQFFoOrYNKoHKoGtoPNUDfQyegc9BlqB+6Aw1D49Dv0DsYgSkwHdaE DWErmAV7wcFwNLwQToMXw0vhQngzXAXXwkfgVvgcfBW+CQ/Bz+ApBCBkhIHoIBYIC2EjYUgCkoqI kZVIMVKJ1CJNSAfSjVxHhpAJ5C0Gh6FhmBgLjCsmADMfw8UsxqzElGKqMYcwrZguzHXMMGYS8xFL xWpgzbAu2EBsHDYNm48twlZi67Et2AvYm9hR7GscDsfAGeGccAG4eFwGbhmuFLcb14w7i+vHjeCm 8Hi8Gt4M74YPw3PwEnwRfif+CP4MfgA/in9DIBO0CbYEP0ICQUhYS6gkHCacJgwQxggzRAWiAdGF GEbkEZcQy4h1xA5iH3GUOENSJBmR3EjRpAzSGlIVqYl0gXSf9JJMJuuSnckRZAF5NbmKfJR8iTxM fktRophS2JREipSymXKQcpZyh/KSSqUaUj2pCVQJdTO1gXqe+pD6Ro4mZykXKMeTWyVXI9cqNyD3 XJ4obyDvJb9Ifql8pfxx+T75CQWigqECW4GjsFKhRuGEwqDClCJN0UYxTDFbsVTxsOJlxSdKeCVD JV8lnlKh0gGl80ojNISmR2PTuLR1tDraBdooHUc3ogfSM+gl9O/ovfRJZSVle+UY5QLlGuVTykMM hGHICGRkMcoYxxi3GO9UNFW8VPgqm1SaVAZUplXnqHqq8lWLVZtVb6q+U2Oq+aplqm1Va1N7oI5R N1WPUM9X36N+QX1iDn2O6xzunOI5x+bc1YA1TDUiNZZpHNDo0ZjS1NL01xRp7tQ8rzmhxdDy1MrQ qtA6rTWuTdN21xZoV2if0X7KVGZ6MbOYVcwu5qSOhk6AjlRnv06vzoyuke583bW6zboP9Eh6LL1U vQq9Tr1JfW39UP3l+o36dw2IBiyDdIMdBt0G04ZGhrGGGwzbDJ8YqRoFGi01ajS6b0w19jBebFxr fMMEZ8IyyTTZbXLNFDZ1ME03rTHtM4PNHM0EZrvN+s2x5s7mQvNa80ELioWXRZ5Fo8WwJcMyxHKt ZZvlcyt9qwSrrVbdVh+tHayzrOus79ko2QTZrLXpsPnd1tSWa1tje8OOaudnt8qu3e6FvZk9336P /W0HmkOowwaHTocPjk6OYscmx3Enfadkp11Ogyw6K5xVyrrkjHX2dl7lfNL5rYuji8TlmMtvrhau ma6HXZ/MNZrLn1s3d8RN143jtt9tyJ3pnuy+z33IQ8eD41Hr8chTz5PnWe855mXileF1xOu5t7W3 2LvFe5rtwl7BPuuD+Pj7FPv0+ir5zvet9n3op+uX5tfoN+nv4L/M/2wANiA4YGvAYKBmIDewIXAy yCloRVBXMCU4Krg6+FGIaYg4pCMUDg0K3RZ6f57BPOG8tjAQFhi2LexBuFH44vAfI3AR4RE1EY8j bSKXR3ZH0aKSog5HvY72ji6LvjffeL50fmeMfExiTEPMdKxPbHnsUJxV3Iq4q/Hq8YL49gR8QkxC fcLUAt8F2xeMJjokFiXeWmi0sGDh5UXqi7IWnUqST+IkHU/GJscmH05+zwnj1HKmUgJTdqVMctnc HdxnPE9eBW+c78Yv54+luqWWpz5Jc0vbljae7pFemT4hYAuqBS8yAjL2ZkxnhmUezJzNis1qziZk J2efECoJM4VdOVo5BTn9IjNRkWhoscvi7YsnxcHi+lwod2Fuu4SO/kz1SI2l66XDee55NXlv8mPy jxcoFggLepaYLtm0ZGyp39Jvl2GWcZd1LtdZvmb58AqvFftXQitTVnau0ltVuGp0tf/qQ2tIazLX /LTWem352lfrYtd1FGoWri4cWe+/vrFIrkhcNLjBdcPejZiNgo29m+w27dz0sZhXfKXEuqSy5H0p t/TKNzbfVH0zuzl1c2+ZY9meLbgtwi23tnpsPVSuWL60fGRb6LbWCmZFccWr7UnbL1faV+7dQdoh 3TFUFVLVvlN/55ad76vTq2/WeNc079LYtWnX9G7e7oE9nnua9mruLdn7bp9g3+39/vtbaw1rKw/g DuQdeFwXU9f9Levbhnr1+pL6DweFB4cORR7qanBqaDiscbisEW6UNo4fSTxy7Tuf79qbLJr2NzOa S46Co9KjT79P/v7WseBjncdZx5t+MPhhVwutpbgVal3SOtmW3jbUHt/efyLoRGeHa0fLj5Y/Hjyp c7LmlPKpstOk04WnZ88sPTN1VnR24lzauZHOpM575+PO3+iK6Oq9EHzh0kW/i+e7vbrPXHK7dPKy y+UTV1hX2q46Xm3tcehp+cnhp5Zex97WPqe+9mvO1zr65/afHvAYOHfd5/rFG4E3rt6cd7P/1vxb twcTB4du824/uZN158XdvLsz91bfx94vfqDwoPKhxsPan01+bh5yHDo17DPc8yjq0b0R7sizX3J/ eT9a+Jj6uHJMe6zhie2Tk+N+49eeLng6+kz0bGai6FfFX3c9N37+w2+ev/VMxk2OvhC/mP299KXa y4Ov7F91ToVPPXyd/XpmuviN2ptDb1lvu9/FvhubyX+Pf1/1weRDx8fgj/dns2dn/wADmPP8CmVu ZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKMjYxNQplbmRvYmoKMzcgMCBvYmoKWyAvSUNDQmFzZWQg NDAgMCBSIF0KZW5kb2JqCjQzIDAgb2JqCjw8IC9MZW5ndGggNDQgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4Ac2dXZPkxLGG7/UrdK7OELEIfavluzVgwAHMnt3BDgfmAi9g8NnF hgV/nF9/3io9VVKq1d3VPduzy0agkVpVqsp8882srFLpp/x/8p/yXdGOedW2Rd/k7dgU/S7vm12x 2+U/f5v/Mf8xf+/9V1X+/FVe+n+vnqtMWVRj05fldGk+G9qiqdpylw91W+zasc6ev8x/e5e3lS/L 4e5l/t7vqqLMq/zuu/wmfye/+1v+4Z1ac7Q92X3aU3VF1/Vt7tuTHWvPl/nNJ+/k77b5zY86jPnN L9PZt9PZzzp08bdv38m45av87vcJnbhAqFVZFX0/VvlAJ1KE+u71hFqV0nLXNbE9aUL9QIKr6vwG AX49ifM7HSRqZCwouLNcUvUHzi47fDM94WdVJoXtPe8yhWUJVlD1ddHX47gS0J4VZEsrSFXYJoCy o1ZZ9Z3Msq9PtWeyysxbpazgh0kZ4B4NSV/pgsvOpI9q6ItyGI62M1uxxz3kJl0el9uwK4a+OVdu APzvE/xeTFLU4Ypy241FV5czQ0wWaQH3kIIb66IuxbaBsbbakwdFRsAhuH9EwaVLLDqqLM1RSVhF NVRvjcTqsil23bDmVKvBfYlVk6jK6RDZM50vXwfP/l5P3+U3v06uEKdJW2rTwLm5iZq9wOXXu7ao 6notyaMuPzkE8eSbXRgSlX1R902/ZQtr20wNiTacwSlSiyFaP/bFOChWOxaiTbZ5nnwuDBn73VD0 wy4huJFvSoK6Bzc0DLdQ7tcJljANt1jk4u++n+4kzqM4BZ5PwOdAnTyIA86TqrlzszICIZ5AtMLZ q+lB1hPHtvgI1Bbnzn+Gxvs41oaztmoa/1w2LFOm07YtNIKLa/H4J/AbT//3RAgImWgCudA/auG3 TT1w8bt3skTO2LAJDT6OOvqmLouyq/N0CCZbxAUMNluo4o9mp3YlDVoQfsLh60kx3AkorfCBE4r5 64Qji3BU+JepMsIcVE/VqJ6LqN4qmyCdi+CP4hYdL9WISqMCW1uRHFddoIlqrIqmGTUgTtdEMjLu 40s0HCzq3dvjSrqxGEcFyqddySHuBn4WvZ9OuAMcENAvAtw8OIz0sIx5VlABRxZ/HvbZjWU1MA1T gs1jdmLbZMmNZlvatc/DorgIsr8x5okl0k+eYA0k+qglCU/D7ezm1pmNht3TeX7z2J1X+c1HXL+q AdVDV/TVrs17g5A3H4z1XVkMZUk+yIbZbyQYa6uiLYdNi94P+62VcLZpQU/QNrgBYXKmzoQA6L91 j9JcVGNRu4m+YF7eWrKQu6EgzQD1VIpd4STsLTgXcj7/ApbUZsMMaiOssZVSwNtsFjrDLZv2jHNa S8bzSPQxPnVkb5lZ4byAJDsjj6pxQlGOTd4fgcUKpiJWxIskUB1dOepLkf0xaVlFqNLEzl/gdZtq KHZlPa56/xaQRlMXVdVujpj2tQFYEw64uWgrPqDfxOxjzJlbUTF6R33Yk/cp2Y3ofeEtKffldDG4 hE+m0+ApuClYOQB6Jc7Q0ABXZZ/FLY/Msw5Rj9qTbVMP7aDnp6nHpY2XRGZ5hW5wEWu3ZmALfDVV timxleCfqqfOqYY+SoPXtYemaTU8Mfh7C+yhrotdvRn13ccc4K+Av39ILXJPgByohR85BTJoF3Bu 6DoLczqA45nTo4Khj9FnMIEvOJde3bODoVDK15+FFtEwsBT8F7cmDa58/+zgChnQr+givS3zG/bB gyI/+8oQC78FlFo/Rnlqs0HAJ+q3rPQsS1y2bTYszCI7Mbd30aC9c1OMchMTDBMSR8ljswu81jxq rxol48fXPmq/lR04zklgMvQejMSOMjxSYoT0lwnhFjCgFjsCNhzACwXsWCWAn3siJpfxpb24fG4W 7czDL49Dl1V3KIMnOuCQvBlY2wCUXCSMo6nUQuNsV8lwIEVuWTY8Tl/OA7EreoNSSaG+6vM+HWfJ uL9XTkLTwnUTptiPDqkOJQFQjT2A90heXrPHyAuVniavLEwKo1MKzuS1GBbtRSNGw9nrXERR9VVR j600jEQTmG2WKEZr0aouXY+Iq0HJqKYTEae39+bdK65P2FXFWNdVbE9a/jTJVXsmY6YLRB6ONuIq kcK50zjCBt6Q3I9TeMNFy462am6x5AxxQUePphB2szLLWE/VpAeMYLVEqB+7czTyIJzVjW0xtklz crOFId1jB5gkOOBrhrCfOUUKXF+g0GfuqJD2zh3LCDqgRLDqD9kNTBfcdgJsKE//otc8mZFdk7i3 o00SZ3KMqm2TrAffDF3oJ979n5NxAX0M1rK9NSDK8Vi6KU/i2DM7vUTtojBWcwxaJ5EHLCawfbJt 3CeO7XbK3XZhfvjoaPMs22DMPsdKCy977kglWy3V2/PSbuVXsELLpug2OvtlwHiLLaWH2kvzinZF BGJHb8HYeL4lfAv37w16+c26KSDNAZwDaVpve2jD3s0WIkRMnZ4ts0q5skrXnI1V/q+RPYC/t8Ye tDit6VKSf8nmuUEXycs3un4oyj5MDttwO3HG4ANg/hiX8RHnIC2ECB5AEdQAlnssB2PTQIY0vTU0 VmP+Ro+aI6KZZxdcAIqBbzDiZRST3RyLhSj/yDyJptF64P/3yc4wjeUT9sjjP6ptniuJ5f1FL5k4 sA52zhO51UqPM7pIozBb/CCWHbo/12bGHycWcZ+3YqnR2u1x6GSBRyC2n+BDbrajkIjEltjeCzyW UqNFWe2GVXuPeqzzTPQ8+cVMUNcNxdhvzuntiw/t2wPqBuYWPPxGXp5yXOTMMjkw4xYqs6b318kS KB744RZeCOeP3fliCpnbgSqPwahsm3ka7aIcF+2d1rIZJG3YWwxw/6ZGNXkIaW23eFAUjg9X8Wi2 1QybeZBlBM6McJLm1xdMR+HfOQkqOEdWasNX2bVeH2gazSVWpcxjguNb40/bndb7hUUjR631UHwJ 5ZC7Rr0vhWE3IIJHYSDL6hEJ3gvhxLgIDv0hW602SuexPdfuXxw4ugqtajs3Sq7zzkhmz7U/2GsD reZhO+cHjrdn9doAmI5uzPtGrMyKGJ1Yu8LUqcVaINazcoaHfXJcm0DBi30yK+aO87BfBc2TLMDW POzHGlYWlrDETVf0l25+va77lV6PWuDD+Mtm1HrHpEU5hxjhA1zVLcdw/tidR5cVgzRL/mDOOiJ0 x28UiFpejhphGu7EheBlKLBpFKjeRqEUoDLrMGkg5YI1YE2FeqqpO8pzuHPdl78hQMfLESFzj4Xs UwT4xLGpBPepzufAd/XoTapdtcvLIxrkJvit5GjWZ64hovOgwT9dNRkjBA7KvHcg8a3xlY0WKO/C 8rCjlnrIMlA2qkdjJCYtuC3+OdtM16BF/OcPgooUhRkAEYpbjuYij0XRkGsEwcY8D8ZEH7DF2bNf jzKrsSzG0lHmWYoI/sYKb1OijIuRhVUIF2EUfqMWfrPGm+BDrbSRKKqzDvkS33c9TTS10qWjXoY9 QxMP47z0DsEw3mtx2DpM8Iy7ZkpvY5vOJfi6W6g7nAfm/IjrQAbEAadNVB33fUuHwMJ9aqF5FIcJ jhmvRRyshGFj5tTCE2wBLh7wkl5iK29UJAdYy0A+9eXCvtcL2y5wTsfEeRi1r1il5wyrqujKzQVb q5ThfZpz6m2bOT9SutdEkzYJOOTV9jE+LZIB439wkFf0YqGEK7SIArMU/NzbSqaXGj3KA3psutMG g5/oVrk/6oFfo4/y3ixUQ3O4FSa3KVFL6E99c8J6w+w1RWNx/eSaY3xHrC0jl9ADSizdelxNgRfh QDXBFVIPglT5a7qKUbtYDBpPg7OEdQDn4f7CvKD2xSjG6l4rZaz7BkhrvvWYs8FSuqbtnawQ3wxd UGkwxVuwGs4fu/M49HL5Ok/IWAbw4GCDGs74jcdEi/KGyZsM9iL2TdRFudNNP53Loyrqp0YrKG/a 69eKzkb7BU6n0XKwwa0SPgNd56H9QqfT7rSnjBaG3ePlMDDMoAXfb+UOmRP52lH3adXPaw0tarP4 mtT5nkQuZMFt2evdaMcNSNq22uVBugkjVfnQFHdWTPYJ1jkEI+bU+qOj2YFsOxEbHMmmK9xULfkR uI6GPINcPoZ0Avl8wfmnOm4t4PbUeMhRLdSWsD/SOe/1NF1fDLtKGy0dMYrV3NDDGKkLypqw2GMv 5bxK8VpscJbkkrw27Pq5aLn+N2u5IWo4PIBeZ+hpDD4Dv8BFoLPpa9LHHLSX7h54nndxYJt58E2k UxyGork8AVEwJ0dx6+mgQmpZ2RQtRHbepuKSfh6BJwsFOaU6rHB+orGL17rktWm0xdXYVXkLDhPo LNkuLphSjkOUVlsnlU3Koo9DIxQoF9GiRas3Fpgvg+mNJeWL9GtwUoHtwvnE0rPTQpFoENxvwh8A 8hvlNgf1FqoUgEkpF5pzCwlP51lM4X7E9Yt8qlatnjUs27CCOEizpkXr/3yj5mnZ2Ip7rNnLqIw1 HF6AcQH6Gs231d0g556MvmRjWEaWbOqXnD5ou64YG20MePlr/hY9a6LzHiASnX/3dpOS0BQEaQea xNqQVwTmcszBEwgnuZO2YCs8gd9sI1hxQXEqA2bUYkdim0bPnQSsPO+Zs4w5X0GlCI0SmJyNgxoV HOPbnv7MrdLzA/na/ebPEiErjJy7c1utlFdd7xTYHMHIGwlsWuXiNKNzGrL3MaHklFfbuLWNTcq+ mHIo7JfVRwW6BNOsTnfWK1qflOvOgBGH91XOrfEXYhI1fwFZVW7cOfRjHrqWkGVR14CvNRQMGpeJ KTL/kGAEWIZNAz9FCE/csVqnzqarcXfI+EhvMSEswn5pAWekzy01UJ5bIB9IxBb/ZtIpmmJNNB3g YnCjj33L/RD1emqsBy0K2Gk1zhlqTH6Jxzud85Jl9a4sun5sV+2xI5MVoQhWlv1Rzib/rpRrd75C ZYAU4qW2UFCn11NHo/1JykGroM9Rh3CTtJHuBeqYA+J6p2XHSWs07kOo6TFJ5fboDDPjFh6rOY1D EfqGnXnaxAyDvj2KYmYPMAAUiAug8RvlucVSA0lQDJ5Q4hjFUUuMZ7xnjzD1PsBSSsK4I4Ygnu0i 60wzKLfw5lo6IXi3naTpy7FmnF2gYiuAnyb+o5W0xN5CObpF+idE5ZhmOLVCVpErmmYrhzfKryr9 toDe0UUZ55nCeUw5m2Y5Fho/b4bn+0yJdO0BBQBLlGNhuZlhtTjGDKgM1dhaKEBlBKq2LXcOgPOa JUvC3AoIMc30cBlM0VBrW3ZBdQAYj7c4pxX2IpX63yJdcJE7KYcQbLwCF1hAEwMZKoopAupG3BLJ FbFfakV73corG6y9DdjXG6a7zZnt86CPMA+Ebhs8i0rRJZpdk+YtZMrPkx5j6hIUc0Dz1qVQkN8g P1CMLwE41oTJPYJeC3ueR9WU47UTTIleBdyFI0KyzaBtyMM/Mb40xJ3p2NxLU5xePu03/nUvGbfl QSwcjAjoKO1EJJt2jSglLszsGlubaEylDduH0JW3JRvaaNZpt7vX1iYWWMjb7kd3YBTog5QluuLr E9RSTCq5zmu6VS3n6j7CEGTw1uhEux10Y1hM8OaZuBnqoinjdK+GMaUM0v2X3T0/EJ+HD4HkMjyN YMpcd55+2XovWaElmt1uV7f6PEmjDTQqTY/Ofx199UIyLJtBX0gIrU/QroYTjx2tK11nmZQzoDqn LxLd8h717XcrS+xWVeoV7rHtYre20mD7/hF6j+7FjzXgPcuQzxAAJRhEHzNSqHWngnPaqp3OHukw J7FYTkxllLOSjj7LV2apJfiqla+l/dYT2p7yROvRY4HlzDEuL33ihuZH/7mMJ6yAIUG6TVtspPiB E77SexMK59UrlKFxnNmb5/UO/LyMOrPwiZbYzCX1Wg3YRtvWkiGLkvO1oDLduWEOrXI+TVk22gtB 02767obe7NTuy+67P8sx0b5BWDt31jwK81qz3Wrv2UabaA7KWKjyXTnsRESq8DuxjPsnWlDqeuy0 TMwVaFwqwd/od6DUxjZjPWijZV/ivK8TnWplwleUGrcNaFUm7om/h9sNCW995+l18mijbanrQTI/ q+XBVoEs7/OBrfAjfPB/Qr32oQSbII6uk36wv0ELNjXBwJPfKGChvSdOx03YCQUAM+ELRsrF0Gxa yFXusSPrZXvjKkoIgAPFuZOLiIuGIi6esDeyTgTDQe+z8DmJ3qdWJKAdCvoIhjTv8wW0hqhjfzx9 WGkijqhFT6fIwY58oH3LqscYco9Ogz55JljhQE1Uzy3Rnfm5x0MQ3dDLa6LBKTEk6Wtthb59ljdK 3ep9WxcUiQh3Cg4OEaFKlC6RtCLCnXade0NE2CnnViXyILoGONb9gB9yPHCCNUqG/pTbJBjMN/KF VzBn6BlEYLdcjAWW2VueMDnomBOwCQgijOme4PH3nPhMBA5Ul4yDjvms498Yq/VqgSYs5EUnVW3Z +v7oe2VUSKswceBjxwcKspHTU+jhib+8ns9b+Qw4BGFil6uHAhem4NDbLErH+psc9JlrgH4M7fvT IqRRTuCc9Z6Xi13jHK0D1V53Z4kdUdJXpMOBvoa8J7cSefKjfVnNxt2IUwU2mO3K4UfjdiIsd4r9 zuELMAN5Y9tAkd82k95gZC/o2Oj3NqOfHXgFRu80xO5F5G7nk3ZQiHsytO20JeIgH7Bk9FKv0Sll +oYY3X1wtNolUnogPiz4ADlOE1fBHm8hChBsLXrFATPxoLxlUm9beQcDJcl4L/vguDMoT9NH/jNg vXQx9sOITuSOE1ShW85dmlM1+hRrozWMDSLfouZVEmBzvipRDiFTG4dVAmm/i2GH29jfD6sujCbC qC1l+NTou5d6aXdj7U9Kf7fIak/reZk8Va2mKMsUNjw5kAp7wA+uKcOsl93LNiHXtYmHLfnsUdo5 6tLkUtuGqfw3n8msx11Rae+TBPwoF/hHRzd9/KhKjCp8qAdvQTOPdOuc52LGBX7adM02IOKWAwcf ix74zT/2Q9dQxVOMsgmRcHS00Lc3Tl5S24qE46jLD8wCobIAx3aYGapGT1bSr5wOVgq1+W3+UKQr sO7NyS6uCyzFvf7NV8YHMaaYMq4Gs8M5Co5TQ7vp8NUizDkz6DttGY2bba20gVhA4qWWus3cwVa/ VPq9UrRW5t9M3/p+/5l80rFc+rP3974B/u78EXC/F/agF1y6yjW4Vh4gr3Za3K+/K22gWFda1/Qi f+a/9j0Xc9m47VqcAarkmKlkW3Sqpxk6V407mSqK39Y52m554Z1CJyUFM5foH9yOGi/DJZ8k95de 5MogVjt9CN2lBGv3jUxd0kxGre0WY0FdWtf1Iv9eicUvJ1GuHdThvjVuCkf90dYGXabOLU71YPXV /0pvG336LdzsfrU3f+/F6vRZuZij04eB5W9bjRJqfajj5frCC2Va9VCFy/GeTp+A19e9e10QHWtf Pd0yXcnaWhtU+Y+ox2u6i2vhrmNX1KBQl3qrfRzUgXBF/RcWxP+6QpMUyst/a7UB3YjnsWPhSra+ Y32umScFzdoUvM5DGT27bfXdusFBMjyp1dL7Sr0X1GhNuOL041qsmrhn7qmraSo3Sy3ULalNwo8N CBcWbQqX9u5ZX8iee4jV+b8SLdDZjlLqpSywKZ3lhL8zYad0+wEowe5/a0oNI/WXBpRKvXMmq32+ +Hu+Ov/1PPN/12NXOjy6WupRGSRXcXxCPQ4ao7pn+79cneFv+1fG77X7gob/+4UYRMbnGuXPxSeL J3CmZz93TON6oDa7MkOVxd7EGnxPfd3+L1dGz1ldna85aTueinR4KAs667+Seeot3JdLSGAiGzDJ AkwEnNcAkwi2aCGh2rMsPSJbcIv2eaGlK871EhHe9oT0QmzpMiWthqe7pvVmKL8jhWiZ/K5VqFyr 8KDJZA1SF9+SV5Ds/ongHMmWY69JHcHJ/5tPQ62tvg/jJoaJ4+Q63I3TYT0O+P2T/A9fv3r17a8K hMJa2nOegYeen9HID7YyBz3Rf+9cXxBTy+++y2/+60pPUB6OJ+TDe1X/ntbQVfVv9P8nyliFPk1S d7JTzKo9OIpWk1yVJsq62l/YFbuxbUOEEL2rlxxir8amn6UezhC63uQTt7Sau5qkLn/ry3LwotDc 1tRQRc8+tuTFF83uMMB3UaTOXGisF7I445MzbrsM7fepqMzmW1q3cvpor5ZgStzRRRGDy6FrQY7p lXzzolcrLLE+QPGrGwuoGwSQLtJWw33AzOd86LGu0ke/h6V+5JQKGCK4tB1S0SiC6lxmThfto57p ot4K+lgHt5LSZ0R09DMsOn46lfGy1+kForwXQPTJ+zJ+w/aEJN2wQt2jly5HN3f2m+kM8SIkl5XT LW5wpYP9baUBhGzvofxS1nFTvfUj/JMovqkxRlUuiz+4xvgxB61wcwL+oh+k8DyHf6GBA712Ay7d uWxS7KBkkGAG+szAFP84445m8OTbn59/+49ffv36RfbzD2JUkUArtnQkqTDYfWrIbcXuNxuYVfbe Jy+r/IO/i76vTyWNvtIx9ArdfCJni0oi58noUIQ9IGxrHosvEXioLPUYbORzCd3ZzlOOH+ook348 Hd7n6sdSqbuLy7+dfsW+KEKD0PemLXvwxLf4bA9Cg9x4Xa3dtPc1MAP2E6BheD9C4/1Xiv9eOSic ynJF3m92faEvqoQv6xq73p8Awlzc2wDqFHaNstwM7ox3bIECkRGXuQB+c4kNlUNQVLY2QW9tCDEu q/GVrYW4RAW18CCatDZIX0BeKkHqpwwyP2SQmt/o3VKVIG0Xd5xrkhtalqZfPddWJXZUPp/NWtYH 0atK1OBN0vrBqGWNQRXoHDJJ5Ix+gjtEtAgaE9Ar2f5l4GCE3BTKSI0JsjYIv8RxjW7bXH3mqjF9 P0VHoJgm301AP9Rp38s/v6ObFO880mFOEx6DJZVHo1C5uIgrOp2zZQQ+ztnfZMaHy1LMX4Q3LLAf J/k4ha9wikVv1XHHpoHy4NFFnOLk4kOCab589vCwK0QCBXCwxsudHIgTCCUKI3lAiOoIDHgCxbkF JsDBB7Q+UW1yGepFAkrXjDDN9swu+iAjaOpTUysauC8kbxghOy8yhvc9I+zlGrYYwX21rldm7Tgj uKHPIUZYWYXbkkWahWVXNr8B+XVoRHWww7wc4ipy6KbQyC12OkcOmCz40QAtrugUYrSiYEp/e78E uBAHBzyYn62XxVDPYrZeAlxyadyAOcbHwb0lYPPeDDoN891iBa3rjJ9dO8WgxL10FYnRRXTsMvU+ fvCIocPWL89ocHdauVN1jAM87x6LDoNpr0BJPRuUP33xejHsoyRNFeEkyN9wQ/RgCdygqVglQIzY Z2r4KdsP+NtOEfdqyngu8QARf6PtJPTy9waX7HsPQG8PfjpO8gbnaN9yCTx9pmeNBjV7VueO3PJU Pc86BB5r0XboeQsEKAS7CkvN/lnJ/VHfmkhj6+CIP3f8JJoJ8P9wIqjH7pDdzIOh6S5/Ob+5YDDk +Q4LQa0YM2cIFHvDa9sCz6a2hZHZLU0PXflU5+KBRUyxEL9PSZ5KI0UDnAdJ6c5Sac2+1RjcA/wU AYY4Fxn8r5qu8Y3trn5zHTjh5QyDxPj/NINokVHRuW8BNjT8wccbyrvp2fcZb0C1iA1ZYq4ACVj5 37IpwFzHHxaOmDIHqg7qIuzEj1CQW3kgF23TKMct/EY5KIvWUzyYpUo8AIg7eRNl8vVSkdHJURCv dwo5TW4XWFfXK2vdK9V+RsMUihKeI1LkjNuQgBcSvT4ra6PiXakNzjb83mJUTQy9CSULb/dClqhi 7o3zVABrHe34oGcvLHQFJpKc9m9TWHoLlYI+4Ir8LJQxKFqKsRXXTY1olZt/k28hy3NDl8iMK2pP yYwobNGazBP5r+OZkbvJN6ELC0yEjmD9KDSLcwlkycEAqqDEptZt3TDVIRrzALHxzaEBi09A2NZY U0rysPdJQNRKQ1bddoJqP4Q8Z4jh4wZk617uVBRBT210WRjuONRh45Ej6SV45FFfI9ULq8t+zjA/ FtP7nZ40Unexx1zi+jF97RIT8eMDJzJCgNYeVjE9OMUUuPXYqA20C8ILUj+kmHsPdrV6sNc2v/lZ /bbxCLBkFGGNld4T+65STvwI7wJWO14J0Tq8QD7LCzMmCajGEsnh5EJMwMy2zjrq0/7+EOVKPXOy aZrg35tqrpVyqYYh0W0+xX19qOPWTI4bvERftzl4CTuEEjkgJXCIQuLIzxME+YmQ2QWrtuCeshJA eil7uC/6tVr6K3BOoluRwdUjHa2k07cF6/tkC0ElQoSJsRgbxlifhRmhgxCsc9XPHe0lazCOcG+k mmXIZJvDI90XvOUfsDH8Awh5JPwpuNqsjE6tceIr28OJi/B0ZwJc7s1pIYGnRXlaKRKXahsy3w9U sQWrBsJGZIL4iVfpfuQ2L6hoUd4BIwUke0CIXl78Fgb+n2P+KTSwmND1r5Z+qrJS54dJwja2Gelt 9uwHJ9u16W/v1pwuhfygjlrJt1Kf5UlLTiBee0DVKCk6rsN5HUueVBZUJSU/BLhHzaB0tdbWpvf/ Yca1pVZSDaUWPaY37PS41nHPJktBdpas0MheSL+oJVKvtzprwrZO+5uqfgjtRupS5lPTVImpt02a QWx0I0J3yTab5bhonROSpRb4zK1xE9HwhP8W7WgxmOXPD+CxxzpOg/IEKRpOOmO04b6HOWiDLbes NkpvwUnXjxeUd2z0ulxaZgSZ2oPN8/AKq9UhCkLQhSQ7O2gqu9NFaWatQ89sIT5YxhJxgV748XQs EafuaVy0Uv/kzViCxn3mMMGOMH7+0Hst/ZgADRMbRHc1J0CSFwD5N8H1jsXkPg4sDZlecxNLbTIK VEJXMY30Gb+E4fj/AzdcpZoKZW5kc3RyZWFtCmVuZG9iago0NCAwIG9iago4MTUxCmVuZG9iago0 MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDUgMCBSIC9D b250ZW50cyA0MyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjQ1IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBS IC9GMi4xIDE2IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDM1IDAgUgo+PiA+PgplbmRvYmoKNDcg MCBvYmoKPDwgL0xlbmd0aCA0OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB zZ1dt+S0lYbv/Ss8V3NYixh/l525IkAICQQm3UlWhmTNIk0TmOkGQkOS+ffzSnoke1e5fFRV50B3 X/hYJUtbe7/7Q1uy/PfyP8u/l1PVz2XT99XYlf3cVeNUjt1UTVP53fPyj+XX5VvvvGrKZ6/K2v9/ 9UzP1FUzd2Ndh6Ll7tBXXdPXU3lo+2rq57Z49rL8xdOyb/yzXJ6+LN/6ZVPVZVM+/aK8K98on/5P +d5TUbNLT3ELPc1QDcPYl56eYo+eT8u7D94of9aXd1/rMpd334e75+HuO12G9NvzNwqq/KV8+uuM QVzB1KZuqnGcm/LAIHKY+rPHY2pTS8rD0CV68pj6rhjXtOUdDPwssPMLXcRqeCwouLtSXPUX7q67 fB56+E6NSWAn/V0nsCJDC5qxrcZ2no8YdKIFxVoLcgW2CaBiVyubcZBaju199AStLLxWSgu+CsIA 90hI8spnXHGh+WgOY1UfDrt0FkfW4wa+SZb7fDtM1WHsLuUbAP8mwO9F4KIuj8i3aa6Gtl4sRNBI C7gfk3FzW7W1rG20WFv0lFGQCXAw7tvEuHyOJUdV5DkqMatqDs1rw7G27qppOBzbVCvBU441gVV1 uCTrmW8vH8LO/lq9T+XdD8EV4jShpTUELuRmSvYKl99OfdW07TEnd11+dgjijW9xZUhUj1U7duOW LhzrZm5ItOEM7jNqKUQb57GaD4rV9kK0oJuX8efKkHGcDtV4mDKCG/mmTai/LbBJpWPcRhSBG3vp flRQsVgXF2Lg3OKP3NrAz0cORQxRaA7rbtH+KmjClwH0VPkh3OEHPg9aAv08QBVI48LjGEUbIFH4 WWhsCVAz1WoDNmW9H0O0zVw1w3AoEVMOam5wzZou7Lrmtm00v2jmSE4eapDBESK4hYtfiacCBoL9 WxAe4qIK8gUsVpQWQUibHjbbRMzEwTQWY+WI6I8VPRSPNb/oJNphVmier4HZBuEKA74YKIVf3TS0 AWq7BvycRVjp9Uo1ioed9Lpgpz/0fSnr5QnOAyO6z4XpCXgDRa+ERXnWSiA8mQ49VWFTl3ebYMQ+ 0IyHfRFnQIu1cDNXJkngDtMDMcnK+Gnwwss45V0ZUKoyGFr7yJEowiOK/+TuZZ/5+a+6nYtogil8 pkINGa1AY1AO1AgeYTQTkZ4q32Z5h6IzfvFvJf2MlEdxQcqjlds69JrsReljGeuqrntlSPSvePrs TCAXMyAavFIgdamKj5IHaR1Gu1Yqnq9Tmzre19XQ1XVXDvNQ1ZoZ9W01u0zR9lRvVIgxHFy3YzX2 7aTE0TDVU93O5VzV89xMrfNFXzxe4keJk6qdXp+ga5iredaU8v6gSzaNeHl0ipLMQGvuDuYOJeLy rsyHy7igBmgRym3DEowCD/5BjTpFpSr2gyeSbbpQqZY8os+h7Lp3RRrV3JVjPrc20frQWc1xqKuD 1DrDwGfTc5OH7Juqrw+g+yoPeeRGMLE4HuCAj8AmY6FBw+IVPEYx2Gs4FXd4BZwL+KEZOrQWfoGY 8wWJCm/hLwbzP4KGrLGcJqubHUELw8W/QAQDO3a6PmS0z+GCuNDYP51iSSPPB4SJW5C25mRyi/QE Tb+j0U/Q2g+Duyvu9ySb84D9wLtrJkU7SjWNYO+10YWurZqmZzp7lS5YpCB45gPAZzO+AN8/zw4z rtD5xuX+RwXDykfmjjPbBnkcXJnWGNu2mhRZbDi0o6zGuSAdGNtLnAG950Fd3P3SXRXuvg3If++u 0iSB3fnGaMb+O9xGVYi148+/wiNS7R0a+Zjrb7nG6lGz4u90xtNPXGPykh/oKUW5/+UeFoWi+LJo 0zvG3LxlMypPOGiukc32y1Bgkzf5yaSmUwZ63oTBadrSinrvzsKgXMEg8H4fBvFpJBTFiPwo/S2Y iEIPiCvvovBjMBSxZEEQ5zhLY1cIP3N1VSl1LWI2QznC7dfG9mpFsO1yV1f35G1/iwFsFMllRuBE +iEaPpZ+sCMXS98HI7GLiKwIx184WyDTAFYSOEJf72Nmnjymo247TXwOgxw1wnldwDLMfTX3MQ9+ laO2KOHuMcESbUEEYpR7lHd0HLE82opQXtxFRxMzIPf4H4DxSLkABRBDNx80hb9EEFFB7NC85820 eFdEPe2g/Sh1PVxC62X+7sqoZ5iGSrPBzcWTny7sOXFGwd54tBV3v8LsRGMVgyTAGDF+LODfYMuS 3fSTnYj4iOz4dNSQ2Iqg7C2hyh8RJtqv1E1NeYFULkPJlVHRoLRXN2yC5CgouoWc+9ZKUkJ9GA9V rTlEhic4F6vjyb6XVH1G2mPhq3DHNAhz/J0Kte3muS6Kz5ntfxPuYtIgXn2lIq65fB4q8SR3tErH tEMhHaf8gnfN9AhtzJj/LzTNc7YjqnwWqvwQLi8UHGqgabx+2Hae+EI1VYUHoNryAiK+VmPiBb1D LnxiRHZ8lmt0RNP/ESizfCEvwRgs1UxdITCR5MXztzeKTO28KmXglg7LC9CXrQ1XuJRFG4ZDNY85 meFzyoAk4DYcBVRvBlSwBk0Viwpq8hy/IXLQRCEXNhtajbCCBA6fht6jUY5x8zsqdpPmQVetvJA7 rt1deTeGy190EZwT/f5uX1M8qkGnxdzFmvLSTcbUPQyz+hrNBT/+ryhVehBAM3LI8IUpl2b5zuNf h/FqaJnQvwJsWnKpDq0mRlo5zwRbNvY3NDF7uj70k/Za5C5DwFp7WTO6jCley2gLW/idCj3oqoA2 23SEbQxQPgyS8pWKmDu1XSFT2rE2FV0CmUlfPGrt+v61Jhktp4c9I2yVHXJB8L/CML8NXoJC7AFN U2gtAL9Zn5is/drlWKuy2Vhiz6NqRaNwTZvdLAx3p4KXqcW1Ub3mzN1Us0vcrtlmRvUWiGAevkf7 9VcjYcAKFpAiwQiFNg6g0QQJL2HAQ6FVjrjqYFct6BcU+J5SCEYhrcXnoY0HMb+WxIR9TxQ14ckm lKli9YJ+KXwmdsnO2zFxB2dpmt4hiW7tc9+rMfkXywoeOCctb6lgiehN7qLYfV1hwz7fF6l3nbzE cJhKzc89EDMi9WzFuMJ9LbFSp+0M000LjZvAJiLmNxtlILc3jYfA6yxWykUuCYletIgdYVpTSeFe f2ABnBCA4BjAgEUU/QHktTql2ORfQeFtK5vqYMlFDyAXyv4RGrPd2kAJAuESPo6xU4iBYXULWizr 6B2W00O1wv+D79romqYaere7JB9v2fi/ZZFLm+urwxwXF69yDE+F49V+LeuKE8jXs01ro5CpxZfV mOMZrLfBiA9hJgx5m4a8qQJJZ0C+NuiWCB4HWDYq5zcLT3TLwtqacItEEGy7DV4pxYMM0LoAW2if p0OowBLxADWtU4V3ljRJIPmDh9cHwW7WYt8F8LtMHa7Nazk91e6vjTXfo7zWuakzTLSW9Iy01jqB YCxYrFUHcsgV6CQA+sZiQANkeYILYqYnZrC0RhVfmHYuyiS6kILnuHwQCiHN6ilNL9BRIPHQoUTb 6IXOSZP9IcgqI5KQrN40Q/lQd3KvXH6rO5c8YG/Qv+u2S6O23g82IWSrU7ACNmEKbhDrSvseeF9v V2tnZ93NF7AwW/tuCsZq93ZVXGvfnTWdU78/30l6S3YWBCsL6ORt8YxBRZbIGSFGPbI/emEWR1gC EmgcapECN69AFjVoLDkv+sVe/PmNQD4gsiSisUCKKn46nDSW36CCKhSeV/jVti3PJ0wLj8MSCIUj ccZnNQEmeCOWtmUzei7JXnnOYH3syOiJ7k/mNSu9yNjxvGzO1BzlnldBOr3brQBNbskA0UZFR34g WzGumDWlWYreN6/mZszZnnlOMQjRkRemDgMGp4mygEtUAX5MqF3HV15SKRlJTboAg9YqAvMzk9uH 8IdAEO2ybhjKwJfVI+5Sqmo9NWaevm/u13iGE9aZJ76sdcwSkar43sW6TKxfYXS75qDdbVoliNgK Mc+u0b0M61emqvpJK+Pac7MVg2WmqmDqnsEDH1ZQKWL27Ac7AAoc07Q1hqS9Ni0cj1uLfCYe9BAC bNAS7axtxhroDNWssqF0zkwpBFlOw/BHBaSTMtpWi8Fd25R7oktms2yKS87GOEdPzlkdendJhNU5 b15mQ/sKVVvMuI4rqLvNVfNMZD91oeq5d6NSkt8fCwGAKOQOTINia5tRF2wQYObdZx7IN6fgnW6T n/EWngw+He2RxONWeaCF1NNilDNt5Sag7nlFtNNLPoM2FvXnBZjwnV76h2prRmykg/lJSxpru0Pc Yy0UjhPzYx0Z/SVee2tiMQHL8UvUxLRQuEg6k59XKETX6QydQVvtd/h5pBDZ+rkh3uzFw96/nKPz gW6e/iMLq2BwP0nNxwFWvhbwFjqbHihp8roxBEtjmyDb79YvS9A05FrrYKFjQV0ZX/PAU9dWiaNa u4/KKKuM6X82dq6A8mLbe/ciYE7Ukk3OTVDWgks35K6Db76O18nXnEyawc1Hzg8pNZTw6uGHJbHw Az97AQytpKVB7yV+57pQVuYTd112HEPAx/yKfbNYRdE8HSmNmkjNDapP2J/xdt886eQJcb3fZ785 H0kjyjol7ISe+ye0CzrbSRvkttd/jzzXLfC8bxlwoUcvWx307myG9p6b0D4BF4iexaNNIBDLAJ19 YHlApdwF4AVQMRinE3Buu8Rm0xfzbPI4QBAnDlXWR9hQgFZCv8WibV4x97QNmmzbSS/XvsLabqus KKRN2dAKQ9qbR9EYF0haYo9HjC/8cXJK2wSQbbnznyS8qOdKU5JbwgsQdK/Vcxk9b0UXq+dsOXii MNlbHykey9VjjAc4ac7ilwf2DDt0ggAet4tk4IHfrKaidpvBVCLXgxlwQS4PUEjNmM+iJ2haJ2qT q+AJVJlmIA2mKcg5XRp56kySn52t3aGayYT6FRa+1WkF3UEraX0+uH4cC18rXTDdsiPbst/m4AAd skTeSB9BqUom268I+5qmrXq9G6pzMNwoMyyM3BgDsuiCaAqTVV1rH07Ewpnn4IBV5einLHs8z9Jp T1YNMpTYzl44oCn2ZGnjDhVj2OcJTnqHHOGFbYU7y0NpoZFx8ZBHvraTTnJtak01sqGcrVlXQC7F Tt1c6wzbrFWybHq85bkyYav3U3TKUnxH0i6WHLlZKUHGVIMqxybW+7OPnIldTzzuDYU2oF1ERwim gea7rm3NOD7mGu/fdveagbxPOdUfIFJ8RPD6/dl9W0bpZETa2Wi5Cb2HturqmN7/6ZcburFzWr4Z lJ2iF9HbS8QHpb8DJp8Amw911TsJ/Aoco+EkQsJnYeTij9xas2iPxqM5a+np6gkE/AqCIq5/z/2H YVU8wpynNmM2Zgn0xrQC8vxzxzYch2S9TBwXaoedPx7CenZCTWZFtMb8icch+4wD9UbDEgOvudBm jA4hBpZrnSWp6KPsiR3afigjBF8bFdW7qYfmFo0AQ0iPOIC7CAJmjpvOHi//uOeOaLFfB3ZNpdJk mcPNNpAbgXx2ErpzB9Y3WUnoW+jJTtV0nWYY7S2ZGlQMReWVkmh1PsYYxfu3MVpHzvYPFGNzUmjp M9XHFmQdPKPJ2IwIPptm8a0lC80rZpGgD9SzAo5IJ6OIDUEPgOWCiWaVlipvhnZ43toZCje7THRB M2pEV2sbXN5dTpVeiksW7qKtej4Zes9ZpjqavZrGuS/B0NY0SdnHHz0bKjhrHTYrOf7jqJj4dOiz Tl87lw3d1LEnKA02FuRwh0aAIxBIM3KYCRUP7vcaf8KtIkAHj4uHfcbPex19XwGNC+AZDG4fR8/o UUqq7Ol6Urx7tMpbm31d91EIlmhP1xPp53X9BqqOdf1hZ8vzwR2jLHeaL9Vs5bppwqHNrn2f9YZP Nj23TJdbrRE1ej9wyxhmTjiOld2D/0TZfRydp+yrVOYZ/TKT7+gL4wzH6huuDc+E9n0uUxQT0MXd ntolHchTu3X691oXS5fF3Xm1u4GqY7W78LtE+1tT3ItF9aBgfQ9WP8UKXzvpS0tjTv43W+tusQLt QUeBj69P0qw91DrEKitpls2fW2Yd7agXcqaYlrFJvJ8EPoM+DTVnbd1TSPRHF+iMq23s3thgyjBE rGFZG8Fv1MSOESlguSoTt1OFSUy621gM2vztPSKy9TbjlDphUgNNNjCLUwN+tJu1oqXce/26Cwa4 DhfLhdb8Rvq1DtmhzWFcUegdyOZzOIPoTGycxnh5cHaEFqsDPVKUetHcxW2c8PPfnU2t7h0Zbbkf yxYkbvnrpBk7m1rPHizuv+zzqQ5KbxRs1+Xn4U2Fd54U0sR6mKa2147brp37RuZ9+evJOydbX3+2 7Mz1CyAHbaHW+XjPXhZtqzPKh4NOR6q13e5l2TaK0HTSoo7q1sHuL8onnm/L444t26255JSe1jtD g5a+3NMv3bf11Hq8D62lA+b3BuF8mnMQczOPOkJdJ6aPOkJdHZyUvVCZXlYS1e6k9UEbrFyJ/nIL DvHJwpUdt/ai/FLHr38aWHu8eXl7jI5jGtNU6Uwfvac+hCEuty/8iN2vy5gbHfiX6vsKqb7I+tJz 2Im4cacPD/qclU6Id0PRiNX8UcELHQenxRRlpFKdQR8u1DfpxmLUAlCrLQ2qEkpUxcnR+ZCNstNa sUQtbTyn4+4PTgiOhNi+g25zcGfURaJ0HNk4O0j5gRTuc4r+Xp8BEEv07RJ3jC9lL8q+15nwXnax zDFXswQJPbYdSwqdoh8oUFtLLcpySpbnlhE6GmKPkX8LVYhhIZ2CZTRqKYjqpM5JwTOPt7b8Z6Z6 OoXSBwdqgUmnFQaFsvcv9Lt7x1GfIUh1ulr77PW5R52Orj/CnSNR6l08s/e7d9TVET7RFPi2DhKU NjrPRerZ7VfxZPmNK2XrjsJ1f0rl2ql2ZPhbGRp9coyn9ZO7o23RZe5376jrzpfzJst1o7biiGXQ 6DRxxFOU7tzzojDd79yJrqCe+/ZWartgSJ996LTc/3JVhDJJ2Zdq10AtaXxE1nnsnRiSHbuhZoPd KBa93tL/WHZa66REjFvK4Mh69KkofP2il7uZOllrf27rVDbaGzn1yr7JcOrrcM18HNcnc+msdj2P k5AQPPbqNrU6ap4xx3R5IWvlqnKJH+KT9XXvnPz6k/IPn7169fwHRVpxy+UlfbBAs/TRydH289io R9+VDjCnq397pB5WH5c9vNWMb2m7UdP+XLHvJx8tPaZXrrdjj8jvjdhDDH+Q2MNHCy72OBz0vYtg 3B469lBstvLDLpLJjz3k4gY9HwMIF3ocF8ny6K1LZWVdnJFCD3nC1n3uJT7pQo/TJ6+MPLQ0vo48 VrcusJBaHUUemrPF+q7CUv985CHdU3gxrkKPWLK2IbEsqrkc/aA1MndgQwoOOkH/YEKPUHJc4+h+ bTwGTYLnTihZBR2D9FmfBHZhDkGHBFVNB0GcYCneq6VoKuUfqLMKOlJZssup7aUEClxbKVAI41hb tDj6JXSIHEoUjJSsqYplC507JVfHD9r9F8P74Kjj/Sp+SHWCl9eeB33pYg4RwkEOwqmoKA+/cr97 R92mVnDi+lEw0ujGBysxdiiaxvch4+3/wjf7v1fhg7/3Xj61EO5c2yEeKCKNPuxwsUUcQYoH0ghD hBJ5QJ/mVzkJOHZc9+J4oJUrc8H5OiD4qeAT5xIRiHsKLWecodBxdGtVoEyCsN7dHYIqZegX967v U+k9er3uuPq6ufsYxGXuXeclyULEg+sW1ysvf5Qtv96908cjuvfcHs649+HEvff6YFOt/ISfSNWe 7/pszdCqpB2qRjFTF9188oo+Mtr9OhVBlY7WH/QxnHQKeNEd/LNcfKijXVMh1FH6zSentEHOJWt0 nh2JM+5cbo0DOfQb343Uzg7OWLEZnO1hyfO0aVgJTp88/+7Z82+//+GzF8V3X2nSpeH3igNd+KdP II/iRO8+vKqPSqwG89YHL5vy3W982mPjARkGTWLEVE1cw56H5QEXVW3TZ9ie6HvnlVIwrzw995w7 sbBdMhxrTaLDC4gbbBdAtr9cmyhzTs4vbjcREBr+ONZTd0LZ/S80LZTpU5pSw6iHx5RpCf9qQPhc bQLE0XHN1wzLs/zVs53kXq9PKY/+m6/7wwrfjQ/JvZhm1tFAbpc25/Pq4tZ1dSFF6dK2h3AsuC62 plsEmwp/oLYecGqixtxymS604taRl8bIS7v1vqWQHtz+KRXynG86EeFyqOGBM+p1HiQ3WQ1lKzpl pAJ8t6xGsm/RavDhIy0N+kVF3drUtB9JOL1z4QAs82lvLfd/G0YLPzE78UduYRPvnsAf2EtzcHlT nMiRKm7rhKhxR6hLcgvrL2b2WiMzv5O0aKQ+rF4vbxMZjTzyjGI2bPh7oJwBMHC3uVNYhSmWje70 OA0VTvGbXgjLGao32yvjE76kuZjt8pzZ1hyjdt/vHldDNHa4uMEsnKTnlux34q37gMhhIB4wnF1l /F1KQZzdXNNAR2Gb2w8mJrK+QyHPLarqFuEtIo8w7J9P+z/iSVfe+UpvkDAioln36p5EG+u8rduk asXd0WlTdG6tDejea12LYTlw8F5yBQe//nEcnOwZ7ZBHch/DUOJI20x2vWQy2slcep215jLD9nrN D+drLQZok5/Hpgt2YjpQOfcujwSC8K17QHSYswzavslj/LEeBsYf6WFxGg0No5Idbia+4rdRwyUc ehx/4hau5npkq8x9/mRTEWEmmEYk1nVanbNWcDF4K6lRBVftzpZblBs94Tdqpm6jV3aqvomhcJaW AFJJU1XJjumpCtWVRY2qXKx9tzh57aLQp443Q9RTtxMHuWc+Yp0j48TQrXS2LKLn0o/BgkFfqVNu QwpxCQs+ktDcpkSG96dgghmd23AkicIeCt3iviCQqd23mtVB04TJfV50Z1Qrr+cOb5LXw46yxRJb Beoxdbg7dICRolB+wIVD+Upw/w9m8hi8CmVuZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKNjY5NQpl bmRvYmoKNDYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDQ5 IDAgUiAvQ29udGVudHMgNDcgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago0 OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkg XSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+IC9Gb250IDw8IC9GMS4wIDggMCBSIC9GMy4w IDE3IDAgUiAvRjIuMSAxNiAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMSAzNSAwIFIKPj4gPj4KZW5k b2JqCjUyIDAgb2JqCjw8IC9MZW5ndGggNTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ac2dW5fktBHH3/0p/NibsxjfL7xNWMIlwGyWSTg5wANZIBBYbgvk8ulTkn+SVW63W3bP sH32weu2JZVK/39VqSRrfkr/kv6U9lk9pEVdZ22V1kOVtX3aVn3W9+nPX6Yfp9+nr7/5skifv0xz ++/lcymTZ8VQtXk+/jTddXVWFXXep11ZZ309lMnzF+kf79K6sGW53L1IX/9TkeVpkd59lR7SR+nd v9K37kSaVXmSS+Qpmqxp2jq18iRr8nySHt59lL5Wp4fv5TKkh1/Guy/Hu5/l0vhnXz5KeOWz9O69 iE7sUGqRF1nbDkXa0YkYpb72cEotchnlpqm8PHFKfSKKK8r0gAI/H9X5lVxE1ehYoGDuUtGqvXC3 7/LF2MLPUpkM2FF7+wYsiWBB0ZZZWw7DTEFHLEhCFsQO2CKAklVWFm0jtGzLc/KMrEwsK4UF34yD Ae4ZIRmveMUlG81H0bVZ3nWrciYz63GB3mQs1/XW9VnXVlv1BsB/GOH33ahFuTyg3voha8p8shAj IzXgfk/FDWVW5mJtncVakid1A+kBh+J+9IqL15h3VEmcoxJlZUVXXI3GyrzK+qab21Q9gscaK0ZV 5ePFW894e3mpnQ1GKLnfUKJs8myY9BHh88RkvSeK6NPDr6M+8N+opXS6sh570lzQhc3R0LrdLfs6 K8py6kQEDaKjoUU/sG7Ppugsb7OyrdoIpUbLc0l01g5tNnQSNp6PzqLlsfpJ9kWvbd9lbYc4moMz KyqYW2Qdxl8/+5sgUEyOC0W+G6McwIqbpQTliY74ERf89QhkXeCJVGaiqzvTRp4ePqKtD81VfqeK T+RWIisXixHo3uqXXpi65C1aeClPhVRciKP+KT9KbMwrj8dqaYTAwdIvcS2vN/mPsToqpyndw+1S fRbtc3eAtxwkqGqaLo0Hyzbs6pnXuVjFc1twm1V9U16LrZGZS1b2MaYmlkvWZx1xyeJ6I5eSwyKX 9AwFL/LtyIJTPLJCHfFIuLedR54yIY88g7fxKDHMnfNoq1TwKDk/Rd/hlEqJXfNeZrfxQInm0Q5a TzxqhmwYJPi/Fp8k8VCX52Qw7s8pOTzdCL6LIjk4DDsHAnh+Gg20JhjUeD5SgzffkDs7ebeUwMPo NyEYBV6Yliea8CrOzr6THL4Ym4d9uAle4Udq4xkywW9e+VUcmzgtWoBeiz2jgFZO6pVjHyeHmeSb HSUiPxexhKbIiuvnme74okWYhwXJJRHtegQpDk+C8rxJW9B4NRFkXWR13rURbD3lZhhyfXFh1cgO C4D92j3nw4u8ycq6aNNW9UZzfTYJPFyQ/5Cc7Hr+I++yoZQ42MkTMdqiXaerNw2vJfT8s7lK2Itm R9IkzitFkIaCs9jVNXNL5Mtb8B+Oa/os0DlyNHd4krJos75rxLGp0VzNPW8bzW2zm7KQJFFbVDN5 NLqOpzdOzauj6WOMcDQTN9HRcwVeiQ/OJajYmkgsuy6rhl6Cc6X71b5GRxULQc45Zk9RRVVmRVEv Ti3nzBZAR62LLMhzjtmTPGWZ9aVbpskzCTBkVccs7Nw919ry0rlVm1E8++L5wHAHf0zydWhrweso 49KE5hiuWAGcKHdcnmGQeEgs4wMNGxvwqg5bmIZTjujFOX8MDtVYD50ceBUrRKUzA0Ybt0jFS65a /P/LMTaANLSlCaUn3yud9Db38k7a2G6xk/xIEjfUSjrTiliAIFD89CC3sk5DvpxIh35TDXLTRPxS xA70VWWbifEeNqDv9zEgRSWp/iFmer8p0AGMTw0YxVf/JleJlNsxYEbvjKmO3uEG4/WfsZwHr80c +eKWYTyjFv/Mtge+dQt6QkCBz0fJQItGIvTgzX+bLkkYgoRAKZwYJDPQ0SUE1RCe0dNLY8X/fhRK Bx1rWtO64I7+Mivgx03u0q+G+GX7M4nqoc+aopfAMx5dl6A93j3JUnNZtXVE4Bktzw5j4N1lM9TZ UFeXTDOAKsDhcifAMVlbgA9UmcOSeQLq4IGCgCvkjQ+7ZlAFxxpy2FeZsz9cIFxIJiWviy7doL3o 0bTBz7ZAeBrNvslkIrsYjM0ii23y7EzdNrL8XTWL4vjoyy+WagCt3f1BDGDrp1+86Sa22P1bjCS3 2uRqyOAagJxFZeIXFEA3oRVZfe3SqRsjDQCR6hPhgWSC3DxtJtxjEdJmluwFklCd79Zo7Mf+THLd mP6JX3ubfvI6DENqqtIeDTlJHUFQOq9dg66FFvgRnvoCC/HTbgsvkw/zb3UqX+WyKtBUfbqOMbUj RXqwf/6x7nAmCrZdlrfXs1ohCzrZ0F6yWsG4+4sd6RMUHLE6Q/lpCibOPyxQMD18YKAt9BBePKAt N/sEh7ZJUVTcpExzdH0aFJI8cUGbrsCZh5Hkk7lYI/l8SnaC5DaMWyd5mEJeJ7k1U9oqaJLf95YJ 8Wd1L2YuHsXRfu2iqKnuZTn9epZSmmqQJdKLllI8vUOPNGf5mi97hiPCtzJlwG8Cd360ziZxqxa4 rP9KeZmguaycRpmeNeOsqPSX0cXSgXgu+glUyMXJwW7h4jwRYLnoue4dbgQXmXXZi+eiJejc4Z7l 4trenx3gr0rZSZ1LBlKDbT37K12I97h7g95Ksny9WynROb5XEvSWsq45RGVETyU0AL/m5FNDsGmz DZHX1+MMnVeX2cOreAEqJ4al4Ee2cg/Z/8nt0Tr7NmpZWxFSa3JrW6kVOqj9bg5q2croNap41dSy Owa6rkxly2sAnSugVlFkTb6YmnslzMrNLtyLUoWLzAoCTTMdA7TvmBSGpNk0SJyb0z6IjIaOdHFs lnY+U005HJrOfUQSzDJLguJAVvC8OY60y/R0kG7vJ1hI0wsJds9xZGU2I3fygYeA2SLoWtJv8kFR NhRRX/FEB7aXJJDqXpy85CfjZkEMsr7E7GNjDYiC3pNZCw1B+JFXXOaPh8SK9mFyICkzcSlytni0 zGjzDqtZh6Ips6ou+nRNUZLaCtMO4uSd+JppUJie8gwn7aPoBXcFUXHgoS68sdJ+1yvYVjbpKcxM 3ZoAQKydMyE3NiA4yi/5GMJWhcxS/16Vm0TPembFrHzLbrrinMrDb322cUUnN88lnnympzb/kzTU 1dgS+Sgql4TYwgeKM2e9Key8M0CYMvksUwEw3JhGMpzVzhC3olHudkBrzlMbr2ooz1ykQ+mI3uQQ 5lqmreOAllaiRA+j1xOij8mps6L7za/0Jy7YNNT0+w6tp78x4ci06egZfHWzgve3cHDr7hPZIJeV Rd6mdTTGLqFg9OaT2u7ekw97FzB/yQIDCHRmmyHj8wbsp3vILajC1MajYpx4pYd3GM8Ryenhr9zL uJq0iDPLcIv6rQvwi70AzC0P8ypRKA8R80SQZ406bEEHFCCHQZ2uCdacUYF3MyKxj3epjYLhK36L Fc90SMybfDiL9CL2wzmaSjYH5mXZpBtQdQnK4x1N3WZtfe8pfEaGwQMm3DH4pOX5kewdw3VnAJr7 DP4W4xrOXLxxDbHnuHWWRn4REIBYpibu4+tFRwLMNOgAMrWQtITvuttHwaax1LxCe7TgrYbtLn6T aG1Ro5qipxhjCPAwHy7IQQdZWZZi5aMBF43/HQnHKdCqZO9jE5VtPxXZoEx9cSvGt5haZ2NvzP3x 0ip8YZS4YKYylYOmmXf3WquY9c+iLrO67sRaKe3o9OfxTARzvgguDV9ewS5YJibukzngq6OtNdv+ DBVP0YqlO21AH8127iK+o/thTIFiSahzv3Wzod9o3fz+FYRBexAcfUm/I53SDhJUhaw0tcN8mF99 arAue1nnvv8lJyFNkNf6auQVZGNMt3sHO2D+2zhq81beNqitPONt4yv/oSjlCEkW4yo4QHEAAmp0 OO/ZYokAocAunoNa/JsPCLOyqrK8GcT0q2Fdh9lrD7e4U1ZN1tXNMJNHW7fjWS3ERJuL30ExGDrc eazM9yn1mzhcW0UQQZ0MFMez8AwIiamMNBKzrFSML6jkQ4g2b9e1NfMF0Z57Jo9J2JxL2UyeW6xX 1y4vzV0yPzsxQqFPQe9QEN8AMBgonjlzEnLQbzlkaLV10M1rT6OxgK2AydTCRZcDulyyaLjs8Cml mc03sn1REpnB8KyTXYD/4Cu5dT5kklVbnM7PyH4JfOPTC7kcBNYvLn8do5fzN1rxX2InZACNG6vU XanuMCVcPhATZDY7aZMCRAEszwCO9i7hBN2jl7qfSLsmt3vL1d3fmPvjQDesODks+jlgypvcISU8 gggU/2a0sDyjAOLBDgrADp5BY3rO5UepbLLFFNDc5o7WNeGpRdp7wLmU7PPuBqHYCKFryRFXQy7n 4LkV1FfP+KqXBWb5JmopgTdj/KmpnQPz+viHa6bT+Aco4kc9iXB13yriJP6D0Lf5HbCGxEnPEefh sFfIIl7ZdHXqtBuBPtHuhSzWtgCNLHpKz0Y7KFBUR+OYBCwdRkCvdFHOG0Nbma/aWl9eoTJqWRwr fnxmxzM5PMUwvh/thhejJNnBLAvZ02GSNnTyB01W8mlKJ8dU+mFaIoH3M2mRbDla8pQ8MUddVp0s cuZRhymdIiW23HPSDo7LGkM1Ro6tE6AvE82LF2Q8uNyZ4ZAlKJulS9xhWNqJAD8AoAdZv0m7HHQJ RpDJxYLuSge0a+LH0FElB5/HtO6fNhADAHI3giwNQRbYIRylEwACgV1adg+1dHSdxuyd389F9+gH glCAZ/xIg3SAZ7+NDhcdTw73Aac0ktXK26pLHRhPkCNcaL8kJoye0lStzJSL5U9sPFnXv2lhhND0 osL9j/akT/Qejux88cRBQg90SAq/X5yh5RmQCMNHf3gplXEBg+zdWCTqDXYzEulC9enIEbq8E+lm M681MloBCPIRckUvstmq/CDYz3ipmCWRIyoEFJZxCohx31uZzFbvohRiAMQI5x5NjB2TST/Xlwy9 uLOYudspp6FNMQEB+MRWYbS1eeUOa8ioMVw8o/gc8+E0glf0kib4QQhEclwLl4L8OhglaF6HkxCY V7RMrlJ6qF1WhGw0ONnmEZAWyPSJ5nXVugANoUoGxP9o1RW6PX/ynygogPzaznMCk2TDGdyVOSW6 k6WOeIhFI34hTopOD1Tm06HC7z5YO2tiNpc5pIIBSadEnjURChl5HKw/a2ImpDonfCbVxEvNE81L uACKeBOn4JFigyDepLiO3l0sSPkQ4H7DjOY1DULvRYRqYrEsxI+ae0+MQ4jPiJBwoA4tF72kB4+l 4il+Rcps/BEfq9cKUYA2FKE65p5eiz59r3KDj3Nz0nfHRt3rqOHIFHjaJqtH1YcQ9N/gn/lCs5aZ Tycn3joIXo2nksUFOQ1jKaI8yQjUxwVIa2UCBEYZO461FAR4Ra//TYBFRa/vkJTjd2TdXk5nr053 bBaaXmIfo/etmBNH8qpyZ/Eo0+PlcYfvRKaXL4pQ5PyqrnZLlqvJr8kU6oH/2JBMPj3XUQKnZPCq DkAwW9pcEjnoWJfibk+kDmCwJLwDxjBEmCXwFyZSfCKYNymOzaHA4szVhSPUzTd2FEQ0ylMpb9I1 XkEY7Jlv3kYlFI/yLvZrJGpBFb64/YZBexdYx5u6HO3x47xHD3nUYCXbuKpe7CE4vBp7KBvfZCvJ JWeAAG9o4QffBoygnDEBA2Hs7NM96xMuCxo9spN1DZwuLTh/yO0zw1zx+E+tm0wO78t1WkMABg71 CKL56R5q/MEMzxPr/ueoCpv6wAggIYKT7+9WIHSQHNZ1YGvXOqB/mkb6XFBNAGyBDFmkS9phc6tC Nu2bFWmzqTISW9t80s6PRUs5GKhoopYYT/kA9AcMGC9trbW5xFJhtBkvxkQ7Ep5RwE83x5VBTRlt 0WleR5HasFswL+wVjgTBUVxiNyasfywjh853ckROuqZ0CQTCHJ4oHfIsak0/05i3BfwWNd7EMGkG UDXFeZPxpMAbjx7QE8jijJx8LKdTOcVciycoe/kzWfJndRa2088i421k1V/YRE+wy84c8OlWK/Xm Hx9ArudaIQbE4jL6AJ+8AAffSgJx+uYZxAAHCmrqUw7gACO/ZXohWbIy6fU+8Na4A/FTtGhJ79P4 CMUzZKN9/cwdPsivXg2hE+VHJxWs+PSRSCDHFtIIRoSeU2R0hX6ijvOjBPXw6qKzck2iM8wltpBq pNJ9pskaprOnB8nyfFeJaVqHWGiaLoF89PJC2eVZ2S0viEdCHv3pC7pF4bgizg4AQNqjcMfQMqay Vhc5JjtihkK2HhZFX8iYhDpYnadtG5O9MUMrf7inj/oodps8e81iI38+b4hagrpEnuh5filb0Rv5 ivlqvJhsZhXPylLEFeBH/nRkLh/PXYtXlXRRV7jPKc55VZfxwHJgCHAr2nI8FsdxlPvEtk9G3cy6 mFhlqoA2WCfurP9afPaWcZyymY0DW4nLEVs7bus4vfd6YgqKx6Uz2qu7Sd9a8F2Nq+O51CN901oo xx95xh5B7ha7cT9/KZKqOX3wKarBmPsMZTgtHUZBu/GiT/VaW8/ZYejNnFDMhYS/ConxRP0/ibxH 7gplbmRzdHJlYW0KZW5kb2JqCjUzIDAgb2JqCjQ4OTgKZW5kb2JqCjUwIDAgb2JqCjw8IC9UeXBl IC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNTQgMCBSIC9Db250ZW50cyA1MiAwIFIg L01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjU0IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAg OCAwIFIKPj4gPj4KZW5kb2JqCjU2IDAgb2JqCjw8IC9MZW5ndGggNTcgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2c27LltBGG7/0UvlxTBcaSz7mbMJBAwQwZdkKlgAsYIJxP AwnJ06ctfZLd3l7estfsQ60Ll70sqd3999+tluxf8r/lv+R9UQ+5qeuirfJ6qIq2z9uqL/o+//XL /KP8x/yNN1+a/MXLvHS/ly+kTVmYoWrL0l+azrq6qExd9nln66KvB5u9+CH/81VeG9eWw9UP+Rtv m6LMTX71VX7KH+VX3+ZvXYk0m/Jkl8hjmqJp2jp38mRb8nycn955lL9e56cf5TDkp9/82Zf+7Fc5 NPG/Lx9l3PJpfvVuwkMcUKopTdG2g8k7HiJFqa/fnlJNKVZumirKk6bUJ6I4Y/MTCvzMq/MrOYiq 0bFAYTzLRavuwNmxwxd+hF+lMzHYtfGOGSxL8ALT2qK1w7BQ0DUvyOZekGqwVQBlm15p2kbcsrU3 yeO9MnNeKV7wjTcGuMdCYq90xWU76cN0bVF23aac2YI9LtCb2HJbb11fdG21V28A/CcPv++9FuVw i3rrh6Kx5cQQ3iM14O5ScYMtbClsGxhrTZ48GDICDsX9HBWXrrEYqLK0QCXKKkxnHozGbFkVfdMt OVVb8LrGjFdV6Q+RPdP58lXw7Lsyep+ffvehkKCJLHYP7KMRJdtI4VnblRIYq2swK4uyHCQ5GfOT qxebwf5UGlGepB/jnQnh+0AOYvu6MNYuTbstVmpO5KJBdjBHK9vCtlW75pxLstglj84Zb2LZmDO2 Q1sMnSSPWzmjJ4vknHE1Wm6z/iRP3xVt1ydkWxIsV32PEBD/c972gbiLEE9ISF547/nOH3Swfekv 0h56dLdkJ9rRgFj9b2kgGSsXSYBo/h/5b8y/uJV4/rX3Wu55xj2cfu670y1WpMlPTtIsDKyzuU9O 0o1kYFzVSvndDwHnf/LI30oCSHKoA+oPcouZskPyOqSCfRjDKSBKxS3n9OA0xz26U0L4T15VoT1K FuFuL0xVtipMY4a89Vhcc417cVXJjKq+sWvyXI9SKDXhgKVRP8b87lF2QMOJM1YjgbduqioXT3eP lODuyexzIFpM7NMOhe0fDjk3QzEMkgvfTM6pbOiylKejNwsrwQPBuT/3vjb52EggAAjnhhy4CIGA nCWphkn6OKvUpBq8WXPc156V6DtSpVDEkk3eHuUvo2xbjMnAPNNvt4lqa3qp4wiosdqDAXVTFl1Z ppRhkp3skhSorU1Rl12Kl12G6syFLNBxEaqzU0KqkIZql44AdWQC8c/xSk5vRHX0CnGVC7k6O19d tEamub3Jt6wWo09usj3FxYsSxcoWxtQpmWIyqi8KHdYWvV2l6kWyIKBmCtl6xivkIBxZqzNQwOH9 ERtyD+kQQVrzJxRNOOc/7vyX75veIpnPZ6Jzwo3ZLA0CNEMa/Z7qjoyPMEA/OpuDhvkPEQk/xA3+ Y0bLLXiIND+G8KQZbVVKaVX4qD1vQkG4KhyKXpLK56sI3y4cTsmIqaTANKxCKnrcXU7NpARtq7ZO iGtpEDc+3wD+QI3DmyPgJUXRWSmTK7DNmbslCzMdzalP6YarNMQbYGGINrqPq1wjxhMthmB0Dw73 1QjMIDUUY5u8RdFrad91LtGO9uEosEx0j3jankfT5Ya83Ma0tUNRt129+Wj3gelmqIuhrtoETN9J FGn6pmibUI7ZLFedy40egwAQTAAgcOAy2kl0qKAdAFrNVF6I40rxMdU3Ixr1sEjGal6Sa7qSBgJS IKBdDDDzkKb/o532l6geV4lYqsd1xkXdGUEL0tAlIB27aE51BbL5rxhJakbndJ3oiQfylcoYmVJ2 Nt+BtGTkXzIrkAAsUXi1Dnmd89CbPgABTBImtRpzPwhyxzyKqxrBdKBxAkCiFV2q9stovizMn+lF A5KZMqhhPN0LLoZrMixzap6CW2iOLFykaz369/KA8nwaX3oKpKG7rifXaRbwqef5Gt5aJh4iVB+n KZGTSnMK98IwPM0Umm/RByTPq0qJkumY2+cCOjgm1+KbtivK9qICnwYKICLPnlTrqceZJJZZHR8B DQ0p7KRhg9kjyudMqYWgHRdDsbkQDxKc0jeHxy50Rdg9H08lB1yfdQCYgF8wyvMw2sLdNVZ5Su1N qIw7kcsnVdnprwj0jOPfOb4nR2HzJ5zSColwFzp2kSIL6wHwAdLSDrk4Cy7EVXFs5RjZq9xJVNWy YWeQTS8BiQ8mLWq6YmgvqRhhZayAbgN2otFdyRJg6RZYkYaayLT5og+5zgAShqZrzjQAdS+04+I3 ntXFg5XxX+k2MiOpZ9mPrOiVnWB7SUHPzKF0oubIgWePidrc/wPIterpG527hplUQJyvBdNprS2u YiZsR+fYh3yM/+gGOtMkQgM6oxfsg0WymzfSrVYCthdFx1ytbIZuh0WS49SB1DEWJppaCt1dWJY4 NEk5E3acy/AfZkf70UWd9WPYcSDSLIplmKNofIS8ZMt/dW8uaGZh/xy96U4RDZnmaI0THzydBRYg xHNqzOvEbbXrKLzTlpZlSRtOPzrwL8sdzlVf+hldiM48BGKL5+2hnX1VDysz8LKWbVQaVXoTzmIG kIzyFadLz8aqQdYmw7KJlmdRqjg3FV/Q0aROv3XHQTkSkLMm4EP/q5NFCHSDB7PTYuAtHqS7ItnG B5jD9LJb2bZiY6XTTebYZ+N9mJuYTEq/ZZ+0FLVPnqMzACtLdUO9OgtOxNzjMQmVAiAQek5Oei6H dqE5wOVMDi0dTlNmGAZIAWl3FrNazdUI8v4oiHQT5PunlnOZLDtvoKwCQ2pi1hTFmQ4WzHt+FG47 t6OcdtEJnUsiC4/BfzwwmRhagFnphVtIW1aJGZG8wrOTnpgzEr1N3J9Ivgccs6qMLA1XuexjPYu7 e+FeyXyaMmXl4xz1RnO5CBgAjk3gPBT9mccHZ0AIYGNnoKeBOMd+rCiRVtKO8WiXEIcRAgghmRZX Y4YRGI/mejz+o8ykoc6DvSbOOM3GGQ8hwKEgd4ZDWTB+lRNP29ayPlBJpusNnzb3IIHSMXPphM73 0QuaUE6Y73DCW0rzpRzVtbLfLP3hk4PRAU6YgmM5bigP64+bwfqcF55xJmeTJGdysNx2JtfZmaTW 7ZHG+HjKHwJ1iQZIxkUOX3gm0P62BJRrTp+BV6AC+nZPNiVhC7jRlCb8qQfRkYeQ8z8RXBZdoqhz OQiU9Ilf0DUNCu+/twThUpbQq7rOhbQdZhIc+E4wLG/DFYNJegUtWZ5LVjnqXt71k0X0tKXdhG0i 1sNZrDsjcILQE7k41k9BALDWkRHf0rEM13QwzMIbeeD2GZ0SR7iVIeiNIZZQdblmEIqGOhzhlWfa u0d8PI5v4lZs5ss01FNqLiL4X7TgPPHP3uV1qSmUCYKsfsz8FLpYTJOvxp5lOyLhGi5CFlHCLG7u ePUzZetKVcrLUoO8NbqFK5k43PnelXqMIiLdGs4XE5l9fqcnVvIGyebLZDGW1fI2XlmlbBY7F8re xsiRm+fbREA6mAJ3GlMBS8F/wnnAc8DWazLOlIrRIxB+DoTPTeZcy7DmcdlkjlcWYr0Vz0YQnFcH SpRAEGR4LlKN23Js/kO/DKS3XdIZPssttINItAlozp10rQt1siV41DfGkhGOeat71fqGXTBVbYu6 ltegQeODcY6mKYaqv8Q70CkaZhEaBuTiosYPoJgTYaHgFM8Auj/PYtEgOIk2PTa/xrt+mdM5RUyQ XLaIYDpBAsx/SkbAgdzaDDLfllf08xqVewhs5tb7+PFgIayu26KtU9KSfeJouk6uvdZVJ5tBwgqD fPlAtq/Hdwt1KfZaeSLPBXDpLxfOS8SJ77HKQlljKzGillJ932Ah1rWocobK3/Hsj3M4SMadjcCc /wgyUCLtxF8S6esIeOVzFbYZ5IMV6rkfAHhtL/sm1iv1CzvcDXrlRZCuXa8qL5Kfa7jQoYqzTXYc S6qyqUlKvoEdd4PhgA8YK+9pjq9w1RsPey/KL2WraZdUQr8EDOmZp0yNTZ/yTZZULKhplI6UU3k9 YOEfYyQVbMATZEnEOioLBGiI5Smxd1G20GVH6ecWiaaTTbCVFMSE80fdreVJ9wGtSjZo930oiOkw tPDrO4FW1UuVfEjdkK+55AzPOGyF2KQDjuTSiSY/UCAxMpHtK/kKSXimB2PzbtwruF6wuRebt5W8 JFBekqvj7hEPzuaBR3Dzb4UEqsga5BrMtJj8kVJDLK637PQm5MEYX8ipFFvn90zb+biH7mAfGWNE 2e2UKcdv8rj0u0rXYrInH8ioYnlCct2iM6vVknshuvHDZEbKSq/4vePHIzqmtWmi0PQ5r1nhA3Do ufr69HAe9CQRkoIn0A5lEniM2AcYJ7yNo4ooieR2wMymk7fKxy8FSYV8ptf7T5yrSr5RZR/MrE9E kSJdnPWp+dSCa1NzpVnJOMJiN+woZWn8gEzY6w9fRgZbjKBjLA04cKfuE7qkfE8CxuihfKLBTAs9 ILe4KseygKfrLTD6VPyalUyuO5t3ruDEkmEmusx8esEXIm6qBFhJAU0vO5F3YCKZqVfkSU7n5ZNu RVeXKS9BJstzgFKmyFF2UlMMc81NStnlM1fjnFLWNAAoMCcRoKxKGU1Hd50khI0uGu4aruA8uqVL GaIrOA+mU/2mDFAmUuh0BLEheRxxifb51gA9Ou0QQmco2oNinHJZFAMF13lH4p0El2ckRfwbFo01 WSCA893sxCD6FtrDIIzMk557xOMuepNLVFIBMLI5uQKBD2XJ1w69fL4nFAAOeQTK1Icno0dIchGs GYx8iA93f6TRSEG0Nm2un07PQe8jVbS9TNzkK5c3Z4rJdHgJPVtJtZo26RO4qXToHPs9P5GBCfBV +ASYRCZwPs9FDZIsgoe/ie0EbJ0MbCeor/S9H9PK9o3x/Zod6ks25yXRbfzYoO0ezvYNK4oa+vVq wML7UuHl0BJgcjVGijI7fTgeZaL09JIcyxH4xpddzPgqcNuYfOupYt59h592sY18e3lIqnHcDQpl 3baRXUSe5DYjSrI8B2pkMeezVVVIHFidni9QuE+eg6t1Vr47Xpar08gInzv8Tok1tRRTqsSS+0ej q7XxC42adWPa6jZ7vCa3Tlsz+E8HAZiczLhQDWI6MU8V48V516sX34IT5vsr4pZ7HTqIT3QTyAWB 9cJhSEa3vv1WychSxSv9QWvBqv/ip3HnqfXq0+y5eF5fH8voYpEP5DDSJdrXyTMjDaOg2an38n56 m8Q6ZsRCFxJOQeJmdrRCrP8HLI0aCwplbmRzdHJlYW0KZW5kb2JqCjU3IDAgb2JqCjM5MzUKZW5k b2JqCjU1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNTgg MCBSIC9Db250ZW50cyA1NiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjU4 IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjYwIDAgb2JqCjw8IC9MZW5n dGggNjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2cXbPktBGG7/0rdDmb AmNb/szdBjaw1MIhy6G4AC5g+UxlCbBAkn+flvxIdvt4PFrPzjlTc+Hyh6R299tvt1ry/Gr+YX41 fV4PpqzrvLWmHmze9qa1fd735rfvzOfmZ/POu69K8+KVKfzv1QtpU+TlYNuiGC9NZ12d27IuetNV dd7XQ5W9eGn+dmvq0rflcPvSvPP3Mi9MaW6/NwfzyNz+0zy5FWk25cnOkads8qZpa+Plybbk+cIc nj4yb9fm8LMcBnP4fTz7bjz7TQ5NvPfdo4xHvjK3Hya8xA6llkWZt+1Qmo6XSFHq25dTalmIlZvG RnnSlPqeKK6szAEFfj2q83s5iKrRsUDBnRnRqj9wtu/w7TjCb9KZGOzOePsMliV4QdlWeVsNw0JB d7wgm3tBqsFWAZRtemXZNuKWbXVKntErM++V4gU/jcYA91hI7JWuuOw16aPs2rzouk05swV7nKE3 seW23ro+71r7unoD4P8e4fevUYtyuKDe+iFvqmJiiNEjNeDuU3FDlVeFsG1grDV5TDBkBByK+yUq Ll1jMVBlaYFKlJWXXXk1GqsKm/dNt+RUbcG7GitHVRXjIbJnOl++CZ79UEbvzeGPMRQSNJGlUgJO 4iZadkfIr/o6L6tqqcnNkJ+cgnjyzXamREWbV61t13xh6ZupKdFKMDhFajFFa4c2HzrJ1bZStNE3 X08/O1PGtu/ytusTkhuJTatQh3HjPQ/ujwWBLu3gJkkBQY1HX40IJsSRKXD2h0NwduARGnx5kKuS VGiq94/GXEbnizT8c3QSfY++aa5HInzQQCcxXz56lCU60gpQJCPfjH5VUeXDIPhIN0wyTnb49YRb icq2b6oRtw/v15Ka51Wf4tbHcPvYQbSMoH7uTgWxn3D5mRwFgSBIsrIzbZ4dn7+VhdNt3ZmNl4pR yJSZTN/kpV46QSVfnwK3y96BbLjJqZ5TRVfzrkrCiafqQPIpyvjAHUU5Nxw/4+iVZA7viX+52yiL /nEiDvT/H1ryKBMRbnrHjjoP76AlQ1x4Yt4w5s68ww+j1zMSDX6U8WV2iV64h/NzkSe5xwjfX9Lp rcztus7WAQAJbHw/Tt8MQkaSiifN31GYPoBOIAFzfz1aJhhY650zHl3lZTDg72VhFks7Qg1SMO43 o9Wx5Z8KA3l07exEKWQHnZdCU7brStOiyusxbZF3RZFSmkmG2jl5WluXeV10iYROStuOhhQLOuqr 1ZlVZxGUnvIC14MHnUEArkgini9ofyudlgVljewArGA4AKiRRzcale+5boQvH7ujhKAbzZ+7xXvi +8sWJTQ8ifdCSvGdxIC2I2uo6jZvikoCmrLqFWQNtsrLsl7Nvh9kNlBVeV/Br6emnRHD84lmgBA3 A3RUFhMD80+CM3GUwLtnZA4iQhZKVXgRSEeQMAYErJ2KCBvvealorwmfM0CriRtc0wtOSBFTj7eS ZUxaoD0y0dC/U3Qk3gkptLuHF+Umb0Fv8WX8GyKw7kYPzz2hi8t5p7WFVJIr0x4H34P4QmmlnDac 4wxoHUBiNS4uEz9vkUDENxByOH8MMb/PdbrCVktO910dGcb76rLbMJzGle82pjPHWNsVfWgX5sOr 8MYRQKDWjO6b1/lB3lUyY/rmIqr8dkzYQCd9ykQ4FaXzzCm1Vuir0jLBaTdwscCpzIpyeQuhON6C w9PxIu/ExaXB/JIS915IA9Ez9tYkxCNoJr0yvyOOWlvmVSUVXa2DK4ijMmGpbFjY04Hrrk3QmD6g Wy5quEVDec+6BITfUjDRssDvRILA75x61GRh/ig8PfMZugktQAjZJe8E6iKIPOpwYC4yEg1WnTsM wYgIRUPGjUr0DsE9dMlIi27iwGF11XkSQ8R78+mzvP4Fw1RZ5bXMjE2rwPbw4G+GOh/qpJLysdpT YO4lB83RxAqqRhENtDU0c/MIdotTFO9KELgG2jomGFc7n3eN7PA/BXud1uASoB4indKambv8Pmaj DIRMiM0Zo9OcN+Me7aLv7Anoq9UJdhdoh9VKQkqYAkloINaYOYWU/d7kVg9bdbLGJ1tHAgivpZ7Q 9E3eNmFdY9NJjzlFKA0C7ugbK4GZZA4zAEDOgBzNgU7MeFYiCuPRTht6CTLPpVoy7VMh1bsRF3FT /HD+2J3LVH89o3wlrjDldYGW6VkDEWk15njS+16sn6KPrdqXS+HcigouFSwQc2Wveu3f9KrVhFA6 5EQ1ETIuuGpibZN3pRQcAgyvxi0ki7VNSr3hmFckpaIrWQQGwgjAJbqBx/FEWDNW/nlM9WkAm4Mv +pTkacZwW5vZduS8pSuUCruZZofqNORA5RZUpazvkhytnuB/QJ1OVx0Px/H3lsuVNCcSEqRD36u+ Hd14TnnBKRlfvyLjY1deY17PjFWaydiJtpvP2fxGRL8Ja3Px0payv1B2n2zZLi5k3eMid9N2edE2 Kfsij7nh0l4eNtqdtJPkF3WSopP9o0VrwpslrNA4kk/a8XlOGb9punxoU6r4ryeO3t2QvNuiqXvZ 3RAWsPQ8dQHEY4Z/TODG054T1x+8wPopcn2AQDccP+P4TI5Szhnzj5gTkPBqvqCsCsFoyue1I+t4 ZgLp3IPnyDPohdRYk5aeN6zm/4EfoTJYS3ej2dpLEctmMXVJDVG7aM7mXWN7cwJeaqepiJnufRru ptjeaRo3aTRWVhv7sKi3C+663IAVOaD3KSB5EpwCyyyLWJ1YAZRgYlDkoRUrKiCTmP3XZBKdmzGx wlgKV3VlYc2W2hbVrPthLSnQF/36WuiCtc6R59RWpAlWlawVD/XFNokBhP+OjAXVQC6B3sAeuOLm WEbJ4iTrBu4bSW9aX11MulbB6YWIKz4IsbPELemST5ZO7PUqZc4shSSZtaDgI5sC759HJI+T9dsj 4sw3rN8P/mRPXFUkfdZyLIoDH3DD2sjHwGU3/p5KB7IOCgOCGXqDyOBTqG8qhyUm4bsmUFIiauVD EbGgV9u15IbyYVI+lEmLBufAKjk5rHv57EpWMRJgngorP63+xMFKSj3YHFj8OM6rQeBaDIwbW8l2 VgtSPlfLQt8EZiZ8II8hdCQHjtzjSfZhMRCpE48EDk3mVJ8Z8s6MxjCTf1wO9ZX7lG4oBqOtulmI fD2U7dyAXrswakNhVOdkD5Fc1PJZUiG567j/XBKNopYvCt1HhbcvTkgnyJAU1j94+rvBHQmZ+/Bn aGv5IFLJqD4bXKhscszHeN0CvuFygDG3n3vqz0LhZ14xubuNdL4qc+sahh1gZtoB5lNh7YBPkGiC vys14Rp6KoQH+igV48kULFxiTdICmyAw7qbT9Ni1l2nedfyAkl5oDt8gpy6XafbSL6gZRgtBwJ3m ClPFMTvoJZKtAuIcRYlfw1r54qO08t0dKLqWUnDdSLZn5QPf/ZtpUT+a5uylBBa3D5xTjTZtzLDs qA03Dw2xhondMSOPaKBQ0cSjGJcGqxtGeJJHaMDLANqwIDGf+Mm23De7iFYVMp9pusYEk1wNRGTf ZFuvJiQL3nu90KXLCekJku1k8eKs6hm2xvIcAidTaYq7+nwGAdTAH4gDxlv4+9gzOm4Qq95glNRG L4XNcb/8+jx6yFymkLRBm1rECdUXTHJc2bfvJclRlrmCJKfqpcC+Xnh6EOSW7hvipArKlEFokK4i 96mATKg2ZPggt1Wp/QLdgBywQdLgWQ6XA0spGBl62etcK2VcAViKIZesOKSgW+nd/dCchIOyT6l2 7MGKjsfsLQENsAx8ovM90AjiwmyMq556YvbKxZBrQXaQJb2uT+4CVhcfIAR8I5jGrn4hnWD4UeLs VN+DLrV0+pFlCjNfZItZrfdAmJwGuh3q0FL/MvooXs09RKK5eOrlvNHKv4gMg5QFZLZ1DG0PwZR2 KORPZ5J2XZ/jjMm1ZttL6VEmgQkpWao3ehQ9n6cH8WthcKCx9S6PghWmWh72cZkJyEj7RMjcmcj4 AvHmarr8pY/s/q1MUElCnep+TNRVuS1sm2CiZHl21Dnj8oRtbV7IN7RMrLZKGnH1JPwJkhGySK9p 7JBS4FzYTmajCylV1FuIJcBezT6eCTClEsA9Ulu+6YHmYWwmVTAhYP11bA6eCQ+kMLHdvI6hmZ7O GJ3QxcUQnqZ44na/xVXnhUfpfjV5Q8nz+Z/7f6rsTW6irEr5wxtXiA42uRokN7KwXF5NYmRdTbUM FQtdHIyQjf8jAxQSDn8RILZx02GE0PgNuYZQfOpTR8pSVF/FsobQCwn1splSLu7lZolWp5buGvlc 1W3sCzq6GgjJTkhbXU0JQUQR/jurhLAKqD0Qgj4hPggM6EA73Bsn+n5PwgUhVFtXXREWQkdXAyGh x64Ok/mHny9aV/Wo1yfzi5T5WEqYhCEf+tYjWaShxcxIz2kY5V1XkJWt30RKHe3IOLkncToRYDtS D7+T1n2nohX48Aathj4vZe/UWkK7MGhyAnknv5ZNUyc4PCaQVS9/vCkp2um/ZDqGL8ypYRagBMUw 1WXXG0wDOEi/NAtp/NB3AKDHUdw1BZnRKRtpaBGK/nQHALkZoi31epkCuwyTZ7Tgeqq+2ttHLkjL hgidjMYX9zN3Bn7fPSpOov2B3PSXUQxZDLjgNwOVbP9qe8kpMP+10G/Vyd8KtmFGfgXe2sk0tEva tnHMPQLKsP1zbB+w7ANznCyoGBzXPZnRAMlQiedUUyy7GhKcKSSVHyDQDcfPOD4bi0bBkREfdGrk Mo9CePwI8Xy7uCSBsLis9qPwXtt84NckEIYn9coGboQGeFLHqiiaj3raRfXo8Unvvsgr0l8ucEm+ KDUgK56poHcFrtAWUlJf3zG0CFzHXAFtomKIclmc3ZwJBe/BEtrWOqxM/4CVaKyVKHp6JlTkje16 U6GcBB4V5dw6F1vZR+FBFiF3vBqB9+nK3TaMvdvwSJ6M31WVbO/HdvWFfui7qJKEzOKcROeUiaZE R2atskkqZSNvsjw7EtNJnto5esls9Qr829pcktPrSUzl/9wL+crndGKabK5VOG//JeVkrlL+pq60 iZ9Rfe48XMo8mpKIQng437i/JY/KsiqBins6ekGYpAHivrMGtNv7/+VPnKBSWiJt9uE9Rmt4Bplg DwYMeQE3IXPOQij/ZswhuEp3dGBlZEm3i/GgtVCpe/E/fOexP773qjISLnp6Xe3lCxl9ttCN9ik5 8y40HJyg2cEfzOGr84hVkLjxR5luIit00ZoKJG56xvhPmcoz/g8xml/GCmVuZHN0cmVhbQplbmRv YmoKNjEgMCBvYmoKMzkzNAplbmRvYmoKNTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1 MSAwIFIgL1Jlc291cmNlcyA2MiAwIFIgL0NvbnRlbnRzIDYwIDAgUiAvTWVkaWFCb3gKWzAgMCA2 MTIgNzkyXSA+PgplbmRvYmoKNjIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgo+PiA+PgplbmRv YmoKNjQgMCBvYmoKPDwgL0xlbmd0aCA2NSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngB3Z3Jst22EYb3fAouj6psmvOQnWLZiVy2riIr5YXthS3PseRBHpI8fZrAB5DNA/KCPLpD pbSgSGJodP89Ajz3l/Qf6S9pn9VDWtR11lZpPVRZ26dt1Wd9n/76dfpJ+ip9593XRfridZqbf69f SJ88K4aqzXP7aLrr6qwq6rxPu7LO+nookxcv078+T+vC9OXy/GX6zvtFlqdF+vyb9JQ+SJ//kL73 XKjZpCe5hJ6iyZqmrVNDT7JFz6fp6fGD9O06Pb2Sy5CefrN3X9u7X+XS+HdfP0ho8nn6/IOIRRxg apEXWdsORdqxiBimvn1zTC1ykXLTVJ6eOKY+EsYVZXqCgV9Ydn4jF2E1PBYojHepcNVcuDt2+crO 8KsMJgI7m++YwJIILSjaMmvLYVgw6EwLkrkWxAosCKBkUyuLthG1bMvr6LFamRitFC343goD3CMh kVc845Kd5qPo2izvuk06k4X1uIBvIsttvnV91rXVXr4B8J8s/H60XJTLDfKtH7KmzCcLYTVSA+42 GTeUWZmLtXUWK0RP6gTpAQfjfvaMi+eYd1RJnKMSZmVFV9wbjpV5lfVNt7SpWoLnHCssq3J78dYz 3l6+CTv7gczep6ffrSvEaUJLqQicyI2U7AGXX/Z1VpTlkpObLj86BDHGNzkYEuVtVrZVG9KFpW7G hkQBZ3CdUfMhWju02dBJrLYVolnd3MefgyFj23dZ2/URwY34JpDUWnhlcpF4oVF3Ooh4X94VuQ8D frdNMc46+vhobCrDETEYQCfu7lvbEaf4kqbcTgHjzeG7aOssz+smhV8h8d0JnMRZVn1ThuhZGK7b gVM7ZGXfxsEpaDnPIGNC/SBkHA7mkPEACkEmOZ1BZhbxEnm9FnSJYYU4xubuhX1HcEsHcMwdTegH 3bo7MYolPznheXkKmrcIRY0glJZfWUfATAT4jImL5x306oBJxpxpT/JmE9Sy6ySzlZBOEqp4eHxp lR4WskwW/Z1995NdNMvUgoCR4OAttb6tBPyA96vKQrRQ4gjWF9LGO7EOzZANg/D9emcj1h146Msf ltFwH8wAdUDmgZ+MegPwtSw0tpmBh4yiwfmdFSzT8g7V0qCGJFrShNnp91IGG10LHclQ9dhBYniI gpoOySKTPr5OEwSCY00L82kFZSJI0qz4URYo64vHeCCCkVLRZlpWDkXWDRK7t4AqwsZHu5wDOjdF VE2edeKbLcg3I841kGubC6f/HFEjlRM4jjT+ZT0AyNJQwjahDxgeM3YyymbmarTHYhTGpHvQDSFo 3kEZ/bSngk6A9R+rxbT04DGu1XnR3W6I6Y3+Js56rLDSFqG2WOmVzBAFt4NuzBGsmciiZMHejyWb hc0DOlCVg0SB/SA6YDF3b3SgLrI678hyDumA4yoyQo7fW8uijQ/CAai0BO6ZwjmAeygPi8Jj5Nl4 K5r11DxOTx/KVSq+Gv+OHnDxo7QREweenUXnFhKgElxwB5V6WUz1sSEgOf19vApBV1z/yRXCHnFL L8aHIi5m/OT0p24K8TAMGnCpEIbyL5lptIAJWcnkKzzCt0v3IDzZsZVQFXnWFnmXtgpRuiJyJ6FM VWZFUcfkzWtWXhuTgPhSLz5gr6Gt8ck7PSiCdtg1SElcmX0LiXQEz9Cmgcymh3YWWjGhEJrovpJ0 m4hBCN2HpT3bUmUhpY68bGVjy8ouwlqK7CAb/nK3zOZsQBdUf5zjX6KXdiD4kIpS1tTTykIB9p1o SVlmfRkT70eHZgfc5BSaFcKmMmo/ck1psZkgm+rSR6OVnXsDe0tbdEnHPNr2GuD4UB59mVvyyRQw MzjUbbx9mFtr5wJQd228GU0/BMbmXXIikNHaC6jnLdPTZyfhg2yy8TSTO2GKd8TzKrP2QJgEqFi6 nrkzpskXEgaIh17LyPfZkD3+qJRyadlVddoCpXujabIdW1Zua1v7x0XhbQ3aHtPzzCCA03Hz1mym buL0LSt9BgUL+vLZA7GJyY1tmFeyYT6MJVJYE2Huo63QARvtrVAz1NlQuy2AzeA4mh5jFQ9uSTR9 k0kCEQxlFk5jDTpLq2gQ9GS0ihLFot0uRkZpMRIYAmDCOACLh9os2FjGV04xRDTFSHFHtMtD7JhO RH+z+QQdfCJqTI4OVHSc80rWJgYIeqEQb6AXyNDaYNLd9zP84s7z0thLvSIX+V/BWnf/cLwv0tPf eL5kwDyHhfETCTdnLauiH41Sme6A2D7I612m6F2vRo4YVE0Q8ZcYS20QEd231lfpiFGjiZYay6Rl vMPRkwhI931S2xMnF7XsQpdlkcKle2M32y7LW7e3dA/sZtNlQxuzk/t/bjYpBARRrI2htj1YKaIJ 3k11s9HAEgvqqr9WHpQOs8lgDO1iXyhkNKbgIU2xvjw0xPgC0Vm0ekD5Io+kVEUhoGratNmDLoiH hUJuJIEHwhizt9QN9Q4Cb8ek170cHLhobwkk6AtgAzoeesY5r0QBxptrpdAAZgYUhrBBBx9AjguC xUEQ14B4iPB0zinD6TDfM6KDp0QLH8pVdOyxXCRPYxzmMIjy5x14p3WTfo9uEm2lSLXKyz5tlHjv gfGvBtlidbs8Ot9aBM23A/8qz/LeVdw1PZEhjQ88DRzAzBMw44N4W9r40gY1k8EZ8366MM71QTyV guSkAx+vFoYOXeEAgTooYl7tR3Twj/qiTnSgCQ8h22PcxMxoFavX2sgozscE3R9qREeoQCt1RKjH lnlvzoTLgRg5lp82G5C5EwiXsok1RJXUL1Gp6zaWpzxdXHGTx3y8EBvfGdO8qlHGGMdq1LKK70r8 2lMAUa1R4M4r1ryUtqJY87LetmKZJV6vEv4DgHWV8OVQloQqsiTiSl1UDcRwo1UyNImbUntq7v7h +Pw8ddZGAdsg1YJIrTxQpa5KOZ8/dGkTDbtoLTgQ5k1akI+nuAdq+HfveOVzomyQ448RhddYtTR+ 5kwt7ZaOzl9ABRgMOjptx4038cUqwK6DQY1rp8daEX2OMy/kuKZB/Vi8xMNyMYMnrjI/mYyj4Daf w2yf1pFwqWu7Wr4tWxefxCnqYxhhc9QnYUFl2/4YxsO77uVbN6lRheC0iJui1S1Iz/Zppome8X9V HnkAGiDqC7D0D9+o1wFBYIZgiRnJEgD0FNRFwuqAlRq/sSrGGkwN26wYN62UWAXnn9BH7Tbgm3dz RuVY6LJ4bCzHtNAxjWIwLYSg/joqUHUMhzYHvNOcNRQmLmHTM9ES+fxbnJtkeNDEyshM6fezjeR5 57bwnHe8wmu6+4eTt7w5qVZjbpXL96g7pLpPOQ/ulNTyCV1eBcvGi4B5zfXAZn3xUDPC0mkM8kSC Zsdsxyem+9ZZyJ6mFFDiV7mP6Qdr9XXTZEMlHyJff2j4Enqi04K6brO2vuSTAq2xxKdP0LSzRHtn WnDEQI92y1kjbxON29C2Atq0OYmyOMaIeotjlrTf4pj4HXYtdWaeoRzWmQMeqJT4oZRabQosQihd 2IZLUBq9w1VXnexwRZVDL6EnXmvKXjZv8jpiM2nNdt6o2oBp0B+OnkEsPpk7wAZxfPWC+6WJLgXr cOEHUfvKbyQzvVcpozbBiIChnV++WvfTc62BdE2CXg9lAVbAO13L08U/QiNaYiK0FYJYb1rmta03 /GnPmEXXRSn6GA+4aAU4YB+mwF72wiUDuuRINGzUFx0uIAykB8O38k0t/EcSDI5HNh4LnMQnOFQx 45mLMI1AN20mzTHYRa2IbaEHIt+xk3CHAgF98OO7z3+8gVG0lWd6rY3aUQHNVzbgRavgFATqaSGJ S1AN9WAQAYF6dsc8YfgNRs5yXLpo5LcT6ni0jdX3+DR7X0QpPwMj+ZmU1zQ9enviTtxjPmSSXcQE lWvuCGHrSxDM39gKJLCg/AoadblIYwwAgT8m+kEGW3MYNEGnAbN+yJ238kZL6aCtvFYlrS6MojWR yAyqMQs00bTAJU2n9pmSiBqdpyMvdZuPR6cnpVueMirzM7Fhns+VoTv43Xgro0muPKZY42ZWdrN6 Kj+01Ax9WiscbtYtor3UJWcB61wMSB88sH0XaloNuXyo64rP2mwsqnNravrYehltjIOofCaIG53f e8Dq3fE6+wrno/FevKK7unZPaPeIq32enNw9oAtqs1Z/khoUnnf6iCI6iupgRNBmZtC6hvNnxRyc hiRG0bzxpsGog9ZR3ZIvQKCTiyaeiRiTd1hA3tmIwdfIoZ4L0+utUt7drIZK+DjIAbhUQ/DuNbTq ZVdyuGj/4wqgIk0sNVYUMeo0W8uWfkhTuzwkrTHojv4iTb1pp3dYAEUwjTA+yB/K0lTQD0JZy4o+ mbCVBUIo87EWHdJGqZz51jwekQe2CMrxO+e6GVKHgIhUOtpnXJLZVF0p5Vq3hXIPNEQ+hsqL2PPs W7GAyHNMg8AWl6ej9kjUwW89AHjsKwAShEcG+QBhzzcoxXiquhmqtIpfaDQQAsCMrjlJvSnripiY +hJyoktO1fhrlkV/yVbaJGvjDPnc/UzWY9yoDZB2zJgjbRRfSLgx/T7FK0HVNMpOm+gPOQRPRWB1 IfAZxt8t7UM1sVlachKfvA+/e86Xl5IUtm3RpPsEhDFH32CpDR58CkA6jmtg4dwhNbyW5nfQl+ha Hk20l3TTMzaD0gaG28Q/OWk3y3D6oXivSLYfsNfV+HOu3TCxPWKvdJ+e7qsN+MpYVcnBF/ksN7C/ s8g51mJ8ZIrzh+8Ig3c6ig5yP9hvJe81myNan0Eb+OTC7K74AzIY1EzoD3LRFCq26sI00XrNPi4P YQXr1AZL2ybdgaFdHfAKY+FSmYfj/flhKcZgWbrcSH1SUwLnAuzwH3XqIFFmGDUjuf73gQMO7DqP UZXym3NNJZGVReK9CaxK+SHUyu3hbAZWa5qhLRI44IskbA8+A/hpHQr6E2f0jPSWR8S1TjCoLiw5 MD0WMKkis1EqNXrqjgYzLEC7Nh1847+0Mv52QG3SQWRybzAihHW1O4e+iZHbMeZ5l9W12+bQFZtI a/58NDLyI43gE9BqYOGbwRdRN4ZtgSBUAAOEgWM0E1P40gPDMCGg5Q5TpalgeiITXQ4Bqtru0QGS oMU5B2YyPXy4wEPdg7H1WnRLVISIFeq9dRcGzwpbTiEfLqx7ZhWUXiTMrtHOsWgOka9v9CBtLTXM rqnTCizeF10th152Z9ymw6aurtlzXaAAB7hY7mgC8JA8Zh32/1cEK6kH73DbSIjNXe1+GUxHq3RA T4D2Mvwx+wsLhANmXQZkCnR4CvZ9QPzmbbqcbJaTG03q5BKBE5GL1iV3YO7ZqDuiU0+NDiXuN6Qe WxVixVgPloq8eIfYGJ1+Lg57yw6zU+f8IJY02dkwWyqi1p6pUT/YtCe5q+QMWdkLJ3YwNdoxHch6 fJZR9pL+yKfox7OM90fRil8CojrE9qphAM8754nQDZ4iYi1TwDD3L8tfYkV5wYvWb63DzAehOvVh Ih316ZBdU+a8g0FTsjwT4JbIoqCfC3MFwzXcCU00a8A59DMYM+iVwgVqcfRjTFrqtWmpwdJphhtM MsQrlUXfpQAxwtjcjl508lcDWrfFdsgpATdkEdSEnZaL5t7bzXepkSBCjvB2SBfy+AUF+vGO+bgD d372eWWOaX0/k7MsVz7vALlLlTSpj9Zo0jJoWSgWUzAaHYOLMBT6HW9RgguNvRzQmv60j/m7J/7P /shfN8mqrhNjr0Cko36/T5sWyZ4/9HMgkZ+MfSfK1rWXnDaEt8iNwqKGkkaiFiby8jgx8vYGzVR+ tw3aHEMYa7ozEZEWmRCoYVqo1g+9Ys6Hdtb9anRu5bRp/XC8X6304IOCtthPY5QWEuzwvrhDdQsO wGpoZ3lzs+33/BYuWIdOur8X3Hy10+8oXqgUG3/9qhp3juU7vjIeg7dj6Ns8G/qobbq17MPjd54+ 4MhdIAzifU5s2I+EEW0wszZY8oKeCk9HBXX9N2mF/KSo/LGVIi0VZ86s1/ybtIkzDtHvGsVxgf8t nR8qWvkZuvEnejTpm947GmTG8B6s5ZfN+KNrUXuv++g5+PFIWUuOJ5+LhsJ+75hu8c+blJWkR0PU nmQ0fy7KiuQv9OV5kD2Lal00OQG/Hb2DPG4NdoWreJ9p4uJPk30yql7rfyQomBjho3VKg98JJka4 1UzGPtv6x5mtXEwoGHz3Hs6Uz/GwjVhDKIQmYz69GXTeWTtK7lyEiK3kKcNBRyUpv2wr50KAXDQX SvuQd9NfZZrtQy9Xs77EZct17n1qOft0PG0nAQYBtc4RGU3TBKGfR0e0BxRj/L3poi3EeyskxhvW /wFJxsMZCmVuZHN0cmVhbQplbmRvYmoKNjUgMCBvYmoKNDczMwplbmRvYmoKNjMgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jlc291cmNlcyA2NiAwIFIgL0NvbnRlbnRzIDY0 IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNjYgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAv RjEuMCA4IDAgUgo+PiA+PgplbmRvYmoKNjggMCBvYmoKPDwgL0xlbmd0aCA2OSAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Z1bk93Gccff8SmQJ6+qJBD3i9/WpGVTRYUMycSV kv0gU5QlmZRkUYqTfPr8Z/CbwWkcHOycs1xqU6wiFjhz6en+92V6BoN/5P+W/yMfi3bKq7Yt+iZv p6box7xvxmIc859e53/Kv88fPHxX5a/e5aX/9+6V6pRFNTV9Wc6PlruhLZqqLcd8qNtibKc6e/U2 /93LvK18XS4v3+YPPq2KMq/yl1/nV/lH+cvv8t+/FDW79GS3oafqiq7r29zTk+3R80V+9fij/JM2 v/pelym/+nm+ez3f/aRLF397/VFGkb/kLz9LGMQFTK3Kquj7qcoHBpHC1E/ujqlVKSl3XRPpSWPq IzGuqvMrGPjlzM6vdRGr4bGg4O5ycdVfuLvs8tXcw09qTAI76u8ygWUJWlD1ddHX07Ri0JEWZIda kCqwTQBlu1pZ9Z3Usq9vomfWysxrpbTg21kY4B4JSV7pjMvONB/V0BflMOzSma2sxy34Jlnu820Y i6FvzuUbAP9hht+bmYu63CHfxqno6nKxELNGWsB9SMZNdVGXsrbBYm3RkwdBRsDBuB8j49I5Fh1V luaoxKyiGqp7w7G6bIqxG9Y21UrwmGPVzKpyvkTrmW4v34ed/Uy9j/nVL7MrxGlCS20IXMhNlOwF Lr8e26Kq6zUnd11+cgjijW92YUhU9kXdN/2WLqx1MzUk2nAGNxm1GKL1U19Mg2K1vRBt1s3z+HNh yNiPQ9EPY0JwI9+0CfWXAltV5lffzKAjNqMogQZODVPzboaujT6wP9Z+fzuHJK/mCv8z90DTNPbL /BCDj9ukB0pS/QejKhSBMkuSrQ5JDIU236kxqR9U0y0d0SYVoJqHKOrfzFB+nocZOegDYMtByxdG y8N/qjEX4/kushBAq4tEfd/AsyYO715lp6cctZy0gpsuBz+7cM6r7JwZxylyUmZAgnLRjF3KDOgU niNavBS+n0FDVIsQQS53SAHJWuxQEsl+OTdmgU+IjLifI8tn7lrlV08MUOjD95hdQRTgo4G3rqLC eOlFuvjPDhmnyk1G+jzwe0v+K/Mqflsti5rkHRlssKylwtezflj9pyTcp7HvNPomv+Kh1TmKIATu wvzoqWObdCjcX7t78f8PPP9tMjsv8p5DUY+aa1p2/vreUxNgEXZ/nGc3FdOkqcHNzvOUdlu4AIIT Svd4hp1VbGAHXPkNm4EmPhZmpIGC0oEGypi+z5yPSx3V3dTkPTxJ8OCbAUVbFl1Tlk3eTV1RatbV 1sU0ngRxr/ClG2p1Oxal+0PVx3Is6ykXVCbFgYOz31/fXVKp78piKMuUpNLmgE8m3S6MMPu2Ktpy SFGSs0CJ5ceGEW9Y1wGY15EJEwPvvwhQbHRFcobGQC3eBJUguqIHgiwqWLP6t9mpUS+4HxqlBq1R EW2xntIrVAxeLDFrl+xHZp0JPaCWxI1oJ0SowoE+npGDTck+1X1VDI2SuDto0EzSJJ/EsqQU7GZA tJ98WuYbTV1UVXt/5ht1XYz1beKztQX3k+mnuOm/6qrkMWEAIAQ+Fr3/NZekiEdvdvWpa0ZzGfBu rbutDxkUAf1/vlIDSns+lU64aOKha0/XEM1RjL4BK8E8fUIQ6P7zRx9ll4E2ZeGgLoei7SdZ82Sp JJvUkx7k9KRiAW3VKLMmum5eN0imxyvRpSZeufe6CesYNj10HOUiZHu5dkhQPMnTzYgjC79iJ4Mt xXiDEwASfuTWmjo70aC5TcR+7uhSsPLvIPUFdL50V2kCiwIWqlBCg2H6ydA2jbV3UVlIbjP7BfHW OTCQ9QTZR1RxguyXf1CRQw2OE3LotV5hxTKvz9kV9SlKo4yFZqBJTilRFy8Af1NPRdtqRpWOtfOw bxNEyQmrbmqLqd1OoB2nRi3ouQuY+iMYC8Y6YI5IR/GyjGVUAiQB+JES4ALRNsNCbwGO38xxCRUx 3hFB3k0gcyqqyN2JtxpkautRUfZpdh6bEksudIJGtI9IyWrBW+d/5iSAc4ewEh7QDA93bY2fcUeJ UBTVtGTASkvGmulebel+lnZc9Q2Y4FcrYB4eNuf1NlFcm/HT/iJUU3duJX2K8rp0erU127jAOkTX 2I1doRkQ8dxuhuDUbAOjBnBiHOSFgxjhNFIAKciWeisxBvnNYs2urvEjIX9i5UqLPLRIsih9JSQr zwrYgwW3HhEyrbG2zcxGITqgQyRFn2wfWiRbjwdRdMhvDAbSIJjfoBDrZfNYpKWtLVqMmDdUELNJ oSpGPch2t3JcpAelIkQl+gLu7o0eaNG66TanNcdmFNHYyyYz14j0SgHiLSKAMBYacRPRIHWrKd8J yTemJg9nttBygk4/7aEjKAOPNh1glWtzKMyWbT1GRHU6sshNoMxaECowMHqw3cJWGPnj7MOtTlkb xdg1sKgF7z331JTamdW1eZcMug8TmvVDUfbdbdKh8NLCFzEhOxDw/ynN4zzGx3JAioDAmvUNVjEj jL2yWy1/Ssj6qbv66ZBv1cJ6bTSkxNlqb9Ua1l7Pk2DtiSqS0X1k44up7MaxbpWo1RSjraoxi3/t x0D1pKXhchzybgdnJ43tNQEAvOYC4yzCoqnxY7VeddPwUAS+P0dGz+jxia4SAL/S43bkgLDDj9yC eIhMm0tvGJ/EzPqxgBZROQE5MXSNMnidNpQNVV4pNJXW92Teq7Jz8eTXS74npOhd+abWnOMwRV9O UzXWDiXnpuhvojMhr9N1QzH1fUoM8SIxN3oUS9+CzKnop9YxOplMhdjnTWo3wQ3+Q8wHcPGL/Iih Jh0TTZa3I9Zk0UWS3nmFA+50S3/qfQPSW7MZLE4WNyxfLgFtby4qLe+dJQDo3mPJIzcdVhr2KZbi EddrLEaYpDzW/bxw54vTMgzFhCMBbDe/2ZDkiJMHjmhNppcAFaw/wPJhv+zUYdsfvCeDM881JYS+ 6CvNNOtWf7TKfno7MrQTBucu5hpTVWqukax/m2FWIhu8wZR9jeZS49Uy6KGxVAp60Or3BcYyNJ5i FNtRO7DCovbujH5zuCd18sJkd9dM2kIT1lffc7I72pT3PlOdpmJUYkQZG+hP8DIy3z5YiGHiqWDB T7bSggVvkdFymsOkejsb4xI5OL8gkOQ/IoHYG28bsitMBO2v/MfpPHzcZE4mjz2kGDGIxitQJMHI Yh+XdzMOrN7iVA4eMhbo5AKTMYVsjKMki3uMWiUjmvZnfEce6mbtbJpeO5WbLqJpa8vJKvY9Tzsv Tcc3ZaGYfHO3QWI6HmHEiML7PBjOQ6TAvivu+M0WIcwAH09xrBvLsNkVEra6EdOPXm9oJsy2yAIA xVjfa+OGbsVEN80sq7FuYSGPq7taVPWrtLhyOyDCLjtm7iwhPIwc8GQx8oRECQOgd8PA7GqDgflN DEzUhqOIOUEbamUB20mRsUHfPfBVImyYtnc3rLTzVDb8IZBFK5Amso0RmQ/TrGUExzEs9Gq0hlxo /RnWnm08CwJ9rROhvv8N2wc+QKAn9sQGUOhiPNTb3xfpkWs7CiFy0Ohwf81AQsj8se4P0yyHM4qo Gb5IcE9kTOkOaiGTh17TYwplU9OpAPf3s7B3uIOice9sdspD60Ugj8SEqCPZT1ygqcs6UVUVnbbz beyUTFQMTBCaAL8RF3L6+7w4Y60jJZEa0ObhIXwP3ubE9nsYgltbj/42W7Ea+xvhUVl29IwKeA5a gQjqQSd3FGGYceyeMurxkHrERwAQnmkMd2eMa80XymHUhs1zRIybsdaK0TJ264qpQATGaGOMd+it kZhlD5xfS9MzEu7CM/EzkVnEceHV6JRteU09FOM0VnvM+jW25Uk19a5e2OFkJ1mJYRygttxHbSw4 bXwPfhE6cgIJhNbb8wpfJoYmSxTudhjQzFPnHRRpJYUvHgsWdDTzqWvmjG14cdso+LROCQ7ZQAsO WTOz9x5Okq54Rxd1xa9cL+y+DOU+Oiv3d3vW01h0ValMfTqskr3QSutmevZXDqIX0lkExVT1bYJX PBWfrXLziAhhwmpUAek/mEOSTf2gCBbIvqROY9gxioDIKFO/t5qHlARfUMZvduqCsoEFa4vpiFa4 fDUvfDIUqI6Lot76xtjU30Vz7SG4gM4pZ6HGlhgNAl+iYyEso2N+Be3wEBI9E7KwF4PRQxv1qEB1 ivDbElCgCcoBvf8cYq01EuXszkBesibcJh5rR53xoT2kCVtaT2kCUoC3f5f8tMxJusVy2iIZ9lMd r7sJaLuvBcmCpfQXoC5It1StdjW5V9ctm6xfXMWtyWLbMGDJux9bZ8q0/L8VR6/89G3okVHdPRNh Maha0yub27yua/WcFEgwBktIduDUrZmzpgxs+elltAwWftZAWBSCLVp55EySX6aZl2vC/bV7fvAu HsVRBNs+DynyZrZ8dMNv1ucnjC525B06TdMtVpgeMH8wwAZjFIF/MH5h1V1GB23RDoOUawbPvcFy 1xVTM94GzMgiXryfewFcFplcwNvEEy3mU4IE2pbBbDF3Zbhk39ECpI9KWhs+aBTed3uH3s2TpOzm 85o2rN1N1qWqR3d4QxUHkRCuJVu7WznNeeUxgafJ5GywJ90ZNIP2HIaVOuucVs7glA9fW18v3FPW 16M5wT5hUmgb2FuzyGvsFAF+qM1+btBTuLbah6vWwUo/xXqH++vFaifq3wVQqSsnkmrIWyObXz8z rb3+2qWTtIr6YbBbuVOVbrVuFAQKbPaB6bG7eLeDcAJvaq3dk9nacflXoOR7yq7CFJCadm3F5iEo wmzI9sFsDx1gMmUtMRXsoqcdBU7d7tpeUWgbpUNLDM14QmPgFJqBw+g1/VODC1rOQLlDy616UyRt 2Aea+p5fWG/qvhiGSjMzkHhvnEypF6+GsIa0azlOWXWCQMtp8gHw3WYjAK210RZnVKAkKTyLiE20 Pkd3wooTKlXoccgBxD0Ij+eHFi+QsUcb+LTpss16Nh9Am6DVopyJLEVoDI6i1SQQrMZHWvz44DbR tWU67GK0Vli0SWMkJSFCG0AP1OKM98ZTUmVNVbqZ75i3wPD+qIUOGNVO0csXkJAamA22DaYiDF49 QOpWNNTnIfU288VR//yZk8Br31D64Bp8WDzOCbEsnGdFvxRlggxOLIasR4mNek/IAKlubTHYg080 vSTLDlwn+zFgDKygMWihWxpbtD4RwZeEYHojbXL7kdvyfMRcO2ulqb3gcIcUKj1eus086RR+kJis mUod+HurRSDQGZQLRbAWMvxoU4Wo1aaSASl0FES+QFR/dFe9pvvUX5c3x5/oXhPWRzymFu1DERfa D5pGURTW4pnf0B/GB8jRSXhgD4niIUOwAR002eHxMFqr+QVa2wx3Z1qru35VteyKWkcc5gFO98WD NKO2IEzh1IT3EFgh9s1dafyGTDcN+wl8efuMNmzmP/esvMWHfUcqeiW/2QxY0xF30Mkd2hHVwVNm ew+6TJmweAPdULPhq+JmmrNHCGNjh3NqFm1BE/gR+qlBEehHMPzmtSzTwlSq1d9I29yU1fKvcPdK DQQc3hu9GOqiKZOWgs5zQxdu+G76pijdRv/LQ73HMvqaXSBkMI6sIwB80ghUWKgHn8GP1jUBruB+ /I9ZOM+cmAvEU5GHdAwZQFXLWHEeFLcJoX9BuahBx89xaM/cVaHKE12XHQ+o3Fw1C+eBWk1YtWu5 ZMdMc5tHlUJPaI2Km9mQFVXcwh7a4W7TIMAs6v2vRjwvNSbGaJdoa9PoRXPlpwIa7422do1bUb6F coAu3M8J7h9mVEEzAgYuBCaIhDsLnohb7ziox0Pqndqu5hCNvkAgEN6coFGENumIh4yWxqBTRDjo 3M3yRa19cOU45UrNO0klAEd5HDtYdAHaGclf5z0YPMSoWGlQck+VgmVADkF7LZusEtMVSoiMkRxB /MdSyZDOia9ziLbzFHR5Z8+nKnaXoN1OOn8GFmxOUIjzvNeFL0Q07hsqlb6bsuG9EhdlkqMotwXf rwEjEyQU9c7LhIcIOMjblvE/nojJQGYgCiXb7CrmqbzCQ9RelizJshz6aZBtqT/HsvjGGBJjQGkC ZyDbqgBdwERPRcxaLqmR89Ae9o3mpd85egPa9ZqNTlY4A123QftNsWzc/9E07p3ulDeoT+WqgQCc ZcUAyVjngtARHncYdGSI7KJRPPRits0gbZuhsEKnbd9hXBOhApdNKvCsELpSPFLBeyY6SSt80GfP ArhcK3xjrEfByuhvD40IVBfJhv2C/J3LQFcuCwW2tgzpagfDbaCevNruFozKJmm1/Tb0pKtepQWs trzNXtZrphCI/LmcidvvlDCziAcbnppZeM1DD0ENyskduh31/nAS87mjS+HETF929Z+WTnTP6lf0 PR6vS5x3MDdCW6CKQdugkXo8tIoI4VBstWVzGFRImtEc7s2GMtrcj9NTI6yLFNFvL1EgC9JmTdxN nJ2H/EsTBO6Y2HZ778DKMtzgddb+woMwep07CTwujRFujoirVgeG6DzHvIE/aTOPJHt/hyuO2o5f 6BuCmmmnk50MswtgH2Mb9xZD1SUtxCfT4zMRF8K+HvVun77ftjGxOEY9H1nqZTmXXXuDuUPwXJ7M vzG/xpoSUWAxuSOQstHzI2ei5Tso401fPMsWO5pg+TcVkpApeAVra9HWtXH2OW5r2zVjvcNJv963 7Mp+yJFSgu4lg+ZWIB70UTh3pLZHza9vu+uhLOohLMLYPYvHKLYQ5e53DmpKfNpgfXMeASqIFAAX wOU3Gl1Nb/nRu+440aMiELcqYrsgKqJtAGu3p9AK9ShpQxryLtCyBvPh3GYzIqIevVv+QCAj+nje lg4Rz1Hl7TCQCIlWrUnwDcSX3+KwD1NDNjAjtrFDU5s4yTt5IUfndFb6KEgA4r1R1L7Ud06SVmFO BTXWeEb18MmY30ioeg85vqXj3QLSE3oSo5ILLFGlz9U2erU0r9MHePVJ4mlrF7hTHTiocEMfirH0 3GSJ4C16A2CtCYDFaFFIMJAgRf2YC1hJ0RrKGCpyS3NemWMSgodWmdB3hGp9LhWiffHGY9++HE7I oJf+2KDNQ1KQdEuoQO8Rg94EoO3UY9RwFFqYVdGYXRxjfLBwYdrdYbep9d2HXh81sli5B16008eg p6Ql0uQoY2ORLDk3UusjTZ1erN2KTVdJ79vQk5wbqbV6p/A9Ze0lmZ4LbN8yldCH0N0UJyl0/5Pz v/3hKooL4a12o8gfq+iy7IKpoSQqj7ahZoWpQJETF+83Tvzmu/29I1SB2H/rKgoJQlBMKPSanIUT /2ntkau4TBYwFih9sH9LWt01TnNMBZq5x3K+WC7U5rflY7OulfVobhyiKtydedH30vTCmb5CX58D j/UYDhHAb1+IBYJFCOCAALuBYDNFLX+4+8tdjtrnd90+mPRRb+ro9rGKwYp9ketkWsmuzL6a11ke vtBRikdnD+sZpxDnLx4efdDzE2Wip6ZXdmL+Vp5OOdG5Bi5irGv3zbmh0uf/9FEG3Vc6c6d3J6GU +gD3m/yFf5N8qe6+F7/TWtVNvnbnar/NB/3vGvO3c2NJp5m6Uxncq8utsgS9wi29ZVmruaNHb/RI 7xG7j9b1/mxL/eGeudNOtXIZqmbu2aq1N/k3Oqn3CzE2/yqRX7J62aDcjh9NrwUjfcfC8ez42Rs3 8kIfcV3G3usrgHoQar3ZaMmR5PjtBF6595Y7fQhd3/9zQ9OE/O3q/o2+oaFOtGycUUKfLeTroXpp Ul/Z0OlJyxO9Jl+2+rjfxrOjUtnRE1NPWt64Ty07CkKP+tCVDlDWUe7QpE9fCZJa6svCKLhXS22n Q1pqGc5QRi3pGDR9v9mBL5TTicFKW7lvodJ2dvAECtTWUopnCU+yw3ra3eA542gIPQb+LVTNMlgo n+9fZesnN92/8rir838mgs4pqQBeCgVaOZ3Vyt6/0e/uxCKJO5ZpSr116r5g2ZaV8t7+TgkLp+Qa u7nfvaOsPiwXDIKvOyosUX9Z7Hh0H7ecRIEnLd7pkG33tbF4/0b3o9RZ52fFZ7JAVR4anG9qb460 88CZJ/0Y7vfuKNuHUbquVDfyIHYceeRJi3eQGu/Nr5m5E12zou7bYSnwAqhWB3Q7WxGeSGVvA7sD FfJAvBGGa2OyGA+xyJuXoMqiLMl4zCM6VJrwZD4AvVVoPzYyzNLnUQeHVHqRdGy17KgTQOuyqaZ1 HBrNnjvbt5z6UWh37kb/ltvYqrRBaUp2p2RD5wtyefk2f/Cp9i7JirrvY3/2LP+PL9+9e/2LYq/w Xchz+iCzsvTRyH22U1+pT9+VTB9d/csd9bAMJh8eVP0DHeJU1b+tm/zZ50uP7syX1lkJN4HppTRt LwZV+nBmV+uJjrev+mEa1nyfeby7awOuS510BnAfv4yRNYNnOxfPC215nXmh5I4PjxVXu0hN+xwJ 3blz0b2+6Mgd5/K4ibKyO0fR6vawhko7ScKwQsD04Nnrn169/vHnX758k/30rVii4bcKBtwwK3FA nGhHId4542UwDx6/rfJHP/hoZ6NC184fIW30eW6WqpcaiXyPBD58V+Wv3nmCbjh/auG7JvBlJV84 T7w2+C6EZDPcxbyA8kspu3kfTyvzNXbehe9Stvdd1m2hGqwe8izx5Ah3YMTY6wU7nQp0kmerDP06 Lr8rymQBx06flj6DMiWfbyHNVJ7pI7uTfNxZlN0OZ8mUNfpK4n2kSy/ndS7AOEOWsocfQJaazO2D X07LqOXTD0NWL/c/3EN+jYptz0P+9Qdh2Kgvwjf6vtA5CPvDB6FMhw92Oh36LMoefxjKWvdmnFz7 hVr5f6Z8DQ0KZW5kc3RyZWFtCmVuZG9iago2OSAwIG9iago2NTk1CmVuZG9iago2NyAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUxIDAgUiAvUmVzb3VyY2VzIDcwIDAgUiAvQ29udGVudHMg NjggMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago3MCAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSCj4+IC9Gb250IDw8IC9GMS4wIDggMCBSIC9GMy4wIDE3IDAgUiAvRjIuMSAx NiAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMSAzNSAwIFIKPj4gPj4KZW5kb2JqCjcyIDAgb2JqCjw8 IC9MZW5ndGggNzMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2dW7fcRrHH 3/Up9DheyxG6X3gDEjjhOCbYZmWxgAcwCXAOCSQOt29PdevXPfpra2Z6NB7vvfwgS9NdXV31r1t3 S/vb/Jf5t/lYtFNetW3RN3k7NUU/5n0zFuOYf/dl/kX+Tf6Dn7yr8rfv8tL/e/fW+pRFNTV9Wc6P jndDWzRVW475ULfF2E519vbr/Mdv8rbyfbm8+Tr/wU+rosyr/M1X+SF/lr/5v/yTN8bNWX6yW/ip uqLr+jb3/GTn+PlNfvj0Wf5Rmx++scuUH76f776c776zSxd/+/JZRpPf5W9+njCJHUKtyqro+6nK ByaRItSP7ifUqjQtd10T+UkT6scmuKrODwjw97M4v7KLiRoZGxTcXW5S9Rfu9l3+OI/wnREzhT0Y b5/CsgQrqPq66OtpWgnogRVkSytIVdgmgLKzVln1nZllX1/iZ7bKzFulWcFfZmWAezRk+koXXHal +6iGviiH4Syf2cp73CA30+V5uQ1jMfTNtXID4H+b4ffXWYp2uaPcxqno6vLoIWaLVMB9SMFNdVGX 5m2Dx9riJw+KjIBDcH+PgkuXWAxUWVqgMmEV1VA9GYnVZVOM3bD2qarBhxKrZlGV8yV6z3R/+T78 7M9t9DE//GMOhQRNeKmFwSO7iZrdEfLrsS2qul5L8mzIT05BvPPNdqZEZV/UfdNv2cLaNlNToo1g cMmpxRStn/piGixXO5eizbZ5nXx2poz9OBT9MCYkNxabNqFOwHo345EkgocKy6+tSWUZBj6aHpqE vJ3J+LwhO9CEYMjdc2tyzFP+YHeWLtJk2d0Zh//tndmImQpNmATEaEK/P88daELywt3MfRbIaA+a Ml8VSZi20HGpkU9i/yND6mzogYQQGxd+Y1L/nonhxHkIN8wUpv4p8oLKUV3ORWSXq4INE7Ba42xc b5q6qLo6T0dcsgHscFhHg7R0oxmNr6QaBXnpBf0gdeLp16YRB3akTw+UR/7NQ5SuGCKP/pepq6qz kBbylBE34YrWackQ8PbPGSaKD5oEmMIi06ApbcBJMAXgpj3gTWfDQ9IyxTzVHHyrFP80o1U7/PZg T4/FxVKKWag4GJCLEjVq94uETWWF+Wh1mnnVVGAlA/2WSGjFbFGPKYHwlKdHz+pkwAnq/t4AZqBH 3opB7vgNPwSi8Kb8hkbfGjHz2wyLpwZCShrsWMv7KdYSV6fY/Co5gj8mhJCwfi5qPXFeXo50pwlU 8CjIatPc1yrytTiihhgDqfwZ4X+d06miGhnJE81CEsBcUAdkNLj89tlsp4VdjgGbMV47/2hjMEUI QM4uiYrcYRFNNRRjZSlYuiavM1BNxdJTw24qpskK38up4SkLfeUUZ6s9n6PAF3a15AiRq0v/do4F mBXy1yYau0KAAA7LBCi6XdAINfqHjkpuE9t/nJliCJrogDxkTtwRCaMXAnDeiHhIBziEJowSZqBC PFbD1MRWpwJNNVOgzEOaMBAhz6R9DcwVVxfzrdKWk5uyzXtwlZDjJ+P8poyrK4uhNMb2Z1wKUxRM uFAooEuUgdZ/KA5JIRSh62MPoAHrDIQu+W0zZd90wJsOPxgHrEX/7xEM7WX6kx2rGr8AAL+KL1hb 0V5abKw/6Bin7YmGjgpz7jZKpnVU0H4v8Uq/4vpxMux3wKypx6JrzbkLynRJ51EK/7Yq2nLYzL8e LjGhQL2EvDfI87wP89Xl2od5VAU9oPoTxuSB4I0penfgCFawKe6woiVU84Np2scjONXsEDjSETLq LkMGgRyWs4mQg7amHkyNfsCR7gHcdMSxnzVOHZ+mPJRkKS4PmAO40bVnpzf8GnPtzdCYa08BVV5l bsPvo8S9qT2lfWX7it00RH4SQo2lMLhTxdFRj8gvu7BBuYff2ha9uma6ht8PExrdGkll3msOjWVh YdL2e92W75u36sOizwj7uXn+vVmr7en6tpeXcHb4VlsrHMyvmtyUzwsbu+gZQ8dseKjOB1vEUAk0 9MOI8RPEyWjD3rHRL9rnsoYiLaC7BiiI0R2/xOizt4h2jWOBp2KXlSfvlpRFY1sUK2krDB4llNV1 MdYpdUqy0eww4uMKXtXYPlzSqQdzOuyG9BaZrDIyBbrSdJQ7UAhQf+piWBm9FbDAaSmmP52pLcNN dqClGsGDaJcYLHYYbdXajkM3WLBATgl593V627k109uJhroJp0MeH9bd1BZTu71VFL1t3DYFHXoB AIqKTZfzyi1/WKX+iUOXLYP8xF3t/hdcP3NXQ2a4hnYv+T1kVvPzLGZa8AMHeDQefmt9DfMgWB0w d9/M9Tfd4Ryfp75WH9JyXUdv5KDqeRlIazYVHx3IHZVrbQmDs8eOJylow8UzmoVDRsZvouGdclDn sjTLiqZmrPIkYJGlmaqSjmWd4iflmFg3dpb+lLds+gUZo46/GmwMrGdzaLRDrAWSgQ4/el3HbT+I xzUTNvN8YUJ/migOADhYpglRnQvjUabTnZabSwbEBNIVHXbJvA8piZja4czrZiqGwXYXgg6fijPv 7BBR021uaz9GitL1Q1H2YVdPY8tDX76ZE0yztyRDAG9cPrXfDO8BvX+fvaYiTTGJJ8ZrQiY4e5pS bAMnoEbTsKLLU8jRkTuwzR02aSaVCMcdLqWayqJtuyEP8k4o/JJzix3mEXPCrhuKqd9cbHkUOLaj nbK449K+BlAOPACdY0Xtoj8A0nUaLcEDrImVgAxYqv8m7oce+NMThuBjBOhUQ1A4M5lNO2AEjpdq P+7WZuBNlSxi05q/eJbdz0RqO5ZaDVOd26Kkx0CCiViZsikDJIJewwkDpo1itc3Ss8QSZkP2MSOy 7jfK4lxGZMsG3biQxRy9TrjnD5kRWVhtxrJN0w3y14s6Zo7lIX6sBLmTz9A9AtofaTgB6OU+OLZK d0gDbx4qFDTt/8ucqmkTNWqYUJhg0zrC3+bAR8KljoIR6ACDtMREATlNOBClU9FhX8wx+cd2cUXT K3e1oun5HI6ho25r+dCfxtkB79QFGzsQXI6dJfzAaQvejxJ+GltJHG/ae8Ct/HtWAKDlIdqM6vdV n0JqszJANeqj1H/pfjCRDMwzrHaAGBBmhAg+zxnMc1HvSXf6AWGaKMqxo02b3jQutVQGoiXEqDzW Ay3XNtUoESsd+I19UEZgWLVpE0iiGexIwpqqLtq678wMlrB7/LPAdli/GKawuq5RZ2WWpw5YoCEw h4jnM3qL4zIeZqopmmpYvxFmSaHDV8to/1gSuHNVan404SFul1jDhSbhSCJNz5m2GoKmhYgCr49g QSsDcofsNGU9oYl5VQ39cLmgiXtawmBF8TDmirwnYAm2NNWVmyv4iYawgr6iJ/pNbwib7gydaC5E zIBYKCo8bOIJWDri0guJ/CDytUsLLD1g4HWyccdkvxpLS3BtdWaWb1o6qUaCDNbRwtdOMVr4iHB1 tJjlkh3+x8lnsdb8K+5f2NUqxI+5RZpqaDz0esvC0czNChNFYYOaDkAzWvTGRp31SzTM1bpFyruC TdPYUr8ZAIraStRsmUheFbSZ71+ZPf+q4HHZonSvcFmBtP8IIKDHPpA+WsOw8NgsaW52AGn0w4Lo jmKhAlD/JJUA3XH4aBunrixpFhb9vgcEw4ISM/X7AaJy7861tn5pXvGcBj44Iuxt7mKqtjfJVguZ yQtrK4PxL4lfeHkjIrQd7V1127VLc23gRy9fOP/SL/ZnvLK1FlSfSJQATvyGRwHoDMEukYajc7kX 8A2xBjgScgAg/RmCHlhBHNe7ZLANh4GoLsetjdB3ZAi1GyxMDY3snnHVJJWZzVxTvTLiCgks1ODi /01PliY+t4utdUP7FcHhc3e1GGsxA6u8xzkdqySacajyK1CXbAU7KpujFbj/2Sms2U+fzedOVRIx /dVdLW8LGnIBlQIO9PMbRhB9safJ/hdNNACDN7WT6H29wgN6PdEsnNNPgNhmtIgA968iMC4DKs0k G2APcCNvwEkgLTC8dhJ+gjr5sJqKuJiEagmiiBmiQU52G+OT2cL7/cRHU01F1Yx13oK8BP/7YSzB vnJQNin7fqcMATGeSNa9pjZXBt84D2TncsALSkFv6B2AoVOPs4hkOgT10QZqCphw8PY1Ti9ixK/L Am3ogSq11sE6zqeNIkTe+1dXqmmy8/6WwrTXqKSZOQsHbQu7PTp7DDNIGmPwmoqb9Gq8mzFnJell jM0PuloFNYQYE1XP1EbocUJddvHbGIki3pEFNaW9QtcGAT8ZE+w6d87klmCEvEFyVKIv37EIxIzy eKj9uFP/jwlqDoR5MRD98AB00HilEZHKBTNkTRrm4YzfVtYN7Vh3Gq7iAb0VSrmFKuRgyqwkEWQ7 kgxLru2jUH3eilrPrlYme/oNzCe/ntbaOcK+3dxSf5RCpHFra03Kt64s8mye8OBhGZyzzybAOZeQ 5qJ/wIVfArc8DFCjdiAAYAz0h+pnNqI73Ke5CncUOxHA82vk3ELVUJkIwKXGE7exKvtExdDYh5Ra RLy1GrFaJvwwCLRXe0o7NbrFz6NAsHJfKhpuqYUf4Munx5fxFT+FtomvGYrxtR1AcwJfMxQf4GuR BrA7pTkR1PCooYLkKQ52o0c8aIAprLwu4UUtCx8M7WgCS3PlNwaECnNCRFBhXEaIGYYnBhWaQOWq UOes8l6fz6iKurMwkIy5ZJvcEaSOlbClRFaT3JJ8qF5j3PcaeeU8pS1VBzt5MftqBY/CDHygYK/1 +K6YDgUVYEIaoQYFBsAOhgBpBiqMpQcp82vHty2PQHtjgTxaJxYEMyGK0JGBwSDGAotx2l5Sa0B7 pugQTcY/hDQ0uYMYC0IwQ36G1HQSNNHEDGI23h0Noa7sI5f2ylEL9J5MHl66L3+EtfvFu1tZwrtb 935zy17Qawb7GKG9TrZgUl7cWoV0y5oAxaY7BVo4UO7QP6c2FCLLpDt+9iGWGr4+psOns0XNNh9t N7gAhe9VodKX6/RnrJCKqU0zHayP35ZGGMOYbmCGhQKZwdF7hcFCte15yA5hQVzHYQkDVjBhHe5n zsuYd4QzPY2F1s69645h2zQTs8kdkaKxJLLs3LJEMvKSA9cyueVbucnlTGNHl0d3FnH/Vpv6vnOK ovpF3rQk0j2X+AHk1C7UdP5lW21O65AhfmgYUdbAurpzD5rsABd015HgFyRxoSWjE4v0FAdN1NLU mGDphU3e1nC4vPR4jhYPbTVNfJLKUH0Cv7H+rSbzQL53RH5pZ9Bbe/9HoXZ2t+A66O988c7eSSq6 aXtP8WEQQFN6UdXE5GGZCeGNYobtfwvpjeoUhSlCEtztA2U6LMGMgi+Me/xytMvZlkO4lUi/q0B/ 5huxtAxQjHv8iov7GlkYQvszUZUC48Ki7xDPUrAKRhN4WrbUFc9YCMIvCZz6D37D1CF27jClsXTP BM7WF9o2DzB8KvlbM9huYxne/zxrpqf2MnCYBGstZVTp60PZ3jq0Sezuf8Oj42h1hFB9q1NU6ygk zHhEZIfXzuFamUJT+uO+uTyXjq9cj62CzBchEAimoBHDcHc/Z1vXBqp+avLrtBg4xSYQK+I4pkfO WWwWf1jWZ04q1uZHyPPXXPkZl4Bpe6lkB4SjSR8jaz+aLHgVOWbv828JuJNRZWsv9wc5Phnr7I0x 99W2/V+N2vTFmw4ThYEKtYATNu6NlJinlgcVjBvVon2I8Rt3s6LjJyegpmTgEGqbM4uhy2/jbFKB JsQUfMoaLdl5wTUwgnan5ab34je6I63gvaxSEVxf9TcyLuX9tftYu+1eNAIj3VV5jDVk28Iohirl Vezk1HBHkRaX8xr3F0mq97GXCDK5vKRmwQUGV6ZlilrIJqZ9k2gZakSgESpqICeM1gctYL+KXRHw 3rBpA09MipF8y+jPGUmZoQMPiTI8hFHGYzucgTTM65TCWgMD6uoccuI3SiCGMHe2w84SN49qt3lk nxzJFUlqaKsiIxnZN9X7jf05jjpl+/JUcoe+9ILYETSIIFXgIUrUVN4tASVqYYc9V/amy9TaIcvm 9KwfRQmWpZX2IfCERZdbQHHp05hHd1e5UuSm9z7VJRAfX5Il3+buLhxVUnegYNPoy3qslpZ0UO+n fgeoQyx2X35NGHDrIkuI6FShuD0MgIeedtwE0ZFwVBcq1MU7TOo1YZQsQ0UBv8zTJn8/I2zsD0dV VT3k9leAPMoSUtfrUL93/ccWptp2+3XQlVe4yheu1+I9TgIW1EOqUuy3+6mhsv2iZuxNDTLtxPpe UwwgzNI8MNU9M01p6MDkAaZGfKAPIr+yROm4m0g/mgBoHiovayo+a8EbLfOUeOhErRGaMM9AzA/S epwYm8busWm6MxWGpfs691muF+CDTC6JMFglAkmv/LhXsuzPI61goImJVQAf/A2Pehrt72KEHfQH /Kz+PBjSTLggfpQB9MCqKkOdN8o4hYiFhuxLD+9z6aHyfyDElnCCRJ7K0kM92pe0be90Y6do5S6v c9/6Pe9LFWxMWurBStn+pp0rQKEoCotY/EikJJcFFWra52BEy/XCt48JOBb8IC1jeuE/hIF70pbw y28sH8AnxKASCkzcN9zDr07QE80O+C7dAHtFHvc563kv7Ho8cgy5o/dyGQmbArhQnb7Ki9nQnZli tWEJiFnR9CjThRWmvmmQWMC5M87296mG/BzMHgf2ZVEP27tWq5Wbq7IWFI+/A01kzCF5QXFkLWhs mcjGsBr7H4GShX0mVHz10n8AM9AKt6ABxBhwrwHFdamj+0N5bTd1BorTSngUUPRW6I5hz+Zs8LzF NycXlHVnfzV2Svq0YjI/O+r/Y6xo7YtL9v7oUyk9attesPCe8r5QsnxWyaB7nTU9ltpfTC4tKdwI 7Sufcgs76fCpWls9Sz3U/oWLSscXaXE963jiI+5za3osK3BEtCS44AAJXIV0oAn1RLxb0jz38BPH qG0zLr8eFD/ogP+CJw14H7uOttvIj5oUBD/4h/nVc9pADnYaI2ABu5wvKoVafosvA/jdknOzuea3 ZTFHv9/YsKaKkFIgdl2ipWnkySaRHYzfazy8ZpeXIOiK46kuzcOnQ/Dwu8RPIuzwYP7PqPWVpSHw c60H+y+wNcsOCmVuZHN0cmVhbQplbmRvYmoKNzMgMCBvYmoKNTMyMAplbmRvYmoKNzEgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jlc291cmNlcyA3NCAwIFIgL0NvbnRlbnRz IDcyIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNzQgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8 PCAvRjEuMCA4IDAgUgo+PiA+PgplbmRvYmoKNzYgMCBvYmoKPDwgL0xlbmd0aCA3NyAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVpNjxw1EL33r/BxViIVV7n8dQWCRIRQQCPl EOUAywaB2EB2E8TPp7pd07OebWa9M2zamoPlcbv7dbmq3muXP5gfzAeTgLNBZgjOcHYQkgkuQUrm 5sq8Nu/N869u0VzeGjv9bi9ljgXMLlhb/tr3IoNDtslEYkicabi8Nl9uDeM0V5vttXn+DYI1aLbv zMZcmO3v5sVW0BzFM5yDBz14H9hMeIZjeN6YzbcX5hmbzXtpstl8LL2r0ruRxs9jVxeDXvLWbF82 vMQJRkWLEEJGE/UlWoz67OmMilZW2Xs342kz6tdiOCSzUQP+VMz5ThoxtdpYXGHsGbHq1GjvtOaX 8oQbuZks2L3nnbZgQ0MUYCAIlPOBge5FwXA3CloXbNGBhqNRicFLWAZ6CE+JymGKSomC38piqN/r Csl6tRtueGT6wBjAxngU53CQPc6wm6zlcbvFBDG4x9pNHfzP4n5/FCtK84R2Sxk82X2GKBFZO9zn NFwmICvZdpexlvCY3ULODqeG+2s2XLvFZqIa2ohKjAUYsRuLkXWQfDzMqfUK3rcYFlPZ0szZsz1f /h959qU8PZnNp0KFSpqKhSqAe7iNK3sC5VNiQKJDSx6l/GYJMiXf4URJZANQcGEpFg5js1USLZDB Q0ltlmghB8hRtNoxiVZi83H2OVEyhhQhxNQgboSbFl1dM+48Njn39+KBo+z4VDzxeuyKtvi5dGtR pzP1PipNpj+HzY96n1dji2bzXbmBTrmUnsSAzqyF4yEf3I25HRzFcVtuo41Kll/Lk+pLFJVeqWP1 cxWa3kXHVBTpmEJTFasvoTdT+v+7erpMf8LQFfrPSYSuusKSZ64SKaIDXPK0hOcgJ3+eSAkZKIWG SGmGc0Ki3ScSnyFnkUkPf1s14zkn0QZvIVqr33o1ha7iPozANi4m/lXcxxEgckumbV6vs/yHCBIt Rtcqy4VOxHRexLPKcsnnNrnAvYS7zwyZdzpmfV3lkwcJ+UUds4b/eGEx5xfhrOE+PkSwwXezE+d9 hBwWk+Eqq8VJVOeOvGqyWGW5XBatYfuJdmfBph15dRDtJOSeeTG8VvEfRPC2G7IQKLLz0s++u5QA IGPTvnuz1jhHG3KSAoew6ZKUX8N9eFTRbpm81kg/LFvF1nUjDdl7yE5KUZ18WjAHCNyP97goUqMf 8mJKojX6IS/GcQO/H/Jim0EivhvyYiul29QNeblspezcD3m5JNye+yEvFwmc7Ye8XHBgsR/yklQI EbshLzeeqcB+yMs5KQNTN+QlUERq9ENeUiGHyP2Ql7MRmPshL8oJ0PdDXpTkkJIcauikfEVRavCh H/KiaIFiP+RFwUpxpx/yIi+nqnI/5EVMIjawm6oOOQcS8t18epGcKLS2G/YiZNEaTewl5erXUkTF MB+pquu0Wm/VWuwXcun+7JuOfawOxGlFV08WQTVBC7vHm7sV6PrKFyNQqW7/I60cfdSjOFoKnqvF 09hUeh7GXZsR7+50nwKuS8m7Kvexorsrx0f0KEttBSpodGx/imSEWOOfe//9ivMld+28+Oeb8mqv BNlok8VyvE6sMbmC9+1TFssdyrdbwGhqT2zfof0XGtkEtgplbmRzdHJlYW0KZW5kb2JqCjc3IDAg b2JqCjEyMDMKZW5kb2JqCjc1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9S ZXNvdXJjZXMgNzggMCBSIC9Db250ZW50cyA3NiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0g Pj4KZW5kb2JqCjc4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjgwIDAg b2JqCjw8IC9MZW5ndGggODEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac2W TU/cQAyG7/MrfMweMGPP95UvCW6VIvVQ9VAtiwQCWnbp/6/JDNkmuwpD+BDKwZrdJPPmsV97HuAb PEBEm4CsRW/AJoM+gjcRY4T1Cr7DPRwebwiWG9DdtVnKMxopGa91/mm7ChYNWR0hsMVoE6vlHRy1 YKl7toT2Dg7PCDUQtFfQwALaGzhtRc2kHvUWPeTQOW+h06Om9PyA5nwBBxaaewkJmse8WuXVWoLr /1stVLnlJ7QXFR8xAyppQu8TQSgfUQP14OOgkpYsO2d6PXVQTwQcMTQF4K+M80qCoC6MpRSeViBU u1BW88Jl3mEtL5OE7ew3L2GqwgXkGT2nNAK04wL1vwtqE7a3gNSkK8k7saXnl/RkV6rOleKC65yM UvclQ5KvenDqle2DgkcdwqRONeoeb+AmuZzmFiIGb17LrRT471x+t5mihA/kFhM61tsOkR05LLjP BJcYWUu3fe5Y+/TAcyL7givg/vTg6on1g0rVDSqBhRToyxBjbTC6MO6pwwzuEqOMSufQd8/6fvke ffZCdo/Q/M2jsAzNooUHArdyKzM7Y+RztEjMY5KTI7/6CNI1XzXzSKQ9sjd+nxfG3qw9Eu0ZBi81 tf6I5pNDy1zkuDzXShhac4DnH7L2E1UKZW5kc3RyZWFtCmVuZG9iago4MSAwIG9iago0ODMKZW5k b2JqCjc5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgODIg MCBSIC9Db250ZW50cyA4MCAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjgy IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUg L1BhZ2VzIC9QYXJlbnQgODMgMCBSIC9Db3VudCA4IC9LaWRzIFsgMiAwIFIgMTEgMCBSIDE4IDAg UiAyMiAwIFIKMjcgMCBSIDMxIDAgUiA0MiAwIFIgNDYgMCBSIF0gPj4KZW5kb2JqCjUxIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDgzIDAgUiAvQ291bnQgOCAvS2lkcyBbIDUwIDAgUiA1 NSAwIFIgNTkgMCBSIDYzIDAgUgo2NyAwIFIgNzEgMCBSIDc1IDAgUiA3OSAwIFIgXSA+PgplbmRv YmoKODMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDYxMiA3OTJdIC9Db3Vu dCAxNiAvS2lkcyBbIDMgMCBSIDUxIDAgUiBdID4+CmVuZG9iago4NCAwIG9iago8PCAvVHlwZSAv Q2F0YWxvZyAvUGFnZXMgODMgMCBSIC9WZXJzaW9uIC8xLjQgPj4KZW5kb2JqCjg1IDAgb2JqCjw8 IC9MZW5ndGggODYgMCBSIC9MZW5ndGgxIDExMzA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AZ16CXxU1fX/ufe9WTOZmQyTZCbbe2GSGcIkJIQsLJG8CUlEIxIgYgZNmQCxUBWCBLG0 BUSpGlyCC66VuAEVW14miIlAifqz2sWC2oVuP/OxWJeaT23r9lMy8/veNxGlPz+//zLh3HOX873n 3HPPve+++yBGRA7aRhJpK6/u7KZL6Q3U/BJ068pre9TP5z72ByLWTmRZdkX3N68etqx+nsh6iMh0 5Tev+vYVnYfu3UnkVInSfKu7OlclDvn+ReSfCXzNalR4tlhfR7kb5aLVV/dcV5YvA+u/G+UpV61b 2em6yjEF5aMoZ13deV23ZZN8Lcq/Rlld23l11+6d+w6i/CHKxd3rNvTQDvY+UU4eyjXd13R1/+PC t7JQbiPKeA11DH/i5yAzxkQ0m+ZM1Ijac3/83OL/ZUky5GQy/Zu8GWWLUWdFajM9S3kG7aM8OUiw N3n6C0qsSZ4WbYLz92B0foomeozTU/Q7NoWpNMg+o2z6lPnZdLqAZPoEs3SQxuke8lIb7WYeKqIs uoQuYDJkwnQrezB5bfJdOo/upEeTz7DtySfRfgf9lD6FBf8pM6qliyF/CXXRu9JbFE0+QFa6idLg pcUsizrpt/j7CHbcRXfTT9h3k59Cq5e2o786ilAk+VzyDE2lW+U+0ynb07SLjjBzcmVyDRXQZOrl 4eRvk29QkKL0GD0Fm8JsRJ5PhXQl7aD7mF/6KXL30OOUYA7eIc0zHYemC2gpraVN1EtP0s+Zh7Wa Tpk+SH4n+TZmcBJNgU1r6F1WzRbwJ2RHcm7yD3QZDdPLGK/4G5Evk/eZLkvUJ3+QfJ4y6RlmZ0fZ c6ZK0+3j1ycfSf4YkRCk6fDIxdCzgm6g5+hn9A/6J9+a3ErzaQk0v8jymcqC8PhvuZ9v4Vuk12ka RtsBazfSHtIpTs/SEToG3/yRRukt5mW57EK2gu1i/+QOvoqfkB6UDkm/lpn8Q/g7QMXwUQ89QYex jl6hE8yE/itYK/sWW8fuZT9go1zn7/NPZKt8g/y5PG4KJkYTnycvTn5EPsqhi2gzbYVvH6NBOkS/ ot/QP+lf9DFzs5lsNXuE6WyUvc9tfDJfyLv5bv4E/5F0sbRLek6ulhvkK+VX5D+Yvm/aaem0JM7s TdyV+FHi1eQzyVcRO070H6RmePR6RMUTdJxeR++/pz/TmyJ+0P8ctox9A1o2sJvZ3exH7EX2KnsP oyTjbzKfwxuhdR2/Bn7azu/id0P7Cfyd5H/gf+Z/4x9JJmmyVCOtlx6RdGlIOin9VXbLQXmaPF1e KC+Tk5iZStP5piWm/aYDpudNH5jrzKvM3eZ3LNstN1p/OT51/D8TlFid0BODiF0rImkzPPEwPYq4 P4Q5+Dk8+itYPEofYhZyWCELwe5ZrJm1sAXsUnY562Lb2U3sTnYfe5A9yn6MEWAM3AJvhXmEL+Gd vIvfyG/it/FD+HuW/4z/lp/iY7A8WwpIYWm6dIG0TLpMWosx9EhbpBvh2V3Sk9IJ6XXpbekdaQyz li0XyBvlzfL98j75kPyq6SLT1fh71HTcNGJ61XTGdMbMzTnmPHO5+Vvm/eY3LWZLjaXVcovl15Z/ WbtZHpsKy1XE/tkf92MNFvAnuVfeysZQnc9kcmHkYczDEqyKf1G9lMC8OEU7bMvkfnmSgJs1WSfi PewIVbMXaauZS9gB5VGKsz/xUfkFfh79hsWYX94nrTX9nBfSAexGffwoP8Ia6BCv40v5QxKxt9h+ egvxfh3dza5kG+gAG2Oz2fdYLdtKv+ZZ0hJ2I9UlH+Uys7EL2AcEC+h6eRV94+wQvjbDZtGf6N3E w3K6/F3sT0O0GzP6FL3BfkifMVPyfexuEnajTuwytyLed5DY9TqwzrZiPfqxg1xlPkGHGPZWS615 rryZPqD/ondNzyKiGrCbvp1YIz8s/yVZmyzDCsMqo/1Yd6vpfKyYtxAlx1AWpcux0u3YSyqxqltp Ga2i72HX25XUkw8lb0h+O7mOfgHsZ6yUfcb6sSKGgKijl/F3B/2e7cQ6PP9rh/d/rEysohF6j/lY MavEehgzXWvqMz1pOmT6iekV83R4+0Z6EBH9JqLZjhGspFfpPfqEWTE3fiqlKtg7E7a301U8Kh2j eSyHurFmp2Afb5gYyQb0sh3eewjr+RjWxgfYJy6nn9Apxlk2RrQS+q3opwV+Xk4baC9m8AY2iJpV 2LWn0t8wbiebyXugT0NPu7FrjcCmP9Ff4e2kYVcp9oVGthR9fYLzwSpoqKFWNoAZOEyzsLM2Sr+E v4uYmxrYZPY4cDGsUCfl0yzTXxin0sTFyZl8jXQMz5gk6vvx9Mql89h6WOHCOMYpky2k6sRi2PA6 k2SdvWZYcT/vSt4kbUpcRb+gH2JONPlaSyORFmnT6ueeVzdn9qyZtdVVMyqnV5RPKysNTy2ZEgoW FwUmF6pKQX5ebo7fl52V6Z3kyXC7nOmONLvNajGbZIkzKm0KNMdUPRjT5WBg/vwyUQ50oqLzKxUx XUVV87kyuipwnWg6R1KD5BX/JqmlJLWzksyt1lFdWanaFFD1VxoD6hBbtqgd+dsaA1FVHzPyC4x8 n5FPR76wEAC1ybe6UdVZTG3Sm69d3dsUaywrZQNp9nmBeV32slIasKchm4acnh3oHmDZc5mR4dlN swc4WdMxRD0n0Nik+wOAohupuKlzld66qL2pMbewMFpWqrN5KwMrdAo06K6wIULzDDW6eZ5uMdSo a3SMhnaqA6UjvbcOuWlFLOxYFVjVeXm7LnWijyY9Iwy9jXr25tO+L4vo3DOv/aavtuZKvU2+NaoQ 7u29SdVHFrV/BZtbKHqIRtEHsLy4OdbbDNW3YqZalqjQxndE23W2AypVMRIxqtT4ugJNoib2LVW3 BRoCq3u/FcPU5PTqtPjbhfGcHG04OUo5TWpvW3ugUK/PDUQ7G/MGvNS7+NuDfk31n9tSVjrgzkg5 dsDpmsg40r+a6YLTU21GzhAXuZbFZz3LhEWBC3QNEbVShSXtAYxppki6ZlLvypmYAPyiDCh9FWZk jW6bF+t1zxb1GCLTTcXugNr7ESECAmPvn1vTOVFjLnZ/RKJRxMnZUNNZ5xd5PRzWp04VIWKZhzmF jXONcnVZ6bVDvCbQ7VbB4D5qhW87o7PL4f7CQjHBO4c0WoGCvm1Re6qs0orcOGnl4ajOY6IFE5hq ybxEtGz7ouUsPBZAJB8yjuOZujV49p/LnTWpafVsnWX9L81dqfaWJYGWRcva1abe2ETUtrSdU0q1 C4fCb2ibyOmT5rVLuRx1IsdzJaMVQXn5srMiKLQ7dLkY/8zCaKwOCUFpVDC1WXfH5qfSqL2wcGLJ /E/MkMX6FdBQ8gOBMtiXsIlR6LPDE3amrNbnnFM+xzpHr9TShh2Ht7Qt6+21n9PWjL2st7c5oDb3 xno7h5LbVgRUd6B3mO/j+3q7m7ALpSZ0KPnszly9+dYohrKazUbYcmoYCLCbFw1o7OYly9qH3UTq zW3tcc74vFhDNFqGo4V4oTKJ1x0J7zcNhzhLmC1DvF6bRCY5IZHdIicY+a1mU4JLR1mQbDig+sgX dn9cN153sfvDugXjdVSPvPsMkukVhRmFGcVIGB76Z1Rp5Ixmos9JlUegC2dzYm/ihCJ0TdNypZnM bJ4p220HJc7NQaaaKkzcdND6ygHRf4fotO5jqh+rH5teMQn9MtDPmD/xNl420gU/8y+RYgQIu3tx LroR7102ukart5pks6nYolorrMetb1jlcmuflVutJMnFGLyNrJZ680Ic4xZL8ADPUdMq0niabFOZ ShWwc4jvHLRPX+ILY4AdYoQXuztgzwIUMFYxWs+s8o714JLJXYdRz8gozMSgQfdKY+Nz+Krxh0zP fpp44tPxXWLcFyTfwRl5Lt4dKtl6bbUlx5pnys/KuTB3ft4FxX90v5Fhq/E3+y8NXuH/ZvD7wTv9 d+XszRnOfSnn5VyH2ZyemWX2Z4XMJZlR/yb+fb7X/LT5p2bH8arfu3l+UeX0jNL0Ii08rapImzwF iT+/al3RmSJe1Jw/lBzRKpyuqvPyGeW78/X8/8qX8/NL2QzSUOsiBaZdUqjlZdQXarluJL6cqsIh 3vO0bHGk20sBH0SbwdFscEiUQkLTvGkF04PWEtuU9Kji2OPgioMlHcyhObOqHDkLq1hVDHNyewVj bEZJ4fJs9kY2W5i9PHtdtpTtn7EmknLt+msWjH24fqxDuDfcYZROi3AaC4fD8PM42Icd4dOGs8MD Zj4PwVuez9ZHx1KFYSpKjjyTm1/VVrSqiHeEox1AZHhmSU7MCqaFre+gjvUsVFMzozIrK1PyZmUX BkPBkNkcmBysrqqpqa3BCSMYmGxGIFrMmd6sGZWoqqlmXcnwayeODrVIucWJ99LcFmn+4x2PH1v6 4J0vXtS6rqWNfaPmvaLa9saLmma40/ib0x64O3rLM4mhW3dclFfrtzY3x29edltLXrGat6hpTuI1 T6UvVDdnaWWwtqgLscqpDfHQiVh14b29TyvzRM1Re9SzNGupL5p3n+V+26c2W3fBtgI+W6pyzM6s 8l8oNTouzGz032+zeeH9uCktR0yCM83idMHN9uwSZ3qQDbESzeWinDsKWIG70OrPb68z3Lxg7GL3 +o/rFoyN1/3VCN/UiqIOuGdeu5a+xrzGvsZzRdYVvjV55g6cSKqFfyjD7ZlRmY2V7M2GW2pSfpI7 E59HBpY9k/g88Xx8O/OPe8obN3fefOM3V9300GVRvK5Zcdz0383dZ7qfvGjtE48/88gejDeC8YYQ /17KY48Nkzv5qdacNut+2wPpu937TfvsR2xH0odyrFYvm8/PNzfbFxbsTz9sPpzzkv1lx2/tpxyf Wj5JT89z5WVqmOtMzZlR5co8nnkiU8oUMeoqqDe4Mxuc36Y5XE5PqzPm5E6fh0HgsD+3is3wkJDN V6sMPrkkxcNlKe7LM7jmwsLoh0vJDbOXezxw86Cc5vEJdxelWaiQlWcWLnQyZ055wfKCdQV7CuQC V6FVS3dVweETcR0WHseGgeAeQzDjwaN5fdoUb71PK3AhwWLyiVWHYA1H68fRPkweGAcJjzASQgaH nODxL0Q/7FgvIGEDQGjwzBKDiWcLpg/a7HONYqSwPkyi69NiLXQY6p0avOQUSp1CvVODs4RMOFpe h2V2TThcxzJmYMV0rKeOMDMhAtRQsNpNMypJKswSATApiIViMWfzz5iv5t2Dib/tWMO8r48xj3lc k7Z3NiwLSdctvbyujrHF5Q888vSuPyMWwomXEse+t3M+u2rz1nnzNoh9egveau9DLITYnGEqwQ7V kWGvhz5HpjnLUSVVWat8VYFG3mRt8jUGHKpUXrLEFivZVrKn5HHzPstex9Pmpx16ycmS0RInlZSX tKLheMkbJeYSLSevqh7lbUajyVIoW3Lys8RysVvErqYVyBZ3RkYoNy8vGLIzMrvcQU+Gtqw6lsHW 4dkyxJs1V05uMD8PdevyWCyP5aHuUHEwGBJrK04UErPjstULrtXA7hBEQ1oEVAcqClWFtNnnVZWH ToTeCEmukBLaFpIopIYqQsmQHPJP+UtqRWKrE77Hr26Be8w9XvcxZhZPk4/XdwhmLFI8+8SfWKsM 00ggTM81YbGlsfCkwkyxp2UbOxteg/BkrAqJjcxsZMVUGdktTNo5csXuiuZHL9/46JT8xNv5oUVz Vk9LvF1QXxNZXZZ4Ww7u+mHbJZe0Lb+88b7xKF/+8LS6+Tt3JzhvfnBZafON94+fwUJYjPX7AOYs He+t92rz32FvWz+Z9Emm/BJ/x8Q9fpPfxqPupZOWZkV99/L7zPdZ73UM2X7D/2j6k+03jrdNb5vf SXfvs/6C/9L8gvWnDtNG6y3mG60SPI65ScsWc+OVLd5ZlpxYbncuz3UWkj+nPfWMSG1eC8Q6EscA Wt+BEMWuZVvjvgJ71hqfzDqi8EjHpCoPPEKZXgpMLgoWi618Ys9a3Dv+0D9YVeJn79+Z+KSXqbvX rr3nnrVrd/PJtzJzb+Klv/8j8cKNyf0P79/f/9D+/SJGb8JxqBbjddN+bcq9JmZzsiWmK0wbTVK5 p9252tntwaHF5VAc/A5H0sHrHQsd3DHEN2klFgu2Y4mb7VPI5rZV2Lptsi1nq2ePhy/3bPUc9Jz0 yB43BZkkNus0zrexfrzJ+zPqh1keTlU4b6yfCAnsIOs/7vAvOE0+ceSoH0PQzMK7MBOPNGrRs5e0 6NU4LA/YK2fCAYXi+CGiIdtizH0G68c5yTTvysZY9NLzz5uzuFwO3ntlY/VH0yJPJv6BMSrJd/gu 0w8wo69oJSqpLGAvcc12XuiMuiz+TPJJWZmU7ZnkZdke7mU+yWaxWxy+IcY0F2X3Z+vZUgxsBM/z ISbHM5l4MA1Spjg94snkSLOV28uJytlyjA8S2hSfFMz2XJJZ793jPeiVYt5t3j7vSe8HXhN53V7V W+GVvf6c6/q/OBm06LUY4RyMcJi8yZGZ0boF4oSJI5j7Q79wyphx6sSeeBpLI2OGCz/hHZYZyPCK Das224ynPB731RmB6hnVxRl880haKC90oW/Fdy/aPCvNdv31LEcOjibatofzcv8wdcaipun3sBOj rz+euAX+wbGY3/HaycHS5a66j6x+KyqIXu56682zHB4034enOMOZU8iLH7hlbuJimuemzz77bDNO 3F+0pNqJ7GZU8SfpZ/Jf6F55A10A3gYeseTTFuQXS/l0E9oVAGpwixNnz/JKaabskXvlM6ZbUzpw 3/VPrMs7cIvOEaXluP0h82f8eRzkuSHhmdArbtmpfUlztGVhOHLNms6ryhrWXbVqAT6oiHOI8UuG 6Hep3L+ldpTzqYQacT82H/c4i6HlUqKBtm2RdOkpOgiCcqQqqB8kkSY9NWhJr9SGwD1eg8ezwpXD yRHpqfjsGUZ92d2V245KB3BdNQPVB+KXiOoDg1qjED8wOGNOipdPN3jcmmq2eCuVSA5g5SBOronc QvA7QHtAx0FmGHSA3gAlQZK0X3o03qyg4yfQkSvilZ6AYzSkJ0BJkATrn8BYnqC/T9TIsOqxQZtD qH/MQOVKjwHlQuoGbQMdBJ0AmWgd0j2gJEhCDlfZIC49Kj0SdyvuiF16mLaCuPQAuZhYdiPSfYNu wzf3D7omVWoRt3QPtYI46dICGgFxdLsLsF3EId4SL5tuuLBl0O6sdEN+J4zeCUN2QmU/UmaUNeSE /M7BSVnC+BvirgwD9514RVUqM+j2VbbCC9cRk7qktXghUXAJvhZXhYq0EjwffIW0Chu9sFMbdLkr t0FfPcTrcSdcguaIlIWbVkVqlHJwyyfENsadKT0b41OmVmLE8ySfIeKS0nHJqUhWyRKvVNQjkmY4 /+ZBW5qw7+a4O7PymLRDsuBgqEjbIJWtuI5Jdsyx3RhJ26AtvbIv4pDaMMw2uEWBjQxeFqkmrY2j o0iG1CTl4cOMIl2JpZMJ3iwVGHyf9Ag+hyjSDwaDecrIEekuA3Wn6BTq56ZCa+5gurNyJGKT5qJV l27HBNxuKO8bDM7ElXJQmkIVIA4fb0VuK3JuqRe5XsxaL2aqFzPVC6N6EX0k3YKWWyBTLm2mbmkT 9YH2IC/CKjMOh4rFkBkvmlI5LPklHxzjPgJXMtTmDNqcwjJf3DPJEPMNOpyV9cekDbQQxDHknsFs X+W6I9JUYyilg75cAeiOI1yP4ROHMTXoKUtMyTEpD44QjsmXCuKZih5RUBaBrBDjP+cnhZP46/w3 YrrFVx6D/2KCvzLBf5XiyRF+MrUo+GuCj0by+FvobDn/M+1BjvMj/AW8PCv4VDQkZp//ng9TPfgp lFeBD4PPAH82XviyMsSHBsFg+4Px9CwxWP5CPFw+kVGKJzLZuRMZT1ZlpJg/z5/DG5PCfwdeBP4c H8GXSYUfB/eBj/Ae3Oor/GlejW+eCr4Apfh/8KMixPkz/DBu3BU+GHcKE/S4RbCDcbNgP45TqtRa rhzlP+YHKAeiP4oHc9C4fzBYpLiOoD+Gb2I98XzFE7HzR1g7+xBC/biPBycPfzReKzrpix9VlWHe x/s0X61WrJVpe6WK4oqyir2SWqyWqbXqXjXi5rdjA9nDsX75TqS1pHJED0gD9fFb4nKtHhnHmMS4 OG1D2m/kYki7jRwhdRs50fqBkavnO2ghiKOPLaCtoG2g63El08c3g74D+i7oe0ZND3IbQZuwm3QD 0Q1ENxDdBqIbiG4guoHoNhBCczcQ3QYiBkQMiBgQMQMRAyIGRAyImIEQ9saAiBmIViBagWgFotVA tALRCkQrEK0GohWIViBaDYQGhAaEBoRmIDQgNCA0IDQDoQGhAaEZiAogKoCoAKLCQFQAUQFEBRAV BqICiAogKgyECoQKhAqEaiBUIFQgVCBUA6ECoQKhGgg3EG4g3EC4DYQbCDcQbiDcBsINhBsIt4EY BWIUiFEgRg3EKBCjQIwCMWogRoEYBWKUbxqQTkZeBOQkICcBOWlATgJyEpCTgJw0ICcBOQnIyYmh C0eIgBkBdgTYEWBHDOwIsCPAjgA7YmBHIDkC7IiB1YHQgdCB0A2EDoQOhA6EbiB0IHQgdAPRD0Q/ EP1A9BuIfiD6gegHot9A9APRD0S/gegDog+IPiD6DEQfEH1A9AHRZyD6gOgDos9A/D9PDb+etVvx rMXxusTgW+l9g2+hUwb/Hg0Y/Lu01+Dfoe0G30y1Bt9EQYNjqg3eQ4qVxZVaVyQLW8BC0HLQOtAe 0EHQcZDFyJ1A7g1Qkldrk2WXZaFlj+Wg5bjFdNAyauEu3DvuMR80HzebDppHzVyN5PJ0Yx/F1kJ3 AMdoK9K/g/AQQVpv5Op5FfRWYZ+txl8Vr9IyxtS/T2UnprLjU9nBqeyOqSxi4+cz2djpVKrF1a7C 2jVHcK5yClQbDM3FznT74fezlXiwRhliR1OsRAuj+D5oALQXtB1UC6oElYGKQQqoNjgVsHZt8kSX R8FDoEKQCqqlLPxvHfJkWLVhns72Dr6YTjahJzQFuCPxUAXYUDy0EOyZeGiFErGxw7gIEIY+jUV1 APxgXDmN5h+l2FNx5QhK++NKFVhHPDQN7LJ46BUlks4uIQX/50VhbRN8CSZclBfHlaUQWxRXSsDC 8VBQSE+FomK0lrB2Og2OvIEuSmkKxJU5kJ4cV2YJaSuFxMTj23SZYZ4JeVGWBmHQ34dZu8y0NGVM uUt5H/b+DY5FePxeHZLBThQPsaWaXTla9jCEI0o8YhfyeD4MTHBd8KeVvcW3KA+iL1Z8WLlfmabc XjZkRfVtsPsWQ0Vc2Y5vNge0Sco2pULpKTutbFAuVDqVxUpHMerjyuXKUWEmRVk7P3BYaUWHF2AU xXHl/GLYAhOblW8rmhJSZqlHhX9pplCNSC47KjyA+2hDeyn8O7UY2uPKJbVDLEObavnA0me5zNJg mWMJWCZbCiz5Fq/VY3VbnVaH1W61Ws1WGVfqZPUOJUe1sHjP8ZqN1x2zLAqykXfjHYMhjkWKm3Yr pwtJnyS18JYlDaxFH1lJLStU/eMlgSFmX7RMNwUamO5poZa2Bn1muGXIklys14ZbdEvrZe0DjN0e Ra3Obx5i1NY+xJKiakeu+PY4wGjHbbnDxJh/x23RKPmyrq331XvmZsxqbvyaJGZUxhpTdzBG6vsy 7wvn67tblrTrT+ZH9UqRSeZHW/TrxZfJYe7i6U2Nw9wpWLR9WO7mrqbFol7uboxC7LQhhmh2QoxC gkHM2kCqEMN+0iDEMEcpuSDgkCsUDHL2dAoackF7uiEnMyE3cEptahzAd2IhU0x0ypA5VUxfkUHE ANs4EEQCqYDK2oUUwxdow7ASoyNFgUgZEogwnPuMjhRmKNPLvxQpnhCpPitSbeiSUvYY3YgE3Xin fCHjnQKZLx35/5fragizwekbt7zQhI+9sUBTFyim77x2tU/ftkJVB7ZsFA345hqMrVi5WvDOLn1j oKtR3xJoVAemG7h/a35BNE8PNA7QC01t7QMvaF2N8ena9KZAZ2N0sL6uPXKOrlvO6mqv+xpddaKz dqGr3sD9m66IaK4XuiJCV0ToqtfqDV1Na0Tct7YPWKkhiotZgw/yNDtiOJZbGG3IcnfPFQE9PKfQ tyX3WZnwP3fS8BHWgc/26SDRVBYpi4gmrDPR5BRf9CeafFvmFOY+y/ZPNLlRnRFoMC56xWSQwItr oxa9EB8ERajgs/vXz9kG8TOafdS0phH/UO4xqGdDz1enloTk//z1fN1v48aNG3qQbAzjMrhFn4or nhpxiWWxQFWsMYq6aV/USZJRN2CzNeG+FY1hGMF6hDqRCzNxEa7ZyUwW3m/ut3DxFtEzmJNfue4Y zg1bQXgd5pviuEoQTZsGJxfjbQki5dUpjtdVUY7nFFaKm91aQAUvTnEtowyZvuK+sr7a/uL+sv5a M1oP70Wlslc8SuPleyXqCW/4whnI9kThbHE/D32PxPPyDcX9IoOr9vAGZszCF/JfcqMexS8dizEa vw1G98LfhoeRiiymUrRiPlLaN4qS+KUyBhZ+NkCohVSqZFSJ5MsfSkT/DUq2RYUKZW5kc3RyZWFt CmVuZG9iago4NiAwIG9iago3OTA4CmVuZG9iago4NyAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MjIgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIK L0ZvbnRCQm94IFstNjI4IC0zNzYgMjAwMCAxMDExXSAvRm9udE5hbWUgL1hTRllLTytBcmlhbC1C b2xkTVQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAg L1hIZWlnaHQgNTI1IC9Gb250RmlsZTIgODUgMCBSID4+CmVuZG9iago4OCAwIG9iagpbIDMzMyAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwCjAgMCAwIDAgMCA1NTYgMCAwIDYxMSA1NTYgMCAwIDAgMCAwIDAgMCA4ODkgMCA2 MTEgMCAwIDM4OSAwIDMzMyBdCmVuZG9iagoyNiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlw ZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9YU0ZZS08rQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRv cgo4NyAwIFIgL1dpZHRocyA4OCAwIFIgL0ZpcnN0Q2hhciA1OCAvTGFzdENoYXIgMTE2IC9FbmNv ZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKODkgMCBvYmoKPDwgL0xlbmd0aCA5MCAw IFIgL0xlbmd0aDEgMzQ5NzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBlL0JYFTV 2Td+zrnb7HNn35LJTCaZJEzYkrAEornKJvsiQYJEgoBsIgSQooKAyiKioq37Bq6gIgECBsTXlFKt C4VWa12qUotrRaml1AqZ/H/n3Alg337f13+GuffcZe5ynv33POdAKCHEQVYSiRjT5k1doFaqF2LP W/w7bcnixL0Lfr+EEHo/IWqPqxbMnDfxib9dRIj2G0KU3828+rqr3nbt6UaI82FCrj46a8bU6R3+ ZAsh1y/D73vPwg7vPMdvsY19pGjWvMVLaxvzBmL7PVyzx9Xzp01d/sS0/YQss+D4g/OmLl0gv+m4 B9tPYjtxzdR5Mz5yzpuF7YN8e8H8RYs1Pz912TEs9i1YOGPBuOzBrwhZvokQWwf2UXz4n4OopA3r BLlc7GF8p/iTiEwUHMVLEAuxEhux42wncRE30YmHeImP+EmABHPn81WIhEmEREmM5JF8EicFuG6S FJIUKSLFJI0zSkgpKSNdSIaUY6sr6Ua6Y90D3574VpBKUkV6kd6kD+lLqkk/0p/UkAvIhaSWGOQi cjEZQAaSQWQwGUIuIUPJMDJc2Uci+EaVZ0hETuP+pOMLfL/k6+zsji/5cb5mX+P6rbkvIVvINjqb bCOvkAP0BH61newlLeQ3eIOB5GGyjPyCrMW7T8KeW8k4fBTs/wWNdLTgeTeDBzaTQzj3MnIj2UeC NNzxFVlBVktv41er0UeFeNYxZD65nY7ouJZMJp/IN+ONRpBryAK6smNixx0dd3c8SZ4ie6XfdLSj X6NkGj6HOr5V3uv4E3plMrmHPEA+oXdbd+O9LyMrceYjZCF5UGqQacfMjh/xBEnyMzyDTEaSQ7SN ZXD1GeQLGqbLpAG4yhMdzR0HcVYeaSCzyINkH+1Fh7CkMrljZMch0KwrWYqrPkB2kj34tJKXyQfU oZzoeLLjBChYjr5dgf74LW2Tsu2rsrXoNwW9VAaaDMV7/Q95jRyhKfpLNl9xKBWKoVzf8Q64oSep w9M+g19+Tv/JbsRnhfSqPLjjYnDNanIX723ya/JnGqXd6Wg6gZWx+exRaSH4qxy/7Ummk9no7/tx 9Y9phu5hDnZYekJ+Tj6t5mePdrhAkTR5iDxCfkmdeNMEXURvou/Sv7ABbAp7iH0q/ULeKv9em4q3 voLMI7eT58g/qZf2pWPp5XQWXUbX0rvoA/QQPUK/ZBex8Wwu+06aJTVJL8sX43OpvEi+WVmj3KZ+ mZ2YPZj9XfafHRUda8hY8MMqPP095FG82V5ymLyPzyfkU6pQO3Xhk6BJWkdvwOdGejt9nG6hW2kL 7nKEfkq/ot/Tf9DTjOCjshhLskJ8Umwh+xn7BXuYHcbnCPuG/UsKSYVSRuol1Uj10nw81VppIz67 pT/LUfmw3IF+rlDuVR5TtijPKQeUE6pDu8lCLG+deaK9S/vHWZJdl703uzPb0vFnSCWXwjzIXw2e fio+c0Dve8Fx28nb1IG+i9Iu9EI6Aj0zhc6hTXQpevIW+iB9Sjz7C3Q/eumP9Ds8s5PliWfuxnqx i9lofK5gM1gT28juZi3sXfajpEl2yS0FpC7SEKlBmiEtlq6T7pWapbekj6RPpVPSGXw6ZJtcIBfK aTkjD5GnyNfKj8pfyF8ok5U3lc9UmzpPXaO2qn/TemsXamO0sVqDdqe2R3vH0gju/BXZTV4EB579 o0elVdIgaTe5g1XKEfZb9lvw8xQyXRrJwKlsC13HltMWVqQsVfuz/nQUOSGn0devssfYKdZfGkmH 00vJHMY1Dv5Uv/wsVjXyr8hxeT/e7be48lLVQW9k36kOspMSVg2F+Wuph5yR3iQfSJ9QTd5MPpRt NESPs2ekMeCCl+ULlYkkKT1MXpCa6HKymw2Cpj1t2QA+HkWfhV4YTyvoD1IHkdgocFEf6S/kZjKX vUeOQ47XkfvodHkmuYNU0mXkC/I0pKJMuUbtogbo62y2vJ75aAth8la8XTUtopLiJ7fQBulB9Tv2 PrmWHJZt5GPpeTz9YfaCNFI+oYyjsyABy8ka0tSxilynTJR/T2cSiU4gxfJRaLdlUoWcxHoFtMpk 6LQ9kO590AMXSSOxJwzOGQG+qIOGeBCf+6EnZHDQbMj4ZdBivyUt6njWSmYqLgqtQ4j8ZnYcmdTx NHmgYya5puNu0hX6YG3HMlxxC/mM3Em20NXZG8gC2IT3IdsjlMHssDK4oytbz95nl7J7f0pf9HYx DZOv8XkBuv5C5SWyXv4juZTUdmzo+AO4uxQa9gFyJfT/Mbzlt7jDJVIbqcyOYjs6BksL8L6fkLEd z3QUUBuZ1XE1GU32k6c0hUzVMsaAuvEXGbUXXlDTv1913z69qiorevbo3q1reaZLWWlJurgoVZhM FMTz82LRSDgUDPh9Xo/udjkddpvVoqmKLDFKygelBjcmmtONzXI6dcklXfl2aip2TD1vR2NzArsG //Sc5gT/3VQc+smZBs686t/ONMwzjbNnUj1RQ2q6licGpRLNhwamEq100tiJaN8+MFWfaD4u2iNF e6NoO9FOJvGDxKDwrIGJZtqYGNQ8eMms9YMaB3YtpzvstgGpATNsXcvJDpsdTTtazaHUgh00dCEV DRYa1G8HIxYnXrE5mho4qDmSwk9xGal40NTpzWPGThw0MJZM1nctb6YDpqWubCapi5vdGXEKGSBu 06wOaNbEbRKzm/E25LbEjvK29RtadXJlY8YxPTV96uSJzdJUXGNQsyeD+w5sDl1/LHxuExf3Dpi4 9vyjMWn9oPDsBD95/fq1ieZNYyee99tYkl+hvh7XwG9Z8eDG9YNx6w2g1PBLE7gbW10/sZmuxi0T /E34W5nvNyM1iO9pnJNotqYuTs1aP6cRpImubybjrkvujEaNvR1HSXRQYv34ialkc20sVT91YN4O P1k/7rpdESMR+emRruU7dI/ZsTtc7lzD4Ty/MQOdbh4TLXE6bw0fd7ZnKX+i1NBmAxw1LYEnmZjC O/Xlixl9yfppfUEA/NVT/Kp5Oigyu9k6oHG93o/vxyvSZqVYTyXW/4OAA1LHv/npnqm5PWqx/g/C D3I+OctqzXRqZ7s5k2nu0oWziDYANMUzXii2e3UtX9LKUqkFegIrdB8Zg76dWt+vO7o/meQEvq3V IFdio3nl2InmdoJcGdtJjO6Z+mbWyI+0dR4J1PEjKzuPnP15Ywqc3CKc1ECzJX32n1sP+gbN6tdM g/+XwzPM48MvTQ0fO2liYtD6xhzXDh//ky3zOO9Q9BuO5VrNvgETpRjDPt5iMUkcBVNOnnT2FGxM dDTLxfinCqae3qpZwJViD00MbtYbLzGX9bZkMicz/68ftXac4L8Sq3M/y71Gc79M7kHNx27u/5Pt nzyeY700fDxUDhs+ftL69bafHAOrmU85NLcCx5PxE5OJAc2kDpJZjH+tHW19+bc+1mygy3BkPKRI 7K6P5TZ/cmIs96N6/HHu7Fo+GDpz/frBqcTg9Y3rp7Z2rLwyldBT6/eyA+zA+gWDoO1Mxmnt2Hdb rHnwhnr02CzaD+LByMVcjAeMn5h7c0EWzt0gEzfhUMncQVUIPF6NXNzC6DFVa2UPGD6iyMckYtPk Y5RELKpyjEn7YfitcAO7kXBGP1XTXjNKP1kzsr2G1KKtn8GiZ4+kJ+kpxoLC7J1JSG1nDIWcJgm5 DfciV0i72M8QVyjw3K/di0Djh12FxVVKa8cPRmG6rMqu2mBqZEoURbV/a7VYJIkRzVJjc1tXWpkV vWgEnO4q68dUkmsYNZyeKhpxND0TzuBBMvxJ9PZMAx4DD6Tj016DBfV4q6v5t2cPmsn4pF6VAalS LDdWHOr6Uc9DPaRdNHTiRPYrc0kgKJOwq0Q8Z9oIEEWiyreMSKsSdCNldI7K76ifajhOao+Lq/fs YV52XTdxMe8//pH9Ft1KybLsWNaovI2o7wLDVuKmRPdqFl1vpZW7yGMuC9aGR3vMdQWRdCkhSdLz nkc2iEu3nzqun8L1a2rRpbSBppmnqk/vPpWqhk9Ap/STe347ctL+VdeVXJDK0Ex27H76A3V9+0H7 6SP16+996eVsQTbxk/vPMBylrFRnVptOidfKn8D2mESxbiGPSVe4ICctus7q0Pihxe0WjWMtTqdo fGO4bTZW53YVuJjreW/uGTP4+7fn9KWIp6okjU9lEB6AztpXoc8LLyi5ftX+SSMPZ8fSo/TP+/fe u37S70+3f/Bt9vssD7UpMaRp7A/opzBZYwyzU7stRmM22WZ1uNy6R1PtlIW5P6ERWbKEvE4N3gT3 MISDAf/CL2uShdpUxU6InvBT/ysqOOwptZXeYziVp4jh8VWRSGQB+pYzysiT7cc4yzbUVHev8Yaq 8Q9kFGu+6tmDNPj6BEN4CVXr3SekasGQli5RtZLefdJGt8cu8dG7JP/M1d1WXH/B/KX9Rg/ru2Rx xSp52x19y3YPnHZPVfkdXVy91tWNXnf7sLo7u0X4+z2b/ZjejJjTRkbttkHQnsOjjTHSVKphjNpo DbExCRtE7av1Gw1/fD68y02Qkk32zfeDH042nDymHwcvg+E4Yx/X2wXj9exRCW728yfr3WfPoTGX VVT3lg4darotPTIylaMSF9FWNofNg2yXG5EFbIHERtKRuGWKsKiyACdE5AW380451qB/TrqPPI53 b6INvl7JwEWsjLbu3g3y4LR9WKzF80uk2Agz/rg15kNuJ/ImHN8ki+c81SBkwnysfYcOHeK/BZrA qkFbiVy6l0gdH+/0V7PWjo+NhL/6Poky6TFpu8SkJYT6cTbUEXSO9CVhX4I3t+L28q7r0QM1+snj uikPa5VumYbl+kEuF5lMgFZSunVjdmJE+eZHXIGRuo4vZI/SBpnLp3U7GNd9hi0alxV/3OkMQYl8 KfibN4wIZ3Crhzg4x5Ogw4Glg+8j3cHch7A4hC6vRbfEdqj/+0oncSW1Dlf6HJIiGt8aEbsdLQ/R +R6iOxx8yfedveS5a7aoiYieB9HbyRL2/4F7FMTXi6+746hxpayuZevs69yvuxSrZg+zQb4RgWGR AbHxvsmByZFxsbnaXPs039WBuZHG2HXsZ+oS+/Xuter92r366+EP2Lvqu/YP3dGzL77IaiRTVT2s lFh16NKNBZ5FhCtUF/YmAJUwsjH+2m1C+WSgexqaMly98VenDU2AQvryP4pvfb1P9/aurAgGvRBw NVVYkvbpwcqK3h49nSrU1Lq5b29asnPxxXPe3vzOdXft3bps2datNy4b1sDepjK94Pkpu7IdH2Sz 2V9tu/9F+kj2vu9OAF+Y8+3sNZxXPgEBT4N2NrLdSEhcv8+VV7A72QMW+XmZWomqMMmqUAejb9jE 09v4OxGawG9bO44KDYbG14ZHEDRPENQlCIpeNiKcXJ00EfSJOhQDFgUWyOyJHgpNAJNhSsS+j9bQ 1TB0XDiaMtD3XN/hDxumzavlaoNblQbSkEmmPKqq9YIcVrLTLRe9Pf6+T7svlm+4cFnBC0PemMLf rQa8rOHd4vS1HC9ZPboz7POpdc7WjpMtHo9ofGtYdR2tuF+JcxYN8RPicX40nufCkTgYFMtW9pLh YLZQKFGgexhLFMDEdX/nEF8eIt2P8yet5cuDCNJiOTHgN3R4vUzc0LC6PWiZ9zlq2L0+Vhf38338 2jtxaS4qdjurQ+MbQ/Tif7oblxF+P343cTOjd3+lv/qS8or6kvaa5fU8baij3jHeNdcx3XW993rf rd793s+in8VORB2v2F/0sZiep+frcV39HwBoGpjfgrUV1IrGbbpFVd/Ii/rz8qKWvCi0hSWaJznj eit7ctdoD/W00vBu/gZEdIebModtUeht9DbndfoSWwUUVad9DYdndy2ArvlsBZPZPlZECuidO0xm h145leHqRTgxtcfbG45xIyAMwlpXt4wLqoYbeWjGTgnoSxpow8L6+uJAMt0HFO/du1cVWF+oYcgF FDKMtKrJ2pk+LFT8xIPfbXnghpsepnt9P/zu7VOXPHPg8cnxbdsuqpnWduPBz66a+/OH1/sOv//1 tonP7n9y3VSOrFAyoeNzOQheydD6HOnskbDB+TicRyhn1owDG7QsZXO6He64zVYWiOfJ8bI8pcyZ cjrCERj5BJQPq0toaU5Hfnq6O1dph7rzD/FW19bCkBwHvxx/VX/VW60fzFTwL9jFKFWcQecg5xqn PMhzmWdJTBoXvFqf458evNZ5nX+Nc73/1thTTpuSkCB0ht3ucLpkjeK+MDdP7jLwAi8BhCgjTtqr xeEIyOF97EkSYbOMEjylgsd0ehdNScxPsESY83JipbYoLbRTmpK0nmZ44pMv8iPpjV3DrbTvzsjb dB/tC1PSZtjP6avyVnp3joqZ44KOXGudzAgjBEqCkHg5XVDUJCiEFUoM8kqb6mHiudYSpNP6nG12 UpGTUQtiSVKF6QktBffMXbH98eWVI/xe+6LWNXNmb/C3JL9+Yekbc6+aftPG7Jfv/rKD3hx+YG3z Tcs2+x9lS5dPu+mWWxK7X5u5c/qUh7vFX76jLfuPz0FbBnSRyDp8Sxu6J2309k50zHI86NjqeN2h jJBGOH8hS17wOXGokqbY7JJGHBD4NyTZL0my5CTM4YS38xJ7CdAvo5sMG5FlnELesMmt7KoXFcVm 5BdU2Tq1IRrcOLE6NL4VVsrWSvsYTs0oTFVpK5O9tI1umGP0q9NfRZjOEkzC9lHxGzSO7eF0YLtd rXSD6OtvoAGFMjzJVUyN/rnO3e1aBAKnajzVvJurq9d2y8gQG7fbjQ5HcLeXOGH3vdXQc+8Y9spq qbBrtSTn59fwS9SDHDjH8DsMe7Vj5Zhqh5GudhTmYd21mp+QqUc40YtWeioDKY/koeze9lvYIz9/ 9dWWbC865Slpz5lhT2U3Q7DvaZ8L1uP2P6k8DT07wZSdvYTi/Zy8E2ieyxYPBPK8XHva3bIcz3O6 KNHCsBnCKxANIWfc9nM54TYQbNR+ELLBRaPMK/SvWyyHR6/LX59/r+8Z368c7zo+jFmsvrCrS1Sy 9lB62PdBl0mQD91nC3h9vjdcbr/L53e5nRASw8cfxHBtgkPtchsBmnuoF90yfZsLEDSbkeCP55mi z9dX6Hfqsg4xCQsxCVMS1sMMD2uKSXhjwruf9iJueg+Yqu9O1+7/JC4FPxWXcwLTwP1KSIl40QZP dfcGKIZjay3dMgqoSITy45a/L22Cx/UTwYG0+JKBpAR/gAT8GryBdN3LgQeuvqll24bLNpRuvYO9 3/7i6FvuaqOWxbef/E07Xamvv+3g4w/uHF0bZH97PrtkcvbU7167a+dRiAZkYyRoF4Deyydd6Oic 5itw0wJA7RKNlcYNJ3U6YRhjSmHc77TFKSnW0QmmH6fHQzo3+yGh90IgENo5P+7QO4f0X3fSsuG4 frCB07Lr3AgdqBmBgZGBiUne8Ym50nRtumWOd3piseXavNWWNXnvWt4JerQEl4ESUyrUupRQenxX UhzQ+IGSRCqR5Ac8/CnHOBmeM0bfnsJJCcVn7XxmeLV9DS/ZXbxIF6RENKYj7sJbnHiR+4r6xnIb V3VxWm0Ea0NTQvNDK0JyCK6pWhcK8puGWlnRrozpqkEWj3P7JfSe6a+Z2q57A3fcOM24AHGNV08R wwgHDUENyOXlZipVSDx6H2wFqf+cNlSl07vC5UPnTrio7kp20f6ZLe0/O3LLn7PHHrn1y20ftfcZ fceohU8+fsP1z8qXuub0GNnjwm//NK0x+8/frz9+I9IDy+jWX245cOajhmfrWx+9f/t20JUii0Jg z55Bfm+B4TropDL+MYtshT7jktiDUdnqcC5CuM87ZbQw1RKLui2LrH8lo0H9KUyqxWo+XQEnMgJl JBQ/grmGppqRJ4+P0k9xr4xHCByKqPYIPYQeaBKxjEokVUv19nr7TJV2b8geH97bvVe66e+3yj9u 23BP1ps93frhNvo1fQ0pZkQp4MEIeDCE3GsPRkwubHGQWLwb15Pwx1hdt27eZFxVSuNeZ9zq4GYW QcBJqEo0Mm4eS3NGRMN0oHhDHHSHYTHNQFs0+Flo5BhYKgo4uL8VEFcMCAYO5BjYjEbOC0mgkzLH OaiRi0xeFA8ighD+IGjwBzkmIhTeEPty9+duMG57xijkJ/LbcvbiN+RL/qbn3q9TaHAvKnSi+SQi NuIy1KdXkJYFhwaHpj93fNVDsfZACmc5XSYvtjTZFzqudV4fuo2spxvkNZZV9lsca5y3h97yvOrz FkJWduYlonyVSHTnq64J2P2jRrws4SDxMHHgMTZ1o+eeJL7oFSu1trKZhp5Z5DYS8PyBqLh1N3O3 0rv2VIQXNSOIxvGdRYsCnQ59ImAEWGBjz7OhzUlIP7gGfkLOTfBWN3TnL8cNV05mhK5rWNhEmurr aTrdq4pLyHn+AMEenz/Y6T2o0vnCQ+csuPrzV9q+njtv7e3ZU++/nz1115Vr5s5afetVM9f1G7rx 0lVbtt204hkpVnb/nE0ffLLpqvvKyg+u299BKG2785d0/Kxbbp4ybe0tZzpGbhz99Mqbnt3C9SK3 aZwn49CLL5jRw4v2ApiBYg+MwClBZG4NhIFH44RRyika9giSekQU6gl7yjP20jhHcUa7JJfLT8ZQ KpxJp47ognJrA7WqCIofzDRUgMUajleIjgHlOSPqXI9+9GvOdCKwPu8hztlPo4swoB7Bxf+Hu/70 Xv92K9zp3I2Mqn7REUEjdXnwstRV0tXBedGZqeujy+MborfFHwxuje6Pfh38PHEq4bsg+GhwW1Dq VzZdZSXc9qbATOFkQk2Uxke7pnBDm8dfj749xlTKLfwhCvbRamKHTvb81LRuLOeauoUras9ZXvIY HubZmNO9DabPyVmJa96z9rNT8ZIGICkIloWbeSHrVVXC9S3WBMyEzBgPndNUBA4BwUsLtgWXTb10 +ZjetPdL8/acodqrdx6/4fq/Pf78B+zNpxYv3bl12fLN9FL9+mtGrHhvgSM8YS61vPcJ1R/M/gU4 2hfZXS+8IlU9tOfgwxu40mXIthO6BnUdHNftC18CFSmalak1slRDVRkIDnwbwhLoi82WHMrUxPUn YgJBciEOPo6W4rsXYI5Uf+jQmWcA6jATzxLXRnWC0X2R/Wb7z+1P2E/YAbvRtK2PbbBtgm2Gbbft U5tmt7k0fk+tRlUVl2x/Dg7oGCOl1MjiMVYBfla1GtnW195P6S7XyiwhU3mzu/ORagB9AdcF6MW9 zPb24xzY5YELf0iiv86VPFnY1PmgZ8GwQzk4rPOpO0Ex7megcoQo9fDBNeKiM/dQoIysDs7u9y25 xg9CkLDnpFHPBYnreLVOEcvueg99pmWWtVFfJ23UX1deVdv0E7rdotSjLGOMPsverP/d8Xfn311W 2SE7ZZeE9Kciy4iRLKqmOdC2oP4AuBhHvd0CoUhoDj8OMQlK+QcD2hhWISE7/PiVNa4olrgqqa1s gWElFsdXBqOM7aN2KAy74XUkyAxNGjcGZQ6fyNJGdF0rpYZ9jKNN+8QhbXRQB9/W3dphja3QVmpM +7n73T8KTLEpAj2If2F0ZjSig4vDtTXR47XH0L34x3G2DPy/td3CYi2YAh7+Wv3gQdfBg2sVc43+ H95sv3R4cxzpoRbZLVm0fQjgAe1zLVpPF3Kfkf+lgNSlpKTkS0ocTJVY5e/YxI+ea39o8/v0bw8M LsyrVPb9OJjuzw5kk+i9e392+23cJ5RQe0Hkr0Arj/AKfXuJDKoM4YiaLA9OTUhdlVpkvcWqzo5e qyywghOVm+1qSdAqhUu6xIP5VqvPG+/SpayM5OXH0XMFgFKIJZxWHRztVhEdGZXcCqterrRUlfe9 auFXRxM0V/3cKKrji9OOPP4Lh42f5+CcEeBnOaLl+fEE5WKU4MdBVa6Ocw1+Lvb8iCj4bAMIFFfQ uA5aDZn+kznmZnYRT13AlcHGSISx5h/YHnv5F+oY+Q1g1h6ezqACqRbYU6UnCTSu0z65WIomK0xQ Ip1C6FTRh2ufNNr3svSWNxddNXP1nZet/OWG7M/pBav6Dhs++KZHsx/SeVekB0zqN/6eDdltyr76 vTOueLqyZP/KmTsae0rjPMGrRg6dX3Z6k+boO3fwuOsAUlByVccXyhLguvnk7d3T2Jx8BlPC3R3x fl8aU3grQSqc01C7sDh/JbklfyN5UHlOesq5V2pxvuY8Qo7l/z3f4/Lme/LzpS5qqadLXqJgiHOC /7LAhMgsZW7+Dd7bvA9KD7gezNtCn2RbPH9w8bq5qO7XozJk8+OdpdXCfHUtrdbdhMoxX9whxeKy VU+7h5F0AtYtWhBKJyzUAr9KrbNE4tPQ2zwF0DCS+4xYctwHEZ6Hw/5IVTRwrBMO80IaUuVUYRE6 zltUWSEjAQDfWWUBv5ebfbnlwAXZX312PPvHh7bTAQf+RMv7v1J54Odb/zJ53udrnviUsZ7fnf4l veb3nwGBPvpm1013P5797q6Xsl+tRyEi182PQv9MAk+70XufGd0TBXSAxeRPjx53Ewse2koLBOBj FWxltXGesgIuMV1NriSglqIF+fp/zXz/BBcK4vzQyXzxf2e+HCNyzyjHdD17DLjO6C3FNItqUSyy RVYj4WiYqXYbJMEmqYGgP+gLSmpMCiWp14VF2JKXpEGbJ0nQj5lMF/ytog2cR0PICSHsYODQ4mRF DjcrAV8+Sv/13KQb6xcvGnX9XYdWZ3fQ6rue6jlo5H1Xj9qWfUvZF8gfcWX28MFnstmtUyu29e45 6KunP/9nlzh48HHoBl6naCf3GAFViVssmkYkmQu6zRq3EwtiszYjX/dWaeOlYQlbwslsUads/a/7 jEvuTwXW0f9yk4WEeDZwKFhw0sljmbOdlpNU5EE8CI5z38flojOPSpkzf5BuUfZty9Y+n3Vu43IE B09ejXewktuNjHiHOzV69jXwCg8nkB1gLGr/L57bsAtNI9gdaib7vx7fxknOJcD8O/f8yIjllEwD 1zLnP/sW6aMzn7Hm9jH8uftta78KPEzJPMj/Xsh/MfUZ0Zg/FmCNJfQKi496paIikvSGWDEBITgB ErwTKVVDcZeEuMlKabqkuAgJT7xZSaMAnHigkrPBnMch3h8IpSlscIz/ni1cWUJL8tMJG7UJh9YW SU/L0QKCPFJvEFoUb4THh4I8C91kwMrY5joTX47kgqUHyqlYXjQvkiepjrReHEgXpC3FKEkqDjvz kyTo9iVxst+X0LBVqBQnaZ4dvO33YBG3JpOkSMICHC54nLskuQ4Fw4PbATD2Kvb8RIMgh9iNQYXw /K3fK0OJ9PFII9i8O7NHNr2XfaxlFx3z4WOU3p3enrxyz/zVB36W7LuWsrtuPHEhq32eth9duGgv veK9d+milpmtv+ixYOXIsbeMXvfYwewPK6f2oR7Q40nolEIhC+9xvK3NiPoCVbIUt9o22Y7YmE1h zG6BDCeQPeVYoLB68HmA/KHDVQGa4AB8Zq4rVcr7XG1YCcSF2U154aS04aL/N0uXY0BhQcGA5+mc oGnwHAknTQAgaXQucMr968PALjrNH9QvSJWjI6BFkcevrUF8ht1cPQMCRHVBpSeF5ZMH2I8HDrSr yr72p9mkHwezXe0jBV++AuZchX6QyFu7KQqwGE/u7Op7gUjy7KqsMtdde5jr0jJznRJlCG278uPm djgq1ohl9KqEslHZroBb4bTdibxsM5G7I2M2BumqE0TxJrBzI5FEDkn0JcA50xP4ptMT4Mir6RIY op9JQtjJx+V30QGdr89R0J0r4dY11DctRHa6k6M4vMrFsdLzygHuIoHWfTq+kKbiHT1kq6HPYDPV xexadZ1znUe1ColrsXOBa6VRwy7H3VZr2mazpO0c5ORPJhr8gdDgGkI0TNPN9xgCbLI3JHw04TN8 Y3yNPtlH06Am0gimH/N1p175U86UDPfu6XyT43pDk+nPcC8S1vV4Bo8vUurcdPbuhRcR0FO6/3Zt wbShc0oP1P/ypl8eopvCW5YNWHSj9P2ZSOsbcz7mOga+nzKO8zTNGnGpsE+1xdqvxNZL7W0bYrtM WiP9UdKW2N6X3och4h6ZMI+lygZ5vfKs/LVFscm0l/yuzCtHjhpWb7JKSvAFXIddjmoUQXQc3YVt S24t83V+sgrrtl3eIN//sXFBBPcsLr7AYo1ELoDwWlHLaFMkWU4oNj/AdhSpJDQV3rtqsxGFyZRp dpQW2yRmRwVMK+tnuJFT3KQ0K23KUUVWhln4PnsPjSbgjTdrEopt1hgOeyKB1/3/40F+32nEHf23 cHfe5JYGxKFNgDaaRJhUA9apqYHzWMOdR+7Q82wW1mGBz6MUpcZSA/c9DPc9Bved+9bv9a03AQa+ cWKXw8P764QRQkPVXZ4qi+7Sq6y8ZdMhG0IFAhQW3pN4Bo7le6yF6LfySLXMv4WxagjHx3uCaAar QamPkW2sthT6q2XDX827eXcxmgET7TdfpJ5fmDYtbMgQHkBw7qdJin+a594D7D2qtT/Abuog7adO QAGUsT+2v3Dmfvb511lZ6AAeM3QB3yhknuGgDFpQIRYeV7ayZwy3xiDK/2V/n+rk9LNOk/q/nKbP G0zLbwppMoAH/D0E9e8w7yDq/aiTduNZdHasMx9h6Thl6kmLy4l8K2wcFAQa6KVvjVLecni5pClu h2RFUYTFancRi5XZ7KqQX9QWCJn9cY8QXh2i+Xln7tus3sGeM6bO4bANB+t41UFtW5t+5Egbz29m kMyAd5YhnYUNBZrQSapYSmIpi6UilqDS90aKay0mnAuYTW6TXXxpRsc2ES/B4TKDZ/zgB6OA6/w0 EvYJm7fKLRaKQyLUBdfMAh+Nvzi/pmjwS9leYhMwPkZnEwwnMb0YcSO8j3lZwkHIzMnu4Hd0Ojjb fBnA+fxtxJ/JkjFjBWFui5/FLPISxxrHb9CVjqGOoW6pTC52lrsmSpfLS5xLXWudFjtTLNXO3q7R bLiEdIBlpPNil+1+9oB0r3avZYv0jKZ6mdvl6qEwSDyzAFProVjQtDjGucdRA+G4xWK12aH7XS6d 06nRu9LLvPvYFmRjeu5UEij06mnYHFZbwnCsQHnTPryki9pxhLUiiLcCxky4F+gUee0JLyaURmWl AnPCtuzycAMZ4fU/DTVhmEYRp6MdPbtxrAFRO7pBoCK5ZRSxPBf2tctF8I4V9O+5IP1l4ug4jSz7 uwBC3hUx+vBmBzRAqdAAzo4fdrhsPHLPJe7e2ZOsdpUnRfJuT59qV0Uf0dzdFXtzCbpMPaJ8yCnH u2ChaTDUuw9NwkxjoIvnflTdX94jGEGujiovZSdsz05U9p3+/q5LxjwknflxsPzm6V7y0dMJISsA 4JUCyIqVLt/hhS0y/Q1L2BEUOPmXRpK3LABKEpoFStfCNEmyWGXGrJpFlhJAmFCrIKwuGjnXRjFl Cc6IEeXMpjQk7DRhH2NvtC+wr7QrdgviATAYcoRwbv4feiHn38jCfv/Ev8kF9DZOsk6TjlSp8Gia hHo+69EAWkPlSPVaWdCoU90iV/gitKwlgQV4GCqVO5egQovFGFwNLdy2Z3C1xagwmxXVGnQsD4P3 RNCsMJt8b8qsr7KnqjWXH18f3z65x4dmvtnMRzPAmz/sOKt0c+IjhAdErKTcz6Keh1+T2L7XzmRB slXyCpBr5emVIBVi2Gnw/z9S3sH4pBh5wxgTdVO/7vfHQrGYLOuy3x6yx+StoT2uV11SKBSOsUS+ 4RntGx0yohOVidbL9DrPFN+k0JTwhOhlsdtCDzA9Epckb9xuDaQTCIC4t8GVHRqm94TGCeF/oPG1 0BpomIg3Gj+CNaA/tOjKfJrvTnMqqoJGpvqI5HVG/mbob8YKcDhHmvE/1AeP/BH++3SSrJB5mCri /z464FoUNTKE/2QaXUd7v0kHP9eS3fPK4ey+Lb+h+X/8kMau++qu32b/yN6g8+gjB7JP/emT7Kbd v6GT/if7z+xhWkVju6j959nPzLhfbgd/O1HpuNMon+GZ62fD9eH+y/XL/bLdAWzeRUJhHr4Sizdt AUuB20X1GNTpSUPEQZZoIkrxLxp2Juh/x62d4eD/jmYj5xsz4X6P0ptE5/CO6USdhPeNoEYE8XGA ICyZ9CCg58UTIn5nZXePvPru+m+zr2fX0Rv2P9owouct2VuVfS7vjD3zXsq2tz8v0Q0rJt8ccJq8 sxlyDpgJvVBIzxhJr91Fvb3zJhVcZZlXAPiGWw2LWGpiWQTeF6QXhVLc5nEATuyBkjAb3taOT3d5 o1VYn9hVWFIF1P7TXfklVcisijVyYGKN4+/tyk+bx3G+OI41P24MRaPYNSxvWOJS++S8eXkLrUtd 17lX29a573Nudbe6v3R94dZh8xIet9/jcXvcDqsX49KiQZsKRN/pUMJWazAUjcRRMtVmlgKGQiRZ KCgaDrvdLks87XoYLpBZhIjGKWGm0ThqFPI3U1X+9mpDomhB0coiqagw/N9S2eT3/6STUtxF/Leg PxdmRY6FQWhhOHLUznC0vbq7qIEKVfMSKF4FwAWk08CetbKibsNmMdzVbr2fx9sPB+ppk7AbLjh5 0Ui1BzrKi6/LyKvW4fDphQX4nlU63Fp0QpdAh3wpqRsDQ6UEc4nSnORmtv7gW9e/8fbI0roRHScP 1F1zWdfk8D/TzavvHXXfE9keyr7Rv7nu4Xfzi4tGXZttoj1v2dDXrrVfK1X2uW7IrDXc/5qM3Nlf gVP0YAGjZJo0TV4kLZbl4pJeUnXeAGmoNiJ/UMHAosEll0r12uT8y0pv9blSPBXAlQ8Yz2wUdzbS nY2SzgZOBg3Nk80GTjYbONls4ORTxmB+UqkzXcSKpJLi3u6q1MDiQd0nJSak6oqvts9xznVd5Z8R vs5+vfN693L92qJFxWuk9fZbnevdt+uri24uvtt5r/veQNw0F0bXZNobS0et6TKEZqQs6pUreqYx kJURZ9frYrfGWKw46OwaLymmxUoQxvCkYeYw4l2t8XhQEqhnBnhIgwmN8FUDII8QKqbMD8ojiotc TruSBDIZwwAujN9SaXFRIfYBpop1jeKKrO5OaKLjGBUrgB5haXWaoGNoI12AankVQWiz4evKb6ng 1njiYdY0KaNlXIm7XKwOjZOGk1+pLFqBd6JpSOg34hAa6D6oQDRyqRIUaYCkkZ454Kdh5DHwHPIX AjU/B+ei5iuDtFFD5iR/I4C7eDuBmMOoIi93jpGh9X194kzEpVyXFZWIdC/P9/Kib475BvyhIAow OL6OjF1RevKLzim/WT7/2UvHTO6fvXrs7Jk3fv+LJ/61Rtnn3ra1eXN1X/r+xJXXrzn9yGvZvz9A /6hfc/tlFy8aOGhmKjQ10+eJGfN/OX32W6tct92x6vLRlZVzS/vvXnLt4UWLMcCc8ypGc8v7oBc1 cisK11kcXQ4AEEPnkPZetEsEMJS+qCYo685T3ZTuppR3CPSJYecMSyy53MP3QjviwKed0MMZ7BFQ ZhZ7eANXtOx54JyzAtwPrqXefqzhc+5NmupfDOhAOXjSw3zZfHl9NqY4t2378e/m826GD8AxJz95 37Cl3RPliZbXLXKQK78gfKkqub9lsDzMssT9tPKlW3MQ5kG5R4tq9afhfJh+Gho5P40JaATbR408 brpZQyJIE8ExQdYYXBBcGZSCTgH+8atzGMomwmWEDmbCRTQ4t6Dxo+mm2YSbhm0ThkIjF8XZGgLc TTunElFHAwAxB1yYPoEYeJEBkge4wvQFBHIhymQ8cuOB6dnT7/w2++OCA0O2LX93j7LvzI6Psmee uIM6v5JGn9n5yu4rD4iKduC6RBmMPrLRC3MVTV6FApbiNh6QgdWiUKZ0/wh59UOeykr0ei2YlVdW FHVXaBdSKhXbujt6OBodt1putW50tDlOAC1wjHGg4M1uYbliACt1IKTCJWtrRZ4Ov7ZZrQmL4gfk B0gpwRQ/Y4oVt/oqYUOMMsNCZzA4FSj8K60eY6ErLRst2Eau0MmM0uopjN6JMb8M8Qk1PAlljMJ6 IC7ZCBTjhKIgNlm3y94Io8JjkyZeH82/YZ6WhTGJRo4jk8gjkFz6EKtcktCPGGMncYMSf9tp9UJn /G0nQjS4eIhD8FeP00oRivQWoQjKPVFtLlwzXsCURAJRRBaVlF3U/pvf0+XdCgq70g2vtgMWO/3H lQuWLpXLAI9xBYGpF5Zw/4J+aKTLSNpT5k2Hq0lvT7W3d3goGeIZ6h0Snkgu80z0XhbW77fc7851 pFGp02gkE6hSqhwDlYGO4YHxynjH5YHpynTH3MBiZbHjhoBbCfAY1guYx80EHUEzTrWQ0KDV1TFg VTIiRVVD59uAyFudLrfbgfGw3kAwFA6jOKVmFyYFSPC1w+vha2NSAGEIECSWoMRPUeCnWCzxQNgf CIS9Dqs1HvCi6fVgpEJC9/h13eO1OizhgOJGdQdheCRFCqP8zQpACgM8WNjr9SDRGQ2FovpFVjqW JIgDywC+BlHo2D2JBNJjkUgrvW2H6Rw0RCMj2xFYtkcj7eFRg2YM/PysX9AZXHKfAIqUK1PxRQgz 8vwwk6eKzwWd0LJrXUgSY1HDF6J1/gLEdoPYHs4TXhsvZDE5oBg7u5zjgFzo6sKeXQ5DMXASZ4qF DWAIn8kQPi8iTh/yy0gsqBqlj2ZveO2TomhfjDP/+vejU3ldP/9V9pqXsm+WaCF/9nXIau199/y1 SPq4PZr95u+3tUgvILBp2JCYMeT0E0IPqzmZddA5ewA5SnJ/gIVf7PKGOCj4heFCQ45gIfEFDr23 KyxwxPeM/mjIpVh403KZpYutu0ueRWeps+wfqzJGQEuqRbOqqlWVrDYH9LU1YbP7bcB1JNWKCO8U sFfsRV6EQlyp6rCrFCaA2ltZxLDabFaJQWu4WlnYsDqs4wzbSgD7rXS34UQRdoJI40ZjsAQX2t0G kiwEbJJDne3CLIiKMmETuL2FBQjvcboOJLkgZwRkyy0ACqbNFejPkUNU9nLWBuFR1puxQJYVURLA W2t5IYCOxfDmEIiWBxK1WBxWh7yv4yRqX0+KCkRhc6nwFa0CF4Q/CIz14x0RDvjVnzXGSc85Afew /u1vfkOTYwZdfAXN+7T9RTZPGpkdvGzZoo10+5ld7T837U8Z7GUz5BxlDju8GLrWZrgxZuQSOsRy iVWyWezWTrF2OYjLSe1xByQyrkJNIqXeLur6Ia2Z52T0MkUNok222GxpYMClNvov5JkSVIYsyrZS e14V5QuQ/71dWOP53zN8fC9+osQ1ldltcQcU+kt0N/SPDALEiNbDYkCpDnPUAvOJos5YUceSiJPb XFiekSdhZHnqEAWMTTX6Mf0M5M3M9KOQWoTjXIVCr0KkID1CguhCzvpARDnKamWFyWoaTlaDAz/e DTAAHct7s76yF+3dJwmrTbVkoIx9N+aSM7+Vo2der5e2tEjPTR+2bdsZbeY2POdt2dksjP7TyGAj I0sZynRFzRDNCz7T1BdkpRhhtOAVi9WKsQT4yfOWR2ZxnwHRAJ72JEeezj43xkEi2ZlCofZt9HZU vs3Wxt7zr/fvMWlVkp1NW8S9ao2QrGQ0VZcw+Qr1qgos4AuyVKyBNb8BTsZ583nrQ5MErP0fbkKT vYBN9ErSluyi99+nt2dn36OW4C60489ZzPiQ/StyP3BOKcqbogqGuA24iHf4sc4RbhI6pkDemp19 000cxxjW8aWcJ1+ImRH6sK5GudVp7RJxRruUObt0ASgY6BPr12VolwZnQ5c5ztldGnusd64pezD4 UHSrM1DKwzjuqcC9x1gy3no68mzpnshLpQcjh0t/H/io1DIwSDGM56SBaji1zgv/uLOMqBf3c+r4 dkGoIJwp71JVLVeXD5UvKZ9gqc9cZZmdWeJYi0EB/3L+K+PpU+Wist69qCpUkfSHp5TNL2Nled1d ta47XY+5OlzKY67tru9Q0yfGsUEOzDwPGqhS4aOJXKIO0KXywk+UwUmoIX52T/gejKvhfX7SiArX cFCJrSJPspdN1acSRKGgQnESEdA3naHQN2aqsEjmFMKBY3h50TgpegF7/sS9ULWuSNwI26bPWdTK LjdcJQYf25FI90hvTyvVkFXh4yNEencPjwPSPfk+wxlHWWd1WzXbVE2rEUWfNC7iVwwVhwu7F72i HlZZgVqrMhUGFbGyUGhqmD8PdCUehi8RPWOwEpYiS6z27HsOjUNq5HgG+Smu7RrOltiAkTOffcYj omMYxWQOGxFaCWmUJhg6butEaMSDB35A1MGTpmIeEPDqUJQy8A9K/HjAoJVciIAC8UMwgMK+UCqN 4mMXQBOe/cJJUs30vXO27x+y6JJecz+YSSsHrVtxXX5z+Jojt657doxuDRXuzwtdeXD+5Ip5s2c9 ns6/uW7wc6tHrRrldzmjRcW2a7peUN8UbrptuDF1WLelJ06vvqAv/ag0Ty8d2f2SxstHX/AzCBsj a8DTHEflYyBXGg9RxeEuUnopgxSltqC5gBUUoNoq7+K8BQUbC9R+vppgDUosR0QbLA3Oie6G4BXR OZarnbPc1wSvibYVvO/4IPRB5FPfN6FvIn/JP1rQURBJKN3d3f09lFq3oYxwj1GuUj7I/4f8o+7Q Ay4Z2jWWByNsC+S57OGiI3aq2w1grSvtslnRYhdcahfJOsA3PMMishknBBcJQIfzKRpHRcjC9xjd OUXti4FKEsF+RBZBTKVUzFgbRaS5iTbTE1QuoLWYHwkDm5HZ5NYPjTNGPmcwKpiFiiCDejmzwGcG s+CMH3CqaJwxgvzWFByFpZ/fgkbiQ/r8JFQA6yA/iyoDgLoIMgWnYAFm4SyEf6I+i/MKosuFpAlD Ays9iCgBnOkYTFQiIaAEK5hjxmjXZ1oW7rhye5OR/f7l/XNZVd1dS55/6tolzyOt9Y87R9/5xqLs d9l3H6H3vlJ326E3j7x6SPgnYzq+lI5DZ0XppFxMUeVa4aZuO+Vp6QXQf7I3z66F82TMshTQLPz9 NfH+GlAAtIEpYslTKZlD77wqwACMicD4rwYx/muI1UEL8gb4BoQu9V0aavQ1hh5iD0kPOp/Un4w6 LM6IbQ6bLc1RrnUscK50Pu3Ybd1j2+1wBJFm+QuTXIVT3PPdK9ySG8PBnjWu6yFy5Y14rI1Inh9F ztxK3G4M1T77jHl49CKXhXe3qzAGI1NkzxTAf4GHaggSGYI+lwiqRAVVhuYFig5rtECrRUmji5+k 2fhJmlCxWs9Y1cFcZMtzoWZlyMLcHAhiQFDf+uMLT2aOLxTvjuwohr3oDcfwTyAEoFw9SsAg38B+ xWjXs2gAp51UsyP/uxc+yP5z4Ve3bvtTwfbIiknrnn3yljl30NWhFw/TfGp7nrJV2zfH5l79q7ff PSDszGDQ7BPIJOoYaZ3xpI3JzmJnlXOgU+nl75V3GRtvG+e/NG8mm67MsE7zN+a1Fbyj/MH3UeQz 32f+70J/jXwmZC9YUJCJcoEdHuXSi5qSIme3YD/WyzmcDXIO9g/Nu8w2wTnT+Zn6RfBHetKl04Dk sqM8LgZ+8BAIpWQPV/LCcXexrh/xUB1FzY2elR4IJ+cJU0Q9Xi47gFBhuLii9aicgzxCZLEXATvv cY+L9zi2vxVyisYPxsWcOp7F3qJXUHH6idahyZxEo5HnjguWE7paw0hszpCCbMI0acICaZF41Zjz ZK2haeTxs/LFJQwZMHinKFU6jtwfvuckjeefkr24PoZCNgkGqcOolrOSJvWdcXDFH66d887Njfd2 39WeeP7aJU9tuWHp5jWPbjj9xGNUWj/2IuZCHYn3rTd++eoHbx3kenQ49GgcchYAzS41QgUkLwDv vEFpsNbZZ0hzlfnWGXYLwjk+U4LoiWPGON7Kz+PLEu/7yo/+U1G5p7dfpGfeRd6R0YvyxnoxdjsP kxZGp+YtVZcGTrFTYR0T4bmdodCYIEc6pGCee6O+CYOCdDmWZ9PIPvYsH8LWqc/aIA3od0wCQe/x QcJDBmDxPwmYBw1zkB8aZo0GGm2GtaRLVTMKeaIF2NpVnK7ia+MibmoLaEGwUi/SjKIuVZ2UQsIX 1DEphRdB2xQwDKeGgIk6Hk6p87ViQ2Zk+zGkDhBHCHRNQCi8hCU3qKymvcmciINDG6JoVWT3O0XM TLL4taRAV2hSjFRSpSv2lX+796vsd9T/pz9grrgzX9p2rp62of0DNtbRd8Kty7bSCaEnWjA6TMLE bKXZj7P/0hPb982i96wZMOtpoSd9IOJKYL8h6jTifit1R7pHekQwFULkIcfDzq1OS9RZ6myOtEXk CO+R0mhBVb7FKTnceTYaYBm/T5ZUYnsMM0p0+Aw5VCxjDrK7oZh4N/bsW8XXRiavoGojoRGDC0rE cEJQcoFXqQi6CrnokHLhTwnR4QqY+Dnv4/fcUxONz5G1FI0fxTgw8kQ4sp/uI0lyCjNxdcZnOVuD fuVhmV4DvOU4ig94mIbI4TjGPYniNj/Gc1g11QI/SUeCgnhUd4wil9hlFabjgKQs5O5zZS/MKAKz BMXGUc4AH12587HHfNGbl4yYHOtbMW7g4cPSgxua5lYNvsz7iG1w45UbzlwFmbg4O1b6GjLBx6LM NxrtdsVfbi/2j7AP8qvW/Eh+uT3tL09V23v7h9kH+ydoE+2z7D/a/hFwdUuVl1yYurBkRMnG8k3l Wu9k77La8sH2wclBZeOT48tma9OS08oay1eWf1DyZfLb1HclnlBQDbSyHS2leT5N2BI9AYiUW5KV pI0cQdjSypYbFUpents2qDDPYQsGKosrbcXh8JEQ1UNGqDG0MiSXAwxkdeWimjYkFJvwK4ViCwnF xgfWiWHuX5uKjZ/FB9rlFBsaZ4xhXKJDi920mBQWFL3iPuz+xN3hlgvcte7RMHVCZtzQYhj2hVFV WAoM0xwmyverde5Ipnxxkiu4zKjOch0oOIzD/Dcd137sFGKq4xAdMajkmDkHDNKTTSFeQivcyBKo Ol6czAmIaMgsqDp/TNJV2+0VAxYvXxd20SXNH5645ne377/+6Rkfbvqfrx94evmyLduuX7plYnRs ccX0SX2ab6M1H91P6Yb7V56Z88Phpc9JXX7X9spbv3r1VxxLW4sifF5j66dT92KCirZdAeAePHgR Tnax3AvzCe5zymJXv1CkKmTxODx+CRinO0/R/CgULrYalb2rOqy0zUqD6GFWF4QKA/hRKpZ+LiAI Yb8xPLzjMGwCnWhFql7sRaUMFxWrn5MEZ/3AgxC0UBAttk+hBgaNUQJ0DlX1rmoOngiyBcFNweZg R1AOMj9iWC6nOp7hBN4HSNgReCEydv4oVCpvGCEhpaZrieJFSGhniv9H0yfEwGvcB5M64uZkVGAI yHg2ruBBOgSQBxY5wpqCim2Oh5ouIUdQhHS6VJdW7FIdMeq0QC4xyD+TWUVQKmAWOIKiSDageEIM DVIDnrUtN7YteWF4y7Vzx9xeA7fw+7sbnny4fQrbvPaGS+9Y3v4SZHIdCIVD8Ps0csi4wtqbv8Fo 60brJmuztc36ifWEVSPWAusCzKP0WG7XUWuH1VaA+UAwJyNm1VClGxHrKxgZpGrFmITpMXmT3Cy3 yUdltU0+ITMiJ+Qj2JJl019mdWjk+g3jVEAyGSUwWArNhmOmZkPDzDegcYbH9hi2Mcry772HckeR b8jNp8QDLm4mFjZlxLgeWPJ1LS0t8l8PHz4dkNOnP4Ba73gcswn1E+/sJX8wBgGrUPrLlZiEVAlZ FEWTZSYrPkKddib5HZgRxq7xN7SrWp7HvREaHcgoRtYX22wb7bTAXmsfbZcQafxo9OGcYDdLrESw YBeRpR3+CyIQDBvB0sLfA9MegBfsEZ9/W5K/0FmpFp4K4gOgOxxGbSK1I3lcgLcyS5BN8LSycq1u QZIBxcgui+5OW3TMemR1aTGUFXOO4NPwVAZoHy7vIvOgQeTXtGRnFfYu6NO7pfKi+4bKX/3ud/+6 4QHX0Lvlyac3HRw5ncsreEH6Af1iZ1ONGI+QYbPVCeokq+R2/l05BeSxc+iLmTgHFm82IFxmA6L8 pSES73XSz2zMqyZ8At08sctbwtHOEy1Ye5FTxI6k2GHcgj2qDIRT7WMdAlKoXW0TbT+TrrV9IP1F 1Z5WaUpNa8WWarWvtdY52lkv16sTtXrrcvk65QHrq+rv5XfVY+pX2j/Vf1kCXhsKLCWZ8WpLFFva kCKxFJs1lqi7LDbrLm1gWJknPGSMHrNAYgnmP6BuDLQGLwJjKUQuw20kEyI+EECAFt0IF8heTFgx 4kUCdGg0JIfXu/YUsi8ozieHgewLTiYIEiHrIqDAPI5c7iMO55+TQ646n9Z8ADLPe8D5wThsPm7n XD4dDioy6ADx+GwIWIdF/aUGsltqJLHMJXOdwzHcw3qLxDDCgxf/IPoA/3OMz2Ytz6+2WjBXAkoE Pt6Zz8sn39mZEKsdSQH38RkUUHvVhNIdkXpXO9p2JkWR0M4gX328UxdFl1iJLYdY7bCbP0bGHsqK 38r7kUwt/iDu5vfXiAXudWpnmP/4mx0x83SUeJkYCAaVN5llmZiAKYWyzHUt9NmvsnPoKx9nN68A xL6fNmeXtE9nBddnL+d8eTMWfYS8/mWPIhQUOKhtV5++ZsF1VS9z3aOnuTbnhWszimFu3CgKe0z5 RJFHY3FCkQqUBSiR61AwUxyfOctU8PxKQtEH4Nk8RmgbAk12vrbnUT5oy2VcAAI5IMGktemPYW42 ULlTZaHR0Zk0zekuMkr+qe4CqRYKJBReGFdZfIv/8YLVmwF3mvko2FA1DZ8pRV/jtflm1RKwZLMB kXrPGGl3VhXLx+Rj1j+HPksof1BOJVjIkkhZw7GEVZJS8Tw1wF0KjaopjNazHSmmG4s3FbNi6DFX 8UZMhiOLmA1FJiJyA1jH2drj5wyN0AwzCXH17GGcqT1CjcEthA3FMbMuiMdvuTiGNhiOcPFGzMIm LhfjxllcLiYuh+1vDQ+/XExYyZgIvbE3axrnGBAetQ7bJv4Xa8X1goRVporpEQLZ20RYAQafjoa9 4r8xqXG+/AmNS4JC/vhVcmQ5afiFkyzMCAB9IZJFxa106a5/18CcLhibc6yzMBokOQ/ww0a7SHEB n+HOMzxoIcQQV54+7TTUSNml/Q5PjHqdgU5DnQteQN8A956Rf8LCNNfCjz7fcG+ueHrOkvsKbnzj 0Wd3pSZfuOAXLROnj1jVT07fM2rKlRP3bd/TXsIeuXpKv3uebL+P7Vy6dMyDd7W/z2WF+1yfg1+C dLnhUyTVx7borfpfpC98J6RTPhW29IRRA4a5Tqf360fCR8MdYTlh8bv8QS98LqoGnTany+EqCgs/ Kyx8LrvwtuzC24Khy3lbdmG67YWcmAJoE96WXXhb2P6XSVC78LawfQojTrnpEw6dnXYgsTEKiTsM NuGeV/hEmC0Ibwo3h9vCchgjPANBIZunMLmVKXnnRPB8h8sUwXMOF1xziKHpcJk4H7+F998duFEh MU+ZkDe+EKkCge5CNZ3/xyfN434YbPBZLyyoeqw2i03D0AE9DXwjRt02b47IfAgP1GlDk6ByDssV hDVJvPbxaz9q3DxGt7V0mXvJomfk9H3bBy0YWbG8fRFbc828i+5+qz03zm8g8IMS0NFJInTungDw E7XOx7MGvIGKsy+NRbwVEQe8mi3iGKJeYpmg1ltmqrMtliq9n7dfsFd4kD7cOzw4KDxZmWwdpzd4 G4LjwvOUedbp+jzvvOD08M9owKoqzsslJKttlzuulmYoM2xXO2yhPFnzQGn4i2Ii+okJRtDgm5mw jiYAnRwYyO06FzgcPiGeTzQ4JUSDkx2NNsNXVFyF4QtE07UEYJ2en0BL8P1DOZyAtquIYNpGkFuM qMXURNyg4iGwFDBCTm6FBuJT7oHSBi7JFQIjPaMcVhDZpRwBjwNUaMDEgufoKWDW41C2HPPhhst6 qXKp9UrlSqvMrRM/0ScmNcGMNALBOz8sGvjkrb/+kAZv+Ottn2SP7925ds3OXavX7sQk4SV3LMn+ uf3QX2+icep86823fvfrN98QWPpa5JSSoKEXc7Jcadzh0LvqF+jDdbk20ZxgBYkyRyq/IlCRf3H+ gsTGhKVfqF9sWGhYrN5yuWNyaHJsjmWuY7Y+LzQ31pZ42/9R+KPo2/Fj/mPxo4mORDAlZ/RMoJfc T0eVjD5J/8z+1/ysbve4AAFxCF0NAkInrkjRERvVbYatEfleOSGImBAEhe/2OeYxQm/bBCmxzXV5 brYnTk3h3XEiovGlkeLdbVtMfZWs0ltMyH9GzjsBc6GRc4C5AIzPAuanhEYW2LoJmIvaMqhJMDON FAAwp+cX15jKGID5v8PliIy4THJ924mW+zoVKwquxBQJJR5Mr3EWxVv7ZL+7Z607MufaT26YdGc3 z9NLlj73zOJFO7KzlZfXjx27oeP+J7KnbxvRr/209OShg2/+4c03/shxvEuys6WjoKFO8mhv4w47 y7Au4f5sOLvOodYGaiPDIxvjm+JKla8qVhsf6BsYA+wdm+abFmuMr4y/o/7B+7n6lePrsF7GCh0Z VE73cgxlgx2T2Gz2vuPD8F+CX0U+j51hbsxr448CZ3WpfuByxBVyVWKCIv2Im+puw93oXumW4wKM wBRBHCIQYATUQA5ldQswwi3ACOyFMeWkdAe59ePKQvgi4vRaoT8We/43ylrEBY2jqVgKHEITIqYJ 1FyL5Md/ikD8B4S1/SQPxf6NMJgVFPMbCjRcYEaAHH6CrZZ3ua/u5ex389++8ddNj7cnn1+66Ont S659AullS/9RtBvVNmVvfvqOHwdI2w4d+tVr77z7GkQLdm41iPMq6OIhrxv9u/uoLtOUXCUPwH8o cZW8WFatHovVYnX6PFYnwQyvdiEUxGYt3Ygx3YUYoOZjhZ7/c3x/1uP7wfCcF9+jUFZYo/P8CsHF PNUNbWS6+qO8QzozCEL1wKTUwJ1oOLmQj5TlXAu0TXgLfBaKtS4xyKJhIR/pbHoGJq6G0Z6e1Y9f OLv28isuvPji/lf443J6c9Ml/Z4pGVLbuLD9HbMfapEb2IF+6CGFjBvkQn9hP+sw68CiCYUzCpdZ 77DeUvS077nyA5LTGoqGQz2Gl78bUmIYN8T0CmoLT7ZMtk62TbZPdkx2zrHMsc6xzbHPccxxtqRb Sty8pLGorHfRJFu9fXp6euni1GKUFf/c9rDj7tL7yu/p8aRtq+OJkidLd6V/nQ4ioW16pIWdjVRn o6izIc7h/STO4Q1xDm+Ic3gjH0GH4Y1XT7KUFDtscjSRDsj2bvlRng4qjJTz7i+I1EZGR6ZEtkcO R1R3pCAyP/JJRC6I3BlhkZdBnQA4Q6DeBjxzBrAbw2x0/K8gKIbRMUssDM4uf7CKrw0+Fo3SbpPz r85n+XkBDd4RT0gLgIIPiwLiwNWkj2tBOa+bvQAVq0URwxeuquA/7y5wW+HncjsMDBcSg2WC/zKS 4L+KiAAyIpDvCJLZO7WiLvjp7rzqI10oWp8LnYuGWdUtGrwf0Ph6DxfVLlFxqyRw+MaKtgpWW7Gy glVwBL+IiHvmpotNmL2MSgve4A/AG+a8pYkit1DCbvF47oTQIDyYwSNCS4iRWDm4sfCTzvA20jMH 00PQc9AUnxRUR9HswlG5RHgm03TefBP8CMBHnFR7vAl5MQ5mLBTFtHwF5xj/cslwIBdGSdd4CgBw 2qN7dZ8uqYXORIxYS7UYVbpiEfdjM+lKxUghpoe0lAHiKC2x2tSMHCMFej73t/jkvjXmgkeimS6Z VasAh3X+8Vl0MLro7GyNJekS/H8qVcikc8f7/CJdYKN8bAJXU+nane5bb1i2tFfxz199YPRFfbvc denylyd5mh2LZi+bEwx2j93yyn0TZr+6/PD79IK8uQtnDLwgFS6uGLpq1JDrSgsyl9wwMzxu8rg+ qbx8n62o8qJlkyc9dtnzXF8VdXzPuigPYG4wjLG2gQdTaY5/IJeCxkpMuokks41KJKhj9i0bzLdk d+uFGOTg9BY7aIdmGWQd1KgtwMjPjZpM4D9twhDQNu2IhjnXATbzAA4NPq2waHwvSiSwh8dlYs8P gtOwh0OXpmfG7T9aQnfhgOlbavvYHFQ/9t4BrOIcTAlSiomkAVUe41oeGTQMjYf5ReGpmEkHXlZx iPdfuhfPEHj6QJelPGJ2K6ZHR9RceXX5Lbfs2r3blymNb35Mv3DG42zaBqpdnb19Q/vPR5ZjakvE +dBlR/n/J0VH7yVR9I0VETxL+IJ8iMUJo9Lrr8r4aJHFF3RQX9CO/IoH3UQqg8XhEA8roiJmCYlo JeTlahv4O8JP3gMhEa0I+F7EKSE/7wVs51DhkAg8sX2Kl5SrdR0h2haioVGYZgxTx/MQJXoiyhZE N0Wbox1ROQpomh8R0DCfGTlhPWI9akW1tSgJEPhzznTkUGlEKibqbILC1v+vsWuBjqJK0/feflVV P6q60nl2J915dCfQDB1DICYgqcSEABlMhIhp5CmCgCjuJMKoLLRnRMEHzLjnID5GHGd2RWdn6HRC HuBuGHFQo4yui7iLoqh4Bl0VnYM6jJv0fvdWBx/rObvp/P+9de9ft6pu/XWf/0PMUWSxKCxfkf+d pQF0GFwVOspNKX/zhz6E1zu02kXfIZb/Cqyax626ubwoN7KBCYnV5SduyWsuBcJ+BgZHKCKzv1mO l4MV/1yxVyaWBi31m19f+us2zdnn9N505ZU7p/c92jf7xrapXeyB0d77L2m5csGu7ayWL5vi/eAl Wc7i/Sj0o4zsQK5NIopkp/aL4shlnAFtsei3pZL5IM0/MNVGSYm3VuEtvNtbK2PCWS1xBCHej3oR okkWISj+w5CLiqtJBRCOzhoy1nRIDhCOThpbKibDkgCQ6ppAKqCiXkumKrNJi7IQdpTiUqe8mq5m a6W18k/JJrqJ3Sr9VN6k3E3vZndZdji2S/fIvyR75F8o/0yeUP6FDDh6lBfJH5WT5HXlY/K+8jU5 r0zC4yh5JEepINwkVRvBYprN0HOqbWCm6szKG6xJE/7oBPd0HtKDaKwVbgIc4wCsO/I0MajlQtoi ldlsLieawNipKCS2Aceix6IkdlFou0bBamRYVnyyrGCzEGuNQprXBu1wrivOhTodEOMk1BaD0GKJ ZBiG6duA+g8YWNSCtQLqN+QQM2iJ86PX+NcLpc/RJaNLCvI+OcO1NPC51mIyy1tNvgHOlxe/kbnF siGaTiGf9A3PmbLTQlQWMrL092Pr//VMGDJnHw+N3WSNjN55/YaOjWy7YA/wB5d9HQB/6NbCcX1l nY9QRQtkioUJjAo7LswKo3eF9gE3MOwNcYwMyHahKUMGulce8xriWPFaKAzbOlDfKurD7RKyhS6Y dIWPK68Q/MssQuEU9DzHjmknjmnHhepyRsJaPB9/NP5B+PEV+uhE6wSFzfVe490J67DoFsVchxuw FR2/GUGxnxlysLhaC0AnDN/3Z8ZAsKzaanfJWXa/nK/brMRqd0LPWtI1kmXxOQKS31mIuWzYMVGK eqrJVEedNN3TZGmxG455UqvzcrXFO1e/Rp2v3wCbodfrt9pvc3RLQ/aDar/+hf1rucLprSAV7nJP hVqux3yXkhp9k3SXtMfyoOtJuo/tc0JshvTbD3pewNr3f8pnrWfVP+vn7X+TA06hAeYSWBPYI7Aq sJ5hXL/iUa068UoOLI6rYQ+fznkcFjd1hbHnf8Ko4S2VG/w3kUfg9c2XZVec3ogS9XZY5yuLveu9 m733eBWvYgU38tdhvhg+uP22MHsMytamGg0kKPEzRwDAfgObfFzI3WGDZLKEuYqiQSduMN0K2XYd 45Y5xmpF9YSOeB0wkeDV9Sh2A7Ex48F7Drs9PmhLS1joiSoSBKAlLvme+VZg1tihWyXV6/K4xe3p aMu5ZR/+8ejQofMQxfel5qbchEjCbXEP0icNJdSm0A3KVi4Pza4yZFgH3+DdCnN9/Mip2ehysWYM tWr65AH6ZdaX6BghhJs/7/ySJXmwmYB//pktyfthqffMd4cRP76+/4fQuwMy7xy40C6H1mRwQWef O+QKsWdgmpACPOlX+0ilGoJy02khJy0UIFqT1Qtgh0FKv9rj4AZc463JYkhWTxHi8FL6dI8jZKbq SOUm14Z4Qf0YDqJstFevphyVvMQUuZRxI4i40sXCRWn8vFxxnhfmLpSQNcTtmguJerF74Ekf74dh vUkAfOA9WXzZP84/ODEOhNY9YkLTm0vfC6n7rFwhem8pt9DWsUMHn6q3TnlqaO/Uy/r3j/UdemrC G2hiHjnjHWE3je556Rhb/fVJtvnAf78i+iIVfdHnaGs0+lamL8pWqdMOix0QXXCDJ1UxLldjUPbn XMmtdPkHVJ2qEHXmGyJGe37tInW3dbcEM2HqYdth+2HHS6qsGjm1BZYsOdtdoE2ldc476E6nFNOv tsYdcWen50G6R9njHGCDrhecI56XtZOW1+V/c7+pfaDo45+X00V0r5rnxvAC1zmLzW7EVDv2fwlc odj5aiI3KoTayejbrLbDYDekpCmk+7mgP0Zl6NXdVFXdGkyBYIzgtLg0xQ5rpYp2lByVmRYmso8Q yPS7j2JnKuzCPqXLArUdmMG1Y+0FRr2VNp3qc9xbXCWKusIubzEg7O8fMOzt9oQwCXi54QlZtrCS NrTbc7ybxYR1yXmzw0B/oX0Au/bCOoXZW3AsZMozHQZ3o8HNO9eq6t2S4FMTPyc9x5kXu1ToT/g2 VJ8nr7AWy79vG85C2ObOhQXvXHGMjSYo0EIfK7uWQhhdhpqn4BWguFhCRf0siaPTmYLR+bSaGr5X ZCmnKr1z7KF3fz05MCnc+8bYL+i9p07WjX3IKujYhZbKxilfj7lG/0TnxseW4LmKIW/yKXikgH6V 4ZFCxafCcWIgX9XtTnuWoUP6wnCFMrySH4sWnCrIO4ZNEh6IyTr0F8A4vWqAon1627gxUFvhW6ju V+BiwsALCVVUVmscwTyjnuPO08ud5a5y9zTXNPdUz0NeZ4VekTU7J67Hs+LZa/W1WWuzb7VvdN/q vc13W/Y29z3e+/T7snb49ij7nM9oh7wHfR8pf/Z94R7VLvjSgaJxjsqBuoDfqjapd0JcJP/i7ZuL CabyJVcdqoGmEJR7dIwe8n1ZWWFd8eEARv69rrBTwWRYgRqRC4oh/PlJQAuwWGA4wAKDrP6Airow fIOsw3DW64bOlunDsEMxSBv7VVpCmv1oGjvM2oJJrkpXm8vS7kq7GExENvbGIIOJMvr8oc1oGlF5 o9w2JJiIm4bM086fyed+MD4pgJKXiMHsBKYP4xwllEHGNzg5S6HRA/+g3fOgvclDe3MIVifOEmf6 LG++Mmw1RHwwX1BTq8CyD4TVzx7IhsKwqRwM7kFbA0UHsE9WOV//EzLWGY0fDGMwisBEZatv+qQZ s3O9EZtz7MZnT0VLgtH3+8bWN5RVbl5YPXb9U1pFmf8GtdBaMfrQLXds3shu+PqF/Y3xBXwcXIG2 5zj4ykP3G24YhH9RYjqtMlV8/gRrQbnVdCZGrmhTnzXmIjKBVcgxDVLpyhw6i82S5sht2mLawTqk RXK7tp6uZCux+HI77ZZul++l26Csd4GeZ/58KUInSFG5VvpH6Q3q4F/LgJZdzdDAYhhy3CjFdJrV yQrDTneYMqibMMpNhbIVXEXCrqxwE/Tn5w1Z9OdRjwLtHrUP3aHNfohhYxUuM84bYqcM632PQ8nE Y3iWexKezzw2If+PBUFI1XYTZQul+wltg28heNIkwsgXyVe17mLebHDZhcxONjxo/d2MM7AoxF/u KF8KmKF9gIniB0LYMjPchM5PxoAMFuH5F49G4gA0kaEON5g2a0/idYmjZwd4LfKqFITwvCB0gXgf 93ZKFborZnB2wI+95xz/ZXx4lsrlOVDXzKll2JNmBTnfNCxQb7GXmuot06YUZ1ew33R1jrVZrhv9 w4Zb19H/esAi2R/YNLr0dvkR/p7xml3HfOnKR5epM76Q/BISCHlh1QfvjYdckgTagnwpDsZ2eCr+ EDpmjl1BLtfI3/aPTdHqLuaY+YT82I4k7t+UvUGWwjvSIqxXbeZgKSQG0p9GvAHhQU5j7SJXAd4B zAAsBBQAeNo8wAoAfOiSq0A7xM+1LUyP2haS3bbnyWrAY4g/YX2f7LPXkhtx/BvQDFsJqeE0OG+3 /WmyB+mPIn8l0h5D/FcIF+OcykxcdtwPf88LiR1pE3D+vYBya1f6XZw/F3AXymtHOAvQirwshI2A u+nzZDt9Pv0E8hGSn+Fad/N0QFMmnI1n3Yb8epxXhrSfIV6A69oRqoBiAL43eKeeRu6BZ9JPaSNN 0U+ZzirZGsssS591xDZoX+OYJVVJ2+XXlI+dBc7bXO3ugPugZ6nnsBpQz2hrtJPeK/R1etI3KzuQ 3Z9Tl3tz3tH8ovxkwTr/PYGlgbHC6sLVhYmij4InQ33FO0tuKs0r08reCy8Ony2vLk9VjEz4/cSf R38yaeakZyfvjlXE/nqJNGVmdfvUzdNuNt83/LaCV+BN2oYdAw2eXRfivbnh89uCY84ReoYH7LB5 Qjqvbm+5qina8JO1K9bP6xAUIEqXc5tlP/D3Y6RZUPK4L/DvewL/vv9v0+v3t31+mx6/K8klwtf3 tz19m36+DdJIvufhG56t55ErsM/eDl/G8+EFtgNephfCD20nicND9zXwX7uEkJ4OtaHEkkvOAdIA CwkCxwBtgGWAXYC9ADtRMykbEG4FDAM+A9iJYclNPTDFGERwrwh6162vEocrzMPFS8Rh79VxM5x3 pRk2zTHJ6kyyS6rN5MmNZlg+yQz1cFUChfcq7qrDDZCRJq8CGLkZmLLn4PqCwvPu45ZskgQwiO2a KYZF7y2LVO0dtlgJlPww/7yOBNOHLTTl9lY1KCzNzuG9Btmn7BMzh33S6/FW7W2Yy94j+wHDAAt7 D7932btkKzsNJtCA6wF7AcOAVwDnAHZ2Gr938HubvU1UdorEAPWAZYC9gGHAOYCDnQLW2FucpQTm 8XoAY28Ba+xNPNabwCo7idhJdjJ9mP17qqa2akhEorFMJBjORHL9mYieUzXIXktdmBAcZO/3hqLB xxsq2XGSBICPgTVACNAOWA64GWBH7ARiJ0gC8HPA44AkAOsBwBogxEYALwNOwJrGCbRyJ1DGCeiy v5rCZQbZK6lIY7AhB26ln8cSaZAdY9wtfJC9zI6K8CX2RxG+iBAu7tkIO5oqCpIGJ/IJztEQaghj yLexP/SW6cF0g5cNo5KCwDFAPaANsAywC2Bnw6wkdV1QRyGHyAha9yBLkQ9F+E/kCYkY64JG5HLw WIijSN1liAHtDe2NMCOy+yEcchTZ+QBiHEXuvA8xjiK33YEYR5H1GxHjKHLdOsQ4iixahhhHkbYO xIAG2WMDZeXBmrYbaKhBZZtQS5tQS5tQS5uIFV7L8SMX0BYG2SOpiRNRYw8b0QkTg4mDNPEMTcyn iSdoYhVNbKGJO2hiBk0spYkoTQRooogmDJo4BMcglCSo0fedw1ojjyZGaOJ3NNFFExGaCNNEGU2E aI0xyIpTc/BhIWgWQW8D/65Yce9lM6tU3GMxarQYbF2Mz34Y+BVAWhwZIAqVmMT5RTws6Z1Ybx5P rqva0DCbHcGJR/AajpB3AFa8oCNgoyMo5AiKU4HrAcsAhwHnAGmAHdQleI5dAqvAMUA9YBlgK+Ac wC5u5xxuhZENwPwW94sbiwHXA9r4ETuCXwl+xawYhn4DWlSbbdmFcX4RbStKF7EakpODplf3SnAW 5u7/yv3Xr9xEbpDZTrYLxpeDcMZuhrtSFwrhIWdPKnIo2JBNHyRFkC4LwjlAhIYRXkq6xPFUEpB4 ejUJsN8irEoFFuI0NRWZBFcCHn5Wf/BC4EzwQ4zIET0bOBR8IzRopang60j5bX/weGBH8MXYoISU ZyIwr5AKHgwJ0qHApcHfjQjSO5DxcCq4hQf9wb8PtARvCIiMVWbG0i4cGWpwfmRRcDbKawpcGzS6 UGZ/sD6wNDjDpJrKz+kPVuIWomZ0Im52QkBctLRIFHhVzSBdY0xy7HZ0QktnmqPKMclR7Ag6Ch1+ h0/SJU3ySC5JkSQsTVuhzEwkH5f9jvL+0GfXeMA7eag8i7iGFoaKzpC3a1SCei1JZllaWeuCRqj7 H15JWq8NJb9cUDpIlSsXJW2ljTSpt5LWjsbkpdHWQUd6frIm2pp0tF/T2UPpzjhSk2z7IIXP3EGa 5knb/NyjNVS4qHfb/X4eVmy7Px4neTkb6/Pq9Zne2llNP4CWi8TlTeOzU4QY9V78y4sWJne3LuhM Pl0YT1bxSLoQSy//wF1eD9G/0M+am4bo5zyIdw5ZZtK/NM/n6ZaZTfF46yBdKOhIiH4OOnAMAtBJ RSTE6UhIKjLpHjbpwjgfdGU8AJ0sk7CgC8uyoLNSTtfTVdbc1FMGBJrcEOkSNF25oW/TjIRBEwYC TU6CjAiakZwEp0nOFMUEAiApAgIJLSABQRKgBYJE3HmPIIllSHZcJNkhrmQx70bQcIRi3KfHadyn QXOxGv+vyKpGrAf0To+vXNwMd+HLS5tXAZYn7924Ji+ZuDYU6lkZ5xnw2h1Zfu3KNTxcsSoZL13V lFxZ2hTqmS7O+172Yp49vbSphyxu7ujsWWysakpNN6Y3l65oive2tFfXfOdaOy5eq7r9B67VzguD ZaZQT4s473vXquHZLfxaNfxaNfxaLUaLuBYRPN7e2SORxjjmQyLshWEA8Otyf3G8MUe7eaZg3unF eVv8BzEg2UeccOPtguN3N4Dz9Y8aftTAs/BN8SwPktVMVt6W6cX+g3RfJktDsre0kUS7b+m6heQ1 r20y/7vwh6TuW/jLMHGUp/3gH0ia4d69qaubwMzGRMzV6zFX73E4kLq8KY60uvE0p7MZc1czcTIS 6zihxXKRkKfN4GmynCH839wg7gnJYqUxwQ71UqOIdpOuuCVZ1NrB0BR0LEI1wDf4QQyXeCfRBYGu 7i4oL3WNl8afQ6xCIoHgkbvGofuWTCxTD92ZUJzIT+kar47xoqK8lsj/AP8um6AKZW5kc3RyZWFt CmVuZG9iago5MCAwIG9iagoyNDczNgplbmRvYmoKOTEgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNj cmlwdG9yIC9Bc2NlbnQgOTA1IC9DYXBIZWlnaHQgNzIzIC9EZXNjZW50IC0yMTIgL0ZsYWdzIDMy Ci9Gb250QkJveCBbLTY2NSAtMzI1IDIwMjggMTAwNl0gL0ZvbnROYW1lIC9YV1BHVUQrQXJpYWxN VCAvSXRhbGljQW5nbGUgMCAvU3RlbVYKMCAvTGVhZGluZyAzMyAvTWF4V2lkdGggMjAwMCAvWEhl aWdodCA1MjUgL0ZvbnRGaWxlMiA4OSAwIFIgPj4KZW5kb2JqCjkyIDAgb2JqClsgMjc4IDAgMzU1 IDAgMCAwIDAgMTkxIDMzMyAzMzMgMzg5IDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1 NiA1NTYKNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDAgMCAwIDAgMCA2NjcgNjY3IDcyMiA3 MjIgNjY3IDYxMSA3NzggNzIyIDI3OAo1MDAgNjY3IDU1NiA4MzMgNzIyIDc3OCA2NjcgMCA3MjIg NjY3IDYxMSA3MjIgNjY3IDk0NCAwIDY2NyA2MTEgMjc4IDAgMjc4CjAgNTU2IDAgNTU2IDU1NiA1 MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1 NgozMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCBdCmVuZG9iago4IDAgb2JqCjw8 IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1hXUEdVRCtBcmlhbE1U IC9Gb250RGVzY3JpcHRvcgo5MSAwIFIgL1dpZHRocyA5MiAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFz dENoYXIgMTIyIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKOTMgMCBvYmoK PDwgL0xlbmd0aCA5NCAwIFIgL0xlbmd0aDEgODY4NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAG9WQ10VNW13vveO8MkM5O5M8kkkwyQOxkCMTeYkIgkMIUJyfBjpIYfdUYamUCCSfgJ CFqU+ojSPFkDtVAMdnW9tbQ/vr7Xn8XNpNUJakldldJWX9EW9bXWR6n9ectmoVWKVkjed+5MQqDI 462272b22eecvc85e397n3NnToiJyEE9JFN43abWLdRKH6DnRdDQunu3a/vuTP47Ee8jstSu33LX pnvy1BEi6w+InDV3bbxv/bdaAh8R5WKM4uhob20711BwO5FPwfgbO9DhOCM/inYI7Wkdm7bv0H4s /wLtONraxu51rcrX5ATaPWh7NrXu2GIpzwmgjTGkbW7d1F6e5Z2P9nfQLt/SvW072bkA7VNoV2+5 u33Lc/W+e4kK84hsr6OP8SceB1lJjNHo1kyP2X3NhXQFTfkKff+XLoUsl6hbL2kRTbLqVAicj1Pw MonZVG4SUqLRX5nl783yl0Qj94z+ARGZg5qI2t/02DBakAjf3/R8h26DpTePfgOzDFIL6otHv/rx M/Ji+hPfwA6eTa/wPDrLZQjldDqOcAqfL4CeRY+dfpKZY5D+m75Oxz9+RiHhf50o53rMOkjHqJvO Tew3699GKeji8+DF6lVqT9CWjPTLaS7PlDzI6KM0QH305mUjB7Hyo3SAjnAWvculkk57+VnOpbfo ZdpJe6Wn5X8m7DZY+dfPm5htD0aPP3wdneMeqqfX6BaaRQPs53Z6kXOwxtvw9A16mx6iozx5HLPM SBFf8SikfDudUen2P6DcCaxfoHXXPjOXscy+j9PHzijF/sjsw4t+pPWVDNqj2BPIN3N/mLV5aTny YTNyYA7WmMz5yDUbyzjr/gj0X0NWDNJ++iztEPE09a6HngZMVVZYog+B6jv0PfrSmBbXY1bdzPKT o9/gUpqB9gtjK12dW9YL3Mf2s41gx8sX95zlZGafp3f4+2Nzjbxr1p6ip+gvdIrO0H+wSk/hZD6H dZ9Hvu1D1PfBwp20lt5jHiH5efjVjL+rPJbJFuHJpc9OehTei93SDVve5Jew0pWeR5GPl+W4tZlP XraTiL6PffwE5pv4fGtiI1N/VN5B79NNl0jegj8vS0/TXuybh2izKetWnlAGsUp5+i8cXrF0SWje 3LraOTfOvqGmelZV5fUzK/Ty68pmTC+dFiwJaMVTp0z2FxX6CvK9ebket+rKcTrs2Vm2SVaLIktM FewzfA3RSJdR2BA3HMHGoKoZjk++s6zSII8/EHRrNZWxmRktw6IblNtk5DVH+ylcGzOs+uUqnzTk UvVPAQxe5tcihlKKT/Cm1jajbEU0EFRf9Y/LY5jWKGqIBgJ+QyrFZylE+NzUqrUZajP6ITB7lhrU HBWUGj1di06qDcRQrogaU8eaMTFb2pUJRuI0GR26zMxPckLtdxQ2NBqU10+O0wZ5hdo7tWRQyCjT YYiKmjkbVRqc9yeDcw32LoNLly4hhp2qvQIGkbauYKStE4i2xS9i+k4a0YCW0BIrou4afyBgGt1k HF8e7bdnNwQb2rPhBZkd1J9tR49ddCAsW/rZMZ/NiuSIzO2XyOYEfB5hbkRQlxHeG0cl2AjcIMm9 KEmNDu2bKCIMSysR1Mwam2sa1gZjUtoIrdMItxq0V+uvGErsS6m0Nq472oJtrZ+KGnIrjOonuTTS scqY3NR8B7pgBCjeoYlwN5qFCJ4W6dASaAvdOMpgI4Ze2t/W0R4XacLxYCNkWQ3RhwNDfsMDHjHc uuHEcOf9b/nlRMTXqYlmIvGwZjyxPDpRGhA6SALfzAotEQliNUwW6VooIlY5HjYzG5e2mcEJ723V jJ61XcAMn9Z9Y/kfSKiG488BRAfxwUixOwTAgtriXcKVLoxUwLTE3nbT1X2ma8hXLdLVKEgMRPbT rRh9RzTSEYwAz8yCAATj5dLLxwYCRqEuBiYSEWFiaxusF8jgU6ibZqQb2BN+nWFPgxFeZTJaZcYA K4ZbG2OZrowCJAriYITjjbGYcCodAGNS6cOW64NaQkw/qdTI09XADyAbmlnRtCIaaRTZCU2pIfqJ YZ9/GPWm5vFu9kEnUTksQBKSlcGm5eks6BD4iCK+Kr2BgVom8lDN6JuzvuTzv4Sxi4KL4onEoqC2 KBFPtKZGe9YGNTWY6Hc4Elsicc3c+Yz+I3v9xqJ9MUONd/BcBFnk26IVTUbu8tUiPIu0jlb04LMg GKj1B9yYOq2Dk+PK4sw+Q8Yj78U+S6h/hMcOnEh+bZE4XlI4FfyGWiu2KSy5NYp9sA5LRNrMAvtj JSb3i50ix0ojnSszAPkDWNJMGHHuLc/0YpJAQOyhvakwrUXD6FkeTbc1WutPUrhSR+ziQjI0JvHe KiQ9Y5Lx4fEgYuVrwvpmTnxcTuM8H8/nhDvo0erEYQ7r8FnaZgytgo8f1Bo2IGaGO7chKvsloYKa 5JdFLVvHKyFkFOjmQIEJTsmEGtROBA1VNywN0SF/KKapbhyQPJ4MmRlFmqongj9icYhSnmpwyOB8 sa0IhypgxKFfUAvh+EAtkohnsm+if1AV2m0d4/so7QU2rnASMKhB7Ft/Gg+3JyhcfVFk+9hboXSR 2FSIjYnYTTEjR7zsjJw/mgWc8zdENRxD2LbLzYoW0TpE1A0t3mieBzG/kI91p0ZPxRvF+RdFokHF n8lvZDlgy+yJDAxNq6JjtRXRB/z3x2amaGVFU4qy8CZlfiSW4tHeFDVOGaQsktfcCfGqCk2LdDZi QTRurUBHeQC12yqQmyL1o8GYeJMsbUtoIvnb4JbJIWhPxCqRryujOC8J+9AIx/zj1fZYbC7muV3M gyFQT8QwQ1dmBnCzq/IClKIVTTippjdHcdj2NCLRG8UWhrtD2FVDwmPhSGzcUlj8QKcvY/MdsDlW Dvnq9CzI1R5MEUskxJwro0GkeSLhT8CPTDvFdHlHONORIjEEjkdS3NOMsWBB8/tBJBgICuRjjVjq U8B97JRKUcvVEb5z3G6MXANr7zQRjv+dEG69FoTXXhPC68YtvQThNti8TiDcfmWEDWn6VTCeCGk4 DWn4CpCuvwTSu64Oace4obCqE+Z1mJB2/Z0g3XAtkG68Jkg3jVt6CaSbYfMmAWn3lSH9RyTtlksQ 3np1hO8etxtGboO1d5sIb/87IXzPtSB87zUh/OlxSy9BeAds/rRA+L7/P4Tvn4AwEX714Le0uJKS aRLhEF6pp8hWicMYZFNTRCdAoo26/Abq4Aq4DG55g46Yl0S3YZCiHiEJ922iLqlVswLugLsUBUPj fFjuOd9joY8orPRAq5OID+CXr1hzZtinHLa4+DB5rIctVskiHeawLYsPV1fpXORTlw0PqUPqMC0Y XjA8q6oGszKok8tGXhe/Tkdel0tECTckcWNiOY/7ARvlUld4yVo7d6vcrGxRepT9irJ6Eq+SebWV JSt7rEnr81Z5k4ud9il2yalOUaUsJesA5eYeYNm525K1i8JeS7eURxskPWPIuBW85s6WlhZq2YoS D4zSyK1SoLSm2uO+Ycb1rPOg9ABHefPIZ0a+OvLK7947E194JHnEcnzk4Mi/jXxhZMMr7GTPzz/X Kn7lStQy+nulD/d+OeSjB8LLb1O518WP5HLMyw97OaqwXfJLutQkKdkFZdnOJYo9zz7NLsvkUT2S 00JeH+cfkvNddndfluogu496c/J2W8NFOR1SoXX9RQcunBiiBQuGq6tNmlUlHKE1LbpwBw+3BGZb gyXSbNVTU10goJ4eLLF61ZrqOfLGu88eOz362rc+x9eNvLbh/k0Pvf7ZHT/9A5eMcB4v2SM1f3hS 1ne80j9yWFxdwafb4NMcZR2p5KXHwtPcTq53Lne+7Py1812npVfhPuVJRSqystXnyV+yWLldkWR8 nwoXeQqW3CTz/dnseMzl5qPun7oltzsnj76o4rdbWHPlLlFzvijl5/XZVNXl4SzZs9vucO+2hO0F +Ra4yj71WJG67MIL6jCcg7vDCy68qg+7PXWVLVuRQdyyVacWfSuCt7XUGkTgbiARtoAnUD2HA2qw RJnzs+dGhkee5+CZd9+8cPtUntf3zIWVnPhuqnQ+13LOKM8ZOTHy9MixCP+LuJhkkXf8a8RPpsnh HPIyyb3IdAv1jucwUE8n7yCXWfUPTwqMmG4e/b10xlKKbL0lXJ1to75cd5+Un2OxW/psLqfLqthd NiXX1RtXhhQJO0zRkMv7ce1hKKcUmwKHLhzD5hhSj6nH4Chq8HVYfWlWlfCskIOza2aXemu8QXce Qiid6frEyK6dO7ns7befnD7bWswd0sLBwZJfDl747Y9zhD2Cds8643StcYXOst8mrKTj7b89Pc5h seU8PGV8NxP64gGf9OwI7pdw6dh8bp7z1LgkLcdlshVdEm5++S/UaY3SoGUZtSgG3SZ9iQbl+XQz FOfibz09zxX8Ff6eJG7Fxfw22oRcugXnBCOTqnALRErCWQOk09Z6TI6Lb+wcWrRi+bLFt+o337Ou s6118d2tm9vaZy7s3tiGeTI3+aO1JFp//QhXZZqC+7vFtATr4b8XKdqKo+wuUAtopV5fQrdIuVhv Dcpu0C7Q50GPg3CASh5SQRqoCmSALJIHsnzym7xwdIjfCN+TZa/7r1P5BZN/fhLFzs/k+3d+pvDl V1C/99MoNm1BsbEbxYbN+f41m7s379os0wbesHnX3UXb78nzTr6rC8X6ThTtHXn+7o5dHZ/vkKld bdfajfZT7Zahdm7v6N1aVLgt//6GwsB9IEkalA5Jfd+dVzwyKukplgbAwviK+VR2dt07fZP0+hxp njSX5lGxpEnFQFOXpvMFIKKPDklTkm533XPSFGlypmNysrKqbhCSycnCokzFpUJl8viYomRurikp SjpzICmERMyazxeSVj27vopfJeaT/Aoio/PPM/xnGf5yhp/I8Jf4h6beixn+kwz/MThs5B9l+PEM P8Y/TCq6vT6LX0C87Oj1g6TRE/yD5I11sOtVVIoDmUpeQboykJVT53qWH6RikMR68pAMrK5LHhBs xsABm4CsdCAruw48OGB3mDyJdor9yb5AcYoDyQPFYL40U54CtB+DuDjM5v3Ok1v30EGbvqdP0Q8c ZJ0e4Uf6svUDfbJ+sE/Sv9hXXfz4Y3zi0KlD7xySD/WxHu4r9NeF+wB2StqcfNCip6SNyaMWXQRj 7QCC2fOMtIQYLf/A9BmwDzw/3+RJh9MMiDeplWQqBb66QbxYvEkZnkkFyXy0MTQvmeWAII/PJ80s OT8AM+Hy+SRSd5Df5MeSUwNov5nMK6yrz+bn+agZne9n+BAfxUCqL+dfkQqSSENZZdZ6+HuI+zOM 7wiI25EMH8zwpzP8qQz/boYn03z0FKeSjhzYMMD9WML+DPfD2RNsjEXVGIuqkcxE1Ugiqs/xbn6I 3FSMHfiQmOFZ7uBOqkakC5K7rAhvebJXsLLkHgVsevKzgk0beBB+HOESmFwyAAU4XZgsnCpQQsVn woVKjhsZUBxWdweKL5wHlh8B2I96kDWjQwMfeL11JscLSMTc8YHTWffns7J+tsdmKrxXXWMqvDdt mqlgfy+/qK6qP9zf3I8XIgb0u3114bdmVtapb7GYKVk01VS8Mam664zDFv1wr0VXf9P8m/2/kff1 IklPFxbWaacXnH789OHTR0+fOm19YBd6/8nlqvunzJo9c+eZa/Zk1u4pr0i3/ebUAz3BtC15PXm+ up5eSd/fq+gPYpZdmF8Y5X94YXPdw73Z+m6xYG9paV24t7gYBTZD/X2SLCmShRx8jj/gD8Hf57P8 Z/w3tlgS53Yxn6MFoGaQLLn4rOQmp5SFMXZwK38g2cBdFJKyQFaQTCHohvh90OP4H8KXMedBfpT7 wPfzAf4C+DfBv01OfhLyr4N/BfKvgX8TY54EfUWMBR0E7QfV4j+MObBlHof4ExhfyVU8C7yCZ/L1 4IvBl2J8PeQN4PMhD4Mvxth60HzQPFAlqCJ8MOSf4/Xd6PXO9npu8LpqvI5qb9Ysr7XKK1d66Xrv 9Bk5ZTNc5XpOhe4qCeZMC7qmFudoxS6X6nZkZdsd1kk2h6xYHMSSg2RPcbF8i3xUHpWVYtcCV7NL 9vMUp29SkdOrFjg9Sp6zIlQeKgtND00LlYS00NSQP+QLeUOekCuUFbKG5BCFmmvY8DRR06qFRi6D r1xo1OhNKVlbYVTrTUZW8+r0bQt6DWkP3gWrDGVPSgLzNNyxOopMF5cxvf5BJD8ZTfHez8Vw077Q 4D1GELcPYGHchGh7cA+4Ktov8ULcOBtzcAMktGL6FKNN3Mj1TIkZ1aKyf0oMl4xzlxv+4EL9Ss+2 bRN7+8umR4zySKtREYk3ThT873VzIr6CHhYw10Cx/XLxJYtfbGzbdkVNwvC0vX8lHlvj4hxC9/Ll 8IuiIeqPCdJxnW2EER5YlcFgAhQpfk3coaf49TT7zzT7RZr9Ms3eEMw0aXt/lgju/BULmwwbboRt zauNoiAax9G4EQ1HcOH/ADABTMgKZW5kc3RyZWFtCmVuZG9iago5NCAwIG9iago0ODU5CmVuZG9i ago5NSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NjcgL0NhcEhlaWdo dCA3MzIgL0Rlc2NlbnQgLTIxMSAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTA4NiAtNDQwIDE3MzQg MTE2OV0gL0ZvbnROYW1lIC9GUlFNR1UrTHVjaWRhR3JhbmRlLUJvbGQgL0l0YWxpY0FuZ2xlCjAg L1N0ZW1WIDE1MCAvTWF4V2lkdGggMTc1MCAvU3RlbUggMTAwIC9YSGVpZ2h0IDU0MiAvRm9udEZp bGUyIDkzIDAgUiA+PgplbmRvYmoKOTYgMCBvYmoKWyAzMzAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNDcgMCAwIDAgMCAwIDAgMAowIDAgNzkzIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgNjYzCjU4NiAwIDAgMCAwIDAgMCAzMjUgMCAwIDAgMCAwIDAgMCA0MDUgXQplbmRvYmoKMTcg MCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvRlJRTUdV K0x1Y2lkYUdyYW5kZS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo5NSAwIFIgL1dpZHRocyA5NiAwIFIg L0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+ PgplbmRvYmoKOTcgMCBvYmoKPDwgL0xlbmd0aCA5OCAwIFIgL0xlbmd0aDEgODg2MCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9WQt4VEWWPlW38+6kO48OSRqS21wCyA2Eh48EW+iQ dBSi2EDAblDohg4EFIgkvF8tGogNPkBH5hsdxZ1Zv32MctOJY2cVk9XBD3Z1Bllfs84Kvv12ZGVm HfFbXXr/uvd2SDIZP/bT3eo+9dc5p+rUqVOnKnRBjIisFCGJPCvWhloona6F5FVQ0YpNbfL5z774 NdofEaX+cmXLqrUbC+wXidIeI8qetuqOrSuLLc89RVRwCn08zU2h8FcXC08QOezgr26GwLqId4O/ AfyY5rVtW1JJTOi4A1X6HetXhEjGhxxt4FPXhra0pG7LUcHvAC+vC61tem7n72PgMR+Vt6xvbUu4 KQz+V+DHtmxoahn7wfWF4D/HIo5CxvARxUqpICKXkKSqVEyUcoLKk7Xex6wsM6hINBPv6vVnyfbF jQm9TXTxHSH7PiUdgwVZvo8RMfY4rSdr4trEwcSX1EvNVJCoSfw4gdUPU/YkdtEZOk0nqZuepkfp PbSP04vUQ39PH6L9ClpP049oOcb+nH5K7cC/oyfpYdoAuUAhOf7nltn4QbILdIEOsxqaAxxaHoaV h4cK/yL/SaJkGN17idG0g3bwjfwj2ojPT2DxF3RkQM/VaP81tdJ2Os7O0XL2Aq3EejqQKQ9wX+Lf U05SobSFCmm95YjIhEHlEfLTVgpLjyX+gDyxpfnIxo8m/gBbg8t39VuPuZOlhw6wTNqFuE2hm+Hr rKRiMCKGF7CGFVjLHnwOYze68NmBeQ8O7JlaJ7ik3+lkZGsyj1KuNPomPkX+btHbx0W8zYx9nzZh BjdNpFKyJcqQNzckmhJbEz9NHEM2iN1/ysyKXnB/SwfZYXiwnG6lRfxVdk7n1oNfRHPYKJZNj8P2 VcaMydo8VZLBixwXJemfxYyiebbgpVES4o7RCzvERiASJ+hliuv+PEaHKEoRxKEN+b2YfPB9Og62 0e9jPYeF55f6LKVG5B4KcnAG1vOeYdmoU97Uz/5Kg/sz/8TZPy69ZIwRUTQKrrhkeQ07aZyGDsRm I87fCuzsBf30iP07jl17ErmW1C3q176i763oP4OmCi8S0xO7EPtf0y20nnex8exujOtITjQAfwFp MpOL6D02Y4BuYPP75P0OnKHj9MhAczjvt1HTIMkQZmj8hqiHYVPOMQ1xOE2/xHzb8RE3+9DSg/w+ jjhto3lUQ/uwj+/hfDTjDIcR8dNMxv68jltsuBKC3VPYlfXSSsnc5eG6IUPEZ5iScs4QphOzIPP7 czfZ1cjdJDcIZ6RI9A7LQ348RO8gJ56m53CXrBJSZLFR/nd7tIfW0QTzQx7P/Nk3uK+dXl11zdVX XTlt6pTJlZMmVqgTrhg/bmz5GGW0Sy4rHTXSWVJcNKLQUZCfl2u35WRbszIz0tNSUywSZ1TBirSi Wr93jVZcG9SsSp1ilzXr3PM3VWqU53QpufK0ysBEs5eWomqU36AV+Pyd5KkKaKnq0C5zNanc/kcX Bt/klL2apRxfZU4orI2f73cp9rec/foAzGoltX6Xy6nxcnxnQ4XvnJAc1uw+yKHQJbM18vkFxRMf VEFIVa4A6vl+rTTJBoQ1YykDnOzBieob4uZcFrV3Wotr6zQq6CTrBxo5RLfzVaSRWxuvwhE7Wro1 qtRYwR81lq8xx01Y0uApxLCzVcPEwBteo3jDqxHRcPBSTM8bEXXJUTk63587zely6U43aCfm+Tuz MmuV2qZMrIJ0AXVmZkGSJQTYlpZOZp3B9Aa3eqd3ckrPRvjyhLteQWs0z/4gGkod4gZN/iVNPNF3 YKCKMMzoROimt5g+p5Zaq6UZTsirNU9Io/1yZ0Vf9EDcTsuDqjWshEO3+jUpBKc6SSr3NjdqIxt8 iyGCE6Bgsyy2u06vxObJ3mY5Cl70DaJW6jB0sDzc3BQUacKCSh10GbX+fa4+p5YH9Gq5qpaN4dnb PnJKUW/Ralmw0eg+WTsyzz9Q6xJ9kARFEyvkqFfBbDDmXTNL7Fhl/7bp2Tg7rG+OZ39I1iLL1yBm +IYOJPPfFbVr1q9c2B3sD0aK0yECLCgcXCOWsgYjLQA5ur9JX+oBfWnIV9m7pk6QGIjsp4UYvdjv bVa8iKc5IQKC8VL50LEul1asioHRqFe4GArDexEZfItV3Q2DwZlwqgz+1GqeRh2oUd8DzOgJ1QVM kdkBGgv2QfME6wIBsShjA7S08n0pkxQ5KsynlWsFqt31K+j6JlY0zPd760R2oiev9V93rsh5Du0G X7+YFaFPtPKcCJLQLFAa5hlZ0CziI6pgo3GAETVz59HV7K9bfa3I+RrG1iv1wWi0XpHro8FoKJ6I LFdkuxLttFqjLd6grJ98Bvk/7Hdq9QcCmj3YzKZjk0W+1c9v0PLnLRHbUy83hyDBd6biqnK6cmHa 6IObY3i1ec6Q8ch7cc6i9s+xYituJKdcL66XOG4Fp2avEscUniz04xyswBTesF7hfCyAcac4KVKg 3Lt6gRkgpwtT6gkj7r15phRGXC5xhvbHPbQcjBaZ5zd4mZY7Y+SpVLF3QaHpS2ocC4UmktT0Dw8q 2KuiBsyv58Rfymnc5/35HM1V8uRqcZnDO3xnh7W+Rqzx6yotHRHTtzu/1i85ueiCFndKopWp4k+C Wxuh6gNFTHBLRu2KfErR7KqWUuvvc7oDsj0XFyTrTwbTokhT+ynlJBOXKBXYNebWWKE4VoRLFWHE pT+iCsr+gbI3GjSzb+D60FX0Djf3nyNjFTi4YpEIg13BuXUa8cjNU8RSXxXZnvyrUF4vDhX2Ro/Y nICWI/7YaTmf6xUW56z1y7iGcGzn6Q3ZKzeLXdfkYJ1+HwScQp8UxxNng3Xi/vMj0dDFaeY3shxh M8+EGYaGRn+yNd+/07ktMDFOCyoa4pSBv6SM3R+Is0R7nOpG9VAGScuWQt1YIcve1XWYEMzCCggm uNBaVIHcFKnvVwLiL8nscFQWyR/GsnSEoikaqES+LvDjviScQ80TcPY3mwKB6bBzi7CDIegeDcDC GtMCUBdV/jc6+SsacFON9flx2UbqkOh14ghjuX04VX1ixWIhgX5P4fHO1UWmz4vhc2AC9EsMK8jV CEwEolFhc4FfQZpHo84o1mHycUZDBR5TECcxBAv3xlnEh7EARf/3gVdxKSLygTpMdSvinryl4nTb d0d4ab/fGLkM3i7VIxz8gSIcupwIL7+sCK/o93RQhMPweYWIcNPwEdb42O+I8cCQeoyQeoYJ6cpB IV313SFt7ncUXq2Ge816SNf8QCG9/XJCesdlhXRtv6eDQroOPq8VIV0/fEj/L5K2ZVCE7/zuCG/o 9xtOtsLbDXqE236gCG+8nAhvuqwIb+73dFCEt8DnzSLCW///IrxtQISJ8KsHr3z44EUzjQqeS+UW ElT52huv6dWUya5cV245Kobfet96pMi3kRT6hjyWCEbq74epLPX9VXtdy2zuPzGn8Zv3RNPHHwi1 wP4ZCPe5YEQBpr1w0Yd30dILmy7UZouXx8GFG2+fulAmGSh6cNoMuhm+MrLTZPxCppSz2dPgvdAy ytMRr6OUT+SvaVgwd65648YVq8Oh6zeE1oX1n+scPVESVeJtdJhi6uN0pxqnVaDbQAvUmhxMX092 EKfdvI4Yn8ndmE/lM7g7xtQvnufXQXgdmIIyOgadHcTZPtYRKynzxNm9XfbCaqrJYR1kB3F2N2uH LZXdY+Je1h7jauR5thtmz7AdnpXszNnCESPfeBPV9h2FTtv2su2V26XtO4pfPw3Rps2o1ragumM9 qtvXFTqXrdt9O7993e4NJW0bCxwjV61BtXI1qqbmAucDTUeaTjVJTc3td5YUtxZuqy12bQXxHmm+ NAcz249J9eQDcfJI1bGsnOqeRJ9UFcsxG10Z1mpfTZY0kZg0WZqCqKv8S/6feKxV+YexF7ka57/r ejGMtfJ3u6ZMrxYYU8YJK2gUFOiN38amVZuNCZPMhksxGyOKzUZOrt44FctFg0f4FuFejcrbyAfi CO1taN2GVha/kZyg20ESuAZwDcT5dKRxIZXxKmAecCqfIoLNJ5tYCSyFfBKfEistk+OAvMLqHnaB fRiT1MwamX1JjH3B/kOMwvOegZ+b+HsTP2OfijCwT4AW4MdA9E/8E/uwKwuu14yCgNEm1HuFij3M DukGHzLxEHsQ2aqyg8A04ANAMeH97EEsubcXLKMW1BGhYLfEDlnUOFsQOyjg5thhAVd37ZZUJFh1 LK+ouiaDjWHlulN2lqujxXPttwjf176vueeTkpLqnzwqqY89alEfPZypPgR7Bw+lqodg6UegHx/m 6iOHJfXIYfbE4aOHew9LL0g3SLPF4qTZsXauipSo7bLnVpe9KOEQ0FlRS1dJVyJqck2eNI0mgzwg H8giTZMKhBPSVBMrpQL0rOwFizOL7JFBnJ+PHUtF/nwQ600XU/D3YyPG6ynwfgy5EOdnY/syoT/T 1WvBUvnbXUq5yK+3Yw5sGvqfjsGlmmz+Cj8u4slf4n06/qOJB4TvL/BNfLNYCt9sLoXfaSyFbxBL 0WsPDyaNBmOZWbr1ZbERRXpjaWzMFXpjsT6upoAv0QeK2sbnoC7ks2ksiFMGn0jFIA731FiuQx93 RVd2bjWyTRHZdoyP5rLYbu7icsyinoQ9GXdIKWpxuMoMLfuK/UbfyLPsWVyFLnaGPRsb65Lj7Eys 1FVdU8L+jf1Oz5p3TfxXE39r4jvsbd3A2+wtvd9b7A1kl9YLlrE32Ru68F904eqaLHYa6+gRNTtt 6l7XdZjxVAyXQA/y+zciv9Ve9jP6OagbJCXOsqdi+Q5sA7uPHdAn3G9iFCjSelFsL64JtjAWkQCN sb0pgPmxfQLmxToE+GIdQjc31i7gRrFRcVYV2ydgSqxXCEcbwhxPFpT/9Y1F/UZ0SvR5Mv8kEvMr dvYrJtiMTsfIas/HSHnBTTqabauGp55uX3ewu6U70t3Xfar7bPf57ozuo+Gyzz61qPdG09To/lT1 AAhDnrt/8tTq++/DlBhecF+pUn3ffq7ub09X99xlUe8Sa0j0dUXm3CTsd0Vm1hp4ZbWB4yfp81oj o5TqyC6u7t6lW/VYd3pnV+8EswuWhGm5A6Y7sMJ9EOxtT1XvvidTvQfY0h5p573trCZTWiA1Uo7k k+ahnivdLOqYFC6rWSjdKN1ENskpjZRGkVWySXYpF2iVsqUc4DjgFZQtuaBXgKXQy8Bx5JZcoFKQ E2QDWcnNn+bP8KNk5U/yv+I/Az7On+BHgD3A5ymbd0H/LFCDPgbswZguEB4K+dOgJ0GPg+7ieyiH 7+K7Ue/gO0Wt+7uRb+PbcVbsPJfnwW42z+E2IOOcS2RlF1kCf4GtuMlz6VEQF31x19vpCVAv6Awo BTd3Ns0E7QZJVMYu4twUY6wTPuXDpgNYDD/yQXZQNigVxMiNvm52jL3IejFfJ4uxLuAz7Ch+iVvZ SeA/UzZ7GfrjwD7oXwKexJiXQX1iLKgT9AxoLVvH8N+MLMSWsxXApWwZC+r8ytiIsrKaWWwlzQTt BklsK7TbYa0VozYCWzBqA3ArLLWCWoRF0EpQCLQUVMEmko2NZeNQj2dXUA6bwFTURawYkjyWj7qA OSApxH8P5bAUloqaMwk1jrCoPX+DVLmYsDmvcRRd7XBc5ci70mGb5rBOdWRMcaROdkiVDprkGDsu Z/w42wQ1p0K1jVZyxii20rIcucxms+daMzKzrKlp6VbJkmJFpK0kefJLFJLyy1KlkWVltpm23TZJ lliZdLPUKyUki5ONyi5KK8l22Edk51kKsh90sgr3BPd491j3GPdot+wudTvdRW6HO89tc2e4U92S m9y+aUzLa6CGxllaPgMumKVNUxvikjxfm6o2aBm+JcYbAaQa78CP5EbN0hHngLzaxUv8cVYsnhDa nT1i3VpDsP2+AN6HZ2msQ1Pwmxngwe93uQOvV43+Ts5m4Z1UuwbvFqJXQB2lhcU7UmRUQJsqGg+O CuBpbPo8zanMUoeWViFobdPhkq5z/FivNsEb0iq8wbpLYlUlMHDYq130huKMK4OUyY5DjCXFwFYU k43zHd443wYzfNfwZvrHxaW53rh0I7pKPtG1rZX164ZptLZByPR6qFafvG0jHBmkgQClFWEQQ0U8 dBhQ6W63GgoaqKZ+S0lpEgdMMmDZpk0xqlVltX5nQMVTsKYgSZIDTIsCWJztEM/PcbbTgF0G7DYg YsBdBuwx4G4D7jGg3YC9BuwzoMOAewWYK8O/Sq7VpdxtwHUGzDBgpgEeA2oMmGVArQH6O3mcew2u 3oDrBSBuWFtrZ4bIft/8WQ1aOh56031LtBIFzAkwV4OxKrPofwDd5nzCCmVuZHN0cmVhbQplbmRv YmoKOTggMCBvYmoKNDc0OQplbmRvYmoKOTkgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9y IC9Bc2NlbnQgOTY3IC9DYXBIZWlnaHQgNzMyIC9EZXNjZW50IC0yMTEgL0ZsYWdzIDQKL0ZvbnRC Qm94IFstMTA2NyAtNzM3IDE2NDEgMTE2Ml0gL0ZvbnROYW1lIC9YQUtTTk4rTHVjaWRhR3JhbmRl IC9JdGFsaWNBbmdsZQowIC9TdGVtViAxMDMgL01heFdpZHRoIDE2NDAgL1N0ZW1IIDc3IC9YSGVp Z2h0IDUzNiAvRm9udEZpbGUyIDk3IDAgUiA+PgplbmRvYmoKMTAwIDAgb2JqClsgMCBdCmVuZG9i agoxMDEgMCBvYmoKPDwgL0xlbmd0aCAxMDIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AV2QwW7DIAyG7zyFj92hIukZIU2dKuWwdlrWByDgREgLIIcc8vYzLO2kIfnA//szP5bn 7q0LPoP8oGh7zDD64AiXuJJFGHDyQbQncN7m/VY1O5skJMP9tmScuzBGUEoAyE9GlkwbHF5dHPCl aDdySD5McLif+6r0a0rfOGPI0AitweHI495NupoZQVb02Dn2fd6OTP11fG0JgRMx0f5GstHhkoxF MmFCoZpGq8tFCwzun7UDw7h3nlqtSjV8av/DKWj54jOSXYk4Td1DDVoC+IDPVaWYyoO1fgBtmnAQ CmVuZHN0cmVhbQplbmRvYmoKMTAyIDAgb2JqCjIyMwplbmRvYmoKMTYgMCBvYmoKPDwgL1R5cGUg L0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvWEFLU05OK0x1Y2lkYUdyYW5kZSAv Rm9udERlc2NyaXB0b3IKOTkgMCBSIC9XaWR0aHMgMTAwIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0 Q2hhciAzMyAvVG9Vbmljb2RlIDEwMSAwIFIgPj4KZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIChz ZWN0aW9uLTE2LWZvci1SUEwtcmV2LTExKSAvQXV0aG9yIChKUCBWYXNzZXVyKSAvU3ViamVjdCAo KSAvQUFQTDpLZXl3b3JkcwpbICgpIF0gL0tleXdvcmRzICgpIC9DcmVhdG9yIChNaWNyb3NvZnQg V29yZCkgL1Byb2R1Y2VyIChNYWMgT1MgWCAxMC41LjggUXVhcnR6IFBERkNvbnRleHQpCi9DcmVh dGlvbkRhdGUgKEQ6MjAxMDA3MTYxMDMzMDZaMDAnMDAnKSAvTW9kRGF0ZSAoRDoyMDEwMDcxNjEw MzMwNlowMCcwMCcpCj4+CmVuZG9iagp4cmVmCjAgMTAzCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAw MDEzMzA3NSAwMDAwMCBuIAowMDAwMDA1NDkwIDAwMDAwIG4gCjAwMDAwODcyNTAgMDAwMDAgbiAK MDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDA1NDcwIDAwMDAwIG4gCjAwMDAwMDU1OTQgMDAwMDAg biAKMDAwMDAwNjYwNiAwMDAwMCBuIAowMDAwMTIxNjg1IDAwMDAwIG4gCjAwMDAwMDU2OTIgMDAw MDAgbiAKMDAwMDAwNjU4NiAwMDAwMCBuIAowMDAwMDEzODUxIDAwMDAwIG4gCjAwMDAwMDY2NDEg MDAwMDAgbiAKMDAwMDAxMzgzMCAwMDAwMCBuIAowMDAwMDEzOTU4IDAwMDAwIG4gCjAwMDAwMDAw MDAgMDAwMDAgbiAKMDAwMDEzMjkwNiAwMDAwMCBuIAowMDAwMTI3Mjc4IDAwMDAwIG4gCjAwMDAw MTQ1MTEgMDAwMDAgbiAKMDAwMDAxNDA4MyAwMDAwMCBuIAowMDAwMDE0NDkxIDAwMDAwIG4gCjAw MDAwMTQ2MTggMDAwMDAgbiAKMDAwMDAyNTQyNSAwMDAwMCBuIAowMDAwMDE0NzE3IDAwMDAwIG4g CjAwMDAwMjU0MDMgMDAwMDAgbiAKMDAwMDAyNTUzMiAwMDAwMCBuIAowMDAwMDk2MDcxIDAwMDAw IG4gCjAwMDAwMjczMDkgMDAwMDAgbiAKMDAwMDAyNTY3MCAwMDAwMCBuIAowMDAwMDI3Mjg4IDAw MDAwIG4gCjAwMDAwMjc0MTYgMDAwMDAgbiAKMDAwMDAzNDQ2NyAwMDAwMCBuIAowMDAwMDI3NTQx IDAwMDAwIG4gCjAwMDAwMzQ0NDYgMDAwMDAgbiAKMDAwMDAzNDU3NCAwMDAwMCBuIAowMDAwMDM0 NzUwIDAwMDAwIG4gCjAwMDAwMzUwMDggMDAwMDAgbiAKMDAwMDAzNzk5OCAwMDAwMCBuIAowMDAw MDM1MDI3IDAwMDAwIG4gCjAwMDAwMzUyNDAgMDAwMDAgbiAKMDAwMDAzNTI1OSAwMDAwMCBuIAow MDAwMDM3OTc3IDAwMDAwIG4gCjAwMDAwNDYyODMgMDAwMDAgbiAKMDAwMDAzODAzNSAwMDAwMCBu IAowMDAwMDQ2MjYyIDAwMDAwIG4gCjAwMDAwNDYzOTAgMDAwMDAgbiAKMDAwMDA1MzM1OCAwMDAw MCBuIAowMDAwMDQ2NTY2IDAwMDAwIG4gCjAwMDAwNTMzMzcgMDAwMDAgbiAKMDAwMDA1MzQ2NSAw MDAwMCBuIAowMDAwMDU4NjM2IDAwMDAwIG4gCjAwMDAwODczNzMgMDAwMDAgbiAKMDAwMDA1MzY0 MSAwMDAwMCBuIAowMDAwMDU4NjE1IDAwMDAwIG4gCjAwMDAwNTg3NDQgMDAwMDAgbiAKMDAwMDA2 Mjg3NSAwMDAwMCBuIAowMDAwMDU4ODQzIDAwMDAwIG4gCjAwMDAwNjI4NTQgMDAwMDAgbiAKMDAw MDA2Mjk4MyAwMDAwMCBuIAowMDAwMDY3MTEzIDAwMDAwIG4gCjAwMDAwNjMwODIgMDAwMDAgbiAK MDAwMDA2NzA5MiAwMDAwMCBuIAowMDAwMDY3MjIxIDAwMDAwIG4gCjAwMDAwNzIxNTAgMDAwMDAg biAKMDAwMDA2NzMyMCAwMDAwMCBuIAowMDAwMDcyMTI5IDAwMDAwIG4gCjAwMDAwNzIyNTggMDAw MDAgbiAKMDAwMDA3OTA0OSAwMDAwMCBuIAowMDAwMDcyMzU3IDAwMDAwIG4gCjAwMDAwNzkwMjgg MDAwMDAgbiAKMDAwMDA3OTE1NyAwMDAwMCBuIAowMDAwMDg0NzUwIDAwMDAwIG4gCjAwMDAwNzkz MzMgMDAwMDAgbiAKMDAwMDA4NDcyOSAwMDAwMCBuIAowMDAwMDg0ODU4IDAwMDAwIG4gCjAwMDAw ODYyNTcgMDAwMDAgbiAKMDAwMDA4NDk1NyAwMDAwMCBuIAowMDAwMDg2MjM2IDAwMDAwIG4gCjAw MDAwODYzNjUgMDAwMDAgbiAKMDAwMDA4NzA0MyAwMDAwMCBuIAowMDAwMDg2NDY0IDAwMDAwIG4g CjAwMDAwODcwMjMgMDAwMDAgbiAKMDAwMDA4NzE1MSAwMDAwMCBuIAowMDAwMDg3NDk4IDAwMDAw IG4gCjAwMDAwODc1OTAgMDAwMDAgbiAKMDAwMDA4NzY1NSAwMDAwMCBuIAowMDAwMDk1NjU0IDAw MDAwIG4gCjAwMDAwOTU2NzUgMDAwMDAgbiAKMDAwMDA5NTkxNSAwMDAwMCBuIAowMDAwMDk2MjQ5 IDAwMDAwIG4gCjAwMDAxMjEwNzYgMDAwMDAgbiAKMDAwMDEyMTA5OCAwMDAwMCBuIAowMDAwMTIx MzMzIDAwMDAwIG4gCjAwMDAxMjE4NTcgMDAwMDAgbiAKMDAwMDEyNjgwNiAwMDAwMCBuIAowMDAw MTI2ODI3IDAwMDAwIG4gCjAwMDAxMjcwNzQgMDAwMDAgbiAKMDAwMDEyNzQ2MSAwMDAwMCBuIAow MDAwMTMyMzAwIDAwMDAwIG4gCjAwMDAxMzIzMjEgMDAwMDAgbiAKMDAwMDEzMjU2MSAwMDAwMCBu IAowMDAwMTMyNTg0IDAwMDAwIG4gCjAwMDAxMzI4ODUgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6 ZSAxMDMgL1Jvb3QgODQgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDwyMTgwZTEzMTEyNWQ0ZTM2MjVh YjY5YTFlNzFlNmVlND4KPDIxODBlMTMxMTI1ZDRlMzYyNWFiNjlhMWU3MWU2ZWU0PiBdID4+CnN0 YXJ0eHJlZgoxMzMzNDYKJSVFT0YK --Apple-Mail-90-321512623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Best,
<image001.gif>
Durvy Mathilde
Software EngineerTechnology center

 +41 21 822 = 1725
Mobile: +41 76 396 = 8116

Cisco Systems International = S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home = page

Think before you = print.
This e-mail may contain confidential and privileged material for = the sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this = message.

______________________________= _________________
Roll mailing list
In-Reply-To: <4C3F3802.4080102@sics.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New link-local RPL multicast address and 6lowpan-HC thread-index: AcskPJuCuDZfesCPQt2Qb2T+6XmpCgAsWIJQ References: <4C3D8E54.6020101@sics.se> <6A2A459175DABE4BB11DE2026AA50A5D02574462@XMB-AMS-107.cisco.com> <4C3F3802.4080102@sics.se> From: "Pascal Thubert (pthubert)" To: "Joakim Eriksson" , "roll" X-OriginalArrivalTime: 16 Jul 2010 13:53:55.0230 (UTC) FILETIME=[54B733E0:01CB24EE] Subject: Re: [Roll] New link-local RPL multicast address and 6lowpan-HC 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: , X-List-Received-Date: Fri, 16 Jul 2010 13:53:46 -0000 Advice to all : ) The requested mcast address for RPL will be FF02::1A as opposed to FF02::1:A If you see a problem with that value please let us now. If you plan interop tests please use this new value. " This specification requires the allocation of a new permanent multicast address with a link local scope for RPL routers, with a suggested value of FF02::1A, to be confirmed by IANA." Cheers, Pascal > -----Original Message----- > From: Joakim Eriksson [mailto:joakime@sics.se] > Sent: Thursday, July 15, 2010 6:32 PM > To: Pascal Thubert (pthubert) > Cc: roll > Subject: Re: [Roll] New link-local RPL multicast address and 6lowpan-HC >=20 > Exactly, it is free, and is a good replacement for 1:a! > And, yes, we should take it if we can! >=20 > Best regards, > -- Joakim Eriksson, SICS >=20 > Pascal Thubert (pthubert) skrev 2010-07-15 11:38: > > Great point Joakim; > > > > 1A is actually free in > > http://www.iana.org/assignments/ipv6-multicast-addresses/ > > let's try and get that value? > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of > >> Joakim Eriksson > >> Sent: Wednesday, July 14, 2010 12:16 PM > >> To: roll > >> Subject: [Roll] New link-local RPL multicast address and 6lowpan-HC > >> > >> Hello, > >> > >> The new RPL all routers address ff02::1:a is going to cause much > >> worse compression (3 bytes vs 1 byte) of the destination address in > >> 6lowpan > > based > >> networks. Is there any plans for "fixing" the HC or are we ok with > > this? (I like > >> small messages ;-) > >> > >> Would it be impossible to get a ff02::1a address from IANA instead? > >> > >> > >> Best regards > >> -- Joakim Eriksson, SICS > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Fri Jul 16 06:53:50 2010 Return-Path: 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 99C3A3A6A4C for ; Fri, 16 Jul 2010 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 P54uGWQoPBdd for ; Fri, 16 Jul 2010 06:53:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9DA7C3A6A48 for ; Fri, 16 Jul 2010 06:53:49 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OZlMW-0008Sg-GH; Fri, 16 Jul 2010 06:54:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 16 Jul 2010 13:54:00 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/66#comment:1 Message-ID: <064.6b06cde4a000e27cb29a5db391f367b1@tools.ietf.org> References: <055.a09c55694a404838dee3f73fe8b58883@tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <055.a09c55694a404838dee3f73fe8b58883@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #66: New link-local RPL multicast address and 6lowpan-HC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 13:53:50 -0000 #66: New link-local RPL multicast address and 6lowpan-HC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Here is the resolution (agreed on the Mailing List) to be added to the next revision 11 of RPL: The rules for assigning new IPv6 multicast addresses are defined in . This specification requires the allocation of a new permanent multicast address with a link local scope for RPL routers, with a suggested value of FF02::1A, to be confirmed by IANA. -- Ticket URL: roll From pthubert@cisco.com Fri Jul 16 07:02:36 2010 Return-Path: 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 CC6843A681A for ; Fri, 16 Jul 2010 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.317 X-Spam-Level: X-Spam-Status: No, score=-10.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aI+GRj2iVyay for ; Fri, 16 Jul 2010 07:02:35 -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 8A5613A6821 for ; Fri, 16 Jul 2010 07:02:35 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADcDQExAZnwM/2dsb2JhbACfaXGkKJpmhSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,214,1278288000"; d="scan'208";a="133205687" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2010 14:02:46 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GE2kXk013894; Fri, 16 Jul 2010 14:02:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:02:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 16:02:43 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574A5E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Proposed DIS flags (Re: LC RPL-10) thread-index: Acsil4nyax8AnZKQSXiEigSM4G3V6ACVuVWQ References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu><5263.1277904523@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com><7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu><4C3B9001.3050505@acm.org><6A2A459175DABE4BB11DE2026AA50A5D024CDAD4@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Nicolas DEJEAN" X-OriginalArrivalTime: 16 Jul 2010 14:02:46.0377 (UTC) FILETIME=[914DCD90:01CB24EF] Cc: roll@ietf.org Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:02:36 -0000 Hi: I think that there are cases where the node could suggest things (hint) = but it appears to me that the routers have a better history than the = node so even if we have bits, they can only be information/ suggestion. = For instance, a router that has history to support a very sparse network = could answer rapidly and unicast. In a dense configuration it should let = trickle play out. The host cannot know that sort of thing. ND is = similar, RAs can be sent unicast or multicast.=20 But a host can know that it is a leaf that does not impact the routing, = that it is discovering the environment etc... The question at some point = was whether we needed to play out the exponential back off or remember = to set back the trickle timer to its original value because the trigger = was not an inconsistency. I thought that the optimization was worth it = but that did not reach consensus. Pascal > -----Original Message----- > From: Nicolas DEJEAN [mailto:nicolas.dejean.ietf@googlemail.com] > Sent: Tuesday, July 13, 2010 4:27 PM > To: Pascal Thubert (pthubert) > Cc: Philip Levis; Tim Winter; roll@ietf.org > Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) >=20 > Hello Pascal, >=20 > 2010/7/13 Pascal Thubert (pthubert) : > > I'm on the same line as Tim and Phil for this one. > > > > In one hand I agree that the every DIS is not necessarily an > > inconsistency that should trigger Trickle to reset its timer, but = OTOH > > I'm unsure that the originator has all the information to figure = that > > out. > > >=20 > We have at least identified one case where the originator knows this: > the attachment as a leaf node. >=20 > > Let us get more experience in determining which inconsistencies we > > really care about, and then we'll publish add-ons to the standard = that > > cover those as required. > > >=20 > What disturbs me in postponing the integration of these flags into the > specifications is that we already know a common case where the only > described behaviour will not fit in terms of energy consumption. >=20 > Please, read http://www.ietf.org/mail- > archive/web/roll/current/msg03306.html > as a reference for this case. >=20 > > Pascal > > >=20 > Thanks, >=20 > Nicolas. >=20 > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf > > Of Philip > >> Levis > >> Sent: Tuesday, July 13, 2010 1:07 AM > >> To: Tim Winter > >> Cc: roll@ietf.org > >> Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) > >> > >> > >> On Jul 12, 2010, at 2:58 PM, Tim Winter wrote: > >> > >> > Hi Nicolas, Phil, > >> > > >> > > >> > RPL-10 does keep some bits reserved in the DIS message as well as > > the > >> Solicited Information option -- do you think that it would make = sense > > to get > >> more experience with the proposed =A0C/R, U flags and then, after = they > > have > >> been proved out and all of the ramifications are understood, to > >> define > > them in > >> a future extension to the RPL base specfication? > >> > >> Sure, makes sense to me. Until then, we should strive for the = minimum > > viable > >> protocol. > >> > >> 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 yoav@yitran.com Fri Jul 16 07:24:40 2010 Return-Path: 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 6B0393A6915 for ; Fri, 16 Jul 2010 07:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 s0beK57dxmzm for ; Fri, 16 Jul 2010 07:24:39 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id B0C523A6857 for ; Fri, 16 Jul 2010 07:24:38 -0700 (PDT) Received: from source ([209.85.161.51]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTEBrsVsnsjJxNpAMX3V4aSYaTE7Zwypv@postini.com; Fri, 16 Jul 2010 07:24:50 PDT Received: by mail-fx0-f51.google.com with SMTP id 15so1231122fxm.10 for ; Fri, 16 Jul 2010 07:24:49 -0700 (PDT) Received: by 10.239.131.78 with SMTP id 14mr62653hbm.177.1279290289013; Fri, 16 Jul 2010 07:24:49 -0700 (PDT) From: Yoav Ben-Yehezkel References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com> <4E412745-A553-46AE-979E-04D5831ECB8A@cisco.com> In-Reply-To: <4E412745-A553-46AE-979E-04D5831ECB8A@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcskuDo/X5UH/vulR1OCSdjs/ckwbQAOZQmw Date: Fri, 16 Jul 2010 17:24:43 +0300 Message-ID: <72ef8967d1e60455d69a2e1df5c260d3@mail.gmail.com> To: JP Vasseur Content-Type: multipart/alternative; boundary=001485f44d443dc2a2048b81fb68 Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:24:40 -0000 --001485f44d443dc2a2048b81fb68 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks JP =96 I=92m in favor of leaving something about DODAG selection. Even if it=92s a= lmost straight-forward, as an implementer I would expect to have something about it. Are there restrictions on how not to select the DODAG that should be added? Thanks, Yoav *From:* JP Vasseur [mailto:jpv@cisco.com] *Sent:* Friday, July 16, 2010 10:27 AM *To:* Yoav Ben-Yehezkel *Cc:* ROLL WG *Subject:* Re: [Roll] Comment Section 7.4 Hi, On Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote: I understand why joining based on RPLInstanceIDs should be must =96 this = is an application requirement. However, being able to support a certain OCP in an RPLInstance that is not required by my application, seems a little confusing to me. Also, I=92m not sure - where are =93destinations compatible with their =85= =94 advertised? Yes, please see the previous reply on the list. Tell us what you prefer. Thanks. JP. Thanks, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *JP Vasseur *Sent:* Thursday, July 15, 2010 2:15 PM *To:* ROLL WG *Subject:* [Roll] Comment Section 7.4 Section 7.4 7.4. DODAG Selection The DODAG selection is implementation and OF dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. I would advocate for a MUST there. Thought? JP. --001485f44d443dc2a2048b81fb68 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks JP =96

I=92m in favor of leaving something about DODAG selection. E= ven if it=92s almost straight-forward, as an implementer I would expect to have something about it.

Are there restrictions on how not to select the DODAG that s= hould be added?

=A0

Thanks,

Yoav

=A0

=A0

From: JP Vasse= ur [mailto:jpv@cisco.com]
Sent: Friday, July 16, 2010 10:27 AM
To: Yoav Ben-Yehezkel
Cc: ROLL WG
Subject: Re: [Roll] Comment Section 7.4

=A0

Hi,

=A0

On Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote= :



I understand why joining based on RPLInstanceIDs should be m= ust =96 this is an application requirement.<= /span>

=A0

However, being able to support a certain OCP in an RPLInstan= ce that is not required by my application, seems a little confusing to me.

=A0

Also, I=92m not sure - where are =93destinations compatible with their =85=94 advertised?=

=A0

=A0

Yes, please see the previous reply on the list. Tell= us what you prefer.

=A0

Thanks.

=A0

JP.



Thanks,

Yoav

=A0

=A0

From:=A0roll-bounces@ietf.org=A0[mailto:roll-= bounces@ietf.org]=A0On = Behalf Of=A0JP Vasseur
Sent:=A0Thursday, July = 15, 2010 2:15 PM
To:=A0ROLL WG
Subject:=A0[Roll] Comme= nt Section 7.4

=A0

Section 7.4

=A0

7.4.=A0 DODAG Selection
=A0
=A0=A0 The DODA=
G selection is implementation and OF dependent.=A0 Nodes SHOULD

=A0=A0 prefer to join DODAGs for RPLInstan=
ceIDs advertising OCPs and
=A0=
=A0 destinations compatible with their implementation specific
=

=A0=A0 objectives.

=A0

I would advocate for a M= UST there.

=A0

Thought?

=A0

JP.

=A0

--001485f44d443dc2a2048b81fb68-- From pthubert@cisco.com Fri Jul 16 07:26:09 2010 Return-Path: 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 58EA43A6915 for ; Fri, 16 Jul 2010 07:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FEI0U5M5+lDZ for ; Fri, 16 Jul 2010 07:26:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7D7863A6821 for ; Fri, 16 Jul 2010 07:26:07 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF4IQEyrR7Ht/2dsb2JhbACfaXGkRZpohSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="344605330" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2010 14:26:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GEPYmd014554; Fri, 16 Jul 2010 14:26:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:26:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 16:26:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574A8F@XMB-AMS-107.cisco.com> In-Reply-To: <4C3F395D.1050409@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option thread-index: AcskPBx3Ans5PGoCSMOo8kG032G7jgAtoNqQ References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com> <4C3F395D.1050409@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" , X-OriginalArrivalTime: 16 Jul 2010 14:26:16.0178 (UTC) FILETIME=[D99C5D20:01CB24F2] Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:26:09 -0000 Sure.=20 Also this text=20 4. When a node sends a DAO to one of its DAO parents, it MUST select one or more of the set, active bits in the aggregated Path Control field. The DAO it transmits to its parent MUST have these active bits set and all other active bits cleared. Can be misleading. My understanding is that attributing one or more PCF bits to one parent locks them so they cannot be passed to another parent, correct? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim > Winter > Sent: Thursday, July 15, 2010 6:38 PM > To: roll@ietf.org > Subject: Re: [Roll] Issue 59 on Transit information option >=20 >=20 >=20 > On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > > Ho! I think the confusion is that not all the parents are necessarily > > DAO parents. The DAO parents are the subset of parents to which DAO > > are sent (in storing) or about whom DAO are sent (in non storing). So > > in your example there would be only one. But the sentence can be > > improved by saying that all DAOs sent at the same time are sent with > > the same sequence in order to build multiple paths. >=20 > Yes, and it should also be clarified that if you have more DAO Parents than you > can allocate Path Control bits for a given Target, then some of those Parents > will be left out of getting a DAO for that Target. >=20 > -Tim >=20 >=20 >=20 > > > > Pascal > > > > *From:* Mathilde Durvy (mdurvy) > > *Sent**:* Thursday, July 15, 2010 2:43 PM > > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > > *Cc:* 'roll@ietf.org' > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > Hi Pascal, > > > > To answer your question: > > > > - It seems to me that the path control usage is incompatible with the > > sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO > > with the same DAOSequence to all other DAO parents". No? > > > > */[Pascal] The sequence that we are talking about now is probably the > > path sequence, right? Can you please elaborate on the issue?/* > > > > My point was not so much about the "sequence". What I meant is that if > > the path control has 1 bit set and you have 2 parents, you will send a > > DAO to one parent without sending "to all other parents" no? > > > > Best, > > > > Mathilde > > > > */ /* > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mardi, 13. juillet 2010 14:10 > > *To:* Mathilde Durvy (mdurvy); JP Vasseur > > *Cc:* roll@ietf.org > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > Hi Mathilde > > > > Thanks for your great help; I hope more people will follow your > > example so we can deeply clean up the spec during the round. please find > below: > > > > Thanks again for your reply. What you say makes sense although I still > > think that the separation of the fields between the target and transit > > options is somewhat arbitrary J However this is not a major issue and > > maybe at this point it's more important to clarify the specs with > > respect to the meaning / usage of the path sequence, control, and lifetime. > > > > */[Pascal] Yes; at the end of the day the path control really had to > > be in the transit with the parent. Leaving the target without any bit > > allows us to add more headers that would also qualify that target and > > thus factorise./* > > > > - In storing mode, the path control is used to limit the DAO fan-out. > > It can also be used to set a preference between routes with the > > limitation that it cannot specify two routes which are equally > > preferred (since path control bits sent to different parents have to be > disjoint). > > > > */[Pascal] We have to see that. ecmp should be acceptable. We have an > > active thread on path control, lets deal with that there./* > > > > - It seems to me that the path control usage is incompatible with the > > sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO > > with the same DAOSequence to all other DAO parents". No? > > > > */[Pascal] The sequence that we are talking about now is probably the > > path sequence, right? Can you please elaborate on the issue?/* > > > > - In the non storing mode, the path control is not used to limit the > > DAO fan-out as nodes send DAOs to only one of their DAO parents. I > > guess it can be used as a preference by the root when it computes the source > routes. > > > > */[Pascal] Yes/* > > > > - How is the path sequence processed? Given that we have already a DAO > > sequence is it possible to receive a stale path sequence? Isn't it > > redundant? > > > > */[Pascal] I expect not. But the node may have a stale state from that > > needs to be deprecated. By deprecated I mean that the router should > > stop forwarding through a node child that has last presented path > > sequence 21 as soon as another child presents sequence 22 or more for a > same target. > > This indicates that in a DAG, a new path sequence should rapidly cause > > a DAO. In a tree, that is less urgent./* > > > > - What does the lifetime represent concretely? Is it a measure of the > > lifetime of the link between the target and the transit? > > > > */[Pascal] the lifetime is important for 2 things at least:/* > > > > - Flush. A lifetime of 0 is a route flush. That is how we do no-path. > > > > - Seq number validation. The path lifetime covers the path sequence so > > that in normal operations, the path sequence should not be incremented > > by 16 during a lifetime, so we should never see path sequence numbers > > that are out of sync by more than 16. > > > > It's a lot of questions, but I hope it will help make the DAO part > > clearer to everybody! > > > > */[Pascal] including the editors since the doc belongs to the group./* > > > > Best, > > > > Mathilde > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mercredi, 7. juillet 2010 09:22 > > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Mathilde, > > > > 1) In storing mode, the transit information "parent address" is not > > used > > > > You're correct on that with the current spec. > > > > I'm pointing out that in some cases we are missing the info for the > > tunnel endpoint and that it might become handy to indicate a RPL > > router to which a target host is attached. > > > > 2) Hence the pattern would be (Target+) for storing and > > (Target+,Transit+)+ for non-storing. > > > > We want to factorise: in non-storing mode, the target can have > > multiple parents each one with a different path control. > > > > In storing mode, a router with multiple interfaces can place multiple > > targets for all its addresses and then only one transit info that is > > common to them all. > > > > Pascal > > > > *From:* Mathilde Durvy (mdurvy) > > *Sent:* Tuesday, July 06, 2010 4:47 PM > > *To:* Pascal Thubert (pthubert); 'ROLL WG' > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Pascal, > > > > My point is a bit different. > > > > In storing mode, the transit information "parent address" is not used. > > The only fields that are relevant in the transit information are the > > path control, sequence, and lifetime, which actually relate to the > > target prefix. So why not put these fields in the target option and > > use only the transit option when we are in non-storing mode and hence > > need to specify a parent address? > > > > Hence the pattern would be (Target+) for storing and > > (Target+,Transit+)+ for non-storing. > > > > Does this make sense? > > > > Best, > > > > Mathilde > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mardi, 6. juillet 2010 15:44 > > *To:* Mathilde Durvy (mdurvy); ROLL WG > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Mathilde: > > > > Pls note that the target identifies the final destination and the > > transit tells you about how you get there. So you can factorize > > optimally depending on what you are doing. > > > > We have issue 55 that should cover your proposed change. AS Phil > > pointed out, The pattern is really (Target+, Transit+)+. > > > > I tend to think that the parent is needed in storing mode to indicate > > the tunnel end point for targets outside the RPL network, like the > > proverbial dumb host attached to a RPL router. > > > > What do you think? > > > > Pascal > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > Behalf Of *Mathilde Durvy (mdurvy) > > *Sent:* Tuesday, July 06, 2010 3:25 PM > > *To:* ROLL WG > > *Subject:* [Roll] FW: Transit information option > > > > Hi All, > > > > I didn't see these comments addressed in the new draft. Any reason? > > > > For point 2, I would go even further and propose to put the path > > sequence, control, and lifetime fields in the Target option and keep > > only the parent address field in the Transit option. > > > > Let me add that the sentence "In a DIO, the RPL Target Option > > identifies a resource that the root is trying to reach" should be > > removed if I believe the list of options allowed for DIO. > > > > Best, > > > > Mathilde > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > Behalf Of *Mathilde Durvy (mdurvy) > > *Sent:* vendredi, 18. juin 2010 11:09 > > *To:* Philip Levis > > *Cc:* roll@ietf.org > > *Subject:* Re: [Roll] Transit information option > > > > Hi All, > > > > I just looked at the updated draft and most of the comments below have > > been addresses / clarified. Just a few rather minor points: > > > > - Section 5.7.7. RPL Target. Based on the discussion below I would > > change "A set of one or more Transit Information options MAY directly > > follow the Target option in a DAO message" to "a RPL Target Option in > > a unicast DAO MUST be followed by a set of one or more Transit > > Information Option ". > > > > - If the Path-Sequence / Control fields are indeed used both in > > storing (where I have doubts they are really needed) and non-storing > > mode, why not put them in the target option rather than in the transit option. > > This way we could maybe only use only the target option in storing > > mode and the target+transit option in non-storing mode. This would > > have the additional benefit of making the parent address mandatory in > > the transit information option and thus avoid a variable length option. > > > > Best, > > > > Mathilde > > > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > > *Sent:* vendredi, 11. juin 2010 18:10 > > *To:* Mathilde Durvy (mdurvy) > > *Cc:* roll@ietf.org > > *Subject:* Re: [Roll] Transit information option > > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > > Hi Phil, > > > > Thanks a lot for your answer. Here are my comments: > > > > A few items that might be worth clarifying in version 09: > > > > - "Transit Information options MAY directly follow the Target option" > > Is it really a MAY? If not included it means the path sequence / > > control / lifetime are not specified (which seems to contradict section > 7.1.4.2). > > > > In non-storing mode, it is definitely a MUST. Storing mode seems like > > it is a MUST as well... > > > > I think we all agree. > > > > - "A non-storing node that has more than one DAO parent MAY include a > > Transit Information option for each DAO parent as part of the > > non-storing Destination Advertisement operation." Why would a node do > > that? If a node is sending a DAO for a specific target to e.g. 2 DAO > > parents (A and B) shouldn't he send one DAO with transit information A > > (i.e. parent address =3D A) to DAO parent A and another DAO with transit > > information B to DAO parent B? Otherwise how this would work over > > multiple hop? Maybe an example of DAO would help. > > > > - In section 7.1.5 point 2, I assume the node should add a transit > > information with its parent before passing the content of the received > > DAO. Also do the operation specified on the path control field in the > > previous section for storing node also apply in the non-storing case? > > > > These are good questions. Currently the draft is a bit unclear on > > whether > > > > 1) a DAO's transit option contains the full source route when it > > arrives at the DODAG Root, or > > > > 2) the DODAG Root receives just the last downward hops of each node, > > and stitches together source routes with this information. > > > > 1) seems like a much better idea to me. Note that if it's 2), then in > > non-storing mode node needs to send a DAO to just one DAO parent, and > > this DAO can contain the full set of last-hops. What are your thoughts? > > > > Indeed, I think the current draft is a bit unclear. My interpretation > > when reading was 1 (probably due mostly to the history of the draft). > > Now from your comments I understand what the draft is proposing, > > namely 2. Thanks for explaining. > > > > What triggered this change? > > > > It seems to me that if proper aggregation of the routes is performed > > (in particular if in the record route case you can avoid transmitting > > routes which are sub-routes of others) the two schemes could actually > > be quite similar in terms of overhead. This would need to be confirmed > > by a careful study as it could depend quite on bit on the topology. > > What is quite clear is that 2 requires more processing power than 1 as > > it needs to reassemble routes from the received information. > > > > Also concerning your last comment, I agree. The DAO produced will be > > slightly larger but we send only one DAO instead of one DAO per DAO > > parent. I think if we do that we might not really need the path > > control field, correct? > > > > -09 has a rewrite of the Downward Routes section that should make all > > of this much clearer. The answer is 2), for reasons Richard brought up > > a few months ago. In particular, if you use 1), then when a node > > changes its parent set it entire sub-DODAG must resend DAOs. This is a > > significant cost. If you use 2), then only that node needs to send a > > new DAO. > > > > - Has the advantage of having multiple DAO parents been assessed with > > respect to the added complexity? One could argue that since we take so > > much care in selecting a preferred this should be a good enough > > choice... Similar to Phil I'm getting worried about the increased complexity. > > > > But note that in upward routes, there's a parent set. The concern is > > that the vagaries and unreliability of wireless links call for > > supporting some degree of path diversity. Most protocols today > > maintain multiple candidate next hops for this exact reason. Because > > downward routes start at the endpoints, there needs to be some way to > > establish multiple routes. Otherwise, when one link breaks and you > > have to issue a trigger to the entire sub-DODAG. > > > > I understand how this would work in the storing case but in the > > non-storing case how would you know at the root that the path failed? > > > > ICMP error. > > > > 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 pthubert@cisco.com Fri Jul 16 07:28:27 2010 Return-Path: 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 B8A5B3A6925 for ; Fri, 16 Jul 2010 07:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.334 X-Spam-Level: X-Spam-Status: No, score=-10.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 1eiXdefTPjRt for ; Fri, 16 Jul 2010 07:28:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4120B3A6A2B for ; Fri, 16 Jul 2010 07:28:23 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208,217";a="344606442" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2010 14:28:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GESV9A017291; Fri, 16 Jul 2010 14:28:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:28:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB24F3.2A3E9980" Date: Fri, 16 Jul 2010 16:28:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574A94@XMB-AMS-107.cisco.com> In-Reply-To: <72ef8967d1e60455d69a2e1df5c260d3@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comment Section 7.4 thread-index: AcskuDo/X5UH/vulR1OCSdjs/ckwbQAOZQmwAABIX4A= References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com><4E412745-A553-46AE-979E-04D5831ECB8A@cisco.com> <72ef8967d1e60455d69a2e1df5c260d3@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "JP Vasseur" X-OriginalArrivalTime: 16 Jul 2010 14:28:33.0010 (UTC) FILETIME=[2B2B4520:01CB24F3] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:28:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB24F3.2A3E9980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav: =20 A node that does not know the OCP might misbehave and generate misleading routing information. So it can only join as a leaf. I think we have text on that. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: Friday, July 16, 2010 4:25 PM To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 =20 Thanks JP -=20 I'm in favor of leaving something about DODAG selection. Even if it's almost straight-forward, as an implementer I would expect to have something about it.=20 Are there restrictions on how not to select the DODAG that should be added?=20 =20 Thanks, Yoav =20 =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Friday, July 16, 2010 10:27 AM To: Yoav Ben-Yehezkel Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 =20 Hi, =20 On Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote: =20 I understand why joining based on RPLInstanceIDs should be must - this is an application requirement. =20 However, being able to support a certain OCP in an RPLInstance that is not required by my application, seems a little confusing to me. =20 Also, I'm not sure - where are "destinations compatible with their ..." advertised? =20 =20 Yes, please see the previous reply on the list. Tell us what you prefer. =20 Thanks. =20 JP. =20 Thanks, Yoav =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, July 15, 2010 2:15 PM To: ROLL WG Subject: [Roll] Comment Section 7.4 =20 Section 7.4 =20 7.4. DODAG Selection =20 The DODAG selection is implementation and OF dependent. Nodes SHOULD prefer to join DODAGs for RPLInstanceIDs advertising OCPs and destinations compatible with their implementation specific objectives. =20 I would advocate for a MUST there. =20 Thought? =20 JP. =20 ------_=_NextPart_001_01CB24F3.2A3E9980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav:

 

A node that does not know the OCP might misbehave and generate = misleading routing information. So it can only join as a leaf. I think = we have text on that.

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of Yoav Ben-Yehezkel
Sent: Friday, July 16, 2010 = 4:25 PM
To: JP Vasseur
Cc: ROLL = WG
Subject: Re: [Roll] Comment Section = 7.4

 

Thanks JP –

I’m in favor of leaving something about DODAG selection. Even = if it’s almost straight-forward, as an implementer I would expect = to have something about it.

Are there restrictions on how not to select the DODAG that should be = added?

 

Thanks,

Yoav

 

 

From:= = JP Vasseur [mailto:jpv@cisco.com] =
Sent: Friday, July 16, 2010 10:27 AM
To: Yoav = Ben-Yehezkel
Cc: ROLL WG
Subject: Re: [Roll] Comment = Section 7.4

 

Hi,

 

On = Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel = wrote:

 

I understand why joining based on RPLInstanceIDs should be must = – this is an application = requirement.

 

However, being able to support a certain OCP in an RPLInstance that = is not required by my application, seems a little confusing to = me.

 

Also, I’m not sure - where are “destinations compatible = with their …” advertised?

 

 

Yes, please see the previous reply on the list. Tell = us what you prefer.

 

Thanks.

 

JP.

 

Thanks,

Yoav

 

 

= From:=  = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Thursday, July 15, 2010 2:15 = PM
To: ROLL = WG
Subject: [Roll] Comment Section = 7.4

 

Section = 7.4

 

7.4.  DODAG =
Selection
 
   The DODAG selection is implementation =
and OF dependent.  Nodes SHOULD
   prefer to join DODAGs for =
RPLInstanceIDs advertising OCPs and
   destinations compatible with their =
implementation specific
   =
objectives.

 

I would advocate for a = MUST there.

 

Thought?

 

JP.

 

------_=_NextPart_001_01CB24F3.2A3E9980-- From jpv@cisco.com Fri Jul 16 07:31:52 2010 Return-Path: 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 44BB73A6947 for ; Fri, 16 Jul 2010 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 o3FR2jLqluIe for ; Fri, 16 Jul 2010 07:31:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6DA793A6A7D for ; Fri, 16 Jul 2010 07:31:37 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAIsJQEyrR7H+/2dsb2JhbACBQ54mcaQ9mmiFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208,217";a="344608785" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2010 14:31:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6GEV73b022090; Fri, 16 Jul 2010 14:31:46 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:31:27 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:31:26 +0200 Message-Id: <4AC34A92-58EA-4990-AD2A-B6D502D30FB5@cisco.com> From: JP Vasseur To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574A94@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-101-335751517 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 16:31:02 +0200 References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com> <25bdcfe052e31b849a92150f1c9ca75f@mail.gmail.com><4E412745-A553-46AE-979E-04D5831ECB8A@cisco.com> <72ef8967d1e60455d69a2e1df5c260d3@mail.gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D02574A94@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 14:31:26.0887 (UTC) FILETIME=[92CECB70:01CB24F3] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:31:52 -0000 --Apple-Mail-101-335751517 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On Jul 16, 2010, at 4:28 PM, Pascal Thubert (pthubert) wrote: > Hi Yoav: > > A node that does not know the OCP might misbehave and generate =20 > misleading routing information. So it can only join as a leaf. I =20 > think we have text on that. Right. > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Yoav Ben-Yehezkel > Sent: Friday, July 16, 2010 4:25 PM > To: JP Vasseur > Cc: ROLL WG > Subject: Re: [Roll] Comment Section 7.4 > > Thanks JP =96 > I=92m in favor of leaving something about DODAG selection. Even if =20 > it=92s almost straight-forward, as an implementer I would expect to =20= > have something about it. > Are there restrictions on how not to select the DODAG that should be =20= > added? > > Thanks, > Yoav > > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Friday, July 16, 2010 10:27 AM > To: Yoav Ben-Yehezkel > Cc: ROLL WG > Subject: Re: [Roll] Comment Section 7.4 > > Hi, > > On Jul 15, 2010, at 1:30 PM, Yoav Ben-Yehezkel wrote: > > > I understand why joining based on RPLInstanceIDs should be must =96 =20= > this is an application requirement. > > However, being able to support a certain OCP in an RPLInstance that =20= > is not required by my application, seems a little confusing to me. > > Also, I=92m not sure - where are =93destinations compatible with their = =20 > =85=94 advertised? > > > Yes, please see the previous reply on the list. Tell us what you =20 > prefer. > > Thanks. > > JP. > > > Thanks, > Yoav > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of JP Vasseur > Sent: Thursday, July 15, 2010 2:15 PM > To: ROLL WG > Subject: [Roll] Comment Section 7.4 > > Section 7.4 > > 7.4. DODAG Selection > > The DODAG selection is implementation and OF dependent. Nodes =20 > SHOULD > prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > destinations compatible with their implementation specific > objectives. > > I would advocate for a MUST there. > > Thought? > > JP. > --Apple-Mail-101-335751517 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi,

On Jul = 16, 2010, at 4:28 PM, Pascal Thubert (pthubert) wrote:

Hi = Yoav:
A = node that does not know the OCP might misbehave and generate misleading = routing information. So it can only join as a leaf. I think we have text = on that.
Hi,
 
On Jul 15, 2010, at 1:30 = PM, Yoav Ben-Yehezkel wrote:

 

I = understand why joining based on RPLInstanceIDs should be must =96 this = is an application requirement.
Also, = I=92m not sure - where are =93destinations compatible with their =85=94 = advertised?
Yes, please see the = previous reply on the list. Tell us what you = prefer.
Yoav
From:roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Thursday, July 15, 2010 = 2:15 PM
To: ROLL = WG
Subject: [Roll] Comment Section = 7.4
 
Section = 7.4
 
7.4.  DODAG Selection
 
   The DODAG selection is =
implementation and OF dependent.  Nodes =
SHOULD
I would advocate for a MUST =
there.
 

= --Apple-Mail-101-335751517-- From jpv@cisco.com Fri Jul 16 07:32:20 2010 Return-Path: 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 676D03A6A83 for ; Fri, 16 Jul 2010 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vQxQZnGLrI5e for ; Fri, 16 Jul 2010 07:32:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D95003A6A8B for ; Fri, 16 Jul 2010 07:31:40 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIsJQEyrR7Ht/2dsb2JhbACfaXGkPZpohSQEiFCCNA X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="344608903" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2010 14:31:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GEVlOw020917; Fri, 16 Jul 2010 14:31:52 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:31:51 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:31:51 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D025748E7@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 16:31:26 +0200 References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com><871vb4hl2u.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D025748E7@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 14:31:51.0075 (UTC) FILETIME=[A1399730:01CB24F3] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:32:20 -0000 On Jul 16, 2010, at 11:45 AM, Pascal Thubert (pthubert) wrote: > I'd remove the uppercase and say that the application is expected to > have some out of scope policy to decide which OCP/OF it should join, > in > terms such as white list, black list, preference and maximum number. Great: this is already covered in Section 16 :) > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP >> Vasseur >> Sent: Friday, July 16, 2010 9:25 AM >> To: ROLL WG; Richard Kelsey >> Subject: Re: [Roll] Comment Section 7.4 >> >> Hi Richard, >> >> On Jul 15, 2010, at 4:32 PM, Richard Kelsey wrote: >> >>>> From: JP Vasseur >>>> Date: Thu, 15 Jul 2010 13:14:40 +0200 Section 7.4 >>>> >>>> 7.4. DODAG Selection >>>> >>>> The DODAG selection is implementation and OF dependent. Nodes >>>> SHOULD >>>> prefer to join DODAGs for RPLInstanceIDs advertising OCPs and >>>> destinations compatible with their implementation specific >>>> objectives. >>>> >>>> I would advocate for a MUST there. >>> >>> I don't think there is any point in this sentence, whether it is a >>> SHOULD or a MUST. Given that the "implementation specific > objectives" >>> are entirely implementation specific, what would it mean to require >>> that the node act compatibly with them? This sentence is equivalent >>> to: >>> Implementations SHOULD/MUST act in a fashion compatible with their >>> objectives. >>> While I would hope this to be true, we cannot meaningfully require > it. >> >> That was my point. We are stating the obvious so we should either: >> 1) Remove the sentence completely. >> 2) Make it a MUST >> >> Agree ? >> >> I guess that you choose 1). >> >> Others ? >> >>> -Richard Kelsey >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri Jul 16 07:47:46 2010 Return-Path: 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 DD36D3A69E7 for ; Fri, 16 Jul 2010 07:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 bbT+JATVv0Pg for ; Fri, 16 Jul 2010 07:47:45 -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 5D22B3A69DD for ; Fri, 16 Jul 2010 07:47:45 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAP8NQEyrR7Hu/2dsb2JhbACBQ54mcaRtmmmFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208,217";a="560148896" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2010 14:47:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6GEls9b015846 for ; Fri, 16 Jul 2010 14:47:56 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:47:56 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 16:47:55 +0200 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0257491A@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-109-336740254 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 16:47:30 +0200 References: <89DE0D01-5A7F-47E5-B930-A5804453AF58@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0257491A@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 14:47:55.0977 (UTC) FILETIME=[E059F390:01CB24F5] Cc: ROLL WG Subject: Re: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC 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: , X-List-Received-Date: Fri, 16 Jul 2010 14:47:47 -0000 --Apple-Mail-109-336740254 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable oops ! I think that we're not talking about the same thing. By "tag" I was referring to route-tag not tags for label switching: =20 something we may want to work on at some point BUT we would need to =20 revisit our charter. Something we'll bring to the list soon, after the =20= RPL LC, OK ? I was referring to using route-tags as a flag field to color the route =20= if you will. Thoughts ? On Jul 16, 2010, at 12:16 PM, Pascal Thubert (pthubert) wrote: > Hi JP: > > JP> I do not think that I would mandate for "all destinations", it =20 > could be for a subset > according to some policy (remember the route tag ?). > > [Pascal] The problem is that we do not know a priori whether a =20 > target is also a parent since that comes in another DAO. If it is a =20= > parent then we need to store it to be able to build the source route =20= > path to and via its children. If the root now has a policy to refuse =20= > a DAO, then it needs to indicate so in the DAO Ack so that the node =20= > can branch elsewhere. All this process including err codes would =20 > have to be documented. At the moment we expect that the network is =20 > dimensioned and operated in such a fashion that the root can accept =20= > all nodes that are able to join. > > JP> At some point we had the possibility to add tags to route (to =20 > indicate a priority, etc, ...). > Note extensively used in other routing protocols too. Don't you =20 > think that it would be wise > adding them back (this is a simply field of flags). > > [Pascal] I=92d love it. The thing is that the tag is used by the =20 > parent to indicate the next hop. Usually it is locally significant =20 > to the parent. > At the moment, the child indicates its parents in the DAO but =20 > wouldn=92t know the tag that the parent would affect to it. > > If we=92re taking the path of tagging, then we might need a flow to =20= > get the tag from the parent, for instance using an ND extension. > As the parent learns about the child and creates an NC Entry, it =20 > also assigns a tag associated to that Neighbor, and passes it to the =20= > child as a source or target tag option depending on the ND message =20 > being used. > > For RPL, all we=92d need to do is enable the tagging by adding room =20= > for a tag to the transit option. I=92m really positive. > > Votes?. > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of JP Vasseur > Sent: Friday, July 16, 2010 9:10 AM > To: ROLL WG > Subject: [Roll] Comments on Route-Tags - RPL Version 10 - WG LC > > Dear all, > > One comment: > > 8.2. Downward Route Discovery and Maintenance > > Destination Advertisement may be configured to be entirely =20 > disabled, > or operate in either a storing or non-storing mode, as reported in > > > > Winter, et al. Expires December 30, 2010 [Page =20= > 62] > > Internet-Draft draft-ietf-roll-rpl-10 Jun =20= > 2010 > > > the MOP in the DIO message. > > 1. All nodes who join a DODAG MUST abide by the MOP setting from =20= > the > root. Nodes that do not have the capability to fully =20 > participate > as a router MAY join the DODAG as a leaf. > 2. If the MOP is 000, indicating no downward routing, nodes MUST =20= > NOT > transmit DAO messages, and MAY ignore DAO messages. > > 3. In non-storing mode, the DODAG Root MUST store source routing > table entries for all destinations learned from DAOs. > JP> I do not think that I would mandate for "all destinations", it =20 > could be for a subset > according to some policy (remember the route tag ?). > At some point we had the possibility to add tags to route (to =20 > indicate a priority, etc, ...). > Note extensively used in other routing protocols too. Don't you =20 > think that it would be wise > adding them back (this is a simply field of flags). > > Thoughts ? --Apple-Mail-109-336740254 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable oops ! I think that we're not = talking about the same thing.

By "tag" I was = referring to route-tag not tags for label switching: something we may = want to work on at some point BUT we would need to revisit our charter. = Something we'll bring to the list soon, after the RPL LC, OK = ?

I was referring to using route-tags as a flag = field to color the route if you will.

Thoughts = ?

On Jul 16, 2010, at 12:16 PM, Pascal Thubert = (pthubert) wrote:

Hi = JP:
[Pascal] The problem is that we do not know a priori =
whether a target is also a parent since that comes in another DAO. If it =
is a parent then we need to store it to be able to build the source =
route path to and via its children. If the root now has a policy to =
refuse a DAO, then it needs to indicate so in the DAO Ack so that the =
node can branch elsewhere. All this process including err codes would =
have to be documented. At the moment we expect that the network is =
dimensioned  and operated in such a fashion that the root can =
accept all nodes that are able to =
join.
 
JP> At some point we had the =
possibility to add tags to route (to indicate a priority, etc, =
...).
Note extensively used =
in other routing protocols too. Don't you think that it would be =
wise 
adding them back (this =
is a simply field of flags).
[Pascal] I=92d love it. The thing is that the tag is = used by the parent to indicate the next hop. Usually it is locally = significant to the parent.
At the moment, the child = indicates its parents in the DAO but wouldn=92t know the tag that the = parent would affect to it.
If we=92re taking the path of tagging, then we might = need a flow to get the tag from the parent, for instance using an ND = extension.
As the parent learns about the child and creates an = NC Entry, it also assigns a tag associated to that Neighbor, and passes = it to the child as a source or target tag option depending on the ND = message being used.
For RPL, all we=92d need to do is enable the tagging = by adding room for a tag to the transit option. I=92m really = positive.
 
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf Of JP = Vasseur
Sent: Friday, July 16, 2010 9:10 = AM
To: ROLL = WG
Subject: [Roll] Comments on = Route-Tags - RPL Version 10 - WG = LC
Dear = all,
One = comment:
8.2.  Downward Route Discovery and = Maintenance
 
   or operate in either a =
storing or non-storing mode, as reported in
 
Winter, et =
al.          Expires =
December 30, =
2010           &nbs=
p;  [Page 62]
 
 
 
   1.  All nodes who join a =
DODAG MUST abide by the MOP setting from the
   2.  If the MOP is 000, indicating no =
downward routing, nodes MUST NOT
 
       =
table entries for all destinations learned from =
DAOs.
JP> I do not think that I =
would mandate for "all destinations", it could be for a =
subset 
At some point we had =
the possibility to add tags to route (to indicate a priority, etc, =
...).
Note extensively used =
in other routing protocols too. Don't you think that it would be =
wise 
adding them back (this =
is a simply field of flags).
Thoughts =
?

= --Apple-Mail-109-336740254-- From pthubert@cisco.com Fri Jul 16 08:02:58 2010 Return-Path: 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 ECA153A688D for ; Fri, 16 Jul 2010 08:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.342 X-Spam-Level: X-Spam-Status: No, score=-10.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VWsgJN9V4t0M for ; Fri, 16 Jul 2010 08:02: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 810833A686C for ; Fri, 16 Jul 2010 08:02:57 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="133234319" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2010 15:03:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GF302l010240; Fri, 16 Jul 2010 15:03:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 17:03:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 16:59:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574ABB@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Comment Section 7.4 thread-index: Acsk86E5vWGHoOFrRaWjm5ArMkfkRwAAs0kA References: <6593641D-BDA1-459C-B776-EC04259884BB@cisco.com><871vb4hl2u.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D025748E7@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 16 Jul 2010 15:03:00.0799 (UTC) FILETIME=[FBAAD4F0:01CB24F7] Cc: ROLL WG Subject: Re: [Roll] Comment Section 7.4 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: , X-List-Received-Date: Fri, 16 Jul 2010 15:02:59 -0000 Pretty much: The text is actually present for the metrics and instance ID. Maybe we could add similar wording for the OCP though it seems quite obvious... o RPLInstanceID [DIO message, in DIO base message]. Although the RPLInstanceID must be configured on the DODAG root, it must also be configured as a policy on every node in order to determine whether or not the node should join a particular DODAG. Note that a second RPLInstance can be configured on the node, should it become root of a floating DODAG. o Objective Code Point (OCP) o List of supported metrics: [I-D.ietf-roll-routing-metrics] specifies a number of metrics and constraints used for the DODAG formation. Thus a RPL implementation should allow configuring the list of metrics that a node can accept and understand. If a DIO is received with a metric and/or constraint that is not understood or supported, as specified in Section 7.5, the node would join as a leaf node. Pascal > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Friday, July 16, 2010 4:31 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG; Richard Kelsey > Subject: Re: [Roll] Comment Section 7.4 >=20 >=20 > On Jul 16, 2010, at 11:45 AM, Pascal Thubert (pthubert) wrote: >=20 > > I'd remove the uppercase and say that the application is expected to > > have some out of scope policy to decide which OCP/OF it should join, > > in terms such as white list, black list, preference and maximum > > number. >=20 > Great: this is already covered in Section 16 :) >=20 > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of JP > >> Vasseur > >> Sent: Friday, July 16, 2010 9:25 AM > >> To: ROLL WG; Richard Kelsey > >> Subject: Re: [Roll] Comment Section 7.4 > >> > >> Hi Richard, > >> > >> On Jul 15, 2010, at 4:32 PM, Richard Kelsey wrote: > >> > >>>> From: JP Vasseur > >>>> Date: Thu, 15 Jul 2010 13:14:40 +0200 Section 7.4 > >>>> > >>>> 7.4. DODAG Selection > >>>> > >>>> The DODAG selection is implementation and OF dependent. Nodes > >>>> SHOULD > >>>> prefer to join DODAGs for RPLInstanceIDs advertising OCPs and > >>>> destinations compatible with their implementation specific > >>>> objectives. > >>>> > >>>> I would advocate for a MUST there. > >>> > >>> I don't think there is any point in this sentence, whether it is a > >>> SHOULD or a MUST. Given that the "implementation specific > > objectives" > >>> are entirely implementation specific, what would it mean to require > >>> that the node act compatibly with them? This sentence is equivalent > >>> to: > >>> Implementations SHOULD/MUST act in a fashion compatible with their > >>> objectives. > >>> While I would hope this to be true, we cannot meaningfully require > > it. > >> > >> That was my point. We are stating the obvious so we should either: > >> 1) Remove the sentence completely. > >> 2) Make it a MUST > >> > >> Agree ? > >> > >> I guess that you choose 1). > >> > >> Others ? > >> > >>> -Richard Kelsey > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Jul 16 08:10:35 2010 Return-Path: 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 2F7863A6992 for ; Fri, 16 Jul 2010 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9iSjmQaLx-ri for ; Fri, 16 Jul 2010 08:10:32 -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 D14B43A68E8 for ; Fri, 16 Jul 2010 08:10:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG0TQExAZnwM/2dsb2JhbACfaXGlDZpnhSQEiwQ X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="133262883" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 15:10:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6GFAgnd013296; Fri, 16 Jul 2010 15:10:42 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 17:10:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 17:10:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574AC7@XMB-AMS-107.cisco.com> In-Reply-To: <4C3F395D.1050409@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option thread-index: AcskPBx3Ans5PGoCSMOo8kG032G7jgAtQ4EQ References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com> <4C3F395D.1050409@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" , X-OriginalArrivalTime: 16 Jul 2010 15:10:42.0492 (UTC) FILETIME=[0EDB97C0:01CB24F9] Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Fri, 16 Jul 2010 15:10:35 -0000 Apart from the clarification, I'd really like to enable Equal Cost Multipath as Mathilde suggested. Could we say that 2 consecutive bits 0-1, 2-3, 4-5, and 6-7 represent paths of equal preference? That leaves us 4 degrees of preference which is probably enough. Ideas? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim > Winter > Sent: Thursday, July 15, 2010 6:38 PM > To: roll@ietf.org > Subject: Re: [Roll] Issue 59 on Transit information option >=20 >=20 >=20 > On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > > Ho! I think the confusion is that not all the parents are necessarily > > DAO parents. The DAO parents are the subset of parents to which DAO > > are sent (in storing) or about whom DAO are sent (in non storing). So > > in your example there would be only one. But the sentence can be > > improved by saying that all DAOs sent at the same time are sent with > > the same sequence in order to build multiple paths. >=20 > Yes, and it should also be clarified that if you have more DAO Parents than you > can allocate Path Control bits for a given Target, then some of those Parents > will be left out of getting a DAO for that Target. >=20 > -Tim >=20 >=20 >=20 > > > > Pascal > > > > *From:* Mathilde Durvy (mdurvy) > > *Sent**:* Thursday, July 15, 2010 2:43 PM > > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > > *Cc:* 'roll@ietf.org' > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > Hi Pascal, > > > > To answer your question: > > > > - It seems to me that the path control usage is incompatible with the > > sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO > > with the same DAOSequence to all other DAO parents". No? > > > > */[Pascal] The sequence that we are talking about now is probably the > > path sequence, right? Can you please elaborate on the issue?/* > > > > My point was not so much about the "sequence". What I meant is that if > > the path control has 1 bit set and you have 2 parents, you will send a > > DAO to one parent without sending "to all other parents" no? > > > > Best, > > > > Mathilde > > > > */ /* > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mardi, 13. juillet 2010 14:10 > > *To:* Mathilde Durvy (mdurvy); JP Vasseur > > *Cc:* roll@ietf.org > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > Hi Mathilde > > > > Thanks for your great help; I hope more people will follow your > > example so we can deeply clean up the spec during the round. please find > below: > > > > Thanks again for your reply. What you say makes sense although I still > > think that the separation of the fields between the target and transit > > options is somewhat arbitrary J However this is not a major issue and > > maybe at this point it's more important to clarify the specs with > > respect to the meaning / usage of the path sequence, control, and lifetime. > > > > */[Pascal] Yes; at the end of the day the path control really had to > > be in the transit with the parent. Leaving the target without any bit > > allows us to add more headers that would also qualify that target and > > thus factorise./* > > > > - In storing mode, the path control is used to limit the DAO fan-out. > > It can also be used to set a preference between routes with the > > limitation that it cannot specify two routes which are equally > > preferred (since path control bits sent to different parents have to be > disjoint). > > > > */[Pascal] We have to see that. ecmp should be acceptable. We have an > > active thread on path control, lets deal with that there./* > > > > - It seems to me that the path control usage is incompatible with the > > sentence "If a node sends a DAO to one DAO parent, it MUST send a DAO > > with the same DAOSequence to all other DAO parents". No? > > > > */[Pascal] The sequence that we are talking about now is probably the > > path sequence, right? Can you please elaborate on the issue?/* > > > > - In the non storing mode, the path control is not used to limit the > > DAO fan-out as nodes send DAOs to only one of their DAO parents. I > > guess it can be used as a preference by the root when it computes the source > routes. > > > > */[Pascal] Yes/* > > > > - How is the path sequence processed? Given that we have already a DAO > > sequence is it possible to receive a stale path sequence? Isn't it > > redundant? > > > > */[Pascal] I expect not. But the node may have a stale state from that > > needs to be deprecated. By deprecated I mean that the router should > > stop forwarding through a node child that has last presented path > > sequence 21 as soon as another child presents sequence 22 or more for a > same target. > > This indicates that in a DAG, a new path sequence should rapidly cause > > a DAO. In a tree, that is less urgent./* > > > > - What does the lifetime represent concretely? Is it a measure of the > > lifetime of the link between the target and the transit? > > > > */[Pascal] the lifetime is important for 2 things at least:/* > > > > - Flush. A lifetime of 0 is a route flush. That is how we do no-path. > > > > - Seq number validation. The path lifetime covers the path sequence so > > that in normal operations, the path sequence should not be incremented > > by 16 during a lifetime, so we should never see path sequence numbers > > that are out of sync by more than 16. > > > > It's a lot of questions, but I hope it will help make the DAO part > > clearer to everybody! > > > > */[Pascal] including the editors since the doc belongs to the group./* > > > > Best, > > > > Mathilde > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mercredi, 7. juillet 2010 09:22 > > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Mathilde, > > > > 1) In storing mode, the transit information "parent address" is not > > used > > > > You're correct on that with the current spec. > > > > I'm pointing out that in some cases we are missing the info for the > > tunnel endpoint and that it might become handy to indicate a RPL > > router to which a target host is attached. > > > > 2) Hence the pattern would be (Target+) for storing and > > (Target+,Transit+)+ for non-storing. > > > > We want to factorise: in non-storing mode, the target can have > > multiple parents each one with a different path control. > > > > In storing mode, a router with multiple interfaces can place multiple > > targets for all its addresses and then only one transit info that is > > common to them all. > > > > Pascal > > > > *From:* Mathilde Durvy (mdurvy) > > *Sent:* Tuesday, July 06, 2010 4:47 PM > > *To:* Pascal Thubert (pthubert); 'ROLL WG' > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Pascal, > > > > My point is a bit different. > > > > In storing mode, the transit information "parent address" is not used. > > The only fields that are relevant in the transit information are the > > path control, sequence, and lifetime, which actually relate to the > > target prefix. So why not put these fields in the target option and > > use only the transit option when we are in non-storing mode and hence > > need to specify a parent address? > > > > Hence the pattern would be (Target+) for storing and > > (Target+,Transit+)+ for non-storing. > > > > Does this make sense? > > > > Best, > > > > Mathilde > > > > *From:* Pascal Thubert (pthubert) > > *Sent:* mardi, 6. juillet 2010 15:44 > > *To:* Mathilde Durvy (mdurvy); ROLL WG > > *Subject:* RE: [Roll] FW: Transit information option > > > > Hi Mathilde: > > > > Pls note that the target identifies the final destination and the > > transit tells you about how you get there. So you can factorize > > optimally depending on what you are doing. > > > > We have issue 55 that should cover your proposed change. AS Phil > > pointed out, The pattern is really (Target+, Transit+)+. > > > > I tend to think that the parent is needed in storing mode to indicate > > the tunnel end point for targets outside the RPL network, like the > > proverbial dumb host attached to a RPL router. > > > > What do you think? > > > > Pascal > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > Behalf Of *Mathilde Durvy (mdurvy) > > *Sent:* Tuesday, July 06, 2010 3:25 PM > > *To:* ROLL WG > > *Subject:* [Roll] FW: Transit information option > > > > Hi All, > > > > I didn't see these comments addressed in the new draft. Any reason? > > > > For point 2, I would go even further and propose to put the path > > sequence, control, and lifetime fields in the Target option and keep > > only the parent address field in the Transit option. > > > > Let me add that the sentence "In a DIO, the RPL Target Option > > identifies a resource that the root is trying to reach" should be > > removed if I believe the list of options allowed for DIO. > > > > Best, > > > > Mathilde > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > Behalf Of *Mathilde Durvy (mdurvy) > > *Sent:* vendredi, 18. juin 2010 11:09 > > *To:* Philip Levis > > *Cc:* roll@ietf.org > > *Subject:* Re: [Roll] Transit information option > > > > Hi All, > > > > I just looked at the updated draft and most of the comments below have > > been addresses / clarified. Just a few rather minor points: > > > > - Section 5.7.7. RPL Target. Based on the discussion below I would > > change "A set of one or more Transit Information options MAY directly > > follow the Target option in a DAO message" to "a RPL Target Option in > > a unicast DAO MUST be followed by a set of one or more Transit > > Information Option ". > > > > - If the Path-Sequence / Control fields are indeed used both in > > storing (where I have doubts they are really needed) and non-storing > > mode, why not put them in the target option rather than in the transit option. > > This way we could maybe only use only the target option in storing > > mode and the target+transit option in non-storing mode. This would > > have the additional benefit of making the parent address mandatory in > > the transit information option and thus avoid a variable length option. > > > > Best, > > > > Mathilde > > > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > > *Sent:* vendredi, 11. juin 2010 18:10 > > *To:* Mathilde Durvy (mdurvy) > > *Cc:* roll@ietf.org > > *Subject:* Re: [Roll] Transit information option > > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > > Hi Phil, > > > > Thanks a lot for your answer. Here are my comments: > > > > A few items that might be worth clarifying in version 09: > > > > - "Transit Information options MAY directly follow the Target option" > > Is it really a MAY? If not included it means the path sequence / > > control / lifetime are not specified (which seems to contradict section > 7.1.4.2). > > > > In non-storing mode, it is definitely a MUST. Storing mode seems like > > it is a MUST as well... > > > > I think we all agree. > > > > - "A non-storing node that has more than one DAO parent MAY include a > > Transit Information option for each DAO parent as part of the > > non-storing Destination Advertisement operation." Why would a node do > > that? If a node is sending a DAO for a specific target to e.g. 2 DAO > > parents (A and B) shouldn't he send one DAO with transit information A > > (i.e. parent address =3D A) to DAO parent A and another DAO with transit > > information B to DAO parent B? Otherwise how this would work over > > multiple hop? Maybe an example of DAO would help. > > > > - In section 7.1.5 point 2, I assume the node should add a transit > > information with its parent before passing the content of the received > > DAO. Also do the operation specified on the path control field in the > > previous section for storing node also apply in the non-storing case? > > > > These are good questions. Currently the draft is a bit unclear on > > whether > > > > 1) a DAO's transit option contains the full source route when it > > arrives at the DODAG Root, or > > > > 2) the DODAG Root receives just the last downward hops of each node, > > and stitches together source routes with this information. > > > > 1) seems like a much better idea to me. Note that if it's 2), then in > > non-storing mode node needs to send a DAO to just one DAO parent, and > > this DAO can contain the full set of last-hops. What are your thoughts? > > > > Indeed, I think the current draft is a bit unclear. My interpretation > > when reading was 1 (probably due mostly to the history of the draft). > > Now from your comments I understand what the draft is proposing, > > namely 2. Thanks for explaining. > > > > What triggered this change? > > > > It seems to me that if proper aggregation of the routes is performed > > (in particular if in the record route case you can avoid transmitting > > routes which are sub-routes of others) the two schemes could actually > > be quite similar in terms of overhead. This would need to be confirmed > > by a careful study as it could depend quite on bit on the topology. > > What is quite clear is that 2 requires more processing power than 1 as > > it needs to reassemble routes from the received information. > > > > Also concerning your last comment, I agree. The DAO produced will be > > slightly larger but we send only one DAO instead of one DAO per DAO > > parent. I think if we do that we might not really need the path > > control field, correct? > > > > -09 has a rewrite of the Downward Routes section that should make all > > of this much clearer. The answer is 2), for reasons Richard brought up > > a few months ago. In particular, if you use 1), then when a node > > changes its parent set it entire sub-DODAG must resend DAOs. This is a > > significant cost. If you use 2), then only that node needs to send a > > new DAO. > > > > - Has the advantage of having multiple DAO parents been assessed with > > respect to the added complexity? One could argue that since we take so > > much care in selecting a preferred this should be a good enough > > choice... Similar to Phil I'm getting worried about the increased complexity. > > > > But note that in upward routes, there's a parent set. The concern is > > that the vagaries and unreliability of wireless links call for > > supporting some degree of path diversity. Most protocols today > > maintain multiple candidate next hops for this exact reason. Because > > downward routes start at the endpoints, there needs to be some way to > > establish multiple routes. Otherwise, when one link breaks and you > > have to issue a trigger to the entire sub-DODAG. > > > > I understand how this would work in the storing case but in the > > non-storing case how would you know at the root that the path failed? > > > > ICMP error. > > > > 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 jpv@cisco.com Fri Jul 16 08:18:55 2010 Return-Path: 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 27D373A688D for ; Fri, 16 Jul 2010 08:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 35dYuF5zPjrP for ; Fri, 16 Jul 2010 08:18: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 F206A3A6768 for ; Fri, 16 Jul 2010 08:18:53 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALsVQExAZnwN/2dsb2JhbACZNIY1caUNmmGFJASIUII0 X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208,217";a="133267545" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 15:19:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6GFIxZu019294 for ; Fri, 16 Jul 2010 15:19:00 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 17:18:59 +0200 Received: from dhcp-lyon-144-254-54-113.cisco.com ([144.254.54.113]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 17:18:59 +0200 Message-Id: <0882F353-0AB1-4D02-953B-EA133686D1E6@cisco.com> From: JP Vasseur To: ROLL WG In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-113-338604155 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 17:18:34 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Jul 2010 15:18:59.0583 (UTC) FILETIME=[3725A8F0:01CB24FA] Subject: [Roll] ** Slides for the ROLL WG Meeting ** Re: Agenda ROLL WG Meeting IETF-78 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: , X-List-Received-Date: Fri, 16 Jul 2010 15:18:55 -0000 --Apple-Mail-113-338604155 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, If you have a slot at the next ROLL WG meeting, *please* send us your slides no latter than July 27, noon CET. Thanks. JP. On Jul 8, 2010, at 8:53 AM, JP Vasseur wrote: > Dear all, > > Please find the agenda for the IETF-78 ROLL WG meeting: http://www.ietf.org/proceedings/78/agenda/roll.txt > > Let us know if you have comments. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-113-338604155 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

If = you have a slot at the next ROLL WG meeting, *please* send us your = slides no latter than July 27, noon = CET.

Thanks.

JP.

On Jul 8, 2010, at 8:53 AM, JP Vasseur = wrote:

Dear all,

Please = find the agenda for the IETF-78 ROLL WG meeting: http://www.iet= f.org/proceedings/78/agenda/roll.txt

Let us know if you have = comments.

JP.
______________________________= _________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-113-338604155-- From pthubert@cisco.com Fri Jul 16 08:29:20 2010 Return-Path: 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 498A13A6890 for ; Fri, 16 Jul 2010 08:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.146 X-Spam-Level: X-Spam-Status: No, score=-9.146 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 2FtaVb01Us-G for ; Fri, 16 Jul 2010 08:29:17 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 931193A688D for ; Fri, 16 Jul 2010 08:29:17 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.png, image002.gif : 6281, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4LAE8YQEyrR7H+/2dsb2JhbABzUIFbm2licaUFiS+RNAKEMHIEiwQ X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="gif'147?png'147,150?scan'147,150,208,217,147,150";a="227423348" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2010 15:29:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6GFTOHO018911 for ; Fri, 16 Jul 2010 15:29:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 17:29:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB24FB.AB562FC3" Date: Fri, 16 Jul 2010 17:29:21 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574ADA@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282E8D4@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication thread-index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybwAG+67AAAQubjABIXlUQAA+CdlA References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E8D4@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "ROLL WG" X-OriginalArrivalTime: 16 Jul 2010 15:29:24.0713 (UTC) FILETIME=[ABC0ED90:01CB24FB] Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Fri, 16 Jul 2010 15:29:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB24FB.AB562FC3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB24FB.AB562FC3" ------_=_NextPart_002_01CB24FB.AB562FC3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgTWF0aGlsZGUNCg0KIA0KDQpQYXNjYWwNCg0KIA0KDQpGcm9tOiBNYXRoaWxkZSBEdXJ2eSAo bWR1cnZ5KSANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDE1LCAyMDEwIDE6MzEgUE0NClRvOiBQYXNj YWwgVGh1YmVydCAocHRodWJlcnQpOyAnUk9MTCBXRycNClN1YmplY3Q6IFJFOiBbUm9sbF0gVXNl IG9mIHR1bm5lbHMgYW5kIGVuZCBwb2ludCBkZXRlcm1pY2F0aW9uDQoNCiANCg0KSGkgUGFzY2Fs LCBBbGwsDQoNCiANCg0KTGV0IG1lIGtub3cgaWYgdGhpcyBpcyBhIGNvcnJlY3Qgc3VtbWFyeSBv ZiB0aGUgcG9zc2libGUgY2FzZXMuIEkgYWxzbyBwdXQgc29tZSBjb21tZW50cyB0byBwb2ludCB0 aGluZ3Mgd2hlcmUgSSB0aGluayBhIGNsYXJpZmljYXRpb24gaXMgbmVlZGVkLg0KDQogDQoNCjEp ICAgIFJQTCBTICDDoCBCUiDDoCBEICAgICAgICAgICAgICAgICBObyB0dW5uZWwsIHRoZSBSUEwg c291cmNlIGFkZHMgdGhlIEhiSCBoZWFkZXIsIEJSIHJlbW92ZXMgaXQNCg0KW1Bhc2NhbF0gU3Vy cHJpc2VkIG1lIHF1aXRlIGEgYml0IGJ1dCBjb3JyZWN0LiBUaGlzIGFtZW5kcyBteSBlYXJsaWVy IG1haWwgb2YgbWluZSB3aGVyZSBJIHRob3VnaHQgd2UgaGFkIHRvIHR1bm5lbCB0aGVyZS4gTXkg c2VudGVuY2Ug4oCcUlBMIGNhbm5vdCB1c2UgdHJhbnNwb3J0IG1vZGUgdG8gYW4gZXh0ZXJuYWwg ZGVzdGluYXRpb24gYmVjYXVzZSBvZiB0aGUgdXNlIG9mIHRoZSBob3AgYnkgaG9wIG9wdGlvbuKA nSB3YXMgYXBwYXJlbnRseSB3cm9uZywgYW5kIHdlIGNhbiBsYXdmdWxseSByZW1vdmUgdGhlIGhv cCBieSBob3AgaW5zaWRlIHRoZSBwYWNrZXQuDQoNCiANCg0KMikgICAgUyDDoCBSUEwgUiDDoCBC UiDDoCBEICAgICAgICAgVHVubmVsLiBSIGludHJvZHVjZXMgbmV3IElQdjYgaGVhZGVyIHdpdGgg SGJIIGhlYWRlciwgUiBpcyB0aGUgSVB2NiBzb3VyY2UsIEJSIHRoZSBJUHY2IGRlc3QuIEJSIHJl bW92ZXMgdGhpcyBoZWFkZXIuIA0KDQpDb21tZW50OiBJZiBCUiBpcyB0aGUgZW5kIG9mIHRoZSB0 dW5uZWwsIGl0cyBhZGRyZXNzIG5lZWRzIHRvIGJlIGtub3duIGJ5IFIuIEhvdyBkb2VzIHRoYXQg d29yaz8gVGhpcyB3b3VsZCBmYXZvciBhbiBhcHByb2FjaCB3aGVyZSB0aGUgRE9EQUdJRCBtdXN0 IGJlIHRoZSBnbG9iYWwgSVB2NiBhZGRyZXNzIG9mIHRoZSByb290DQoNCltQYXNjYWxdIENvcnJl Y3QsIHRob3VnaCB3ZSBkbyBub3QgcmVhbGx5IHdlbGwgc3VwcG9ydCBhIGhvc3QgYXR0YWNoZWQg dG8gdGhlIFJQTCBuZXR3b3JrLiBJbiBwYXJ0aWN1bGFyIHRoZSBsYWNrIG9mIERBTyBzZXF1ZW5j ZSBldGPigKYgDQoNCk1ha2Ugc2Vuc2UgdG8gbWUgZm9yIGFsbCBub2RlcyB0byBiZSBsZWF2ZXMu DQoNCiANCg0KMykgICAgUlBMIEQgw58gQlIgw58gUyAgICAgICAgICAgICAgICAgIFR1bm5lbC4g QlIgaW50cm9kdWNlcyBuZXcgSVB2NiBoZWFkZXIgd2l0aCBIYkggaGVhZGVyIGFuZCBSSCAobm9u LXN0b3JpbmcgbW9kZSBvbmx5KSwgQlIgaXMgdGhlIElQdjYgc291cmNlLCBhbmQgUlBMIEQgdGhl IGZpbmFsIGRlc3QgaW4gdGhlIFJILiANCg0KW1Bhc2NhbF0gQ29ycmVjdA0KDQogDQoNCjQpICAg IEQgw58gUlBMIFIgw58gQlIgw58gUyAgICAgICAgIFR1bm5lbC4gQlIgaW50cm9kdWNlcyBuZXcg SVB2NiBoZWFkZXIgd2l0aCBIYkggaGVhZGVyIGFuZCBSSCAobm9uLXN0b3JpbmcgbW9kZSBvbmx5 KSwgQlIgaXMgdGhlIElQdjYgc291cmNlLCBhbmQgUlBMIFIgdGhlIGZpbmFsIGRlc3QgaW4gdGhl IFJILiBSIGRlY2Fwc3VsYXRlcyBhbmQgc2VuZHMgdG8gRC4NCg0KW1Bhc2NhbF0gY29ycmVjdA0K DQpDb21tZW50OiBUaGlzIHdvdWxkIHdvcmsgaWYgUiBzZW5kcyBEQU8gd2l0aCB0YXJnZXQgRCBh bmQgdHJhbnNpdCDigJx0aGUgcGFyZW50IG9mIFLigJ06IEkgdGhpbmsgdGhpcyBpcyBhIGJpdCBk aWZmZXJlbnQgdGhhbiB5b3VyIGFwcHJvYWNoIGluIDViLiBBbHNvLCBJIGhhdmUgdGhlIGltcHJl c3Npb24gdGhhdCBhY2NvcmRpbmcgdG8g4oCcVGhlIGxhc3QgZW50cnksIEFkZHJlc3Nbbl0sIGlz IGV4ZW1wdCBmcm9tIHRoZSBzdHJpY3Qgc291cmNlIHJvdXRlIHBvbGljeSBhbmQgbWF5IHNwZWNp ZnkgYSBkZXN0aW5hdGlvbiBvdXRzaWRlIHRoZSBSUEwgZG9tYWlu4oCdLCBEIGFkZHJlc3MgY291 bGQgYmUgdGhlIGxhc3QgYWRkcmVzcyBpbiB0aGUgUkggYnV0IEnigJltIG5vdCBzdXJlIGhvdyB0 aGlzIHdvdWxkIHdvcmsuIElmIHRoaXMgdGV4dCBkb2VzIG5vdCBhcHBseSB0byB0dW5uZWwgbW9k ZSBhcyB5b3UgcG9pbnQgYmVsb3csIHdlIHNob3VsZCBzYXkgc28uDQoNCltQYXNjYWxdIEh1beKA piAg4oCcdGhlIHBhcmVudCBvZiBS4oCdIHdvdWxkIGxvb2sgdXAgRCBvbmxpbmsgYW5kIHdvdWxk IG5vdCBmaW5kIGl0LiBSIG5lZWRzIHRvIHNldCBpdHNlbGYgYXMgdHJhbnNpdCBwYXJlbnQgYW5k IEQgYXMgdGFyZ2V0LiBGb3IgYSBSUEwgcm91dGVyIG9yIGxlYWYsIGFuZCB0byBlbmFibGUgYSBi ZXR0ZXIgY29tcHJlc3Npb24gd2UgbGV0IHRoZSB0dW5uZWwgZW5kIGF0IHRoZSB0YXJnZXQgYnV0 IGZvciBhIG5vbiBSUEwgaG9zdCB0aGF0IGNhbm5vdCBiZS4gU28gd2UgbmVlZCBSIHRvIGZsYWcg aW4gdGhlIERBTyB0aGF0IFIgaXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3IgRCBhcyBvcHBvc2Vk IHRvIEQgaXRzZWxmLiBZb3XigJlsbCBub3RlIHRoYXQgZm9yIGVhY2ggb2YgUuKAmXMgYWRkcmVz c2VzIHRoYXQgYXJlIG5vdCBvbmxpbmsgZm9yIOKAnHRoZSBwYXJlbnQgb2YgUuKAnSwgUiBoYXMg dG8gYWR2ZXJ0aXNlIHNlbGYgYXMgcGFyZW50LCB1c2luZyBpbiB0aGUgdHJhbnNpdCBhbiBhZGRy ZXNzIHRoYXQgaXMgb25saW5rIHRvIGl0cyBvd24gcGFyZW50Lg0KDQogDQoNCiANCg0KNSkgICAg UyDDoCBSUEwgUjEgw6AgQlIgw6AgUlBMIFIyIMOgIEQgICAgICAgICAgICAgVHVubmVsLiBSMSBp bnRyb2R1Y2VzIG5ldyBJUHY2IGhlYWRlciB3aXRoIEhiSCBoZWFkZXIsIFIxIGlzIHRoZSBJUHY2 IHNvdXJjZSwgDQoNCkJSIHRoZSBJUHY2IGRlc3QuIEJSIHJlbW92ZXMgdGhpcyBoZWFkZXIuIEVu Y2Fwc3VsYXRlcyB3aXRoIG5ldyBJUHY2IGhlYWRlciB3aXRoIEhiSCBoZWFkZXIgYW5kIFJIIChu b24tc3RvcmluZyBtb2RlIG9ubHkpLCBCUiBpcyB0aGUgSVB2NiBzb3VyY2UsIGFuZCBSUEwgUjIg dGhlIGZpbmFsIGRlc3QgaW4gdGhlIFJILiANCg0KQ29tbWVudDogSSBndWVzcyB0aGlzIHZpc2lv biBjb250cmFkaWN0cyB5b3VyIHBvaW50IDVhLiBTZWVtcyBzaW1wbGVyIHRvIG1lLCBidXQgbWF5 YmUgSeKAmW0gbWlzc2luZyBzb21ldGhpbmcuDQoNCiANCg0KW1Bhc2NhbF0gSSBob3BlIHdlIGFy ZSBub3QgaW4gY29udHJhZGljdGlvbiA6ICkgVGhpcyBpcyBjb3JyZWN0IGluIG5vbiBzdG9yaW5n LiBJbiBzdG9yaW5nLCB0aGUgcGFja2V0IGRvZXNu4oCZdCBuZWVkIHRvIGdvIHRvIHRoZSByb290 IGFuZCBldmVuIGlmIGl0IGRvZXMsIHRoZSByb290IGlzIGp1c3QgYW5vdGhlciBjb21tb24gcGFy ZW50IGFuZCBmb3J3YXJkcyBkb3duLiBUaGVyZSBpcyBubyBkZWNhcCByZWVuY2FwIGluIHRoYXQg Y2FzZS4gQnV0IHRvIGRldGVybWluZSB0aGF0IHlvdSBjYW4gYnlwYXNzIHRoZSByb290LCB5b3Ug aGF2ZSB0byBmaWd1cmUgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMgYSBsZWFmIG9yIGEgcm91dGVy IG9mIHRoZSBzYW1lIFJQTCBuZXR3b3JrLCB3aGljaCBpcyBub3Qgb2J2aW91cy4gSWYgd2UgZG8g bm90IGhhdmUgcGxhaW4gaG9zdHMgYnV0IGp1c3QgUlBMIHJvdXRlcnMgYW5kIGxlYXZlcyBpbiBh IHNhbWUgc3VibmV0LCB0aGVuIGl0IGlzIGEgbG90IGVhc2llci4gDQoNCiANCg0KTm90ZSB0aGF0 IGlmIHRoZSBhYm92ZSBpcyBjb3JyZWN0LCB0aGUgb25seSBpbmZvcm1hdGlvbiBuZWVkZWQgYnkg UlBMIG5vZGVzIGlzIHRoZSBnbG9iYWwgYWRkcmVzcyBvZiB0aGUgQlIgKGkuZS4gdGhlIHJvb3Qp LiBTbyBpdCBzZWVtcyB0aGF0IDIgYmVsb3cgbWlnaHQgbm90IGJlIG5lZWRlZA0KDQpbUGFzY2Fs XSBJZiB3ZSBkbyB0aGUgYWJvdmUgZm9yIHN0b3JpbmcsIHdlIGxvc2UgdGhlIGFkdmFudGFnZSBv ZiByb3V0aW5nIHZpYSB0aGUgY29tbW9uIHBhcmVudOKApg0KDQogDQoNCkJlc3QsDQoNCk1hdGhp bGRlDQoNCiANCg0KRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSANClNlbnQ6IHZlbmRy ZWRpLCA5LiBqdWlsbGV0IDIwMTAgMTc6NDMNClRvOiBNYXRoaWxkZSBEdXJ2eSAobWR1cnZ5KTsg J1JPTEwgV0cnDQpTdWJqZWN0OiBSRTogW1JvbGxdIFVzZSBvZiB0dW5uZWxzIGFuZCBlbmQgcG9p bnQgZGV0ZXJtaWNhdGlvbg0KDQogDQoNCiANCg0KIA0KDQogDQoNCkFueXdheSBpdCBhcHBlYXJz IHRoYXQgdGhlIHNwZWMgY291bGQgYmUgY2xlYXJlciBpbjoNCg0KMS4gICAgICAgRXhwbGFpbmlu ZyB3aHkgSVAgaW4gSVAgaXMgdXNlZCBpbiBnZW5lcmFsDQoNCjIuICAgICAgIFNwZWNpZnlpbmcg dGhlIHJ1bGVzIHRvIGRldGVybWluZSBpZiBhIGRlc3RpbmF0aW9uIGlzIGluc2lkZSB0aGUgUlBM IG5ldHdvcmsNCg0KMy4gICAgICAgU3BlY2lmeWluZyB0dW5uZWwgbW9kZSBvcGVyYXRpb24NCg0K NC4gICAgICAgU3BlY2lmeWluZyB0cmFuc3BvcnQgbW9kZSBvcGVyYXRpb24gYW5kIHdoZW4gaXQg Y2FuIGJlIHVzZWQNCg0KNS4gICAgICAgU3BlY2lmeWluZyBob3cgdG8gZGV0ZXJtaW5lIHRoZSB0 dW5uZWwgZW5kcG9pbnQgaW4gdHVubmVsIG1vZGUNCg0KIA0KDQpQcm9wb3NhbDoNCg0KIA0KDQox KSAgICAgIFJQTCBuZWVkcyBhbiBpbnN0YW5jZSBJRCBpbiB0aGUgZmxvdyBsYWJlbCwgYW5kIEhi SCBoZWFkZXIsIGFuZCBldmVudHVhbGx5IGEgcm91dGluZyBoZWFkZXIgaW4gZXZlcnkgcGFja2V0 IGZvciByb3V0aW5nIGFuZCBpbmNvbnNpc3RlbmN5IGRldGVybWluYXRpb24uIFRoZSBIYkggYW5k IFJIIGFyZSBub25zZW5zaWNhbCBvdXRzaWRlIHRoZSBSUEwgbmV0d29yayBhbmQgY2FuIG9ubHkg YmUgcHJlc2VudCBpbnNpZGUgdGhlIFJQTCBuZXR3b3JrLiBUaGUgb25seSBjbGVhbiB3YXkgdG8g aW5zZXJ0IGFuZCByZW1vdmUgdGhvc2UgaGVhZGVycyBpcyB0byB1c2UgYSB0dW5uZWwgbW9kZSAo SVAgaW4gSVAgZW5jYXBzdWxhdGlvbikgd2hlcmVieSB0aGUgcm91dGVyIHBsYWNlcyB0aGUgUlBM IGhlYWRlcnMgYmVmb3JlIHRoZSBpbm5lciBoZWFkZXIsIGxlYXZpbmcgdGhlIG9yaWdpbmFsIHBh Y2tldCB1bnRvdWNoZWQuDQoNCmEuICAgICAgIEEgc291cmNlIGluc2lkZSB0aGUgUlBMIG5ldHdv cmsgKHJvdXRlciBvciBsZWFmKSBwbGFjZXMgdGhlIFJQTCBoZWFkZXJzIGFuZCBmbG93IGxhYmVs IGluIHRoZSBwYWNrZXQsIGVpdGhlciBpbiB0dW5uZWwgb3IgdHJhbnNwb3J0IG1vZGUuDQoNCkFy ZW7igJl0IHRoZSBmbG93IGxhYmVsIGFuZCBIYkggaGVhZGVyIG11dHVhbGx5IGV4Y2x1c2l2ZT8g U2hvdWxkbuKAmXQgd2UgZm9yY2UgdGhlIHVzZSBvZiB0aGUgSGJIIHdpdGhpbiB0aGUgUlBMIG5l dHdvcms/IE1vcmUgYWx0ZXJuYXRpdmVzIG1lYW4gbW9yZSBjb21wbGV4aXR5LiBXaHkgd291bGQg YSBzb3VyY2UgaW5zaWRlIFJQTCB1c2UgdHVubmVsIG1vZGU/IChzZWUgYWxzbyBjb21tZW50cyBi ZWxvdykgDQoNCltQYXNjYWxdIC0xMCBhbGxvd3MgYm90aCBidXQgaXQgc2VlbXMgcmVkdW5kYW50 LiBTaW5jZSB0aGUgaW5zdGFuY2UgaGFzIHRvIGJlIGluIHRoZSBmbG93IGxhYmVsIGZvciBhbiBl bmQgcG9pbnQgdG8gaW5kaWNhdGUgaXQsIHRoZW4gd2h5IG5vdCBsZXQgaXQgdGhlcmUgYWxsIHRo ZSB0aW1lPyBJZiB0aGUgaW5ncmVzcyByb3V0ZXIgaGFzIHRvIGZpZ3VyZSBvdXQgdGhlIGluc3Rh bmNlIElEIGJ5IHNvbWUgbWFnaWMsIGluIGFueSBmYXNoaW9uIGl0IGNhbiBwbGFjZSB0aGUgcmVz dWx0IGluIHRoZSBmbG93IGxhYmVsLg0KDQogDQoNCmIuICAgICAgRm9yIHBhY2tldHMgb3JpZ2lu YXRlZCBvdXRzaWRlIHRoZSBSUEwgbmV0d29yaywgdGhlIGZpcnN0IFJQTCByb3V0ZXIgKGNhbGxl ZCBpbmdyZXNzIHJvdXRlcikgaGFzIHRvIHBsYWNlIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIHBh Y2tldCBpbiB0dW5uZWwgbW9kZQ0KDQpjLiAgICAgICBGdXJ0aGVyIFJQTCByb3V0ZXJzIGZpbmQg dGhlIGluZm9ybWF0aW9uIGFuZCB1c2UgaXQuIFRoZXkgZG8gbm90IHJlLWVuY2Fwc3VsYXRlLCB0 aGV5IGRvIG5vdCBjaGFuZ2UgdGhlIGZsb3cgbGFiZWwsIHRoZXkgaGFwcGVuIHRvIG1vZGlmeSB0 aGUgUlBMIGhlYWRlcnMuDQoNCkluIG5vbi1zdG9yaW5nIG1vZGUsIGhvdyBkb2VzIHRoaXMgc2Nl bmFyaW8gd29yaz8NCg0KSG9zdCDigJMgUlBMIGluZ3Jlc3Mgcm91dGVyIChtdXN0IGluY2x1ZGUg SGJIKeKApiBSUEwgcm91dGVycyDigKYgUlBMIHJvb3QgKG11c3QgaW5jbHVkZSBzb3VyY2Ugcm91 dGUgaW4gYWRkaXRpb24gdG8gSGJILCBjYW4gaXQgZG8gaXQgaW4gdGhlIHNhbWUgSVB2NiBoZWFk ZXI/KSDigKYgUlBMIHJvdXRlciDigKYgUlBMIHJvdXRlIChkZWNhcHN1bGF0aW9uKSDigJMgSG9z dA0KDQpbUGFzY2FsXSBJbiBub24tc3RvcmluZywgdGhlIG5vZGVzIHdpbGwgYWx3YXlzIHR1bm5l bCB0byB0aGUgcm9vdC4gVGhlIHJvb3QgZGVjYXBzLCBhbmQgcm91dGUgdGhlIHBhY2tldDsgaWYg dGhlIGRlc3RpbmF0aW9uIGlzIGluIHRoZSBSUEwgbmV0d29yaywgdGhlIHJvb3QgcmVlbmNhcHMs IHRoaXMgdGltZSB3aXRoIGEgcm91dGluZyBoZWFkZXIuDQoNCmQuICAgICAgVGhlIHR1bm5lbCBl bmRwb2ludCBkZWNhcHN1bGF0ZXMgYmVmb3JlIGZvcndhcmRpbmcgdGhlIGlubmVyIHBhY2tldC4g VGhpcyBzdHJpcHMgdGhlIFJQTCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBwYWNrZXQuIElmIHRoZSBw YWNrZXQgaXMgcmVpbnNlcnRlZCBpbnRvIHRoZSBSUEwgbmV0d29yayB0aGVuIHRoZXJlIGlzIGEg cmlzayBvZiBhIGxvb3AuIA0KDQogDQoNCiANCg0KIA0KDQoyKSAgICAgIEEgZGVzdGluYXRpb24g aXMgaW4gdGhlIHNhbWUgUlBMIG5ldHdvcmsgaWY6DQoNCmEuICAgICAgIFRoZSBkZXN0aW5hdGlv biBpcyB0aGUgcm9vdCBvZiB0aGUgRE9EQUcgKGFsbCBtb2RlcykNCg0KYi4gICAgICBUaGUgZGVz dGluYXRpb24gaXMgaW4gdGhlIHNhbWUgU3VibmV0IGFzIHRoZSBzb3VyY2UgKGRlcml2ZWQgZnJv bSBhIFBJTykgIChzdG9yaW5nIG1vZGUgb25seSkgDQoNCmMuICAgICAgIFRoZSBub2RlIGlzIGEg cm91dGVyIHRoYXQgaGFzIGEgREFPIHN0YXRlIGluZGljYXRpbmcgdGhhdCB0aGUgZGVzdGluYXRp b24gaXMgYSBjaGlsZCAoc3RvcmluZyBtb2RlIG9ubHkpDQoNCmQuICAgICAgVGhlIGRlc3RpbmF0 aW9uIGhhcyBiZWVuIHNlZW4gYXMgdHVubmVsIGVuZHBvaW50IGFuZCB0aHVzIGlzIGEgREFPIGFu Y2VzdG9yIChzdG9yaW5nIG1vZGUgb25seSkuDQoNCk5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkg dGhlIGxhc3QgcG9pbnQuIA0KDQpbUGFzY2FsXSB0cmljaywgYW5kIGFjdHVhbGx5IG5vdCB0dW5u ZWwgZW5kcG9pbnQgYnV0IHRyYW5zcG9ydCBtb2RlIGVuZHBvaW50LiBBIG5vZGUgZG9lcyBub3Qg a25vdyBpdHMgYW5jZXN0b3JzLCBzbyBpdCB3b3VsZCB0dW5uZWwgaWYgdGhleSBhcmUgbm90IGlu IHRoZSBzYW1lIHN1Ym5ldC4gQnV0IHRoZSBhbmNlc3RvciBrbm93cyB0aGUgZ3JhbmQgZ3JhbmQg Y2hpbGQsIHNvIGl0IHdvdWxkIHVzZSB0cmFuc3BvcnQgbW9kZS4gU28gd2UgZW5kIHVwIHdpdGgg YSB0cmlhbmd1bGFyIHJvdXRpbmcgd2hlcmUgdGhlIGNoaWxkIHR1bm5lbHMgdG8gdGhlIHJvb3Qs IHRoZSByb290IHR1bm5lbCB0byB0aGUgYW5jZXN0b3IsIGFuZCB0aGUgYW5jZXN0b3IgdXNlcyB0 cmFuc3BvcnQgbW9kZSBkb3duLiBpZiBzb21lb25lIHVzZXMgdHJhbnNwb3J0IG1vZGUgd2l0aCB5 b3UsIHlvdSBjYW4gdXNlIHRyYW5zcG9ydCBtb2RlIHdpdGggaGlt4oCmIElmIHlvdSBjYXJlIHRv IGltcGxlbWVudCBzdWNoIG9wdGltaXphdGlvbi4NCg0KIA0KDQogDQoNCjMpICAgICAgQSBSUEwg cm91dGVyIHRoYXQgaW5qZWN0cyBhIHBhY2tldCB3aXRob3V0IHRoZSBIYkggb3B0aW9uIGludG8g dGhlIFJQTCBuZXR3b3JrIGlzIGFuIGluZ3Jlc3Mgcm91dGVyLiAgDQoNCmEuICAgICAgIEFuIGlu Z3Jlc3Mgcm91dGVyIE1VU1QgcGxhY2UgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiB0aGUgcGFja2V0 IGluIHR1bm5lbCBtb2RlDQoNCmIuICAgICAgQW4gaW5ncmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0 aGUgaW5zdGFuY2UgSUQgaW4gdGhlIGZsb3cgbGFiZWwgb2YgdGhlIG91dGVyIGhlYWRlcg0KDQpj LiAgICAgICBBbiBpbmdyZXNzIHJvdXRlciBNVVNUIHVzZSBvbmUgb2YgaXRzIGdsb2JhbCBhZGRy ZXNzZXMgZnJvbSB0aGUgUlBMIGRvbWFpbiBhcyBzb3VyY2UNCg0KZC4gICAgICBBbiBpbmdyZXNz IHJvdXRlciBNVVNUIHVzZSBhIHR1bm5lbCBlbmRwb2ludCB0aGF0IGlzIGluIHRoZSBzYW1lIFJQ TCBuZXR3b3JrIChydWxlcyBhYm92ZSkuDQoNCkRvZXNu4oCZdCBkLiBjb250cmFkaWN0cyDigJxU aGUgbGFzdCBlbnRyeSwgQWRkcmVzc1tuXSwgaXMgZXhlbXB0IGZyb20gdGhlIHN0cmljdCBzb3Vy Y2Ugcm91dGUgcG9saWN5IGFuZCBtYXkgc3BlY2lmeSBhIGRlc3RpbmF0aW9uIG91dHNpZGUgdGhl IFJQTCBkb21haW7igJ0gZnJvbSB0aGUgcnBsLXJvdXRpbmctaGVhZGVyIGRyYWZ0PyBJIHRoaW5r IHRoaXMgYWxzbyBpbXBhY3QgeW91ciBwb2ludCA0IGFuZCA14oCmDQoNCltQYXNjYWxdIFRoZSB0 ZXh0cyBkb2VzIG5vdCBhcHBseSB0byBSUEwgYnV0IGlzIGFwcGFyZW50bHkgc2FmZSBpbiByb3V0 aW5nIGhlYWRlcnMgYXQgbGFyZ2UuIFJQTCBjYW5ub3QgdXNlIHRyYW5zcG9ydCBtb2RlIHRvIGFu IGV4dGVybmFsIGRlc3RpbmF0aW9uIGJlY2F1c2Ugb2YgdGhlIHVzZSBvZiB0aGUgaG9wIGJ5IGhv cCBvcHRpb24uICANCg0KIA0KDQo0KSAgICAgIEEgUlBMIG5vZGUgTVVTVCBwbGFjZSB0aGUgUlBM IGluZm9ybWF0aW9uIGluIGV2ZXJ5IHBhY2tldCB0aGF0IGlzIHNvdXJjZXMuIEl0IGNhbiBzYWZl bHkgdXNlIHR1bm5lbCBtb2RlIGZvciBhbGwgcGFja2V0cy4gSXQgTUFZIHVzZSB0cmFuc3BvcnQg bW9kZSB3aGVuIGl0IGRldGVybWluZXMgdGhhdCB0aGUgZGVzdGluYXRpb24gaXMgYSBSUEwgbGVh ZiBvciByb3V0ZXIgd2l0aGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrLiBJbiB0cmFuc3BvcnQgbW9k ZSwgdGhlIG91dGVyIGhlYWRlcnMgYXJlIGJ1aWx0IGFzIGZvbGxvd3M6IA0KDQphLiAgICAgICBU aGUgc291cmNlIE1VU1QgcGxhY2UgdGhlIGluc3RhbmNlIElEIGluIHRoZSBmbG93IGxhYmVsIG9m IHRoZSBJUHY2IGhlYWRlcg0KDQpiLiAgICAgIFRoZSBzb3VyY2UgTVVTVCB1c2Ugb25lIG9mIGl0 cyBnbG9iYWwgYWRkcmVzc2VzIGZyb20gdGhlIFJQTCBkb21haW4gYXMgc291cmNlDQoNCmMuICAg ICAgIFRoZSBkZXN0aW5hdGlvbiBNVVNUIGJlIGlzIGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrIChy dWxlcyBhYm92ZSkuDQoNCiANCg0KNSkgICAgICBUaGUgdHVubmVsIGVuZHBvaW50IGlzIGRldGVy bWluZWQgYXMgZm9sbG93czoNCg0KYS4gICAgICAgSWYgdGhlIGRlc3RpbmF0aW9uIGlzIGluIHRo ZSBSUEwgbmV0d29yayAocnVsZXMgYWJvdmUpIHRoZW4gdGhlIGVuZHBvaW50IGlzIHRoZSBkZXN0 aW5hdGlvbg0KDQpiLiAgICAgIElmIHRoZSBkZXN0aW5hdGlvbiBpcyBhIGhvc3QgYXR0YWNoZWQg dG8gYSBSUEwgcm91dGVyIHRoZW4gdGhlIGVuZHBvaW50IGlzIHRoYXQgUlBMIHJvdXRlcg0KDQpj LiAgICAgICBFbHNlIHRoZSBlbmRwb2ludCBpcyB0aGUgcm9vdA0KDQogDQoNCkl0IGFwcGVhcnMg dGhhdCB0aGUgYikgaXMgbm90IHN1cHBvcnRlZCBjb3JyZWN0bHkgd2l0aCB0aGUgY3VycmVudCBz cGVjIHNpbmNlIHdlIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGluamVjdCBhIHJvdXRlIHRvIGFuIGV4 dGVybmFsIGhvc3Qgd2hpbGUgaW5kaWNhdGluZyB0aGF0IHRoZSBob3N0IGlzIG5vdCBhIGxlYWYu DQoNClByb2JhYmx5IHRoZSByb3V0ZXIgd291bGQgcHJlc2VudCBpdHNlbGYgYXMgcGFyZW50IGlu IGEgdHJhbnNpdCBvcHRpb24sIHdpdGggYSBiaXQgc2F5aW5nIHRoYXQgdGhlIHRhcmdldHMgYXMg bm9uIHJwbCBob3N0cy4NCg0KIA0KDQpbUGFzY2FsXSBUaGFua3MgYSBidW5jaCBmb3IgeW91ciBj b21tZW50cy4gTGV04oCZcyBrZWVwIHRoZSBwaXBlIG1vcmUgb3BlbiB0aGFuIGV2ZXIgc2luY2Ug d2UgYXJlIGluIGxhc3QgY2FsbCBub3chDQoNCiANCg0KT3BpbmlvbnM/DQoNCiANCg0KIA0KDQoJ DQpQYXNjYWwgVGh1YmVydA0KSVB2NiBFbmdpbmVlcmluZw0KUHJvZHVjdCBEZXZlbG9wbWVudA0K cHRodWJlcnRAY2lzY28uY29tIDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPiANClBob25lOiAr MzMgNCA5NzIzIDI2MzQNCk1vYmlsZTogKzMzIDYgMTk5OCAyOTg1DQoNCkNpc2NvIFN5c3RlbXMg RnJhbmNlDQpWaWxsYWdlIGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZQ0KNDAwIEF2ZW51ZSBkZSBS b3VtYW5pbGxlIA0KQmF0aW1lbnQgVCAzIA0KMDY0MTAgDQpCSU9UIC0gU09QSElBIEFOVElQT0xJ Uw0KRnJhbmNlDQpDaXNjby5jb20gPGh0dHA6Ly93d3cuY2lzY28uY29tL2dsb2JhbC9GUi8+IA0K DQogIA0KDQogDQoNCiBUaGluayBiZWZvcmUgeW91IHByaW50Lg0KDQpDaXNjbyBTeXN0ZW1zIEZy YW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZSBE ZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJ c3N5IGxlcyBNb3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYx IFJDUyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNo ZWwgR2l2b25lLCBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KaHR0cDov L3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5o dG1sIDxodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwv Y3JpL2luZGV4Lmh0bWw+IA0KDQogDQoNCiANCg0K ------_=_NextPart_002_01CB24FB.AB562FC3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0 ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnAuQmFsbG9vblRleHQsIGxpLkJhbGxvb25UZXh0LCBkaXYuQmFsbG9vblRleHQNCgl7bXNv LXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlOw0K CWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRp b246bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM0Mjk3OTQyMzsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg4MDkwODg1MCAxOTY4MDg0MDc2IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCglt c28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU0LjBwdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MTI2LjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjIuMHB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOTguMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MjM0LjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzAuMHB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDYuMHB0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MzQyLjBwdDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDU1NDE2NjE1Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MDg0ODYyNzAgLTEwODQ5NzYxNzAgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdo dDpib2xkOw0KCW1zby1hbnNpLWZvbnQtc3R5bGU6aXRhbGljO30NCkBsaXN0IGwxOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQ4 MDY1NTgwMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE4NDkyMzc0NzggNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6MTU1OTI0NjIxMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTE1MDAyMzg5NDAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgLTEy Njc0NTE4NzIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTRcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsNA0KCXttc28tbGlzdC1pZDoyMDk3NDMyNjE2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTcyMjY3MTE0IDY3Njk4NzAzIDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs NDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGkgTWF0aGlsZGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+UGFzY2FsPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBNYXRoaWxkZSBEdXJ2 eSAobWR1cnZ5KSA8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDE1LCAyMDEwIDE6MzEg UE08YnI+PGI+VG86PC9iPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyAnUk9MTCBXRyc8YnI+ PGI+U3ViamVjdDo8L2I+IFJFOiBbUm9sbF0gVXNlIG9mIHR1bm5lbHMgYW5kIGVuZCBwb2ludCBk ZXRlcm1pY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkhpIFBhc2Nh bCwgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkxldCBtZSBrbm93IGlmIHRo aXMgaXMgYSBjb3JyZWN0IHN1bW1hcnkgb2YgdGhlIHBvc3NpYmxlIGNhc2VzLiBJIGFsc28gcHV0 IHNvbWUgY29tbWVudHMgdG8gcG9pbnQgdGhpbmdzIHdoZXJlIEkgdGhpbmsgYSBjbGFyaWZpY2F0 aW9uIGlzIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHls ZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTAnPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpibHVlJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xKTxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5SUEwgUyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w6A8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiBCUiA8L3NwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w6A8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiBEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBObyB0dW5uZWwsIHRoZSBSUEwgc291cmNlIGFkZHMgdGhlIEhiSCBoZWFk ZXIsIEJSIHJlbW92ZXMgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxpPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5bUGFzY2FsXSBTdXJwcmlzZWQgbWUg cXVpdGUgYSBiaXQgYnV0IGNvcnJlY3QuIFRoaXMgYW1lbmRzIG15IGVhcmxpZXIgbWFpbCBvZiBt aW5lIHdoZXJlIEkgdGhvdWdodCB3ZSBoYWQgdG8gdHVubmVsIHRoZXJlLiBNeSBzZW50ZW5jZSDi gJw8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlJQTCBjYW5ub3QgdXNlIHRyYW5z cG9ydCBtb2RlIHRvIGFuIGV4dGVybmFsIGRlc3RpbmF0aW9uIGJlY2F1c2Ugb2YgdGhlIHVzZSBv ZiB0aGUgaG9wIGJ5IGhvcCBvcHRpb248L3NwYW4+PC9pPjwvYj48Yj48aT48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+4oCdIHdhcyBhcHBhcmVudGx5IHdyb25nLCBhbmQgd2UgY2FuIGxhd2Z1 bGx5IHJlbW92ZSB0aGUgaG9wIGJ5IGhvcCBpbnNpZGUgdGhlIHBhY2tldC48bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xMCc+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIpPHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPlMgPC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseTpXaW5nZGluZ3MnPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4gUlBMIFIgPC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4gQlIgPC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz4gRCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUdW5uZWwuIFIgaW50cm9kdWNlcyBuZXcgSVB2 NiBoZWFkZXIgd2l0aCBIYkggaGVhZGVyLCBSIGlzIHRoZSBJUHY2IHNvdXJjZSwgQlIgdGhlIElQ djYgZGVzdC4gQlIgcmVtb3ZlcyB0aGlzIGhlYWRlci4gPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkNvbW1lbnQ6IElmIEJSIGlzIHRoZSBlbmQgb2YgdGhl IHR1bm5lbCwgaXRzIGFkZHJlc3MgbmVlZHMgdG8gYmUga25vd24gYnkgUi4gSG93IGRvZXMgdGhh dCB3b3JrPyBUaGlzIHdvdWxkIGZhdm9yIGFuIGFwcHJvYWNoIHdoZXJlIHRoZSBET0RBR0lEIG11 c3QgYmUgdGhlIGdsb2JhbCBJUHY2IGFkZHJlc3Mgb2YgdGhlIHJvb3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6MGNtJz48 Yj48aT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0gQ29ycmVjdCwgdGhvdWdo IHdlIGRvIG5vdCByZWFsbHkgd2VsbCBzdXBwb3J0IGEgaG9zdCBhdHRhY2hlZCB0byB0aGUgUlBM IG5ldHdvcmsuIEluIHBhcnRpY3VsYXIgdGhlIGxhY2sgb2YgREFPIHNlcXVlbmNlIGV0Y+KApiA8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0 eWxlPSdtYXJnaW4tbGVmdDowY20nPjxiPjxpPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5N YWtlIHNlbnNlIHRvIG1lIGZvciBhbGwgbm9kZXMgdG8gYmUgbGVhdmVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEwJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PHNwYW4g c3R5bGU9J21zby1saXN0Oklnbm9yZSc+Myk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMg TmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZSc+UlBMIEQgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOf PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz4gQlIgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOf PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibHVlJz4gUyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHVubmVs LiBCUiBpbnRyb2R1Y2VzIG5ldyBJUHY2IGhlYWRlciB3aXRoIEhiSCBoZWFkZXIgYW5kIFJIIChu b24tc3RvcmluZyBtb2RlIG9ubHkpLCBCUiBpcyB0aGUgSVB2NiBzb3VyY2UsIGFuZCBSUEwgRCB0 aGUgZmluYWwgZGVzdCBpbiB0aGUgUkguIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPltQYXNjYWxdIENvcnJl Y3Q8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzEwJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+NCk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+ RCA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w588L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiBS UEwgUiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w588L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUn PiBCUiA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w588L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUn PiBTICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUdW5uZWwuIEJS IGludHJvZHVjZXMgbmV3IElQdjYgaGVhZGVyIHdpdGggSGJIIGhlYWRlciBhbmQgUkggKG5vbi1z dG9yaW5nIG1vZGUgb25seSksIEJSIGlzIHRoZSBJUHY2IHNvdXJjZSwgYW5kIFJQTCBSIHRoZSBm aW5hbCBkZXN0IGluIHRoZSBSSC4gUiBkZWNhcHN1bGF0ZXMgYW5kIHNlbmRzIHRvIEQuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+W1Bhc2NhbF0gY29ycmVjdDwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDozNi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5Db21tZW50OiBUaGlzIHdvdWxkIHdvcmsgaWYgUiBz ZW5kcyBEQU8gd2l0aCB0YXJnZXQgRCBhbmQgdHJhbnNpdCDigJx0aGUgcGFyZW50IG9mIFLigJ06 IEkgdGhpbmsgdGhpcyBpcyBhIGJpdCBkaWZmZXJlbnQgdGhhbiB5b3VyIGFwcHJvYWNoIGluIDVi LiBBbHNvLCBJIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCBhY2NvcmRpbmcgdG8g4oCcVGhlIGxh c3QgZW50cnksIEFkZHJlc3Nbbl0sIGlzIGV4ZW1wdCBmcm9tIHRoZSBzdHJpY3Qgc291cmNlIHJv dXRlIHBvbGljeSBhbmQgbWF5IHNwZWNpZnkgYSBkZXN0aW5hdGlvbiBvdXRzaWRlIHRoZSBSUEwg ZG9tYWlu4oCdLCBEIGFkZHJlc3MgY291bGQgYmUgdGhlIGxhc3QgYWRkcmVzcyBpbiB0aGUgUkgg YnV0IEnigJltIG5vdCBzdXJlIGhvdyB0aGlzIHdvdWxkIHdvcmsuIElmIHRoaXMgdGV4dCBkb2Vz IG5vdCBhcHBseSB0byB0dW5uZWwgbW9kZSBhcyB5b3UgcG9pbnQgYmVsb3csIHdlIHNob3VsZCBz YXkgc28uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0gSHVt4oCmIMKg4oCcdGhlIHBhcmVudCBv ZiBS4oCdIHdvdWxkIGxvb2sgdXAgRCBvbmxpbmsgYW5kIHdvdWxkIG5vdCBmaW5kIGl0LiBSIG5l ZWRzIHRvIHNldCBpdHNlbGYgYXMgdHJhbnNpdCBwYXJlbnQgYW5kIEQgYXMgdGFyZ2V0LiBGb3Ig YSBSUEwgcm91dGVyIG9yIGxlYWYsIGFuZCB0byBlbmFibGUgYSBiZXR0ZXIgY29tcHJlc3Npb24g d2UgbGV0IHRoZSB0dW5uZWwgZW5kIGF0IHRoZSB0YXJnZXQgYnV0IGZvciBhIG5vbiBSUEwgaG9z dCB0aGF0IGNhbm5vdCBiZS4gU28gd2UgbmVlZCBSIHRvIGZsYWcgaW4gdGhlIERBTyB0aGF0IFIg aXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3IgRCBhcyBvcHBvc2VkIHRvIEQgaXRzZWxmLiBZb3Xi gJlsbCBub3RlIHRoYXQgZm9yIGVhY2ggb2YgUuKAmXMgYWRkcmVzc2VzIHRoYXQgYXJlIG5vdCBv bmxpbmsgZm9yIOKAnHRoZSBwYXJlbnQgb2YgUuKAnSwgUiBoYXMgdG8gYWR2ZXJ0aXNlIHNlbGYg YXMgcGFyZW50LCB1c2luZyBpbiB0aGUgdHJhbnNpdCBhbiBhZGRyZXNzIHRoYXQgaXMgb25saW5r IHRvIGl0cyBvd24gcGFyZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzEwJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+PHNwYW4gc3R5bGU9 J21zby1saXN0Oklnbm9yZSc+NSk8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJv bWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+ UyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+w6A8L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiBS UEwgUjEgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOgPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVl Jz4gQlIgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPsOgPC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVl Jz4gUlBMIFIyIDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6V2luZ2RpbmdzJz7DoDwv c3Bhbj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 Ymx1ZSc+IEQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFR1bm5lbC4gUjEgaW50cm9kdWNlcyBuZXcgSVB2NiBoZWFkZXIg d2l0aCBIYkggaGVhZGVyLCBSMSBpcyB0aGUgSVB2NiBzb3VyY2UsIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5CUiB0aGUgSVB2NiBkZXN0LiBCUiByZW1v dmVzIHRoaXMgaGVhZGVyLiBFbmNhcHN1bGF0ZXMgd2l0aCBuZXcgSVB2NiBoZWFkZXIgd2l0aCBI YkggaGVhZGVyIGFuZCBSSCAobm9uLXN0b3JpbmcgbW9kZSBvbmx5KSwgQlIgaXMgdGhlIElQdjYg c291cmNlLCBhbmQgUlBMIFIyIHRoZSBmaW5hbCBkZXN0IGluIHRoZSBSSC4gPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkNvbW1lbnQ6IEkgZ3Vlc3MgdGhp cyB2aXNpb24gY29udHJhZGljdHMgeW91ciBwb2ludCA1YS4gU2VlbXMgc2ltcGxlciB0byBtZSwg YnV0IG1heWJlIEnigJltIG1pc3Npbmcgc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPltQYXNjYWxdIEkg aG9wZSB3ZSBhcmUgbm90IGluIGNvbnRyYWRpY3Rpb24gOiApIFRoaXMgaXMgY29ycmVjdCBpbiBu b24gc3RvcmluZy4gSW4gc3RvcmluZywgdGhlIHBhY2tldCBkb2VzbuKAmXQgbmVlZCB0byBnbyB0 byB0aGUgcm9vdCBhbmQgZXZlbiBpZiBpdCBkb2VzLCB0aGUgcm9vdCBpcyBqdXN0IGFub3RoZXIg Y29tbW9uIHBhcmVudCBhbmQgZm9yd2FyZHMgZG93bi4gVGhlcmUgaXMgbm8gZGVjYXAgcmVlbmNh cCBpbiB0aGF0IGNhc2UuIEJ1dCB0byBkZXRlcm1pbmUgdGhhdCB5b3UgY2FuIGJ5cGFzcyB0aGUg cm9vdCwgeW91IGhhdmUgdG8gZmlndXJlIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGlzIGEgbGVhZiBv ciBhIHJvdXRlciBvZiB0aGUgc2FtZSBSUEwgbmV0d29yaywgd2hpY2ggaXMgbm90IG9idmlvdXMu IElmIHdlIGRvIG5vdCBoYXZlIHBsYWluIGhvc3RzIGJ1dCBqdXN0IFJQTCByb3V0ZXJzIGFuZCBs ZWF2ZXMgaW4gYSBzYW1lIHN1Ym5ldCwgdGhlbiBpdCBpcyBhIGxvdCBlYXNpZXIuIDxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1 ZSc+Tm90ZSB0aGF0IGlmIHRoZSBhYm92ZSBpcyBjb3JyZWN0LCB0aGUgb25seSBpbmZvcm1hdGlv biBuZWVkZWQgYnkgUlBMIG5vZGVzIGlzIHRoZSBnbG9iYWwgYWRkcmVzcyBvZiB0aGUgQlIgKGku ZS4gdGhlIHJvb3QpLiBTbyBpdCBzZWVtcyB0aGF0IDIgYmVsb3cgbWlnaHQgbm90IGJlIG5lZWRl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGk+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPltQYXNjYWxdIElmIHdlIGRvIHRoZSBhYm92ZSBmb3Igc3Rvcmlu Zywgd2UgbG9zZSB0aGUgYWR2YW50YWdlIG9mIHJvdXRpbmcgdmlhIHRoZSBjb21tb24gcGFyZW50 4oCmPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOmJsdWUnPk1hdGhpbGRlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxicj48Yj5TZW50OjwvYj4gdmVu ZHJlZGksIDkuIGp1aWxsZXQgMjAxMCAxNzo0Mzxicj48Yj5Ubzo8L2I+IE1hdGhpbGRlIER1cnZ5 IChtZHVydnkpOyAnUk9MTCBXRyc8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbUm9sbF0gVXNlIG9m IHR1bm5lbHMgYW5kIGVuZCBwb2ludCBkZXRlcm1pY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MS4wcHQgMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+QW55d2F5IGl0IGFwcGVhcnMgdGhhdCB0aGUgc3BlYyBjb3VsZCBi ZSBjbGVhcmVyIGluOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEyJz48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xLjxzcGFuIHN0eWxl PSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RXhwbGFpbmluZyB3aHkgSVAgaW4g SVAgaXMgdXNlZCBpbiBnZW5lcmFsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFn cmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvMTIn PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNw YW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TcGVjaWZ5aW5nIHRo ZSBydWxlcyB0byBkZXRlcm1pbmUgaWYgYSBkZXN0aW5hdGlvbiBpcyBpbnNpZGUgdGhlIFJQTCBu ZXR3b3JrPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsNCBsZXZlbDEgbGZvMTInPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjMuPHNwYW4gc3R5bGU9J2ZvbnQ6 Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TcGVjaWZ5aW5nIHR1bm5lbCBtb2RlIG9wZXJh dGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEyJz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz40LjxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U3BlY2lmeWluZyB0cmFuc3BvcnQgbW9kZSBvcGVy YXRpb24gYW5kIHdoZW4gaXQgY2FuIGJlIHVzZWQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omw0IGxldmVs MSBsZm8xMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9y ZSc+NS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlNwZWNp ZnlpbmcgaG93IHRvIGRldGVybWluZSB0aGUgdHVubmVsIGVuZHBvaW50IGluIHR1bm5lbCBtb2Rl PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+UHJvcG9zYWw6PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzE0Jz48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xKTxzcGFuIHN0 eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UlBMIG5lZWRzIGFuIGluc3RhbmNlIElE IGluIHRoZSBmbG93IGxhYmVsLCBhbmQgSGJIIGhlYWRlciwgYW5kIGV2ZW50dWFsbHkgYSByb3V0 aW5nIGhlYWRlciBpbiBldmVyeSBwYWNrZXQgZm9yIHJvdXRpbmcgYW5kIGluY29uc2lzdGVuY3kg ZGV0ZXJtaW5hdGlvbi4gVGhlIEhiSCBhbmQgUkggYXJlIG5vbnNlbnNpY2FsIG91dHNpZGUgdGhl IFJQTCBuZXR3b3JrIGFuZCBjYW4gb25seSBiZSBwcmVzZW50IGluc2lkZSB0aGUgUlBMIG5ldHdv cmsuIFRoZSBvbmx5IGNsZWFuIHdheSB0byBpbnNlcnQgYW5kIHJlbW92ZSB0aG9zZSBoZWFkZXJz IGlzIHRvIHVzZSBhIHR1bm5lbCBtb2RlIChJUCBpbiBJUCBlbmNhcHN1bGF0aW9uKSB3aGVyZWJ5 IHRoZSByb3V0ZXIgcGxhY2VzIHRoZSBSUEwgaGVhZGVycyBiZWZvcmUgdGhlIGlubmVyIGhlYWRl ciwgbGVhdmluZyB0aGUgb3JpZ2luYWwgcGFja2V0IHVudG91Y2hlZC48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmEuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BIHNvdXJjZSBpbnNpZGUgdGhlIFJQTCBuZXR3b3Jr IChyb3V0ZXIgb3IgbGVhZikgcGxhY2VzIHRoZSBSUEwgaGVhZGVycyBhbmQgZmxvdyBsYWJlbCBp biB0aGUgcGFja2V0LCBlaXRoZXIgaW4gdHVubmVsIG9yIHRyYW5zcG9ydCBtb2RlLjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+QXJlbuKAmXQgdGhlIGZsb3cgbGFiZWwgYW5kIEhi SCBoZWFkZXIgbXV0dWFsbHkgZXhjbHVzaXZlPyBTaG91bGRu4oCZdCB3ZSBmb3JjZSB0aGUgdXNl IG9mIHRoZSBIYkggd2l0aGluIHRoZSBSUEwgbmV0d29yaz8gTW9yZSBhbHRlcm5hdGl2ZXMgbWVh biBtb3JlIGNvbXBsZXhpdHkuIFdoeSB3b3VsZCBhIHNvdXJjZSBpbnNpZGUgUlBMIHVzZSB0dW5u ZWwgbW9kZT8gKHNlZSBhbHNvIGNvbW1lbnRzIGJlbG93KSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5bUGFz Y2FsXSAtMTAgYWxsb3dzIGJvdGggYnV0IGl0IHNlZW1zIHJlZHVuZGFudC4gU2luY2UgdGhlIGlu c3RhbmNlIGhhcyB0byBiZSBpbiB0aGUgZmxvdyBsYWJlbCBmb3IgYW4gZW5kIHBvaW50IHRvIGlu ZGljYXRlIGl0LCB0aGVuIHdoeSBub3QgbGV0IGl0IHRoZXJlIGFsbCB0aGUgdGltZT8gSWYgdGhl IGluZ3Jlc3Mgcm91dGVyIGhhcyB0byBmaWd1cmUgb3V0IHRoZSBpbnN0YW5jZSBJRCBieSBzb21l IG1hZ2ljLCBpbiBhbnkgZmFzaGlvbiBpdCBjYW4gcGxhY2UgdGhlIHJlc3VsdCBpbiB0aGUgZmxv dyBsYWJlbC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5Gb3IgcGFja2V0cyBvcmlnaW5hdGVkIG91dHNpZGUgdGhlIFJQ TCBuZXR3b3JrLCB0aGUgZmlyc3QgUlBMIHJvdXRlciAoY2FsbGVkIGluZ3Jlc3Mgcm91dGVyKSBo YXMgdG8gcGxhY2UgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgcGFja2V0IGluIHR1bm5lbCBtb2Rl PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxl ZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5jLjxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RnVydGhlciBSUEwgcm91 dGVycyBmaW5kIHRoZSBpbmZvcm1hdGlvbiBhbmQgdXNlIGl0LiBUaGV5IGRvIG5vdCByZS1lbmNh cHN1bGF0ZSwgdGhleSBkbyBub3QgY2hhbmdlIHRoZSBmbG93IGxhYmVsLCB0aGV5IGhhcHBlbiB0 byBtb2RpZnkgdGhlIFJQTCBoZWFkZXJzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1 ZSc+SW4gbm9uLXN0b3JpbmcgbW9kZSwgaG93IGRvZXMgdGhpcyBzY2VuYXJpbyB3b3JrPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPkhvc3Qg4oCTIFJQTCBpbmdyZXNz IHJvdXRlciAobXVzdCBpbmNsdWRlIEhiSCnigKYgUlBMIHJvdXRlcnMg4oCmIFJQTCByb290ICht dXN0IGluY2x1ZGUgc291cmNlIHJvdXRlIGluIGFkZGl0aW9uIHRvIEhiSCwgY2FuIGl0IGRvIGl0 IGluIHRoZSBzYW1lIElQdjYgaGVhZGVyPykg4oCmIFJQTCByb3V0ZXIg4oCmIFJQTCByb3V0ZSAo ZGVjYXBzdWxhdGlvbikgPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz7igJM8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPiBIb3N0PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+W1Bhc2NhbF0gSW4gbm9uLXN0b3JpbmcsIHRoZSBub2RlcyB3aWxsIGFsd2F5cyB0dW5uZWwg dG8gdGhlIHJvb3QuIFRoZSByb290IGRlY2FwcywgYW5kIHJvdXRlIHRoZSBwYWNrZXQ7IGlmIHRo ZSBkZXN0aW5hdGlvbiBpcyBpbiB0aGUgUlBMIG5ldHdvcmssIHRoZSByb290IHJlZW5jYXBzLCB0 aGlzIHRpbWUgd2l0aCBhIHJvdXRpbmcgaGVhZGVyLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBh cmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz5kLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+VGhlIHR1bm5lbCBlbmRwb2ludCBkZWNhcHN1bGF0ZXMgYmVmb3JlIGZvcndhcmRpbmcgdGhl IGlubmVyIHBhY2tldC4gVGhpcyBzdHJpcHMgdGhlIFJQTCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBw YWNrZXQuIElmIHRoZSBwYWNrZXQgaXMgcmVpbnNlcnRlZCBpbnRvIHRoZSBSUEwgbmV0d29yayB0 aGVuIHRoZXJlIGlzIGEgcmlzayBvZiBhIGxvb3AuIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0 eWxlPSdtYXJnaW4tbGVmdDowY20nPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MyBsZXZlbDEgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlz dDpJZ25vcmUnPjIpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BIGRl c3RpbmF0aW9uIGlzIGluIHRoZSBzYW1lIFJQTCBuZXR3b3JrIGlmOjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwzIGxldmVsMiBsZm8xNCc+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+YS48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBkZXN0aW5hdGlvbiBpcyB0aGUgcm9vdCBvZiB0 aGUgRE9EQUcgKGFsbCBtb2Rlcyk8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28t bGlzdDpJZ25vcmUnPmIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5U aGUgZGVzdGluYXRpb24gaXMgaW4gdGhlIHNhbWUgU3VibmV0IGFzIHRoZSBzb3VyY2UgKGRlcml2 ZWQgZnJvbSBhIFBJTykgJm5ic3A7KHN0b3JpbmcgbW9kZSBvbmx5KSA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmMuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4w cHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgbm9kZSBpcyBhIHJvdXRlciB0aGF0IGhhcyBh IERBTyBzdGF0ZSBpbmRpY2F0aW5nIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGlzIGEgY2hpbGQgKHN0 b3JpbmcgbW9kZSBvbmx5KTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omwz IGxldmVsMiBsZm8xNCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+ZC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBk ZXN0aW5hdGlvbiBoYXMgYmVlbiBzZWVuIGFzIHR1bm5lbCBlbmRwb2ludCBhbmQgdGh1cyBpcyBh IERBTyBhbmNlc3RvciAoc3RvcmluZyBtb2RlIG9ubHkpLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6Ymx1ZSc+Tm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0aGUgbGFzdCBwb2ludC4gPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0gdHJpY2ssIGFuZCBhY3R1YWxseSBub3QgdHVubmVsIGVu ZHBvaW50IGJ1dCB0cmFuc3BvcnQgbW9kZSBlbmRwb2ludC4gQSBub2RlIGRvZXMgbm90IGtub3cg aXRzIGFuY2VzdG9ycywgc28gaXQgd291bGQgdHVubmVsIGlmIHRoZXkgYXJlIG5vdCBpbiB0aGUg c2FtZSBzdWJuZXQuIEJ1dCB0aGUgYW5jZXN0b3Iga25vd3MgdGhlIGdyYW5kIGdyYW5kIGNoaWxk LCBzbyBpdCB3b3VsZCB1c2UgdHJhbnNwb3J0IG1vZGUuIFNvIHdlIGVuZCB1cCB3aXRoIGEgdHJp YW5ndWxhciByb3V0aW5nIHdoZXJlIHRoZSBjaGlsZCB0dW5uZWxzIHRvIHRoZSByb290LCB0aGUg cm9vdCB0dW5uZWwgdG8gdGhlIGFuY2VzdG9yLCBhbmQgdGhlIGFuY2VzdG9yIHVzZXMgdHJhbnNw b3J0IG1vZGUgZG93bi4gaWYgc29tZW9uZSB1c2VzIHRyYW5zcG9ydCBtb2RlIHdpdGggeW91LCB5 b3UgY2FuIHVzZSB0cmFuc3BvcnQgbW9kZSB3aXRoIGhpbeKApiBJZiB5b3UgY2FyZSB0byBpbXBs ZW1lbnQgc3VjaCBvcHRpbWl6YXRpb24uPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo IHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBo IHN0eWxlPSd0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwzIGxldmVsMSBsZm8xNCc+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Myk8c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkEgUlBMIHJvdXRlciB0aGF0IGluamVj dHMgYSBwYWNrZXQgd2l0aG91dCB0aGUgSGJIIG9wdGlvbiBpbnRvIHRoZSBSUEwgbmV0d29yayBp cyBhbiBpbmdyZXNzIHJvdXRlci4gJm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+QW4gaW5ncmVzcyByb3V0ZXIgTVVTVCBwbGFjZSB0aGUgUlBMIGluZm9ybWF0 aW9uIGluIHRoZSBwYWNrZXQgaW4gdHVubmVsIG1vZGU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BbiBpbmdyZXNzIHJvdXRlciBNVVNUIHBsYWNlIHRoZSBpbnN0YW5jZSBJRCBp biB0aGUgZmxvdyBsYWJlbCBvZiB0aGUgb3V0ZXIgaGVhZGVyPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5jLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+QW4gaW5ncmVzcyByb3V0ZXIgTVVTVCB1c2Ugb25lIG9mIGl0 cyBnbG9iYWwgYWRkcmVzc2VzIGZyb20gdGhlIFJQTCBkb21haW4gYXMgc291cmNlPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5kLjxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QW4gaW5ncmVzcyByb3V0ZXIgTVVTVCB1c2UgYSB0 dW5uZWwgZW5kcG9pbnQgdGhhdCBpcyBpbiB0aGUgc2FtZSBSUEwgbmV0d29yayAocnVsZXMgYWJv dmUpLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+RG9lc27igJl0IGQuIGNvbnRy YWRpY3RzIOKAnFRoZSBsYXN0IGVudHJ5LCBBZGRyZXNzW25dLCBpcyBleGVtcHQgZnJvbSB0aGUg c3RyaWN0IHNvdXJjZSByb3V0ZSBwb2xpY3kgYW5kIG1heSBzcGVjaWZ5IGEgZGVzdGluYXRpb24g b3V0c2lkZSB0aGUgUlBMIGRvbWFpbuKAnSBmcm9tIHRoZSBycGwtcm91dGluZy1oZWFkZXIgZHJh ZnQ/IEkgdGhpbmsgdGhpcyBhbHNvIGltcGFjdCB5b3VyIHBvaW50IDQgYW5kIDXigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxpPjxzcGFuIHN0eWxlPSdjb2xv cjojMUY0OTdEJz5bUGFzY2FsXSBUaGUgdGV4dHMgZG9lcyBub3QgYXBwbHkgdG8gUlBMIGJ1dCBp cyBhcHBhcmVudGx5IHNhZmUgaW4gcm91dGluZyBoZWFkZXJzIGF0IGxhcmdlLiBSUEwgY2Fubm90 IHVzZSB0cmFuc3BvcnQgbW9kZSB0byBhbiBleHRlcm5hbCBkZXN0aW5hdGlvbiBiZWNhdXNlIG9m IHRoZSB1c2Ugb2YgdGhlIGhvcCBieSBob3Agb3B0aW9uLiAmbmJzcDs8L3NwYW4+PC9pPjwvYj48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjQpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BIFJQTCBub2RlIE1VU1QgcGxhY2UgdGhlIFJQTCBpbmZvcm1hdGlvbiBpbiBl dmVyeSBwYWNrZXQgdGhhdCBpcyBzb3VyY2VzLiBJdCBjYW4gc2FmZWx5IHVzZSB0dW5uZWwgbW9k ZSBmb3IgYWxsIHBhY2tldHMuIEl0IE1BWSB1c2UgdHJhbnNwb3J0IG1vZGUgd2hlbiBpdCBkZXRl cm1pbmVzIHRoYXQgdGhlIGRlc3RpbmF0aW9uIGlzIGEgUlBMIGxlYWYgb3Igcm91dGVyIHdpdGhp biB0aGUgc2FtZSBSUEwgbmV0d29yay4gSW4gdHJhbnNwb3J0IG1vZGUsIHRoZSBvdXRlciBoZWFk ZXJzIGFyZSBidWlsdCBhcyBmb2xsb3dzOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMyBsZXZlbDIgbGZvMTQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdtc28tbGlzdDpJZ25vcmUnPmEuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5UaGUgc291cmNlIE1VU1QgcGxhY2UgdGhlIGluc3RhbmNlIElEIGluIHRoZSBm bG93IGxhYmVsIG9mIHRoZSBJUHY2IGhlYWRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xp c3RQYXJhZ3JhcGggc3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwzIGxldmVsMiBsZm8xNCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+Yi48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPlRoZSBzb3VyY2UgTVVTVCB1c2Ugb25lIG9mIGl0cyBnbG9iYWwgYWRkcmVzc2VzIGZy b20gdGhlIFJQTCBkb21haW4gYXMgc291cmNlPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlz dFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz5jLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+VGhlIGRlc3RpbmF0aW9uIE1VU1QgYmUgaXMgaW4gdGhlIHNhbWUgUlBMIG5l dHdvcmsgKHJ1bGVzIGFib3ZlKS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdy YXBoIHN0eWxlPSdtYXJnaW4tbGVmdDo3Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz41KTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhl IHR1bm5lbCBlbmRwb2ludCBpcyBkZXRlcm1pbmVkIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDMgbGV2ZWwyIGxmbzE0Jz48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz5hLjxzcGFuIHN0eWxlPSdmb250Ojcu MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgdGhlIGRlc3RpbmF0aW9uIGlzIGluIHRoZSBS UEwgbmV0d29yayAocnVsZXMgYWJvdmUpIHRoZW4gdGhlIGVuZHBvaW50IGlzIHRoZSBkZXN0aW5h dGlvbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J21hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwzIGxldmVsMiBsZm8x NCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Yi48 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIHRoZSBkZXN0aW5hdGlv biBpcyBhIGhvc3QgYXR0YWNoZWQgdG8gYSBSUEwgcm91dGVyIHRoZW4gdGhlIGVuZHBvaW50IGlz IHRoYXQgUlBMIHJvdXRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGgg c3R5bGU9J21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omwz IGxldmVsMiBsZm8xNCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0 Oklnbm9yZSc+Yy48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PkVsc2UgdGhlIGVuZHBvaW50IGlzIHRoZSByb290PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv TGlzdFBhcmFncmFwaCBzdHlsZT0nbWFyZ2luLWxlZnQ6NzIuMHB0Jz48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+SXQgYXBw ZWFycyB0aGF0IHRoZSBiKSBpcyBub3Qgc3VwcG9ydGVkIGNvcnJlY3RseSB3aXRoIHRoZSBjdXJy ZW50IHNwZWMgc2luY2Ugd2UgZG8gbm90IGhhdmUgYSB3YXkgdG8gaW5qZWN0IGEgcm91dGUgdG8g YW4gZXh0ZXJuYWwgaG9zdCB3aGlsZSBpbmRpY2F0aW5nIHRoYXQgdGhlIGhvc3QgaXMgbm90IGEg bGVhZi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 OjM2LjBwdCc+UHJvYmFibHkgdGhlIHJvdXRlciB3b3VsZCBwcmVzZW50IGl0c2VsZiBhcyBwYXJl bnQgaW4gYSB0cmFuc2l0IG9wdGlvbiwgd2l0aCBhIGJpdCBzYXlpbmcgdGhhdCB0aGUgdGFyZ2V0 cyBhcyBub24gcnBsIGhvc3RzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48Yj48aT48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+W1Bhc2NhbF0g VGhhbmtzIGEgYnVuY2ggZm9yIHlvdXIgY29tbWVudHMuIExldOKAmXMga2VlcCB0aGUgcGlwZSBt b3JlIG9wZW4gdGhhbiBldmVyIHNpbmNlIHdlIGFyZSBpbiBsYXN0IGNhbGwgbm93ITxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5PcGluaW9ucz88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjx0YWJsZSBj bGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAg d2lkdGg9NTQzIHN0eWxlPSd3aWR0aDo0MDcuMjVwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzow Y20gMGNtIDBjbSAwY20nPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxs c3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NjAwIHN0eWxlPSd3aWR0aDo0NTAuMDVwdCc+ PHRyPjx0ZCBjb2xzcGFuPTMgc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48L3RkPjwv dHI+PHRyIHN0eWxlPSdoZWlnaHQ6OTQuMDVwdCc+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxl PSdwYWRkaW5nOjBjbSAwY20gMTEuMjVwdCAxOC4wcHQ7aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+UGFzY2FsIFRodWJlcnQ8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzY2NjY2Nic+PGJyPjxiPklQdjYgRW5naW5lZXJpbmc8L2I+PGJyPjxiPlByb2R1 Y3QgRGV2ZWxvcG1lbnQ8L2I+PGJyPjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20i PjxzcGFuIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5wdGh1YmVydEBjaXNjby5jb208L3NwYW4+PC9h Pjxicj5QaG9uZTogPGI+KzMzIDQgOTcyMyAyNjM0PC9iPjxicj5Nb2JpbGU6IDxiPiszMyA2IDE5 OTggMjk4NTwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48dGQgbm93cmFwIHZhbGlnbj10 b3Agc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSA3LjVwdCAxNS4wcHQ7aGVpZ2h0Ojk0LjA1cHQnPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQnPjxiPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz5DaXNjbyBTeXN0ZW1z IEZyYW5jZTwvc3Bhbj48L2I+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPjxicj5WaWxsYWdl IGQnRW50cmVwcmlzZXMgR3JlZW4gU2lkZTxicj40MDAgQXZlbnVlIGRlIFJvdW1hbmlsbGUgPGJy PkJhdGltZW50IFQgMyA8YnI+MDY0MTAgPGJyPkJJT1QgLSBTT1BISUEgQU5USVBPTElTPGJyPkZy YW5jZTxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YSBocmVmPSJodHRwOi8vd3d3LmNp c2NvLmNvbS9nbG9iYWwvRlIvIj48c3BhbiBsYW5nPUZSIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5D aXNjby5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6 OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PG86 cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PHRkIHdpZHRoPTE4NiBzdHlsZT0nd2lkdGg6MTM5Ljc1 cHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0Ojk0LjA1cHQnPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiInPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiJz48aW1nIGJv cmRlcj0wIHdpZHRoPTE2NCBoZWlnaHQ9MTA4IGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmlt YWdlMDAxLnBuZ0AwMUNCMjUwOS44RTMwRkU2MCI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+ PC90cj48L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Rpc3BsYXk6bm9uZSc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBi b3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NzE5IHN0eWxlPSd3aWR0 aDo1MzkuMTVwdCc+PHRyIHN0eWxlPSdoZWlnaHQ6OTAuOHB0Jz48dGQgd2lkdGg9NzE5IHN0eWxl PSd3aWR0aDo1MzkuMTVwdDtwYWRkaW5nOjBjbSAxOC4wcHQgMGNtIDE4LjBwdDtoZWlnaHQ6OTAu OHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwJz48aW1nIGJvcmRlcj0w IHdpZHRoPTE4IGhlaWdodD0xOSBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDppbWFnZTAwMi5n aWZAMDFDQjI1MDkuOEUzMEZFNjAiIGFsdD0iVGhpbmsgYmVmb3JlIHlvdSBwcmludC4iPjwvc3Bh bj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+VGhpbmsgYmVmb3JlIHlvdSBwcmludC48YnI+ PGJyPjwvc3Bhbj48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+Q2lzY28gU3lzdGVtcyBGcmFu Y2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVlIENhbWlsbGUgRGVz bW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90IDcgOTIxMzAgSXNz eSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBS Q1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVhbi1MdWMgTWljaGVs IEdpdm9uZSwgRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PC9zcGFu PjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6Izk5OTk5OSc+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fi b3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIj48c3BhbiBsYW5nPUZSPmh0 dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5k ZXguaHRtbDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZTo3 LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMDA5OTAwJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RlI+PG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZSPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_002_01CB24FB.AB562FC3-- ------_=_NextPart_001_01CB24FB.AB562FC3 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.png Content-Location: image001.png iVBORw0KGgoAAAANSUhEUgAAAKQAAABsCAYAAADkDhmYAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABgJSURBVHja 7Z0HeJVF1sdVbJ9rWctaVlEpYgOxLaCAuvjpolgAC12luK4sghjAANKkSZGW3hNSICGQ3hNCOkkg vRES0nvvyU35f+cMuSmkAslnrsx5niEhuXfeue/85tSZNzdBipShIb9u27btppvkfZAigZQiRQIp RQIpRYoEUooEUooUCaQUCaQUKRJIKRJIKVIkkFIkkBJIKRJIKVIkkFIkkFKkSCClSCClSJFASpFA SpEigZQigZQiRQIpRYoEUooE8v9dmpqb0dzSopJjb6Fx8/glkH8SqVc0Ii2/CNlFpWhWsYnlRZRT XIa0vCLUNSgkkKoudQoF4jNyYel9Fif9zyOjoASNjU0qMfbGpiZkFZbCLiAC5l4hiE3LRm19gwRS lYW1i6lHEJbsM8V/j1jCKSQa5VU1KjH2ypo6uIbG4gcNKyzeawIj1wABqARSheX8hXT897Al/rF8 Byav/A2/HnVCen6xSow9m+DbaeGCKav24PXvd+C7g+YITbgkgVRlcQmNwTs/7cPIhesxgtqc7XqI Ts1SibEnkKuxYKcBRixYL8Y/9cc9sAuMlECqspzwP4dXvvsVTy1QxxNz1+Ff6gcRfiFNJcYeRQtn xobDeGLOOoJSHS99uxWWPmclkKosJwMjhLlj7fjk/J/xIU3w+eR0lRh7zKVsfPKLBobP+1loSF5Y x3zDJJCqLKcIyH8s39kG5IyNR1QKyE83aeLJViBf/c92HJdASiAlkBLIPoVrLi39qLxcK5Atg1zV 6U//1wokd62iRSnVBbKovAqFpRV9lgOvBcgGRRNyS8pRXl07KGOvqKlFbnE56hsaBxxIvh2FZZWi qSiTqgUk13TzSyrgER4Hl5AYZBaWQNHUNGBAcmUnMSMPdvS+gJhklFXVDFgNnLthyIPiLorqS3x6 Tq/lwKsFkis72UVlIpnuRi23uEwVa+CqBWRFTR08z8Vjnb4tVmtbwz4oEsUVVQMGZEZBMUzcA0Uy fbu5E8IS00QtfCCkobFJXHunpTOWU/8Grv6iRj1QQJZUVsM5JBpqOjZYo2tDUMbQAlCNqpTKApme X4LdVq74p9p+TP1xLzYa25FGyx0wIFkrckXkjR9246MNR2DkGojyqoEx3ZW1dTjqGSxSOZN+2IWl +83gG5k0YEAmZ+Vjq5kD3l69D2//tE8sqNTcQgnkYErkxUzM3a6P0V9twKhFG/ARAXYm6sKAAcmb GN5cuVv0/ew3m4QWZn9yIKSwvFJo9ucWbxLjn/DfnTByCxwwIANjUzBrsxZG09hHUf+fb9UhDa9y pcahAST7V/3xd4LjUzBtzX4Mn7cOTxFgE1fshPPZmAEDUsPuNIH4iwCAKyQLdxsig/zUvqQ/Y2ew F+8zERWjUYvWCyj323gOGJDsykxe9Zu4L8OpvbV6Ly3WpD7HxVvyWoZOWD40gGTtkZFfTJGnok8g 3137O00SA6kuTJ/LAAKpaX9aaLCRpGWGEziLfjMSgVNvUklRM/uCfUXleQTkkv2mYjExjM98vRH7 TwwskFN+3COA5M/KZrsvINk/5i15BWUVEkixOmllsjPOUfMxn1AkZOT0GkSEJKTivXUHxE1/eoG6 MK8cVQ4UkFoOvnhhyWZhshmEr/cY9wpkdV09QsksWpCp58VSVVfXK5DLfjcT42AgWRMfsPUaMCC9 zicIrcj3hWv37Gf7RffsznCQlZSZh+Onw+AWFosiCg6HwK76PxZIjgJt/MJFILFglyF2UATa226c oQRkI5k6X/Jf2S+cv9NARLfeEQlQ9LABeKgByWmn3465YiHd938fOAqr06FCOdzQQF4iU8d+1eUJ 2oTXl+/AUa9glQCSc4jbLZzF659b/AueI8A2mdj3qCWHGpDc18QVuzCGxjF60UbhLydl5d3YQCZn FWDmFi08/Nlq4bONJGdfx+mMSgBZQ0CuJe342Bdq1Pc6PPq5GlZpHhOVGFUA0pgifPZjH5+7lu7/ T5ix4Qji0rJvbCBTcgoxb6e+CFIYgrHLtsDILUAlgKwlIH8hjciwMGC8Z5HNN+cbVQFITnGN//c2 oQT4Gp9v0xGbgm94IOfs0CPtuFZA8MLSzTB09e/x9cHxqe1R9oLBi7JH9SPKZiA3GNsJEBmwp6n/ NXonegXyyij790GJstXps6r3GWVzkn7ct1sxgoDkzzp7q7Y4EHdDA3kxuxBfbtfFE3PWipv+/JJN MHDpDcihk4dkINcbnRLjGCW0zDqo6dr0CORg5yE9WvOQT/YzD2nmESws0oiFl3fTzyLXiQOdGxpI zoHxacAxpC1YK/GBJusz4T2+PuJipjgXI6oR1GYMcKXmqGeIKBuKSs3Xv+BHrZ4rNZyeYqDGf7tN vH7c0i3YZeUqUkHdyeVKzQkKfjaJSgpXagxdAwYMyMDYi5i5WUuMhfv/bKuOSEn1JLyBhM8bjfpq PZ75aqOItFNyCm5sIHljhI7jGUxXPyRA4E0HIWSWexKuZe+ydBU3kuHdYGTXq99ztUD6xySLieGx sJNv6BKAsh5q2by7xjEoCnN36Ito9YttujgVEIGGHvKorDnNPILw8UYNTCRXg4/mno5MHDAgL2Tl Y4upA976ca/QjnzCMjWn51p2eFI6VlIQxn74++sOknXwQUHpH54g/2OBrG1oQBCZYU6XLD9kCTPP oF7PHnM1xD0sDmt0T1BEe1wAV1RROWBA8hFZPv/8/UELbDNzFMdOe0rUc7ktISMPh0564bsD5vjd xgNx6dk9Ph2DE9F8wIw3PfyH+tdz9sOlXjY/XMtuH8fgKKwmrf6TtjX51tFi+1xPwnsyLbxDxM6m jbSw/WMuoKbuD38QwdCo1PiSr8N7BC9k5fVaqeGaMQcHbgSlU3C0MPm97YfkU4cvdzh1+H4fpw45 t5iQnotT/ufhH933fkg2zwy4rd85hCWloaq250oNA8wPKQiITRZP0Yjr40kUfOrwQ3HqcK0InMb1 cepQ0fqkC+eQGLiSX80PSWhs6rnG3tDYSD58PuwDI+ETkSisVXPzDV6pUUopTRRvKOWb1Ke07oou 6MeOcceQKHL09wgNyVByJBmVktnre9jk8mSW9XPbWQ1BmVNUiqoefMfutHxOUVmfdXsOML78VZei d3WhISet2A1bArmvBV7QtmO8b7i4qsQLvPSPr9AMLSCVGqT/r+3f69kf5ceQcL6Nj8OqG5zs1x7B q63pDsbrM8hfZlPK4+bAadFuIwTEXOzXfby6ezmkDjv8uU8d8g5wbQdfEZl/s8cYNhTBD4F6bb+E 3QXWiEtoQbGmPEJBx6Xcoj/rVN0YQFbX1+Mc+Xi6TmdEhJtMPlPDAB1JGGxhc3qRomRzz2CRiQjt w0eVQKqAsDli3463taUQjIpG1YCxDUoKVFJzCoQ/yWmjIWZeJZDXPLEEYmOTajwX8kppoki5QcUW kgRSigRSihQJpBQJ5FCWpro6NNbUoImiafF9dTVaBtFX5Osor9d4nddrVijE+5tqa0Xj75sbrr50 J96rHBN9VVRVoUV1fU7VA5LjzCaauKqsLGT7+CDNwQEZLi5Id3Ki5oyiyEgxMS3d1ZT5T2zQxDWU l6OuuFg0/p5hbunlKGtzYxOq8/KQc+ZM+/WcnZHu6IiCc+fQUFmF5n6C2Uyw1JWUIC84RIw5w9VV tDT6Pi8wUIypP0Dx9apzc5HNY6JxiDGJ5oqiqCjxmSSQg60RFY0oTknFBTt7BG/7FW7z5sH+rbdw auJEnJowAQ7/mg6/1auRameHusLCTiAqNSpP4Fl1dbjNnAlXasFqashwd0dDRfc7Xero5xkBgQjd tx/uCxe1Xc+OmuP778Pn++WIMTFFceKFXrUlp2wqc/OQ5u2NcwcOwHPJUjh+OAP2770vGo/de+ky xBsYojQhkYBr7nFBcj85gUGI0dGF97ffwf6dd2hMk2BH/bh8MQdBGzYilRZO2aVLaFKRvzqhckDW k9ZLP+2LgLXrcJJuvNnIUdC/915o0vAPtzatm2+G2ajR8P1hJUoSEroAqaisRLyhIazHjcMBev3v 1KxGj0bUwYOoKei6F7CKJj7xuDXcF30N8xfGQv+v90OD3nOo9Xp8bd37H4DNm5ORdNwGjT3UpxvJ POfHxOLcoSNwmj0bFi+8CIMHHoT2rbeK/rhp0tiNHn0MzrM/Q4qDI7kEXWvjjGjRhWREamrBkxbH CYLQ+LHHoUXvP9I6Hv17/wrzMc/Cafp0BG/ajAzfM+JzSyAHSJilOrqhKR4ecFu0CEb33Qdtmjxd GrZ2a9Np/coTo3PHHXD84kvkR0R06YsnJtHMDKcmTRKTxyDYjB+PGC0t1BR1LsvVV1Uj2d4B9h9+ BP177hHX4MbX1Rs2DHoEk95tt0HjlltgRAsj6vARKBSKbrS6Ajlk1v02boLFuPHQoffpdBiz8nvN 1v9bEWQxZkehuOJBUax9C2PjELx9B4699jr07rhTjKXjZ9fq0Kce3SPjx/4Oj0VfIZ1cgoYKlYBy 6ANZT85+iocnXOfOJa3ygJg4rQ4wGhAspqQtTZ58SkwQ/85+1izknT/fVUOSw59kbg67yZPbJtH2 tdcQq6OD2iuAZE0U8MsmmDzyqABXqxVG85Ejcep/34MdmVtu5i+NFxovzsCoi5llPy+XfFrfn3+G 2egx0CKQO45d7847YfzEkzAbMQp6d90lfmfx6muINjahsbbX3Hn0ZWlpCFr3M0yffho6tBA69tO2 MIfd2gVQo4ceggdp00w/f+HySCCvU0oupuC02loYPviQgFGn9UazdrImTeH17+8Q/OsOAY87+5TT P4Cf+noUKU12h0fK9hdIDjxSvX3gNIcWAWkiASNdz3zMGASsX49Udw/yBX1wydMbscamiDiiibzQ cAqMOpf26ihgCj+iAbMXx3ZaSLq33Q6L51+A64KFCCCzyuP3WvYtHD/6GB70NZlNdofjtHU07sST drAhWA937Ie04NGnR8Bh2jR4z5sPD/r8J96YDCNauErNy4vJ5O+PI5Q0a0V6hgTyeoRTI6nOLjgx 5S1ok2lUmkxd0ia25LdF6ukjLzoGFdnZKCUHPvfceaS4uSHd5zSq8wuuGcjG+gYy146wJ0CUQLI2 s546FbGmZqgpKRWmWIyRIGwgbaaore0UqQsTS36j+1dfQ/d/7mo3+bffAStaSEE7dyEjKBhlBEl5 Zhby6XOk+fggxdUNRXHxaOrgjxbGxcFnxUoBltIkM9RWpJn91TfgEpnk0thY5J89i2gjYziSH2pE vq0OActjN7j9drh88gnS3dwlkNcjFTnZCNv9G0zJ2VdqR30C0/bttxFF0WgVBSLKIwMiHUQQMBgM SHM35qnfGpL6zPDyhvuXX8Ko1ZTq0nWNyfy5z1+IWHNLZIWEoDInp8cjC7VlZUi0PoGTU6Z08nUt xo4VMBYlJ3cKgrgfBaekaIyNDHfrIuJ/OWI+PnYcNG+97bJ/eNPNMH/+RQRt2UqWIFF8Zl50zY0K VBcWId7qGOw/+EC4M8rrmj/7HKK1dXpNb0kg+xCOTE+v+AFGd98jgORmQKYzkHypiryrPyHXG5BX BjWlBEyg2hro0/UOdQg+TB76G6wnTITzp5+KFFPCseMoy+y6C521dtiBg6TFXmgPuG6+CW7kBuRG RPZ7zA2krWP1DWD24IPCXGuLRTmMFsYCZIV2f8aGNW7Yvn2weOaZNvOuf/+Dwmy3DO1NJkMbyGwy wZ7kIxrdc6+4sewPGZLpjNPSvqb+rgbIBtI6yba2ODV5CvTJf9XpECi0TfLdd8PmrbcRums3iuMT hO+plLL0dATTz4+OHt32Hl0CMkhNTSTS+yu15RWI0tTC0UcvB1fKRRmyYSOqCrvfsKuoq0eykxNs 33ijPSC7626c3bxZAjkYQMbr6Q06kGwqawoLkeLoCO8fVpKJfF6Y7SsjW23yCS2eegrh5FqUZ2V3 BbJVSymj9OC1a7vNMfYKpIZm90AWFPYMJI3bdtKkdiD/8hcJ5PVKPjnzvitXdTbZ5KCHbduG2tKS q+7vaoBse09DA7kOMYg1MYEfjcV15iwcI8j0WoHUaP3q+PEnuESRd0trZaSC/MvwQ4dh9eKL7Sab mvfX34jMQX+lvrZOVGRMSUsrI2z9YcPg881iFEZFdfueitw8hB08CMsxz7YtBr377sNZum8SyOuQ 8qwshFIAYPrY39sSx5yUdvrkUzJJzqjv5q8McO6PI+A2573DLutrAbKjcBCVExyC0C1bYDFylKi0 6LSmX46TXxljZCI2XVzWbOXCv7TloIZ+r9SoNhMmiOxAZV7XR9/x4S8euzD9ynInfZ5k25M4xqkj up4y3WPzyiuIOnCgPZvQKuxqXHR2pUh7Ngzv+2vbdY1Ji587eEgCeT3SQMAlWtvgxJSposKh3Wr2 OP3hsWSpSJFw8FBXVi6AKk9LR35kFAqiY1BPUe7lWW7uV9qnE5AcsfJuHN6Jc8UOHAYmOyAQDp/O hF5rFMtjsnr5FUSSJmuovpzQ5hpyFsHLuUY98jWVKSsDgsRuxkeIPWqOkpRU1JaUoo5aBZn7wrgE 5J6PoKAks5M/yp+J863GjzzSXt2543acevNNJFhYojwjA/Vk2vl9XNHy+n45TB9/XIArFjHdO9t/ TkMSgT3Ej0EMbSA50VwYGwvfFStgQlGm0uzxjTYhrWk/7V0ErN+A89o6IqINIL/K8z/fI3jHTpQk JbVryKvMQ7J2rSDtnO57hibxFC66uiMrLAw5ERHIpwg5ljSc9auviTKlEhCrV15FlJ4BFNXtFZaq /HyE790Ly2efbYvSuRnefz9s334HvmvWIvywBs4d0RApHM418s9SXFwvp3JahRdckpUVbF9+uc1F EPlF8qdPvvEm/Fb9iLC9+0VxwHHmTJgNHy7ukbIkafzwI/Bf9zMKO9b3JZDXqCUrKpBC0a7jv6ZD lyZA84qgwvjRx0S5zXzsOBjTROiT828/azZyw8I6abyrAVKU/MLDEbR5K+xnfAx78hs9li4TzYt8 NzuKXg1I67T5Z1w/J42Z4uLWSaOKfoKC4LNsmSjhaXTwJTlpbchj59Lj+Jdh8vQIGJAGtJw4SeRY OR/Z4QOgPDkZAatWweChh7qUT9k0m416BibDn4IeBVlaHaDVv/c+OM3+DJfc3NFQM+T/kJJq7Pap zssn7aMvEuIGd7VXPbS621xB0Dp+/gXyzve8ueLkxIntmyteeklsrrgyMZ7l5wcv3szBEf4tw0Q+ Utn0Omg7vdtuxzHSjudIQ3P+78q/fMmbJHj3jsucuTB8/Anq65a28XbZXEG/s5wwCTGmZl02V7AJ T/cPEK6KCe8UojHpdFPP1u5QVuRyqyMtJnZ7aopLhvo0qw6QLBU02fHmFnCnKNX8pZdFOU6jddvV kQ5b0HTvuBNui5eQPxbfFUjStvFGRrAePx4H6bW8Bc2KIuaoQ4dEiqddobYgkzSb6/z5YnL3t245 69j42kYPPwy76R/i7O49KIyJExt5u5Pa0lKkkobyXbMOx96YDIMH/9Zp7Nx4PBoEmc277yGR3ITG bp77U09mPIv81wAy69Zk8g3IjdHs0IcyLcT50WOvvw6v777HhVP2qC0uVoUpVi0gxcRSoJIZFIwI HT2cJsfd8Z13YE/m12HqVNhTNMum2HPefAFuFWnVK4W3++f4+yOMomTPOXPgQe3s+vXI9PJCwxV7 BkvT04VWdp0xQwQPfA1l4+s4krYOUFPDBXsHFJM5bVL0/qweRW0d8mJiKZixQID6ejiTibejYM2B xs3tJPXpPOszEQkX0Ot6Kkky9EWJSYg/bg2/n36C07RpbfdA9EXj8l68GNFk9rNDw1BXPmT+Bs2f D0ihvWiimkh7VFF0nePri0xXV2QRUJkUXWa4uaE4KupyLbiHIwwieuazJwQgN/6ef3alqeX3sxnP CwgQRwz4GsrG1+HjE5UU3bIp7W/g2tKa1qkjjZkfGir6yfL0FI2vkR8SIn7X13EIUbenfqpzcsSx io73INPdvfd7IIEcPGEY+FgCBxLioFd9/YBfo6XjNZSNrtPch0bse/DNnfvlcz3XkCPscg84D6q6 T7iQx2ClSCClSJFASpFASpEigZQigZQiRQIpRQIpRYoEUooEUooUCaQUKRJIKRJIKVIkkFIkkFKk SCClSCClSJFASpFASpEigZQigZQi5Q+U3RJIKUMSyF2yyTYE2nsCSP5HNtmGSvs/hQgkdONYbE8A AAAASUVORK5CYII= ------_=_NextPart_001_01CB24FB.AB562FC3 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CB24FB.AB562FC3-- From nicolas.dejean.ietf@googlemail.com Fri Jul 16 09:06:30 2010 Return-Path: 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 C27FB3A6A31 for ; Fri, 16 Jul 2010 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.422, 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 R4Ot6MTckUck for ; Fri, 16 Jul 2010 09:06:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id D15803A67E7 for ; Fri, 16 Jul 2010 09:06:25 -0700 (PDT) Received: by eyb7 with SMTP id 7so651519eyb.31 for ; Fri, 16 Jul 2010 09:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Pc2z6DM68SxLv23br1Bi4JJolxdwCP4VZXreqXROQLc=; b=GKm4kRZ6TU3uJ0jt4iAOeEaUcWLqEzCWwigosn1RrdOK4q+PTtfQ+yl7gLkignjRdC 7EvS5C5eH1DEA+1h/8Lh3maIMQli8rT3thoLtwOJUZjyFBWi7ACZ9Pn5EI8IoN69B7WB hYEG5bW/nYQ141w/jBDE8NbB/eImtY5gLFx1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LBXMNA59PM/IcBGemMCwvSw8boC8WL1UBtnulMntY5whHrLsDM3r8qnW0b0SRIHUaO fY67Pf746v7HDIM7KLtYxXbnJPTP25yUc6Z41vZGhjupZzdAF9i+o10fjccFfJqPIKp8 JSrOYToqI8VM558d5A2Go3/cNVtmfUkrPOlJY= MIME-Version: 1.0 Received: by 10.213.32.141 with SMTP id c13mr4448414ebd.75.1279296393638; Fri, 16 Jul 2010 09:06:33 -0700 (PDT) Received: by 10.213.15.6 with HTTP; Fri, 16 Jul 2010 09:06:33 -0700 (PDT) In-Reply-To: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> Date: Fri, 16 Jul 2010 18:06:33 +0200 Message-ID: From: Nicolas DEJEAN To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Fri, 16 Jul 2010 16:06:30 -0000 Hello Phil, 2010/7/16 Philip Levis : > > On Jul 15, 2010, at 2:25 AM, Nicolas DEJEAN wrote: > >> >> Implementation of the proposed mechanism requires some modifications >> into the draft for having the ability to: >> - keep the same behavior as the one currently described into the Draft >> for reaching consistency (R=3D1, U=3D0 allows that), >> - implement the proposed mechanism for leaf nodes deployment (R=3D0, U= =3D1 >> allows this case). >> >> >> For instance, in rpl-10, the text from 7.3 might be changed like this >> for managing the Reset of the Trickle Timer: >> ---------------------- >> =A0 o =A0When a node receives a multicast DIS message *with the R flag >> set and* without a Solicited >> =A0 =A0 =A0Information option. >> >> =A0 o =A0When a node receives a multicast DIS *with the R flag set and* >> with a Solicited Information >> =A0 =A0 =A0option and the node matches all of the predicates in the Soli= cited >> =A0 =A0 =A0Information option. >> ----------------------- >> >> A sentence like the following is also required: >> ----------------------- >> When a node receives a multicast DIS *with the R flag clear*, it MUST >> NOT reset its Trickle Timer. >> ----------------------- >> >> Also, a sentence might be added for managing the transmission mode of >> answered DIOs: >> ---------------------- >> When a node receives a DIS (unicast or multicast) with the U flag set, >> it MUST unicast a DIO to the sender in response. >> ---------------------- >> >> Clearly, some use case have to be described for specifying when to set >> or not R and U flags: >> - default operational mode for network consistency: R=3D1 and U=3D0, >> - specific leaf node deployment: R=3D0 and U=3D1. >> >> As a conclusion, the goal of the proposed R and U flags is not to >> modify the well-known behavior that allows the network reaching >> consistency but to extend the possible usage of DIS/DIOs to >> energy-efficient leaf node deployment. >> >>> Phil >> >> For answering directly your question, I do not expect that RPL >> includes the proposed mechanism. >> It might be described in a separate document if the WG shows some >> interest for it. >> >> However, adding these two flags to the Draft is one solution for >> allowing this mechanism to be implemented. >> >> Is my concern clearer now? >> >> In these conditions, does the integration of R and U flags seem acceptab= le now? >> > > Why doesn't the existing mechanism (unicast request obtains a unicast res= ponse without resetting the timer) solve this problem? > See answer to your question 1 below. > The mechanism you describe has a serious flaw; I brought this up in prior= responses but you haven't explained why it isn't a problem. In particular: > > "When a node receives a DIS (unicast or multicast) with the U flag set, i= t MUST unicast a DIO to the sender in response." > > If a node sends a multicast DIS with the U flag, then it will cause all n= eighbors to send a unicast DIO in response. Because the responses are unica= st, they will not suppress one another. This traffic pattern (a flood respo= nse) is a terrible problem in low-power wireless, in part due to the hidden= terminal problem. Nodes will be possibly spending lots of energy to transm= it packets that just collide. I think it is a bad idea to assume that an LL= N node has an excellent enough understanding of the network in order to car= efully expand DIS predicates until a small number of nodes respond. > We indeed don't want unicast responses to suppress one another. The "flood" will be kept under control by the DIS options. It is our experience in smart metering network that the LLN node (via the technician impatiently standing in front of it during installation) does have enough understanding of the network to craft DIS predicates, and does not want to wait one minute more than absolutely necessary. Note that the Trickle max period is anticipated to be several hours in water/gas smart metering networks. > It's useful to note that if a message does not reset the timer, handling = suppression in a safe way becomes an open problem. That is, I do not know o= f any existing solutions that have been evaluated in real networks. E.g., l= et's say we're close to the end of an interval. If a message does not reset= the timer, then if there have already been enough transmissions in the int= erval a node won't respond. Responding without suppression can lead to a fl= ood response. There might be ways out of this (e.g., resetting the counter)= , but I'd consider such approaches highly highly experimental. > > It sounds like you want to be able to send a multicast message and get an= immediate, single response from every neighbor? Your original mail said: > > "Just to re-inforce this calculation, it has been our experience that > node insertion into a dense low-power network, if done wrong, is a > significant energy drain." > > So I guess I have 3 questions: > > =A01) Why does the unicast/multicast distinction not solve the problem? When inserting a new node in a dense environment, without pre-existing information about the qualifications of routers around, running through their list one by one is an expensive proposition. > =A02) If the issue is discovery on inserting a new node, can you explain = how unicast responses from many neighbors (or an iterative DIS with options= search) is more efficient than suppression over a logarithmic number of in= tervals? With our MAC layer of interest, unicast responses will not induce overhearing at other receivers in the neighborhood, while multicast will. With the DIS search options, there won't be that many neighbors to respond, and we will quickly get responses from all nodes we are interested in, not at some random later time depending on suppression. > =A03) If the issue is inserting many new nodes at the same time and many = triggering resets, why doesn't a simple DIO timeout (e.g., 5 minutes) befor= e issuing a DIS work? > See explanation above about technician not having to wait one minute more than strictly necessary. > I feel like there's some very specific use case you're trying to describe= and I just don't understand it yet. Sorry to be slow. > Please excuse my french ;-) > Phil Cheers, Nicolas. From pthubert@cisco.com Fri Jul 16 09:19:36 2010 Return-Path: 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 6F9A63A67AC for ; Fri, 16 Jul 2010 09:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JLAb7qj3Am0j for ; Fri, 16 Jul 2010 09:19:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4640D3A6A44 for ; Fri, 16 Jul 2010 09:19:35 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANsiQEyrRN+K/2dsb2JhbACDH5tpYnGlAYkvkTeBKYMJcgSLBA X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="267956946" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2010 16:19:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6GGJJBX015547 for ; Fri, 16 Jul 2010 16:19:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 18:19:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 16 Jul 2010 18:19:36 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02574B0C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing issue#56 (2nd): Transit and Target address mismatch thread-index: AcslAq5x7BE3Tkv6SV+9AphapiKK7Q== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 16 Jul 2010 16:19:39.0504 (UTC) FILETIME=[B0B58700:01CB2502] Subject: Re: [Roll] Closing issue#56 (2nd): Transit and Target address mismatch 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: , X-List-Received-Date: Fri, 16 Jul 2010 16:19:36 -0000 VG8gbWFrZSBzb21lIHJvb20gZm9yIG5ldyBmbGFncyBJJ20gcHJvcG9zaW5nIHRvIHJlZHVjZSB0 aGUgdHJhbnNpdCBsaWZldGltZSB0byAzIG9jdGV0cy4NClRoaXMgbGVhdmVzIGFib3V0IDIwMCBk YXlzIGJlZm9yZSB5b3UgaGF2ZSB0byByZWZyZXNoIGEgcm91dGUuDQpXb3VsZCB0aGVyZSBiZSBh biBpc3N1ZSB3aXRoIHRoYXQ/DQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gU2Vu dDogVHVlc2RheSwgSnVseSAxMywgMjAxMCAxOjUzIFBNDQo+IFRvOiBNYXRoaWxkZSBEdXJ2eSAo bWR1cnZ5KQ0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbUm9sbF0gQ2xvc2luZyBp c3N1ZSM1NiAoMm5kKTogVHJhbnNpdCBhbmQgVGFyZ2V0IGFkZHJlc3MgbWlzbWF0Y2gNCj4gDQo+ IFJld29yZGluZyBhZnRlciB0aGUgdGhyZWFkIHdpdGggTWF0aGlsZGUsIGhlcmUncyB3aGF0IHRo ZSByZXNvbHV0aW9uIGZvciBJc3N1ZQ0KPiA1NiB3b3VsZCBzYXk6DQo+IA0KPiAtIFRoZSBSIGJp dCBpbiBQSU8gaXMgdXNlZCAgYXMgaW4gUkZDMzc3NSB0byBpbmRpY2F0ZSBhIChnbG9iYWwvVUxB KSBhZGRyZXNzIGFzDQo+IG9wcG9zZWQgdG8gYSBwcmVmaXguDQo+IC0gVGhlIHByZWZpeCBpcyBz dGlsbCB2YWxpZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYXV0b2NvbmYgd2hlbiB0aGUgUiBiaXQgaXMg c2V0Lg0KPiAtIFRoZSBhZGRyZXNzIHVzZWQgYXMgdHJhbnNpdCBwYXJlbnQgYnkgdGhlIGNoaWxk cmVuIE1VU1QgYmUgdGFrZW4gZnJvbSBhIFBJTw0KPiBmcm9tIHRoYXQgcGFyZW50IGJ1dCBpcyBu b3QgbmVjZXNzYXJpbHkgb24gbGluayBmb3IgdGhlIGNoaWxkcmVuLg0KPiAtIFRoZSByb3V0ZXIg dGhhdCBpdCBhZHZlcnRpc2VzIGFuIGFkZHJlc3MgYXMgcGFyZW50IGluIFBJTyBtdXN0IGFsc28g YWR2ZXJ0aXNlDQo+IHRoYXQgYWRkcmVzcyBhcyB0YXJnZXQgaW4gYSBEQU8gZm9yIHRoZSByb3V0 ZSByZWN1cnNpb24gdG8gY29tcGxldGUuDQo+IC0gQW4gYWRkcmVzcyB0aGF0IGlzIGFkdmVydGlz ZWQgYXMgdGFyZ2V0IGluIGEgREFPIG11c3QgYmUgY29sbG9jYXRlZCBvcg0KPiByZWFjaGFibGUg b25saW5rIGJ5IHRoZSBwYXJlbnQgdGhhdCBpcyBpbmRpY2F0ZWQgaW4gdGhlIGFzc29jaWF0ZWQg dHJhbnNpdA0KPiBpbmZvcm1hdGlvbi4NCj4gLSBBIG5ldyBmbGFnIGluIHRoZSB0cmFuc2l0IGlu Zm9ybWF0aW9uIHF1YWxpZmllcyBhIHRhcmdldCBhZGRyZXNzIHRoYXQgaXMgYmVoaW5kIGENCj4g cm91dGVyLCBlaXRoZXIgYXMgYW4gYXR0YWNoZWQgaG9zdCBvciBpbnN0YWxsZWQgb24gYW5vdGhl ciBpbnRlcmZhY2UuIFRoZSByb3V0ZXINCj4gaXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3Igc3Vj aCBhZGRyZXNzLg0KPiANCj4gV2UnbGwgbm90ZSB0aGF0IGlmIHRoZSBub24tc3RvcmluZyBtb2Rl IERBTyBpcyBzZW50IHN0cmFpZ2h0IHRvIHRoZSByb290IHRoZW4gdGhlDQo+IHBhcmVudCBkb2Vz IG5vdCBoYXZlIGEgd2F5IHRvIGtub3cgYWJvdXQgdGhlIGNoaWxkIHVudGlsIGEgUkggcG9wcyB1 cC4gU28gdGhlDQo+IGJpZGlyZWN0aW9uYWwgcmVhY2hhYmlsaXR5IHdpbGwgYmUgY2hlY2tlZCBh dCB0aGF0IHRpbWUuDQo+IA0KPiBQYXNjYWwNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiA+IFNlbnQ6 IEZyaWRheSwgSnVseSAwOSwgMjAxMCA0OjU4IFBNDQo+ID4gVG86IE1hdGhpbGRlIER1cnZ5ICht ZHVydnkpDQo+ID4gQ2M6IHJvbGxAaWV0Zi5vcmc7IGpwdkBjaXNjby5jb207IHdpbnRlcnRAYWNt Lm9yZw0KPiA+IFN1YmplY3Q6IENsb3NpbmcgaXNzdWUjNTY6IFRyYW5zaXQgYW5kIFRhcmdldCBh ZGRyZXNzIG1pc21hdGNoDQo+ID4NCj4gPiBIaSBNYXRoaWxkZToNCj4gPg0KPiA+IEJhc2VkIG9u IHRoZSB0aHJlYWQgd2UgaGF2ZSBoYWQgSSB0aGluayB0aGF0IHRoZSB0ZXh0IG11c3QgY2xhcmlm eSB0aGF0Og0KPiA+DQo+ID4gLSBUaGUgUiBiaXQgaW4gUElPIGlzIHVzZWQgIGFzIGluIFJGQzM3 NzUgdG8gaW5kaWNhdGUgYSAoZ2xvYmFsL1VMQSkNCj4gPiBhZGRyZXNzIGFzIG9wcG9zZWQgdG8g YSBwcmVmaXguDQo+ID4gLSBUaGUgcHJlZml4IGlzIHN0aWxsIHZhbGlkIGZvciB0aGUgcHVycG9z ZSBvZiBhdXRvY29uZiB3aGVuIHRoZSBSIGJpdCBpcyBzZXQuDQo+ID4gLSBUaGUgYWRkcmVzcyBp biB0aGUgUElPIGNhbiBiZSB1c2VkIGFzIHRyYW5zaXQgcGFyZW50IGJ5IHRoZSBjaGlsZHJlbg0K PiA+IGJ1dCBpcyBub3QgbmVjZXNzYXJpbHkgb24gbGluayBmb3IgdGhlIGNoaWxkcmVuLg0KPiA+ IC0gVGhlIHJvdXRlciB0aGF0IGl0IGFkdmVydGlzZXMgYW4gYWRkcmVzcyBhcyBwYXJlbnQgaW4g UElPIG11c3QgYWxzbw0KPiA+IGFkdmVydGlzZSB0aGF0IGFkZHJlc3MgYXMgdGFyZ2V0IGluIGEg REFPIGZvciB0aGUgcm91dGUgcmVjdXJzaW9uIHRvIGNvbXBsZXRlLg0KPiA+IC0gQW4gYWRkcmVz cyB0aGF0IGlzIGFkdmVydGlzZWQgYXMgdGFyZ2V0IGluIGEgREFPIG11c3QgYmUgY29sbG9jYXRl ZA0KPiA+IG9yIHJlYWNoYWJsZSBvbmxpbmsgYnkgdGhlIHBhcmVudCB0aGF0IGlzIGluZGljYXRl ZCBpbiB0aGUgYXNzb2NpYXRlZA0KPiA+IHRyYW5zaXQgaW5mb3JtYXRpb24uDQo+ID4gLSBBIG5l dyBmbGFnIGluIHRoZSB0cmFuc2l0IGluZm9ybWF0aW9uIHF1YWxpZmllcyBhIHRhcmdldCBhZGRy ZXNzDQo+ID4gdGhhdCBpcyBiZWhpbmQgYSByb3V0ZXIsIGVpdGhlciBhcyBhbiBhdHRhY2hlZCBo b3N0IG9yIGluc3RhbGxlZCBvbg0KPiA+IGFub3RoZXIgaW50ZXJmYWNlLiBUaGUgcm91dGVyIGlz IHRoZSB0dW5uZWwgZW5kcG9pbnQgZm9yIHN1Y2ggYWRkcmVzcy4NCj4gPg0KPiA+IFdpbGwgdGhh dCBiZSBlbm91Z2ggdG8gY2xvc2UgNTY/DQo+ID4NCj4gPiBQYXNjYWwNCj4gPg0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogcm9sbC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiA+IE9m IHJvbGwgaXNzdWUgdHJhY2tlcg0KPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAwNiwgMjAxMCAx OjQxIFBNDQo+ID4gPiBUbzogd2ludGVydEBhY20ub3JnOyBqcHZAY2lzY28uY29tDQo+ID4gPiBD Yzogcm9sbEBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogW1JvbGxdIFtyb2xsXSAjNTY6IFRyYW5z aXQgYW5kIFRhcmdldCBhZGRyZXNzIG1pc21hdGNoDQo+ID4gPg0KPiA+ID4gIzU2OiBbUm9sbF0g VHJhbnNpdCBhbmQgVGFyZ2V0IGFkZHJlc3MgbWlzbWF0Y2gNCj4gPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLQ0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0NCj4gPiA+ICBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICB8ICAgICAgIE93bmVy OiAgd2ludGVydEDigKYNCj4gPiA+ICAgICAgVHlwZTogIGVuaGFuY2VtZW50ICAgICAgfCAgICAg IFN0YXR1czogIG5ldw0KPiA+ID4gIFByaW9yaXR5OiAgbWlub3IgICAgICAgICAgICB8ICAgTWls ZXN0b25lOg0KPiA+ID4gQ29tcG9uZW50OiAgcnBsICAgICAgICAgICAgICB8ICAgICBWZXJzaW9u Og0KPiA+ID4gIFNldmVyaXR5OiAgSW4gV0cgTGFzdCBDYWxsICB8ICAgIEtleXdvcmRzOg0KPiA+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tDQo+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLQ0KPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiA+ID4gIEhpIEFsbCwNCj4gPiA+DQo+ID4gPiAgTGV0 4oCZcyBjb25zaWRlciB0aGUgc3RvcmluZyBtb2RlIGluIGEgc2ltcGxlIHRvcG9sb2d5IEHDoELD oFIgKMOgIG1hcmsNCj4gPiA+IHRoZSBwYXJlbnQgcmVsYXRpb25zaGlwKS4gTGV04oCZcyBhbHNv IGFzc3VtZSB0aGF0IEEgaGFzIGEgcHJlZml4IOKAmEFw4oCZDQo+ID4gPiBhbmQgYSAgZ2xvYmFs IGFkZHJlc3Mg4oCYQWfigJkgdG8gYWR2ZXJ0aXNlLg0KPiA+ID4gIEluIHRoaXMgZXhhbXBsZSB3 ZSBoYXZlOg0KPiA+ID4gIC0gQSBzZW5kcyBEQU8gd2l0aCDigJx0YXJnZXQgQWcsIEFwLCB0cmFu c2l0IELigJ0NCj4gPiA+ICAtIEIgc2VuZHMgREFPIHdpdGgg4oCcdGFyZ2V0IEJnLCB0cmFuc2l0 IFLigJ0gdG9nZXRoZXIgd2l0aCB0aGUNCj4gPiA+IGluZm9ybWF0aW9uICBmcm9tIEEsIGkuZS4g 4oCcdGFyZ2V0IEFnLCBBcCwgdHJhbnNpdCBC4oCdDQo+ID4gPg0KPiA+ID4gIFRoZW4gUiByZWNv bWJpbmVzIHRoZSBpbmZvcm1hdGlvbiB0byBnZXQgdGhlIHJvdXRlIHRvIGZvciBleGFtcGxlDQo+ ID4gPiBBcCAoVGFyZ2V0IEFwLCB0cmFuc2l0IEIsIHRhcmdldCBCZywgdHJhbnNpdCBSKSAgRm9y IHRoaXMgdG8gd29yaywNCj4gPiA+IHRyYW5zaXQgQiBhbmQgdGFyZ2V0IEJnIG5lZWQgdG8gYmUg bWF0Y2hlZC4gSG93IGNhbiB0aGlzICBiZSBkb25lPw0KPiA+ID4gRG9lcyBpdCBtZWFuIHRoYXQg dGhlIHRyYW5zaXQgcGFyZW50IGFkZHJlc3MgaGFzIHRvIGJlIGEgZ2xvYmFsDQo+ID4gPiBhZGRy ZXNzPyBUaGlzIHdvdWxkIGltcGx5IHRoYXQgd2UgdXNlIGdsb2JhbCBhZGRyZXNzZXMgaW4gdGhl DQo+ID4gPiByb3V0aW5nDQo+ID4gaGVhZGVyLiBIb3dldmVyIDZtYW4tcnBsLXJvdXRpbmctaGVh ZGVyIHNheXM6DQo+ID4gPiAg4oCcV2hlbiBwcm9jZXNzaW5nIHRoZSBUeXBlIDQgUm91dGluZyBo ZWFkZXIsIGEgcm91dGVyIE1VU1QgZHJvcCB0aGUNCj4gPiA+IHBhY2tldCBpZiB0aGUgbmV4dCBl bnRyeSBpcyBub3Qgb24tbGlua+KAnQ0KPiA+ID4gIEFzIGdsb2JhbCBhZGRyZXNzZXMgaGF2ZSB0 byBiZSBvZmYtbGluayBpbiBOQk1BIG5ldHdvcmsgbGlrZQ0KPiA+ID4gODAyLjE1LjQsIEkgIHNl ZSBhIHByb2JsZW3igKYNCj4gPiA+DQo+ID4gPiAgQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSBob3cg YWRkcmVzc2VzIGFyZSBzdXBwb3NlZCB0byBiZSB1c2VkIGluDQo+ID4gPiB0aGlzDQo+ID4gPiBz b3VyY2UtIHJvdXRpbmcgc2NlbmFyaW8uDQo+ID4gPg0KPiA+ID4gIFRoYW5rcywNCj4gPiA+ICBN YXRoaWxkZQ0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4u dG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC81Nj4NCj4gPiA+IHJvbGwgPGh0dHA6 Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gUm9sbCBtYWlsaW5nIGxpc3QN Cj4gPiA+IFJvbGxAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From jpv@cisco.com Sat Jul 17 00:07:17 2010 Return-Path: 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 377353A67F0 for ; Sat, 17 Jul 2010 00:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 4S-HO3Pivxnb for ; Sat, 17 Jul 2010 00:07:16 -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 243343A67A4 for ; Sat, 17 Jul 2010 00:07:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADjzQExAZnwN/2dsb2JhbACfbnGlGJpbhSUEiFeCNA X-IronPort-AV: E=Sophos;i="4.55,218,1278288000"; d="scan'208";a="133537441" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2010 07:07:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6H77RV6001314 for ; Sat, 17 Jul 2010 07:07:28 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 09:07:27 +0200 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 09:07:27 +0200 Message-Id: <79BD7D24-4D0F-4B78-86A7-8F6D4590BADB@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Jul 2010 09:07:26 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Jul 2010 07:07:27.0558 (UTC) FILETIME=[B6F18660:01CB257E] Subject: [Roll] ROLL WG Meeting Agenda slightly updated 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: , X-List-Received-Date: Sat, 17 Jul 2010 07:07:17 -0000 http://www.ietf.org/proceedings/78/agenda/roll.txt Thanks. JP. From yoav@yitran.com Sat Jul 17 00:44:34 2010 Return-Path: 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 285633A67AE for ; Sat, 17 Jul 2010 00:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.861 X-Spam-Level: X-Spam-Status: No, score=-4.861 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 wIaS1eubORQ9 for ; Sat, 17 Jul 2010 00:44:32 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id A3EC73A6359 for ; Sat, 17 Jul 2010 00:44:31 -0700 (PDT) Received: from source ([209.85.161.41]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTEFfam7pzv97SNLm85vHYvMxetyjKLc8@postini.com; Sat, 17 Jul 2010 00:44:44 PDT Received: by fxm20 with SMTP id 20so1833468fxm.14 for ; Sat, 17 Jul 2010 00:44:42 -0700 (PDT) Received: by 10.239.164.66 with SMTP id s2mr148179hbd.99.1279352682114; Sat, 17 Jul 2010 00:44:42 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acslg+esSJNlUmT+TQCi6gazNYIetA== Date: Sat, 17 Jul 2010 10:44:36 +0300 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=001485f197c428ef11048b908280 Subject: [Roll] question about section 1.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: , X-List-Received-Date: Sat, 17 Jul 2010 07:44:34 -0000 --001485f197c428ef11048b908280 Content-Type: text/plain; charset=ISO-8859-1 Hi, Should we mention here that L1/2 performance characteristics primitives are expected to be passed to RPL for its metrics calculations? Thanks, Yoav 1.2. Expectations of Link Layer Type In compliance with the layered architecture of IP, RPL does not rely on any particular features of a specific link layer technology. RPL is designed to be able to operate over a variety of different link layers, including but not limited to, low power wireless or PLC (Power Line Communication) technologies. Implementers may find [RFC3819] a useful reference when designing a link layer interface between RPL and a particular link layer technology. --001485f197c428ef11048b908280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Should we mention here that L1/2 performance charact= eristics primitives are expected to be passed to RPL for its metrics calculations? <= /p>

=A0

Thanks,

Yoav

=A0

=A0

1.2.=A0 Expectations of Link Layer Type

=A0

=A0=A0 In compliance with the layered architecture of IP, RPL does not rely=

=A0=A0 on any particular features of a specific link layer technology.=A0 RPL<= /p>

=A0=A0 is designed to be able to operate over a variety of different link

=A0=A0 layers, including but not limited to, low power wireless or PLC

=A0=A0 (Power Line Communication) technologies.

=A0

=A0=A0 Implementers may find [RFC3819] a useful reference when designing a<= /p>

=A0=A0 link layer interface between RPL and a particular link layer

=A0=A0 technology.

=A0

=A0

--001485f197c428ef11048b908280-- From jpv@cisco.com Sat Jul 17 14:35:32 2010 Return-Path: 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 77E593A6A13 for ; Sat, 17 Jul 2010 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 LEcxu-lHsr66 for ; Sat, 17 Jul 2010 14:35:27 -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 915B03A69DC for ; Sat, 17 Jul 2010 14:32:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPO9QUxAZnwN/2dsb2JhbACBRJ4ucaRnmgSFJQSIV4I0 X-IronPort-AV: E=Sophos;i="4.55,220,1278288000"; d="scan'208,217";a="133706761" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2010 21:32:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6HLWvbu025953; Sat, 17 Jul 2010 21:32:57 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 23:32:56 +0200 Received: from [192.168.3.50] ([10.61.111.95]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Jul 2010 23:32:56 +0200 Message-Id: <088DD23B-3063-4FE0-B8B3-EBBA116F8B27@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-170-447462848 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Jul 2010 23:32:53 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Jul 2010 21:32:56.0351 (UTC) FILETIME=[9EEA82F0:01CB25F7] Cc: ROLL WG Subject: Re: [Roll] question about section 1.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: , X-List-Received-Date: Sat, 17 Jul 2010 21:35:32 -0000 --Apple-Mail-170-447462848 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Yoav, On Jul 17, 2010, at 9:44 AM, Yoav Ben-Yehezkel wrote: > Hi, > > Should we mention here that L1/2 performance characteristics > primitives are expected to be passed to RPL for its metrics > calculations? This is en implementation issue. If other SDO defines such API and use a RPL routing metric specified here, then great. But we do not to mention it in this document. Thanks. JP. > > Thanks, > Yoav > > > 1.2. Expectations of Link Layer Type > > In compliance with the layered architecture of IP, RPL does not > rely > on any particular features of a specific link layer technology. > RPL > is designed to be able to operate over a variety of different link > layers, including but not limited to, low power wireless or PLC > (Power Line Communication) technologies. > > Implementers may find [RFC3819] a useful reference when designing a > link layer interface between RPL and a particular link layer > technology. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-170-447462848 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Yoav,

On = Jul 17, 2010, at 9:44 AM, Yoav Ben-Yehezkel wrote:

Hi,

Should we mention here that L1/2 performance = characteristics primitives are expected to be passed to RPL for its = metrics = calculations?


Thi= s is en implementation issue. If other SDO defines such API and use a = RPL routing metric specified here, then great.
But we do not = to mention it in this = document.

Thanks.

JP.

 

Yoav

 

 

   In compliance with the = layered architecture of IP, RPL does not rely
   is designed to be able = to operate over a variety of different link
   (Power Line Communication) = technologies.

   Implementers may find [RFC3819] a useful = reference when designing a

   link layer interface = between RPL and a particular link layer
Roll@ietf.org
Requires clarification on what you mean by "compare" MG> Some times, the Metric Containers will be easy to compare. E.g. if the good enough criteria (specified as a constraint) is that ETX must be less than 10, the Metric Container will contain two objects: one constraint (ETX must be less than 10) and one aggregated value for the ETX so far. Here, comparing the Metric Container simply means comparing the aggregated ETX values. In case of Metric Containers carrying multiple metrics, comparison will not be possible. I will make this clear in the text. From prvs=8086b4eb1=mukul@uwm.edu Sun Jul 18 00:55:45 2010 Return-Path: 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 B499A3A6A58 for ; Sun, 18 Jul 2010 00:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 RQGPK4ouY5wz for ; Sun, 18 Jul 2010 00:55:44 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B43F53A69A6 for ; Sun, 18 Jul 2010 00:55:44 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 18 Jul 2010 02:55:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 48AA12B3F02; Sun, 18 Jul 2010 02:55:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EUjNfdjOWdX; Sun, 18 Jul 2010 02:55:39 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 270C72B3EF6; Sun, 18 Jul 2010 02:55:39 -0500 (CDT) Date: Sun, 18 Jul 2010 02:55:51 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <178964210.77231.1279439751092.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1342444145.77221.1279439469665.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] P2P hop-by-hop routes 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: , X-List-Received-Date: Sun, 18 Jul 2010 07:55:45 -0000 Hi, Coming back to this issue since I need to add text to the P2P draft in this regard. > Now when router A receives a packet marked with RPLInstanceID 'i' and > going to destination P, which state should it use to forward the > packet further? [Richard]It uses the D flag in the hop-by-hop header to determine if the source or destination address is the DODAGID, and looks up the DODAGID+RPLInstanceID in the hop-by-hop states. There is nothing defined inside the RPL option (hui-6man-rpl-option) so far. I guess a future version of this draft or RPL draft will add the sub-TLVs for RPlInstanceID and the D flag Richard mentioned? Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Monday, June 21, 2010 3:41:10 PM Subject: Re: [Roll] P2P hop-by-hop routes > Date: Mon, 21 Jun 2010 14:43:37 -0500 (CDT) > From: Mukul Goyal > > Here is the problem I was referring to: > > Suppose that: > > 1) routers X and Y both discover hop-by-hop routes to the same target > router P but with different metrics/constraints; > > 2) both route discoveries end up using temporary DAGs with same > RPLInstanceID 'i'; Then 'i' must be a "local" RPLInstanceID (because they are both using the same one). In that case, the DAGs are identified by the combination of the RPLInstanceID and the DODAGID, which here would be the IPv6 address of the origin router. > 3) an intermediate router A is part of both hop-by-hop routes and > hence establishes two separate hop-by-hop states. Those hop-by-hop states would need to include the RPLInstanceIDs and DODAGIDs of the DAGs used to create the routes. A "local" RPLInstanceID is not sufficient on its own. > Now when router A receives a packet marked with RPLInstanceID 'i' and > going to destination P, which state should it use to forward the > packet further? It uses the D flag in the hop-by-hop header to determine if the source or destination address is the DODAGID, and looks up the DODAGID+RPLInstanceID in the hop-by-hop states. -Richard Kelsey From mcr@sandelman.ca Sun Jul 18 06:41:10 2010 Return-Path: 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 B28EB3A68C0 for ; Sun, 18 Jul 2010 06:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 v32w4l6kx1zP for ; Sun, 18 Jul 2010 06:41:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 993113A67F8 for ; Sun, 18 Jul 2010 06:41:06 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.72.127.78]) by relay.sandelman.ca (Postfix) with ESMTPS id 3FEA43477B for ; Sun, 18 Jul 2010 09:41:16 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 04B6B989DA for ; Sat, 17 Jul 2010 20:38:29 -0400 (EDT) From: Michael Richardson To: ROLL WG In-Reply-To: References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sat, 17 Jul 2010 20:38:28 -0400 Message-ID: <12834.1279413508@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] The word Up! 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: , X-List-Received-Date: Sun, 18 Jul 2010 13:41:10 -0000 {my appologies for time warp email, I'm cleaning out my RPL unread folder...} >>>>> "Philip" == Philip Levis writes: >>> I suggest that we might want to come up with a different term >>> than "move" to describe topology changes. >> Makes sense. >> >> If you change >> >> Root / \ A B / C >> >> By C--A--Root--B, now things move left <-> right, no more up and >> down. >> >> I believe the whole movement concept is confusing. Philip> What terminology do you think would be better? Philip> The notion of up/down and shallower/deeper are basic Philip> terminology in tree data structures and algorithms. E.g., Philip> depth first search. The issue I have is that the nodes usually do not move in physical space. There are situations where they *do*, and it's important to distinguish this. Philip> "Move" could be "change its position within the DODAG?" I suggest that we a term like "reattach" or something like that. Or some other synonym for move. What was it called in M.A.S.H. when they had to invoke the "Mobile" part of the name? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jpv@cisco.com Sun Jul 18 08:41:03 2010 Return-Path: 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 07B5D3A681A for ; Sun, 18 Jul 2010 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 XJiil8--O3OA for ; Sun, 18 Jul 2010 08:41:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B0A263A67EF for ; Sun, 18 Jul 2010 08:41:01 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKa9QkyrR7Hu/2dsb2JhbACfb3GkMYxijH2FJQSIV4I0 X-IronPort-AV: E=Sophos;i="4.55,223,1278288000"; d="scan'208";a="227987571" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Jul 2010 15:41:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6IFfEb4022863; Sun, 18 Jul 2010 15:41:14 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 17:41:13 +0200 Received: from [192.168.3.50] ([10.55.89.37]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 17:41:13 +0200 Message-Id: <0032665A-A00C-48C2-8642-EFFD9E4B9573@cisco.com> From: JP Vasseur To: Michael Richardson In-Reply-To: <12834.1279413508@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Jul 2010 17:41:11 +0200 References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> <12834.1279413508@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Jul 2010 15:41:13.0422 (UTC) FILETIME=[A700D6E0:01CB268F] Cc: ROLL WG Subject: Re: [Roll] The word Up! 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: , X-List-Received-Date: Sun, 18 Jul 2010 15:41:03 -0000 On Jul 18, 2010, at 2:38 AM, Michael Richardson wrote: > > {my appologies for time warp email, I'm cleaning out my RPL unread > folder...} > >>>>>> "Philip" == Philip Levis writes: >>>> I suggest that we might want to come up with a different term >>>> than "move" to describe topology changes. >>> Makes sense. >>> >>> If you change >>> >>> Root / \ A B / C >>> >>> By C--A--Root--B, now things move left <-> right, no more up and >>> down. >>> >>> I believe the whole movement concept is confusing. > > Philip> What terminology do you think would be better? > > Philip> The notion of up/down and shallower/deeper are basic > Philip> terminology in tree data structures and algorithms. E.g., > Philip> depth first search. > > The issue I have is that the nodes usually do not move in physical > space. > There are situations where they *do*, and it's important to > distinguish > this. Not sure I could change the "move" terminology though ... it used widely used in the document and lots of emails. Not a strong opinion, just a 0.2 cent feed-back. > > Philip> "Move" could be "change its position within the DODAG?" > > I suggest that we a term like "reattach" or something like that. > Or some other synonym for move. What was it called in M.A.S.H. when > they had to invoke the "Mobile" part of the name? > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Mon Jul 19 00:35:35 2010 Return-Path: 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 D432C3A6767 for ; Mon, 19 Jul 2010 00:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5hPD1VkgXk8X for ; Mon, 19 Jul 2010 00:35:30 -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 996423A6403 for ; Mon, 19 Jul 2010 00:35:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="p7s'?scan'208,217";a="134033963" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2010 07:35:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6J7ZU6j018457; Mon, 19 Jul 2010 07:35:43 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 09:35:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jul 2010 09:35:40 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0B6E_01CB2725.C0459550" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarifications on Section 16 "Manageability considerations" Thread-Index: Acsk13zL9jao5sUeQwGW98WkIlsZ9ACPGd+A References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 19 Jul 2010 07:35:42.0304 (UTC) FILETIME=[FDEABE00:01CB2714] Cc: roll@ietf.org Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Mon, 19 Jul 2010 07:35:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B6E_01CB2725.C0459550 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0B6F_01CB2725.C0459550" ------=_NextPart_001_0B6F_01CB2725.C0459550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi JP, Thanks for updating Section 16. A few minor points below. Best, Mathilde - In 16.2.3, 16.2.4 It is not very clear which parameters are configured versus negotiated dynamically through messages. All the parameters are the ones that a RPL MAY/SHOULD/MUST allow for configuration only. I will add some text to clarify. [Mathilde] I'm not sure what you mean by 'configuration only'. Do you mean not negotiated dynamically? Then it seems to me that parameters that are part of the policy must be configured while other may be. For some parameters (OCP, Route information, DODAGID, MOP) it is still not specified in which category (may, should, must) they belong - In 16.2.4 "A RPL implementation SHOULD allow configuring whether a non-storing node provides the transit information in DAO messages." Shouldn't a node always include the transit info in DAO messages? Correct, what I meant was the requirement to configure the MOP (this was already in 16.2.5), which implies to send transit information for non storing mode, but this was not clear indeed. I removed it from there. By the way, I added the Route information and Prefix information that were missing. [Mathilde] Shouldn't Route information and Prefix information be in 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a problem :-) ). I would also add some text on what it means to configure the target prefix. This is not very clear to me. Do you mean decide which of the node's addresses / prefixes should be in a target option? Aren't the 2 first bullet related to the DAO mechanism and hence more appropriate in Section 16.2.6 (or maybe we should just remove Section 16.2.6) Yes I updated 16.2.6, which was outdated after we removed the DAO FSM. Thanks. [Mathilde] Thanks. Maybe 16.2.4 Target option should also go there - In general, Sections 16.3 to 16.5 can be difficult to implement on constrained nodes without interface or file system. I would emphasize that it is expected that constrained nodes do not implement these parts. Not sure is you saw it, but there is already pretty explicit text in Section 16.1: When memory is highly constrained, it may not be possible to satisfy all the requirements listed in this section. [Mathilde] Well the 'may' is a bit weak in my opinion. But I'm OK to keep it as is. Attached the changes. Let me know if you agree with the proposed resolution and I'll close the ticket. [Mathilde] I think once we implement the minor changes above we can close the ticket. ------=_NextPart_001_0B6F_01CB2725.C0459550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

Thanks for updating Section 16. A few minor points = below.

Best,

Mathilde

 

=

 

- In 16.2.3, 16.2.4 It is not very clear which parameters = are configured versus negotiated dynamically through messages.

All the parameters are the ones that a RPL = MAY/SHOULD/MUST allow for configuration only. I will add some text to = clarify.

[Mathilde] I'm not sure = what you mean by 'configuration only'. Do you mean not negotiated dynamically? = Then it seems to me that parameters that are part of the policy must be = configured while other may be. For some parameters (OCP, Route information, = DODAGID, MOP) it is still not specified in which category (may, should, must) they = belong

- In 16.2.4 “A RPL implementation SHOULD allow = configuring whether a non-storing node provides the transit information in DAO messages.” Shouldn’t a node always include the transit info = in DAO messages?

Correct, what I meant was the requirement to = configure the MOP (this was already in 16.2.5), which implies to send transit = information for non storing mode, but this was not clear indeed. I removed it from = there. By the way, I added the Route information and Prefix information that were missing.

[Mathilde] Shouldn't Route information and Prefix = information be in 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a = problem :-) ).  I would also add some text on what it means to configure the = target prefix. This is not very clear to me. Do you mean decide which of the = node's addresses / prefixes should be in a target option?

Aren’t the 2 first bullet related to the DAO = mechanism and hence more appropriate in Section 16.2.6 (or maybe we should just remove Section 16.2.6)

Yes I updated 16.2.6, which was outdated after we = removed the DAO FSM. Thanks.

[Mathilde] Thanks. Maybe = 16.2.4 Target option should also go there

- In general, Sections 16.3 to 16.5 can be difficult to = implement on constrained nodes without interface or file system. I would emphasize = that it is expected that constrained nodes do not implement these = parts.

 

Not sure is you saw it, but there is already pretty = explicit text in Section 16.1:

   When memory is =
highly constrained, it may
   not be =
possible to satisfy all the requirements listed in =
this
   section.  =

[M=
athilde] Well the ‘may’ is a bit weak in my opinion. But I'm =
OK to keep it as is.
 

Attached the changes. Let me know if you agree with = the proposed resolution and I'll close the ticket.

[Mathilde] I think once we implement the minor changes above = we can close the ticket.

------=_NextPart_001_0B6F_01CB2725.C0459550-- ------=_NextPart_000_0B6E_01CB2725.C0459550 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxOTA3MzU0MFowIwYJKoZIhvcNAQkEMRYEFIPPLw3o8Y+X4b/P rz/TN4tZ5OtMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAHCeECi0llyLfTUQW0F7OKAmQntqq980i Qh3vvJlQ6mvblbf7E/b93DIMgxWdzpMrJa91z3V/G7cElTaYI7hsFYVXRa8Kw2Gal0LGCxGpqyrH a5XCXatU0WTa6NRuccYv2TiqXBmrN3ZvW9tm7FWtGycsHH/fA/LWkeclM++Y2eYAAAAAAAA= ------=_NextPart_000_0B6E_01CB2725.C0459550-- From mdurvy@cisco.com Mon Jul 19 00:57:05 2010 Return-Path: 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 7851C3A6846 for ; Mon, 19 Jul 2010 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 nQwp8krgQ-Dx for ; Mon, 19 Jul 2010 00:57:03 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CCD103A67A4 for ; Mon, 19 Jul 2010 00:57:03 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALOhQ0yrR7H+/2dsb2JhbACBRIFcnExxpGCJNJBXhDJzBIsL X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="p7s'?scan'208,217";a="231040421" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2010 07:57:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6J7v20x000663 for ; Mon, 19 Jul 2010 07:57:17 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 09:57:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jul 2010 09:57:02 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0B7E_01CB2728.BC911170" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0D5@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574ADA@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Use of tunnels and end point determication Thread-Index: AcsfTYIna0PNlK9dRxq1EOLrDU+ybwAG+67AAAQubjABIXlUQAA+CdlAAIdJBiA= References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E8D4@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D02574ADA@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "ROLL WG" X-OriginalArrivalTime: 19 Jul 2010 07:57:04.0614 (UTC) FILETIME=[FA3BB860:01CB2717] Subject: Re: [Roll] Use of tunnels and end point determication 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: , X-List-Received-Date: Mon, 19 Jul 2010 07:57:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B7E_01CB2728.BC911170 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0B7F_01CB2728.BC911170" ------=_NextPart_001_0B7F_01CB2728.BC911170 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Pascal, This looks good! It seems we are in agreement. Some comments below. Best, Mathilde =20 =20 From: Mathilde Durvy (mdurvy)=20 Sent: Thursday, July 15, 2010 1:31 PM To: Pascal Thubert (pthubert); 'ROLL WG' Subject: RE: [Roll] Use of tunnels and end point determication =20 Hi Pascal, All, =20 Let me know if this is a correct summary of the possible cases. I also = put some comments to point things where I think a clarification is = needed. =20 1) RPL S =C3=A0 BR =C3=A0 D No tunnel, the RPL = source adds the HbH header, BR removes it [Pascal] Surprised me quite a bit but correct. This amends my earlier = mail of mine where I thought we had to tunnel there. My sentence = =E2=80=9CRPL cannot use transport mode to an external destination = because of the use of the hop by hop option=E2=80=9D was apparently = wrong, and we can lawfully remove the hop by hop inside the packet. =20 2) S =C3=A0 RPL R =C3=A0 BR =C3=A0 D Tunnel. R introduces new = IPv6 header with HbH header, R is the IPv6 source, BR the IPv6 dest. BR = removes this header.=20 Comment: If BR is the end of the tunnel, its address needs to be known = by R. How does that work? This would favor an approach where the DODAGID = must be the global IPv6 address of the root [Pascal] Correct, though we do not really well support a host attached = to the RPL network. In particular the lack of DAO sequence etc=E2=80=A6=20 Make sense to me for all nodes to be leaves. [Mathilde] Just one point how are we planning to distribute the address = of the root to all RPL routers? =20 =20 3) RPL D =C3=9F BR =C3=9F S Tunnel. BR introduces = new IPv6 header with HbH header and RH (non-storing mode only), BR is = the IPv6 source, and RPL D the final dest in the RH.=20 [Pascal] Correct =20 4) D =C3=9F RPL R =C3=9F BR =C3=9F S Tunnel. BR introduces = new IPv6 header with HbH header and RH (non-storing mode only), BR is = the IPv6 source, and RPL R the final dest in the RH. R decapsulates and = sends to D. [Pascal] correct Comment: This would work if R sends DAO with target D and transit = =E2=80=9Cthe parent of R=E2=80=9D: I think this is a bit different than = your approach in 5b. Also, I have the impression that according to = =E2=80=9CThe last entry, Address[n], is exempt from the strict source = route policy and may specify a destination outside the RPL = domain=E2=80=9D, D address could be the last address in the RH but = I=E2=80=99m not sure how this would work. If this text does not apply to = tunnel mode as you point below, we should say so. [Pascal] Hum=E2=80=A6 =E2=80=9Cthe parent of R=E2=80=9D would look up D = onlink and would not find it. R needs to set itself as transit parent = and D as target. For a RPL router or leaf, and to enable a better = compression we let the tunnel end at the target but for a non RPL host = that cannot be. So we need R to flag in the DAO that R is the tunnel = endpoint for D as opposed to D itself. You=E2=80=99ll note that for each = of R=E2=80=99s addresses that are not onlink for =E2=80=9Cthe parent of = R=E2=80=9D, R has to advertise self as parent, using in the transit an = address that is onlink to its own parent. [Mathilde] Agree. So what do we do with the sentence quoted above? It is = kind of confusing. =20 =20 5) S =C3=A0 RPL R1 =C3=A0 BR =C3=A0 RPL R2 =C3=A0 D = Tunnel. R1 introduces new IPv6 header with HbH header, R1 is the IPv6 = source,=20 BR the IPv6 dest. BR removes this header. Encapsulates with new IPv6 = header with HbH header and RH (non-storing mode only), BR is the IPv6 = source, and RPL R2 the final dest in the RH.=20 Comment: I guess this vision contradicts your point 5a. Seems simpler to = me, but maybe I=E2=80=99m missing something. =20 [Pascal] I hope we are not in contradiction : ) This is correct in non = storing. In storing, the packet doesn=E2=80=99t need to go to the root = and even if it does, the root is just another common parent and forwards = down. There is no decap reencap in that case. But to determine that you = can bypass the root, you have to figure that the destination is a leaf = or a router of the same RPL network, which is not obvious. If we do not = have plain hosts but just RPL routers and leaves in a same subnet, then = it is a lot easier.=20 [Mathilde] Agree =20 Note that if the above is correct, the only information needed by RPL = nodes is the global address of the BR (i.e. the root). So it seems that = 2 below might not be needed [Pascal] If we do the above for storing, we lose the advantage of = routing via the common parent=E2=80=A6 [Mathilde] Agree ------=_NextPart_001_0B7F_01CB2728.BC911170 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

This looks good! It seems we are in agreement.

Some comments = below.

Best,

Mathilde

 

 

From:= Mathilde = Durvy (mdurvy)
Sent: Thursday, July 15, 2010 1:31 PM
To: Pascal Thubert (pthubert); 'ROLL WG'
Subject: RE: [Roll] Use of tunnels and end point = determication

 

Hi Pascal, All,

 

Let me know if this is a correct summary of the possible cases. I also put = some comments to point things where I think a clarification is = needed.

 

1)    = RPL S =  =C3=A0 BR =C3=A0 = D                 No = tunnel, the RPL source adds the HbH header, BR removes it

[Pascal] = Surprised me quite a bit but correct. This amends my earlier mail of mine where I = thought we had to tunnel there. My sentence =E2=80=9CRPL cannot use transport mode = to an external destination because of the use of the hop by hop option=E2=80=9D was = apparently wrong, and we can lawfully remove the hop by hop inside the = packet.

 

2)    = S =C3=A0 RPL R =C3=A0 BR =C3=A0 D         Tunnel. R introduces new IPv6 header with HbH header, R is the IPv6 source, BR the = IPv6 dest. BR removes this header.

Comment: If BR is the end of the tunnel, its address needs = to be known by R. How does that work? This would favor an approach where the = DODAGID must be the global IPv6 address of the root

[Pascal] Correct, though we do not really well support a host = attached to the RPL network. In particular the lack of DAO sequence etc=E2=80=A6 =

Make sense to me for all nodes to be = leaves.

[Mathilde] Just one point how are we planning to distribute the address of the root = to all RPL routers?

 

 

3)    = RPL D =C3=9F BR =C3=9F S             &= nbsp;    Tunnel. BR introduces new IPv6 header with HbH header and RH = (non-storing mode only), BR is the IPv6 source, and RPL D the final dest in the RH. =

[Pascal] = Correct

 

4)    = D =C3=9F RPL R =C3=9F BR =C3=9F S         Tunnel. BR = introduces new IPv6 header with HbH header and RH (non-storing mode only), BR is = the IPv6 source, and RPL R the final dest in the RH. R decapsulates and sends to = D.

[Pascal] = correct

Comment: This would work if R sends DAO with target D and = transit =E2=80=9Cthe parent of R=E2=80=9D: I think this is a bit different than = your approach in 5b. Also, I have the impression that according to =E2=80=9CThe last entry, = Address[n], is exempt from the strict source route policy and may specify a destination = outside the RPL domain=E2=80=9D, D address could be the last address in the RH = but I=E2=80=99m not sure how this would work. If this text does not apply to tunnel mode as you = point below, we should say so.

[Pascal] = Hum=E2=80=A6  =E2=80=9Cthe parent of R=E2=80=9D would look up D onlink and would not find it. R = needs to set itself as transit parent and D as target. For a RPL router or leaf, and = to enable a better compression we let the tunnel end at the target but for = a non RPL host that cannot be. So we need R to flag in the DAO that R is the = tunnel endpoint for D as opposed to D itself. You=E2=80=99ll note that for each of = R=E2=80=99s addresses that are not onlink for =E2=80=9Cthe parent of R=E2=80=9D, R has to advertise = self as parent, using in the transit an address that is onlink to its own = parent.

[Mathilde] Agree. So what do we do with the sentence quoted above? It is kind of confusing.

 

 

5)    = S =C3=A0 RPL R1 =C3=A0 BR =C3=A0 RPL R2 =C3=A0 D =             Tunnel. R1 introduces new IPv6 header with HbH header, R1 is the IPv6 = source,

BR the IPv6 dest. BR removes this header. Encapsulates with = new IPv6 header with HbH header and RH (non-storing mode only), BR is the = IPv6 source, and RPL R2 the final dest in the RH.

Comment: I guess this vision contradicts your point 5a. = Seems simpler to me, but maybe I=E2=80=99m missing = something.

 

[Pascal] I hope = we are not in contradiction : ) This is correct in non storing. In storing, the = packet doesn=E2=80=99t need to go to the root and even if it does, the root is = just another common parent and forwards down. There is no decap reencap in that case. = But to determine that you can bypass the root, you have to figure that the = destination is a leaf or a router of the same RPL network, which is not obvious. If = we do not have plain hosts but just RPL routers and leaves in a same subnet, = then it is a lot easier.

[Mathilde] Agree

 

Note that if the above is correct, the only information needed by RPL nodes = is the global address of the BR (i.e. the root). So it seems that 2 below might = not be needed

[Pascal] If we = do the above for storing, we lose the advantage of routing via the common = parent=E2=80=A6

[Mathilde] Agree

------=_NextPart_001_0B7F_01CB2728.BC911170-- ------=_NextPart_000_0B7E_01CB2728.BC911170 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcxOTA3NTcwMlowIwYJKoZIhvcNAQkEMRYEFMgBke/1LEoPm2Bk 2dg023+ODUGuMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAEmhFwnfSmDeImsXJ8E/+PxUicQO8U168 hOJqrEOl6LDmiPgiUsCwoghcVMbKMeKU6kR4BJOu7oN0NVXC3032LNSE7lx9zxadl7f2EXn0Y53F yPB4vK/+wV6Sph3c7FhEo5S3LBiFEQGNkFUh4THeCo/JZ1otyMm1G3SecdExL8cAAAAAAAA= ------=_NextPart_000_0B7E_01CB2728.BC911170-- From daniel.gavelle@jennic.com Mon Jul 19 01:25:55 2010 Return-Path: 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 69D063A6855 for ; Mon, 19 Jul 2010 01:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 esK9KxqrCOhB for ; Mon, 19 Jul 2010 01:25:53 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 193903A6846 for ; Mon, 19 Jul 2010 01:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 966989BE50C; Mon, 19 Jul 2010 09:26:06 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o61QExye6GVV; Mon, 19 Jul 2010 09:26:06 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 781369BE508; Mon, 19 Jul 2010 09:26:06 +0100 (BST) Message-ID: <4C440C1E.2050901@jennic.com> Date: Mon, 19 Jul 2010 09:26:06 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Mathilde Durvy (mdurvy)" References: <6A2A459175DABE4BB11DE2026AA50A5D024CD300@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0279C0F5@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D024CD489@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E8D4@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D02574ADA@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0D5@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0D5@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Use of tunnels and end point determication X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 08:25:55 -0000 Mathilde / Pascal, The summary below is good and needs to be added to one of the RPL drafts. I have a few remaining questions:- What happens in the case BR -> RPL when non storing? Do we just have HbH and RH or is tunnelling required. Is the HbH mandatory when going from the BR->RPL when non storing? The RH is all that is required to reach a destination and the packet arriving from a parent confirms the path from the parent is still available. Has it been agreed that we use HbH rather than the flow label in all circumstances? The case (2) below is likely to be required by Zigbee hosts that support ND but not RPL. Ensuring the DODAG ID is the address of the root solves this problem and also allows DAO's to be sent directly to the root in a non storing network. Daniel. Mathilde Durvy (mdurvy) wrote: > Hi Pascal, > > This looks good! It seems we are in agreement. > > Some comments below. > > Best, > > Mathilde > > > > > > *From:* Mathilde Durvy (mdurvy) > *Sent:* Thursday, July 15, 2010 1:31 PM > *To:* Pascal Thubert (pthubert); 'ROLL WG' > *Subject:* RE: [Roll] Use of tunnels and end point determication > > > > Hi Pascal, All, > > > > Let me know if this is a correct summary of the possible cases. I also > put some comments to point things where I think a clarification is needed. > > > > 1) RPL S à BR à D No tunnel, the RPL source adds the > HbH header, BR removes it > > */[Pascal] Surprised me quite a bit but correct. This amends my earlier > mail of mine where I thought we had to tunnel there. My sentence “RPL > cannot use transport mode to an external destination because of the use > of the hop by hop option†was apparently wrong, and we can lawfully > remove the hop by hop inside the packet./* > > > > 2) S à RPL R à BR à D Tunnel. R introduces new IPv6 header > with HbH header, R is the IPv6 source, BR the IPv6 dest. BR removes this > header. > > Comment: If BR is the end of the tunnel, its address needs to be known > by R. How does that work? This would favor an approach where the DODAGID > must be the global IPv6 address of the root > > */[Pascal] Correct, though we do not really well support a host attached > to the RPL network. In particular the lack of DAO sequence etc… /* > > */Make sense to me for all nodes to be leaves./* > > [Mathilde] Just one point how are we planning to distribute the address > of the root to all RPL routers? > > > > > > 3) RPL D ß BR ß S Tunnel. BR introduces new IPv6 > header with HbH header and RH (non-storing mode only), BR is the IPv6 > source, and RPL D the final dest in the RH. > > */[Pascal] Correct/* > > > > 4) D ß RPL R ß BR ß S Tunnel. BR introduces new IPv6 header > with HbH header and RH (non-storing mode only), BR is the IPv6 source, > and RPL R the final dest in the RH. R decapsulates and sends to D. > > */[Pascal] correct/* > > Comment: This would work if R sends DAO with target D and transit “the > parent of Râ€: I think this is a bit different than your approach in 5b. > Also, I have the impression that according to “The last entry, > Address[n], is exempt from the strict source route policy and may > specify a destination outside the RPL domainâ€, D address could be the > last address in the RH but I’m not sure how this would work. If this > text does not apply to tunnel mode as you point below, we should say so. > > */[Pascal] Hum… “the parent of R†would look up D onlink and would not > find it. R needs to set itself as transit parent and D as target. For a > RPL router or leaf, and to enable a better compression we let the tunnel > end at the target but for a non RPL host that cannot be. So we need R to > flag in the DAO that R is the tunnel endpoint for D as opposed to D > itself. You’ll note that for each of R’s addresses that are not onlink > for “the parent of Râ€, R has to advertise self as parent, using in the > transit an address that is onlink to its own parent./* > > [Mathilde] Agree. So what do we do with the sentence quoted above? It is > kind of confusing. > > > > > > 5) S à RPL R1 à BR à RPL R2 à D Tunnel. R1 introduces new > IPv6 header with HbH header, R1 is the IPv6 source, > > BR the IPv6 dest. BR removes this header. Encapsulates with new IPv6 > header with HbH header and RH (non-storing mode only), BR is the IPv6 > source, and RPL R2 the final dest in the RH. > > Comment: I guess this vision contradicts your point 5a. Seems simpler to > me, but maybe I’m missing something. > > > > */[Pascal] I hope we are not in contradiction : ) This is correct in non > storing. In storing, the packet doesn’t need to go to the root and even > if it does, the root is just another common parent and forwards down. > There is no decap reencap in that case. But to determine that you can > bypass the root, you have to figure that the destination is a leaf or a > router of the same RPL network, which is not obvious. If we do not have > plain hosts but just RPL routers and leaves in a same subnet, then it is > a lot easier. /* > > [Mathilde] Agree > > > > Note that if the above is correct, the only information needed by RPL > nodes is the global address of the BR (i.e. the root). So it seems that > 2 below might not be needed > > */[Pascal] If we do the above for storing, we lose the advantage of > routing via the common parent…/* > > [Mathilde] Agree > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- __________________________________________________ Daniel Gavelle, Software Engineer Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 Registered In England http://www.jennic.com __________________________________________________ From trac@tools.ietf.org Mon Jul 19 03:48:22 2010 Return-Path: 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 724B83A69E3 for ; Mon, 19 Jul 2010 03:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 rPOH7pEQOq+K for ; Mon, 19 Jul 2010 03:48:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 997F33A68F1 for ; Mon, 19 Jul 2010 03:48:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oantj-00079x-JS; Mon, 19 Jul 2010 03:48:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 19 Jul 2010 10:48:35 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/70#comment:1 Message-ID: <064.bfacf08ad569ee7cdb705a0e927d86bb@tools.ietf.org> References: <055.d823261b419b55d9dd0dde82abf7f82f@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <055.d823261b419b55d9dd0dde82abf7f82f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #70: List of detailed comments during RPL LC (was: Comments during RPL LC) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 10:48:22 -0000 #70: List of detailed comments during RPL LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- -- Ticket URL: roll From gnawali@cs.stanford.edu Mon Jul 19 07:04:56 2010 Return-Path: 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 C31913A67A5 for ; Mon, 19 Jul 2010 07:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ArJV5wW0YNQt for ; Mon, 19 Jul 2010 07:04:55 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C7DEC3A6B03 for ; Mon, 19 Jul 2010 07:04:55 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Oaqxx-0001jI-Kc for roll@ietf.org; Mon, 19 Jul 2010 07:05:10 -0700 Received: by iwn7 with SMTP id 7so4605625iwn.19 for ; Mon, 19 Jul 2010 07:05:09 -0700 (PDT) Received: by 10.231.170.79 with SMTP id c15mr5511275ibz.82.1279548308943; Mon, 19 Jul 2010 07:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.144.199 with HTTP; Mon, 19 Jul 2010 07:04:47 -0700 (PDT) In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF016C115B@ftrdmel0.rd.francetelecom.fr> References: <8E09C72DBC577D489F13A71228C0B7BF016C115B@ftrdmel0.rd.francetelecom.fr> From: Omprakash Gnawali Date: Mon, 19 Jul 2010 07:04:47 -0700 Message-ID: To: dominique.barthel@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Cc: roll@ietf.org Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08 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: , X-List-Received-Date: Mon, 19 Jul 2010 14:04:56 -0000 The ordering results in something other than OF deciding how to compute paths. As a result, in some cases OFs will perform path selection, and in some other cases, metric ordering will. This could be confusing. - om_p On Tue, Jul 13, 2010 at 6:38 AM, wr= ote: > Hello Omprakash, > > Thanks for your time reading the draft and commenting. > > Yes, the semantic behind ordering is intentional. Some priority mechanism= was needed and we proposed to use order of appearance in the packet as the= semantic. We welcome comments on that use, especially if this is improper = practice in the IP world. > > Regarding nodes making their own decisions on objective, that's a differe= nt issue. I don't see that a node by itself should have the right to prefer= one objective versus another one. It is my understanding that the RPL inst= ance dictates what the objective is, and the nodes that join that instance = have to adhere to it or become leaf nodes. Am I mistaken here? > > So far, to my knowledge, there is no case in the -08 draft, other than th= e ones listed in 8 and 3.2, where order matters. > We have strong langage with MUSTs in these paragraphs, the text "the orde= r is significant" you quote is just a forewarning early in the draft. > > Thanks again, and comments welcome from all. > Best, > > Dominique > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de O= mprakash Gnawali > Envoy=E9 : samedi 10 juillet 2010 01:17 > =C0 : ROLL WG > Objet : [Roll] metric ordering according todraft-ietf-roll-routing-metric= s-08 > > "8. > ... > =A0 When the DAG Metric Container contains several aggregated metrics, > =A0 they are to be used as tie-brakers in the order that they appear in > =A0 the DAG Metric Container. =A0A node propagating a DAG Metric Containe= r > =A0 MUST keep the order of metric objects unchanged. > > =A0 An example of such use of multiple aggregated metrics is the > =A0 following: Hop-Count as the primary criterion, LQL as the secondary > =A0 criterion and Fanout Ratio as the ultimate tie-braker. =A0In such a > =A0 case, the Hop-Count, LQL and Fanout Ratio metric objects need to > =A0 appear in that order in the DAG Metric Container. > > ..." > > Is the semantics behind the ordering intentional? > > A packet could be forwarded from a node that prefers to use one set of ob= jective to a node that prefers to use a different objective. For example, f= rom a low power energy scavenging sensor to a powered node. > Not allowing the nodes to change the order allows a node to dictate the r= elative importance of this metric to rest of the network without regard to = their preference. > > If we had already considered that scenario and determined to be not impor= tant, it might be worth making the last sentence in the following paragraph= stronger - are there other cases besides those mentioned in > 8 and 3.2? > > "2. > ... > =A0 Note that the Routing Metric/Constraint objects defined in this > =A0 document can appear in any order in the DAG Metric Container. > =A0 However, for some of them, the order is significant (as described in > =A0 Section 8 and Section 3.2, for example). > " > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Mon Jul 19 08:14:27 2010 Return-Path: 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 481F73A687E for ; Mon, 19 Jul 2010 08:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=0.836, 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 oPEBq-lnJqzh for ; Mon, 19 Jul 2010 08:14:26 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 765693A6944 for ; Mon, 19 Jul 2010 08:14:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6JFEcGP009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jul 2010 17:14:38 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6JFEcfD005612 for ; Mon, 19 Jul 2010 17:14:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6JFEcES027551 for ; Mon, 19 Jul 2010 17:14:38 +0200 Message-ID: <4C446BDE.2090808@gmail.com> Date: Mon, 19 Jul 2010 17:14:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: ROLL WG References: <20100715221338.C808F3A6A7D@core3.amsl.com> In-Reply-To: <20100715221338.C808F3A6A7D@core3.amsl.com> Content-Type: multipart/mixed; boundary="------------060904020301050304050305" Subject: Re: [Roll] IPR Disclosure: Rene Struik's Statement of IPR relating to draft-ietf-roll-rpl-10 and belonging to Certicom Corporation 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: , X-List-Received-Date: Mon, 19 Jul 2010 15:14:27 -0000 This is a multi-part message in MIME format. --------------060904020301050304050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hmmm... interesting to hear there is an IPR disclosure relating to the security aspects in draft-ietf-roll-rpl-10. Earlier this year (January) we discussed about potential IPR on the Security DT draft. At that time the view was absence of known IPR in that Security DT draft: http://tools.ietf.org/html/draft-tsao-roll-security-framework-02 What does the Security DT think about the IPR disclosure relating to security in the RPL draft? Is the security part of RPL coming from the Security DT text? When did this happen and in what manner? (I suppose the output of the Security DT is subject to WG accepting it... yet I don't hear anything about this acceptance.) Who are the members of the Security DT? Last time I heard was about the names in the attached message... is that list still final or has it evolved since? Alex Le 16/07/2010 00:13, IETF Secretariat a écrit : > Dear Pascal Thubert, Tim Winter, ROLL Team: > > An IPR disclosure that pertains to your Internet-Draft entitled "RPL: > IPv6 Routing Protocol for Low power and Lossy Networks" > (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on > 2010-07-12 and has been posted on the "IETF Page of Intellectual > Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1356/). The title of the IPR > disclosure is "Rene Struik's Statement of IPR relating to > draft-ietf-roll-rpl-10 and belonging to Certicom Corporation." > > The IETF Secretariat > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > --------------060904020301050304050305 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Received: from LAURIN.intra.cea.fr ([132.166.65.44]) by LODERI.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:27:12 +0100 Received: from levau.intra.cea.fr ([132.166.88.52]) by LAURIN.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:27:12 +0100 Received: from muguet1.intra.cea.fr ([132.166.192.6]) by levau.intra.cea.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:27:11 +0100 Received: from epeire3.extra.cea.fr (epeire3.extra.cea.fr [132.168.224.5]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-in-1.1) with ESMTP id o129RBFp017733 for ; Tue, 2 Feb 2010 10:27:11 +0100 Received: from oxalide.extra.cea.fr (oxalide.extra.cea.fr [132.168.224.2]) by epeire3.extra.cea.fr (8.14.2/8.14.2) with ESMTP id o129RB70019293 for ; Tue, 2 Feb 2010 10:27:11 +0100 (envelope-from alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com) Received: from relay2-v.mail.gandi.net (relay2-v.mail.gandi.net [217.70.178.76]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-in-3.0) with ESMTP id o129R5sF029999 for ; Tue, 2 Feb 2010 10:27:10 +0100 Received: from spool.mail.gandi.net (mspool2-v.mgt.gandi.net [10.0.21.72]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 94122135D7; Tue, 2 Feb 2010 10:27:05 +0100 (CET) Received: from mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) by spool.mail.gandi.net (Postfix) with ESMTP id 8138132C067; Tue, 2 Feb 2010 10:27:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter4-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.72]) by mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) (amavisd-new, port 10024) with ESMTP id qvGbj-J5IYr2; Tue, 2 Feb 2010 10:27:05 +0100 (CET) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by spool.mail.gandi.net (Postfix) with ESMTP id E831F32C09A for ; Tue, 2 Feb 2010 10:27:04 +0100 (CET) Received: by fxm10 with SMTP id 10so236298fxm.7 for ; Tue, 02 Feb 2010 01:27:04 -0800 (PST) Received: by 10.223.15.21 with SMTP id i21mr5910981faa.58.1265102824543; Tue, 02 Feb 2010 01:27:04 -0800 (PST) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.223.126.13 with SMTP id a13cs148423fas; Tue, 2 Feb 2010 01:27:03 -0800 (PST) Received: by 10.101.208.22 with SMTP id k22mr7124055anq.129.1265102822551; Tue, 02 Feb 2010 01:27:02 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 12si11032343iwn.86.2010.02.02.01.26.59; Tue, 02 Feb 2010 01:26:59 -0800 (PST) Received-SPF: pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=roll-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F36F28C22F; Tue, 2 Feb 2010 01:26:19 -0800 (PST) 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 02F8928C22B for ; Tue, 2 Feb 2010 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 H-J5I-Qv+-x7 for ; Tue, 2 Feb 2010 01:26:17 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1B07528C22A for ; Tue, 2 Feb 2010 01:26:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALJ+Z0utJV2a/2dsb2JhbAC/UpduhEUE X-IronPort-AV: E=Sophos;i="4.49,389,1262563200"; d="scan'208";a="294888573" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2010 09:26:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o129QrmR017727; Tue, 2 Feb 2010 09:26:53 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:47 +0100 Received: from dhcp-lyon-144-254-54-125.cisco.com ([144.254.54.125]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 10:26:47 +0100 Message-Id: From: JP Vasseur To: ROLL WG In-Reply-To: Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 2 Feb 2010 09:04:56 +0100 References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Feb 2010 09:26:47.0590 (UTC) FILETIME=[D7C06C60:01CAA3E9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17168.004 X-TM-AS-Result: No--26.799200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Adrian Farrel Subject: Re: [Roll] New Design Team to work on RPL Security 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 X-CEA-Source: externe X-CEA-Spam: 10% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description TO_IN_SUBJECT 0.500 To address is found in the subject line BODY_SIZE_3000_3999 0.000 Message body size is 3000 to 3999 bytes BODY_SIZE_5000_LESS 0.000 Message body size is less than 5000 bytes. BODY_SIZE_7000_LESS 0.000 Message body size is less than 5000 bytes. X-CEA-Spam-Hits: TO_IN_SUBJECT 0.5, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_XOAT 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MIME_VERSION_APPLEMAIL 0, __MSGID_APPLEMAIL 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NS , __USER_AGENT_APPLEMAIL 0, __X_FORWARDED_FOR_GMAIL 0, __X_MAILER_APPLEMAIL 0 Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Dear all, On Jan 26, 2010, at 12:22 AM, JP Vasseur wrote: > Dear all, > > This is to announce the formation of a new RPL Security Design Team, > made of the following members: > * Tzeta Tsao > * Roger Alexander > * Dave Ward > * Phil Levis > Kris Pister kindly accepted to help there. Thanks Kris. The final DT is thus: * Tzeta Tsao, * roger Alexander * Dave Ward * Phil Levis * Kris Pister Thanks. JP. > Thanks to the four of you for volunteering. > > Rene Struik will help the team as our security advisor. > > As a reminder: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission > * We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... > * All: please provide input to the Design Team and copy the mailing > list. > > Charter > ###### > > The charter of the security design team is to produce a Security > Framework document and the potential routing security extensions to > RPL in the context of that framework (or document how existing > routing mechanisms should be used). With regards to the framework, > the Security DT may choose to use http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt > as a starting point (the document has been presented and discussed > at the last two Working Group meetings). > > Please make sure to be aligned with the ROLL terminology document > and provide input to their authors should new terms be introduced. > > Milestones > ######### > > Milestones are pretty aggressive. > > Feb 10: produce a first draft of Security Framework to be submitted > to the WG for WG adoption > Feb 29: produce a first draft on the potential security extensions > for RPL as a separate document (that may be incorporated in the core > specification of RPL in a second step). > > The Design Team may not be dissolved after the completion of the > security work for RPL as security in routing within LLN may apply to > future specifications produced by the Working Group. > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP and David. > > On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: > >> Dear WG, >> >> I think that we can all be very happy with our progress so far with >> the core specification of RPL. There are still a few open issues >> that we need to solve before IETF-77: >> >> * Detailed DAO mechanisms >> * Detailed mode of operation with multicast >> * Use of Flow Label versus new IPv6 header >> * Potential needed optimization such as DAO packing >> * Editorial work >> * ... >> >> We are on track for all of these. >> >> The one item we absolutely need to speed on is security. As you >> know there is a security framework document that is still not a WG >> document and we now need to start the work on the RPL security >> aspects. To that end, we will form a small Design Team with >> aggressive milestones, the objective being to have the RPL security >> item almost completed by end of Feb, ready for the IETF-77. >> >> If you have a good understanding of RPL and routing security >> expertise, please go back to me (unicast). >> >> Thanks. >> >> JP. >> _______________________________________________ >> 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 --------------060904020301050304050305-- From alexandru.petrescu@gmail.com Mon Jul 19 08:19:48 2010 Return-Path: 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 3B70B3A68DF for ; Mon, 19 Jul 2010 08:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.669, 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 nVB+40p5Kuse for ; Mon, 19 Jul 2010 08:19:47 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 30E873A68D7 for ; Mon, 19 Jul 2010 08:19:47 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6JFJccg015933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jul 2010 17:19:39 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6JFJcqj006603; Mon, 19 Jul 2010 17:19:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6JFJck2009766; Mon, 19 Jul 2010 17:19:38 +0200 Message-ID: <4C446D0A.7060106@gmail.com> Date: Mon, 19 Jul 2010 17:19:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: JP Vasseur References: <4C1F3935.9050302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] The Design Teams in RoLL 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: , X-List-Received-Date: Mon, 19 Jul 2010 15:19:48 -0000 Le 23/06/2010 16:06, JP Vasseur a écrit : > Hi Alex, > > On Jun 21, 2010, at 12:04 PM, Alexandru Petrescu wrote: > >> Hello RoLL, >> >> I am trying to follow the RoLL group closely. What are the active >> DTs, their membership and respective charters, documents? >> >> Until now I know of: >> >> RPL DT Security DT >> > > You are correct. Only two official RPLL DT have been formed so far: > * RPL DT (now dissolved) RPL DT dissolved? Who edits the RPL document currently? I see a "RPL Author Team" in the topmost right header of the RPL draft but the Athors' Addresses do not say who the members of the Team are... and the Design Team is now dissolved. It's good to know who one talks to. Alex > * Security DT > > For each of them, I sent an email to the list with the list of > members, charters and milestones. > >> I think there may be more DTs (p2p, metrics?). I think some DTs >> were announced publicly on the mailing list, whereas some other >> DTs were not announced. It's difficult to understand what's >> happening. > > There is no other DTs, otherwise I would have announced them on the > list. > > Thanks. > > JP. > >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From prvs=809a70b48=mukul@uwm.edu Mon Jul 19 09:32:40 2010 Return-Path: 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 3A8C13A687C for ; Mon, 19 Jul 2010 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 VqfFaiXTSw5X for ; Mon, 19 Jul 2010 09:32:38 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 1AF163A6832 for ; Mon, 19 Jul 2010 09:32:37 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 19 Jul 2010 11:32:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 58B4E2B3F02; Mon, 19 Jul 2010 11:32:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1J2Ieu+BUmm; Mon, 19 Jul 2010 11:32:38 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EF7DB2B3F06; Mon, 19 Jul 2010 11:32:38 -0500 (CDT) Date: Mon, 19 Jul 2010 11:32:51 -0500 (CDT) From: Mukul Goyal To: Omprakash Gnawali Message-ID: <512948818.101310.1279557171804.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08 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: , X-List-Received-Date: Mon, 19 Jul 2010 16:32:40 -0000 I agree. I think that the metric container should simply be a set of metric= s/constraints objects. The order of appearance of these objects inside the = metric container should not have any inherent significance other than to id= entify the object. The objective function should assign any semantic signif= icance to the order of objects inside the metric container. Thanks Mukul=20 ----- Original Message ----- From: "Omprakash Gnawali" To: "dominique barthel" Cc: roll@ietf.org Sent: Monday, July 19, 2010 9:04:47 AM Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-met= rics-08 The ordering results in something other than OF deciding how to compute paths. As a result, in some cases OFs will perform path selection, and in some other cases, metric ordering will. This could be confusing. - om_p On Tue, Jul 13, 2010 at 6:38 AM, wrote: > Hello Omprakash, > > Thanks for your time reading the draft and commenting. > > Yes, the semantic behind ordering is intentional. Some priority > mechanism was needed and we proposed to use order of appearance in the > packet as the semantic. We welcome comments on that use, especially if > this is improper practice in the IP world. > > Regarding nodes making their own decisions on objective, that's a > different issue. I don't see that a node by itself should have the > right to prefer one objective versus another one. It is my > understanding that the RPL instance dictates what the objective is, > and the nodes that join that instance have to adhere to it or become > leaf nodes. Am I mistaken here? > > So far, to my knowledge, there is no case in the -08 draft, other than > the ones listed in 8 and 3.2, where order matters. > We have strong langage with MUSTs in these paragraphs, the text "the > order is significant" you quote is just a forewarning early in the > draft. > > Thanks again, and comments welcome from all. > Best, > > Dominique > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part > de Omprakash Gnawali > Envoy=C3=A9 : samedi 10 juillet 2010 01:17 > =C3=80 : ROLL WG > Objet : [Roll] metric ordering according > todraft-ietf-roll-routing-metrics-08 > > "8. > ... =C2=A0 When the DAG Metric Container contains several aggregated > metrics, =C2=A0 they are to be used as tie-brakers in the order that they > appear in > =C2=A0 the DAG Metric Container. =C2=A0A node propagating a DAG Metric Co= ntainer > =C2=A0 MUST keep the order of metric objects unchanged. > > =C2=A0 An example of such use of multiple aggregated metrics is the > =C2=A0 following: Hop-Count as the primary criterion, LQL as the secondar= y > =C2=A0 criterion and Fanout Ratio as the ultimate tie-braker. =C2=A0In su= ch a > =C2=A0 case, the Hop-Count, LQL and Fanout Ratio metric objects need to > =C2=A0 appear in that order in the DAG Metric Container. > > ..." > > Is the semantics behind the ordering intentional? > > A packet could be forwarded from a node that prefers to use one set of > objective to a node that prefers to use a different objective. For > example, from a low power energy scavenging sensor to a powered node. > Not allowing the nodes to change the order allows a node to dictate > the relative importance of this metric to rest of the network without > regard to their preference. > > If we had already considered that scenario and determined to be not > important, it might be worth making the last sentence in the following > paragraph stronger - are there other cases besides those mentioned in > 8 and 3.2? > > "2. > ... =C2=A0 Note that the Routing Metric/Constraint objects defined in thi= s > =C2=A0 document can appear in any order in the DAG Metric Container. > =C2=A0 However, for some of them, the order is significant (as described = in > =C2=A0 Section 8 and Section 3.2, for example). > " > > - om_p > _______________________________________________ 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 prvs=809a70b48=mukul@uwm.edu Mon Jul 19 11:55:25 2010 Return-Path: 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 3E0053A68D5 for ; Mon, 19 Jul 2010 11:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Mr5wNkLYSAMt for ; Mon, 19 Jul 2010 11:55:24 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 5C5153A6B36 for ; Mon, 19 Jul 2010 11:55:24 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 19 Jul 2010 13:55:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id D2EBF2B3F02 for ; Mon, 19 Jul 2010 13:55:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-KNu5hXG7ki for ; Mon, 19 Jul 2010 13:55:25 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id B7CDD2B3EF6 for ; Mon, 19 Jul 2010 13:55:25 -0500 (CDT) Date: Mon, 19 Jul 2010 13:55:38 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Mon, 19 Jul 2010 18:55:25 -0000 Here is a quote from Section 3.4 of RPL-10 "Any given RPL Instance is either Winter, et al. Expires December 30, 2010 [Page 15] Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 storing or non-storing. In both cases, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward route). " I dont think that a P2P packet necessarily always travels to the DODAG root in storing mode. It is possible that it turns around at a common non-root ancestor of the source and the destination. Thanks Mukul From jpv@cisco.com Mon Jul 19 12:49:23 2010 Return-Path: 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 51F563A694D for ; Mon, 19 Jul 2010 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bm4nErnj9eSm for ; Mon, 19 Jul 2010 12:49: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 8738A3A6951 for ; Mon, 19 Jul 2010 12:49:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJNIRExAZnwN/2dsb2JhbACfa3GrVZsMhSIEiFaCNA X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="134303620" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2010 19:49:35 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JJnZdj022432; Mon, 19 Jul 2010 19:49:35 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 21:49:35 +0200 Received: from [192.168.3.55] ([10.61.107.215]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 21:49:34 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C446D0A.7060106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 21:49:32 +0200 References: <4C1F3935.9050302@gmail.com> <4C446D0A.7060106@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Jul 2010 19:49:35.0045 (UTC) FILETIME=[8379CF50:01CB277B] Cc: ROLL WG Subject: Re: [Roll] The Design Teams in RoLL 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: , X-List-Received-Date: Mon, 19 Jul 2010 19:49:23 -0000 Hi Alex, The DT has been dissolved months ago ... JP. On Jul 19, 2010, at 5:19 PM, Alexandru Petrescu wrote: > Le 23/06/2010 16:06, JP Vasseur a =E9crit : >> Hi Alex, >> >> On Jun 21, 2010, at 12:04 PM, Alexandru Petrescu wrote: >> >>> Hello RoLL, >>> >>> I am trying to follow the RoLL group closely. What are the active >>> DTs, their membership and respective charters, documents? >>> >>> Until now I know of: >>> >>> RPL DT Security DT >>> >> >> You are correct. Only two official RPLL DT have been formed so far: >> * RPL DT (now dissolved) > > RPL DT dissolved? Who edits the RPL document currently? > > I see a "RPL Author Team" in the topmost right header of the RPL draft > but the Athors' Addresses do not say who the members of the Team =20 > are... > and the Design Team is now dissolved. > > It's good to know who one talks to. > > Alex > > >> * Security DT >> >> For each of them, I sent an email to the list with the list of >> members, charters and milestones. >> >>> I think there may be more DTs (p2p, metrics?). I think some DTs >>> were announced publicly on the mailing list, whereas some other >>> DTs were not announced. It's difficult to understand what's >>> happening. >> >> There is no other DTs, otherwise I would have announced them on the >> list. >> >> Thanks. >> >> JP. >> >>> >>> Alex >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > > From culler@cs.berkeley.edu Mon Jul 19 12:58:08 2010 Return-Path: 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 012FE3A6B59 for ; Mon, 19 Jul 2010 12:58:08 -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 p9JaIN3TukU3 for ; Mon, 19 Jul 2010 12:58:07 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0C38D3A6B4F for ; Mon, 19 Jul 2010 12:58:07 -0700 (PDT) Received: from [10.85.149.236] (72-254-60-71.client.stsn.net [72.254.60.71]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6JJwFCe027397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Jul 2010 12:58:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Culler In-Reply-To: <4C446D0A.7060106@gmail.com> Date: Mon, 19 Jul 2010 12:58:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C1F3935.9050302@gmail.com> <4C446D0A.7060106@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] The Design Teams in RoLL 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: , X-List-Received-Date: Mon, 19 Jul 2010 19:58:08 -0000 > Who edits the RPL document currently? The editor (Tim Winter) with support from the Authors. > see a "RPL Author Team" in the topmost right header of the RPL draft > but the Athors' Addresses do not say who the members of the Team = are... > and the Design Team is now dissolved. The header refers to the list at the end of the document because it is = too long to appear in the header. > It's good to know who one talks to. That is what the mailing list is for. And it is important that it is = used for substantive discussion. On Jul 19, 2010, at 8:19 AM, Alexandru Petrescu wrote: > Le 23/06/2010 16:06, JP Vasseur a =E9crit : >> Hi Alex, >>=20 >> On Jun 21, 2010, at 12:04 PM, Alexandru Petrescu wrote: >>=20 >>> Hello RoLL, >>>=20 >>> I am trying to follow the RoLL group closely. What are the active >>> DTs, their membership and respective charters, documents? >>>=20 >>> Until now I know of: >>>=20 >>> RPL DT Security DT >>>=20 >>=20 >> You are correct. Only two official RPLL DT have been formed so far: >> * RPL DT (now dissolved) >=20 > RPL DT dissolved? Who edits the RPL document currently? >=20 > I see a "RPL Author Team" in the topmost right header of the RPL draft > but the Athors' Addresses do not say who the members of the Team = are... > and the Design Team is now dissolved. >=20 > It's good to know who one talks to. >=20 > Alex >=20 >=20 >> * Security DT >>=20 >> For each of them, I sent an email to the list with the list of >> members, charters and milestones. >>=20 >>> I think there may be more DTs (p2p, metrics?). I think some DTs >>> were announced publicly on the mailing list, whereas some other >>> DTs were not announced. It's difficult to understand what's >>> happening. >>=20 >> There is no other DTs, otherwise I would have announced them on the >> list. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>>=20 >>> Alex >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Mon Jul 19 13:24:48 2010 Return-Path: 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 61C0F3A6B76 for ; Mon, 19 Jul 2010 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 oCoXG7BHk3JI for ; Mon, 19 Jul 2010 13:24:47 -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 145D73A6B74 for ; Mon, 19 Jul 2010 13:24:47 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAANRREyrR7Hu/2dsb2JhbACfbXGrH5sShSIEiFaCNIcO X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208,217";a="561393339" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jul 2010 20:25:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6JKP0hF027768; Mon, 19 Jul 2010 20:25:01 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 22:25:00 +0200 Received: from [192.168.3.55] ([10.61.107.215]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 22:24:59 +0200 Message-Id: <969DF4DF-4AA9-4BFF-814E-782E5AD58D97@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-46-616187659 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 22:24:58 +0200 References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Jul 2010 20:24:59.0494 (UTC) FILETIME=[75BF0060:01CB2780] Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Mon, 19 Jul 2010 20:24:48 -0000 --Apple-Mail-46-616187659 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks Mukul, I had caught this one in the detailed review that I sent =20= out last week (ticket #70): 3.4. Downward Routes and Destination Advertisement RPL uses Destination Advertisement Object (DAO) messages to =20 establish downward routes from DODAG roots. JP> Not just from DODAG roots ... DAO messages are an optional feature for applications that require P2MP or P2P traffic. RPL supports two modes of downward traffic: storing (fully stateful) or non-storing (fully source routed). Any given RPL Instance is either Winter, et al. Expires December 30, 2010 [Page 15] =0C Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 storing or non-storing. In both cases, P2P packets travel up to a DODAG Root JP> Or a common ancestor in the case of storing nodes then down to the final destination (unless the destination is on the upward route). JP> with regards to the last sentence, indicate that this is with the =20= default mode of RPL specified in this specification. Cheers. JP. On Jul 19, 2010, at 8:55 PM, Mukul Goyal wrote: > Here is a quote from Section 3.4 of RPL-10 > > "Any given RPL Instance is either > > > > Winter, et al. Expires December 30, 2010 [Page =20= > 15] > > Internet-Draft draft-ietf-roll-rpl-10 Jun =20= > 2010 > > > storing or non-storing. In both cases, P2P packets travel up to a > DODAG Root then down to the final destination (unless the =20 > destination > is on the upward route). > " > > I dont think that a P2P packet necessarily always travels to the =20 > DODAG root in storing mode. It is possible that it turns around at a =20= > common non-root ancestor of the source and the destination. > > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-46-616187659 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks Mukul, I had caught this = one in the detailed review that I sent out last week (ticket = #70):

3.4.  Downward Routes and Destination =
Advertisement

   RPL uses Destination Advertisement Object (DAO) messages to establish
   downward routes from DODAG roots.  
JP> Not just from DODAG roots =
... 
DAO messages =
are an optional
   feature for applications that require P2MP or P2P traffic.  RPL
   supports two modes of downward traffic: storing (fully stateful) or
   non-storing (fully source routed).  Any given RPL Instance is either



Winter, et al.          Expires December 30, 2010              [Page 15]
=0C
Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010


   storing or non-storing.  In both cases, P2P packets travel up to a
   DODAG Root 
JP> Or a =
common ancestor in the case of storing =
nodes
then down to =
the final destination (unless the destination
   is on the upward route).
JP> with =
regards to the last sentence, indicate that this is with the =
default
mode of RPL specified in this =
specification.
Here is a quote from Section 3.4 of =
RPL-10

"Any given RPL Instance is either



Winter, =
et al.          Expires =
December 30, 2010 =
            &n=
bsp;[Page 15]

Internet-Draft =
          draft-ietf-rol=
l-rpl-10 =
            &n=
bsp;   Jun 2010


   storing or =
non-storing.  In both cases, P2P packets travel up to a
 =
  DODAG Root then down to the final destination (unless the =
destination
   is on the upward route).
"

I dont =
think that a P2P packet necessarily always travels to the DODAG root in =
storing mode. It is possible that it turns around at a common non-root =
ancestor of the source and the =
destination.

Thanks
Mukul
___________________________________=
____________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/roll

= --Apple-Mail-46-616187659-- From prvs=80951255a=Roger.Alexander@cooperindustries.com Mon Jul 19 15:08:54 2010 Return-Path: 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 C86BA3A6B90 for ; Mon, 19 Jul 2010 15:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 WaJxaMLvfrq5 for ; Mon, 19 Jul 2010 15:08:52 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 2F2F03A6B7C for ; Mon, 19 Jul 2010 15:08:51 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278302400"; d="scan'208";a="61607266" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 19 Jul 2010 18:09:05 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 18:09:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 19 Jul 2010 18:07:57 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19C8AD@EVS4.nam.ci.root> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574B0C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Closing issue#56 (2nd): Transit and Target addressmismatch Thread-Index: AcslAq5x7BE3Tkv6SV+9AphapiKK7QCTiF7g References: <6A2A459175DABE4BB11DE2026AA50A5D02574B0C@XMB-AMS-107.cisco.com> From: "Alexander, Roger" To: "Pascal Thubert (pthubert)" , X-OriginalArrivalTime: 19 Jul 2010 22:09:04.0753 (UTC) FILETIME=[0035E610:01CB278F] Subject: Re: [Roll] Closing issue#56 (2nd): Transit and Target addressmismatch 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: , X-List-Received-Date: Mon, 19 Jul 2010 22:08:55 -0000 KzEuIA0KDQpSb2dlcg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJv bGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gU2VudDogRnJpZGF5LCBKdWx5 IDE2LCAyMDEwIDEyOjIwIFBNDQo+IFRvOiByb2xsQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb Um9sbF0gQ2xvc2luZyBpc3N1ZSM1NiAoMm5kKTogVHJhbnNpdCBhbmQgVGFyZ2V0DQo+IGFkZHJl c3NtaXNtYXRjaA0KPiANCj4gVG8gbWFrZSBzb21lIHJvb20gZm9yIG5ldyBmbGFncyBJJ20gcHJv cG9zaW5nIHRvIHJlZHVjZSB0aGUgdHJhbnNpdA0KPiBsaWZldGltZSB0byAzIG9jdGV0cy4NCj4g VGhpcyBsZWF2ZXMgYWJvdXQgMjAwIGRheXMgYmVmb3JlIHlvdSBoYXZlIHRvIHJlZnJlc2ggYSBy b3V0ZS4NCj4gV291bGQgdGhlcmUgYmUgYW4gaXNzdWUgd2l0aCB0aGF0Pw0KPiANCj4gUGFzY2Fs DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogcm9sbC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YNCj4gPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ID4gU2VudDogVHVlc2RheSwgSnVs eSAxMywgMjAxMCAxOjUzIFBNDQo+ID4gVG86IE1hdGhpbGRlIER1cnZ5IChtZHVydnkpDQo+ID4g Q2M6IHJvbGxAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbUm9sbF0gQ2xvc2luZyBpc3N1ZSM1NiAo Mm5kKTogVHJhbnNpdCBhbmQgVGFyZ2V0IGFkZHJlc3MNCj4gbWlzbWF0Y2gNCj4gPg0KPiA+IFJl d29yZGluZyBhZnRlciB0aGUgdGhyZWFkIHdpdGggTWF0aGlsZGUsIGhlcmUncyB3aGF0IHRoZSBy ZXNvbHV0aW9uDQo+IGZvciBJc3N1ZQ0KPiA+IDU2IHdvdWxkIHNheToNCj4gPg0KPiA+IC0gVGhl IFIgYml0IGluIFBJTyBpcyB1c2VkICBhcyBpbiBSRkMzNzc1IHRvIGluZGljYXRlIGEgKGdsb2Jh bC9VTEEpDQo+IGFkZHJlc3MgYXMNCj4gPiBvcHBvc2VkIHRvIGEgcHJlZml4Lg0KPiA+IC0gVGhl IHByZWZpeCBpcyBzdGlsbCB2YWxpZCBmb3IgdGhlIHB1cnBvc2Ugb2YgYXV0b2NvbmYgd2hlbiB0 aGUgUg0KPiBiaXQgaXMgc2V0Lg0KPiA+IC0gVGhlIGFkZHJlc3MgdXNlZCBhcyB0cmFuc2l0IHBh cmVudCBieSB0aGUgY2hpbGRyZW4gTVVTVCBiZSB0YWtlbg0KPiBmcm9tIGEgUElPDQo+ID4gZnJv bSB0aGF0IHBhcmVudCBidXQgaXMgbm90IG5lY2Vzc2FyaWx5IG9uIGxpbmsgZm9yIHRoZSBjaGls ZHJlbi4NCj4gPiAtIFRoZSByb3V0ZXIgdGhhdCBpdCBhZHZlcnRpc2VzIGFuIGFkZHJlc3MgYXMg cGFyZW50IGluIFBJTyBtdXN0IGFsc28NCj4gYWR2ZXJ0aXNlDQo+ID4gdGhhdCBhZGRyZXNzIGFz IHRhcmdldCBpbiBhIERBTyBmb3IgdGhlIHJvdXRlIHJlY3Vyc2lvbiB0byBjb21wbGV0ZS4NCj4g PiAtIEFuIGFkZHJlc3MgdGhhdCBpcyBhZHZlcnRpc2VkIGFzIHRhcmdldCBpbiBhIERBTyBtdXN0 IGJlIGNvbGxvY2F0ZWQNCj4gb3INCj4gPiByZWFjaGFibGUgb25saW5rIGJ5IHRoZSBwYXJlbnQg dGhhdCBpcyBpbmRpY2F0ZWQgaW4gdGhlIGFzc29jaWF0ZWQNCj4gdHJhbnNpdA0KPiA+IGluZm9y bWF0aW9uLg0KPiA+IC0gQSBuZXcgZmxhZyBpbiB0aGUgdHJhbnNpdCBpbmZvcm1hdGlvbiBxdWFs aWZpZXMgYSB0YXJnZXQgYWRkcmVzcw0KPiB0aGF0IGlzIGJlaGluZCBhDQo+ID4gcm91dGVyLCBl aXRoZXIgYXMgYW4gYXR0YWNoZWQgaG9zdCBvciBpbnN0YWxsZWQgb24gYW5vdGhlciBpbnRlcmZh Y2UuDQo+IFRoZSByb3V0ZXINCj4gPiBpcyB0aGUgdHVubmVsIGVuZHBvaW50IGZvciBzdWNoIGFk ZHJlc3MuDQo+ID4NCj4gPiBXZSdsbCBub3RlIHRoYXQgaWYgdGhlIG5vbi1zdG9yaW5nIG1vZGUg REFPIGlzIHNlbnQgc3RyYWlnaHQgdG8gdGhlDQo+IHJvb3QgdGhlbiB0aGUNCj4gPiBwYXJlbnQg ZG9lcyBub3QgaGF2ZSBhIHdheSB0byBrbm93IGFib3V0IHRoZSBjaGlsZCB1bnRpbCBhIFJIIHBv cHMNCj4gdXAuIFNvIHRoZQ0KPiA+IGJpZGlyZWN0aW9uYWwgcmVhY2hhYmlsaXR5IHdpbGwgYmUg Y2hlY2tlZCBhdCB0aGF0IHRpbWUuDQo+ID4NCj4gPiBQYXNjYWwNCj4gPg0KPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogUGFzY2FsIFRodWJlcnQgKHB0 aHViZXJ0KQ0KPiA+ID4gU2VudDogRnJpZGF5LCBKdWx5IDA5LCAyMDEwIDQ6NTggUE0NCj4gPiA+ IFRvOiBNYXRoaWxkZSBEdXJ2eSAobWR1cnZ5KQ0KPiA+ID4gQ2M6IHJvbGxAaWV0Zi5vcmc7IGpw dkBjaXNjby5jb207IHdpbnRlcnRAYWNtLm9yZw0KPiA+ID4gU3ViamVjdDogQ2xvc2luZyBpc3N1 ZSM1NjogVHJhbnNpdCBhbmQgVGFyZ2V0IGFkZHJlc3MgbWlzbWF0Y2gNCj4gPiA+DQo+ID4gPiBI aSBNYXRoaWxkZToNCj4gPiA+DQo+ID4gPiBCYXNlZCBvbiB0aGUgdGhyZWFkIHdlIGhhdmUgaGFk IEkgdGhpbmsgdGhhdCB0aGUgdGV4dCBtdXN0IGNsYXJpZnkNCj4gdGhhdDoNCj4gPiA+DQo+ID4g PiAtIFRoZSBSIGJpdCBpbiBQSU8gaXMgdXNlZCAgYXMgaW4gUkZDMzc3NSB0byBpbmRpY2F0ZSBh DQo+IChnbG9iYWwvVUxBKQ0KPiA+ID4gYWRkcmVzcyBhcyBvcHBvc2VkIHRvIGEgcHJlZml4Lg0K PiA+ID4gLSBUaGUgcHJlZml4IGlzIHN0aWxsIHZhbGlkIGZvciB0aGUgcHVycG9zZSBvZiBhdXRv Y29uZiB3aGVuIHRoZSBSDQo+IGJpdCBpcyBzZXQuDQo+ID4gPiAtIFRoZSBhZGRyZXNzIGluIHRo ZSBQSU8gY2FuIGJlIHVzZWQgYXMgdHJhbnNpdCBwYXJlbnQgYnkgdGhlDQo+IGNoaWxkcmVuDQo+ ID4gPiBidXQgaXMgbm90IG5lY2Vzc2FyaWx5IG9uIGxpbmsgZm9yIHRoZSBjaGlsZHJlbi4NCj4g PiA+IC0gVGhlIHJvdXRlciB0aGF0IGl0IGFkdmVydGlzZXMgYW4gYWRkcmVzcyBhcyBwYXJlbnQg aW4gUElPIG11c3QNCj4gYWxzbw0KPiA+ID4gYWR2ZXJ0aXNlIHRoYXQgYWRkcmVzcyBhcyB0YXJn ZXQgaW4gYSBEQU8gZm9yIHRoZSByb3V0ZSByZWN1cnNpb24NCj4gdG8gY29tcGxldGUuDQo+ID4g PiAtIEFuIGFkZHJlc3MgdGhhdCBpcyBhZHZlcnRpc2VkIGFzIHRhcmdldCBpbiBhIERBTyBtdXN0 IGJlDQo+IGNvbGxvY2F0ZWQNCj4gPiA+IG9yIHJlYWNoYWJsZSBvbmxpbmsgYnkgdGhlIHBhcmVu dCB0aGF0IGlzIGluZGljYXRlZCBpbiB0aGUNCj4gYXNzb2NpYXRlZA0KPiA+ID4gdHJhbnNpdCBp bmZvcm1hdGlvbi4NCj4gPiA+IC0gQSBuZXcgZmxhZyBpbiB0aGUgdHJhbnNpdCBpbmZvcm1hdGlv biBxdWFsaWZpZXMgYSB0YXJnZXQgYWRkcmVzcw0KPiA+ID4gdGhhdCBpcyBiZWhpbmQgYSByb3V0 ZXIsIGVpdGhlciBhcyBhbiBhdHRhY2hlZCBob3N0IG9yIGluc3RhbGxlZCBvbg0KPiA+ID4gYW5v dGhlciBpbnRlcmZhY2UuIFRoZSByb3V0ZXIgaXMgdGhlIHR1bm5lbCBlbmRwb2ludCBmb3Igc3Vj aA0KPiBhZGRyZXNzLg0KPiA+ID4NCj4gPiA+IFdpbGwgdGhhdCBiZSBlbm91Z2ggdG8gY2xvc2Ug NTY/DQo+ID4gPg0KPiA+ID4gUGFzY2FsDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiA+ID4gT2Ygcm9s bCBpc3N1ZSB0cmFja2VyDQo+ID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDYsIDIwMTAgMTo0 MSBQTQ0KPiA+ID4gPiBUbzogd2ludGVydEBhY20ub3JnOyBqcHZAY2lzY28uY29tDQo+ID4gPiA+ IENjOiByb2xsQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFtSb2xsXSBbcm9sbF0gIzU2OiBU cmFuc2l0IGFuZCBUYXJnZXQgYWRkcmVzcyBtaXNtYXRjaA0KPiA+ID4gPg0KPiA+ID4gPiAjNTY6 IFtSb2xsXSBUcmFuc2l0IGFuZCBUYXJnZXQgYWRkcmVzcyBtaXNtYXRjaA0KPiA+ID4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLS0NCj4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4g PiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiA+ID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiA+ID4gPiAgUmVwb3J0ZXI6ICBqcHZA4oCmICAg ICAgICAgICAgfCAgICAgICBPd25lcjogIHdpbnRlcnRA4oCmDQo+ID4gPiA+ICAgICAgVHlwZTog IGVuaGFuY2VtZW50ICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KPiA+ID4gPiAgUHJpb3JpdHk6 ICBtaW5vciAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6DQo+ID4gPiA+IENvbXBvbmVudDogIHJw bCAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCj4gPiA+ID4gIFNldmVyaXR5OiAgSW4gV0cg TGFzdCBDYWxsICB8ICAgIEtleXdvcmRzOg0KPiA+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0NCj4gPiA+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiA+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLQ0KPiA+ID4gPiAgSGkgQWxsLA0KPiA+ID4gPg0KPiA+ID4gPiAgTGV04oCZcyBjb25z aWRlciB0aGUgc3RvcmluZyBtb2RlIGluIGEgc2ltcGxlIHRvcG9sb2d5IEHDoELDoFIgKMOgDQo+ IG1hcmsNCj4gPiA+ID4gdGhlIHBhcmVudCByZWxhdGlvbnNoaXApLiBMZXTigJlzIGFsc28gYXNz dW1lIHRoYXQgQSBoYXMgYSBwcmVmaXgNCj4g4oCYQXDigJkNCj4gPiA+ID4gYW5kIGEgIGdsb2Jh bCBhZGRyZXNzIOKAmEFn4oCZIHRvIGFkdmVydGlzZS4NCj4gPiA+ID4gIEluIHRoaXMgZXhhbXBs ZSB3ZSBoYXZlOg0KPiA+ID4gPiAgLSBBIHNlbmRzIERBTyB3aXRoIOKAnHRhcmdldCBBZywgQXAs IHRyYW5zaXQgQuKAnQ0KPiA+ID4gPiAgLSBCIHNlbmRzIERBTyB3aXRoIOKAnHRhcmdldCBCZywg dHJhbnNpdCBS4oCdIHRvZ2V0aGVyIHdpdGggdGhlDQo+ID4gPiA+IGluZm9ybWF0aW9uICBmcm9t IEEsIGkuZS4g4oCcdGFyZ2V0IEFnLCBBcCwgdHJhbnNpdCBC4oCdDQo+ID4gPiA+DQo+ID4gPiA+ ICBUaGVuIFIgcmVjb21iaW5lcyB0aGUgaW5mb3JtYXRpb24gdG8gZ2V0IHRoZSByb3V0ZSB0byBm b3INCj4gZXhhbXBsZQ0KPiA+ID4gPiBBcCAoVGFyZ2V0IEFwLCB0cmFuc2l0IEIsIHRhcmdldCBC ZywgdHJhbnNpdCBSKSAgRm9yIHRoaXMgdG8NCj4gd29yaywNCj4gPiA+ID4gdHJhbnNpdCBCIGFu ZCB0YXJnZXQgQmcgbmVlZCB0byBiZSBtYXRjaGVkLiBIb3cgY2FuIHRoaXMgIGJlDQo+IGRvbmU/ DQo+ID4gPiA+IERvZXMgaXQgbWVhbiB0aGF0IHRoZSB0cmFuc2l0IHBhcmVudCBhZGRyZXNzIGhh cyB0byBiZSBhIGdsb2JhbA0KPiA+ID4gPiBhZGRyZXNzPyBUaGlzIHdvdWxkIGltcGx5IHRoYXQg d2UgdXNlIGdsb2JhbCBhZGRyZXNzZXMgaW4gdGhlDQo+ID4gPiA+IHJvdXRpbmcNCj4gPiA+IGhl YWRlci4gSG93ZXZlciA2bWFuLXJwbC1yb3V0aW5nLWhlYWRlciBzYXlzOg0KPiA+ID4gPiAg4oCc V2hlbiBwcm9jZXNzaW5nIHRoZSBUeXBlIDQgUm91dGluZyBoZWFkZXIsIGEgcm91dGVyIE1VU1Qg ZHJvcA0KPiB0aGUNCj4gPiA+ID4gcGFja2V0IGlmIHRoZSBuZXh0IGVudHJ5IGlzIG5vdCBvbi1s aW5r4oCdDQo+ID4gPiA+ICBBcyBnbG9iYWwgYWRkcmVzc2VzIGhhdmUgdG8gYmUgb2ZmLWxpbmsg aW4gTkJNQSBuZXR3b3JrIGxpa2UNCj4gPiA+ID4gODAyLjE1LjQsIEkgIHNlZSBhIHByb2JsZW3i gKYNCj4gPiA+ID4NCj4gPiA+ID4gIENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgaG93IGFkZHJlc3Nl cyBhcmUgc3VwcG9zZWQgdG8gYmUgdXNlZCBpbg0KPiA+ID4gPiB0aGlzDQo+ID4gPiA+IHNvdXJj ZS0gcm91dGluZyBzY2VuYXJpby4NCj4gPiA+ID4NCj4gPiA+ID4gIFRoYW5rcywNCj4gPiA+ID4g IE1hdGhpbGRlDQo+ID4gPiA+DQo+ID4gPiA+IC0tDQo+ID4gPiA+IFRpY2tldCBVUkw6IDxodHRw czovL3N2bi50b29scy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0LzU2Pg0KPiA+ID4gPiBy b2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQo+ID4gPiA+DQo+ID4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IFJv bGwgbWFpbGluZyBsaXN0DQo+ID4gPiA+IFJvbGxAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+ IFJvbGxAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From prvs=80951255a=Roger.Alexander@cooperindustries.com Mon Jul 19 15:26:00 2010 Return-Path: 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 7C87A3A6B99 for ; Mon, 19 Jul 2010 15:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 QwoCiIc1XOlh for ; Mon, 19 Jul 2010 15:25:58 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id CD72D3A697F for ; Mon, 19 Jul 2010 15:25:57 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278302400"; d="scan'208";a="61609152" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 19 Jul 2010 18:26:12 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 18:26:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 18:24:33 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEE19C8B1@EVS4.nam.ci.root> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02574AC7@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option Thread-Index: AcskPBx3Ans5PGoCSMOo8kG032G7jgAtQ4EQAJgDZsA= References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com><4C3F395D.1050409@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D02574AC7@XMB-AMS-107.cisco.com> From: "Alexander, Roger" To: "Pascal Thubert (pthubert)" , "Tim Winter" , X-OriginalArrivalTime: 19 Jul 2010 22:26:11.0603 (UTC) FILETIME=[6442C630:01CB2791] Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Mon, 19 Jul 2010 22:26:00 -0000 I think equal cost multipath is a worthwhile objective. However, there is a question as to what extent must equal-cost be enforced? It may require at each hop that equal-cost be enforced by ensuring that DAOs of 'equal' preference always be sent to DAO Parents that are of equal rank. As a result, to ensure that paths are indeed equal cost, a node may be forced to send two DAOs to the same DAO Parent, even where multiple DAO Parents exist, if none of alternative DAO Parents are of equal rank to the selected DAO Parent. The net effect could be to reduce path diversity. Alternatively, there can be less precision in the enforcement of equal-cost with the corresponding softness in path preference extending also to the preferred path.=20 Roger=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Pascal Thubert (pthubert) > Sent: Friday, July 16, 2010 11:11 AM > To: Tim Winter; roll@ietf.org > Subject: Re: [Roll] Issue 59 on Transit information option >=20 >=20 > Apart from the clarification, I'd really like to enable Equal Cost > Multipath as Mathilde suggested. > Could we say that 2 consecutive bits 0-1, 2-3, 4-5, and 6-7 represent > paths of equal preference? That leaves us 4 degrees of preference which > is probably enough. > Ideas? >=20 >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Tim > > Winter > > Sent: Thursday, July 15, 2010 6:38 PM > > To: roll@ietf.org > > Subject: Re: [Roll] Issue 59 on Transit information option > > > > > > > > On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > > > Ho! I think the confusion is that not all the parents are > necessarily > > > DAO parents. The DAO parents are the subset of parents to which DAO > > > are sent (in storing) or about whom DAO are sent (in non storing). > So > > > in your example there would be only one. But the sentence can be > > > improved by saying that all DAOs sent at the same time are sent > with > > > the same sequence in order to build multiple paths. > > > > Yes, and it should also be clarified that if you have more DAO > Parents > than you > > can allocate Path Control bits for a given Target, then some of those > Parents > > will be left out of getting a DAO for that Target. > > > > -Tim > > > > > > > > > > > > Pascal > > > > > > *From:* Mathilde Durvy (mdurvy) > > > *Sent**:* Thursday, July 15, 2010 2:43 PM > > > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > > > *Cc:* 'roll@ietf.org' > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > Hi Pascal, > > > > > > To answer your question: > > > > > > - It seems to me that the path control usage is incompatible with > the > > > sentence "If a node sends a DAO to one DAO parent, it MUST send a > DAO > > > with the same DAOSequence to all other DAO parents". No? > > > > > > */[Pascal] The sequence that we are talking about now is probably > the > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > My point was not so much about the "sequence". What I meant is that > if > > > the path control has 1 bit set and you have 2 parents, you will > send > a > > > DAO to one parent without sending "to all other parents" no? > > > > > > Best, > > > > > > Mathilde > > > > > > */ /* > > > > > > *From:* Pascal Thubert (pthubert) > > > *Sent:* mardi, 13. juillet 2010 14:10 > > > *To:* Mathilde Durvy (mdurvy); JP Vasseur > > > *Cc:* roll@ietf.org > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > Hi Mathilde > > > > > > Thanks for your great help; I hope more people will follow your > > > example so we can deeply clean up the spec during the round. please > find > > below: > > > > > > Thanks again for your reply. What you say makes sense although I > still > > > think that the separation of the fields between the target and > transit > > > options is somewhat arbitrary J However this is not a major issue > and > > > maybe at this point it's more important to clarify the specs with > > > respect to the meaning / usage of the path sequence, control, and > lifetime. > > > > > > */[Pascal] Yes; at the end of the day the path control really had > to > > > be in the transit with the parent. Leaving the target without any > bit > > > allows us to add more headers that would also qualify that target > and > > > thus factorise./* > > > > > > - In storing mode, the path control is used to limit the DAO > fan-out. > > > It can also be used to set a preference between routes with the > > > limitation that it cannot specify two routes which are equally > > > preferred (since path control bits sent to different parents have > to > be > > disjoint). > > > > > > */[Pascal] We have to see that. ecmp should be acceptable. We have > an > > > active thread on path control, lets deal with that there./* > > > > > > - It seems to me that the path control usage is incompatible with > the > > > sentence "If a node sends a DAO to one DAO parent, it MUST send a > DAO > > > with the same DAOSequence to all other DAO parents". No? > > > > > > */[Pascal] The sequence that we are talking about now is probably > the > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > - In the non storing mode, the path control is not used to limit > the > > > DAO fan-out as nodes send DAOs to only one of their DAO parents. I > > > guess it can be used as a preference by the root when it computes > the source > > routes. > > > > > > */[Pascal] Yes/* > > > > > > - How is the path sequence processed? Given that we have already a > DAO > > > sequence is it possible to receive a stale path sequence? Isn't it > > > redundant? > > > > > > */[Pascal] I expect not. But the node may have a stale state from > that > > > needs to be deprecated. By deprecated I mean that the router should > > > stop forwarding through a node child that has last presented path > > > sequence 21 as soon as another child presents sequence 22 or more > for a > > same target. > > > This indicates that in a DAG, a new path sequence should rapidly > cause > > > a DAO. In a tree, that is less urgent./* > > > > > > - What does the lifetime represent concretely? Is it a measure of > the > > > lifetime of the link between the target and the transit? > > > > > > */[Pascal] the lifetime is important for 2 things at least:/* > > > > > > - Flush. A lifetime of 0 is a route flush. That is how we do > no-path. > > > > > > - Seq number validation. The path lifetime covers the path sequence > so > > > that in normal operations, the path sequence should not be > incremented > > > by 16 during a lifetime, so we should never see path sequence > numbers > > > that are out of sync by more than 16. > > > > > > It's a lot of questions, but I hope it will help make the DAO part > > > clearer to everybody! > > > > > > */[Pascal] including the editors since the doc belongs to the > group./* > > > > > > Best, > > > > > > Mathilde > > > > > > *From:* Pascal Thubert (pthubert) > > > *Sent:* mercredi, 7. juillet 2010 09:22 > > > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > Hi Mathilde, > > > > > > 1) In storing mode, the transit information "parent address" is not > > > used > > > > > > You're correct on that with the current spec. > > > > > > I'm pointing out that in some cases we are missing the info for the > > > tunnel endpoint and that it might become handy to indicate a RPL > > > router to which a target host is attached. > > > > > > 2) Hence the pattern would be (Target+) for storing and > > > (Target+,Transit+)+ for non-storing. > > > > > > We want to factorise: in non-storing mode, the target can have > > > multiple parents each one with a different path control. > > > > > > In storing mode, a router with multiple interfaces can place > multiple > > > targets for all its addresses and then only one transit info that > is > > > common to them all. > > > > > > Pascal > > > > > > *From:* Mathilde Durvy (mdurvy) > > > *Sent:* Tuesday, July 06, 2010 4:47 PM > > > *To:* Pascal Thubert (pthubert); 'ROLL WG' > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > Hi Pascal, > > > > > > My point is a bit different. > > > > > > In storing mode, the transit information "parent address" is not > used. > > > The only fields that are relevant in the transit information are > the > > > path control, sequence, and lifetime, which actually relate to the > > > target prefix. So why not put these fields in the target option and > > > use only the transit option when we are in non-storing mode and > hence > > > need to specify a parent address? > > > > > > Hence the pattern would be (Target+) for storing and > > > (Target+,Transit+)+ for non-storing. > > > > > > Does this make sense? > > > > > > Best, > > > > > > Mathilde > > > > > > *From:* Pascal Thubert (pthubert) > > > *Sent:* mardi, 6. juillet 2010 15:44 > > > *To:* Mathilde Durvy (mdurvy); ROLL WG > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > Hi Mathilde: > > > > > > Pls note that the target identifies the final destination and the > > > transit tells you about how you get there. So you can factorize > > > optimally depending on what you are doing. > > > > > > We have issue 55 that should cover your proposed change. AS Phil > > > pointed out, The pattern is really (Target+, Transit+)+. > > > > > > I tend to think that the parent is needed in storing mode to > indicate > > > the tunnel end point for targets outside the RPL network, like the > > > proverbial dumb host attached to a RPL router. > > > > > > What do you think? > > > > > > Pascal > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > > Behalf Of *Mathilde Durvy (mdurvy) > > > *Sent:* Tuesday, July 06, 2010 3:25 PM > > > *To:* ROLL WG > > > *Subject:* [Roll] FW: Transit information option > > > > > > Hi All, > > > > > > I didn't see these comments addressed in the new draft. Any reason? > > > > > > For point 2, I would go even further and propose to put the path > > > sequence, control, and lifetime fields in the Target option and > keep > > > only the parent address field in the Transit option. > > > > > > Let me add that the sentence "In a DIO, the RPL Target Option > > > identifies a resource that the root is trying to reach" should be > > > removed if I believe the list of options allowed for DIO. > > > > > > Best, > > > > > > Mathilde > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > > Behalf Of *Mathilde Durvy (mdurvy) > > > *Sent:* vendredi, 18. juin 2010 11:09 > > > *To:* Philip Levis > > > *Cc:* roll@ietf.org > > > *Subject:* Re: [Roll] Transit information option > > > > > > Hi All, > > > > > > I just looked at the updated draft and most of the comments below > have > > > been addresses / clarified. Just a few rather minor points: > > > > > > - Section 5.7.7. RPL Target. Based on the discussion below I would > > > change "A set of one or more Transit Information options MAY > directly > > > follow the Target option in a DAO message" to "a RPL Target Option > in > > > a unicast DAO MUST be followed by a set of one or more Transit > > > Information Option ". > > > > > > - If the Path-Sequence / Control fields are indeed used both in > > > storing (where I have doubts they are really needed) and non- > storing > > > mode, why not put them in the target option rather than in the > transit option. > > > This way we could maybe only use only the target option in storing > > > mode and the target+transit option in non-storing mode. This would > > > have the additional benefit of making the parent address mandatory > in > > > the transit information option and thus avoid a variable length > option. > > > > > > Best, > > > > > > Mathilde > > > > > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > > > *Sent:* vendredi, 11. juin 2010 18:10 > > > *To:* Mathilde Durvy (mdurvy) > > > *Cc:* roll@ietf.org > > > *Subject:* Re: [Roll] Transit information option > > > > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > > > > Hi Phil, > > > > > > Thanks a lot for your answer. Here are my comments: > > > > > > A few items that might be worth clarifying in version 09: > > > > > > - "Transit Information options MAY directly follow the Target > option" > > > Is it really a MAY? If not included it means the path sequence / > > > control / lifetime are not specified (which seems to contradict > section > > 7.1.4.2). > > > > > > In non-storing mode, it is definitely a MUST. Storing mode seems > like > > > it is a MUST as well... > > > > > > I think we all agree. > > > > > > - "A non-storing node that has more than one DAO parent MAY include > a > > > Transit Information option for each DAO parent as part of the > > > non-storing Destination Advertisement operation." Why would a node > do > > > that? If a node is sending a DAO for a specific target to e.g. 2 > DAO > > > parents (A and B) shouldn't he send one DAO with transit > information > A > > > (i.e. parent address =3D A) to DAO parent A and another DAO with > transit > > > information B to DAO parent B? Otherwise how this would work over > > > multiple hop? Maybe an example of DAO would help. > > > > > > - In section 7.1.5 point 2, I assume the node should add a transit > > > information with its parent before passing the content of the > received > > > DAO. Also do the operation specified on the path control field in > the > > > previous section for storing node also apply in the non-storing > case? > > > > > > These are good questions. Currently the draft is a bit unclear on > > > whether > > > > > > 1) a DAO's transit option contains the full source route when it > > > arrives at the DODAG Root, or > > > > > > 2) the DODAG Root receives just the last downward hops of each > node, > > > and stitches together source routes with this information. > > > > > > 1) seems like a much better idea to me. Note that if it's 2), then > in > > > non-storing mode node needs to send a DAO to just one DAO parent, > and > > > this DAO can contain the full set of last-hops. What are your > thoughts? > > > > > > Indeed, I think the current draft is a bit unclear. My > interpretation > > > when reading was 1 (probably due mostly to the history of the > draft). > > > Now from your comments I understand what the draft is proposing, > > > namely 2. Thanks for explaining. > > > > > > What triggered this change? > > > > > > It seems to me that if proper aggregation of the routes is > performed > > > (in particular if in the record route case you can avoid > transmitting > > > routes which are sub-routes of others) the two schemes could > actually > > > be quite similar in terms of overhead. This would need to be > confirmed > > > by a careful study as it could depend quite on bit on the topology. > > > What is quite clear is that 2 requires more processing power than 1 > as > > > it needs to reassemble routes from the received information. > > > > > > Also concerning your last comment, I agree. The DAO produced will > be > > > slightly larger but we send only one DAO instead of one DAO per DAO > > > parent. I think if we do that we might not really need the path > > > control field, correct? > > > > > > -09 has a rewrite of the Downward Routes section that should make > all > > > of this much clearer. The answer is 2), for reasons Richard brought > up > > > a few months ago. In particular, if you use 1), then when a node > > > changes its parent set it entire sub-DODAG must resend DAOs. This > is > a > > > significant cost. If you use 2), then only that node needs to send > a > > > new DAO. > > > > > > - Has the advantage of having multiple DAO parents been assessed > with > > > respect to the added complexity? One could argue that since we take > so > > > much care in selecting a preferred this should be a good enough > > > choice... Similar to Phil I'm getting worried about the increased > complexity. > > > > > > But note that in upward routes, there's a parent set. The concern > is > > > that the vagaries and unreliability of wireless links call for > > > supporting some degree of path diversity. Most protocols today > > > maintain multiple candidate next hops for this exact reason. > Because > > > downward routes start at the endpoints, there needs to be some way > to > > > establish multiple routes. Otherwise, when one link breaks and you > > > have to issue a trigger to the entire sub-DODAG. > > > > > > I understand how this would work in the storing case but in the > > > non-storing case how would you know at the root that the path > failed? > > > > > > ICMP error. > > > > > > 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 pal@cs.stanford.edu Mon Jul 19 17:45:34 2010 Return-Path: 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 62C0E3A6BC7 for ; Mon, 19 Jul 2010 17:45:34 -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 I-vudlxqhUA0 for ; Mon, 19 Jul 2010 17:45:33 -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 7ED9C3A6BB4 for ; Mon, 19 Jul 2010 17:45:33 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ob0xw-0004IZ-8V; Mon, 19 Jul 2010 17:45:48 -0700 In-Reply-To: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Mon, 19 Jul 2010 17:45:15 -0700 To: Mukul Goyal X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 00:45:34 -0000 On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > Here is a quote from Section 3.4 of RPL-10 > > "Any given RPL Instance is either > > > > Winter, et al. Expires December 30, 2010 > [Page 15] > > Internet-Draft draft-ietf-roll-rpl-10 Jun > 2010 > > > storing or non-storing. In both cases, P2P packets travel up to a > DODAG Root then down to the final destination (unless the > destination > is on the upward route). > " > > I dont think that a P2P packet necessarily always travels to the > DODAG root in storing mode. It is possible that it turns around at > a common non-root ancestor of the source and the destination. Mukul, You're right. I'd suggest removing the last sentence and replacing it with: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination." What do you think? Phil From yoav@yitran.com Mon Jul 19 23:33:48 2010 Return-Path: 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 E04243A69E5 for ; Mon, 19 Jul 2010 23:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gwidtCSy0G0Y for ; Mon, 19 Jul 2010 23:33:46 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 700253A694C for ; Mon, 19 Jul 2010 23:33:45 -0700 (PDT) Received: from source ([209.85.212.50]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTEVDVXj4qs8S4UV6+v4VXh8Gh2/SyYkd@postini.com; Mon, 19 Jul 2010 23:34:02 PDT Received: by vws10 with SMTP id 10so2165551vws.23 for ; Mon, 19 Jul 2010 23:33:57 -0700 (PDT) Received: by 10.224.49.66 with SMTP id u2mr5244333qaf.250.1279607636825; Mon, 19 Jul 2010 23:33:56 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> <12834.1279413508@marajade.sandelman.ca> In-Reply-To: <12834.1279413508@marajade.sandelman.ca> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsmfu3y0Rlbyf4HTMmHoZTHoF6dEABVEhwA Date: Tue, 20 Jul 2010 09:33:53 +0300 Message-ID: To: Michael Richardson , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] The word Up! 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: , X-List-Received-Date: Tue, 20 Jul 2010 06:33:49 -0000 Maybe define in the terminology or introduction: Spatial movement - RPL can be used by mobile nodes, but this movement will not be discussed/affect explicitly RPL nodes. Topology movement - where the terms up/down in the RPL spec mean:.... BTW - just a thought - should spatial movement capability be an explicit part of the OF/metric definitions in the metrics draft as a special object (for example, describing speed, heading, azimuth, etc.), such as Node Energy (NE), or is this a TLV for example in the Node State/Attribute (NSA)? Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Sunday, July 18, 2010 3:38 AM To: ROLL WG Subject: Re: [Roll] The word Up! {my appologies for time warp email, I'm cleaning out my RPL unread folder...} >>>>> "Philip" == Philip Levis writes: >>> I suggest that we might want to come up with a different term >>> than "move" to describe topology changes. >> Makes sense. >> >> If you change >> >> Root / \ A B / C >> >> By C--A--Root--B, now things move left <-> right, no more up and >> down. >> >> I believe the whole movement concept is confusing. Philip> What terminology do you think would be better? Philip> The notion of up/down and shallower/deeper are basic Philip> terminology in tree data structures and algorithms. E.g., Philip> depth first search. The issue I have is that the nodes usually do not move in physical space. There are situations where they *do*, and it's important to distinguish this. Philip> "Move" could be "change its position within the DODAG?" I suggest that we a term like "reattach" or something like that. Or some other synonym for move. What was it called in M.A.S.H. when they had to invoke the "Mobile" part of the name? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jul 19 23:45:55 2010 Return-Path: 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 AAEF03A6BE9 for ; Mon, 19 Jul 2010 23:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.337 X-Spam-Level: X-Spam-Status: No, score=-10.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 V6CSBzVlw3BW for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 63CC03A6BE6 for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFvjREyrR7H+/2dsb2JhbACfbnGmCoxijj+FIgSLCg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:46:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6k3FB011735; Tue, 20 Jul 2010 06:46:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 08:45:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 08:45:30 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02575106@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] The word Up! thread-index: Acsmfu3y0Rlbyf4HTMmHoZTHoF6dEABVEhwAAACqywA= References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> <12834.1279413508@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "Michael Richardson" , "ROLL WG" X-OriginalArrivalTime: 20 Jul 2010 06:45:34.0785 (UTC) FILETIME=[27B58310:01CB27D7] Subject: Re: [Roll] The word Up! 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: , X-List-Received-Date: Tue, 20 Jul 2010 06:45:55 -0000 Hi Yoav: =20 > Maybe define in the terminology or introduction: > Spatial movement - RPL can be used by mobile nodes, but this movement will > not be discussed/affect explicitly RPL nodes. > Topology movement - where the terms up/down in the RPL spec mean:.... =20 [Pascal]=20 Agreed. RPL can be used by mobile nodes. They will probably rather build trees than DAGs (see MANEMO). > BTW - just a thought - should spatial movement capability be an explicit part of > the OF/metric definitions in the metrics draft as a special object (for example, > describing speed, heading, azimuth, etc.), such as Node Energy (NE), or is this a > TLV for example in the Node State/Attribute (NSA)? [Pascal]=20 Great point. When applying this sort of technology to cars or trains (e.g. ITS), we found that the capability to detect nodes along a same trajectory was crucial, in order to setup peerings that would persist enough to enable classical interaction. Also, when using GPS and common topological maps, it is possible to advertise "going along road 109", which is another way of qualifying a direction. It could even be possible to affect 8::/3 prefixes to routes for the purpose of local addressing (like Autoconf and CoA) and document that in the GPS tables. As far as RPL is concerned, this is left open for new metrics drafts to dig in.=20 > Best regards, > Yoav >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Sunday, July 18, 2010 3:38 AM > To: ROLL WG > Subject: Re: [Roll] The word Up! >=20 >=20 > {my appologies for time warp email, I'm cleaning out my RPL unread folder...} >=20 > >>>>> "Philip" =3D=3D Philip Levis writes: > >>> I suggest that we might want to come up with a different term > >>> than "move" to describe topology changes. > >> Makes sense. > >> > >> If you change > >> > >> Root / \ A B / C > >> > >> By C--A--Root--B, now things move left <-> right, no more up and > >> down. > >> > >> I believe the whole movement concept is confusing. >=20 > Philip> What terminology do you think would be better? >=20 > Philip> The notion of up/down and shallower/deeper are basic > Philip> terminology in tree data structures and algorithms. E.g., > Philip> depth first search. >=20 > The issue I have is that the nodes usually do not move in physical space. > There are situations where they *do*, and it's important to distinguish this. >=20 > Philip> "Move" could be "change its position within the DODAG?" >=20 > I suggest that we a term like "reattach" or something like that. > Or some other synonym for move. What was it called in M.A.S.H. when they > had to invoke the "Mobile" part of the name? >=20 > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > > then sign the petition. >=20 > _______________________________________________ > 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 pthubert@cisco.com Mon Jul 19 23:59:33 2010 Return-Path: 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 4D5553A67D1 for ; Mon, 19 Jul 2010 23:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ow4x-Oq5esTR for ; Mon, 19 Jul 2010 23:59:30 -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 20E7B3A69E2 for ; Mon, 19 Jul 2010 23:59:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANblRExAZnwM/2dsb2JhbACfbnGmA5shhSIEiwqHDg Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 06:59:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6xip3016009; Tue, 20 Jul 2010 06:59:44 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 08:59:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 08:59:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257510F@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Section 3.4 in RPL-10 thread-index: AcsnpjE4y0q8URMGQXmBnxvXIpMYKQAMfCPQ References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Mukul Goyal" X-OriginalArrivalTime: 20 Jul 2010 06:59:44.0499 (UTC) FILETIME=[222D9430:01CB27D9] Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 06:59:33 -0000 This text troubles me a bit.=20 There is a confusion between P2P in the sense of node to node (as opposed to P2MP and MP2P) and P2P in the sense of the optimization that Mukul, Jerry, Anders and others are working on. I'd like to separate the 2. We can indicate that additional P2P optimizations are on the works but with the main spec, the P2P goes up to the common parent and then down in storing, and up to the root and then down in non storing. Extending Phil's text: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination. Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Tuesday, July 20, 2010 2:45 AM > To: Mukul Goyal > Cc: roll > Subject: Re: [Roll] Section 3.4 in RPL-10 >=20 >=20 > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: >=20 > > Here is a quote from Section 3.4 of RPL-10 > > > > "Any given RPL Instance is either > > > > > > > > Winter, et al. Expires December 30, 2010 > > [Page 15] > > > > Internet-Draft draft-ietf-roll-rpl-10 Jun > > 2010 > > > > > > storing or non-storing. In both cases, P2P packets travel up to a > > DODAG Root then down to the final destination (unless the > > destination > > is on the upward route). > > " > > > > I dont think that a P2P packet necessarily always travels to the DODAG > > root in storing mode. It is possible that it turns around at a common > > non-root ancestor of the source and the destination. >=20 > Mukul, >=20 > You're right. I'd suggest removing the last sentence and replacing it > with: >=20 > "In the case of a non-storing network, P2P packets travel up to a DODAG Root > then down to the final destination (unless the destination is on the upward path > to the DODAG Root). In the case of a storing network, P2P packets travel > upwards towards a DODAG Root until they reach a common ancestor with the > destination, at which point they travel down to the destination." >=20 > What do you think? >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Tue Jul 20 00:07:20 2010 Return-Path: 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 893943A6BF4 for ; Tue, 20 Jul 2010 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 S5ExCm0zNqVz for ; Tue, 20 Jul 2010 00:07:19 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 167663A6BE9 for ; Tue, 20 Jul 2010 00:07:19 -0700 (PDT) Received: from source ([209.85.212.50]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTEVLNX5DavtiIC6JCyIxeJXjkKP373bt@postini.com; Tue, 20 Jul 2010 00:07:34 PDT Received: by mail-vw0-f50.google.com with SMTP id 10so2190540vws.23 for ; Tue, 20 Jul 2010 00:07:33 -0700 (PDT) Received: by 10.224.93.130 with SMTP id v2mr4705678qam.253.1279609652566; Tue, 20 Jul 2010 00:07:32 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0257510F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0257510F@XMB-AMS-107.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsnpjE4y0q8URMGQXmBnxvXIpMYKQAMfCPQAABdUKA= Date: Tue, 20 Jul 2010 10:07:30 +0300 Message-ID: <0827489c0d40521405cbb2c6c82440f4@mail.gmail.com> To: "Pascal Thubert (pthubert)" , Philip Levis , Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 07:07:20 -0000 Hi Pascal, I agree to this text, but there may be some ambiguity in the following para.: "... Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." One may understand that these optimizations cannot be used with RPL. May I suggest a slight modification to this - something in the lines of: "... Additional RPL route optimization such as [non normative ref to Mukul's draft] that may enable P2P packet travel shortcuts can be used in complementary to the P2P method described above." Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, July 20, 2010 10:00 AM To: Philip Levis; Mukul Goyal Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 This text troubles me a bit. There is a confusion between P2P in the sense of node to node (as opposed to P2MP and MP2P) and P2P in the sense of the optimization that Mukul, Jerry, Anders and others are working on. I'd like to separate the 2. We can indicate that additional P2P optimizations are on the works but with the main spec, the P2P goes up to the common parent and then down in storing, and up to the root and then down in non storing. Extending Phil's text: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination. Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Tuesday, July 20, 2010 2:45 AM > To: Mukul Goyal > Cc: roll > Subject: Re: [Roll] Section 3.4 in RPL-10 > > > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > > > Here is a quote from Section 3.4 of RPL-10 > > > > "Any given RPL Instance is either > > > > > > > > Winter, et al. Expires December 30, 2010 > > [Page 15] > > > > Internet-Draft draft-ietf-roll-rpl-10 Jun > > 2010 > > > > > > storing or non-storing. In both cases, P2P packets travel up to a > > DODAG Root then down to the final destination (unless the > > destination > > is on the upward route). > > " > > > > I dont think that a P2P packet necessarily always travels to the DODAG > > root in storing mode. It is possible that it turns around at a common > > non-root ancestor of the source and the destination. > > Mukul, > > You're right. I'd suggest removing the last sentence and replacing it > with: > > "In the case of a non-storing network, P2P packets travel up to a DODAG Root > then down to the final destination (unless the destination is on the upward path > to the DODAG Root). In the case of a storing network, P2P packets travel > upwards towards a DODAG Root until they reach a common ancestor with the > destination, at which point they travel down to the destination." > > What do you think? > > 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 pthubert@cisco.com Tue Jul 20 00:08:32 2010 Return-Path: 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 C3D9D3A6BFD for ; Tue, 20 Jul 2010 00:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.35 X-Spam-Level: X-Spam-Status: No, score=-10.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Irv+2pUIGfS9 for ; Tue, 20 Jul 2010 00:08: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 4BC763A6BE9 for ; Tue, 20 Jul 2010 00:08:20 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC/oRExAZnwN/2dsb2JhbACfbnGleJsjhSIEiwo Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 07:08:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K78Id3006448; Tue, 20 Jul 2010 07:08:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 09:08:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 09:08:26 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02575117@XMB-AMS-107.cisco.com> In-Reply-To: <9BB070DB2D281946859EA89837931EEE19C8B1@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option thread-index: AcskPBx3Ans5PGoCSMOo8kG032G7jgAtQ4EQAJgDZsAAIhCZMA== References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com><4C3F395D.1050409@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D02574AC7@XMB-AMS-107.cisco.com> <9BB070DB2D281946859EA89837931EEE19C8B1@EVS4.nam.ci.root> From: "Pascal Thubert (pthubert)" To: "Alexander, Roger" , "Tim Winter" , X-OriginalArrivalTime: 20 Jul 2010 07:08:30.0162 (UTC) FILETIME=[5B7F6320:01CB27DA] Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Tue, 20 Jul 2010 07:08:33 -0000 Hi Roger: On board with the latter. We can't have much precision here. But I'd like to be able to make a difference between a strict order an loose equivalence. If parent A and parent B give me an approximately equal metric set downwards, then I do not necessarily want to impose an order. Do you see an issue with the idea that says that the path control bits are paired for roughly equivalent parents? The consequence is probably that we'd have to skip (not use) some bits when there is not a second equivalent parent, but I fail to see that as a problem. I do not expect a real case to fan out more than 3 or 4 parents anyway.=20 Do I miss something? Pascal > -----Original Message----- > From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com] > Sent: Tuesday, July 20, 2010 12:25 AM > To: Pascal Thubert (pthubert); Tim Winter; roll@ietf.org > Subject: RE: [Roll] Issue 59 on Transit information option >=20 > I think equal cost multipath is a worthwhile objective. However, there is a > question as to what extent must equal-cost be enforced? It may require at each > hop that equal-cost be enforced by ensuring that DAOs of 'equal' preference > always be sent to DAO Parents that are of equal rank. > As a result, to ensure that paths are indeed equal cost, a node may be forced to > send two DAOs to the same DAO Parent, even where multiple DAO Parents > exist, if none of alternative DAO Parents are of equal rank to the selected DAO > Parent. The net effect could be to reduce path diversity. Alternatively, there > can be less precision in the enforcement of equal-cost with the corresponding > softness in path preference extending also to the preferred path. >=20 > Roger >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Pascal Thubert (pthubert) > > Sent: Friday, July 16, 2010 11:11 AM > > To: Tim Winter; roll@ietf.org > > Subject: Re: [Roll] Issue 59 on Transit information option > > > > > > Apart from the clarification, I'd really like to enable Equal Cost > > Multipath as Mathilde suggested. > > Could we say that 2 consecutive bits 0-1, 2-3, 4-5, and 6-7 represent > > paths of equal preference? That leaves us 4 degrees of preference > which > > is probably enough. > > Ideas? > > > > > > Pascal > > > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > > Of Tim > > > Winter > > > Sent: Thursday, July 15, 2010 6:38 PM > > > To: roll@ietf.org > > > Subject: Re: [Roll] Issue 59 on Transit information option > > > > > > > > > > > > On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > > > > Ho! I think the confusion is that not all the parents are > > necessarily > > > > DAO parents. The DAO parents are the subset of parents to which > DAO > > > > are sent (in storing) or about whom DAO are sent (in non storing). > > So > > > > in your example there would be only one. But the sentence can be > > > > improved by saying that all DAOs sent at the same time are sent > > with > > > > the same sequence in order to build multiple paths. > > > > > > Yes, and it should also be clarified that if you have more DAO > > Parents > > than you > > > can allocate Path Control bits for a given Target, then some of > those > > Parents > > > will be left out of getting a DAO for that Target. > > > > > > -Tim > > > > > > > > > > > > > > > > > Pascal > > > > > > > > *From:* Mathilde Durvy (mdurvy) > > > > *Sent**:* Thursday, July 15, 2010 2:43 PM > > > > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > > > > *Cc:* 'roll@ietf.org' > > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > > > Hi Pascal, > > > > > > > > To answer your question: > > > > > > > > - It seems to me that the path control usage is incompatible with > > the > > > > sentence "If a node sends a DAO to one DAO parent, it MUST send a > > DAO > > > > with the same DAOSequence to all other DAO parents". No? > > > > > > > > */[Pascal] The sequence that we are talking about now is probably > > the > > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > > > My point was not so much about the "sequence". What I meant is > that > > if > > > > the path control has 1 bit set and you have 2 parents, you will > > send > > a > > > > DAO to one parent without sending "to all other parents" no? > > > > > > > > Best, > > > > > > > > Mathilde > > > > > > > > */ /* > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > *Sent:* mardi, 13. juillet 2010 14:10 > > > > *To:* Mathilde Durvy (mdurvy); JP Vasseur > > > > *Cc:* roll@ietf.org > > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > > > Hi Mathilde > > > > > > > > Thanks for your great help; I hope more people will follow your > > > > example so we can deeply clean up the spec during the round. > please > > find > > > below: > > > > > > > > Thanks again for your reply. What you say makes sense although I > > still > > > > think that the separation of the fields between the target and > > transit > > > > options is somewhat arbitrary J However this is not a major issue > > and > > > > maybe at this point it's more important to clarify the specs with > > > > respect to the meaning / usage of the path sequence, control, and > > lifetime. > > > > > > > > */[Pascal] Yes; at the end of the day the path control really had > > to > > > > be in the transit with the parent. Leaving the target without any > > bit > > > > allows us to add more headers that would also qualify that target > > and > > > > thus factorise./* > > > > > > > > - In storing mode, the path control is used to limit the DAO > > fan-out. > > > > It can also be used to set a preference between routes with the > > > > limitation that it cannot specify two routes which are equally > > > > preferred (since path control bits sent to different parents have > > to > > be > > > disjoint). > > > > > > > > */[Pascal] We have to see that. ecmp should be acceptable. We have > > an > > > > active thread on path control, lets deal with that there./* > > > > > > > > - It seems to me that the path control usage is incompatible with > > the > > > > sentence "If a node sends a DAO to one DAO parent, it MUST send a > > DAO > > > > with the same DAOSequence to all other DAO parents". No? > > > > > > > > */[Pascal] The sequence that we are talking about now is probably > > the > > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > > > - In the non storing mode, the path control is not used to limit > > the > > > > DAO fan-out as nodes send DAOs to only one of their DAO parents. I > > > > guess it can be used as a preference by the root when it computes > > the source > > > routes. > > > > > > > > */[Pascal] Yes/* > > > > > > > > - How is the path sequence processed? Given that we have already a > > DAO > > > > sequence is it possible to receive a stale path sequence? Isn't it > > > > redundant? > > > > > > > > */[Pascal] I expect not. But the node may have a stale state from > > that > > > > needs to be deprecated. By deprecated I mean that the router > should > > > > stop forwarding through a node child that has last presented path > > > > sequence 21 as soon as another child presents sequence 22 or more > > for a > > > same target. > > > > This indicates that in a DAG, a new path sequence should rapidly > > cause > > > > a DAO. In a tree, that is less urgent./* > > > > > > > > - What does the lifetime represent concretely? Is it a measure of > > the > > > > lifetime of the link between the target and the transit? > > > > > > > > */[Pascal] the lifetime is important for 2 things at least:/* > > > > > > > > - Flush. A lifetime of 0 is a route flush. That is how we do > > no-path. > > > > > > > > - Seq number validation. The path lifetime covers the path > sequence > > so > > > > that in normal operations, the path sequence should not be > > incremented > > > > by 16 during a lifetime, so we should never see path sequence > > numbers > > > > that are out of sync by more than 16. > > > > > > > > It's a lot of questions, but I hope it will help make the DAO part > > > > clearer to everybody! > > > > > > > > */[Pascal] including the editors since the doc belongs to the > > group./* > > > > > > > > Best, > > > > > > > > Mathilde > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > *Sent:* mercredi, 7. juillet 2010 09:22 > > > > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > Hi Mathilde, > > > > > > > > 1) In storing mode, the transit information "parent address" is > not > > > > used > > > > > > > > You're correct on that with the current spec. > > > > > > > > I'm pointing out that in some cases we are missing the info for > the > > > > tunnel endpoint and that it might become handy to indicate a RPL > > > > router to which a target host is attached. > > > > > > > > 2) Hence the pattern would be (Target+) for storing and > > > > (Target+,Transit+)+ for non-storing. > > > > > > > > We want to factorise: in non-storing mode, the target can have > > > > multiple parents each one with a different path control. > > > > > > > > In storing mode, a router with multiple interfaces can place > > multiple > > > > targets for all its addresses and then only one transit info that > > is > > > > common to them all. > > > > > > > > Pascal > > > > > > > > *From:* Mathilde Durvy (mdurvy) > > > > *Sent:* Tuesday, July 06, 2010 4:47 PM > > > > *To:* Pascal Thubert (pthubert); 'ROLL WG' > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > Hi Pascal, > > > > > > > > My point is a bit different. > > > > > > > > In storing mode, the transit information "parent address" is not > > used. > > > > The only fields that are relevant in the transit information are > > the > > > > path control, sequence, and lifetime, which actually relate to the > > > > target prefix. So why not put these fields in the target option > and > > > > use only the transit option when we are in non-storing mode and > > hence > > > > need to specify a parent address? > > > > > > > > Hence the pattern would be (Target+) for storing and > > > > (Target+,Transit+)+ for non-storing. > > > > > > > > Does this make sense? > > > > > > > > Best, > > > > > > > > Mathilde > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > *Sent:* mardi, 6. juillet 2010 15:44 > > > > *To:* Mathilde Durvy (mdurvy); ROLL WG > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > Hi Mathilde: > > > > > > > > Pls note that the target identifies the final destination and the > > > > transit tells you about how you get there. So you can factorize > > > > optimally depending on what you are doing. > > > > > > > > We have issue 55 that should cover your proposed change. AS Phil > > > > pointed out, The pattern is really (Target+, Transit+)+. > > > > > > > > I tend to think that the parent is needed in storing mode to > > indicate > > > > the tunnel end point for targets outside the RPL network, like the > > > > proverbial dumb host attached to a RPL router. > > > > > > > > What do you think? > > > > > > > > Pascal > > > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > > > Behalf Of *Mathilde Durvy (mdurvy) > > > > *Sent:* Tuesday, July 06, 2010 3:25 PM > > > > *To:* ROLL WG > > > > *Subject:* [Roll] FW: Transit information option > > > > > > > > Hi All, > > > > > > > > I didn't see these comments addressed in the new draft. Any > reason? > > > > > > > > For point 2, I would go even further and propose to put the path > > > > sequence, control, and lifetime fields in the Target option and > > keep > > > > only the parent address field in the Transit option. > > > > > > > > Let me add that the sentence "In a DIO, the RPL Target Option > > > > identifies a resource that the root is trying to reach" should be > > > > removed if I believe the list of options allowed for DIO. > > > > > > > > Best, > > > > > > > > Mathilde > > > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > > > > Behalf Of *Mathilde Durvy (mdurvy) > > > > *Sent:* vendredi, 18. juin 2010 11:09 > > > > *To:* Philip Levis > > > > *Cc:* roll@ietf.org > > > > *Subject:* Re: [Roll] Transit information option > > > > > > > > Hi All, > > > > > > > > I just looked at the updated draft and most of the comments below > > have > > > > been addresses / clarified. Just a few rather minor points: > > > > > > > > - Section 5.7.7. RPL Target. Based on the discussion below I would > > > > change "A set of one or more Transit Information options MAY > > directly > > > > follow the Target option in a DAO message" to "a RPL Target Option > > in > > > > a unicast DAO MUST be followed by a set of one or more Transit > > > > Information Option ". > > > > > > > > - If the Path-Sequence / Control fields are indeed used both in > > > > storing (where I have doubts they are really needed) and non- > > storing > > > > mode, why not put them in the target option rather than in the > > transit option. > > > > This way we could maybe only use only the target option in storing > > > > mode and the target+transit option in non-storing mode. This would > > > > have the additional benefit of making the parent address mandatory > > in > > > > the transit information option and thus avoid a variable length > > option. > > > > > > > > Best, > > > > > > > > Mathilde > > > > > > > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > > > > *Sent:* vendredi, 11. juin 2010 18:10 > > > > *To:* Mathilde Durvy (mdurvy) > > > > *Cc:* roll@ietf.org > > > > *Subject:* Re: [Roll] Transit information option > > > > > > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > > > > > > Hi Phil, > > > > > > > > Thanks a lot for your answer. Here are my comments: > > > > > > > > A few items that might be worth clarifying in version 09: > > > > > > > > - "Transit Information options MAY directly follow the Target > > option" > > > > Is it really a MAY? If not included it means the path sequence / > > > > control / lifetime are not specified (which seems to contradict > > section > > > 7.1.4.2). > > > > > > > > In non-storing mode, it is definitely a MUST. Storing mode seems > > like > > > > it is a MUST as well... > > > > > > > > I think we all agree. > > > > > > > > - "A non-storing node that has more than one DAO parent MAY > include > > a > > > > Transit Information option for each DAO parent as part of the > > > > non-storing Destination Advertisement operation." Why would a node > > do > > > > that? If a node is sending a DAO for a specific target to e.g. 2 > > DAO > > > > parents (A and B) shouldn't he send one DAO with transit > > information > > A > > > > (i.e. parent address =3D A) to DAO parent A and another DAO with > > transit > > > > information B to DAO parent B? Otherwise how this would work over > > > > multiple hop? Maybe an example of DAO would help. > > > > > > > > - In section 7.1.5 point 2, I assume the node should add a transit > > > > information with its parent before passing the content of the > > received > > > > DAO. Also do the operation specified on the path control field in > > the > > > > previous section for storing node also apply in the non-storing > > case? > > > > > > > > These are good questions. Currently the draft is a bit unclear on > > > > whether > > > > > > > > 1) a DAO's transit option contains the full source route when it > > > > arrives at the DODAG Root, or > > > > > > > > 2) the DODAG Root receives just the last downward hops of each > > node, > > > > and stitches together source routes with this information. > > > > > > > > 1) seems like a much better idea to me. Note that if it's 2), then > > in > > > > non-storing mode node needs to send a DAO to just one DAO parent, > > and > > > > this DAO can contain the full set of last-hops. What are your > > thoughts? > > > > > > > > Indeed, I think the current draft is a bit unclear. My > > interpretation > > > > when reading was 1 (probably due mostly to the history of the > > draft). > > > > Now from your comments I understand what the draft is proposing, > > > > namely 2. Thanks for explaining. > > > > > > > > What triggered this change? > > > > > > > > It seems to me that if proper aggregation of the routes is > > performed > > > > (in particular if in the record route case you can avoid > > transmitting > > > > routes which are sub-routes of others) the two schemes could > > actually > > > > be quite similar in terms of overhead. This would need to be > > confirmed > > > > by a careful study as it could depend quite on bit on the > topology. > > > > What is quite clear is that 2 requires more processing power than > 1 > > as > > > > it needs to reassemble routes from the received information. > > > > > > > > Also concerning your last comment, I agree. The DAO produced will > > be > > > > slightly larger but we send only one DAO instead of one DAO per > DAO > > > > parent. I think if we do that we might not really need the path > > > > control field, correct? > > > > > > > > -09 has a rewrite of the Downward Routes section that should make > > all > > > > of this much clearer. The answer is 2), for reasons Richard > brought > > up > > > > a few months ago. In particular, if you use 1), then when a node > > > > changes its parent set it entire sub-DODAG must resend DAOs. This > > is > > a > > > > significant cost. If you use 2), then only that node needs to send > > a > > > > new DAO. > > > > > > > > - Has the advantage of having multiple DAO parents been assessed > > with > > > > respect to the added complexity? One could argue that since we > take > > so > > > > much care in selecting a preferred this should be a good enough > > > > choice... Similar to Phil I'm getting worried about the increased > > complexity. > > > > > > > > But note that in upward routes, there's a parent set. The concern > > is > > > > that the vagaries and unreliability of wireless links call for > > > > supporting some degree of path diversity. Most protocols today > > > > maintain multiple candidate next hops for this exact reason. > > Because > > > > downward routes start at the endpoints, there needs to be some way > > to > > > > establish multiple routes. Otherwise, when one link breaks and you > > > > have to issue a trigger to the entire sub-DODAG. > > > > > > > > I understand how this would work in the storing case but in the > > > > non-storing case how would you know at the root that the path > > failed? > > > > > > > > ICMP error. > > > > > > > > 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 yoav@yitran.com Tue Jul 20 00:22:36 2010 Return-Path: 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 5F8213A6BF0 for ; Tue, 20 Jul 2010 00:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wGcjwLQ3BZ5e for ; Tue, 20 Jul 2010 00:22:35 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id EB0353A6C14 for ; Tue, 20 Jul 2010 00:22:34 -0700 (PDT) Received: from source ([209.85.216.173]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTEVOyaDZwXH3WlaXf6xyAVCsATj8zeiD@postini.com; Tue, 20 Jul 2010 00:22:50 PDT Received: by qyk7 with SMTP id 7so2515867qyk.11 for ; Tue, 20 Jul 2010 00:22:49 -0700 (PDT) Received: by 10.224.60.133 with SMTP id p5mr5584093qah.331.1279610569062; Tue, 20 Jul 2010 00:22:49 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0257510F@XMB-AMS-107.cisco.com> 0827489c0d40521405cbb2c6c82440f4@mail.gmail.com In-Reply-To: 0827489c0d40521405cbb2c6c82440f4@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsnpjE4y0q8URMGQXmBnxvXIpMYKQAMfCPQAABdUKAAAJxDAA== Date: Tue, 20 Jul 2010 10:22:47 +0300 Message-ID: <1acf824ac4b4d694be79c3fd33f8c5f8@mail.gmail.com> To: Yoav Ben-Yehezkel , "Pascal Thubert (pthubert)" , Philip Levis , Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 07:22:36 -0000 Maybe even further clarification of (I'm not sure "shortcuts" is indeed true - it's more about good enough criteria and "reactive-ness" of routing formation): "... Additional on-demand reactive RPL route formation such as [non normative ref to Mukul's draft] can be used in complementary to the P2P method described above." -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Tuesday, July 20, 2010 10:08 AM To: 'Pascal Thubert (pthubert)'; 'Philip Levis'; 'Mukul Goyal' Cc: 'roll' Subject: RE: [Roll] Section 3.4 in RPL-10 Hi Pascal, I agree to this text, but there may be some ambiguity in the following para.: "... Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." One may understand that these optimizations cannot be used with RPL. May I suggest a slight modification to this - something in the lines of: "... Additional RPL route optimization such as [non normative ref to Mukul's draft] that may enable P2P packet travel shortcuts can be used in complementary to the P2P method described above." Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, July 20, 2010 10:00 AM To: Philip Levis; Mukul Goyal Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 This text troubles me a bit. There is a confusion between P2P in the sense of node to node (as opposed to P2MP and MP2P) and P2P in the sense of the optimization that Mukul, Jerry, Anders and others are working on. I'd like to separate the 2. We can indicate that additional P2P optimizations are on the works but with the main spec, the P2P goes up to the common parent and then down in storing, and up to the root and then down in non storing. Extending Phil's text: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination. Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Tuesday, July 20, 2010 2:45 AM > To: Mukul Goyal > Cc: roll > Subject: Re: [Roll] Section 3.4 in RPL-10 > > > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > > > Here is a quote from Section 3.4 of RPL-10 > > > > "Any given RPL Instance is either > > > > > > > > Winter, et al. Expires December 30, 2010 > > [Page 15] > > > > Internet-Draft draft-ietf-roll-rpl-10 Jun > > 2010 > > > > > > storing or non-storing. In both cases, P2P packets travel up to a > > DODAG Root then down to the final destination (unless the > > destination > > is on the upward route). > > " > > > > I dont think that a P2P packet necessarily always travels to the DODAG > > root in storing mode. It is possible that it turns around at a common > > non-root ancestor of the source and the destination. > > Mukul, > > You're right. I'd suggest removing the last sentence and replacing it > with: > > "In the case of a non-storing network, P2P packets travel up to a DODAG Root > then down to the final destination (unless the destination is on the upward path > to the DODAG Root). In the case of a storing network, P2P packets travel > upwards towards a DODAG Root until they reach a common ancestor with the > destination, at which point they travel down to the destination." > > What do you think? > > 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 prvs=8107c8147=mukul@uwm.edu Tue Jul 20 00:57:05 2010 Return-Path: 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 308F23A6890 for ; Tue, 20 Jul 2010 00:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 Y-hGiaev4mHy for ; Tue, 20 Jul 2010 00:57:03 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 484423A6843 for ; Tue, 20 Jul 2010 00:57:03 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 20 Jul 2010 02:57:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0679E2B3EF6; Tue, 20 Jul 2010 02:57:05 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6oVqRA5Rg8L; Tue, 20 Jul 2010 02:57:04 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id CCCCD2B3F03; Tue, 20 Jul 2010 02:57:04 -0500 (CDT) Date: Tue, 20 Jul 2010 02:57:18 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1785798412.124804.1279598975032.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 07:57:05 -0000 Hi Phil "...In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination." Not quite. Since the DAO parent set is just a subset of DODAG parent set, the first common ancestor (of source and destination) may not know about the destination. Some common ancestor would know but we dont know which one. Also, the packet may travel upwards in a manner that it does not reach the first common ancestor that does know about the destination. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Monday, July 19, 2010 7:45:15 PM Subject: Re: [Roll] Section 3.4 in RPL-10 On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > Here is a quote from Section 3.4 of RPL-10 > > "Any given RPL Instance is either > > > > Winter, et al. Expires December 30, 2010 > [Page 15] > > Internet-Draft draft-ietf-roll-rpl-10 Jun > 2010 > > > storing or non-storing. In both cases, P2P packets travel up to a > DODAG Root then down to the final destination (unless the > destination > is on the upward route). > " > > I dont think that a P2P packet necessarily always travels to the > DODAG root in storing mode. It is possible that it turns around at > a common non-root ancestor of the source and the destination. Mukul, You're right. I'd suggest removing the last sentence and replacing it with: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination." What do you think? Phil From prvs=8107c8147=mukul@uwm.edu Tue Jul 20 01:57:41 2010 Return-Path: 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 BA4513A6BFE for ; Tue, 20 Jul 2010 01:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 XkcokWaXuotf for ; Tue, 20 Jul 2010 01:57:40 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 5BB693A68AB for ; Tue, 20 Jul 2010 01:57:40 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 20 Jul 2010 03:57:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 3778A2B3EF6; Tue, 20 Jul 2010 03:57:42 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8-TlBClSh4a; Tue, 20 Jul 2010 03:57:41 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id DC0532B3F02; Tue, 20 Jul 2010 03:57:41 -0500 (CDT) Date: Tue, 20 Jul 2010 03:57:55 -0500 (CDT) From: Mukul Goyal To: Yoav Ben-Yehezkel Message-ID: <1835426049.125839.1279616275112.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1297904629.125834.1279616054719.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 08:57:41 -0000 I agree. Here is my own text for this: "... A reactive mechanism for P2P route discovery [non normative ref to Mukul's draft] can be used in addition to the P2P method described above." Also, the beginning paragraph of section 8, quoted below, has the same inaccuracy regarding the P2P operation: "This section describes how RPL discovers and maintains downward routes. RPL constructs and maintains downward routes with Destination Advertisement Object (DAO) messages. Downward routes support of P2MP flows, from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow to a DODAG Root through an upward route, then away from the DODAG Root to a destination through a downward route. " Thanks Mukul ----- Original Message ----- From: "Yoav Ben-Yehezkel" To: "Yoav Ben-Yehezkel" , "Pascal Thubert (pthubert)" , "Philip Levis" , "Mukul Goyal" Cc: "roll" Sent: Tuesday, July 20, 2010 2:22:47 AM Subject: RE: [Roll] Section 3.4 in RPL-10 Maybe even further clarification of (I'm not sure "shortcuts" is indeed true - it's more about good enough criteria and "reactive-ness" of routing formation): "... Additional on-demand reactive RPL route formation such as [non normative ref to Mukul's draft] can be used in complementary to the P2P method described above." -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Tuesday, July 20, 2010 10:08 AM To: 'Pascal Thubert (pthubert)'; 'Philip Levis'; 'Mukul Goyal' Cc: 'roll' Subject: RE: [Roll] Section 3.4 in RPL-10 Hi Pascal, I agree to this text, but there may be some ambiguity in the following para.: "... Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." One may understand that these optimizations cannot be used with RPL. May I suggest a slight modification to this - something in the lines of: "... Additional RPL route optimization such as [non normative ref to Mukul's draft] that may enable P2P packet travel shortcuts can be used in complementary to the P2P method described above." Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, July 20, 2010 10:00 AM To: Philip Levis; Mukul Goyal Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 This text troubles me a bit. There is a confusion between P2P in the sense of node to node (as opposed to P2MP and MP2P) and P2P in the sense of the optimization that Mukul, Jerry, Anders and others are working on. I'd like to separate the 2. We can indicate that additional P2P optimizations are on the works but with the main spec, the P2P goes up to the common parent and then down in storing, and up to the root and then down in non storing. Extending Phil's text: "In the case of a non-storing network, P2P packets travel up to a DODAG Root then down to the final destination (unless the destination is on the upward path to the DODAG Root). In the case of a storing network, P2P packets travel upwards towards a DODAG Root until they reach a common ancestor with the destination, at which point they travel down to the destination. Additional route optimization like [non normative ref to Mukul's draft] that may enable shortcuts are out of scope for this specification." Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Tuesday, July 20, 2010 2:45 AM > To: Mukul Goyal > Cc: roll > Subject: Re: [Roll] Section 3.4 in RPL-10 > > > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > > > Here is a quote from Section 3.4 of RPL-10 > > > > "Any given RPL Instance is either > > > > > > > > Winter, et al. Expires December 30, 2010 > > [Page 15] > > > > Internet-Draft draft-ietf-roll-rpl-10 Jun > > 2010 > > > > > > storing or non-storing. In both cases, P2P packets travel up to a > > DODAG Root then down to the final destination (unless the > > destination > > is on the upward route). > > " > > > > I dont think that a P2P packet necessarily always travels to the DODAG > > root in storing mode. It is possible that it turns around at a common > > non-root ancestor of the source and the destination. > > Mukul, > > You're right. I'd suggest removing the last sentence and replacing it > with: > > "In the case of a non-storing network, P2P packets travel up to a DODAG Root > then down to the final destination (unless the destination is on the upward path > to the DODAG Root). In the case of a storing network, P2P packets travel > upwards towards a DODAG Root until they reach a common ancestor with the > destination, at which point they travel down to the destination." > > What do you think? > > 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 pthubert@cisco.com Tue Jul 20 02:08:29 2010 Return-Path: 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 E4B453A6BFE for ; Tue, 20 Jul 2010 02:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9tiP9sYex2bl for ; Tue, 20 Jul 2010 02:08:22 -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 D653E3A68AB for ; Tue, 20 Jul 2010 02:08:20 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 09:08:35 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K98UBH016196; Tue, 20 Jul 2010 09:08:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:08:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 20 Jul 2010 11:08:31 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D025751C4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing on #67 DODAG Default Path Lifetime thread-index: Acsn6x8cjizvc0c9TS6huLdJOepmVQ== From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 20 Jul 2010 09:08:33.0785 (UTC) FILETIME=[21310690:01CB27EB] Subject: [Roll] Closing on #67 DODAG Default Path Lifetime 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: , X-List-Received-Date: Tue, 20 Jul 2010 09:08:30 -0000 RGVhciBXRzoNCg0KVGhlcmUgc2VlbSB0byBiZSBhIGNvbnNlbnN1cyBvbiBmb2xsb3dpbmcgUm9n ZXIncyBwcm9wb3NhbC4gSSBkbyBmYXZvciB0aGF0IGFzIHdlbGwuDQpXZSdsbCBub3QgdGhhdCB0 aGUgbGlmZXRpbWUgaXMgdXNlZCB0bzoNCi0gYWR2ZXJ0aXNlIG5vIHBhdGgNCi0gcmVtb3ZlIGEg c3RhbGUgcm91dGUgYmVmb3JlIHRoZSBwYXRoIHNlcXVlbmNlIGhhcyBpbmNyZW1lbnRlZCBieSAx Ni4NCg0KV2UnbGwgYWxzbyBub3RlIHRoYXQ6DQotIFNpbmNlICB0aGUgaW5jcmVtZW50IG1pZ2h0 IGFjY2VsZXJhdGUgYXQgc29tZSBzcGVjaWZpYyBvY2Nhc2lvbnMsIGl0IGlzIHN0aWxsIHNvbWV0 aW1lcyB1c2VmdWwgdG8gYWR2ZXJ0aXNlIGEgbGlmZXRpbWUgaW4gdGhlIHRyYW5zaXQuDQotIElu ZmVycmluZyBvbiB0aGUgcHVyZSBzaXplIG9mIHRoZSBvcHRpb24gaXMgYSBiaXQgZGFuZ2Vyb3Vz IHNpbmNlIHdlIGNhbiBoYXJkbHkgcGxheSBzdWNoIGEgZ2FtZSB0d2ljZS4gDQotIEFkYXB0aXZl IG1hcHBpbmcgY3JlYXRlcyBjb21wbGV4aXRpZXMgYW5kIGJ1Z3MNCi0gd2UgZGlzY3Vzc2VkIGZv ciAjNTYgdGhhdCAzIG9jdGV0cyBpcyBsYXJnZSBlbm91Z2ggZm9yIGEgbGlmZXRpbWUgaW4gc2Vj b25kcy4NCg0KU3VnZ2VzdGlvbjoNCg0KSW4gdGhlIGNvbmZpZyBvcHRpb24sIHdlIHBsYWNlIHRo ZSBsaWZldGltZSB1bml0ICgyIG9jdGV0cykgYW5kIHRoZSBkZWZhdWx0IHZhbHVlICgxIG9jdGV0 IGV4cHJlc3NlZCBpbiB0aGF0IHVuaXQpLiBUaGlzIGdpdmVzIHVzIGEgbGFyZ2UgYmFuZC4NClRo ZW4gaW4gdGhlIHRyYW5zaXQgb3B0aW9uLCB3ZSBwbGFjZSBvbmx5IG9uZSBvY3RldCwgZXhwcmVz c2VkIGluIHRoZSB1bml0IGFib3ZlLCBhbmQgdGhhdCBzaG91bGQgdXN1YWxseSBlY2hvIHRoZSBk ZWZhdWx0Lg0KDQpDYW4geW91IHBsZWFzZSBzaGltZSBpbiBpZiB0aGF0IHJlc29sdXRpb24gc3Vp dHMgeW91Pw0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIHJvbGwNCj4gaXNzdWUgdHJhY2tlcg0KPiBTZW50OiBUaHVyc2RheSwgSnVs eSAxNSwgMjAxMCA2OjM2IFBNDQo+IFRvOiB3aW50ZXJ0QGFjbS5vcmc7IGpwdkBjaXNjby5jb20N Cj4gQ2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1JvbGxdIFtyb2xsXSAjNjc6IERPREFH IERlZmF1bHQgUGF0aCBMaWZldGltZQ0KPiANCj4gIzY3OiBET0RBRyBEZWZhdWx0IFBhdGggTGlm ZXRpbWUNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Ky0tLS0NCj4gIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAgIHwgICAgICAgT3duZXI6ICB3 aW50ZXJ0QOKApg0KPiAgICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgIHwgICAgICBTdGF0dXM6 ICBuZXcNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiBD b21wb25lbnQ6ICBycGwgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+ICBTZXZlcml0eTog IEluIFdHIExhc3QgQ2FsbCAgfCAgICBLZXl3b3JkczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0NCj4gIEVtYWlsIHNlbnQgZnJvbSBSb2dl ciBKdWx5IDE0DQo+IA0KPiAgU3ViamVjdDogW1JvbGxdIERPREFHIERlZmF1bHQgUGF0aCBMaWZl dGltZQ0KPiAgRGF0ZTogV2VkLCAxNCBKdWwgMjAxMCAxNjowMjoyMCAtMDQwMA0KPiAgRnJvbTog QWxleGFuZGVyLCBSb2dlciA8Um9nZXIuQWxleGFuZGVyQGNvb3BlcmluZHVzdHJpZXMuY29tPg0K PiAgVG86IHJvbGwgPHJvbGxAaWV0Zi5vcmc+DQo+IA0KPiAgSGkgV0csDQo+IA0KPiAgSSB3b3Vs ZCBsaWtlIHRvIHJlY29tbWVuZCB1c2Ugb2YgYSBET0RBRy1kZWZpbmVkIERlZmF1bHQgUGF0aCBM aWZldGltZSAgYXMNCj4gb3Bwb3NlZCB0byB0aGUgY3VycmVudCBtb2RlbCBpbiB3aGljaCBQYXRo IExpZmV0aW1lIGlzIHNwZWNpZmllZCBwZXIgIHByZWZpeA0KPiB1c2luZyB0aGUgVHJhbnNpdCBJ bmZvcm1hdGlvbiBPcHRpb24uDQo+IA0KPiAgQXMgaW4gb3RoZXIgcm91dGluZyBwcm90b2NvbHMs IHN1Y2ggYXMgUklQIGZvciBleGFtcGxlLCB0aGUgdmFsaWRpdHkgIHBlcmlvZCBvZiBhbg0KPiBh ZHZlcnRpc2VkIHByZWZpeCBpcyBkZWZpbmVkIG5vdCBwZXIgZGVzdGluYXRpb24gYWRkcmVzcyAg YnV0IGlzIHNwZWNpZmllZCB0aHJvdWdoDQo+IGEgcHJvdG9jb2wgY29uZmlndXJhdGlvbiBlbGVt ZW50IHN1Y2ggYXMgdGhlICByb3V0ZS10aW1lb3V0IHRpbWVyLiBJbiB0aGUgc2FtZQ0KPiB2ZWlu LCBhIGRlZmF1bHQgdmFsaWRpdHkgcGVyaW9kIGNhbiBiZSAgZGVmaW5lZCBmb3IgYWxsIGFkdmVy dGlzZWQgZGVzdGluYXRpb25zDQo+IHRocm91Z2ggYSBEZWZhdWx0IFBhdGggTGlmZXRpbWUgIHNw ZWNpZmllZCB3aXRoaW4gdGhlIERPREFHIENvbmZpZ3VyYXRpb24NCj4gb3B0aW9uLiBUaGlzIGRl ZmF1bHQgdmFsdWUgd2lsbCAgYXBwbHkgdG8gYWxsIGFkdmVydGlzZWQgcHJlZml4ZXMgdW5sZXNz IG90aGVyd2lzZQ0KPiBzcGVjaWZpZWQgdXNpbmcgYW4gIG9wdGlvbmFsIFBhdGggTGlmZXRpbWUg aW5mb3JtYXRpb24gZWxlbWVudCB3aXRoaW4gdGhlDQo+IFRyYW5zaXQgIEluZm9ybWF0aW9uIG9w dGlvbi4gVGhlIGJlbmVmaXQgb2YgYSBEZWZhdWx0IFBhdGggTGlmZXRpbWUgaXMgdGhhdCBpdCAg d2lsbA0KPiBhbGxvdyA0LWJ5dGVzIHRvIGJlIHNhdmVkIHBlciBhZHZlcnRpc2VkIERBTyBkZXN0 aW5hdGlvbiB1bmxlc3MgYSAgc3BlY2lmaWMsDQo+IGRlZGljYXRlZCBQYXRoIExpZmV0aW1lIGlz IG5lZWRlZCBmb3IgYSBnaXZlbiBwcmVmaXguIFRoZSAgTGlmZXRpbWUgZm9yIGENCj4gZGVzdGlu YXRpb24gYWRkcmVzcyB3aWxsIGNvbnRpbnVlIHRvIGFwcGx5IGZyb20gdGhlIHRpbWUgIG9mIHJl Y2VpcHQgYXQgYSBub2RlLg0KPiANCj4gIE5vIGFkZGl0aW9uYWwgY29udHJvbCBiaXRzIHdpbGwg YmUgcmVxdWlyZWQgd2l0aGluIHRoZSBUcmFuc2l0ICBJbmZvcm1hdGlvbg0KPiBPcHRpb24gYXMg dGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhlIFBhdGggTGlmZXRpbWUgIGluZm9ybWF0aW9u IGVsZW1lbnQNCj4gY2FuIGJlIGRpcmVjdGx5IGRlZHVjZWQgZnJvbSB0aGUgdmFsdWUgb2YgdGhl IE9wdGlvbiAgTGVuZ3RoLg0KPiANCj4gIFRoYW5rcy4NCj4gDQo+ICBSb2dlcg0KPiANCj4gLS0N Cj4gVGlja2V0IFVSTDogPGh0dHBzOi8vc3ZuLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90 aWNrZXQvNjc+DQo+IHJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwg bWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsDQo= From prvs=8107c8147=mukul@uwm.edu Tue Jul 20 02:25:11 2010 Return-Path: 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 D94C43A6C36 for ; Tue, 20 Jul 2010 02:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 CtLP5J49jlF1 for ; Tue, 20 Jul 2010 02:25:11 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 184E23A6A10 for ; Tue, 20 Jul 2010 02:25:10 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 20 Jul 2010 04:25:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id B07C32B3EF6; Tue, 20 Jul 2010 04:25:12 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hQX2F327s8S; Tue, 20 Jul 2010 04:25:12 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8CCA02B3F02; Tue, 20 Jul 2010 04:25:12 -0500 (CDT) Date: Tue, 20 Jul 2010 04:25:25 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] determining downward routes at the root 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: , X-List-Received-Date: Tue, 20 Jul 2010 09:25:12 -0000 I was wondering if it makes sense to add some text to the RPL draft regarding how does a root, in non-storing LLN, determine the _shortest_ downward routes to different destinations using the "path control" values as the (inverse) link costs. Thanks Mukul From jpv@cisco.com Tue Jul 20 02:43:16 2010 Return-Path: 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 BE3973A6C1C for ; Tue, 20 Jul 2010 02:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 KLnQguArRyrw for ; Tue, 20 Jul 2010 02:43:15 -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 EE2A63A6452 for ; Tue, 20 Jul 2010 02:43:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIMMRUxAZnwN/2dsb2JhbACfbnGlGpsthTIEiFmCNQ Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 09:43:29 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9hLqD009493; Tue, 20 Jul 2010 09:43:29 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:43:28 +0200 Received: from [192.168.3.55] ([10.61.107.218]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:43:27 +0200 Message-Id: From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <1acf824ac4b4d694be79c3fd33f8c5f8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 11:43:25 +0200 References: <1775805837.109690.1279565738694.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0257510F@XMB-AMS-107.cisco.com> 0827489c0d40521405cbb2c6c82440f4@mail.gmail.com <1acf824ac4b4d694be79c3fd33f8c5f8@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 09:43:27.0397 (UTC) FILETIME=[0114DD50:01CB27F0] Cc: roll Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 09:43:17 -0000 On Jul 20, 2010, at 9:22 AM, Yoav Ben-Yehezkel wrote: > Maybe even further clarification of (I'm not sure "shortcuts" is > indeed > true - it's more about good enough criteria and "reactive-ness" of > routing > formation): > "... Additional on-demand reactive RPL route formation such as [non > normative ref to Mukul's draft] can be used in complementary to the > P2P > method described above." We do not need to reference other in progress work. Just specify what the core specification does. > > > -----Original Message----- > From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] > Sent: Tuesday, July 20, 2010 10:08 AM > To: 'Pascal Thubert (pthubert)'; 'Philip Levis'; 'Mukul Goyal' > Cc: 'roll' > Subject: RE: [Roll] Section 3.4 in RPL-10 > > Hi Pascal, > > I agree to this text, but there may be some ambiguity in the following > para.: > "... Additional route optimization like [non normative ref to Mukul's > draft] that may enable shortcuts are out of scope for this > specification." > > One may understand that these optimizations cannot be used with RPL. > > May I suggest a slight modification to this - something in the lines > of: > "... Additional RPL route optimization such as [non normative ref to > Mukul's draft] that may enable P2P packet travel shortcuts can be > used in > complementary to the P2P method described above." > > Best regards, > Yoav > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Pascal Thubert (pthubert) > Sent: Tuesday, July 20, 2010 10:00 AM > To: Philip Levis; Mukul Goyal > Cc: roll > Subject: Re: [Roll] Section 3.4 in RPL-10 > > This text troubles me a bit. > > There is a confusion between P2P in the sense of node to node (as > opposed to P2MP and MP2P) and P2P in the sense of the optimization > that > Mukul, Jerry, Anders and others are working on. I'd like to separate > the > 2. We can indicate that additional P2P optimizations are on the works > but with the main spec, the P2P goes up to the common parent and then > down in storing, and up to the root and then down in non storing. > Extending Phil's text: > > "In the case of a non-storing network, P2P packets travel up to a > DODAG > Root then down to the final destination (unless the destination is on > the upward path to the DODAG Root). In the case of a storing network, > P2P packets travel upwards towards a DODAG Root until they reach a > common ancestor with the destination, at which point they travel > down to > the destination. Additional route optimization like [non normative ref > to Mukul's draft] that may enable shortcuts are out of scope for this > specification." > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Philip >> Levis >> Sent: Tuesday, July 20, 2010 2:45 AM >> To: Mukul Goyal >> Cc: roll >> Subject: Re: [Roll] Section 3.4 in RPL-10 >> >> >> On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: >> >>> Here is a quote from Section 3.4 of RPL-10 >>> >>> "Any given RPL Instance is either >>> >>> >>> >>> Winter, et al. Expires December 30, 2010 >>> [Page 15] >>> >>> Internet-Draft draft-ietf-roll-rpl-10 Jun >>> 2010 >>> >>> >>> storing or non-storing. In both cases, P2P packets travel up to > a >>> DODAG Root then down to the final destination (unless the >>> destination >>> is on the upward route). >>> " >>> >>> I dont think that a P2P packet necessarily always travels to the > DODAG >>> root in storing mode. It is possible that it turns around at a > common >>> non-root ancestor of the source and the destination. >> >> Mukul, >> >> You're right. I'd suggest removing the last sentence and replacing it >> with: >> >> "In the case of a non-storing network, P2P packets travel up to a > DODAG Root >> then down to the final destination (unless the destination is on the > upward path >> to the DODAG Root). In the case of a storing network, P2P packets > travel >> upwards towards a DODAG Root until they reach a common ancestor with > the >> destination, at which point they travel down to the destination." >> >> What do you think? >> >> 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 jpv@cisco.com Tue Jul 20 02:44:23 2010 Return-Path: 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 446D43A69DF for ; Tue, 20 Jul 2010 02:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 z+H2PrpPfRD8 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6168E3A6452 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEYMRUyrR7Ht/2dsb2JhbACfbnGlGpsshTIEiFmCNYcP Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 09:44:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9iL1P026616; Tue, 20 Jul 2010 09:44:37 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Received: from [192.168.3.55] ([10.61.107.218]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal , Philip Levis In-Reply-To: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 11:44:27 +0200 References: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 09:44:29.0326 (UTC) FILETIME=[25FE7AE0:01CB27F0] Cc: roll WG Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Tue, 20 Jul 2010 09:44:23 -0000 Hi Phil and Mukul, On Jul 20, 2010, at 9:57 AM, Mukul Goyal wrote: > Hi Phil > > "...In the case of a storing > network, P2P packets travel upwards towards a DODAG Root until they > reach a common ancestor with the destination, at which point they > travel down to the destination." > > Not quite. Since the DAO parent set is just a subset of DODAG parent > set, the first common ancestor (of source and destination) may not > know about the destination. Some common ancestor would know but we > dont know which one. We'll make it clearer. Note that there are many other clarifications to be done in Ticket #70. > > Also, the packet may travel upwards in a manner that it does not > reach the first common ancestor that does know about the destination. > JP. > Thanks > Mukul > > > > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" > Sent: Monday, July 19, 2010 7:45:15 PM > Subject: Re: [Roll] Section 3.4 in RPL-10 > > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > >> Here is a quote from Section 3.4 of RPL-10 >> >> "Any given RPL Instance is either >> >> >> >> Winter, et al. Expires December 30, 2010 >> [Page 15] >> >> Internet-Draft draft-ietf-roll-rpl-10 Jun >> 2010 >> >> >> storing or non-storing. In both cases, P2P packets travel up to a >> DODAG Root then down to the final destination (unless the >> destination >> is on the upward route). >> " >> >> I dont think that a P2P packet necessarily always travels to the >> DODAG root in storing mode. It is possible that it turns around at >> a common non-root ancestor of the source and the destination. > > Mukul, > > You're right. I'd suggest removing the last sentence and replacing it > with: > > "In the case of a non-storing network, P2P packets travel up to a > DODAG Root then down to the final destination (unless the destination > is on the upward path to the DODAG Root). In the case of a storing > network, P2P packets travel upwards towards a DODAG Root until they > reach a common ancestor with the destination, at which point they > travel down to the destination." > > What do you think? > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jul 20 04:26:08 2010 Return-Path: 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 0B2103A67B5 for ; Tue, 20 Jul 2010 04:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pJC28v5Z4Jpv for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 426153A688E for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB8lRUyrRN+K/2dsb2JhbACfb3GkdJswhTIEiw6HDw Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 11:26:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQEts000369; Tue, 20 Jul 2010 11:26:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:26:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 13:26:00 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> In-Reply-To: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] determining downward routes at the root thread-index: Acsn7YE0s6sQ0MIeS+uyprxTvkf+VwAEDwMA References: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu> <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 20 Jul 2010 11:26:04.0613 (UTC) FILETIME=[57117750:01CB27FE] Subject: Re: [Roll] determining downward routes at the root 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: , X-List-Received-Date: Tue, 20 Jul 2010 11:26:08 -0000 Hi Mukul: This is a pretty classical recursive route lookup. Only the highest preference 1hop route should show up so recursively the root will quite naturally build the source route header. Routing protocols usually do not describe such operation.=20 Do you think there is a risk of misinterpretation?=20 Would someone else please shime in? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, July 20, 2010 11:25 AM > To: roll > Subject: [Roll] determining downward routes at the root >=20 > I was wondering if it makes sense to add some text to the RPL draft regarding > how does a root, in non-storing LLN, determine the _shortest_ downward > routes to different destinations using the "path control" values as the (inverse) > link costs. >=20 > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Tue Jul 20 04:46:18 2010 Return-Path: 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 9A2B73A6835 for ; Tue, 20 Jul 2010 04:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 ccgKKENkJ-39 for ; Tue, 20 Jul 2010 04:46:17 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 776B13A69E3 for ; Tue, 20 Jul 2010 04:46:17 -0700 (PDT) Received: from source ([209.85.212.49]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTEWMl/Ye41/98hYbX5/BnYZ5JUbEvFDp@postini.com; Tue, 20 Jul 2010 04:46:33 PDT Received: by mail-vw0-f49.google.com with SMTP id 8so6613634vws.36 for ; Tue, 20 Jul 2010 04:46:29 -0700 (PDT) Received: by 10.224.65.147 with SMTP id j19mr5785427qai.189.1279626389168; Tue, 20 Jul 2010 04:46:29 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsoAS8NiBKaleRrRdurW9dUWH3V+A== Date: Tue, 20 Jul 2010 14:46:26 +0300 Message-ID: <3a9969c91b0b37f5c4c64305397a14aa@mail.gmail.com> To: roll Content-Type: multipart/alternative; boundary=00c09f88cf8c5f499d048bd03c7c Subject: [Roll] RPLInstanceID term clarification 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: , X-List-Received-Date: Tue, 20 Jul 2010 11:46:18 -0000 --00c09f88cf8c5f499d048bd03c7c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Question on the following term: =93RPLInstanceID: A unique identifier within a network. Two DODAGs with t= he same RPLInstanceID share the same Objective Function.=93 Is it really limited to two DODAGs? Suggest to remove the word =93Two=94 if= not. Regards, Yoav --00c09f88cf8c5f499d048bd03c7c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Question on the following term:

=A0

=93RPLInstanceID:=A0 A unique identifier within a network.=A0 Two DODAGs with the same RPLInstanceID share the same Objective Function.=93

=A0

Is it really limited to two DODAGs? Suggest to remov= e the word =93Two=94 if not.

=A0

Regards,

Yoav

=A0

--00c09f88cf8c5f499d048bd03c7c-- From jpv@cisco.com Tue Jul 20 06:06:21 2010 Return-Path: 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 DE10D3A6B09 for ; Tue, 20 Jul 2010 06:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yeRFrcsAWAf4 for ; Tue, 20 Jul 2010 06:06:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1D6043A6874 for ; Tue, 20 Jul 2010 06:06:10 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABc8RUyrR7Hu/2dsb2JhbACfb3GlFpsrhTIEiFmCNQ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 13:06:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KD6FPi015134; Tue, 20 Jul 2010 13:06:24 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 15:06:16 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 15:06:15 +0200 Message-Id: <350547E3-0A61-422D-93E1-C3EF29539B5F@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D025751C4@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 15:06:14 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D025751C4@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 13:06:16.0064 (UTC) FILETIME=[562C1800:01CB280C] Cc: roll@ietf.org Subject: Re: [Roll] Closing on #67 DODAG Default Path Lifetime 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: , X-List-Received-Date: Tue, 20 Jul 2010 13:06:21 -0000 Thanks. I'll close the ticket with that text unless someone objects. In rev-11, please add a few sentence to add a bit more of explanation =20= for first time reader. Thanks. JP. On Jul 20, 2010, at 11:08 AM, Pascal Thubert (pthubert) wrote: > Dear WG: > > There seem to be a consensus on following Roger's proposal. I do =20 > favor that as well. > We'll not that the lifetime is used to: > - advertise no path > - remove a stale route before the path sequence has incremented by 16. > > We'll also note that: > - Since the increment might accelerate at some specific occasions, =20= > it is still sometimes useful to advertise a lifetime in the transit. > - Inferring on the pure size of the option is a bit dangerous since =20= > we can hardly play such a game twice. > - Adaptive mapping creates complexities and bugs > - we discussed for #56 that 3 octets is large enough for a lifetime =20= > in seconds. > > Suggestion: > > In the config option, we place the lifetime unit (2 octets) and the =20= > default value (1 octet expressed in that unit). This gives us a =20 > large band. > Then in the transit option, we place only one octet, expressed in =20 > the unit above, and that should usually echo the default. > > Can you please shime in if that resolution suits you? > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Thursday, July 15, 2010 6:36 PM >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #67: DODAG Default Path Lifetime >> >> #67: DODAG Default Path Lifetime >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Email sent from Roger July 14 >> >> Subject: [Roll] DODAG Default Path Lifetime >> Date: Wed, 14 Jul 2010 16:02:20 -0400 >> From: Alexander, Roger >> To: roll >> >> Hi WG, >> >> I would like to recommend use of a DODAG-defined Default Path =20 >> Lifetime as >> opposed to the current model in which Path Lifetime is specified =20 >> per prefix >> using the Transit Information Option. >> >> As in other routing protocols, such as RIP for example, the =20 >> validity period of an >> advertised prefix is defined not per destination address but is =20 >> specified through >> a protocol configuration element such as the route-timeout timer. =20= >> In the same >> vein, a default validity period can be defined for all advertised =20= >> destinations >> through a Default Path Lifetime specified within the DODAG =20 >> Configuration >> option. This default value will apply to all advertised prefixes =20 >> unless otherwise >> specified using an optional Path Lifetime information element =20 >> within the >> Transit Information option. The benefit of a Default Path Lifetime =20= >> is that it will >> allow 4-bytes to be saved per advertised DAO destination unless a =20= >> specific, >> dedicated Path Lifetime is needed for a given prefix. The Lifetime =20= >> for a >> destination address will continue to apply from the time of =20 >> receipt at a node. >> >> No additional control bits will be required within the Transit =20 >> Information >> Option as the presence or absence of the Path Lifetime information =20= >> element >> can be directly deduced from the value of the Option Length. >> >> Thanks. >> >> Roger >> >> -- >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Jul 20 06:02:48 2010 Return-Path: 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 AFE773A6A25 for ; Tue, 20 Jul 2010 06:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 A-Yw5X50nqTt for ; Tue, 20 Jul 2010 06:02:46 -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 5FCDE3A6BB2 for ; Tue, 20 Jul 2010 06:02:41 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAGQ7RUxAZnwN/2dsb2JhbACBQ54scaUXmyuFMgSIWYI1 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 13:02:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KD2sCV011331 for ; Tue, 20 Jul 2010 13:02:55 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 15:02:54 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 15:02:47 +0200 Message-Id: From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-57-676055681 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 15:02:46 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 13:02:47.0369 (UTC) FILETIME=[D9C7C390:01CB280B] X-Mailman-Approved-At: Tue, 20 Jul 2010 06:06:24 -0700 Cc: roll@ietf.org Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Tue, 20 Jul 2010 13:02:49 -0000 --Apple-Mail-57-676055681 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Mathilde, On Jul 19, 2010, at 9:35 AM, Mathilde Durvy (mdurvy) wrote: > Hi JP, > > Thanks for updating Section 16. A few minor points below. Sure, in line. > Best, > Mathilde > > > - In 16.2.3, 16.2.4 It is not very clear which parameters are =20 > configured versus negotiated dynamically through messages. > All the parameters are the ones that a RPL MAY/SHOULD/MUST allow for =20= > configuration only. I will add some text to clarify. > [Mathilde] I'm not sure what you mean by 'configuration only'. Do =20 > you mean not negotiated dynamically? Right. > Then it seems to me that parameters that are part of the policy must =20= > be configured while other may be. For some parameters (OCP, Route =20 > information, DODAGID, MOP) it is still not specified in which =20 > category (may, should, must) they belong JP> I see what you're referring to; a sentence was missing in 16.2.3 =20 and 16.2.4. Added. > > - In 16.2.4 =93A RPL implementation SHOULD allow configuring whether a = =20 > non-storing node provides the transit information in DAO messages.=94 =20= > Shouldn=92t a node always include the transit info in DAO messages? > Correct, what I meant was the requirement to configure the MOP (this =20= > was already in 16.2.5), which implies to send transit information =20 > for non storing mode, but this was not clear indeed. I removed it =20 > from there. By the way, I added the Route information and Prefix =20 > information that were missing. > [Mathilde] Shouldn't Route information and Prefix information be in =20= > 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a =20 > problem :-) ). JP> Yes ! Done. > I would also add some text on what it means to configure the target =20= > prefix. This is not very clear to me. Do you mean decide which of =20 > the node's addresses / prefixes should be in a target option? > JP> Yes. I prefer to leave it as is, since the target option may be =20 augmented in the future. > Aren=92t the 2 first bullet related to the DAO mechanism and hence =20 > more appropriate in Section 16.2.6 (or maybe we should just remove =20 > Section 16.2.6) > Yes I updated 16.2.6, which was outdated after we removed the DAO =20 > FSM. Thanks. > [Mathilde] Thanks. Maybe 16.2.4 Target option should also go there > > - In general, Sections 16.3 to 16.5 can be difficult to implement on =20= > constrained nodes without interface or file system. I would =20 > emphasize that it is expected that constrained nodes do not =20 > implement these parts. > > Not sure is you saw it, but there is already pretty explicit text in =20= > Section 16.1: > When memory is highly constrained, it may > not be possible to satisfy all the requirements listed in this > section. > [Mathilde] Well the =91may=92 is a bit weak in my opinion. But I'm OK = to =20 > keep it as is. > > Attached the changes. Let me know if you agree with the proposed =20 > resolution and I'll close the ticket. > [Mathilde] I think once we implement the minor changes above we can =20= > close the ticket. Here is the new version. Let me know what you think. Cheers. JP. --Apple-Mail-57-676055681 Content-Type: multipart/mixed; boundary=Apple-Mail-58-676055682 --Apple-Mail-58-676055682 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi = Mathilde,

On Jul 19, 2010, at 9:35 AM, Mathilde Durvy = (mdurvy) wrote:

Hi JP,
 
Best,
- In 16.2.3, 16.2.4 It is not very clear which = parameters are configured versus negotiated dynamically through = messages.
All the parameters are the ones that a RPL MAY/SHOULD/MUST = allow for configuration = only. I will add some text to = clarify.
[Mathilde] I'm not sure what you mean by 'configuration only'. = Do you mean not negotiated dynamically? =

Right.

Then it seems = to me that parameters that are part of the policy must be configured = while other may be. For some parameters (OCP, Route information, = DODAGID, MOP) it is still not specified in which category (may, should, = must) they = belong
JP> I see what you're referring to; a sentence was = missing in 16.2.3 and 16.2.4. Added.


- In 16.2.4 =93A = RPL implementation SHOULD allow configuring whether a non-storing node = provides the transit information in DAO messages.=94 Shouldn=92t a node = always include the transit info in DAO messages?Correct, what = I meant was the requirement to configure the MOP (this was already in = 16.2.5), which implies to send transit information for non storing mode, = but this was not clear indeed. I removed it from there. By the way, I = added the Route information and Prefix information that were = missing.
[Mathilde] Shouldn't = Route information and Prefix information be in 16.2.3 (right now they = are also in 16.2.4 and 16.2.5, so we have a problem :-) ). =  
=
JP> Yes ! Done.

I would also add some text on what it = means to configure the target prefix. This is not very clear to me. Do = you mean decide which of the node's addresses / prefixes should be in a = target = option?


JP> Yes. I prefer to leave it as is, since = the target option may be augmented in the future.

Aren=92t the 2 = first bullet related to the DAO mechanism and hence more appropriate in = Section 16.2.6 (or maybe we should just remove Section = 16.2.6)
Yes I updated 16.2.6, which was outdated after we removed the = DAO FSM. Thanks.
[Mathilde] Thanks. Maybe 16.2.4 Target option should also go = there

- In general, = Sections 16.3 to 16.5 can be difficult to implement on constrained nodes = without interface or file system. I would emphasize that it is expected = that constrained nodes do not implement these = parts.
Not sure is you saw it, = but there is already pretty explicit text in Section 16.1:
   When memory is highly =
constrained, it may
   not be possible to =
satisfy all the requirements listed in this
[Mathilde] Well the =
=91may=92 is a bit weak in my opinion. But I'm OK to keep it as =
is.
Attached the =
changes. Let me know if you agree with the proposed resolution and I'll =
close the ticket.
--Apple-Mail-58-676055682-- --Apple-Mail-57-676055681-- From trac@tools.ietf.org Tue Jul 20 06:08:51 2010 Return-Path: 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 63E453A69EF for ; Tue, 20 Jul 2010 06:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3cCgh8r9XA21 for ; Tue, 20 Jul 2010 06:08:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 614663A6BB2 for ; Tue, 20 Jul 2010 06:08:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ObCYi-0002ds-Pa; Tue, 20 Jul 2010 06:08:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 20 Jul 2010 13:08:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/67#comment:1 Message-ID: <064.ffa0fe20630297838ee0e971f2a660b3@tools.ietf.org> References: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #67: DODAG Default Path Lifetime X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 13:08:51 -0000 #67: DODAG Default Path Lifetime -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Email From Pascal Thubert - July 20 Dear WG: There seem to be a consensus on following Roger's proposal. I do favor that as well. We'll not that the lifetime is used to: - advertise no path - remove a stale route before the path sequence has incremented by 16. We'll also note that: - Since the increment might accelerate at some specific occasions, it is still sometimes useful to advertise a lifetime in the transit. - Inferring on the pure size of the option is a bit dangerous since we can hardly play such a game twice. - Adaptive mapping creates complexities and bugs - we discussed for #56 that 3 octets is large enough for a lifetime in seconds. Suggestion: In the config option, we place the lifetime unit (2 octets) and the default value (1 octet expressed in that unit). This gives us a large band. Then in the transit option, we place only one octet, expressed in the unit above, and that should usually echo the default. Can you please shime in if that resolution suits you? Pascal -- Ticket URL: roll From jpv@cisco.com Tue Jul 20 07:53:44 2010 Return-Path: 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 D403D3A69FA for ; Tue, 20 Jul 2010 07:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Snji6cg4HuDZ for ; Tue, 20 Jul 2010 07:53:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 692783A6981 for ; Tue, 20 Jul 2010 07:53:42 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN9VRUyrR7H+/2dsb2JhbACBQ54qcaVcmy2FMgSIWYI1 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 14:53:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KErrEq027830 for ; Tue, 20 Jul 2010 14:53:53 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 16:53:41 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 16:53:33 +0200 Message-Id: From: JP Vasseur To: "Mathilde Durvy (mdurvy)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-74-682593163 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 16:51:43 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 14:53:33.0206 (UTC) FILETIME=[53020360:01CB281B] X-Mailman-Approved-At: Tue, 20 Jul 2010 07:54:38 -0700 Cc: roll WG Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Tue, 20 Jul 2010 14:53:44 -0000 --Apple-Mail-74-682593163 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Just had a quick discussion with Mathilde to clarify a few things. =20 Mathilde, here is the new version. Let me know if we are in sync. Cheers. JP. On Jul 20, 2010, at 3:02 PM, JP Vasseur wrote: > Hi Mathilde, > > On Jul 19, 2010, at 9:35 AM, Mathilde Durvy (mdurvy) wrote: > >> Hi JP, >> >> Thanks for updating Section 16. A few minor points below. > > Sure, in line. > >> Best, >> Mathilde >> >> >> - In 16.2.3, 16.2.4 It is not very clear which parameters are =20 >> configured versus negotiated dynamically through messages. >> All the parameters are the ones that a RPL MAY/SHOULD/MUST allow =20 >> for configuration only. I will add some text to clarify. >> [Mathilde] I'm not sure what you mean by 'configuration only'. Do =20 >> you mean not negotiated dynamically? > > Right. > >> Then it seems to me that parameters that are part of the policy =20 >> must be configured while other may be. For some parameters (OCP, =20 >> Route information, DODAGID, MOP) it is still not specified in which =20= >> category (may, should, must) they belong > > JP> I see what you're referring to; a sentence was missing in 16.2.3 =20= > and 16.2.4. Added. > >> >> - In 16.2.4 =93A RPL implementation SHOULD allow configuring whether =20= >> a non-storing node provides the transit information in DAO =20 >> messages.=94 Shouldn=92t a node always include the transit info in = DAO =20 >> messages? >> Correct, what I meant was the requirement to configure the MOP =20 >> (this was already in 16.2.5), which implies to send transit =20 >> information for non storing mode, but this was not clear indeed. I =20= >> removed it from there. By the way, I added the Route information =20 >> and Prefix information that were missing. >> [Mathilde] Shouldn't Route information and Prefix information be in =20= >> 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a =20= >> problem :-) ). > > JP> Yes ! Done. > >> I would also add some text on what it means to configure the target =20= >> prefix. This is not very clear to me. Do you mean decide which of =20 >> the node's addresses / prefixes should be in a target option? >> > > JP> Yes. I prefer to leave it as is, since the target option may be =20= > augmented in the future. > >> Aren=92t the 2 first bullet related to the DAO mechanism and hence =20= >> more appropriate in Section 16.2.6 (or maybe we should just remove =20= >> Section 16.2.6) >> Yes I updated 16.2.6, which was outdated after we removed the DAO =20 >> FSM. Thanks. >> [Mathilde] Thanks. Maybe 16.2.4 Target option should also go there >> >> - In general, Sections 16.3 to 16.5 can be difficult to implement =20 >> on constrained nodes without interface or file system. I would =20 >> emphasize that it is expected that constrained nodes do not =20 >> implement these parts. >> >> Not sure is you saw it, but there is already pretty explicit text =20 >> in Section 16.1: >> When memory is highly constrained, it may >> not be possible to satisfy all the requirements listed in this >> section. >> [Mathilde] Well the =91may=92 is a bit weak in my opinion. But I'm OK = =20 >> to keep it as is. >> >> Attached the changes. Let me know if you agree with the proposed =20 >> resolution and I'll close the ticket. >> [Mathilde] I think once we implement the minor changes above we can =20= >> close the ticket. > > Here is the new version. Let me know what you think. > > Cheers. > > JP. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-74-682593163 Content-Type: multipart/mixed; boundary=Apple-Mail-75-682593164 --Apple-Mail-75-682593164 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Just had a quick discussion with Mathilde to clarify a few things. Mathilde, here is the new version.
Let me know if we are in sync.

Cheers.

JP.

--Apple-Mail-75-682593164 Content-Disposition: inline; filename=section-16-for-RPL-rev-11.pdf Content-Type: application/pdf; x-mac-hide-extension=yes; x-unix-mode=0644; name="section-16-for-RPL-rev-11.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnVu33MQRhd/1K7TyNF7LCN0veQPHZJFgx7HPWjwAD2Ag kGBuhhD+fUqtr3tm62g0LY0PPvAgS9OX6qpdu6ov0vkp/Wf6U9pn9ZAWdZ21VVoPVdb2aVv1Wd+n P3+Vfpx+n7776HWRvnyd5u7/1y+tTp4VQ9Xm+fToeNfVWVXUeZ92ZZ319VAmL1+l79+kdeHqcrl5 lb77QZHlaZHefJ1+kh6KB+k7Q3pop0tmlzo9pHJ58iB5p7Cnn09lvp8u3P1ruvtKHn4x3X1rF6v3 3XRxd8nhl+nu96kIPT2yu6JMDz9MT+nitd316YFmvpx+o6efTagmyESjlLzVymfpzd/Sxzem81Wt J9u1XgyNKbsYgtZTp/VkTeujem/+HSGPQ0GyEwVFkzVNW0/yKAoSRcE2eRSVSZ5GojJvs7Kt2iV5 Ui9P4lGpAOTuZgRJnh6+ESDwI3AEAa+ALD8CiK+t4hHdYIbWqAjkqOfukgOQe2nVDY5rWKPeYmO/ mEzWO7JQEvehwn+XRka3c1AnK66RRroGQixKpupBBVR4ZXKeYYTksJERgkKNEcRPkzfJjlWZG9dW ZdqBwwh2jPaLHbwR2Lod2mzojLYv84axNfrXyyK6n48eYIz6bDRVkR4+mqD10C5HF1BGh2BpHL9w jSeH38ZmrDl+fM7trHV+9YVBNfzvLolvgRChuGIkP06yBqZfgPNXNjwLWyoy/RE9EIYxcocauDx1 w0gOmV2PWqHoKt3AE+qbP05CLY4pjntOHCB5s+lBVXRZNzRF6gF3bxyg77K2A/+rceoc/rEFaj/D 0g4uiowzLO2gABKBgpr5+8nMdEsr8+zEYZbqa1T6tTV2jAqnrhJCxcydGAQ0SxcO5ckBmdSBVCMU od4id/joqfTA3UZ6nyd8f56x/IYc2HKNC9lGaWTalWWTtudBNUs2okn+mpTc8J1VfROZkmMavSxC EFIBgljm14k9f7aLJMgn3LI29dgRzIqizerWgqsfZ1wwQ2wgCKwfChX7ROOHyeUoQ0XcivqMl9/U SbRRXA48oy48jzbRve/+vCOE5NAXhYXon+a0f1rDosGwjqGQRqtHjEkl/PJBEmntHaguh8FmqJb+ eWvfm0jSDlnZL84wZjOec5FEeRNE4WQBZm7e6c2teseWsQlAsjyVQQq6p18FewCNm7x/N8UQQKto 4SHw5jeYghRPMY+rreUrOj7k1PCL1D6SeHWpdxAz0SFiICIN4AguaIXckRBGYyr+3FqOBCli48Ut kgsrATvcoiqbrC7zNm0nGN4br2iGbBhnPvsnGIuI+mQC3XPj63Fi8MF4tcn5I+4bu1qC3k2XfLqw yvSZ3VnOk92lOYoqz/q8NpZi/PfHHnnW5TkLM29/oaiti6zOu0jaXFwu5KHZ8/Ys6sPpITkzjqjU Bg0Q+qC2c2wwOnByeSlvhwMX48rrkHep18i9QUxVZkVRxywRbMtmdy4ttmWZ9SWEsmvG9sRAMa4f QfLwuRL55jhEOPiftW3EA2eFpt0sS4lMZ1AA9fEomq2X3IxX4zPPa5IRJjFr4csxTwf52kj0uKSo yYRGR1yGhwwLoajHkjh64LcXjId+aWbR13joioS8lmawlEXXHYllEreDUdmSdT6Y/0Xjaxvcd65c t0WVNeWwiPfZZPJcXunxrgbmTifUPmPCijoRwBiBUx3SFzOeCXwBp1gf/GtuZY1G2nTP1LArs6Ed qlS1uBr2TIufHgy2Nnv16PUKZOSfPph+dvpIDqwlok98AwXiMGhOfQqtUC+dEhrvtiiJGrRGGq3u 54UVIZPD+3geXS+3i8/RLr3Q/HGUjryQ1uSKNNdiDExWt2uq0hZQmsG2IeNBf40TXlrQOS6T53VW Vm0dEZPPOeHMAGQkuMRRuWPwgCWxnHqtAmpqNPgZ7rro2bRGEUxNv36Jj6BH//8xBB33P6moUUvh yf4RY3o5BRcFVbYXPm717dL6W9lnRVmbt2OuM7t9ycke9HXwWYdzgE8z1NlQR+0+XidP5G5o0zdZ 2+T9FXD2iQk8RfBXyCrk4BrvB7oDcwr5xCdmhBaa2bsuAZ3pIhjAZwkCjNIRLP8YAr0Zr3kyT8V0 DcSPyl8ZLE6jXv67OYZ5Ob0hgkYPfqOVtZDC5mn8QFxOGUnhOyJuVfRZWeZN6jEWMfHfhvmd04am a7OquWaj5wWAADuLvPz5ZFvgrGT9ZKxv0w6tuEjWE4xCFgyM6BhweA+kL9rxAATSq8yuLgFI6Qt4 kxkARMbz7ZSqUFIjwppjeQXSkx8kjq1JCIN8OurM1ncYDq0fR+VS0BCv7nDZ2Q432cmnfkjBUQR1 RsN6h5sdQ0vbZXnbXLO+dg6XjqXm04MJwphjEZfPcBOs4gJE2IYjXCh5YnlM/onVNy95juU9zB9x X00eVtutkShrPyzwsbKnuF5HpB1TsOk2ZRDZ0B5JkKc5buQ0s6wqywXsyFYjlru0kIHGEBR/RF6s gf5QcQieLns/Z2OnxEgbf5ZEHWM71Unk4cGqsIOEXVcHndwb72o6mz9GLk6if72QTOApGCUkTW6W 6efcMDgmhiQpSv0YF0kO5eQbzXRhDbyf7hZdRCNSiFqCHAYym1ZSVkXnDmE9zTMSaoBZXJ8MhxqL WgqtXT4NiurQmcYnHrru3bmiHZ4ei+p8sOMAvaF6QtG9AXXd25GXq7ZkzuTiDjDYeZHisXMWTbA7 QuN4HCAv8jJt4scZHaodue3NQKvBjmH4rZdVwt8mz86Vxcb2qPJ+eeslcmXxPSOVMX6q/4IOgBC8 0eUTsBvuH6jm9NQTwY2S+H1oxUUsFssupApKgOQIugnoUoWws0uXi5MpxfNEaunBXwNNn07tVA9Q HQOhOT2HvjhI1Rgh3/erikeKEPqPWk0OCIPiaUZ5m+7DWGKzoB1OWpW2LZyXlgUJCFcXZrc5xV4n tZO63eB3u1ad9NxKH0ol0ijEvd2YJ1KGGpF52Mkup0NqWP5TMOgCC3anQ5yKh+xZcX50UfxFfwWZ 4IU2qY6HbnYBdUEaY5FDqUBH6xWLMOcz47knqEbODSkyS9jjCVWTdd3Qpo0g7x54QlFkjYXRhfd4 Is8zYSGwg2oxYqAqlzPwULVPkWOKeHdGKEz3ed3ZqtWOQS86DCPysNQyeP92f8edQLdTUNTUWn1l kfy/mebVGIsiahddqlTHoQcsyHKwxjp+w54a+dRftcjachMYMVnuDhxVaa/GuTw+GhzbQtXe/C0v szK/amc4kLXLFLChZiGAlEN+wANcLMAxrKVgGU2bMCzBgf7I9ygJyOgBARW/L8g6n47XMjk8Ga+2 ZPSM51k0GmZrFTGbTMVgLwwUtslk3Lim/j98k8neucyGYvmVu1k6fw08o/dM6350m6qNmPaey6Q+ NIOaXQPTuFhR2kNb+cvlUk13D6cKi7Sl0P1Q1rChJiU/uuUhRWj6PetonPg43koOil0cSBulCA/B vNIebuGXWPAgXICimk76vX8U5aWaWkgOxy18p0ed1+CL2iCdMcrjOrub1iAC+8L4JI0iLIxA/UV2 fuNvFjVZkduLzBvwFo3/HflcWJmvx39VV71aNxHc7d2P6d06tKtWQfOeErEnUObuNO9IwhQWnFNU 4X5hou28Lzkw38YXuWPBEbloVjMJ7cveHhj9GycCZXgPbsNDLgiuQA4ducYoghDUo4j6IMNHRaEV Rzkcl6MVVa31HpmBEHOSDS/XV8WQNX1Xpoqp1dlpNMZnMXB8XT/6teq6tTNz1eKm6izknKN4TzFY CKVCMRiD31C/Wp07bIJL6AIIRfhtysjD1ioVIdDH0PrNeL19/NLkiTTyDuIoejvXWpT2KYbzSr09 8UI3ANVrc40avAIUvwvUcFzdopNFamDVAC+iY8ThDufljrijhgvCOHdVV9bqk/ipX8+iojoxzng3 B7Wr8YMZQ1V4O0XkN9G+uAM2x3jTNNlQ2cc79r9poXSH1f32FJ6iplW/I/pTEZtgIVcv8bQOFkAU RcLs4DTrozEuIAMq0HSPIgBLZQFDBBXtj6mNTkgVdMgJr9AKMUJTOab2aImSOtrsLlmkbO2oWZ5b OhQPh2h4XrP7Uddt1tYxW6nbxNk5ea6rzo4D+U0wjaSRoesfY5CwsymAA/jhEVgeMIJXoKIlgbRW AH5n8p0FkvTMD7SVXRf92gmaHLQLRDPXjQx0p9lD7AmIvMrq2rKGNRvMIt3hnS0frdmGCXtrLiss 7G5CBGpTYoDxMCW6pAhmhuN0TYuSASzu3K1Sq6Y0c4M6QFCBdX+EoHdggYBKdTQNSbF058MsFa3D uwNEVdqSSrNqgDkcbKzx3zDaBodjQLXjxLkdJV5aAY+kCHSqxntBkvkU/ngyXt3y1XQYCTvGzLnS Q22VF85BuZWSzH6zdmmPy4fTQ3DBwzme2GR11TnHrcSiFLY4zI8mybhMgw2fiNDIDVaRApk8ApWg Qhk3Qt3joiJDQygqIDBeOB+2858j1E+0tvjwlrpOfONNL2/Y/mjnsk3QeG/STTvo27X+9MDqdtW5 uR9qxPre3nxbBxMtQssHu/gwtSOxdudI8rK23GDLSBXL3AFJMsYAfofhW2Aa/ZnRPzIfGlMMtPCc 28fj1VYfKfXxeNuGY/OQfMTrG3+lPWrQy6/TAowu5TEQzStwDpIVNWf4mJjzre+sJ6MiDTzejPR7 Ue5wToMKptUTx1v7qshpluJOb13+mEuVN1lZ2Av1av5bmeIfv85vx8psHeiaRRc0rWlHsL4jf4ro SzzgzXsq5gfc3IFx2vZF3W3iU2WQsubiEDXNRLxZRGPqcDwkBnF5Cuodls98fcvHaMU0KObycMJ0 6PjUm8NDB3v1GrIBhkZjqhJ9qyMiBh3dM9IjdhBiNZ5ntANjaS0IXKX+bXO5nWd26tyOD/dv7qTC Ip/pN4CwLxyp/KlgVSAHJDiwYDXvJLSmdAgw1NdO0RI+eUiiRKP0q/UYGdBjEIFNT2cRuq3jmZoa z/GgZ+PV4tBHdj0GLfxKW0A40K5p2GIWF/TmpEI1VEdiogmjocLD6KCwxwXGz3qMH/mJh9w2D9g5 VakGk6u/6igAOkXR6BRgKwHpxw9N37fTZUKCmtnD/BSS4eyahg0qZtG2tACfbPxicdH29iJG16Vr ynsb886qt4NXw/3ZyK/sJfoqv2oj/z2IQumPO2U47tSpNZyCLh5e/yWgUwgnhz+ZrG168CLTyxJ4 3at8dxdvC/vSWdNXBlAMELeyr57k5UafqC7Ej9MwxG/z5SDeUTGmtwRemYBQ46gjJHczhcErgc5d pIDHKQoOQsBwjH8rYEQqepbqxxzpGd9Z7Ttb6FFFv/1Uv2qr8VWGa1J9TIRtif+oHxUH05zGfwyN hShCY9iLxmiFh1xY38T46rA81EUxn2EsnAwI0z7tfoYzBKYr7tQX2Jsh3UAJOMYpB6The8NIQ8cM 2D0MQtET49bwSQW8jSLIHbTgXJCHlKRbE20b6LedKahs/aYxdlkB2VsJf40JVlyDeYygWTmqRe1Y hqRe6QgIAQwueIDaicZ4+IWcoOVh6MjxHk0DfWAFSPEjpF5LslZ8JawJMVyXIs+PvJ8B4mkex8gU zmwNgHh6YBBUYIDaAxXCyJgsOODzGxbgQmN+nGoC89RIr9iT4I9bEX3RpLY3eA6Fb8UpxkMHhd/c vxWZpr+qsf73C7w2Fxg2oCZ4jvvKKGY44zk+kN+dMQp7SSgv2jJ1Ry7C6NcXHN7ZsjO0bcGhqApb ALEVYZVHrTFDh619r4UGvEcJAc7gOCjoD+upp0SCadTdfMp3Si/hW6/UgJ2wMB1yUSIydzuZ3/1m HDcuSJ8PjAFLF+UOm0FKlTACTBK41Q3b2rw7uFXjPnDZVzPzrsPN5IvfiNwGt7ARWdkrQvZprKV9 yNtoQ2F60SiEgdEwiFgLOGoSDYUG3bszSTF+e7K1g4+bVACqiTdoYkZ/OAeKAc57PU71Q4fkFvMQ 6qZTVFBmVXnxaSSjMSxHmFRDLK6iYWNlcpJzJR0NskyCM3F+BnYzTub9H8IJBymRN95DZxM1d+r0 wge+xrdGy9xywxU4zHbmr1l+i37VYfxuXV5V13xgH0SEWOHmYtgEkIIWJXvqzXMrx9lh1uYyLeop yfOQi2IAc+MpgY9dYzRNBSRDFioA0jOtOAF1m4PGqAA6QS6NceGhd2nXYVh/IJ2mGR2ZahJBaY0B clTLkB9Ja7dwPJ6gXv8QW9nnWdNVlkjEAycayDuy3mOksW8ndLU/8nIPIl/e2VExf8jgUqKFyfXy fGQry1iejddbexUThMKxVIUZDS0SK0ys8OLVBeoprniIj3BHUqdODCwJyPiW7pzTND5CY+qTugul +7hITT16WJsX+JTSCZrMtvG1ouapdKH0RPca0yiCh8IFKih3qJ6S1vvoqHd01ts+1lSPf7aoAoj3 5fRNOdinLu0DJ3FLwlhBL4BOVewPe6N/b3fwho0Ui4sYZt0BKEOtysyAlzbpwXeIqMFbXNBRaC0K Q6OI7wMErf3dUUD4YC/DAP6LiOM3hKMZNIZ/LgqF3BoC8RPNvnFallYQgodH02wLRZuWAXNb+7ZD 46kiyv7Opx0itz/zaf8lNy+VeUOKNf0Zz8MPpnWbBOWpFbz8bfwd8Wn8NHfTVMNMyLcfn8retGcL FPu/kTBhMvUfkT6DSfeZdvUJfAqo8Bv4UUxSkiJPxhm87eQQ1c506E4gWw50MvWn/sejE9n+mENz yP61D+/FiONv11iEOckR8mPPeAwsAn3wEN9CfoQjJhBZEIo28WVoAw9VglL3e+iH78iHkrRCf35k tGbCRHrqHicYP5kzbgbFgy46Z1zIYaPfASw726Zso84eXCPPpZw65LBll2dlF/Wt7mh5dpjrKE+b Z0PvP/58DzirKez9teVNxdvLSd7d1VE0ZuJSwV8ca2j6ir9oXFzkF0rOL84H5w9P6emxC+7pIXzM yC0YIjYSOv+eLzv+ZaxoEwScXxNQ7+A6B6A5losqa8BOP+XTRbVQym/6tdL5aC4OcV7hdPjz31xj vELgpz5oHx5lvFQcJkGR0F7aDkRmf6zqDf8tUMul7UMVbVqCxK1J9f8BuHWJuwplbmRzdHJlYW0K ZW5kb2JqCjUgMCBvYmoKNTMyNgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2Jq CjkgMCBvYmoKPDwgL0xlbmd0aCAxMCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT 9StTtmXVTAlinX13nRxnp5ndLUUihOiYdYwuVkSHiE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+ MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8nemHZ6dEzb/BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqU sdb7NnyrdpkQUDQqd2QDPix5PODjki/knTw1ZyQbE6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5Mz HJdxIjvILUUjK2M+IOt22rTJ76U97RlT1LDfyDc5C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4R YPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAqfa8DNt8Afl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb 7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C+x8C2x8DiWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/ onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkmTFkFztlf23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe0 6OomN5DvZ8yePnI9r/cZt2c4YOWAme8bCjhyyrbiPBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334u dSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMTnfHf/MYtJGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsY GuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVdFhW9WOGeFX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l39 83xtob7imXPPmsara18ZV2aW1ci4QY0yvqwpiG+w2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8 NdSlCGVqxDjjya5l90WyxTfh51vL9q/pUft89klNJdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxr oe5VD6p9aovaCk09prarbWoX346qA+Udw5yViQus22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0 +Q9NuLmMaQnfEdw2cIeU/8NfswMN3gplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjc5MgplbmRv YmoKNyAwIG9iagpbIC9JQ0NCYXNlZCA5IDAgUiBdCmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3Ro IDEzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVnVub3MZxhu/xK5BcrZ5H AnE++I6mIod+pJAhN/GFrAuZkiw7pGyJlp3k1+frxts9KAwG0zO7q2XICyww6O7qqq8OXX3Aj/m/ 5z/mY9FOedW2Rd/k7dQU/Zj3zViMY/7Tt/nv8h/yJ8/eV/mb93np/79/ozJlUU1NX5bzo8Pd0BZN 1ZZjPtRtMbZTnb15l//6Nm8rX5bL7bv8yWdVUeZVfvtdfpN/lN/+Of+XW1GzS092F3qqrui6vs09 PdkePV/mN88/yj9p85sfdJnym7/Nd9/Odz/p0sXfvv0o45Wv8tvfJnTiCqZWZVX0/VTlA51IYeon D8fUqpSUu66J9KQx9VMxrqrzGxj49czO73QRq+GxoODucnHVX7i77vLN3MJPqkwCO2rvOoFlCVpQ 9XXR19O0YtCRFmRLLUgV2CaAsl2trPpOatnX5+iZtTLzWikt+NMsDHCPhCSvdMZlF5qPauiLchh2 6cxW1uMOfJMs9/k2jMXQN5fyDYD/ZYbf25mLujwg38ap6OryYCFmjbSA+yUZN9VFXcraBou1RU8e BBkBB+P+GhmXzrHoqLI0RyVmFdVQfTAcq8umGLthbVOtBI85Vs2sKudLtJ7p9vI+7Oxv1fqY3/w8 u0KcJrTUhsADuYmSvcLl12NbVHW95uSuy08OQbzxza4Micq+qPum39KFtW6mhkQbzuCcUYshWj/1 xTQoVtsL0WbdvIw/V4aM/TgU/TAmBDfyTZtQB3oY3r+ZIOIPMxBxZhTH0lDg/YxjLng/yr2dK7PF cYkUp06KE27wCpXx23dzZf8zk6RyidqwIe28POP6B8WO1VjncDdB2OIuxB9c1yIao0ffb/ETA05Q /OP8ys/zBRbEV3xo/U6/VYr04KsNuD23siBqiLGchBiKE/AhCN6M9sibOkv9obLLJJBdMCSqx16W vdKgasb3lgQeRf0V3DRjV2/Rc+xo4Km9AGe4/0aylBuwiEc3fph9Q6FX5rj+Mn7bIegZxFcaWQ7j lMuWXNDB1w6J1Zr8TQ0ANXQ0os3jC5bw8B+uUg154ALYtxjk1SW8sxuqsbwEyX9UpRqVUm5PVf8y c50hFgVs68jOSpI3NxWI9qJWeYFSy3/PlGEaeBP1X/fIc+vvcwEVfzg81GNXlF7/0vGw6e/asuia smzyblKNGhS0dTGdTpL08q7dIMOrMU3f1qNyJt1YjmU95VNRTpOMsotuvtvPeWya/P1Ry8HB91Mh 63MHhwpykOR7wUkKjnhBR1RwD8qPJdDDwN1iZW2dPQKCAzjE/K48eAo/cgvmADAPvU5FhQG5Qe+g cVOLN/UAO0U1UExLG+3mN4FEqyu+RPRcgRrLOMwlD2kRbq411rOKN6HmoLGXqc5Frmsai6lvhlzZ J4ekLVfxKK6rm4pp0rj8fOR6KlS0Ych+pOIzfEHQsN9iEWEgRCSLLLF/HoPZjVWCzaCUylAeUAe+ +I0AkoeQZKumOLRYkug8Bf40R6Ob3oXW6Qr929Qcfvt6djkYdoiwasjDGFgvPQi1ROl41tNpy09e oWMHpUjUhisGlo1S2kpOdXlv4Pf4A8u+K4uhLMlt25TBSj1PqQO8tV59LWcvDCRkTSPiRs6SycNJ oZIUuraSTTK9zsqiLCdNSLg5ids3lgkxnGXC4dvCJ8f9iw8y7VA1lYb6k5y/JXJv2mEz5jg5LXNl DqJvq6Ithw/Hkjd1UVVtSg5C0CV91M9Ro4ToYoXa3AFPLs/02yL+xrvjXUEr4TRmGrOyaXzXSuK9 8heuCZFBCTSIO+rGOp10IV9lDzZ1NMlmdc6Dw+iEYDAZiEc2tJjKbhzrVqFuU09tpUHv4a/dTPsh Zq3rYqyvnjbcjtGPCA0TmTFGr0vNd/YmRK8nZRIHF3+fCdGPar8PNlSNEvpJ06fSi1uHwXIdmdug hOAdKOI2sfBowhrfXr1ikODvqPPNPBKwQzt+O7hiN1hAEdeuZDmCpTLb+vU66r2UdWRB8S7V0Ww1 A2xHN4wqYB69txyFjD/OQVECLxgGYYVgCXVyZ9kFEVRNcfppbVlgAvLxlWZhpMWrFjLIgHZ5hZaO xjTeGAKrw5hmIw7YVtHlONdP4ZxTotli5H0lBzK0eaMVCxoSBBWuys5r7mG2Nqq60kOdGzssh+PS tEHq/0i6run0uunbBNMsXYfF+9rideAKj+Z1PADFoyiqwGUebZEEiPrhkwfABzCBRUDMnR07oELo QCFL5/ML2VXI8qtYjpGl4DH4K3mpgKxSnmhU9FA1SuCM1Rpa+3mbe3QKtXxB0yjh1KcDZdOHb2ve EaVHzlGMUN7LefVDAutRNaZTVDO1TUpm6z4ZIbOhQYaC5w+HEcptaoiROGf22oUJSnFjO4Keo3Zo ZnrOmAKvXK3Kcb+k9s91Denp7OZSjxRzf2uP5P2LdWxrwn27NGj9sLWW5CiwOtGkeMty63pxCKVs E9Zq+aRRpmlv3y5mzr6yYrG1ZfAvellvtCnPb0nG3je/Nva+sj0m0EICRxk1wa67TlrK1l49SmhG rTRsyj7vLsI9fQQZXOgOYiOo4s1Tqalkn3NkU8/1GZ/Tae1CPXV93mhuoZykVrOpUTjjqvzOm2a/ aCmEM93YFIMbQK9s0uMNXTrNdzRdokkCoTa1DTRR2r/OwfMdsYycbX7fjl/QddmDh5fzoBmkUnNC ujZaTrkW8+4y2GWofCKgUX0ENGfmSttJ/qPrcoSWkFC/wKEeEbqOLDrBvq0DyOeZsTmwmNF+GRtC 7Qmrk7t+KMq+uzrNsJWWO9L5S+jpBk20pGTl0rJgJMqsa2NR7XP5K4XQ+CL0wmoXZtCayP9VOQ3o +Y3FNRS3/hX9/cK5UrXEj4eM8YZ63RNDq34symaY8i6ZoZt43iJnA83JS626dtTSpqQJq7vQI8Sl Zdm6ZtLSiDJxyIk87eWfJd0+v3nqhKyYkkXWNgFgwYV95RUQt45bfDDDYisafBmb8AvvqRT8UhsP rW/3Da6nhkEjURdN7Lmh52re68sypKIvRGvQwkMqg0G08OVcyyvXlzq7+cxdFWY+8/cxsz3pVrFz N1/G+fKVLiLg4/lCfSGWZ6mVZSrc2NTKZq4U00ATqtspZXZ+MmRDC86hrimnonJLWy9AXbIW3Mnq Npo0GsNkyO48nswujLcXEmaI3NpG4MArvzLiW2kPKQ8Ehvi8wYyLCPgNhNPgpqBpEEKhicAHI8xv VMYrgJm71dCFBlEpXrUtrVKCdN/qBh3lN4yGpYaOUjcXOroZmANlu2fkqdjt7BLNH0YtTpXO8jJm vdR8orc6pRjZ6XCkadw6oqaVYiyBeHLuMrtks9QpelI2b2krQTFMbWIMbzViDTtv0L4xCfArYcfO obVBByEMIRAtboUIxqIeEGE5oRcDSnFQg5MAfJsThSDZdpBa0BJasIpAZbx5UOeHM8O1YhCNNYb8 MuliDpb6n69WsdB5dIx+rswIPITN/Ih4uPjy0d5Za0TzdpyoVxKV8wov0WgKf6i0CTKwax4b7XqJ ZK/llfPKKfzOTWAoG7yx9ilxsYdlJrJAbID1nRT2eFYbrTotvfymMG7O15adnZ9MlKK4ZjeUncuq nDa9VdcV7dBUOdxMm3sBxFgcdW6D8MQk+znSPYFacSQClfNqtSd3VOqrqqZuzhUMY1k+zCC56jX1 3Ghh60WswQ7CGiw8D1F61pntoQf0AVBMAKijMl6xi9Z4+Pkc23L5NxcCKDF9EJfz/VtRShb2pNo2 rJ7Y31AXaAvB0h9mP8er1v5j6uVTNlCzNeC8xmjJcU+N8knpRmLTZm2D+Cik8LOrGnHGZKQi/U5p jHUuUnNnV0ytXpI/0RRVXWq9VdLubtBiL4f0hBuBEaeCMgCMWC2eguiBtQ00Y6ihKCh6NtwdBQCJ XSkEabwC1mIU46dCVu1aPFodo7aNECe7SQhxqAxtwAbaQInY+8g+OoXjIQTSHqykajjKmygRbOLN 4tiv7Kx7iRqW3XcKUduoi7Zz1hHIJXiOTRW7J42fJw60iU9nLRRTlXrAgcU+d0RXViiIdonkOEeH TCkOQCj+XxKY0oWIL77psWshQTkQRWXUAmYtdDG6DGkpTjlbtaXMRo/8FvXep3csElHKSLzPwxzs uEM3tbzC17x01yq7wQXx65bPiecgwCEYbO0HWdZNwj+lyRdcw/1TT0J+85uVo8nu85yPpnHHe/RV hN0HowaaD+u1muYOngCLjJy52M2kxDf2zegzPEwirvwA2PoMJqBBB/ASqqPZ2l9bsvLDhzVOO/Fu q4UCVasDXgx/jlINyxMplPMKTsZqP92G/E19YNIOLaYAd6FSgI/+cserS35lYUshLdEu5TZ1wzI/ Cma5Ro32lg3lN3+W7jQxP2Rtib07s6TvMklesienKTV11dbSvB1JrgaCyQ5ohSwXgSXPcbTOFTVJ 28lPZVODCXtx2qT5iP5j/d7GeMoCAedg5QryAAI4QqBkL9bi9WoL1HA/R8G+f2cJ3JibookV1G11 vIP6rwMx745o0eoP/YVgW4vVyei4PPAtnyCbArRAZTRLgWUH3WhquY4PxtKQ1O4BgV/reABtZc/3 gPYowNfpOmWTuIUBftsL7gTuW7bD2ih0L0rYTohMZUDeyhDBguC10fOVUQAAUllALiijbhuHLZGb hTifmOla5P7+RvjSaU1QWjhNz2+olDtIRJstL2g3dnQJ1s2Owlj4RHfpJzFsHIl4naT1KBBPYGDX Wld8DCxzlagW1wz5K3dwm4vETsPwUbRCGbapUf50I08Z92PFk39gqr0gbnv5/UeChABiscAo5bVz HGmb+JGfDR88CuKieKgBYCAECdvfiDe4AKK9JRIWtFT2ylH/C62ktN2HHB7avp0m7uG2LdWj1l6X /ZC3oOiDGV60bjN/4kIdOGcvgCMYDJn+h7MNbvNXM/V5ewnV0dr56CbQCex/EESVHgMoFjYky7Cy vEnn8R9om3VRNIjyUMCu0eUVyoXhNK9CDD/ycDliiZHiafcV01Sb7ovOEynKnC9G/oEYumYdCA9j nzzzNo2MNR3W3eLTeMjF0kQLtC7eJ4JqFfCnDCWbWjMRlXbG7aBKBn45krzL+OPcAUeHBFgzaN1p 0hqrU+MPaxRhJvyGw5H7PhYAUJSjgFUA+alEWVzh/Kta2Y7GxcSm848/SanzTrTAMmlL+l3AkT44 rdxJjmGpz1HaY3XwZcI+Y7vC0t7ZlSif4tWfz2bjtbtViAKegn0FNJiBZZCRheUqNkCnAEMHChCj rO2yt1ds7LB2GdNiByD2FSwp7XFRbJOI6pWF8ZM6Z5Yp1rUOyGlGhbRILcX7f/Jw593WbilA3baR HpKLlxw58LNYrEOOH+7IgVpzdv0kq7yD9EcZB2hOUCP2lHHAXSyBOJu29LUtNZ+uo5f2hiXzMRGn vMTvnAZr6WscOnhXYJUGDUTJ+e20jsfww2ZXbE4I5cYD4XNowSrwHJPEcQwFY8TgoxAKWgOgRYqJ an2Ns/KnCU3KQc8i2BoZPgZCm8lt/g+Tx7u+4RdBqCyfdiin7gdGjvay549uHXxP7XA7i9QszgkA cTthZf0X4RFxkf0NJwmMUQ16YSG+2RCvULU9nZNOUPV2uE6llOdVfxfXfjIUgKZNQq1m0V30jOEQ WaqlR89vVjHBi4dUO23d1fZdLSAKuEqYGrsM51cuZGsGt684TNVZvVvZgVOm2KLe3oXIinWeAIYL 4kfECIffqAbji4gBaFgXxzuSY6K93AiDzgWvVdcUtTu1fY9Rx6k0gclnkQLGnhJw/obnkE6HbFBp FQDIwx2LdXjFK9Sp5K3PzcFdxstWA6hmqXFxiRbaiP5a/bNzpjRvvZd1grYhOoENwvgEVn3mWCOT SDcgHzJUJFHGV/jERsfydL3b8GmU4fEHcI1WAZbV9mze/SsnaEBkwABziqifSEaaCeAh6EVEEYx+ PoNakKLFFA1RIOSSN+S+PqmPlmjXwp7agNgBNvM2+OWEDb9ZnxkMFWAm12UVxHc7C5vvYn+Xiaig 789nRgVs07fQSDR1fmKEimDVkTV8QNzrTItBm5xzi7MPAPcyulr2nRCbXuOTELFduQRCkTvy4qEF GiMOxIXwsGV7SxfWxs/Dhlpob0ZPdhNgE9D01JlGpSuC9yge0hpWLhLX7k2l8RKFcFmgYg+mP+d/ Y2axcd9GclsB9saMv+BB+W7fUFOnnH5yCqO1pKo0voQ5Z7K9jQIJt07i/y/GBycMru+TdRB2rw+/ 4SdWBtL+SBMrJcHEvkY3VjVEE+snf/dN7HJ6OkRPUEA0Y/2A7RYq7C1HdoMBkXNJtNsbMalPo+xu WdNG9bFz5215DO6qRF79YjvWpA5KGTZ3SesgxXhZ6gRQQbI/ztqDMbfituLC39vFYsG0bjtqAnIL Q4jy8o6zWSBLOLlW3n66ZzdtVg06e2rS0WiBwScEvpztkdGBJwRr+DJ6xh2/0bPAkxdu35GmwMP9 2v2sIrajqMaqnE/M2ahmyck47rAPERoPIReXzZ2V8lIN4yAC9QU5iDPOSj5g9txJSkcNKLRK14lk N3rFEOfgRrV0fmjDnNBuqHfKbyGT9cWr6p7iIFJgibwQDTKJMbmvLODvhTPxO3hEBz/Wa4fF4NS/ ueU6wmmZhAVOMaG8/I3K2BRBe3SEbqFKPIQ5IA6u8HDuVha+bxh6x69ntMlTZbXJpqs3+2ZNJ1qx 6arkdu51ibpbL6ilGm7HhoNdQsb/l1EDLeBt2zAVee9qAF6QO8gCGsgCcYMlgGKEH30M0OId8GYN OYjAG9KERS3itgAFCpY0IER738yONiLa23OLaGuJTSfWR2YstSzOjVA3PbPtWnpD3XTN2gsopYT1 e/Y3GoQYNbhw3vetAW6QPTRd7taMO8h9KCpQayao0pk4czBx7yoABhEmFxgO+xEid0AKmFKAhKMF GDgB8xSfrWq+M3aegxrbNlVZjKOTNAqV9Mc/jJq56QmozBpiS2yAMV/ro8+2l+CX5i1Nqz4/d57v kDbg19AI+kANXKh27Ul86FY85LqCOTLSUtmAvw9GH0Z9blmJ/o38wirXmuyhNsZ2yfmOenDbeOOE qFvmoCnbzS8rHJEnAKQvc1gSmfjdTvdFVs2NNvmKSPNlhRVVh2jyqQvnDotvXrnbEwtumZI/zHfa 0AVkr4COTlv1jbrlI0usC2+iL6+h618h6AXX/+D6ua7K1wRDQ8oPRUKFrfUKyxJp4LQf31+4v2dJ 6FeMWr13pj07+oFZmFnusGpceBitoedV4C4840depSV+U90LR7r3VfMrhjCNOy6tVALQgm7XcV2m qVdOodZDWdRD2PR71RQq/NuMxgDY3kJ2pAD4gIv1GJuipWq7uMzOFFK1RTnkRj+8BF3APFRYfFKb fbiE0voQCJvloc4TaPWjP1hI3MCbUB+QTINQwR2vwjUInbOBUTutvTjqxQNi3x034w4isVj7ALDf 66yL8U7LB+A4Yti0kcxhI5Qgxk2DZE94OxLR4gQIhMmQKVQak0Pe1gMKGj5YuUXCPriD5/IOyj4E J7Kild7RVy7A0sdgcSzEb5TnFWiNhtk3ZdUA5bcBM83acjAFZQodt2owp/gyNzmRiOplGOEPxPWL THfzmloQo+N0FHLVoOiDCQU7fa93CvPuH4CW6SDqTudKJMSmCrNYd9bP4Yok6HBZ79yBNQKaFaBf qKALzxIAGUo+dUV0/sKq6K/943h4LUAHd1T/hXtH5K71xU/RLPUlvpJAV6DD+4a4kR38o9RomNW+ Z/TdvkMExdIyRlCHzMt1+uJnAc4sn6317WKdK6QIaAcPq10fwgNss2p/6FIivddEbPpUxqDV0Hvk rkYJlwVsV04l143WdE0fzlRy7b5pWKYkhg6DqKizXrtfAdSXqNjn8xFYvASobXSJo0ULIqZ9dVb7 7ECHOtGXS71nPOuIaqAJVwYoQSp3NiLAzUETxUE4tXC3cmxUat2c50zM5tiWrEWAT3hSWwu/MdVg Mz00G8dny1mF6LKXsUbMyDz07JQ7PykdecmKeYWdiJNTtbZRD1XYPbbrd09pwgmse/+BLIDJCroA EtChDzwEUR5t8WsqdrQFds7YWpc/iC7Gj67DcMkCBBKBGVQAM3rBw7DLgB8hKmqJV2cb01KQ7kMN LRFoEzPwJpdbZ1sOS1JsT3mH2vxvcdSEznx8fSh5forcf1+81aolCyE7GF+5xk1I7x+696U2pVSK iMv8m/m4mGevdc7e3qdUXj87Ouv3E+190UfS3DdS/VTboDNkusrFvnWtT5V3g86WKcsq133V6Ywz BaOT/uVv89f+SKJDcZ0Mk+/UVnXuDP66aF3pd+6A48PtXNmTZ++rpK9XVPrCW9Mpx9ErLVn2+mjG u/z42Vs9q9Q5hSjug+udJv7cI+UutSokFs3cs3V1b/Pv9WWVLz1rEzmmaDjr9FkwfThDqaHO9/Bw 99Yf6KzfAgP0wH21lpfdz8uXv88cc510K7eHqRv1re3J90K9dVXbByo+uSF518R33Iepmk6riHvZ s1o7wLLFEydClyFSsfgWzxKeZMty+u5xr6/vOApCVfrOgvCkQ4UjTdqx37lZ/kB2uH+TteJHXSui 1ydH5nfeahOxPuU9CGvxWatzinX6qToT6l48mQlQVYeX5kfnH+ibwLHQAANc+3NrWWDdgiLhyEng QDYPVFPsyYl3Fn2NhRzK6vwf6RDTvJ0Oee06fexsViN3L1Rx/1a/+48ZOkXlmT4TpzNte31Wxf0x 3zkCnFK/yez93t2buWwvdPu2XVuqsJdB6KZhUk20rBN59JPIcn+8kRlxHz3Wn2/1p77WJDL8rczL obQzNrqjbiHM3O/e8a77XI3vk2tGdYUeZ7HRyBFPUbyDwnhvfzV3out7b/b2raw0NmBIPdWnj0an s4dHQE2WZ/Fs1tK7QU2IPYnPoHu88YgmA44sex8fzd/VbYWpUYfgaxdEUTnrUGkv+9jKalfKuneC 3zqui6bSnXdXTr2OQhYA/f/DbaxWn4QZ44gr0+fb3Ytcbt/NO79led3Z+r99mf/n1+/ff/uzgiDN YvmvYVzSBkmkQxuN/Gs7SR2079c1pW+V0tQ/PVALVVHSQj48qfonCpuq+ldyvy+V3wh9coeitvoy ub4w5sys1sdITSt9GrzTfiNFBl01aj/Kmu0zi3fTajDdqfpY1PowITP8+gC1K83Fs0LbS2ZCFU77 7I2m5VwoqDNDCSG5c0EnB0LpN8JEl2vVQX2K/WwO4XyvlsnCxDnHVl9lk3tyn5xf9ip0Z+7VXjbh /wBgav4vCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNjk3OAplbmRvYmoKMTEgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE0IDAgUiAvQ29udGVudHMgMTIg MCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxNCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9G MS4wIDggMCBSCi9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgPj4gPj4KZW5kb2JqCjE5IDAgb2Jq Cjw8IC9MZW5ndGggMjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVWTW/U MBC9+1fMMZVa144dx7kWigTiAChSD1UPZWkLiN3S3YL4+Uzsl6RTRZB0W+Uw8seM33y8mdzRR7qj qH1D1nsdHPnG6RApuKhjpO0VndGGjl/tLK12ZNK3W7GO0bZxwZi8Na5qr531JlJdeh19U6rVmk5a 8jbpQrRrOn5jtSFL7TWdU0EHdOQfi5+82VBxmcX2QB1VVNznm9+yWLGIVPzKV37kzUGBOgWYxibU 79kYv3eV9TZZSNO34gxWvuZNGNvxil+nbOxzPoNNaRrqN/kKwP8WCgABY8ACEFCHf1Bfs7plJ7CU 6JM1VeBB6OMKnABCnOF5RLK3Pfikukxs+cUxosB2zZtj6iafQJz4wQtq36nTlsvuuQuPq06HuqqW FF5XG+13+j8etQ8RbKWrKnhKRFDPQYSUhUuuOs5JnylkE/HHCgkb6jRlSqYolbLqaYVi6I2iGqAP RdwZSiORFJsrBsWMkNxBhaBOUZIwDYTA+yUzAsZus4cDMRJ63AQDmf9dSb1MCkvXtbCae9miFIJe cOJTx9KSig+dtFS8f+Ci6hmFeCEmkznUrDfSDMbf5s1NDpRMkwwUInsorHAQXy56rix17bxbEr3Z hEyTST1xMpmgy+BCJqScTEpOpmV45KRUhuZNytAE3dQ8Mv81KVWalPvg4fk7E0+suZPGGYN7Npx9 +idD0S5W5bz+ecYFbsMwFNE7Jhl1yKwZGQW6yB6HLoO5O0lBMBFje1hNkFWenXZAuR/8YcltHP86 qUcObQGYZPt+3SlyQ8Eh/oCw6hv30Jwn5rbLL5osZEcoxZkVq8UuSocfrx4GH2fn/B5npG+ViD4G BjzE1SZDS3hVcTG7kT3hl9aZWjc2BOorcSkz/gK+xjnYCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBv YmoKNjY3CmVuZG9iagoxOCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNv dXJjZXMgMjEgMCBSIC9Db250ZW50cyAxOSAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4K ZW5kb2JqCjIxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjIzIDAgb2Jq Cjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdVdSbvd tpHd81ewd8/fZ9OcB+8UuztR2okcSU4vnCzcsp3hkzJYGf99nwJOgSheXF6Q7z1JLS34iEtiKFSd GlAA/1r+qvxrOVf9UjZ9X41d2S9dNc7l2M3VPJc/fl/+T/mn8tPP3zblq7dl7f6/fYV36qpZurGu fdF6N/VV1/T1XE5tX8390hav3pQ/eVn2jXuXl5dvyk//q6nqsilf/lDelR+VL/9Y/udL9Ga3P8V9 +tMM1TCMfen6U+z155vy7ulH5Sd9efcnXJby7m/+7nt/9yMuQ/jt+48KPvLb8uXPMwZxgqhN3VTj uDTlxEHkEPWTxyNqU2OWh6EL/ckj6hcgXNOWdyTgt56cP+ACUpPGYAW5K0FVd+Hduct3voUfURkm 7KK9cxNWZEhBM7bV2C7LhkAXUlDEUpA7YUkGKnalshkHiOXY3uqPl8rCSSWk4A9+Msj3nCHMVz7h ioPw0UxjVU/Tbj+LDXrcg26Yy326TXM1jd1RupHB/+zZ77WnIi6PSLd5qYa2XhHCS6RluHdJuKWt 2hpoq4iV6k+pExkYjoT7SyBcPsWCoiryFBWIVTVT88FQrK27ah6mLabaGbykWONJVftLQM98vHwI nP05Wp/Lu797VUilyb60poNrdzNn9oTKb+e+atp2S8ldlZ9tgjjwLU6aRPVYtWM3pmRhK5u5JlFC GdwCtWCijctYLRNstT0TzcvmMfqcNBnHearGac4wbqCbkqxO1vu757k34McGVsT/+ltrvvF9YjSN EBZS0/0+eq/QBmlTsDK+R9OC7RLwrUXzD1/Zt15G+AhfYGVv8QjEiJ145e9YtRWqMCJne/IFVsZa WCe7+zEqW+0pWycfocn1TzwpRlo8+GDssiXCNJv4K96Akczmnc1QqI1ne3GdvOXd2m2DDMVDOidd 28IMapcyn9OyGf8EUK2CCDOjm4fWC+IuUF3jfKpMziwniMz25ojlEfRopsPXQG8tNTxHSK4bRJ74 kjEoI7xjt4McON2UJQeOA8leJAUro4D/w8sdLVorxEEAnIxQtv7tufoKy8Zy9wUl5hmvev9E7pvy 7qcst8LDfv3Z98tihcUfK9eshRNNHOGFlakIc7CEjt+hGxBTvk/gYi9AKyN110MCJ9gc8QDYgiJ1 +WyeLXb30cdwqat2zlHH16SOnENeIaE5NZA6p33+gBkG9JKNSf4r4upmSF9MiEjAVVazgmYUpiD3 JGe/ChNd3Ii1JAwLRHBuektd3yB65AmbgQTZ83yC71Z4HZZqWeDF3Q79ZPfnXnw31NVU1wxFWQt/ YwdeYzzFFvLBc0LMV3IF5Hwpsh5MFnKC8hV5j5hBLtMfeUtWJitRj1jGInTwSXbkBTvwM3ZIMfFr 3n/p4U4hkm9dATMnDQpmfJRi5BovND5HMOM4CXSETaqBpDSwzr95CbUWD3+zOLmFW9ND10Tok4Vb q4zYNUtPEhLvEYofQUK7rqv6aenLkSz4wYho31R9PRGL72MBWUpzasmrMfOUd5xMTvRtRC7uEogc opmEYgBsZGizbpVWa9iwRfbNMihZgw1SzbA2vhCYKPbgKUm0YfgkXQ9W9rHpIbmOT5JcfJLtsS8U D7bAQj7CQt6RsEQNTgjlwVad1F92mBBAkYfi9urACY3VtXVVDwNME/LfByMPXVs1TU/X/D7ywKnh LKwegbNNOBuW2/hoYFbH0GTPuLBQm4bMQ1a6BsaPZ2A2w1w1wwIX5BDVOE7SICljHBJdYysIlpNV oz2jotP7J3JvnAAnrmyblAvS50gNCHk8WrWyzLfU4Ph8Wr0bowi++dzSRtu1iY51x8ai8mNjTYeA +pLsz9Uo7IjJhouFCRQd0Jq7ztwR43j5CgaIMInlCrIbmWNPd6nZ52Q9+AiU/I1llyHroeHYyw0h JzdEdtx2ah8AXGVHZM4RkVJmVRgX9KyLbokXtGNcCx9h54PGjYe5J+Nf+ink5ZfnxRQBk2Ge2x6r 6F279A1cpvWvXRerg9SO9VCOZM+z+qqvq6Gr664clqGqsb7Vt9UyX3WyRgSKh6lFs00FoG3R3WGu Z3Hq4UIv7QQvGmvzPxxcvj9Ph9W3w1J02439uyZEjUiiuHAfDCGGpa+WvhszCAGnUtUSReE5OFuC vgokjsXfh//4C+kIsPNrduiFXIGML+Vah7wAQhsNTV4IlDsOY4hjOxul0PXtEw6jQ5XgMMYActRh DH1yvQg0T85IiN7ddlZKOCuuW3t4/1kSwjKx4ZbwehEFwECRznNfAiSqul5GLzJTvwwCNzcg44xN P4hojgtazpaIpEmRSQfNiVKMlAHX4so+DDRo9RkpV8M8VHDsc5yG5ICvpoCdXO8ckMzRDcnlxcww F0WaKJUEq8IHu7YpW3RUyP3ECxootFpoWjwFtABxvhAbDBDIRr7RUg+MfOiZwND60Ma0YptvUROW 8dim9Xs/9tWykWCBxDaVeg6uyeJu0yTNMFbOFq0rcrxXv/W9ot1qqf1EhgwEJsg6gha6Osj5obHF oRIWWQ1nIGCl9W0ednmvQ1raNPUlGS9DFWbLwVXTKEcux6mqx3st79k54d1zsqzR2tcF4fGcyqYZ q17yAYdDI82SShU45zYra5PhrJCTKjcdlRCivRapEB+OrgIl60pwINb7F3weLbapSKss673K1k8t 9rBtChcvrD8JIPzNEaC4yyESSU+hJh3RkuGRBxZOLHpMyG9SHvlgpHOYqmW8zypgUji3bBgvAnJK 9/1lpxOusKGrjHPIyWMnWMg72olsj7NNrUMt+G/w3rosbHvGWq744C4L2vrgf/KVsRZKjdVOSZ3H Fzja8J7rGQvZF7I6X2BheMHRjI+wWb6uuUC2eTxjOP76undsiGZmGHY1YH+ANspmsGxtFPeGeRrZ ka2hn5FlpauhNtJ2GdkihTMu6netml74Krm2ZqfUTj5bomzwtwBwjvF5ZxtKvmcZg49QYH5veJUa hSLC9/jCH2ECdeUd+2I5iI8wrs67pHvGXlvps81SeBneYmVfiAEGm/MZr3r/hIbZT1metN5+Sc1i 6Wgl0pKTfUBhpmScsIy6dkJGCILQlhd3lzmOycZZj6VbkMN0r5V5zpq9WFSmg8BZSMZQLQM+5xSn DL1gzVhjiC1SjKzHw76xMDwZ64Gt9nIuUrKnV4yoGLo5UDsmciQ7yC5ZVgxs6qTeIgIr4yOwih6P W9sZAYVlasrBcMcut655GwFtnG7iqK3Yf2dUMAEiXwA3ygCKQP7vh5GRkjXOHXSTGdKFMjD7UzBH Wbu0Nv1xvan396eEcC6C0lU9ax7ARX82+1OskO3dWX4OjOy4VO3lwG6O2amjOGEWP9kSCxlMZKEV dUoH1Qpf4CNkdqtPfmd4QbH+2W3sf0T+b+pqbJDhaSdnl//fDVpj9R7JLDkBpmP9OblmOMjqCBZT bqfTr/BgmZYMshaendVbwdnrUYsFAliP7VRyNBluGkbzJRgU1h552aqiIC1O2igRLOSTxEPaTdZr oSBSWoIuUW2VoFA6cHsBS0qjYl17W/8CfGJL1bIMIwiB7a29bIptsArGta9pxtbX2/HrE8ZRMzTY eovNtzvsdBk+VYQg0NFkJbWIdxZwwpKqUlKioJ8TaMiIVstyztQK4TMxfhWbbZy/uUN92HqpvdPq tYrffPSoihsrAdPYDAcomcSJTH5yihd8ExYCauzJQ2Bhsw4wN6fWSm8r9VWJYnGyrTV34f3jNHaB V0ujW6+tUr/k5BX8okQ68pr9bQs6LuxOJueTfO8E6Lgtw1vQcSDHqjdmAx8lWlEonOAVurcFy23R kLjC8DRbAgA3h7fTzqNswh+xrT97Cu4+OW/n3QpCNLJNtUO+3V5/LoMQagbRxSVxCW4kPKY4oQpS S1onMLmtsbdl7OR4hJiO+6J1iI7HHNYWlkZ9cF6hpa1NS6MUl0ckXAtlhrWPD4ZwOJUCczht+nML kyzhaK2Q8ciNdE+xBhZRs3jYwzXafkGi47RSM8M4yxbnM2IhpkrfzRtq7ooF2DAbOWVXoAN1LFBG VH3gI0vaWXxOrHGqcOdQFUogyxk+QdWgx/sZZ7EguSlj38o1h8IqTN6RqDSzrY1IbqbCtEhLY521 BEc3js5QNHSGrdtNKeL7CdW8rl1ZbE8o1bBh1PaGUmgjKjR/2SAfsT4KW+CYrEgzhG1Hz4GykN2l ucwukYZsNgz+Zghbtd0z2uJ6/0TufSoxheExdoi02KM+I9ilzPfBCIOIRZeV3HJIGH4AwsDxsbOk /JuM1Fg+ok2COZdJeZxtCk07VDOWTnvSIGNOVhq8FLZB6hyXSyzjMrM9yLIzUJ+T8dRLo51NtqZw KImIIs6YCDtk9EfKBUWOCjODqOwWpYs9J905AFovVuRYNX/jZbMrlsNIgoKFPeazsEEnwCFnkEPi I6yTA1wXpjKV1gklgbxhpFx0sKTz5SLp3KYsZBcqOWaRrkoLRw3VMAkSQbBMX4/EtBfOJZmPGoz0 5pPkD84hCzecyDcIxq62sI3FArydS8uzrNtKTcbaN3mO75GFbGV85JW3eyg/lDE7XFuLlQOyLFug NmRlHDtHyzqTlVXAAUAjO8jLU4+XlsqWEqqwnvr3n2Ubb2fkQGKujRj02Xx3TAxOxoKRDlUtHaJ4 CTm4dHAtiffuggDER4VwwZgTTBbiHV8I0T4XwrDcoiv3FAfL+eyMneHbUiUb3p3pbt8PHOm68aln EAouGZMvbPHZRSkt0/IFdo0DZQtWVuyQ7HZmtpckLCtjB22dQcZcz0jRPRljLbzghUfUDjgncFnE pTFsuOuYHROLs9qhH6uxf/Bkqy0HOZOOzMJ5IobyYl/gxHLyOJUfK/q5yshkVkfwjnVa8SM/WYuC OflW/Czjkh1foHUx9m2l7Kh7o1CblUzKFye8iJWYyvd+8HdhLA7QrTSwT3zdcnw+k3J1pThwVGgr hyQODUyYI0xBgrC7Cl2cT841jQVL5j8Cj25m8TjaYVofUzRxwmEDPyZ/1Mck86zC6iYk6z98WphV HJwZ8hx/s7bEBQcKO3PWwdWPNzM4GKpa2hagaUhxHDSvrhelw/e6XtR3Q9U32GX3MAtGuryJ6g5u Mlxt+RZbdsb6XW+u6xGDaLBReUuI97fLEIfaYCVxytxcRzAiROFylmfPTyEih0hbwlaITc9lcb/H qc1ycPPLVzbsHcxSPZUZPUeM0z14+/SFC9v9Hp2fQOwB6YGbzt84s/krqkyahYQMq4D/BSUAOOHU WM3LJ61poJYuoSpDAePJzPmmznTHa7uc4vMkw6oAjpbEDoxjJCMcc8hEXhvT+CcoJumnpJW1HUhH OhekESvlC7ESLnRTFFuKfyvvaEYlp4+Tyd+sv2Nrsa1zTvl6PHu6DBFiVhwLB5HsoR08KjUT7bdL XAV/e7DejakuPAZjOifoBOwUb3FASdsiG8UrhwZ7wG9nn1zEcW60unOueycnj4/YqH6AwZJ2S5o+ F+ih6Q5BOWKL0YwjrLc64WQ2xXlCrMoR6R0Ivt3nuFKyXLg4T+NLb7JnsOMTAh4fJa87AQiSRmGm pwL76TKic2uro+uV4iAlifXxQplhW3zkY9OWB+dwNgWf2YKzM785nKf+fQriFpxdeoZ2iu1b8bag xkpZSKhxL4SQrn0hZ08kK30u8wCI1GM8MIMGGPyukjTjxzrA7eRQzryWlabAgIyEpkFmRysnNyA5 7QguXEibNopaDtqKHQCq6/q27PPF4UFxAZtsBomzbYzm92gr1kgXnHO+e7Gu0ZCRrlycAFKdKsuT g52wB/dIf6R0UXQoFk5IQoIeq7M8z/ZfCD8j9vAz8vUzXr/mFfwtpwt+wVu+RSFkj3hh/eqm89Fk bM9iAbGEDj31PjvNcVk7hb9xOY8NXSjsyPjziBSSYhKIVNz9S0YazMWnuEM8/AoiuURHnYEtIrkp XIn96PDQLfh+SwtYaJGi0c/IvXtf+CBLlz2+hAGvI1MsHhIehA4t4o0bdHh/VkOH/Op5zvosziF4 UBmNNVsw2lfGi7hZWZUi5lR5gAfKj83fsNJLFg8mueN/SmEyzqkgwGesbF4X2HAkiuINxVBHzDd1 OJTjKwaK8/74iG2SNGIhfQp2lZWxxwGMnFCTRKQiH0m2gGXhhNyn1l8fUj/LZyUmOIYHGE+ibRfJ TWnz5XBPab50LhEUbg2ObMBuA8KTJNVLjUcPhdkzX/Y3HiGhBImdcCuUPBnrdQfw6cK627o1sFyw pyB5oNa7JURwa7pZjvhKJ2uHCFH4YAvFJeNCYKLwUECorSlmVtuyMFvbBuzii0nQ27oRDrTYewIa v2JCSUYtmUJ7MdfKldcs+et7cJoJp6pJmvTeZGyyKbLzPB+yn+AVFzE/0E9ota3552ysDPPPrtsm p7nyJprlx6fGbuNvdmO6tdf4CPvJ36gEyLkfm4ZsZRb9n+NJ7x16qxrWc4KjHhpea5g9aBVchPxr bJEL5t+7hZVO9k6Ny7DLyRtYeVB8hSSNWMFIGIDvlhArvk5yPJkm9SKc5lTC5ruIJ/CV4qBmUPAP nZFCjtQfeUtoJdJZEUhIVzDEfiEcDUdI/cEXcg9/8aVc3SF9zk9ihQmHsLhTWzAIo3tjTZyL7FS+ zw5ZU4x5goR6QgjrvKJwXEOsjAqH5GBSme2SNQuT9jDHSZMxJNo4U5PqjiS2Y2CzfI/N8hFMTQQS uo0gDRJXAR1MfxHNEXNIbbCpxomRcjJfj4NKOrCkA4nMnY1o1S5nqrpLtXpjNzo2iXT4UFzZUTYy 8lsPgIQIevIzhBpb7kCIDqt7W5B4fzEk7DVySQIZhDjkJZIPk3L2FaV4a6FdCEzAgad442Q8xL3I xFzCEAXgmXQDwVSKr5UcSqN9w8lfoQfU2UdsjEhRh0JmqRHk3iFmkkTWcCGhLL2IT+y9HaF1KjkI 20NCGDGPyMJHiE+VgQbdC3MQGq7ZpAoN2Oo84mu5DxNdVqfnusHrosiQf7J9ygnbmruYrkwf9QIf txt14QDio6PBSAqnGp+MEt0e7moMDF01YVEtkSSaM95U7OBitGV9a1fm2h05HL65V9Kq1ZeUKTUQ +GPQ6E7SKFRWJpO6cR9vTq4IpVa/ijvtMQewMZwg5JF2VhFMzcZV3XNdFhqELHGIK6TBzMZuGhKU AIHHQgbJ+LEHag6GH6SyIKoD3k6RA+rrU1TcWfNlf4ruGSJPETjB7mD4/cNvsD2+luRYS+BdUzxp bmT3Z9/8WcUPzlrXZiYZcTL3L07AOKUZCnVvzfM+J4lFa85U1pb5nlPnqwnyJe7XZRcig8ogx0EQ YaRZfyTDs3oqeMrETVNiFfufsUPPeFVPhx37gsUkPutnj9wlJOeqycFHrQXBbu6HPhyukQZ8AQZB Jv5sxMNpvltnQ4ELp7YH/nh2TCkneOzv/GgoSIZ4Kfc5XicpLDpD1uLjbh6+QXBlkJ+TyBf4yIYD +Ya7bJMxyKR8xDbBSimzbJCcZXe1Jn1R1pkUAzZEbuUALXyzPbIZf2NltHNZi6FaSKFIUsZqD1bD QjaoxLP7ukJPHRrwDUu8j7Ml4YQm7pAHPDhJMKy3q4mPKYqTuyiQB1VN/aMdU0h2s86L9VN0+olL VzwpZzw4jt5m2SUzBskMnGEyGiUhxHacSrPt2ReuKBNrmVAurYIg21tGYzf4uiI/+C5Sar+WHEkE wD71pXyWd/oKK9r38LCrq5C9G+fg3XkeN+DdfR3drXiRiTJiDNlMfULIVusHmTx9r0f/vX8ha2GH NzigNKX/Ns7ZtRgMeZczz8t/i/EAZgn84DiaMkfIu4eCPx+Ga+Scvw5bd3XkGZyBkdtTjRQYVm0q rHxmW/zeQPYNfLeRo0FOmg6EUyjJ78uV5PfNjN79CdOTn/wem1n3zeTuZIdcM4XO580CGYdMRSQj /wU9rrnvZ9HlckqiONKuz4XjI6sB/8Ko8qSK5sy+UaS+QjQqDZhneWiXo4pC2G9foS6sYS3dKHsm 3P9w546zGrHLYsNo6UWdsile/lCurjrVFnUQZ25PsxnkKO72NAlro3omO7BQFdITAtEzZvjzZ7XF rKHFmVjxSRw0PBIRXeMg6VDkhWq4QfZS4GiSjXLtAmtnQaqrkLvpdYPU2WSR2+G5dlmqeZTcWqqA PBEk/TYBpZXKEtcOsfNjVBZiW5MjGcS5nFkfS2fP6DFwDmNXwXUreypjtOPp8yBqdPKhzFgrccTL tDthg6PpPbdnLBgRLfJp5jEz+TZvDuKUsXucQ6XsHiHmujy3j53IrG6XGuzoB5cBnWJCno2O3+po g+50bm1ghntUS44polb4kq4usuftTbnAg9uz3MhZDx3C5QcIAdY/S4jtMkGLwxSX9qFWCW8Pd2Vq JDEM44dznmeL9dJ2SqeIbeyoQ5bxL0QhYUHxmVwBlRoOJHzpYbL62Na6UTtAHDP+Zr1GX29YWqSC Y0CCqEj9S8XJaqg/5bTaT4YA4Rugp9enjbDTNzDGgQtda/Zni/PO0UxrcNNk6Nd1mA9Ox/FenUY+ 4N35r53igO+lEeQjx2Uo4gPQdwFBt3oqnwtfJJsImfWAAsmvctCHP95XflXbwUnFGQpKoZRyeMT8 KiFEJ5GojaZH6sQZTb83Afs+3wqWI+ZoDvlVexueN1h1V5ZeW2TueI7NoHs6fcijrLtpBD+x9zmM nq/aLhhdlY9mwLTDgvNkLzNgTq6A701j5lqY7FvBd8ozd1cSCAPcO8zculLq/Yp+0CAhAZ6RR75B ICaC/wGgv8lyCas71B0Kpxk6xFZqU87Yi9gwL3V91WoFNsTK/GBWffklepy9fOYe1QFw5FwbIDny R/ULUdyg1ddyRQ7PC7k2RX5iYLlNDGQsNuhhN4ecZk4MtSeJxxmxk2Zj14EvYssepEz4P4fiB8ct e8l3W3p89F65PYXeG5SCRZXJvInxPJBr7sEWvYYH0yFLSPRiC1p5LTBhQ4MH//AlmoAzOMDYpRzG 6qLGSVXLJGh6wzG8gLGHwBlsnx1wOH0G4ILyxBlaY+RDMmfAAqwFQAbypUbtWryRmLIUCz4gIXC2 AA4/RpRb9hHnE4IUYGSROMSVeRKCK/MkkjW2A8449LELLt7KDqaqs7LXzaacgWNWtmslWNlO7C2e WrgwsBp8iYSOCCZ3Fl94bLzCF65T1sonX5GqRC32NACiG5o1zjX4mRb22GoxG84hvHvZwu4Aig5O n9gKY6O2ggh7hujikQfLFu46nKyIzxEd4NjkAlaaPheydWEr4T2XGxljWLvgFPEmgxBXq78eZV5N W4wcIUmuSH0AK2SCHfDOPpDsRWggBIxzE0QabySN/lLhAtBuzV1v7ogKvOhZDwQ7yiOFlHfWeHnt mwjvi2lENRGOxSA4bMwx1mohlFYiqwsNOxxhYTJDxHbKajKCS7CoXGUBzh3UWMS3MMRm2c+wEcK9 xyN7tp+Ldb+ttbx7/dfOOClTvhmu3JNnCHCoGnB/hrkVg1fvn8g9DN+fshyPJ4aWBqCrAH3NvnRD kGh723SIzM7Ia0Q6M5KaV3PscYBJzD6cJgbz1UjeLjDBiLIiw8knA5Ou4RHHgQnN62pJkDRlLZGg R46m7OQ4LXy61w7MZohu7PIDKuZihi8izQ0+XDXpQte8JqSrivkGR7Q1YKm6/M6dHlZ+/gKTzThb kk9efH5xuNMn67LmjI+ilBMOjRsaQfO2Rds4w6Qt8HcDjsKG1Ll8Xb4of3WklgY7WOXNaijfFPJJ Od74ikJ/U4aHRAmarqkacS/kPMYZvlL5JpQVoex16Zb75ag7l6+IWJQUYRlIjs2KH7uo7nX5+/KH 4htPxq3+vU4d5Ehg3QNT0UwAD4yt1JKCJa9LjBa/hPGO2OEkt+55/LqpQToitJVJbWToA1Y62wWD lLPU0YC/dyPE/esShrp8RwnHvfknhkUk35EKJkKNyYpKJGbZ4wzHy7Kskvg9HIMon8ctpAfaItKI MEso0C4BDLoGHoV2Wu9x3CA+yIYDNnFYkJa9LnpxCSfwWCjr8YHqxg2GVUcFvv0SVa0PsUxLAD+b ElSdeA9fGhW6gJr6JqhJ6mmndAbWjnt6x0PxJdsntvevCvBa2Zb/PCBAnWQcNPKhwTfl+vfroqtl IQyT7H7rahxZir9wGhmgmHcoehX9vZauf/nfCyiOETRg+QK2RcVrC0s94U76IX+9AjRgHcr9/Rp/ 48s50qi7B2g0qI01yB16hbrlHf079Vf4HX2WOt2zfjTF2oJQwbctf2k/bGn8uxeogDFJTISgrVOP c2rAxW+ikh0Gibg2Pf35DKIspkKvIn1/IfcjitlbS3ycpZevN+EbwCJ4s3zoshGc7WFAN1hvlM+0 bZ2VgE8CljVOHZNkKucfRbehWkDgPGJ52LkHBb5aJY/y8vKN/5Qv4A45MXc//6r89bdv337/dyh+ Xa490gaNtrWNDroM30eDCeQXP9pK+i5N/ccjtYAIPlsop0/b+lNshO4/wymNXyEoqkMS7elUbdry U3LvavektszW7kIoiJhMseN2r91nnJB0RrtD3HF0t0gN1oAg7e7GVxTOAVerJNlvSOAEFYrtBkUP lT30wOM3WlSGoteyZbl3h2ZLJjbWntHdCViNL3aZp7Z1OQ1fHtbwnRtIM4uahgkU3wpUyuyto8Xp d+5WHna/CkX8u7iNFLssYAWdKMt2kLRVtcN2dyWx3GtZpGyxU7rrirUAQOm/lx1pZC27fOqiJLYK kPoJawMRnki7yx6QacGnz1W7o3Woa2RlcSTh/lURVF4oE+yhdg9lAXG16qiA7aOqoN11LDGMQfuh urXuXukUehBKol6FssunLkteiWl4QF2LXFFNNmKwrX+LalV1veA3r2hxakqkrhegsKpr/A0FLypd Ste/+HuL2oTL5Im2g59g1DXScMQEEF0pf72CAoWEuL8jde3unaINNfAOdas6ltZVHbO3kTqWkdAU wF+qjm1p/PthdYxjq/rJCUgOL0T6eIcXYvuT0nYx8ysXB365lNocGQ3yWMjJmJcyyvHFfK1jfs2F ENWkDmEGHFIVFPQESWnraVaNoWh7TEHX8pEQRu9W1QktvXVtT6tn18IjKue8+v+fqeYW0AoIcaoZ Jz6LUjnueBfyJhQRFAykiDcHVXMjYYi+G4sW7iiUICrTIqTg+SL42oJuM9qQbw0L3EgR/AJJCIyf 2tR1UjXjrFeMqh3gSYpqjm/RMMbqfnVDxy2sBX3Y/bq+i9u0apZhuANlg2oOJZHYh7KgUWVfDbby j6tuxgH8HsMiDzqURe/xqYuSWDe3I1KScWykjEI973acsFMAn4ALyhknwGMKkPtC5az3qCkAnZah pqCcQ1nA2lB3VOJ7IHWpdg69yimJ3yNlEEdY3yT9ol7pTKx915J4PCxbgTvMTeq9k2odAjSpWnd/ R2rd3XuFPEzjqtYhx3B+qKrxt1frrpRPR7/L2f2q1scRFmXshWM2xBQQtS5/qVqXv2O17nYiiP/c ag1erUvdVOuYaVHc7hn+Vbgy/V36TLXf6miCF+5G6k0KoQfVfigVzMG+FWdy+N83av+aD7AyAeg3 C6kiPzyIzElmMcyvDHTJGpclQe8rQ7mwF6NcWhaJozLwKqA7AJCAif33SBkntoyPwQ/y1NoaDJh/ sCF8qWAwqEe/DT0fMhha5CF306C5EsZkCDmG9/Tor7bxYB59dgvGbGhG8eib5jNIzZMP06VHVryo aG83LAjon7MbkJ/j7IZmxBdYWn930HDoEO5GctBcoC/YLOUi91om/fNlgDtZQBKthphwhWiSwBny +5FaCw/fPLet76T10IzyGQuMCm6tmA/mHo3LmN3vjgbuXrx6/7z7PXof9zQhcFxfFLYHAmL1wZlL qodZEBsQLFqFHuGyGsohAgYsr2OTk7iG0VMsyygx9gMIDEshth7kZEbst42sBzkLVz67pL3W+8iJ brUsth60bIVxrTsqce1Hnr1MuXy+NtgS6fvYalB6rIoAHqmnWmQ1kLArnrMgthmuPBPZEOGlYwaD eFOiqGEyw3BnHMD9HRsM8ps3AWYJbGnY3gmwGgwizPIMauJfsu1Fwun+zWWoMZ38GwdYWYNhgYb3 BoP85RV10crfscEg994YQKjU1cA71K0GgbSzloa/wFz+b+mTGgw6mtVgkJF6g0D+UoPBlDJG4X8/ bDBAsTWjwJ4yEqqjiKxsIl11wnWITSTc4eT4gpUuClZTga9cSnos1+zMpQxnSXpcUwIhSJF49KHI Bv5FmLFmjGBwFPiHu7c5L/GYjQDoH+f2UaP+WEJ0bTxeYCG7hZSN0H4GQ30b9u+RK4tDp7CYDQ2C THvYZvii09CiBOoWofO63dI9ZM9ul6bXdXtGiPDJQnyGBdqDh+MU3eQWW3hxiy04UNKbZsjAcGkq SD6STJ251JMTeSeZGEP4jWfOyCZ/fDzzIo8lPSyc5dmGYQWT86vvf3z1/V/+9vdvXxc//gErIRh+ D29DhomFfjmSoseOQsBEPJhPn75pyi/+jMVxWTwJzUnwGKleERXhDGO5/V5E7BasAeLYALdghcNI Ixr6iNhpGro0p0DDwiau3B5UIOHnbwHmb12//DEfWNdMb03Hua6SpYjF2+uDsjZ7AcZg+o29SIYO uOT63D/oZMhmb38g/43JCKK39tvxNQ4gdulYuOq9pGNhQ4TLxkIxs3X9ryGHN97Otz6kVdl8Ya2Y NfmHQk2SdweCSTIfLpKoNwV5ekdU9Eu7sAHg8LqIkOPpFC7EZORMS8YxOs6ULEkK5HdzUSgJg7j8 FmcGIF+SjMKR8rfv/CP8bUNWToWS1T1U3LmER+TPEYJIMl5Yu2QlomU+wtrdcSOYLTkhwv3ovjnO jvAZjiM84p7kbzqRuD0qlPeB6w4B/H7N5DVQY6VSzotgCr0kkGIiLDk4Ds4cvqeQMwyHzwTMgC0r PJfX4FmM1RnQrt0XBXwUoEN7GyzbOWYjaDk5qLmRANib8icvLUBHVOMpG6RMxuU6g3DfARgsxbf8 hGQu3zrWZHcoVORwFlqkYK90O0QVcWhxXReenNoB67Sj+CGewnZik6p6gOmJs4Lk7Fx838kpzaOs cC8Jwsm5OJuNvHAL2JJMQJnBb5HMgA3vo48R4byij3EAzoIgLrtN0/WG4LPbzyH4cq4+OyzpsMA6 8odss8EdH6VCIgBGG5TwCJNqFWuJI6zGMaTf14hHLYBGG5SkKf5oYZ46g22wU9Hen7V9AjhrkXT0 VTsqs8dzssPsznze4tgGVy7y7dYZWnGll5DUooHNG7Oy0WgkudFoggz+s7n5Gs1aGAQIR6VgWNxg hJiPrxrLMUAEAbyN/bKyhvxVJL94UgkGR/L+aGITDBkci4Xwgu4HvjFFlIb9i7Ng7icwlMlCZYIN UlCz7Cg7aYhA0U+UFTgQHEmeWz/xmgbN4XTZrz8hunodf477OA5/BA1gYgcfxw5rxdTdYdktYs7N Qc7UjvurTo4OK2UZbJMZKpuPtxIcoV98KXGf3m6ff0bHlG1bLI7XXThE0LDtO/EpkQx+e1RHfcq9 UUWGGPItC/NZqv8DZJYgrQplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjEwMTY5CmVuZG9iagoy MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjUgMCBSIC9D b250ZW50cyAyMyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjI1IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBS IC9GMi4xIDE2IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKMjYg MCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4IC9IZWlnaHQgNiAvQ29sb3JTcGFjZQoyOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NN YXNrIDI5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp4Afv/HydQKHmpWvVKoxaBIEqBgiY9r62nvIFwgWwIA6gSKOi64C2Eq98GFYdw7aZD1QOV QUSwkgB/Y3mJCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBvYmoKNjEKZW5kb2JqCjI5IDAgb2JqCjw8 IC9MZW5ndGggMzAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOCAv SGVpZ2h0IDYgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGb9h8MpkEoTBIm wcAw7f80IAIAVBQq9AplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjI1CmVuZG9iagozMSAwIG9i ago8PCAvTGVuZ3RoIDMyIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUFNcXx9/MbC+0XZYiZem9twWkLr1IlSYKy+4CS1nW ZRewN0QFIoqICFYkKGLAaCgSK6JYCAgW7AEJIkoMRhEVlczGHPX3Oyf5/U7eH3c+8333nnfn3vvO GQAoASECYQ6sAEC2UCKO9PdmxsUnMPG9AAZEgAM2AHC4uaLQKL9ogK5AXzYzF3WS8V8LAuD1LYBa AK5bBIQzmX/p/+9DkSsSSwCAwtEAOx4/l4tyIcpZ+RKRTJ9EmZ6SKWMYI2MxmiDKqjJO+8Tmf/p8 Yk8Z87KFPNRHlrOIl82TcRfKG/OkfJSREJSL8gT8fJRvoKyfJc0WoPwGZXo2n5MLAIYi0yV8bjrK 1ihTxNGRbJTnAkCgpH3FKV+xhF+A5gkAO0e0RCxIS5cwjbkmTBtnZxYzgJ+fxZdILMI53EyOmMdk 52SLOMIlAHz6ZlkUUJLVlokW2dHG2dHRwtYSLf/n9Y+bn73+GWS9/eTxMuLPnkGMni/al9gvWk4t AKwptDZbvmgpOwFoWw+A6t0vmv4+AOQLAWjt++p7GLJ5SZdIRC5WVvn5+ZYCPtdSVtDP6386fPb8 e/jqPEvZeZ9rx/Thp3KkWRKmrKjcnKwcqZiZK+Jw+UyL/x7ifx34VVpf5WEeyU/li/lC9KgYdMoE wjS03UKeQCLIETIFwr/r8L8M+yoHGX6aaxRodR8BPckSKPTRAfJrD8DQyABJ3IPuQJ/7FkKMAbKb F6s99mnuUUb3/7T/YeAy9BXOFaQxZTI7MprJlYrzZIzeCZnBAhKQB3SgBrSAHjAGFsAWOAFX4Al8 QRAIA9EgHiwCXJAOsoEY5IPlYA0oAiVgC9gOqsFeUAcaQBM4BtrASXAOXARXwTVwE9wDQ2AUPAOT 4DWYgSAID1EhGqQGaUMGkBlkC7Egd8gXCoEioXgoGUqDhJAUWg6tg0qgcqga2g81QN9DJ6Bz0GWo H7oDDUPj0O/QOxiBKTAd1oQNYSuYBXvBwXA0vBBOgxfDS+FCeDNcBdfCR+BW+Bx8Fb4JD8HP4CkE IGSEgeggFggLYSNhSAKSioiRlUgxUonUIk1IB9KNXEeGkAnkLQaHoWGYGAuMKyYAMx/DxSzGrMSU YqoxhzCtmC7MdcwwZhLzEUvFamDNsC7YQGwcNg2bjy3CVmLrsS3YC9ib2FHsaxwOx8AZ4ZxwAbh4 XAZuGa4UtxvXjDuL68eN4KbweLwa3gzvhg/Dc/ASfBF+J/4I/gx+AD+Kf0MgE7QJtgQ/QgJBSFhL qCQcJpwmDBDGCDNEBaIB0YUYRuQRlxDLiHXEDmIfcZQ4Q1IkGZHcSNGkDNIaUhWpiXSBdJ/0kkwm 65KdyRFkAXk1uYp8lHyJPEx+S1GimFLYlESKlLKZcpBylnKH8pJKpRpSPakJVAl1M7WBep76kPpG jiZnKRcox5NbJVcj1yo3IPdcnihvIO8lv0h+qXyl/HH5PvkJBaKCoQJbgaOwUqFG4YTCoMKUIk3R RjFMMVuxVPGw4mXFJ0p4JUMlXyWeUqHSAaXzSiM0hKZHY9O4tHW0OtoF2igdRzeiB9Iz6CX07+i9 9EllJWV75RjlAuUa5VPKQwyEYcgIZGQxyhjHGLcY71Q0VbxU+CqbVJpUBlSmVeeoeqryVYtVm1Vv qr5TY6r5qmWqbVVrU3ugjlE3VY9Qz1ffo35BfWIOfY7rHO6c4jnH5tzVgDVMNSI1lmkc0OjRmNLU 0vTXFGnu1DyvOaHF0PLUytCq0DqtNa5N03bXFmhXaJ/RfspUZnoxs5hVzC7mpI6GToCOVGe/Tq/O jK6R7nzdtbrNug/0SHosvVS9Cr1OvUl9bf1Q/eX6jfp3DYgGLIN0gx0G3QbThkaGsYYbDNsMnxip GgUaLTVqNLpvTDX2MF5sXGt8wwRnwjLJNNltcs0UNnUwTTetMe0zg80czQRmu836zbHmzuZC81rz QQuKhZdFnkWjxbAlwzLEcq1lm+VzK32rBKutVt1WH60drLOs66zv2SjZBNmstemw+d3W1JZrW2N7 w45q52e3yq7d7oW9mT3ffo/9bQeaQ6jDBodOhw+OTo5ixybHcSd9p2SnXU6DLDornFXKuuSMdfZ2 XuV80vmti6OLxOWYy2+uFq6Zroddn8w1msufWzd3xE3XjeO2323Ineme7L7PfchDx4PjUevxyFPP k+dZ7znmZeKV4XXE67m3tbfYu8V7mu3CXsE+64P4+PsU+/T6KvnO9632fein65fm1+g36e/gv8z/ bAA2IDhga8BgoGYgN7AhcDLIKWhFUFcwJTgquDr4UYhpiDikIxQODQrdFnp/nsE84by2MBAWGLYt 7EG4Ufji8B8jcBHhETURjyNtIpdHdkfRopKiDke9jvaOLou+N994vnR+Z4x8TGJMQ8x0rE9seexQ nFXcirir8erxgvj2BHxCTEJ9wtQC3wXbF4wmOiQWJd5aaLSwYOHlReqLshadSpJP4iQdT8YmxyYf Tn7PCePUcqZSAlN2pUxy2dwd3Gc8T14Fb5zvxi/nj6W6pZanPklzS9uWNp7ukV6ZPiFgC6oFLzIC MvZmTGeGZR7MnM2KzWrOJmQnZ58QKgkzhV05WjkFOf0iM1GRaGixy+LtiyfFweL6XCh3YW67hI7+ TPVIjaXrpcN57nk1eW/yY/KPFygWCAt6lpgu2bRkbKnf0m+XYZZxl3Uu11m+ZvnwCq8V+1dCK1NW dq7SW1W4anS1/+pDa0hrMtf8tNZ6bfnaV+ti13UUahauLhxZ77++sUiuSFw0uMF1w96NmI2Cjb2b 7Dbt3PSxmFd8pcS6pLLkfSm39Mo3Nt9UfTO7OXVzb5lj2Z4tuC3CLbe2emw9VK5YvrR8ZFvottYK ZkVxxavtSdsvV9pX7t1B2iHdMVQVUtW+U3/nlp3vq9Orb9Z41zTv0ti1adf0bt7ugT2ee5r2au4t 2ftun2Df7f3++1trDWsrD+AO5B14XBdT1/0t69uGevX6kvoPB4UHhw5FHupqcGpoOKxxuKwRbpQ2 jh9JPHLtO5/v2pssmvY3M5pLjoKj0qNPv0/+/tax4GOdx1nHm34w+GFXC62luBVqXdI62ZbeNtQe 395/IuhEZ4drR8uPlj8ePKlzsuaU8qmy06TThadnzyw9M3VWdHbiXNq5kc6kznvn487f6Iro6r0Q fOHSRb+L57u9us9ccrt08rLL5RNXWFfarjpebe1x6Gn5yeGnll7H3tY+p772a87XOvrn9p8e8Bg4 d93n+sUbgTeu3px3s//W/Fu3BxMHh27zbj+5k3Xnxd28uzP3Vt/H3i9+oPCg8qHGw9qfTX5uHnIc OjXsM9zzKOrRvRHuyLNfcn95P1r4mPq4ckx7rOGJ7ZOT437j154ueDr6TPRsZqLoV8Vfdz03fv7D b56/9UzGTY6+EL+Y/b30pdrLg6/sX3VOhU89fJ39ema6+I3am0NvWW+738W+G5vJf49/X/XB5EPH x+CP92ezZ2f/AAOY8/wKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iagoyNjE1CmVuZG9iagoyOCAw IG9iagpbIC9JQ0NCYXNlZCAzMSAwIFIgXQplbmRvYmoKMzQgMCBvYmoKPDwgL0xlbmd0aCAzNSAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVxbk922DX7Xr2Df1jO1LFIUJfkt TeKZZNLWrbfNg5OH7XrdpHPWdnyZ5Of3AwmA1OWclY7XTuwHHUIkCIIA+BGk9hfzD/OLGWo/Gut9 HVrjx7YOgwntUA+DeXtjvjevzKMv31lz/c408f+7a7Rpaju2oWkSKZd6X7fWN4Ppna8HP7rq+tb8 5dJ4G9vy4/LWPHpi68ZYc/nSPDcX5oF56O96VEer/Jyav8JjVC7vE/GnRLyZvPvuQUU1v0vEvz0w P5rLb83Xl9DHPo3UY9MNg/NVU7du9NYOUI38Oqkp29radX2rmjIrmqqmmiI9Xf5vJqdv6q5tmtZ0 Y1c3zvTe1eNy7iqaKkgUQj12Pao5VLOtg7zd0AyNG81Yu9H1Q6B5f3laEdXcNEQRxfA3KiKbjO3q rgt+g8nsUMRCUjFiVYSFybvG/4EU0YTahTZsUAR85wsYsbVq9v+kojMXT5kcbbwSD2NPuaWXcLg3 eMIPDnigxD4iL7nIXsXudJU8h0vM7nViM/W/v3If/6InBHpGT8h5Sc+G5I0OfYViFoElYYa/clMO D9coDuZi2ttLEH11wZL8N3H7kB5v8eiMvGPxuArznEeJGBfwbiUgbHQ08YRjISHZu+kbj5qDN3Zo 67YdxRFt053jf2LVx0Mzgk3dNxSa2bxSwKnuCM0yXTxPrFJWIpsIK5FnlI2Ka3KVOE06Fb+l+eE5 eI4SzO8rPMhQkkFXF39fnYVNC5XMQY5GxWycDMst1q3R9+NMS9MFbBaW8wI2c513GBEMlh+swaw6 srFquujstLE8vvyrwvhaR0tByEbWouxt4Bi3zcZghtXO5b/txnp0vtupvT8nA2BzWF3NT4e1jUa6 4tRr5nR0yTjuXN762vYtaTzF7g3OtWMROzoVuoghmrSulwn+2NX87miiq3YYASh6hJUIX+6KJhy7 OURw3DiyipTLA8fuFzCUjPAkYHyTzAfxIsYPNqOJL1bihMd8kdjyux83x52FoSzjTvZLAl/HDciG sR5csEb0uWHxv6g3w8HdkpI8PaAt5OnqYLtgHAystaOYGGIIMb0DJ9JSNokhpzREkeuEhnpXNwGA WTS0BpiNAOYqbi32udhUUvEBcTFSRNN6AvgTwDz4/hxFCPvjA84uNvR16IctFgHb37hBWFiECKTj Hboae4n5cM/cHwj3LcPth7odOrchoqzO71pIj3ZYnbeVDXAFh13Rmfuzo+JMd9bYn500/2wNtMaO 2LityLPF/DfKgwnbKk9DuPLsbduaPEeNc4v5eFv7Bkvh3QvS5zGf1tXWIm6szNcSSH5Pi1hQoMzr Hi+UjKUZWU9R081kY8Zr4HRzheXiaAqFG+jjeLKFq3xNgmI7x1CeV3Reykvsr0svN5RVmwfDmzou yaL9H3DHijwdMO8v2vSuSY+pFtzknZ2UdGyshTuHOG9wSnuRGW9knqJbUs0C8BfYZUyi8VhKyFHt y0DdHVjbpkemJwRk9ZIlfpqF5DmyeRb75sa8SBnDL59h7eD8WAGDclro2ZeL5f5hTiXGtGSPzXFn SWDnkLTyGMGIfwZl2w0GmUYqD+ZgnsWEVW5O6a4T3Gw3ovWI1Cda3xrrhj6XEzdNe54aBGEW10EK C68l8N97hB6It6AdQMMOnPZGvnYtEDNRAsAEkgDSsiLanNvB/ASc9Typdh4B18eIYFNZh2RuZ1oA dIySdDanHOK4UUc1ESm2bEUU4lMpHxKHtE3TbWmR6AbKHGIMLbbOSKTdLigHJCfBte2Q7uRaVQeu LfJ9oMAsHTKXSgkjwHBPIXOFtqiVOa2265s6eOQVSAbuMQQgjBEWoFIFoJ6u70LFY5EyJPCdq50D A6UdjPdYgwGPM837obY0GuFdZYpIAF5aS2gbKFXZTjRDMnCPqj+VSnScZRcK8ZLxCG0T5TraoDO/ 7nBZZKUbJE4QBJL5TcsH0zYWRgH/0zpt46zxrsEC7vCaCkiTU3MIPimfLHHdbojRghwttu1Gj+4A pLXjQMZIwkXRtASXRibcaBlO6YYklNIQjyzshzmmkvRH7emtlE+VuK6Ok/pCW1GCdqw6iqJpiUXV 8uRtNSnBlpPjno7KcGg1rYDxuUAuXZjz72eCs0CDYKkOrMasTq5uoZTV8MCjWQkid7RjzRSOKNqC XGlb7DtbD61HTOgRHAJyvW2PUzFg9xZZoga76fn+WGMqhflmDANcSM7YtKhsEdn7vpczNiwtVJUf shFGiMYZ28W3T82/r969u/kAaCY7xI/qo8XK7EckLJq06UAM567+9Il60APDC9M/cs0jHCK4xwji T3HSIENS7LSeSJV9xefAKoS2MHmWwMAfEqswCplglQKZMFZhRDPBKqnWFKtoy4/BKopDFKsoRbFK gUOA2girTOpErFJQ1rFKCF2NnG2GKkIoQgqTisgQgIPGdiiBhK2REvIToBKYluMHU0pOK+2wnvfB +wlQ8YAliBIa5vC+DuMwKE7h8gSnJNoIRooIuB0wr6CGwKyFUAXpv4z/QpNaRmstKbldFUQHZXQU 7WWheBIUkcgkZJACTmmiFnUWhLMRSkAguWUEgJ8FLqE3ETkEi51C4xiTBGCS6NmMM6QMXAHEIiVu Oa+LBCrDkR77MkI/ikZ62ye+hEYqLfES31sk2tNeR0GB0iJmEIaxgCwpjIJ+VvRTafqDgYeKy8BD h6qdkBYSHrINYJj8XPmxG2BUoUOSESvkbWGYZ9mOGkq2HSy7221HcX9sUiIL4VK486YwkEYGTtlT eLALeOC72vWYJIUHMLcOu6UJPKhwA2cfPMBG0nVyMiO4IMGDWeLpfHjAfXBKIUOQ+4MHW3uYwAMb CB5Y9xjr7xn4QLf+EVFxHlTxVwRkGZ0pHEOw7PJJWNYF1Y9wzMuVp4snr9/eXr1/f/PiccYuJ+EY ttg9mQjFX+pkoXDtpNDDRt7Ymg/WAabu4P3k9av3j3+4+Orm5dWHw/sfHmzrqgPutZ4umO3oCmk4 gXenVNThzprdq6Iv3v58dUAKcVMHnUes2qmnrcIjEdQHnHnsUYxFCnST4AGCj5/GeDokToa9SnmD fLYIfhKKF7c2zkgbUsYdyx1dicOlDvyrPgaKR25l2hDc7GAn8JPSYnfurlsscLh4R0k/geDVkgaQ QAc9FE8kOUjAAdFwaJCb0LagzflhzTkHhGM0bgKnaXxEqQo4TSOepQchzwyEz/gUCUMcy+aEYfBY SFvMjyYMlVLCcKmVF2Cc8AAdFXC6BTwDFprAcKHlZkcpQDW5loNBD8jhlvlCXAoK3tEVS6iDspgB tycH4EGBDVy8rjIsZVIJwpmUAYHwLSjcOzghRKaMoki0hZJBOIBo0soEgiTVlRsDnoMsuOi7RFJM K4YntdbakfWdkSqMV1IpG8doXMsEmDlVqLSItRGOc6qwh0jRyxmWSzkB8SMlrosbsCkRSF0BxA/I QU5ThYOjY1dJFWqJ8bCWi1Sh0iLkVo6pJP0xCtf+p2+nJa4rI8G8xveiBAXsqqMI1bXEomp58jal CvXdbiQPa2vrgS4Wl6lC8bgSBO+xwE32tmaB4pdipQcEC3FdoWWXZ5EyQeQu44KM71B4ptLmCT+H 5FjjhtOIHnfqEQ/p/1aECfjU9sg2xDv1c4BZFXfqzwf0qYsFvLw/PL+xgwLG9o9+FziPsIuMblJ2 NVc2PmC4DzSf+lho+z7A/HbWH4vlt/e0FQ0rlN/O+jwkv53/VtEVyG9nvR/Hb+e9VWyF8dtZf24U PwAPU9pNUTyO02Mabs/hf0bxaN0lbgMuLHsuAvZtAvG47IvML07G6NCHcsIAy0xCvi2RkLLGnUXb x1uUfe07nGgTDaENL7QlkWbMBMDjUtiLjQeuNLAB503FUOYEAAYMNY4aANCnuw+gYbUrWoEwZVPA 97RUpcW1CtgbeBx3F/BdKCV8F1peXZHdQvY5KOauAhKfvsERe7neCq1ox7WWlNyuwmklshlQb4nf ccOg6/FtVgYBDS6tddgxCFCQcga94MR1SggvtIzFhXdBYQkyFs9SLWstKbmdUc1kBAVtsf5yIl10 nKGQUPJ4sGfh+ZJaeQaFkuucnU0fcMQZvZJBvJYLEK+0hLVxEoHZp0N4Qt7Y4UYvF2TO5enbWYnr joBdHBEir7Gl4/nivH+E1ccK8bxfS4yMx7SBiBdz5LxfaRFqC8NUkN4Yl2vv07fTEtfVUTKGH0QH CuJVRxGma4lF1fLkbQLx+u4MEI9dFi74wqULkCuOmE0QZrndBMsrJwsTzAa3ZoLinGy4iF/ZgcWY i2AwCyvZeXJ4AC2NcLIpllEvEvMNjukoU3PPiXl8LNI2+FhkBcffW2Ke+1hAy/sD8lt7+P2RPJaE 4ETfnwrKcycLhd8Hlt/B+2PB/I6utmJLRfM7eJ8H53d0sFV4xfM7eO8H9DuYbxVcEf0O3iWkp6s0 vqNbSIBJdIOpp1StRa6kc6DgC0Mknrv47cvkC5/yyGz9jwTwgRmOygccB9FNuxgIq7aPbfkRT8yw ngNzpj8SEC+O41o1XQrHV5UHPPijZZTohjw+9eV3L9JleByuPWzjl9HTL//Wh9VbnL/IsPRi1tOb t9c3b95/uDpUb3+GSjB8D0BPXo00foAmPH2e000G8+ibW2u+eh2vJK80iAdJOATrcRus8fHLidxi o95VwPKPM5z+girrHV+04BtXWYBW9I6Ynb6gyt+2wu6KrwfoQz6oPROnGo6Xt0/fwVqcscJg418m UFvLH1rhzNPi3lxLg8bVuv8DzxCA7AplbmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjM1NzkKZW5k b2JqCjMzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzNiAw IFIgL0NvbnRlbnRzIDM0IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMzYg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgo+PiAvRm9udCA8PCAvRjEuMCA4IDAgUiAvRjMuMCAx NyAwIFIgL0YyLjEgMTYgMCBSIC9GNC4wIDM3IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xIDI2IDAg UiA+PiA+PgplbmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngB1V3Llt22lZ3zK9iz8loyRYJvzxQ57cjLXlKkcjxwMnAkOXYi+SHZ cXd/fe8DbDwOLy8vyFJJFWnAIkgCBwf7PPG4v5R/Ln8pp6qby6brqqEtu7mthqkc2qmapvLNy/Lr 8sfy/sO3Tfn8bVnb/2+f45u6auZ2qGtXFO/Grmqbrp7K0XTV1M2meP66/MN12TX2W16uX5f3/7up 6rIpr78rr8qPyut/ln+8BjWb9BQ3oafpq74futLSU2zR80159eij8uOuvPoRl7m8+tXdvXR3b3Dp w7OXHxV85W/l9ecZnTjA1KZuqmGYm3JkJ3KY+vHtMbWpMcp93wZ68pj6KRjXmPKKDPzWsfM7XMBq 8hhQkLsSXLUX3h27vHAtvEFlGLCT9o4NWJEhBc1gqsHM84JBJ1JQpFKQO2CrACo2pbIZeojlYC7R 46SysFIJKfjBDQZxzxHCeOUzrtipPppxqOpx3KSzWGiPG/ANY7nNt3GqxqHdyzcC/CcHv1eOi7jc It+muepNHTWEk0gNuPfJuNlUpoa29RprjZ7SD2QAHBn3c2BcPseCoSryDBWYVTVjc2c4Zuq2mvpx qVP1CJ5yrHGsqt0laM98ffku9OznaH0qr35zppBGk7QYRWAkN3NkD5h8M3VVY8ySk5smP9sFscq3 OOgS1UNlhnZYk4WlbOa6RCvG4JJSCy7aMA/VPMJX23LRnGzu489Bl3GYxmoYJzo3dVXXHRxM8TGv n5+RA+9AOnbZF2/HjYQdmIeuLUnjGssWQwj7SRF4ABGAovG3lA9aB/ootLH84ndIknhK3zvh4atv nZjpV71T9VgawSf+3jf6GatizVSt9IWob1mj9nb5QdposfDS6B/wFX7Ayl4LPXDh2CCdh/91HaJ7 598hNeGh1V5/d6+yuue4g4ohJ/yH9mHhGcs2yDR+SKo8W86zSdgXqtIWnK1qF5WFdF/ZDHpCxVZc iGVWBBcR0qY30vZzNUO7eRDmRAGg6yS06uqqb+u6Lfu5r2o4N52p5umsph2gJfrRoNW+wqsI/fqp nmozl3NlZjNOg/Tlu9sL3aATqnbqjRO6TT0ehY4DwgtHia4Yh+5bZ684rAQzheAfHqgWi5fR4+S1 wlcnYQtjSY0ej+AV6Bc+UiG1FC8SzQ6lYrkMntiTX9E9EKOl0/fkASgVnfSZXKE2nvBeawSyjTGu fkZGUTC1tLHN31Apwme+QrmE7Gfa/gMiYqapGhr4nR4zGTICzGjNwTHRA/aD4+ay0I43uruvS8WO jAritqprTB+6lGF7bmKu892HAfIP4b/sPZyTSgKc2CFoNF5pPhjC880ASwsvwlKj84WD3qpAXotJ rIN1JUp1u8QApe3pQkq+cLXbp4UPk71Ik2TdOf+QPaDwEE0BcFZgKb6Ud75JQr4UQiDUX5GgZ3KF GF/LFV3ia9RsJIEXVvg7P+Wr2rCyNTLYUlJcUReST+QzqeQHWl2yW9EQ36JNbMeqrztkLB0aM+Q9 WzjOWsSM9OcgtnpG5iAr3cix0BcCkogJisdihGPJcQqjnqpbfrCKpoB1W5kergDG1JTpV0gSmyUE fnLWlIKnX2F72p0lnohOfsc6qW1ZNfuge6Tp1O1pcNLb1H3gK4ETtrcUBlatB+ATp+SLy/HFEbtl g7J6LD1u7g6O62pEIJaB42y5svw5GEMPXVN19bhqdc4GYFqutCPFZ8+oSAkSKlDqOhYGbFqssFAD aKFjLX5DUPHXKzSCRDSlVqtlDWcNYGrXv34EEcP3pMO7co+p0P39A3bFu3YAbuKUBimw0xZabChu LFwYCl/9aXOwpokn+cg1518nsd7+aWOrGft3p0E0TRftU7lun+izvtjrmu2Z7Gq7Fmn1eig9Ku+M 1LamahpYxePWh+OmL1ot8xmRC06Ls88LAcwB5h2lgzDTapnPWKf+XMuYR5bGeXEphEl9RUIMhGT6 7QdcgWbuqm7sG8ylqsGQvNaUmdd6DkIRvt9eXsvUCP1ncZ80kVvTo+9HzxtTTYbuk07+LdT8PnJ0 ajI/1mlazK/Mq/ScJuW10PBOA5yFPuzmQ8L+LRRhTHYFcUnNTvStRehYG1NmtFqs81+usgj55AOG Ktr2sGrW6Y2WlcHiitXwwndCkGbNG9ul4uabVAshhrCGTNfCzuvuervMV1lpqlYKnxTUH45OHVXO GpmNu949E+uaqQ2OOHjItY+wF+VAJN0ZU4G5fNNmrYvYJ2kHHbweanPusiZJzqUVViXtGqMsEXII X23oQ8+KF4KMrxDcFA7eaactxAvWmeIzvslaWKeWNEIdr2Qi7oj9GVpkdesZWd6Uo5vp0/czwsgj D/36tNOH0O091hy0fc4sGADHCczhsj6h5iEaeHkCZSzOMkFFjPDO+8iEDJWcBmXqCoXpGA14PXHC hrfd6FQWgoq2ypytU32zMranFS7J/X7Nifcu22MRwtVJKlfO+skWZhTYGurPFJZV9by9QMaMI9a7 jU2ZD4Z9sqL9jkszPWGKth/Gqh76O7OKru/Hah5uEn0/AgSQwNTYoQAQZS8chKgkiSveaejdc5UR NpQNQvbfTkT13AUb0po6Akwo054VocgWfnaUvSPp1dWQbLa0La+WhTRaXHVBQjPklZ3Xs62Br9aS kYgg0jZ2QtX7BHDXLEcNYHUTBDAbYTcRwGzHv+8woTT6PK4ORDId/13Kr/AOCgdEY5PjQuBQhrRu 5jPKUBCCNPrVEqWlRldGofvRwZ6tg6R9ONAplW1F3Mxj1Qwz5qZ3MZ7ule5ZwLTtfGo5w5xkEEEb j1CG2OtVUQocsXWSI36EH4k6Kq4e4yJWjk8XZp108EICtAPKZ9VtBiRt00DghsDnuxKP9O2Myf67 k3DGSomqnm6UcH4geIDTpxHIOyKXZopqnyhLp+FKH3qfkdAUj88gr9IgEcxKt4SDUNVBcysWtLjS RpaA5QdPCfUn7OIX8klAPrvhBYDWk/aHxPmHvKVOI61sbIXyYuFB+Gr4xb9ABzIorFQzXqegyXj2 hyoDjD+m4mBX5P/2Mp56rrA7oi+3oAXbohaHg76TdTzZWza2VW50Ng3meiQZeHxGnyOlFSnxxzEJ w7/iaSwAw+FjbXoU2ZIdsDDDQjXKUVw1ftrxZC3B50tpYnsamJQ+EsrK2OwSQzaqYqEyEeV+ExFm 4TWkK+AcPisb4eVahDGub+AXgTrbx6B2rLySw+fFzTrsmSJxIFfRmhHLxSVXoSB4B3IVsJI9lsit SMQiVXEhGaVn6rdgx2dZIpQqWw7eK+h+IEJLgq5Mt+41J/FBZFvwB7ki6okkfs871u2r0ZLBd+iN sgkmKHQAQvL5ipY9NqgRrDm6J17SkLfiQJKCbrpF9W+QCTbDDPV/HlsfRPtjKsjUN5rioFLhUGql 4vERMGRhqjHEUb+nlJqfhqaOBr5uTw812PbYmR56SDFjUw9B8Ak+PXHypWhhSOJXckU08EyuTbFc qnUgW8fo3wJXZ+vI+RM0Jz4ZX6HlCs6kHQ2tGPimFj49thw+Cmb43FLGZ9re8nM2u2qgWUvQQ3Yq jJXhu8zBP5ADbGUKFN6PHvvNkP8mKYhLbmJwy7CJtpqxpjUjQjtnhJYad2W09VB+StD6UNbfP7Ag jsuGOYdPUaffxcsqcKhh+crSf3rXdGljRJj6vjxCXyCfvot8utBTtIPUTITvmWg9F5sHHCTZ09RP I7ZnOyxkOCQ3wWZ2eqybsF0c04dr9CzSYzehJ19WRGra2u8h2lrGcE5WCE3CgQA/gxlCiDAm4ClJ lAnqOIuc4orw99WxLSpxrbY1dgk54pBUfeMQ7GtbAFqbUV2dEoWYsfI1nYq5FZWLTlaIUlbNktbs WgWQIBYyU7D1wd+yTcEBcWtlWcyIzZgd8eTwvekH7MP3wdnxDhu563Y1Ql/EI/vI0dNT+eLf99Xc 4qCIlfhoIf654maB5nG4QPQjF9vkilvpxc27YqkMhNjmHQgRsm1w8B7TZnriDwmRtYAU9v9wITIT jgWpOxgthZI7IETdUA1Ifa+A9oMIEbYwtP2NppioNoPN2hKip5IcBlyjSy3RAbFG0XoBKKOQ7g4L qf0Ztj+0aF8uvqJ9guI+4Kdn7txvRqQpsXCx7DYYtxhIaB/dGZoWcmxLBywT4KkSCZk3L/PbOiDo nIuGNCRwzugAqyZICQefo7Q0pHYgtw3pLS57a5sJq8uwF9+PVUYQk225Dhj2GFSZCQsr7s40UwdG jcONpploLDUOiHoK9NGVFayF2HpK0c+c9LEIpONLpbMIsji/TJSysS3MkpBnQgjmuf5kCfIWuAgp ly9QDjXmhZNfsX5SxAuFyCeb+Op3zuHgQ3r0fHZAhu0ks9YfNPWsk30O0xG5WvSAJLSml22lsM4K eXfAOmN6DG73qk95qtXJOH1hapjDdmagnRXcGg0aM2KWY8OWWLdtKah1JxhxMzXxx0/ysqM2d8a2 dCRJcrgPLeOksQOokOUXQ4Nlyp0ahbuACjiTU85ETLb5WEkRZgc+7VxjveCNkuVEkEauV6laB3JN JV91nlc4C4P6npChjtLQ54dOXYb9yv8H7RjnyPnOlidULpYCrO4G8sr2MXWyv38g99DVn7Gc7QUt anHPvlB+KZsHoiFbGVsgKyh9ZBOr5jM2e6spBYMTunCymSk1dD68ZLUTpjhxts1dCYfa0VRtnZVS 3JVTWEsCiOvg7IBGiVfkFEPigwsYHgHByBuzkAC2che2x/A7bUD2SVjq4bMpVuAlKlvCVjYTRQnb F6ftWdJpsIIPx1115daInlr0A+JuvTzmRPVAfjBxB4KracQRmbrzd0DcsS2kbu7O7gtkPqqxWfX2 FhnEmxj2ixMIAw6H7XHICsk5GqYePFqp7bEYc+wHdbZSPc/i8dzu2UqtHPvb+Azuh4Nn4L+iR0++ LnTFKh7WB+DE1bPr9LBKz59t1eIIrGEykxoA7Pecmts+3KptcTSruTPJSJCCCYasZOQq/7PXJG6v kQx5Gjn9aOzqnMnvbHoOxEWRHuxT6Dqfp9mUF3gnX4uzO4SDdGnHV6O7ey7VQBu/GnPSq2A8Wzk3 hB8sL9Z9WBZav2W18I9CKLzz/8EVGRM6y9ZLDjsSSBOdGlbjnRE+pDfEO5/mCWtcrF/OEIUVtK7F 2l3u4QLfis+MehbPDhUSae5Xe3OgcIVfDIUWIRndE/aQLc2O0E4uxVV+HHGil2CnLq4exkaZBluw WiLxdkzVNzhZs0H6qS5fuO0bD59BN851P02mw1+tmbsGZjv+9ezhybHwH8dz4e0Z8yNWC/SNEGwM IiFsqMdZCDi0GPcNNmD2dV++Kp/ZgwTjl8KR9YoQsRT4UFZr4Wx31NLiAHv3t6smnLK2STjMAGaq aoNddgOOj5Njsl/7Ehx66EpelTiEcJLDW+UYxKHDaYQoGnE2jhyM6N9hPb6keFV+j4MRv3FsXJ4a dbZT6AdOc7ZrPXrHHltQyOIPW/BKeoo3fF9b7JlK3pfHqgIhQ9gqQ9pA8RY9glGc3yhdabHRBv1d lrzCtmHEhXCH4ls9fhsAx74LC9B6KyvYWQLGNTgLTvIhoQxvscy/tVUSvyuGpq466H0wOH5Zg8UT RiZShcN0W4iBJ5y3OCi2xzpGgxmuwRVhELoOh3GNQBiLUIDqbE9cvch3hRLfOmoKZeyJrcp/6XkQ K/fcjBT4kpQqlhWnb52WPLf4MeXvO0QLJ3vWQMYo8uD/BCJqWW06i5CNuDHYaCfnCtY4YsPdyXyI gO25vi/0U33HdyegYJ5RtzSDmqElpKkGd2x0brAFHf9QG4jzd2jLyJka4f4V7iFCoCqWQVP4GsdJ 9EZT+vYK+V727Hra5Xu59z0LtUmnbVPyB1tNy4rkoROVbV0HlRHBMUIfSL76dSiL4iDYuxlgUBeF 9BQepyUQo4VoR0GONUWx8iBOSlYE2fcw9qYYYpk7+bVDCDMh2BcRw76yqWwwOzt18CRlazXUfbM0 dkEbiWKs58EeimMNYHIbqoX6bWD3mKUae/siL/oc+avPn5R/+fbt25e/wdPwm2Z2tlHgJ0tiGy3Y 1M1DgzZtU1gnCj0qv1zyX8daoM0+30Ly2yjj/Wa4j+0cjfkEJ009QRrL9yn8Vsp60OPd3Pdhyo3p OwiANeMGwrTXjsuXM6QQHoE15DCvvNlpyQVscz8UMGtViz9AFIsQ2rMIhtsexoISYHZE8IsSqCxs ylIvLas6as37CZ2CSUKMW0ApJ7eiMWGu5KntOW6xNsW/bJ/Gb3GbmHHZ00VZl260sm8rmPFQEqXf dta+FWS9hVnsx24okhIsRbHHHEXT23YsO33rpAQaOZbJ1L+4BIkZl2iu7lo5k4TOBX4sCNYabpXv C+9RU9Bu4Z3EkoeyoF9D3UmJo0Dq8lrYLkgQqnJK0u/IhdQF8PxDXfQvAt8j7X5s0v6wLLoAm9+J C3nABQBXxZG1Ftf+nTgB9t7aamPsgYr0AiDGrfcA5G9n/W0p306edzhBnBYflWB9MjyAYPFNJ8Ik 1t7+9dxZWPt3YuXtvbXZoQbeoW5adyPtxFL5q7Bl/rnQTMsfehMsv+2pte72L9r+UAqywKX0+V7z 34J/I7YNQLIjpLzIRIMJwXbClgMWBX4PoFNInZacqATANYqarymKqKcpKTmvAFbUxIXvHGcwOAln yK1XPDDe23eRZ+z67qLb0EJVwCs46zZYl/iS2yDpTQPNcGJwJar0bgNt+VG34Wwb78xtyG5BuQ2m Freh+wSe1131GjqIbvAa8LNPO6N/7zXAwkevwd4c9Rq6HktWkQZOvAZfFL0G5Ip7nHueOA3JO95p iEXHUgD0Egbo1cRpkFs07J0G9tU7DeGpcxp4e8ZpaHDA4oAfk4hOgy9JdYYvi5KOkA7nbZtEGyCG xs9BYAonMf6+LH53tiR1GgyChhl6DX0MXxpkyAcEj1GTmVYm1+bgNPj7VG/6MtQUzHMoC/oo1J2U OAqU0+BpTzUZ+RBrbz2vol5mSUrX+bdSh4djczj+N0igBOMvf6fGX+6dOe8QOUi0zTv5iY34N42/ jMbp8wm5P2/8J/FdlfGf4OI54y9/eeMvf6fGX+6dYfc18E6mA73Jt1ig+XfUwmYzSWB76Yy39Mkb d/k7lsa/hJuSBguxfRGzl/GvNLaXWVxMjomQBIBgd5GD+woYigC1jWFOPcHzkDkBkYiXi+1D3R9Q UANnUi54bi2Nu2lxFK4stj3JCfgY1WdqfU4gz7gjzzTWAlr5idEiRtPv0rizjRMH4t0Z99wWco17 10v+BKmSATMEvcFcVQMftUf8aac7J0TH+39HlX4aTjPGiXR9OJ+zaEebiOHFelRYX+A8KkyA2ekh nkSDtWacupLJE9zJPBiOM+cd1ybLaeWtnQHSK1Mu9yrNL2VuJeiwrXLAiWOLXmHRRtKrxbRzXHQk S03QDT3bdO0KOcklU3Z4BRN/0pv42wH7epP527s91mwOIzK6fowIWtWbhdeL3siE3ujmKMF4Tk6y UzIDiEJZoI1uJOtqcccu2kk+7CdhV/k9PySLZOLTc6q4StcY4piSB3iICT27nAm3cQpwLwBuBGv8 XoeJ6yAusOzcIEsnl+xMZxYDOy079rLTbbZBEyk73TpQFMqcLS5b/MfEpMyufqKmmsl+DvhTvCJn x8isJwbli+VGnnXg4lc+BXU4bzZRLk9evnn+8udff/v2VfnmByh06KAOuTZRzvjpTfxKU9ljFguH ImNeJuH+/Uevm/LTn2Cn/1z8Ap/okjJLxT5TUKIyQ+3T7BcXoKX0Fwe3MHBV2n82F6tOZ0dO5zYI lrN82wG/AaUI3qIQgk20eQElQEQHQ6SpdV9z/SNviSyCKFek3eEWmPm2GzGAHi/LXxFNgJFg01oD PCbWWD0J4sVqjOLKbsRwr+5VAwtA2KU+FybVIyAkthtkHtP+avmSwemRXGCwrHaA5tRKLi6tFDbL cgH0XLZx4UKVaQfGnWCGQr5CpviOyx4QPExMJSRXF7I2roQgN1kNBzKStpeLB5QpZovl6D6Is+Li mo8QfZmP9XzGZfE5RBgm6qGb9hAWDSOFgaxMhzBo4n84+7jK+xdhIHOG4KgmRUTUY3405fx7VaTw 8E3XeU26lBv3u+LBKySfti/WblJnkekcAjlSIToskb8iL7S+rJpDJ/snoizpZ6ya0kOxWdrwdFGS 7HqwLpGVz702XGuLsHNIOwak0KvLB+hv4iDhaQ6S3pnDj41iY1igqEb21DP2toZqi3zkhTymvtOv nJx1uq4IUvEIev6yo9EhcB4lYTS4zohjHMVjzTXpMFk44qCFocF6vxqrSdQXMvO6TuA74zp8efzM lf/drX2uyalbEqltG1HScNdCUAiWNMP5n3+VmfMGzofM5dj/4S5YzRb5uH7yWzbW9P0tx4TnOhUg 8vAtlp29dfRvrzwNIaHuVGZISMmlouIdL9fOEGgbTuOt1ciKR1QGj0iritR5KHyAxlcoYayNepKy qH8U7EuQFo6wsN6/30F1RtPkMJzO+KU9dRFFAKLB+sIzvpezIe7nyGGc/e/SeNLJcm0N9HCQySx8 LJ4v+koTQ2Zpc0D7QX6yCdoI/F6MTV/cwwWHPrNWr7MfC0dRu7+nDv+MxU9whUpna2zb0uf2EMFa 6WdslB4nPsgZGKstF+J9WVn2WHA0SVpNtgj7AYnaUkVlO3AA4UNqNUebYJHA3L5zV4KjvyUbHMNF fuKRDLCPacJA77d0Figh+PmU8FO1h6d/cPigxaTMEiYa1LK2eiqu/olLjOoIE8L3ZD1yMF1q+I6i RfKBSDLK+gsM28JQpiG8TLbU2HMeTQ9TBidzvM7S5MHFyI+YY+3O+WTXfuNj3UVRJZDRiwnJzW4V X+ujlS5Kgc9I+m6tacNTv4uY0NDQhU/RHdFI1GKMSPkj4RpalBHqHG2bqJY8/IlQizS3sxgo1IqS ZHiFTXPENghtIjXQn6YbUXhG2W1yvvSczzX8WB6BBYyYOppkdRiWr6zkAE45ryOUVJOHBIxsqkC8 wmfsMQ2/D/fJDvKBPgLZsdWErVRt0YDpODEWEv14e8VKzyk5ZxT5kh9lTTp7sOrOQ8mFwSqUm6wG K/Xjo/Tn2CYk7GX2wQ+S9uTPN5j65bFBuIUhZbh9SHrwUgwWoiY/QKvioZBbD14K+Zhx0TLHD+xZ TSsyaw0SB4WvPgLIYKXOy2xx5UczldkA0lWZZSEBSHAyANYfnLcxm+Pu1GPGuMsRYjNSSyn7o0+y FcEZHBdVY2vf+0fKgIz3gCVNK3okEynksYbPNUYa8rwaR/AZP6DmpsaN8hok1G61Cd6AGiklMAdy bt2MH84RY28UG9aCw5AMhFtPykkrKeeF3PAqU34lE2pV95Xv0ErxGYHLQkoaI6eQjbAmR79CYUpj rDDPharfCxuDVcI+adMihWHRdImN7AdVBHGgC6nFmRsjp8g+fqDZtwSc1TeMt8LQOPNBxvmR4miy fX7CylnICoJXgspDJERKqzyOr5mW4n6OioHZx0+tlVhPGjgdVUymaTkiKWGIsVgRe2EYAF8aYvIv 4/IAggJHlm8+pR/IEPQLp034kLLhLQUVP+WPvoZ/SHBxrCljF2yLEpk4V3Ze86QZnGCqtwPJHitH m7HD2iLy83xksKJ5noEfYNafyKXHvLqZrEImREX5+rAebFNdinm2C13ad/5r9D7QN2x4XLEop54p xYYixaHkheJG4ePYEQN+SpBDyfFlNVox8wu2RECwNnsJIQFr0aqUVGRpGzsdcO24z2YzzNv/A3L5 YCUKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago3MzM5CmVuZG9iagozOCAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDEgMCBSIC9Db250ZW50cyAzOSAwIFIg L01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjQxIDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBSIC9GMi4xIDE2IDAgUiA+ PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0 aCA0NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzX3briS3seV7fkUO5mG2 AHUp71llDAZoS7ItQ1L3SO1jGLYfdFrSOTrTkmxd7PF8/awgV5CMvBWz9q5UtwDVTiaTDAbjshi8 /b383+Xfy/Opu5R1152Gtuwu7Wk4l0N7Pp3P5Q9flX8svyvfe//Hunz9Y1m5/358jW+qU31ph6ry SfFp7E5t3VXncmy607m7NMXrb8tfvyq72n3Ln1fflu/9pj5VZV2++rp8KN8pX/1X+eErULNJT/EY eur+1PdDVzp6ii16/lw+fPRO+awrH77Dz6V8+Mk/feWffsBPH9599U7BLH8tX/0+oxE3MLWu6tMw XOpyZCNymPrsfkytK/Ry37eBnjymfgDG1U35QAZ+4dn5NX7AavIYoiBPJbjqfvh028+XvoYfUBg6 bFbfbR1WZGhBPTSnoblcJgyaaUGRakFuhy0KULGplfXQQy2H5ho9XisLp5XQgm98Z1Du2UPor3zG FTvNRz0Op2ocN+ksJtbjEXxDX27zbTyfxqHdyzcK+Pde/N54LuLnjnw7X059U0UL4TXSCtyRjLs0 p6aCtVWLtURPqR0ZBI6M+1tgXD7HgqMq8hwVmHWqx/qt4VhTtadzP05tqu3BOcdqz6rK/wTrqfYy k383ONamhsT1bT/p4WuOdUbhhpm/zQX8Hqw4lw8/e47Qg9OfNIZbkXeZbKLlLXbgoebcneqm2e7W qWLm4qEFT3DNokV8Vg2nZmiHDMXMxmcL9AD1bVrYQM9wGU6XsTrnQJtc/twg1pGe83gaxjPZU52q qgPaxb/i1esVpVQ0W8o/h76qEplvwLWnS9Wfz00HmN02l66uz8lfm/wE1eNQ1305ePrJTqH/4ukX krbQ78P3vxTtl+7Unc9AKZb2LWIBUhRVvoBuC7rU5+fyXJcPv3XphUJ6fY1Giun5s//RVOJ+Letd /5Z5faZQkmbi239HXowViDJ/xBOsEKETsxAQ0L395DEuQRbf0V791VTMMvnuS1/RtAGFa722ekLc t/imRnNJD6njD4v/D18uBzQs/p97UEvwwW6wqEJc7BbiBrZgOLe1CsKSjZrYTAjCfyr9rh+C4Xfd TOxqs7CJH6AfRHD4yPEIUZvlDbOwr/KR8MwQKW8StY5c2lRwjLtO5/HSKm/uai8fQ+YZfq+a2qEr urzdTV6/n0t3Qa8TCV9w31116tuqasv+0p8qAPiuOV3mAQ1t4JqMOiMKOzycB1ji5ly2gI1NVw/o uP5cnWu0EEGJr2NoZIAb60exYf0JlTJf1VzKy6m5NON5EGH4ejvQMXOkSueSvGwP/aJDw1imPffN kjLNceUug+EUjrpBc/Yjegn2j4nWGrKX//IOFBbj8tOiiVnuwN2K5JtfDuN4EmE4I45SjZfYe8d2 Rt22p6rrB9CT3RmL6GuZOzOx0XhdEEoMr4cOYuyl10tldbnU5+YWRmjxGeFAhK9ODWT/xmjgcntn 0qAEhfYOIwJVprVeB73S3i3YOPSX0+WCuEFWsJFKYn8UkahDVxjDXJ+JQ4fToiviDzWLeYhI6PPp ++jQ/gH9BFqx4IPD71+h7Bh8YxbrT6nQrPZbMckRXbD61ygGJoAVWhPAJ4uvXM5CbQYrZBUEPRZP qZFiFf9ChWgTq//Ot3CRM0A1jnv8kFVZ7vHJfR+IInQjGeTXhAyWxjy27DcgCowCpQs+64lC8C1c XVWfx1Kl8FalW6JnVeVybEBfnUaMox6hFewwilboMMdUvqNoUQqYyCeL7SgazMLCvvE9xG4jJubn qpMvKD76/Fyew1AjSCDjzqyGP4Fmp2NULtLFaphoc74GXVGbSB5/Fov+LxDVBgMx1eKUY6yWbaVQ s0wbRrFayCfGVpQZL64w54T30bqw7t/IR5VQ68wSaLijfogTrivRDy+Pb41+dPWpq0aGZG6KpNHo /F+wM45F1TzHsKp0gDWlVk/sWJaC6H4K/Y5i8ghL5iZSNsc6ddef6uECMG04MwtfHDaN0o2I0fYY 1GzTM5lGoSot+g5rfNgnQbGcplhHZlWQ6jPxQFNH6ITBUVFM5tn2OsJg277wijo1xI5gtmmPIXZa b3lhLRaMU6ZFuMFDtTX6tWkAy02/bmrgIixf8pgOlBe3TaJj6ulU151GIc3oeR4AoTDYnwyz/Nfi bhPXdXUaELzUdmRYWgRy2ADriKhEwSk6B0a/yXf8gJ9bi8ZwDnNOvbsrbFE/KYX8ziomE63ztlE9 VUwq9qLve0XfR4BOj+u0J+BO25jP5AuA/5fyC9zxsTf3bDhJ1qqD1XeNJCH6ko/kB5m7qIcp5wJZ nwgB8CXPScifsrWUQ9U9Uylte0FEBUqarxT7lNSudMmeSRmaRqxHXlzFKiefaCnZ8+ww/pDvlG1K F79jfy1GNdmJ9OSUCWoBn1iY9RYsk9WyIpr5VAbKB8o9C/sP7xDYBpJL8WIp6mwsvQuNKHSJCD+0 PGAiZZbvWArfBXVxMm9zLjpQ20A2gtwKSu8KY9G7HN8dPVdTn1rEb8oNIZw4imN0om6xHgHIbSve E6b92Wv2h+JlDTe5z96m6BEgPXKs5mKRHH8sClW+swnS5GANxW+qLg6ULapLEDiHpmgHOC1DxWLL Saf9gImsj0y1HNMRQXRLmSK6EGG8ZicbBOOGQUBzvkw8RkYRA9wcVMSAOFaxNe3QZYCSbHpuAJ+B nh7zn5dOZ+Q3wWcESVZnPhA/DGDwnP74t+45uOt/YzK7nbJE72NFikLL4j9luT97I6/owQYYWRw/ +QifABmwHGpE6haKBy1mEYTYIGQw6K7Qz0jOS7bnY08Wa2ZDtHTqD+0I69KXC1UXGrG0KkOtsnzR Ykie9aQcIrHiaMduUzU3Wr4i2i00rLmMmPNKJWlzuAxJUrdM9rFT0ZZMQm+QeSxqwPJizJJZSjdl PlsHHzPg6jFrh7DQYwZcwfg7A095mRp/5xis8V90bYtSZ3My/EZptdiKXapm4QX1Rp+fU3+8mZCB l4M41FLWzR+WzxL5xHdMTLVb4GFaGBWNtoZU2sI2SC/CbO866c4ysHySZxnlSCgemIV175b21ANm LjUUtRwRlcf0Y7Z07ZP2G0cuPaYD235R2OczwmSY/aEI08Z+CXmKYUd2As3xIkhjlo2ej/P8tucL ruspH/Y7tejNHLkKhha92QlNmkWrVW/IC+uOiszhuCv3ijtKRxyWndQ8644+pz7/Tn4BA17w9w/u NxCmnCT51JKZn5KuhG+4oxfoh9N4rjEtvy6Hv8TgpcescTXkrpSwCsGnLCfAEYDOeMhaiKAs7p0d 0aifttqSqtA0OE9iKCs0z0yk5PAdS+G7v3k8ReHkdySNH1DVmcjmrtTnpJiF/QOiCLniE4mwtfPJ VktWMMpgKeMTSSIRCs34khSSd07kCwWnbAQdg35o/QSVhEShUKMWxVNuoWpb7Pa59HWpcvjWDFD6 8XQZFlcMT9R0bXxCd0HWLvbbv3vZs1A6FfIgPOxotWZq7PTZG+noJ5idPUgxXhR/1sZ3/I7zr0y0 gmvLpCHdJK+QIZoRoSfdhdeICJ0hQb7HMgQIPaYo8IpDddps2fAp/Qy7VzVo0aEGdmJxSKFrNqld 5Cp1neLBD/7ygEpgISdWMBggNzsO9b4fU9vufGp6LAnP52o2irthDBXjBqBrGB+12GjF5DrPZHuD or5oHNlT/CAOeMXgU63Z0VZFolGVnMSSzMn+ZRbWwJG1JYJP/NyafZZiR2HB/LhmsmjmpCQy8XOR b8yz2ELJNH7hNCK4FH7Yem93wg9ApH1qwrtMkb1BRiT2hlWrQFj5MpIts48aZ2Mupz3rUiAboZj4 kn303DoSarFD4qxLLyw986EQNw4NoQeld2N/ypN9R3Hgz/twccnaPcqaFU4qES0qxZ86kQpeoSsA rcTSPtsY8Gegd33a8KVQBSFnJbZKNenUAFLAJ2alArpGhhkcZqHC2wbwncVtLJoNmKwtei4tAI0v brLzmcP1BmuFz2fYUywgXxWKqZA+y9xtnYYPuKX+agD9jNW6w6XbpGcupPS+ZDk7Z5Hlk84NUNnZ RX5P8aKxY2n6IR7vZ8NarNKqRqzitd3xFsQKGywfu2QtzjjGhtX1qcdWh9un3Cx0jvED2i3tbidE IZBGWaCcWLTAd/yeWWguKIrUcOo7vXdq4cISRoogS7EQIkipk1lrUTIGHYteX/cFwdg4sznlzm+Z bhtJ0tOBphxu4FAz+WAZ8HcUA9hDKkmJzcLv2CzOUSoQJlv00TIZn9xRMzvENS/wKP265E3tJJqS ddTHDXYyAuJKNp8/avKZ/KdUsm+sVJLvjEiwi6wYU8RZGHvGlsIPWNjJyAnKzOy8BW6V1fa+IKwq O7XYi1LCZOzg1isReizUpXxbf0AmUCHYerqT0OyF8SO/o3zzO6vnVsm8sBcaLmPZpIml2cRgbdJp AiZa7WSPWOhkByW2QydmkfWybGYF+Td0ZSZgaSvEZZoOAGGjK38JRcTxP6dLrWfuXEPV7Df7Q/6R m9swMh3HsRfYmSxzasFf0ILzdexIVxJFjj8UR+vf+CHfUYkpxnzHWCrbQXoYBaX2WLm3km7bb4NQ Sq/+kkmWjHWrEwartkaSyFLYikVlCr6quEG2M8+TkrkznFwz4mAqL0sZsaxstHXDiDo4me6Mg7Kw fOQRm1loGS3DOW1K3uYOA6cg6eTtTXH97IFF17G9gqbG7H0nx1EpD96aPpHeaXX2/k4jhK2tuNt8 i7KD45iqNueoC4Rln4uRwpjXaimfqJcMiFnXY+0QBcqq9ecsm5bDCWTYIsAvrHjSHpzxIUArxEyC HZ1/etc/MQs3UpEmJN5qJJTha3u013eeYe+IrMyFoHqGLw2Npn4Rrb4NoD6CzBHR+rrD4XvZZEIu rDxM/YTbesmuU//gf8MkIUXBeh8rNOw8lsOODR84L2ldcv60DckPPisduFlZpQ1k7aTFwrMPIHkS 2fK6EleL8Bv6QD7ZzLNRbgr1pmEssoxssT1gibbUcidg4JxTHnYZci5oxvKGZ2es070kKnRL5wKI MfImB4IlpzrK8QUYsnUdEFk4vkB84MLxBfJFc8FO9flOcSHiyvkFM8d6jc51HY5GEwdfXNpzptWc Se4Cj5d26zwh5QAIzbkZu7LbRblqK4WWW/koXfqSxvX/Qe5np8yw6RwNUcEojyG25ySQVXBpDt/x AyvcM3aK2bdTLRRn4heqKROVbFLBVOaxo+uU3rAUkyaAP/ycOZnItpBQsos1sIH0VssKtyQMM2yk YrzfFTUjNmUP0CcVhgxfBCP/Bxo2sjq0x3Wf5SbZEXrRGVTywY43aMXAuOOVom3k+JqxD3zIwI7g A5t6zZD7eRVmVqGzAk25ZkkUHmZJAUyAQTM9WmDahrUuv4t7nFR8rlnrvsPhMhhatA2On8T/vBEe zzh8bMVa44uq0ozncNrMGQfV/ELWupOTRnLO+0DvUiAp3dZLsjN5ngw7w1oOQhB+xw+sFaSNCUbN BaH4xJyUCBoXJoYPHM5dEr8ApxaB0BWsEa2VCNUto7UtkdoOADYI2mJepSmBB6SrlgzSfFZpolTk VrSs4heei9HCiIU98Rlt2EuXHFYh8u3EsdHQkZnUy0mlFBeG7dgpkZVCwqKh/EQISOj7U2IAi82z YFYdwZImb7Ndlr53nYxJ9rCdzGJbyR3+sK06AcCsBMh8SQDKd/QRlkn8gP1Bw0i9YTfz3a6lvNnW cjfyUmyLQwKaCwb9cu5JN54zsC2OOh9rg2xvPxVoSwFzwwGtnFLU5hyVDmOpJoW6sWJ2vCdUTXxB FWT/W12ZaFdUaXYdVCMox6aji+fEbzFF1EO7rgWkx6lsAwYZl0GP5RI/l+G1kGX36dItzqRv23PZ keNLNm8aEADPZgGBTDa4PTtorh5H1aG9XY1tL+mgCqL3C7ppIIxqqG7eA7fMiJkqT8/l6poBpwNi xmLCCJyOl9Hzs+K3xC1XB2s56XvMBCwfQZ/gSOiIqFU0znwiYKGqBTPs1jAGO+pgPE0tv1Nt5BcO 1ASMgTwL9vTOQ5fa3QWBSyE68ihDa2Cn2AAbqGHi4sgxOHIHzsgjfkBOv+v5vsJwNxaeMtwd/b/F cBad8jus9DN9Ekaj+VvjVnHDDQNINyiQoPuuXmALLAPo/2np10CWG0CSnSxGfc8r8SeYBf5cfoH0 PpVfxN8Wa7MrPFipk+vAZybyc9uFTAzEplFHNouSwxVP9IiLoUiWwu84d28HgZaWqNQLipdp/a6Z J/WGOIWmg1UEkMFZsDgJmdYRZ4yuDfvqAf4sHEb6Ngz7KqDbscsM0nF0RQG0ohbMR7pyRuXvOeXu hZU7olVaF4pYMCsw2cGQ2nEdbRR7njWrIbYyTSLt8aYQpwXpuLdZxjLFrq0vZUee55llbZb+kvlk llUoNtZlCZvIaTw4EucH1DmWEnTV+bep7XYdyl6x/cCO4zuWsiIWzgEvblilFPA7Ekgi2FprU9jh 3Ny++J310cxCOq3ZCTW4Zl6VyGACLSdYNKn+EsuCMNsGqhfEbNkI7fY8aoQqnNtcXyT2hEHJiBXR HqKtH3SME+tw1HKwVsEI/XInHeOg/hNOtF3Sh/WABjluxYUdzT5lb9i+4ZIMZjktdtG9LQEOIBq7 C2Kq6w2fjGpiSPU5TSlV4jNa1JdM/hi/XvQE8DruxIMbqK9UfrJgYljINKsyQcecklD/mJOEfCIE 2GBNGlRiJ7Bq9xOWwl+JhDgIzlpWIiGOLIrCdiRkAcGTNNZAT0HmsOF8x4ZbiEyzR8theWvdDk0G e4E1sEUknkUTC1nhtisXSdnt0e7dozJanPaCq+YaDC9a3Bg3DGF0vA575IsGAcvJ4PGXG0W3lwo7 BrLuuoPikdPsZytlAYo6g88s1jWwSyk7zEKBUnz0SpQn4PNiG5/njQacoNuVkrolTzXeGkYKsFXU VPDD5DoTKcCcq+JTNB8Lrm/Jru4Ww/Wp5wZRol4c347+fXi2EC66N52AAHDZ4x46IYcZG0RwRL8b Py+7tadFHq1cYdZ2ZY2FfudGVx5kBgOfstex+7+uml3cFGiWGSScUTqNjQFK4QYJzMtMzNuNsTEt fl3MvR2WAPoZG0guulz3Tsvn9tCDOfO20iWWdvnwBM8sdsCS2s1wMdbJXzlVKfIHa2JwcHTOeSmP oQccyjvADHMGmMfIGWtnk7MqnTniIzfI1hgIZF168EdxUcP0xAv6Rhp/Ord3za4IvmNO+g7rZWCu BK3y3fTHgbtp4voHHwqhiHFxIQ7RlnPbwYORJuuo1RnzJd0sn9Rn0gjb0/1IXIuagb0r//NuaNSt nvC66jWAYBVuzEEIak9fNobQeK1eMnII/N7J/fDdYge5wniF10sQIf1EUQhIKh2/XDyhvf/BJVuB lTvnf6+z0m3KqHFahrIyY6HLopoue1lV1D/j0rkazajKL/302/ufw3FsXR/3+fuz65ufxfub3UEm I5au9bUQ3GDdUomDPLG6BJeL4rnGcVE9INGb8nM3Kxi/lGtxlwuCQSjw4UU+PPUoBREr/u2LCfcp bhIOoyiuEeu7iwF/yHW232oKrlvyKW9KdwOenBkvh211OMUHSVjgIOfqJ5l8QZpSvCn/E2sa/+z5 OLV1q62CS5IGydaE3vPHJRQh4Y0LzskeK8knT2BszI8EW4CQIXyVPq3hBYoeoAhXR0lbWuzhR4On KW9whh7cNnxBzNXjEm/cEyYNRn2tbPJiCjiH+6swVClfhzTkYprm2kqJ3xWD7P+T5fZCg9YoJ6jj jPyEKmz1x/mfcvqZb4s+4xrCHlvPmropBk0DRzpcnTNCykJah51qtWuNlp2kkAKUxVyRKk3Bqe7M NU+J38U2Cw2+RnCL/ItUaU8o7fiOfRPbE9M0F0piLk2JeV472WvKf+7QS1xtVkGqRghE+PONXE4m CE40FPC1wiKTHjMEXYXDqf2TzPaKoL62z4V9a5+Yd8RJwxf8Q2e79yNu0egvOA0lVOquWEMOlAbi 9Al1NXIQcHh+g2fsaAdVMQ1mBhfxaon+ifUV8r281fq3npi313ZKXfhWuVCEmoVBjiz5gxSatOSl V8kFo5pM4sE2qdDgbi8YHsyBiKELoqsqFoULAjARrm0hmQvOekosCeo6MSFPYTC0hWlrYppfHN71 NSancHUeHJhEa2qMps+dW2+Go6GxRlFdmFp/NXpODarLgGUgkCP33yk8hlJxgVqNvYUEm1hQKhn5 o/dKw4a++rp8+P3L8t+++PHHr34GntRRmtj4UOiVOui5Yx0teq67DDVqdFXhkgZW9d/uVAOW6rGG cnyvqd5DcKf7FU6UfIkwqTbpyiIdZfcRiGHEjhZnaIgYOig8jUc+bHD4Q2BDB+XpxPS40rBNRp93 oAdZddRh7bG7X2eASuDYQejnJAXyLIf5y2qyATG9RgRM0vQ7eNpOFmqlab6sGwEEYBGMQNEBtAgw 8o9ooDzCeNUC/tL2agYom0MckkdK0E8Kix+C8mMJRy8j6YgfNCU1B5qm3hx+GcgJK6YS/44lVB1W UEUYAEftk/Sr1QSY8pgH5vzcdwY64EbxocIKoAhoMCM+nrGiT22YPr8uou3zaQ5dBeigadH+atkx hQSgqGCkmXQ9IbX2bH00hZFrETUoZyPZmpKiBk3TXCiJ/aYp4C1TbkYNmCmCGNBHe3dO1CBvvG/H PZkRNYwjTGWCGvTZowZ94peTvGec20LAcMZ6V8EmAS+ccfynK1doKcITvTEwpJgMAZfBa4c059W1 QP+Airz3L6TOkBb+IDQI5BIaAGn6poZKhAtELBcHPhx4iWnhJepbhQbwLnpxdwINigHA5CybhlNo MBMgdDLVbl2AomhsCVAUlyUB8loVS9oyBZGmqMIzUxDbF7UBN1OwzW+4ayy4cCxkauV2r4AMoKQ9 RjIXBOnM0s59yABnH2IFDW8ZVEjgnfc0angzMmAdd0QGuTUsIgO0/gZkoEDMgy7IbRZIgtHEnbp6 qWMESVKKQ0cIKRG7/Ob7H7794qefvvoSh/sratmsA751HLEYYWAlM36HShI2ZJYNX36W1VZ7yv5U GoApWSV+E0slw4NoDbKjLwJsYbwaRDhah50KYqkboi8CEjTi4qIvhQYkBI0tjGys+WLUBQMWH2OZ RV2Ah26JusC07466iARMgiazBBgfLIm6FnVJozQrqAmD50FmpiNq0pTUVDKtiIaxxjLzCqG/JAUR ogErJFMEVDNtlistaf6doCOEUwx0EksOZBuRUy8I8jycNYCkzyAgeAKmCQQIfiakBQykRWsCiGP9 CQgKaZrLUeKonKfE7wqwxPMl9RfKvUDUoFwPpIeU2ByUxd6a55qn3IyezgPDIIRQ4TmJvoQ0B6bO GAtJsMM/nHGKCf4BWJjnzSfmlWueiKVqbPYzYKqoK0iXA3XuL4Io93cCoNyzg0ShBPckRRMg4U+E SRA0kbTwB1+eSb4DZcijbQvgKTTdISh9Uhilzx5CrTxloSo3nAu4vRpwcY7T0yBt+yQrHU5QiqJk 4eKifMmSMQ6UUWK2+tWCrUgtw5qtkJJCVFVbmOpJTLMBl96ZaYS7A67CUr4zNkY9MuIiy0yBTO8a cWEdMz//dBGX3BoSQBEjLoio3oCrNlFC4mpvQAnCKCgpMHTVVfBTcPQ3zc84hEBU4BBCmLIQhBCA Yeb8jCIFQJYpdrgVKSCw8RbPz8DVnhAlkgkpan9ISbQ/pAW97s+YZsVsmibAXWPJA9ZgpEAhpGku 1MFc85RoNAqcGQv0jFkgIYHTM3KlAM5RxWQMvLibNOpx5oyEyL3R4lNi/HyKRLw0usI8wdSGMpMU 1hxdPS4z8Gkx3KIpMUoeUtLvtK2J6SPbUBTnigJng6cPKWlTtJdmuaL9T74TicuflRGz6AIZ8LGC GNUXSwAjhDzcO+f4ZYVRhAV11V7Q5XyDv+Uv+HT+Be1O3kPVAw6oZf4wDarUdYPZewRUSveXxwGF +zvFAZLLOfdaS+CTDOT0Df6OqeEv58whMY4mRlFCawIQcC11IMD95enAN+BNSAXOkNG/pGU5fVkW E2UMd8aM6EiwWtOi9sxlJRHfVSkAFSoZKIoarSnQkNWU4PNDnqj1saSohBOtj/octdfdiePaF9tS yD05TJu4fDnnXaLWweUnoZTyj8mh6BpKKTbH3Zy66UcgGUyzQ7R//cpGUsJC+rIuHjPHYqooYvTg yRw+K7iKKBb9fdW+tf4eYf+n8/fu7FC/RGGXv7/Ad1QA3rrWAg5/mgRThdsIe9FUjR8gBe5IDjjR 7yTTtKgbggMiqB2OC9ehP59CtKPDqia7/EKi6QHqpJ9OV2LQQcKpSmMwJRE9vaZEnYezY66o8wP2 aOA4qOCKURImweVMrlTpNS35jrnmKfG7ou+A8C9Yepe6epyLMMiC2ujqsQ4CkzlhJUavz6nd07TU 4WuaGlpcJ8GykxRSEE10pGqea54SvwP32ObU9Cn/os9XHkcLrSmxPbEnNFfsQU2JeW6OCtR1K6uj 6Hfxd+rz5Z337DKdF0IBcLwSD+KbvvHTKS41pIX3TT26MjEAqeFjJz6/wYScr1v+ek2/Kn+nPl+e vRfXEviEstXnSz0xVf4qaknT90Kz+nxtTfT50lLv0+Uv9fmaChQyeb9z+gQX72CwPJw7mJkoQHNh QYdS2TKEBXBmLgg5KdHpU+yAkaOqqSgmajsxAFHMoyKHtBgCDMqQlLRgOMgZdE7kjHJrOvHSwwx2 2FuVDRayJgLkVqT2DDneRguPWpGxWsfTwYW1VkxrWMYLx827iMkfKzEhAs4S5BSmRJ5g3kUryelT rNTVaZFNbKnzLnvK/s333/30q788fPDV11/8/OYn7ErJqqrHNGotccE9VWU2AzteT7VMTe0p+/kP 33zxBuu4c/gktg6nc8F9s6OfsA+wmBKHnUB29pRdYx16FuEwfeNlJ2dyuY5xDm7m2ceUv2GrgBK+ GYp7ogm7uhnGJ5usqzGRFPBr1mwdwkcnRAsCtAYssSnwU7j0V+4Fw+Qnp/QkSS49TbC84A37IVJ2 R+FEamvMswaYPXl8g7cIZBtUjpSI4SVD/By0L8/V9f7wrwSWMyF1ykxSTwqAWgEiy41+IT4GtXZn cKQ+WdPmuTSlEHMw+06OuhQmp6C8wWItuY8thN8wsz1iiUQIwPHZwBLNk2JyTYvunkUnCb5+KUqn SnqlKScl/Y7tc3FAvzgaxoPciyiLDI7wiQkpxprkQSe4Y9sSFBY+2heBE1EjCsaK9/TvFI03eOfx dQMLG9E4rsqLaHsYiMYllbmT97ihVbRDFljXcuqcjcC1MKyeDvlL0bj8naJxefZIW0vgE5GzRNik npjq0bikKRoX6hSNa2siGpeWejQufyka11Tg+sn73Wi8BaJF7PHbJKSrapDC0B1iksRh16RiQbY0 ds1PosYH2VI9jTIbU5Rko/G+ZbEVUHBNmkTesF4Uh2onk21PE3nDSXEtrujZDL0Vj1vejPC/1lGY 8N4U6t68vFlrmEGXaQ2/OJiGWcQyVrL7XmCalcy4ERB7woYIWfLA9I6yHwumd1SVC+uggx5M7yj7 NjC9o4Jc4gOY3lH2fjC9o/BcwgOY3lH24WAat8QGMH3BdJ9fEixIWBSjvrSDTHbJf+vb9NzyN+ST XQRnlIbloThz1D/CgWbBallxP8pyQTePCXjBhIIJb+RQ0052h+MME9wTjTArknAFADYD6kdIsKVY QI3xR157WllKDcSIGUTwQ6COTXhTyBFyfdrGFot1k0+AXiafrOFqXHI5YG0RuKZuliloXoJifa4E SMsphXIDeUDWWA4DfwCQlcS2NG2ea56S+ueqw8AeoaYUWVdYzynCEYlCD1duiM65bX1O0SjTHK7V yWTNFzGylp2keAoAq2ZpCRwinfM85jvlQoQb2LHm2JfMcCvXI/7RlLQ5mjbLlSArzbM32i1YRHBt UWP4GPC1/J3ia3kmMoYeRHzd4nhfjXbL35IHJfEviUXG9x3uwlF83QGlW3wt15d4fC1/eVxbIM4j A62IfuXZY2ctgU8oW/Gz1BNTw19hhltoUnzdsjWxBmmpx9fyl+Jrk8pIvH+/G1/XWJmL3bFgtcpY ITsZnRbNZQWZVIC1h2dSACo1rejXc2ke7PymXkP5qESaErU/lpQo7ar2pxaB7YttQftC2gRnQynd MvM0aI34BMwfLji4fYYb18u57Ux3nOFOq0ig5RQD346yfQUzWDmtIEGXcUUb1ni8rSva5EBwrmir B7dVbL/XL+RLOD7v8/mwY9ugLDlRRy+3c401PFjw/e7CLpcUvb9cnFT7qVj1/uHD4P+LJGl3SM3Z Yee9cbUmVnE5QCOAwD+K5XTeP7TW+/7krcmcxNNkVS31vJMpNBmABr8fUqLmo/3MFTS/w3TcGYtx o5PvEGscBAQlDjykxe801ywF1jimYQ/xBVPaid+XM9URxUx2DXbYRy6zhKEp+pzsGgx5xPbQbIY0 tbY4Jp5lJymegGTXoJwlLzTN8swSEqwQGJDYPmVdQpGyNxjkwPBoyGMnaC5IF7tFU2KevU4/BtUQ KBU1ckvL5O/U6cuzd/oDBhXR6Q+IrarTx98Mqkkqcyfvx3PYKihjwYnTR5CYdctfGlSTv1OnL8/e jWsJfELZ6vSlnpgqfxW1pOl7oU6dvrYmOn1pqXf68pc6fU0Vc2Pf73X62F6MqyFxgHJ0+nDZ1KAo LOhQr2c5wpLGkjdEY0lYJtbAAW4uHA0lRe1UmmKKUp7qMNMWLMSV7zxn0DlRs5Rb0ynuTvYmitEJ cAHLLWETMCJZgQtZc9xyeVcPDDbztQshnFv3Fq7WMfXnNwOG7BoWEUPdzxCDLJyqZK+8+KOqAaao xTE1SIHtRTec9fCBsJLcjdi5xTAd9MYhMLeJ1m48jaVK0Ho3092O7lv+uB2GEAy/wxCnGrpTt3AM lJyzhavxkvNT8SSHhvXhHY9VxmbEZ+3C6crXW5XKUuZd3Vg6hiknGAmJEsRWlaZV022qOOtTJzAl 7HEnwmBkxI/tISw5UON+hGGqDKuUd9GVRMDuSBeAHq5u2UUYDkW9f09ecICl+KE9PYlj7e5OWI8w SgPntouwI2RfdsM23U4Zw8m0B3AMC7DH876uPEL4exwZgethfbAz14wl6zDuppW9uy9ett/tsK84 9Pr+XYkzSVrZu72HMDix+xOGlQQ4c1aC1Pke6RAZw4KGrpJz7XYQdoi5kK073U4Zw/Gf9+9KHBpR jW8lYVgTJjdD7OnKI3ylrNsZO4wa9xB2BOrpAaCxl3OfVh5DGFYwjThOYg/HDrFjWCc5YGpiF2GH OHHsphp6xPH3cOwQc4HRLADsPsIO6UpZdygnSe/h2CEuCac/tJh12EXYIS4Jsel2lB1VO3wlbpK4 v0sCPbg+YR9hx3SlOzJlH7TG2dL35ximDTrMWe7qykM4hokQBP32GVgciX4Ax3A+9WUnYYfYMRzd VGPz966uPGSUhNOI6w7HRuwxF0fIWAz6wQU04TKBtyA8Bl+J027gknYQdoSB7bBu/4x/uwg7pisx r4bLBHYRdoRWygztBVN7uwjDrUR3t2Od+G4cnbuLsEM4hiOsBtiLXYQdAa07uCR3ytgerTzCwHa4 nBMLA/fJ2CFaiSMdhjP2Dezh2BFOvIOvxFW2+zh2RIhADmPG3QvwlTss/xHDtw4nVF9wqtcuwo4I deIqSswC4mbaPRw7RPgxM1LhnrFdhB2C+TEzggtK3j6t7LGCFSd87CPsiK7ssWlwxAV9u7ryCMvf 4wJdRBT3EXaEViIChePAZM/nDjt2BLqQNa1yd+ceug4RMazBxnEpbx8c6+WOglF2GuzoSVxfdncA 2zdYtlVhUfUewg6ZeW6xHWKnp8QNb/dnGHYV1j0OnN/DsEOi/LJdZGz2KeUhnhITNgOOm9vFsUPs vmxzbcZ9sn+IjGFbbCNLMvfI2CExa6xhbnC8+y7CjhhV9ljO1spC7z0cO8Qj4b40nN+1j7BDuhJ7 INsRp+Xt4VhWdAyr67Gb3i8iDMvtXn71w+uv/vbTz1+8KX74BgvisNawQwRMFmFi1hQHL+McJaxP mUTr3vvo27r84HvsHMxbffKoNYsQISyD5/btzcV9RwiOrCo+uynIt40uRFUHmeV+2+iSoKosPXnb 6JKYavP20SWn4teQ97eNXxLqbV1QKVsfj0AxEum9jJ0MLbLpOsROYHMzzv3fpY+HhLowJ4p7WnbR dYTfc2FenLe/px+PQDByQ95w2Sf3We44XdMf3PH7P+Ku4B+d+71ydbkEecdalinky/0RGBk31uK+ rn38wgXTdx8fdth02w5u4JptJw6JiWNXf1e5CG82XUcMWyXyfK7dtEs2XYfYe5xcce7dzF42XbgZ /u7yhTshBabusl/J9Vd5OPoGO+Gup6qwEW+HnTgkVCn3Srm1Ofn26wi/LcvxceitTJ5ly9chcTdc T4CDVnb57UP6Ua4DbffJ1xH2SyK7FU7+3NOPR/jHHkvxcTbkLrqOwF89VuJjemoXjv7yCLuKhfgj Noa/df2ISArO4NlF1xH4Xk7qvfhVCdn26xC72mJlYbWvH48JNrt9trv84yF2ArHmod3Hr2+P0Eec fwrzJaHmbPk6xA8hoDs2LqCbTdchfgirHXG8/y6/fcrpx5vDudhgjks10v6L4dylALAc+jTiwgMM noCMLu5U+viFAa5yX94oV3qETevYqofL0s8pcC2TAa67O2dt0zo+HUe5dAOTxzKH4Dat2/Wr/u4c t2ld7s7Zu2m9fHYpH2ab1otJWHt3q2bn6SVb8TEMxdlqoVE8/kCuBcdRzfKvfIVjPuYb82GlePXv //zv/8vJh8v54atpEH6V2huC8D3uxuxqXFtk+6DYog998LE/MABmUk4DwJK3Z6M/MKBzZwM8ww8g jZwp8PU7hTzBAckP7NczRKb0wAGYf0mFlspJAywNPlRKY6H8EAPPZ+fiAfEgKRSwRH7w7q/lq9+X O1hEMS12na0QxLTCPl4sBF8Q08kpBGARm0E2kHDLKbbbtS00/zswjKcvgDWWCwhXyDsmwuhaZggv EZmSH1b7AwoDZ8lEshsLaOQ7fs537iiIqnx4gZc1fvX5OZ6hQr91ycUDDFcOy53pmlqGOBNV/vAN 7MLSTBRuucdG6R6r9ZTTa4ZIDuQcMXsVDBEueqnP7Ti7uNMfeHnl+Azt4gFHk8uZHL/U8Rn9arNS A5sdQaQpMq3CSaCpKdpU9YdrpmiV3EfZIkPvJoFQNAqw/aH8x0SR2mLBUMgxCziMfiJG4s4nZ99k iRGO1WwxUyFWdcS9xe6gvAVTuv8MFmcTxOwtubOZg0gb5VTR6YZvVOHO/zO6uDgrLEt5EeT1TRF9 WFPEtDIX8tbKbhCBsKWlwz1oOPdNb2xZ4GFwl9kiIHbxJQwiWEjLSxNIm0n/g8Vf4n8oOkyk/V60 rurUaMdpZfmhtf8slDnlvB24T5cl+DaEysU6M+c/8STmmKVZC8482G4hBIdCCymUH0RPKa1nlmwv ep+uxd2QwMsbNjbtWkTehB2LHcbu4zv6ukWvSE6TKexF5rT95TuzmHjHNcYJU22foFDjIHGWLM97 cie6PLmpkVk1wc7rxiblJiVm+8cBNiI85txq/3P0EFSKOclbMvwLD2Yo08QtwBDCN0vEn32iwo6P /KOiEZe3mMJHlscf0si62Lnvmrpe4slpv0NFzLKm/aYb4zlS6934KHuHyWRFPLih6oq9I3dWjJID 09EopXCSCrBolJhIhbNaET5whf3VM3WxH600fIacYr7IeAhV4CrGYMnpXOtcfYwfloP/ANi7p1YO slF5TJZR5ilW+pKP7Cuy1clqoaZjq1c+9yL7OzJSFeIPfAZHxTx+AD0TPlt1JUH8YR+qR0HW0Bd2 kdd6XzxKwhG+Gbpx42S61FAtjp6splLRf/Ymhk6ArCS3rS/lO5ZCVk2ttxNwvgvmIj0IzxJhwcJH 6A1YtqCXzpKS7yRQxYLWCtUf0QtyQRrOYsDNUbt6YSaYR9AaMSCuXmxxmuj6YCyVGPZZxs8LKsu2 pUtRmHaaHX870SlU5zAFPR9VU4zZ2QGopOEO2gc5X3Ef7JtKbiS4CKN3CqRaDTDn2B7EmcByzcDC QGgeMFEmkyEZzp19/RNYB62jnjGRwJcSzMLIMmsr2HHsWxZGIkINTq9j4ORYLspxrLje8Kn14G/G crLFW+aNzAzmbSHSpJ0YzZt0zcyOJKLOClMrGXSKpYSu0QqPYH8vK+4x7112+ex/eLYS17+TS8XM PI4/zhxJ3epSM7ry5P0etYU/tD2MZy5qki2aWazNpOZSOt/1qr5YmFXZz0DSCvI8BO1gkQnWHmei HbYn4+cbMACje1WzG5EnB63FpmJ+IhxErF6hJpHoK+/nSCt78I0naxVpihFY91f+5GENWhQa3+YH rIkGIqK3I4xAxCKI6GGhVaYNZrfQz2xZ1q+8DaaUs6lsuHVoi/iC7Kez+wcKQyCI9bF2FmYdIbPY 6FA078Law4KlLUJ9uMX0yQdpW/K2B9k7cBGMmUNZCz4r6qQ1amSq68sQ42M/v6CNygeiVt1Q6G4l mA2nCwlsb86O9AjHVz32nmlPEc/ZeQQ7pTmBdw/f/QfajCWaa1Oaq5FG0Osj1lg4nc4rb83A4gxB F4bHDetYSbo8rzwhEEFkHRizx6z4WM2MQNADGSci1r9S+6wJoJqzv6nfhFMBsDoDz0Q7gKXY0cpS FpiFRcMTJyKBSbYQfpT7ObDpLEyXyUbyDqDyEdMcHQZoF0z+r4dX7jzRsd2mXZO8etS8timR8c5P 2xfXpu3LclPGV4i9JaaC6VGs5LvgbgffAXkjg+cwN4h+UrQo0ZT2GaBwUkg3oS/5yAKoIOvmjlUF NE8AcTWU5YEb6EskOY0VPiEj1VLgxgRs4cbelNV53zTUQFdM/eXohFyxLpWjyam9cOMY65gnPF6w N4VO3/DDhSzB9/PdYodxnuRfkIbZNJfFIcHbuGkqC+4CSk/DyxFWXO86v0TAGKHivevTkj1seofN qmmPrcxM3kNOGtwFjyXHWQENdoL9ob5ZJbS+hpiQ3yn8/pRg4TP+fui1mUr9PlNVuZj8ayBCqPzH eIvgEj9hwezrRTVmR57wHZB7aIHzc0rQohdj1mmDNDYVxMJG/1d66lG+CWPjS+PXsuHC5isTKmzv 3z2fqNHsqjC96iSdWsAP2I1WI/mOoWGyiYURD/zrnSKwwg5Hn44VcuoP9mkNZbeLFexBGrc43DJD OMcKtpMfWKRjMQr5ww9gIpPG3xujYCA+VN1jRhekPnhKTLXEJWxsNpnwlwdIEBZcqZKyxWrcp4A9 Tg4/Xbd3OLfr3OAoSdzRsaPllHIS/MorQmiyjwTQMLHJf3nHt/Vd/EQjQWYtejwW7pQmTH6xtOiO EtnI8PqPGR902NHVyKW3WeZ8N3wRrjioMF1NQMtLM0MDwR+yg6xiTv6Q/4QYU+PseoEdR/azBn5O GaVXL+EaQKBK6kv0ovcUu/lf/rH4rty1oFLHZxj5jwOUKYv/JN/+TCSUTLRG+lu0NNFYa7PJDavj dmTGGj8Bh3C38wNd6588wyxTWTF/WIwOLJk1BA+cEWV/892a9uzrk1uGFIqEW6zOAbb65WPK5MiK H3Kyu2hkVKDnplcg0IKZC1FQtdL8kj0DNTuQ+3JhOg75yBuHkEX2548ipoilkjlUEAZo2bQr0iZ2 gTmtspAlQC/Xhg6slp9v13d/KBTCuC3O3sCx7OsBi3SYp0D3U+EoFleoZH3oNd/ZgeJhFXmrPc1G 3k6mbQ8FW+2MO7lJlaAbsB987mn7nZg8kPyCpGtTPsazWy7iW4R+OVC2ca4ObpjMDKGrMpID/weE x9A25QnvhPyFSPUTwqlgGBFrwf0fjwGSVB/2GNfG0TmzU9nFbDUDDdadxcZLV9Jj2GlrZR7dIfNY LWSFTExJKx74HbPwnS2FvF/Ye7HC+xucUi87q3BGKO5o9rzfZRZVbdGKuwu5LNvHRav9HkpXJ4uf kIGI3GOnaL2HLETCiQUphBaTQF4Sbt558NYiLId16BsB5tRek1Ar2EHZnOF77T0XfSNlnx+sDHXd d9bIfuCsakCCL2hkWRyVh9xLFSvEXkkpVf90QDAgekCsZrhwj9/1uAibZH9eeSdCJtKMsUnMSTPG 8YeaIzuFSc7wC9cJhW5fYqKVQFbBvtBCrY0LQx3nTD+RnsFY/Tl+MbixkN1SgxoTuc4YeN5gz2In yJEKCN7n2TM7sUTWUlqJsxbXQpJ7i07kdGhzMXl+kZNTsqLr7Hv7M0G1lIGttSVWZckLiof1ueQv l1ZYmWMpxFqk6TMqPF9SLinPLpAR5jwUHdLGUCHYh1agrT5sjRJJ4qEi22CsjrMQskbqyp8Pvdo9 9z/Kit+Re0z+tX/rkGmhIWqNo9ETkdFkGzvDDjGoARqUYnTDfjjrqOM0vsGwusXi20eoAOWDTaIM WIfGd8EIulFDlBYZ16nZZCqD1I6XcX/FxG5T7Mk+2n1LDqvku+/hZoFNiVvZX++io0HAYmEknO+m veZsOet7RJywxM63XXPCCv1xq7C/qT1L+imXthPopciR0HnpoMauALbSTdbTimSw8A8cAH5KZbtZ JWXW6MABeoMACK6CyUR8ZIT9IePJMgtPrJyxG6xZYWHKOLA8WIm7TVrhxDOsLevLHa0/YvSARTnd iBvZlKw840WbTeZao0HmBmvhzIT1jdZo8ANgmNALWfNlN6AznFUmNwU0O5trRYotI6SgOWQWKjiN K9sZ3s2mSO/VzoBCGwTD6jE3ILNogthcNiIokutWdt3id1YqLAtZCqWCTGOW/wFzBjzPalmDH44F lP/iAFmJPMR+mnPfZCJ5Emx/rL4Et+p4SF6QXWz2yThSFvYKiXC5VuL4TidAFnx+BATZPj/MZpGc 4PMdAYvquzYOO9KxIISEE9AyHctsbCjIhUpNweTYY2Uc5njBviTbt8ZhDGH+f3L99wEKZW5kc3Ry ZWFtCmVuZG9iago0NCAwIG9iagoxNDI2MAplbmRvYmoKNDIgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDQ1IDAgUiAvQ29udGVudHMgNDMgMCBSIC9NZWRpYUJv eApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago0NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+ IC9Gb250IDw8IC9GMS4wIDggMCBSIC9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgL0Y0LjAgMzcg MCBSID4+IC9YT2JqZWN0Cjw8IC9JbTEgMjYgMCBSID4+ID4+CmVuZG9iago0NyAwIG9iago8PCAv TGVuZ3RoIDQ4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXV2T3baRfeev 4D7tuMqmSPA7+6TITiJHjrTWxCmvkkopIyl2duQPjR0n/z4HwGmQzYvLC/JqRlPzwAEuCTS6T3+g AYI/5v+b/5gPRTPmVdMUXZ03Y110Q97VQzEM+bvX+Z/y7/IHj26q/OomL93fzRWeKYtqrLuy9FVT qW+KumrKIe9NUwzNaLKrt/mvL/Omcs/ycvk2f/CbqijzKr98k1/kH+WX/8g/uwQ1q/Rk59BTtUXb dk3u6MnW6HmRXzz+KP+kyS++w2XML37ypde+9A6XNvz2+qOMt/wlv/w8YRA7mFqVVdF1Y5X3HEQK Uz+5PaZWJaTctnWgJ42pn4JxlckvyMCXnp1vcAGryWNAwZZycNVdWNp3eeV7eIfGILCD/vYJLEvQ gqozRWfGccGgAy3I5lqQKrAogLJVray6FmrZmVP0eK3MnFZCC771wiDuKSHIK51x2UbzUfVdUfb9 Kp3ZwnqcwTfIcp1v/VD0Xb2VbwT49x5+156LuNwi34axaE05WQivkRpwd8m40RSmhLUVixWjJxdB BsCRcT8ExqVzLDiqLM1RgVlF1Vf3hmOmrIuh7Zc2VUvwkGOVZ1XpL8F6ptvL92FnP0fvQ37xs3eF dJqkxSgCJ3ITJbvD5ZuhKSpjlpxcdfnJIYgzvtnOkKjsCtPVXUwXlrqZGhJFnMEpoxZCtG7sirFH rLYWonnd3MafnSFjN/RF1w8JwQ18UxTqDwE2qLTEbYwi6Mbe2h8RVEzWxYYYdG7yI4s68HORQyYh Cpujdddov/Ga8I0HPW/52ZfoB155LSH9fIC3kDRe+DiNog6QWPnSNzYFqIlqFYFNXq7HEKYai6pt +5xiSkHNGa4Z04VV12xMhflFNQo5aaihDBaIYJFc/BY8BTAo2L974VFcvIXyJVi0KDWCKG32EG2T YmYczMYkVhZEP0X0kN3W/KKGaNsRoXm6BiYbhB0GfDJQCL/qoTUeaqsG/JhFWOg11e0GIobD4oyA IqbgeEsBuR/MQC5RWZX5xVz+mZgiqiSbIdLYxaSgdrLIeQlFTW2nKgfFdjPPBfm6Gd5KgtnaF5bE JrsQ4HxtyzCJ/PlvKIICjdwrVIIdBCJBSjxSG8gj2ilNJNvkiNk0+Jdoi3YgxMBT9A3mV3AXc4SU RVk2SErYvMTl1ZHYSZIO4AiyDu7GW0k9GBsD1wZapYlcSz1E1aopi7Yuyzpvx7YoMRlpTDHa5Ex8 dtXBq7e97bYrusYMyNW0QzmUZszHohzHajDW/L+5vVwLchWFGe5PnNOOxThiFnc6zoEZYYjaeUWh GTCq1KsSNYuXT2FabJKDakAtohnQkQC1mQ9+hUatovJWp00ZYuq5vkLVE5XqwMG7tMWqR4VzL8Y6 79K5FUXr+04kdm1Z9FDrBAefTM8OkzM5paYqmrInunc5pYUbYXBAp0Q40EfQJtNCEw0Lr0CDPYdT dkGvQOdCNLIZdhgsvPN0vEV7E4Yvm8H8Tw/bOZbd/HAvek8nnk2FfHLfV3lH+STgBdoeHTUZQ94z fUi5kMvzCCA4V/0c/SEvbOwXmoe1gJAiIGlzsQYf7XoKkceX1nTA5jyjCXmy1UxkGzL8dTUUpkGq SRgdM6sfZDpbm6KqmpTp7LFoUcOWUQ5FRSyHYMdNEjR8frWV77KykpRTtrn/DsEw8pFr41Q5ZYA2 aWXlwF1YhVufD04G0ZhiQJiT5F2pRQkXmQF9RlD/xl4Rez+0GgQ/+UeCHmC3Ea3Y1L/6oqjCQ3sX 7paff8eneNsjquNTVv+BV7ldNEt+Z2d8+jkbf4wr5gr/ZxsDhaD4bDuXTUtqbr0hLLeZqkOesG3y LoHtLtR1ZmI/Ctan4RMKqhoZ6KT1vmPatwSF07DjMPCCXYeBPP0YooGERIyUH+W2FLogToQvkZlg 6QkaA+LYiJ9whSVDNLZF+NtSiUipYxGzavOO3I4p3QexvVgRNLWsrh6ZeIU0/1LQkZk2bxH5iUi2 GQF5mnI+Jn0fsIvKS1fHpe/sDaUvXfi2s2CVfk3TQIOxQNpvaWZgQBLBsiNiNTVmYX0LR62Esxqx JkfQzmFsA28wFe3YFGOTlAdPNRUOQSILL8HsYgLLNlPhGlNgyS4EDYIO6UvMj9gQqRdbIfWPKPGv rY+APyJ8pFp6k9vFswgol82h3gInO524iHr2dZtuWuwBKcsW+QYvqIRQOhk4O4A8AWdoC0wHGeGt AnkjcLwJEOFuA86BA/CNUcIScIiEJTDhz4KrpYB/7+xHJjhZ2A+BjTwthEsrAh/U075kJ7bW7IEJ 9gjVQ5W3lMq9QQnyXnUbnQZ8CNfYdn1R2rh9f3xM6f8ETEwp6W996QYX5G7pLzlXfY1KRCic7n/v S5I1kCtv+s7/+spfWOlKYX7JjtkOu2LHCQmGf/t4ic/pjt4EhJ7a/EWEbpmqVmOPNX4k/tZksMAE DMdLzwomW65RAtc18/VEkbdw/Zss1IKhtMhssoK8e4cesD+J7A3MdkGmFiE7YtP/4yljY3yOiQmO IVDtwl+d/NckIcF/e6GIXWBC1LpBDMn+JGK4khfAsZpZjF00T32404Js1hdKgtwmR4nwj5V4uLyj UcE7tSpT5IQfH+AlqKcDB2nRgmTlC9+7eAhxaeI5WvwMC+Ey2dlF6Uudv/zFP6rpP1BbqxRLTXEo C5hzenNEU1zvUU3x5imTtv/taeKoxHax4//HjzB+bIf3UElC426pT/Odj0+m7xahj2l6bzAzWgHb wgTdDfabAZstUhdFyFp9WTLayUIzOsDW4ZX8DpUOBIVHm25aYCvR0pMZCjLZl6i7okzZjrap1CUi M+iLI4orm3xu3SRHvCqZwK0m60bYKYRWdnZLsP7LD/MH7zBZSXvApllJdeTj/E076GDt57ZCW5Vo Y4E9t+kQsHujHrDbrVUwXA3pt6nF3rkpJs31UHKbuE5kLNT02BRDA5GYJ9/Ffv1NSZhgpTApRURG s2hPxwFsNEDCSZjgYaVWjl/QmF0h0MsW7JcocN1nsu+FlWxNnidtfJDml3STxBCAOKJ4J3kShTJv 0XrBfll5BXbBzusxsUTO6t5JErvVz/2ExuC7NCv4wDFpzd0V6A3uAtOq9/v+RF0jJGn7IW8JxHsz q6qxuWIIy57bdlrkwM2t7rXAFLRFvgtcm1N5Sn21ilH2hLiOd4igj0UnHYJo+id7aSMqrRMEIJvW Rjv05xQl2h9RSWVgKEQXRQXV2NabiOaKHaKk4GPmmI4qpt6pSCLIHlKmoztqsg7ZSKDeR8Sxk3WU Q1B2F0ho1rF3spwzymKmieu7WSKzhFMbDGssKLeN3XVDTN0bTTTYEDHKOueqyzzmoi6tO5j2sYWg wFnZAPL5vFdbS8pU40sj+I23spQie6D4KMwohngLHwggd5TxAbZJtGki+DihpOcH/E2nI6Kw1s5E I5HxYujWmQLxj+yXjZJpWos1J/mb6zCTFAC1g62wJ+3eNSv4ACRwe+m+GrAbse6I10wc/O6NOlg9 xa64SHptW8CmLakWId/y05KkYDRYKAqaSUKOJUJHA3ABHT7BCztkT7S287azC1byFpjEWdTIxx/7 ygkl1lHxAV5o6z9Wjz9BCXfy8geUbAxJPv03ivUs8ehyWK617ILUU3E0jrUT1L8tWek843y4IUsW WCmIP5U+3LHuUJfYZVraqCIZYtvmKPo9ifS0VWlfrhqjkE/MW/35AtJDzlGjhkzVGPrGT1W00aUQ Bbv6RzaqseQgEabuhKIOljRqGEWwMRp7Yu/PH4EokE9806SSCq0QvCVMhudRD6ng3J09RZQsFyWj eedzYFeYCKyHHzvAZ5oe+zxqTASUtBPdPeVDrpExMvlkkfMgjomqx98oCl50QEd91Gw+sUkukU87 cvw13jNHhAa/pPi0GvrfiZbi3fdirM7aEsFInzIh9mkxiWuGzvRPoo/8UasQm9GaxDv5mwN2tng/ gf2uzbOPWHFnvqksa1acEKQCsj9NmV7Y4m98YMuMxqm/TtaRMrapXdCcL/kF7SO7DQTOhzmFYKcc UnRKsr7lrq5gEwwWLDZg6xysn5oihYX5ZsCOAez/SYgJj01JltbXMZX2R5saLShKjygjdggoWkEq hzaGdAhRC6fNPPsjxukONQYIGtIidlY3Q/CwNaeamfjfqGoWye4FUIq/CnL8nA5jsEhemyoX0SXE z+dAKTm4aSyoatnjoc34Irg5h550aOPohLI+56XUSxs3T5NtPZWIrjewknAipok4Ypow+qcKzgjm 5dx5vkFAI02j+DvfGLvVfobqwsfXSAoK6TSYdLIjPYdlZVR1lyrvZtk6iCMRmk5qIllAlecl9Oco 089pOXCYbIx3Up1Zycbw0sa22Ea2fNsN1qdAWNc4Q6fFVvsmGYTJOrEjJJ3MvXtTCOcDuTl3YkhK JPBCDlP2AdROzGsY1ZY2Cp2o1ae4Qkfz3BYRS8o0yFjJBYiAbRdGaC0gyAhcjkFDJ4DaAXCTfQ/H WySew2SQpSlbpOsbyirBNd8Ndhr7VmJ0z8UiXZNMTiSSSnc3WG+p29Rl8Oi7gTXsO7Ik6eLcoXr2 VVIcuITzuRS921TvC+uIsPKlUUyzxtkgfyOY1yIY3qnXUL60XZhs/iaS5Q216Kn7NZzAQJ1kX1GN +d67JOj57VnZahxwDAYgILy9N6piBuwclLXoVVlv05Wda+MN3vzq8VZxQqh4LMp/bhGA7c8UfTCI ToMCEOaxP6HjgaVecZsBS0+UQztoNbuQaJxd0iJr7NGSsy+WmFUizrm5jyGW9iNRlyH98nm6KqdR 4SgR/kaCSZNum/TyTlIY+OY4xceprFRInbNhK8fXHqxVmDemSZoCoUQ13GHiane2HQL+ZJBtA/3O ZGtTjgXmJNHtxIv5yDHQU3YEqUbe0uq5AEhDhjJnpba3a3JlyoTPMSLmA2uGXYfCfFy7Bx2FUSdI J0dEvEfBHJ1D8wGtppLQIhVE5TxtHFLKHBmVl82QNDKtgPWB/yOhvFxak+SmZw7/5AyaSYR6JPo4 9eqkwTkOdY+1tA3gOgfsp+YZU2Bf4rXDIeXMzmNY1+xn2KxBR1lS3pQCBTVx3+730SLVWbuoKdO9 83H2wG6D/jhNWzHSoXuNvYjmhH3yx91QnuiG5svcS4IddnX3HKE2KSzxOAHeAujfIp4HvHtflZhs ePzEAoSFrbwTONdjiVNsk95JTaZnh2cL6oW3ZXDOkiwJrAZ00K8Tkw1ryXhLAdd9YNdORPsOTRFo hw2AOl9Jq05d+pSB/FNepfxQoSx7v1vj8CYHDt7o2lzYmBCng42/JY0k/YiOOtsv1kD7IK1d6Y5h B1KM2yzemDDEhAxLMnKdo9oZ+te9Keoy6ZXNbfTsjMrqrrYW55yoDFh1UxHi4kvC5Bmrn+A6zVy5 e00AQhDRaREg8iOL9G+0v9QfVwohC9VPe8LnJOB3JEh07I8skzCvckvXwwCJDXOaQJ/BUIzkcdjB nzgFoHPk42xMxjUfQjgbODKE8OoGp0W8RQeg7J7ciTpz7iDj4+Q1L6yU8DCMwskMlivR1+1QUbtB tzUNrJCC4Kox36YSe1UUb+32VVQjFom1Y7HbEdPoeCog4OoF5XZgGm3Uln4Kyg72V1jux1lmQ46k XeJwt3F/r0Gyx+dXkhL/8MtWdY0phjlnQZYqRkVl8C2O/imNkZTFmC6c7Ve0ZUucuDCXSst+tBFk iTZDwKfzLM48BQPI992EoMfoGSGR0MlRSEOkh9MFXrh3mnEPb/nYt7O0lnPfEO0y0EWaaTzZFRvf TRXe0Eu0cIvZKfLip1ed7Akz3djkxNCRaP7OzxkCnLESm5SqP0flkyfLOFAfh1AmHUx3zOJGdUwC gEjkYM9Qc9AjjgggNhOmtoB+SDFGXetCTfkgfSuhSj2g4r8P9QLl2WIPzV71skkcN+c5X70iVO1W LyR+TqqXsS+ltzifQPBzb/QL212bJp7e/xCzd4N1mQrvB6ZN86gK+vKh9OsL6/dm7kcmFaSO+kYH yJCK2vdqr2l3hv3EmW0VpnF4u6zJhbdHsLf4DgjJPssGOJevTctOF5stvfoZNuA4VZttwJaDKey7 RWWLYH1NDouo/RyflrwcbgZ89wnfiYm8TPFBTECPg8m7+5PAM32JI7WSEnjbxLVzzmc6vJMz3J+0 jGnxoaoxNS3zJ2slu5BK0AkTGgfmIHScwN+4JkXrRNtCM1qouF17hSOlSA6Vd35mCcWqtd5oTPNN CkmTC8xC8C9TA/6ot47JZCQyqwlrVLVflC1BAJJRmgvGV/I3poJZ2jzEIw+4SVT0txc+/hLPFrXs fHD0hHb+km5Yd6QH7Cs72HTf5RqJ27Mz62euv8DBmhWmYGX+yu/ne/Qcp6yPZTsMpsF/tRmbCuZ9 +u/5o4OP5n0yHfHpvsDXYxN1W9loxxgc3972ODeqxOY/lCuEizj3EaeY48z76/y5e9tketzGnCut VS1eYWoNvvKHp9/aL/2hdSn71sL5v2uDsJvTrYMYq7HD6fI4TL7D6fIg76DuGnV4dwpU20PoW2z3 sjX4zy5+yJOZrVu2dp1/g5PpX3jWLrcvx8cIZ5VhTEOBA4bw0nzrhzgVr92I7a/TmCscPxjudzeE +0HWN47DVsSVPSmvxce1cHi+HQpGjOYXFdc4KA8LO8hIhXtafEYRX8jrsg6LPwZ7GnCLr8EtVo7W h0TqDu+SGrQUeQ5fAuitECwJ0r6FbtXb0/uEKBzU1o0WUm4gmf24oyvjCwlgCb6kYg8VZt113jQ4 Lt/JTuosczFlgdClbanJ8IEBTwHamu5iXUrN9Nw0QkuD9Cj8m6iiGCbSWTGNBi15UR3cc1Bx5fBm 8l82qCe+xVACTDgb0SuULl/ndWnfF8QXGsI9dYmd9vj4JNav8I8vWRKh3tmVLq+WeC/OExJT4Nrq Iah27Mcs9Gw3rDiy3M4VGBS8LWj/hcqZobRkuCIMDT6Axqet2UGJbYMuVV4t8V7sN/Umy3aDtmTE Weg0cMRRFEr2eVAYyisl0OXVc93eQm0nDOGLGDU+evF2VkVlgrJPt+2BWtB4QdZx7B0YkhW7gWa9 3cgmvY7pv9Qd3nVQA8ZNdeTIfPShyn8YpIG7GWpYa3eK7JBXWPcYGmTfYDjxrbpqXHrnYC6t1S7H bgC6fbZxVgytdphnjJIuz2Ct7K28yGcBYX3t12E/f5Z/9fLm5vXPiLTkGOstfTB/MPVRw9E2Y1eh R9cVjlNnV/91Sz3MPnXbP6i6B9hvVJlfIfZ9hkyBjCkcJROPPYTfdxF79D0+BeKN2/uOPRCbzfyw jWTSYw+4uBbPSwBhQ49lFSwP9kojK2vjjBB6wBMa+yUcedKGHodP7ow8kFOZRx6zog0soFaLyANz Nrnf3jDdfzzysGuONfzvFHpIzdyGSJ2oORx9izUye2ZDCA5qQL9XoYevWd6xKM+NR4tJ8IgNAfOg o4U+4wPFNsxh0AFBFUMPiDNYkjJaElMJ/8B7ZkFHqAt2ObQ91ZAC21YIFPw45hZNRj+FDsKhQEHH mjlVUjfRuVKzO37A9j8J772jlvIsfgj3eC+PBWd8d2P0EUIPB2FVFJT7X1leLfHeqkRwYvtBMFKh 4IIViR2yqnJ9wHi7/+ib3f+z8MGVnZcPLfiSbdvHA5nQ6MIOG1vICEI8EEboIxThAftUv8JJkGPL ezfHA8a+Wo/gfB4QfCj4yFxCgLim0HDGCQoto5urAusgCO3d7YmsUIZmcu/4dBfepMe5A7NvrdtP 6m5z7zgyCRZCTtGbXC+8/DKtudu9s49bdO+pPRxx7+2Be2/wLasS+Qk3kSod3/G1ohbf9EDCoqgQ M9Xi5oNXdJHR6oe7GFThoP8Wn+aZzkeve/csLy7Uwa4pH+pgRdIlp/guBrZtMHFmU1XcesvzQVDi 6TDY2cEjX/Tqc3xY8DwmDCvA6dnrd1evf/jp55fX2btvMenC8BvEgTb8wweZO3CisZ+BxScuZoN5 8PhtlX/6vUt7RB6AYcAkBkzFxNXveZgesFFVnD7F9kDfo5sqvGK3/jb+xHbIsCsxifZZ8wjbAZD4 d3QDZdbJucXtSgCB4XddOdQHlJ1eYpwow7nLUEPRwyVlWMLfDQiXkAyAWLwEu2dYxDk2jerE1lRq 8GHnzn2Bdn1YfvUqrzLMHoBzl2bGSUV2JRxYJsBtthklpiht2rb3B6bjou/Eitwng/8SHx6waoLG bPIXF7Zi18qnxrhwbxcfp0r0QKXhUfxn8OggVzHxyE6hS2t5O/KI5nEpeuGRnWGBR5opbsSBNza1 68ZxN0L2804YMyRRaiTKVrUqCNkZM7zF8RDEIlP+FBf7UofOmHMkWvSU5Fvks+3pVj/40VLM5ItL 1eNHzabZBg3whyXXnD/JDZW6K6KM8CI+7I4O3MkOJ9bfBVomQ4Gvz5dIEG1Cy4+ecg6AfLR7TqFC djPVNKoo3zhivKh2xJsom+i8idjE4CQnb5If8yaY+pT2I+cdh2jxNHMPsDe3o4mBt/YrKn2bxtno UgthE+DmOMtlJ1byuaCqbt1mjki+gDJh2D0fFqrkPDBRIwqMImKz9pVCiFbuUaqWXeBMLnekGElh 59oIEt1rrWNfTwocnPMWOBy4yARfImamxbKEwVacNDNDUWg8c1RUgDWX4DTfn/oC5SCnovxcmi6y k6aDKmdf8YFA2I72WhQdzVkCbXj/M4XxSg8D4xd6mB0GaW2HHIxNEMz4PVPDeZSm9F4JOuj9PEpb /5jRpIZYTxvLjhuksxMOkTzVFzKTmKZI7PadydJrnaPiUBaTwZtJjbcwgvi7b4zKTZjxN94Zup1H F1EM+Y/AAiAFNPPg/aBLVIJujRqMNwUE708odrqJ1Hwkcl7ME2XCAqe+Zj6OMIJy1NJZeHUy/Y5Y 0OJTfki5QCG2sADpYhel0PZ+jeL0kordSACJkj0cst1zAAjYt7snlM42oCGIJb5oVMgGoo1tErps Gu+bzVDyH3E5N/kKZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iago2NzQ5CmVuZG9iago0NiAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDkgMCBSIC9Db250ZW50 cyA0NyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjQ5IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBSIC9GMi4x IDE2IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKNTIgMCBvYmoK PDwgL0xlbmd0aCA1MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7Z1Nt9zE EYb3+hVajjm20PdHdg4mYIJjx76EkwNeENsQAjYBQ75+fapbT/eoNC1NS8O9vgvshY5G6u5S1ftW VVe3dH9M/5z+mPZZPaRFXWdtldZDlbV92lZ91vfpT6/Sz9M36fsfvC3SF2/T3P5/+0La5FkxVG2e jz8dz7o6q4o679OurLO+Hsrkxev091dpXdi2HK5ep+//ocjytEivvk4P6Z306h/ph1cizao8ySXy FE3WNG2dWnmSNXm+SA8P76T36vTwRg5Devh5PHs1nv0kh8Zfe3Un4Zbn6dUnEQ+xQ6lFXmRtOxRp x0PEKPXe9Sm1yMXKTVN5eeKU+kAUV5TpAQV+NarzazmIqtGxQMGcpaJVe+Bs3+HlOMJP0pkY7GS8 fQZLIlhQtGXWlsMwU9AJC5IpC2INFgRQssrKom2Elm15Tp6RlYllpbDg29EY4B4Lib3iFZdsdB9F 12Z5163Kmcy8xwV6E1uu663rs66ttuoNgP8wwu/7UYtyuEa99UPWlPnRQ4yM1IC7ScUNZVbm4m2d xwrJkzpDesChuH96xcVrzAeqJC5QibKyoitujcbKvMr6ppv7VG3BU40Vo6ry8eC9Z7y//DX87Ccy ep8efhlDIUETWUol4FHcSMvuCPllX2dFWc41uRryo1MQ63yTnSlR3mZlW7UhLsy5GZsSBYLBOafm U7R2aLOhk1xtLUUbublNPztTxrbvsrbrI5IbiU1BqONx/TUL7r8IAoXnLv7jjn8ZcUlsowXtSUn4 0ca95PD3UAOX0lyZMfL08Iyx/mSOkurQxRdyKunMeHfissvH+qbX5lTuQqS3ciqk4kDy8o38KAkp t9xVWRLRWtPPCUhCOxvyb2N3tvPEDaVVsl2q53eSSHIHwCuzhNWIXA6SyTRNl8aDJRq7O3zNkUuS KVR9U45ceve+RqYLWdnHuJpYLsVmLzu0OORZnrelGHWL1Bfw2voF8tkgr/UUBUp9NzJyzunEMj1M sK3sSQ53ZZDjzOcSTtt5Ke7jMk4nh+dbklefikXWDEpJXvNepreYPyIA3AynmyEbBsn+z5cMouW5 JH9omzzr8pwShs4MZ/lDNKmPYSk93BfoFUVycEHCBTPA8+MYLHTghBovRmpw5+8chi3PYIa+E4LR YEYTboWg9p7kwGQe9hEPuYUf6Y1ryAS/uUXnqNAr+GQ0cAF0VE7qlWMvJ4eZ5FFBe0pwRH4hkVyC PbKShnBNP3jQI8xd2TUGYAm+2VDlTerQeGvYWhdZnXeEvNUIvMQOTK4PD8Q0JpWbAGB/enMuNy/y Jivrok1b9TSa67NZ4OFeZKVvR7pV5F02lJ0UhJEnwtqiXaerD4xHEd390RwlBUezI2kSl8ZGkIaG Ko8+DvMYE3EX/MeLaPoE6BxpzR15TVm0Wd81EtiUNVexuc2a22aiZSFVoraoZvJodJ1Gkihr+knJ 1JqJm3TpeQu3bEoqtlYSy67LqqGXnFLpfvVZt0VxPcs9x+zjTKEqs6Kob8+suyyzvoxZp1lym4Qr 7zZt1H8K9blI1jAN6d4d6ASBybdtl7i1AhdmoTbdEAsZAr6HXcXDcar8GKm4yXVLpJ1C19cLNHRt ep44R3b5Q9oknWTISRP/kDy5rZcmbgklqBXh2mRa8eVBTmVJhFoILXj8n0dVoSKG2FT1n04AhBfm /+qkvirbTNzkkLYjFhcKUmq1RMSLWjMMBr311ZIjVYtKquoDEwBZ85TkW5Y8zarn1YszniQ1/6yM 9ubzi5tTQSNr2FIv69qikFxMC6oWN0/9OXx7YrggQflfcpSaUjseMDsleJ2mfz0iA7j8Z2yguaOb c41e9LWvpDMZVo+gM38awAfAqtkOO1kv/Ld5JMk3kFCnxfSmMY+3QVDbIHHNHR+5qKUJZhdzrdkn 1EMEn1dPn+Lj4p6cZOizppDKkMbMek4ijx5Ptm05yZFssqhcVm6B/gy7tsizM043Q50NdbhaP8vA YwOjdcFXBqNSKgYIQJUJICUmMKqBB7hgA805U1D1kUDTD/cuk/PIjFc80tasq5CSSV4XXbqmvZlH upGsq+mbTGastybramShu2ouWevAHfmDzbreE3C1PrHimpvz4PddDsSpdrkWMj7tIjRoB+y6wxGT 2bGUoL3rm9HH46QBIFLN5nIz4e7Kg8zKoInbjjN7LPc8Tq77hmAS1z4yx+MaDD7WSu27wjdDQuTk iTTDFlJO6+ERCIXA04UGNtZeq4evclmKaKo+BWOhbOqdULDtsrx1SyTawc8c6iUu4Vyy6QOOrCJl Q9vGVTQw8frhxij4yEBb6AFut8x8AsTye9nOEksqYevE8l2dJZYvDazxJIpYloKoIJ5Y03Tbr1Os zwtKiSF1LxoAOSFivRMg172sm1cxU/hoYu3ILI/EqgZZC3XrFKuZ5VLmFOTZexJNYoPbU5w/KdBL OZXJBp7dgsWvKBDdQBBh4r9jA1fAxLVzj58o2xjFRIZrwJkHiA1yPiNLVjfABkG7PrcuizxrC9nZ 22CVOH8X9Cwuwh4jri6Nr0TcCMfgsw4Mst8xWD+sTbbbMcTVL2TTdC61RqfjBc9w4wWMppKaRe/W RG5ByC1lBXOoL0l7Mat3ENbWTwzbJTJp5OiVvzCVAZnN9ZIDnZPEMsYzOocS/5NTWarTc7MTnlux HE9+i7kr7xOci7kyoey6MpXdrRY6C9Sa7lyODnI73OkxyBVF1uS3J+bmZsOtK1XuirlzZtng9khi 7mmm+bGhhEytaMKMx8VcHVApaTyUJrWfdxFlmWLBJdoRXX8jmJvv7o5dtvKerxOsMvuOO3mXQ8A8 QdC7jxXy7lA2FG0dka9EE/6SrLbuJchLgXJ0QLsYtrRjzc5gwLsukhCeiGQ6vBGeXOnPXkwOJK5c pCqjueRawF4SV8IbI/4Qqs6TRdO3bk7M1MP7W6ZlEv1MWrTTDHN0NPeJwR8Zd3Ss6eA/GIaD9O/T 6V/9fTKzrCxb1Yp0Axyi4Wnj0c7yeW0ik5R+QvHxXVR7annlKJci1Pm95UtzQMwJ2jhcGSAcq+cw gjoj3NFIpqGNP/NZCEMAo5EXWwoTs7TPofQx4VHvz14S3c5Mz4ruQ6dUViLhvZTeJMuvb447RCQa xJgvLRJ5e1PMF1LjPBnHKNyKz5l6kuQQVzg1ZWG/wdDmKE7t9PYUH+EmBZ9eorBz2zpkJ1wmU+w2 SmE3+C5Fbbfp9ZfMtFCnP9gpDWZ0IQST4fzx5e4ip7owYhnrV6jWUPEMn++STceqz2CX2PXekPBS hV/zwCMgEQdQ55aHeSSSUA9JG6TOFi7nVVcWDehzHGL+tkgw5OF1aBi8hWVtnAP65E7aIX28V9iR A1WyCzAvyyZ1qIrIgW4m6NVt1taXvOWAFvVBT0tYmkX7IJaVMX7UidGKo/cv2dCNtuVDQbR4NwgD EjGwilHGuVq00n6NRrRfd662M2CGLjgj9aQXCqjQSj+2zzWnyR63ICB9aq8BY8kc5xoN1PIQkGdH QGkXGRb3EKCQvQllKV4+GnDb8L9zj0JdySbHxr2hsDpnW8qyNPI5W07DgytAYBOMcMA82YhpPYwF us9ogvbUiOEWPDaI8W7RAu6uGugEHKb8Ty9P5U4ziZgkCP7qfFWAfhhx+r6cfzUPxNI5T89WKX6c O5RpBZEHXXcoovZA0hvOHK+TBrLQ1A4SBxTuVufC23iwd/JT9rK07FacNA9mk59NPLA4nTjkqTM6 ccjWGuAFowIGne1a2PoMgVvWHOsxpbk+09ovVtSDeDilylXTiiqhIA+hWaofnl2lPAv6QTE6nV+j LpFDRz+JAJGKCc6I1utjZVVleXOiGI2x+arvvf37085tXyirJuvqZvCGiqiPHQ2Frwq+8MQkGh/L ndqrevVPsU4AnhvfOmUMjEl1nCCJkBEirbcrcA+yMtcetXVrMtfCfFkkvDJ3iceaW8h6LG0h9A4F yTIxt3ZfaiLnN71DYUyrc0A9vA57HgtWJuBCZ/TCQbfDx3DIFFyklPFrfr2qNLP5RrYv1pgnglzR AW4HfP1qU50PmVT4KKeteuVoeS6qNubyya/ebYw/s9+cj360knZJEiYGNJOcSp2V6gxsMPt9JNfM EpSOJ8AXwHIN4OjoYifoc/QyxHKiK2OebnWyHfu8dV4/CKRjgBYpIRlEYF6JsFyjgWYHDTTVoDFP Tr0e/tGcBprbnCG8JrxX8XW+QCr7vLtBKDZC6LYwrJKPEPR91ALqjTCs6mV9eYjaDr+U0jpwr9vf emNA6O1voQyK+JFAsUqcxL/5OdsKpBkZRRz7QvQCcez8aY04XPNssg8ZDE6aAEims3FiFM7le6m8 iDfSC1200/4n2DWdwV5cnFYPKn5q/J6epl5nolRlnXwDMtW4e/eRpurKTNaoL6nx4T41DVwtGHTz jUA2K4AbQhX24HBlzCKTcZIqoOKRZnc5YE8AQMM5Jm0YBDHaKSPTa7OQIVBTaZifjWrnLmfXBw75 kpt8UastUm2MVXAcnVKwjolOYAM0CCDeF2Z82d1pAzZDJBQ4XvRvlmN57MBgmpZBl8ctBFVkZUAs RjvKNtj2aJPrM0YltZe8rbotxriZiNXKTLmIWoE+ggPdajig6aDC/zkWvrECeteWBQv06fCiDW0b +mUorulOAY9e3/HIsBGSdoSENa9x33gNSSgRag3pJ+8friDd70NcQPrZ4P4MuT4m2Dzm+BnHT+Uo Sbv7CAbiBy2zRIUJhcVOhhjJtrdh/fb89Z3OldngXMhXpCqAeGtSy8bE1uBWiMipvk6YCDna5HyH GAhjJ84gBFbTYNfe0GN+uobDLQQ8zS4aIJLjml8KEvD4bd3IxPA6nYTA3KJlcp3yhNNI6z8bvCYb Ax598whISw3aMbzuWjdAJp4eg/gfrbpowEPQpygoMhZQnEw2fG27Mt+D7romlUWgSIhtCwU716Uq 8zHxQj4gvn/3D54dfGkC8CPm+nZMyDnzJrF+SzfXObvLABnJNvRl+SCBGAIeBaHgEWzhBfQ0Ijh7 MPO47vy++V2VHmxXDAqqNLF5Sh79rnQgWSPDIGU2/vjNGD054xYUoBlJZ0FijaIePxS2JPrDcVB3 meFOOPc8ua4Pp1e1lKm6oUodIG9NSJAqvnz1IsSPbSHhqMxIL7OjCikvwue1eJi0UlKbz2EM4+cw kvnnMPyCCF/4f/PNq5cCOvmIQOTXMHaIKR/VkUV6+ei6FnOtOHkzzlC+bpJXUYv0l8hzbuHI15Ll Q/CygpTHbKxeytM/Nz5KXsXz3mG62APNdbaB6/Qu27oo0gQ9hWMu6KK+zlZ08kFqjjM8BlwT4G1G krgv3Gi3qf0e3jM4TXVS6AVHHCai0Z5OGYlH4xbSI3xqsOizHuGsuhYinNU9zXWEeylmElWgNEYP hi3/RM6Qkd4kuKB6Lk2XPVtVL94kHofRvNjhNo68kF1ude2W5CKLG1idAxaCFt74VqmgHJvQYJoo +5ANc4A1vfjZlc0GtGU501GdEe4bqi5NPJMD8ztuBgYO9Qii+ekugiPQr5f3gZpH1TQXY6hHRi5J U5x8f53K6fcCL+jA0kHrgG41jfTXPjUB6FpMFon1HdiqCnlbwCw/mx2UkdiKxvol63elfAWoaNx6 ot7MEJmAoD9goL091wAFMAApwXqKDyQWKdiSBn5uOVZDNWUYiRZwRWey2rFbMPu4QIPZVCAoqX4K jzPnMI2j1dFtwV3bJ6Q5faLDt5Kcy5ulmz7QM/3U2vi617r3LeWjF/LJ/zZ1CLgtGXHZy1+ckr9Q E5gxzgC5jSA7Z7BlZz6V6ZYDNUF8cuv/bgnw0wewpX98gpsjTQAH342WBwf4KfBDe0032tEAGBEi qJPoQDNDOENAO4Z4bGQ7vlxlieaLkbTgVmTTAnPNfVyQFl4N08A14x2E+/KOSCCfJaQjiMuT02QM P4Hl/EgvfpKx2Bf8Vz9PKH+zQz6ZJmtjZ0Axfb1fMmceCrmD0WrJKtapoAVByt5HMw5hfXdbZRbj u+rso93469Vll2dlF/X259IkBf35g8UfiIcxxCIdfXRI4Qy+YlPh6yU2WXfRhezALIq+ELhF6yDa J+5IYnyCXLZ5NvRuKXY1QY6W56IkppE/izdELThtk2dvzKhL2bIh8+JADJvFjEvkiZ7om62rEuZj 3gGLluci/MifhJS/8xFSzzsJ8VIv6oqouoy4GFfywHPgCIhxxEF8xV2JYicFWP1VXdwJM6tMNfAO a9rL/EfrzOY/2gYfmiguEz4+z0pijthIiLw2ivtQ+sA0lPDPRZ1iuFnfWvZdjcXlXPqRZFhroRx/ 5Bo7AjkLPgZFkoVra6oJXPtCJBOLPEE1aB/vz/My0jAK2o2H+E8v7CCGmRSKu5BcXCEx3rH+H1Pm QYwKZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago0Nzk4CmVuZG9iago1MCAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDUxIDAgUiAvUmVzb3VyY2VzIDU0IDAgUiAvQ29udGVudHMgNTIgMCBS IC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago1NCAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4w IDggMCBSCj4+ID4+CmVuZG9iago1NiAwIG9iago8PCAvTGVuZ3RoIDU3IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlnF2T3cQRhu/1K3R5XGWERt/KnYMhMQW2YzahUsAFGAgQ bAKGfP36tGaeGam1ks5I6909Vam90OpIM9Pqefvtjxnp5/RP6c9pl1V9aqoqa8q06sus6dKm7LKu S3/5Jv00fZ2++94bk758k+b2781LaZNnpi+bPHc/jWdtlZWmyru0Laqsq/oiefkq/f1VWhnblsPV q/TdD0yWpya9+jY9pQ/Sqx/S969Emk15kpvIY+qsrpsqtfIkW/J8lp6ePEjfqdLTazn06elXd/aN O/tFDnW49s2DhFu+SK8+jHiIA0o1ucmapjdpy0PEKPWd21OqyWWW67oM8sQp9bEozhTpCQV+6dT5 rRxE1ehYoDCcpaJVe+Ds2OFrN8Iv0plM2LXxjk1YEmEFpimypuj7mYKuWUEytYLYCVsEULJplaap xSyb4pw8zioTa5ViBd+7yQD3zJDMV7zikp30Ydomy9t2U85kxh430JvM5bbe2i5rm3Kv3gD4Tw5+ PzotyuEW9db1WV3kI0M4i9SAu0vF9UVW5MK2nrGW5En9RAbAobh/BMXFayw4qiTOUYmyMtOai9FY kZdZV7dzTtUzeF1jxqkqd4fAnvF8+TZ49kMZvUtPvzlXiNNElkIJOIobObMHXH7RVZkpirkmN11+ dAhiyTc5GBLlTVY0ZbNkC3PbjA2JFpzBOVILIVrTN1nfSqy2FaI529ynn4MhY9O1WdN2EcGN+KZF qMO44ZoF93NBoNi59/8vHVj/7g7at71xP9IeNrK3JCfa0QDX+E9pIAEiPxJv0Pxfcm0Id7gV9/md MxLuecY9nH7lutMtFqRJT1bSxA+sg6fPT9KNBDz8qpXymxsCiv38gbuVeItYTPuvV3KLGYMxwiik wtgZwyogSMUta3qwmuMe3Ske8yenKt9elBxJGgeMoizyrGrqJgWEMTYhaopKWxbEkWRoM/AoizIz tem9OBE2EW2iByh1pAwJiMquLpx6Nil1zUaZcX3QITqgEhM9NuFRIbr426ouy1QYZ/JI1/ytCtFF 6OMzvh2ijypu+qzoFp3EzP1Hz/gBAI7i1H3W92VMHr8245qAoJqnA6sIO8JHnmRgQAgVIgIr9ANJ 2R+TE0QGgcSTu2eVwLXWV3zn2JEBA2VPSZ5rHwzy58EPTZk78czLrXgVnkk6jUf13vypMJ2UbwTU zNoSjd1LqFHnWZvnVF+uGdk077wbVFcmq/K2ieDV/ytUv8AqQe7FoFqy286kDbN2Magui8yY6nIC 6KLIuiKSqknFGsd4mRwkxqvUma7CfTxgQ+6BhnHSgT9te67B21yzdyanv7m+gdYCmYeIFRaGMGng oflcosIhnP9IdUfojRuAuHVUCQ1zzYqYePeD3+AaPomnQAxpHsnbBwKsosylotpK+Omm8GIQbkqp K/XEexfA21J5LsqmiuPtCIgbl2MAf6DG4b0B8BKiACMAD9LA9hR3we9r4D6lG36lIdYA1CHaYD62 YI0Yj7UYi9j+ZLhHjGIKbmKrkLmugTsS1RJE7o5Gil6SqrZKG6btUmBd91XWV8uVmPsIsuuuzpo6 v0np4xEIADSvHa4BFCjVuJyyc4hjAcmcgW1wDEnGmkNAox4WyfZYg61m8GDUBhD+jTymVB6RmlvC NVuV5EftC7DluXrsUh4NtJ3jPFAB7XT1R7uLr90E0Bn2/Z9oHzJL2WIy2qLvsroqitSjacnaBN3T jHYMbq9NfCQtHHB2pTGSUrZzQTerCfuygoMFWnHA4oUXw7lZ0jTqjQnmAEzAh09qtQG8EmQMcRS/ anOiA7rT10Ak134Wg+9DAMOd2jrIlLEHxtO9MO2U2uianJqn4BaaYzn8SNd69B/lAeX5BOxDbZQ+ sQB60Xa0rCfbaeLb6zxf25qWiQF9FXRM9K1UGufcC93xNKNrvkUbkDivzMVlx2NunwnoGnz0mkDd tFne+ALfZsC3ZgMaKICIkHpUrYOGnZJQ7rV40V6Ga8yThg3THlBuO9Oujltoh2S+6J0JQAWn9M3h kfWjAXYvhlOJAZ/bn+dZB4Dx+AWjyMxoM3PXWMVwtDWhMu5ELhfhJac/ItAzjn/m+JEcxdoec0or JMJc6Ni6rcSvS2iF0Q65OPMmxK9zL5a8zQ1EZSX7dHrZ6+KRGBHqR1vGAWcVCqF13WZ9s1iXjXQO zDKzgG49dsKk2xgEYOkWzCINNZEBNq4FG7KdASQmmq450wDUvdCOH793rK4teJ63bEVqNhpDaioL Hlj6cWFjnuW8S01OXomIyiDoi87RCb1yjQZQCI6LH2lAZ/SCTkQLt+gbJD7K675N4yEXbQGzuHLY lBfvGyopLreyG+b8evGab9hD9TayD2Zh2S1QvSVuzVzMjKZ6ZltiAZtRb9mM7g2Ya5gADMCLaMik 0cpAWJdYye2hpchlq2ZV9mmtpmczmpbpAc9MiDZAHbkRG+rn3NLknDfsZAXesJS0yBtYunfPaBQd ysVb1KHUA/JKtk/t0OE+kzuakZS9LE4ur5tEep0ZN47qdFt2rF2x/Aq+sQT0z1RpTGyQcgidZgOD mEVSprtsNsdvNbAwnexSLhqZY3R6MYGF1H7zTmq/53cm3w3mZCtE2y+vakRi7tEQhUo5Egi9IChV QXTACdzj4bISREuHY84MwwSWtZzCGd1px4EgHw+CSDdevr9qOe3Qid+fTA8UeehWewlNUZzhgaBN Eh8tMYaGLdBO+xrUgBAYqH5E+oRZ6YVb5gU8y8E0YJ+eVzgGvijT6ONuj3zL0sjacJnK/tVY3O2z g6OpsIRhdX6TaEdPl9c3iobzAoQshjWE4GqmDehpIHILI9E1AQrt+JF2wQ9b4l/0wwgBhL6U0EkS Sy2uxgwjMB7N9Xhcwyg01Hmwh2KMYzrOeAgBDjEmghZdYo0Cvn1oPxHThwhWj/S7gT8NrCO3IJdS A2ob2eRVryNtRrh3A/x82Lwdtei3FufDgVEAnpJ3APCUr/YA2Ib5Gqs0/7fAS3Cs8wOugUDd7leX 8C4yqYcQD0jfQN5fBK3uNLg7mnBRozawvc2j6e6/IriscQRRp0SBc6JP7IKuaZDNgqr1170OVEfK XNaty6pKhSgnmNlMPvZh+GDgLG+eZb3xr3vpOuZ92FTVyXt1snIdlztHLFwXDs4yuxPShLweC3KH oiUIANbaG0HIIEdfA4b2loDbZzLS0CncDTgZgt7oJkDVWtxMKBpqF4BVbrV/NIwvMaW9NfGrCzTU aSw/MvAftOA8MfGV3o7t1wwe08SP6buYpaZXw22yB5Auv3KeEllECZEx09R1hNcst3eLlpL0t728 obkDV/vsTgdN5/YrhyppNfwn0l1KciV7urO8vMmS3gdMsuZmsAXSiZHAHR4j4N7ZjbefNWw9lHFs +GOXMYAUfbwAj8+H47W9TzO3A7ItDMNefO+TFu2VwdZJYMjkrFgMpR0lfeIEGZ4fUcncsKc+jGvo lyfWr2fQGV1zC+301nHGozl30vWZCtZgrcn5l5AXrfXMbv6qyKpKXjkGjRdjHHWd9aWwyPnKw1qg h07RMNRHHZ0fZ0V+XIXOWr1RPAPo/vzR4MkE8J6A9dQH3rV+ZuRdt7ZozWkaICUnbtEBEmD+3R6+ 3rsTyvSS48rr8GmlVH4BcUnVZE0VE5bcjfsoW9mB8fbfNlgh0CeOc4GkjpMAF9csrwQ2pZ2g9KiL txt6Nl8BGj7IUNS9fJIBnayEjtPtPDebo+2QY3TxRSdbBJZr0vexea6Sdx7a5u3v5fccdJ2TnBP2 nLQbDAfyLFPIq5HD20r+YSMoex8YjuZZuWzxbKOKxfvk0fFn9BplJQmp6W5StMNr4Wk4rGNB+6e/ EKARsJDkQCwETwwAsTzF450ryu4hmn1zaVrZfFpKGWpDd/eRMpd9Lt+giSpD3QRa0alN2Uk9uI/d e67xw9kcWzam9r5JO5ydLz/unPJhzbiU72z4Z1ryLfcy5+2wLS6qTHI3c96UWW6i0tm1CHlxzp8d jxyGLRvb6Ya81l90edul5S7pKYf/IIRUhtqRzt/YA0RQDcmB7fcgMp73azmVcqu+x+ev9p6wAw0m lHxuD8lNHURENCV1ABuAe50sIX62OfpmCIuMpiTazVqzWKC4j2BKarlZY7qY+s0uwD8a0DGuCOMR QQeZvCZJna07B5ycxHBsFdI7ZN+vD8bowwMNTsUPM5zFW3hZR0Q5CjtMMVn/HJpp5WXu4bs8Xq8r sPOfQ0v2fA7tQCUiBPFlKV+EKmLef422ggNh7ShOId99Kv3Wss3lg1jY2fTf1w+AxW7YUXGy+AnZ H8gknKPsBbYYYRHKtOOLcRqT0CXtKFAwui+gaDDbFslsXZZbqHNAxfCrrrhgc2F1a1qR88a1YWyR JnMAE4WEo6aTDcACz1hMRGPUmsy+WGnEqGmytlrOe+8lVspbqSr6fUO6lDRzHbts5mqgWFnVAKDA /KVU4mQVksLqYq0NSNFgVnGmN2sfYU0JnGuz1KZAp0AZ+wDK7CbQ4QgDAXoazNE+XZgKo1sToB1C 8CyLFoRIy37qiShRqvneghBjphNG5oDt8myBT6zaac9YjMyTrj3i7ZloKdUII/uTyw0E3odFDG/A GdnCuelkw8fm0FvEYZ0PQ/Yfqex1l52M31C1H5gM31c1RkqilWnSqKezX1S19nX8QzXb2UXgw6KT JLKJ+dpAND0fcBejOBJq1Y0vF7y9EOIjt6oLE2Cr8AnY2WCCca+ho4JAffh27dOnAWp4q1WGjETX AfWZRjZwDK+1FPHqi57Om3jbos2zor2cDRyFKKrvoioTu7yt55YrvO4nw1ESpacPkshZX+eU1a80 m+EN3KY2qX+qS1mRLGr50nHvP0m4acR3g0JZua1lH9GSR7kXD1eWmfiBGA+3Tz/Tasr5CtNIuvKV 7zy/mDSyMJUUU2LTyE8HU2vCqzAEeVA7VEyM9dBtf4DvuaadgE69Mhf/rQQXtu577doxe7e1rzMV QSPZftEVXaoVdC1nmK4lrrHY+xCU3u6Be0RdpLg4Sx7UMx3ao7LImY+Mp3tySUGCyyxlZCkp5u7w UGm4UNfYP8edQdHLar++fy40YEfO4mHa2WdOludyGLh7MZKn094J2rnDF86339K2EwnPhbvEt2MW e1n+fyBBF7sKZW5kc3RyZWFtCmVuZG9iago1NyAwIG9iagozODYzCmVuZG9iago1NSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUxIDAgUiAvUmVzb3VyY2VzIDU4IDAgUiAvQ29udGVudHMg NTYgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago1OCAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8 IC9GMS4wIDggMCBSCj4+ID4+CmVuZG9iago2MCAwIG9iago8PCAvTGVuZ3RoIDYxIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnEm33DQWx/f+FF6+9AnGsjz2Lg1pCCdN6PA4 LIAFHcLQhzCFofn2fSX/JNf1s10qF5VXpxY+nqSrq//930Fy/Zz/O/8574t6yE1dF63N68EWbZ+3 ti/6Pv/lZf5p/kP+9juvTf7idV763+sX8k5ZmMG2ZTlems66urCmLvu8q+qir4cqe/Eq/8dtXhv/ LofbV/nb/zRFmZv89uv8Jn+Q3/43f3wr0mzKk50jj2mKpmnr3MuTbcnzWX7z5EH+Vp3f/CCHIb/5 dTx7OZ79Iocm3nv5IOORL/LbDxIGsUOppjRF2w4m7xhEilLfupxSTSmz3DQ2ypOm1HdFcabKb1Dg l6M6v5aDqBodCxTcWS5a9QfO9h2+Gnv4RRqTCbvT374JyxKswLRV0VbDMFPQHSvIDq0gdcIWAZRt WqVpGzHLtjomz2iVmbdKsYLvxskA98yQzFe64rIT6cN0bVF23aac2Yw9ztCbzOW23rq+6Fp7qt4A +I8j/L4ftSiHC+qtH4qmKieGGC1SA+5NKm6oiqoUtg2MtSRPHiYyAg7F/RQVl66x6KiyNEclyipM Z65GY1Vpi77p5pyqZ/CuxsyoqnI8RPZM58u/gmc/kN77/Oa30RXiNJGlUgJO4ibO7A6XX/V1Yapq rslNl58cgnjyzXaGRGVbVK1tl2xhbpupIdGCMzhGajFEa4e2GDqJ1bZCtNE2T9PPzpCx7bui7fqE 4EZ80yLUYdx4z4P7Q0GgCzu4SVCAU+PR1yOCcXFECpz95hCc3fAIL3x+I1clqNBU7x+NsYyOF3nx 99FI9D3a5nXdE+6DF3QQ8/mDB1miIS0ARSLyTe9XlVUxDIKP9IlJxskOu55wK17Z9k014vb+7VpC 86LqU8x6DbePHERNBPVzdyqI/YjLT+UoCARBRGWv3E2JkSdn6SJmYBJucqrzmC9HCAJvmsM6NHl/ jADvu6MI9IzjJxyfji2FwB4BwegU9zjBaP8P3uRRgn9/MwvGxL0wBi0Z4iI897BC7v0wSvWNdCXJ G63xwrfjRfTCPQyOizzJvR/Hxk6KemMskpg0W8mnus7WOUhKYMA3Y2jNIAQg4W9SzozC9AF0Agnm CQCGCdZ654xHF7mQefb3spA58h70jhT0+59x1gUtiWy5g55M0xetkbCj1Vori7IcpFDiaiW3L1bi OQohv78sfNbun7xIPcQIV9muM3Mpt+ohyVg7Jzhqm7LoypL6jFbTvQRHtSnqsltk9dUwvB1xJpPo KK9WZ1adaSt5LiRzEKLoMCKymqczzWq30qgpY23D4zy70SGDNgUIXptJIPDgh565ZoXvKcMEfwTb pov32LUjfs13Gi1VszV2K8acaJuCslPLClXdFk1ZdXm7Mav3gjJbFcbU1xOCV1XRVylF2+RQZkS2 CmWiUwbawREcCWV8oRX84qThd85oDpjyJPAPffg3slDaWmxNG5z2QJwB2sVgHpkwQrrXbR6GPTGH eOVIQGgjfUxIoc19HGgWIkE9Qj0YDFE3o7unvC10kW6dJ4c/tpRycpW3yeBL9kg7/PiUZhgrNbXh nOgHXAJIoPCrzLNM82IkGog4EHA4fwSRvheJ2XsYAinmWCYpMeCdNzt2FzMMAKGhs8barvLDyEJS /PU4QobNizwDArVmdNv0Gz2dVxcXaZOhIihtSjbsc/JCDqJgOuTwxF3MwooOF5FicSpeyAsyNMxB 2z1+EWHOzA22S/fWmqKqpJLaKjjqAGkWkCSbx46iwGQekrRUtq0TkpU1X4FumQzSNpTKfHPvEqh5 qGCiZYFSYe3AzJyCGsCnrY5mgrdhMERMfkwxDGJoE4gOQEtPKOEvchc0ii7pXiR1zJ4dzzZ2gKXq BllN7oTaTwILStRKQOvx3iErTFOxz0ulrOlZUxW1ZOpxLCtlU7WmJ0pOWtle1O02MURDbIa6GOrl svKMGNYMMRD3Fh/C0dRD0nMAPW9k4jFk8TEdUFzDp4+KMBNNBDTzp1jyVB9D0AkTzikiL6Su79E9 gjJALmpa0F6AF3hy0Y7fJbF7JhK6hGrueGf+fLFagrDQI51qI0ZK1IEkkIe40USj2BEs2aqTdT7Z PqJBeP812aZvCikpLCZWs0RvzShCqRJYonhiBSb9hcyvBAlcZBoAIGdAjteZTB3wRFB7TqM/3tMT vQgyLRk9EKIEwCUCEJl1p8H9RSD6MJNekVZjjicXXGN2M9XinF3+7kw3lq1DBId2wwzo+Czat+eO RYkRSscQd9R0YBbZX7sLytqm6IzUGwIME4Kk5KBth5lOvkL2V9jmHKvYDot94D2VzA8imohxHvHT rs1gIqyDNEZHhSAKfNHmQxXI6WkGCRHQhxa2HV0JYW8m4/NcYt6THyfoxPuQ0YTgMNpT2EHm1LVo OsEQ6EMPEWPxuszCOssR/3wA/a0NgDugZo3s65NdH3mTDLVk5C9EScmL3U3bFWUbFg0306c1hxDn 65D/NIQjML1bKJJd78LIjq3OmrKTfZtlm4eRXQ3HNF0xtIuF85nnfTMTX8u6TBcWsXZN/CMXvR1Z no31hu/G4kcw8iM1TQ8liAizhjPk7IvsYjtKZbWlsV2fN2gnATxiFvCPdvbwz8co6f1ZyPuJuy6h 71M5iqcPAQlvoR6siIYJCtCk5nze0xSI2XEPBRJoIPP347RoBvWJQ5w52kQIGgvzeDjmWD7WbzCI NQkvybm26Bo7zWbCgu1ptrdzx1NjZbWxT1rUWyNdXfsgw9GJzh8gjrldDCMWMyuAEqbYoyiWZ8AU k0oA8fdTGP3UVSojxNmZ0uYnqO20adQbs9J9pxToyz5pLfQceY55vCmKrWSteKgvtlOMqf/fyFgY OWb9PnQGH4Arbo51lCyS3DMeDqQXHEly2h+DTIRwCVIij8xCipQSl5GkWSpJkrag4KspcUlQKeu3 K+Ic7lp/M/iTjXFVmfRtyxqtaSdDsv4hcNmNvyfSwLTIAWY0kcGnUN9UD0tE1Y6MwNFa1crXIjKD Xm3X4p3k66RiMOGTIB0Z3kekWvfy7ZUsqSTAPBVWPgn9yMFKwlfmHFh8K15T4rFZmANYeEYnN4sV KR+rZaFtHDPZJ43RhfbkOljiSdYz6UiX2gKHJnPqYXmI3uhmircvh/rKfU83lEOuZ/X+K6O1c6M2 qTJ6DpkmBxe1fJtUSux6fBP6GuiDVwVnASjhcgCMv53dPIdkYeAjhZIDE7l1Lx7utfIAA/Ea6o+x uAlorrQDCHXS4bEeyza8MNGy658YA5tEYIxZB8R/KpumFQaqZeF1HTLHKpmnja19CtqWtRD0p2pW MY5JX42YxS/+81G3YV1KtdPnpv5bvPgpqpUPLIyVz9xSMJWb7JRvT9fESfkWtm4krrL9OfEq+Ipo 89hTiUv8IhWc6MkMK3wycZfjPCNh41CbNg8DTvD0YtQARnsExGcw8RH/JadGLVVVrB+Y84KuHWiV UKbmBTSLcYaFiPR8b0dgVJWSxjRdc4q6TqPknWl7Ldsl23oxDrmXuMh2smhxVgUPOIARDsFBAJK4 FOVtCzSCPxAHgLbw9yHuxRtsLBSBUSIavQSmcf9E3hdfASojzx7KFMweDtciMlJ5/3J2XrnSc99L bKNm5gpim6qXIn9Svek0Q9pZOKmN+344qXCyFtwsIheQhMAe5LbK+8/QDcgBG+4EPMvhcmAxgpGh ly3OWhlXAJZyKCQYXow874XmxB2YPqXIsQcrEApkwbZe0ADLwCc6+IQrQVyIrbnqW4vBKxdD4AfZ QZa0upzTBaw+o5JLSwHfCKaxqwekXbvvJSal+h4a0NLpR7CO2INfNKZ3Hb3D5Lyg32MQWuqfRhvF qrkXJ8WvkIilXs4arfyDyDBINaBeR9t9gN8OpfzhTNhsrWsxs01s5zB3conZ9lJxHM7a3Tpnbo+i 54fhQfxSeBFb7/Ao7ZD3eVAuLFIkQuZOGuPrwpufAcvf+cgO5CoPKknI1N/MFHVVYUvbJixdJsuz I4qPqxK2tUVpQmFl07+dROB8ZAsMiCQ1q0KQ5DAQD2z0s8BIigjAhzVVIgb9nqYvSInG6B1PwcWw u3Gi73Gpl9szAEc69QHuvDNvHenp1h0c+/rAJo4rI/8t48q9YaKuBjiNLN+aq4lDrKtcGvn3r/0V OQCgD38TILax4JwGoY8dB0rpehHLGkJsxZSLe6nwOIRMIx+Fuv1zQUdXAyHZcGirq8nYRRSp6Z6V sWvscLYHQk9H/hPCTMTFDh9gKiP7HCrBhRr4MR8Am4JjCBdmD0k+eL7M9xmmtq6yIpSI3FeDZ+Hq rg6J/KYek327dxk7K2LWVTzq5UR+Fi6v+fYkQHsvGJKsFbc6y4p0PkMv75BI4ba16yXa5J4EDRc0 DPdfCO7bFK3A+5/QaugLI5vflpzcbEJPA9jOSlHVyx9uysrFfp/LdGqYBShBMaS5rOzANICDWFCz kMYPbQcAehzFD40hMxpl7wxvhNUHmgOA3Aww/2pMjSX9dfEqz2jBdZq+2Nq/XMQgeyCoNzCqOHAf e9Lxe+5R2Zmo7YFA+adRDFkIuOQ/LMnWiLaXAIfpvxb6dd/tNW3Ixq/AWjtJQbuknRpr9BtQxtw/ Z+4Dln2UED+AnvlgsEB6BSQPHLTDq6bYS//FEhJp5JLUITx2hLR+2HE5AmExWW1HYVzbfODXI9Al T+pVDcxIZ5HaV0XRvNfTJqp7j09680Vekf5yjkuCV6n/WLFMBb0rMIVW1lj75U1CM8e1ZgpoExWv FGbHv+145MxE8q9nmMvMepgJPdfarXwzsjov3rp2DvdQeK7XhsWjSHloV/EfwnQRNgE5PFJEyGRH /mp6Z32hH/our5iiq2FzyVplKxKxzhVAuHa2JdsEFoKdGYTfTOxlbSHx4GIseB+150r+Or0sr6au WRn5dzoTkvlN+AjjfOosXMo8mgUgfmwat/VQqEGWurW9a4cBR0EQYr4HL/BePBw2Fi+uv/DYCSrU RqSKR/ViR55BXtiDRmcxNfzJo8F7xoWhw4V7GrDSs0QM5Xh4qAZVqXvT3+W6F9glfGdsiV5wRmkp G8Ir+UxoaAebawzcWZ45/M+DNa9zR+yVqYxB2GejYj6Sg5snoED9G3XT6DBqjcMXl2R5l8gKd7VR Jaey/P8BwsZd0AplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjM4NTkKZW5kb2JqCjU5IDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNjIgMCBSIC9Db250ZW50 cyA2MCAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjYyIDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjY0IDAgb2JqCjw8IC9MZW5ndGggNjUgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdWdSZPcthXH7/wUPLaqZJoE99wUy3bkkj2K PCkfbB9seYkdS14UO8unzyP4A5qPDXJA9rTUqTmwuAB4wPv/3way59f0r+mvaZdVfVpUVdaUadWX WdOlTdllXZf+9m36Wfoqffe910X64nWa27/XL6RNnhV92eT5eOl41lZZWVR5l7amyrqqN8mLl+mf b9OqsG053L5M3/2gyPK0SG+/Sw/pg/T2x/T9W5FmVZ7kHHmKOqvrpkqtPMmaPJ+nhycP0neq9PBK Dn16+Od49u149pscan/v2wcJj3yZ3n4UMYkdi1rkRdY0fZG2TCJmUd+53KIWuWi5rksvT9yiPpaF K0x6YAG/GpfzOznIUrPGAoXhLJVVtQfO9h2+GUf4TToThZ2Mt09hSQQLisZkjen72QKdsCCZsiBW YUEAJausLJpaaNmYu+QZWZlYVgoLfhiVAe7RkOgrfuGSjeajaJssb9tVOZOZ9Thj3USX6+vWdlnb lFvXDYD/PMLvp3EV5XDBdev6rDb50UKMjNSAe5ML15vM5GJtncUKyZM6RXrAsXC/+IWLXzHvqJI4 RyWLlRVtcTUrZvIy6+p2blO1Bk9XrBiXKh8P3nrG28v7sLMfyehdevh9dIU4TWQxSsCjuJGa3eHy TVdlhTHzlVx1+dEhiDW+yc6QKG8y05RNiAtzbsaGRAFncJdR8yFa0zdZ30qsthaijdzctj47Q8am a7Om7SKCG/FNIKkZ4ZXJQeKFWp3pIOIDuVfkPgz4fXwU46yjj4+HR6U7IgYL6MSdfT82xCm+5FFO jwHj5fBdNFWW51Wdsl4h9b0VOImzLLvahOSZGa43A6emz0zXxMEpaDlPIGND/SBkHA6mkPEACkEm OZxAZhLxEnm9FnSJYUU4+ubsxXiP4JYG4JgzHqEdcuvmxCij+MkBz8tV0LwmKDRCUJ78ZnQEjESA T5+4eO4hrw6Y6PPrkWg/jakAXTPQ38d79MlBTx7hWfuHY/SV3J1kBiyqpK6rYWJpCkG++G5J0iIh F82AHQ7waODrPut7CV+jcl5Uog9/jAvN6qOnH0aVoNgg2LQuNJ4YgYvfjZ1pQKBfhuUecKYdsnDg yRfSmRCG0WnnuElDskLdtxfmGDklBy5CCr0GkCpqntZssFoR82Q8TQoG+lkmKBUJvRTC7Eh3MwN3 TC5rhtSikly2UWg6CUxVLit0i6rozOQZK0zruazpi6ztJXC/Q55pLhvNtqA86+SfsC3PWnHMZzgc bXD/OTLjX0LBoWyicf8PuXp0DRrTGEmIaS1g4mpZopmJn9Huil6AKM3nPmjqA7mHZLTTbgo5Ic9/ RnPCk7CV5o6mm32QbZ8cNMHmS2lnHbOUv4wM02wP+jAnsF5EqCntB05eyuH0EgJ2AyejMRfNgbM8 TlVkVd6S4qymXBLDAwN9cKsKKtAjLsdbQVuX9e7IKlc7/EzhnCEeycWiSNzAz4dTYdYzezk9PJWj GFceBv9OHmAptnbgD/B4KWAZMgVOEQEpwUWEi/jUCpAc/jIcRaAbjn/jiGCPOUVA+kciDpDBIZ1H gy4F3848IT9nfjEt3emFmRyd8zavk2zYRyiLPGuKvE0bhSjtdd5KllOarCiqmKR5CeHamATUlx6c +oC910YAn9zTncIMh12LlMSFRahYEwwV0xA8I5sGMjse2lloYtIZMtF8IeO2BSglqN9boWEofQpS LjngkP60NyAaAxBx+MnyFpeUcCQgamSPLAIJaZFs2eE6K/4wJuvM1Wy4NYUsk+nPST5AKGji8LE2 uQ45PAt+dZzBvUAu46OGqfU80o8hwaF+Zs5Ji+Mjb62X0AaT3vRFmMY9Gzz4UlMwuebJLw7iDGRX i/aZnIkfgiqcUQBjTVgFOkWKubmfGhgeYfZfj3ERi8CwwrdtPsDtJUdlHlKfNG1ZpRpK2gdIZUll HrI8l8o8jpG+7H+a0u0ln8gzzTyWfABa1IcFnNrdS2ypxqCD28NR+/SG9vXhiweiquRiO9Sl7FD3 Q02SpYlIgt5IQFr3VdZXrua+GpBGy2ON9M49gLqrMwnag+HDLJxZgg4o0dD5hNAQdru4lBoabMUQ 0JJ+ABYXtVkYjasvVeJdeRS7wBkRJhdJgnTyRz5LA13C0MGBji1eydwkLEdeJMS26QnSNXIya5r7 dlPL7NfSWm89Ixdt37C07vzRcF6khw+5Pl8AGzHrOOoowjZruS1i7gajZNINENsGeb2tE73NVMue flkHET/bFlhCPCusD9ogorrvRyelI0aNJp7UWCY04B5GluBbmm/TmvNxPphceV+qqGTb15giZZWu xm42bZY3bjPnCuxm3WZ9E7N1ugQiT3XLf7D0/2c2Sb6DKNbGUJs/Jsx2EfeOtarBwBIL6jBZkwfS sZZ0RtcuGEFCemMILvIotpiLVhhflFmLVhFbHolk5I5alt3MafsqraMh92bMaNXJ7rjbzLm/oBMF oy6vbusQFzyvZZAGogYNagakuGrt8FGz9pMYZWIJUIYQXs6pZBh6xnuOR36Gh34qR8H1EzlIbkQ/ jGEh6DMt7mk+0O7xJdFmRKtlbrq0Vuq9AoNb9rKnmfO+rIbbLFB9M/Av8yzvXGVZyxMZRsR5AAnu BCxku0eDM+TawIx+7g6cyc59WepIi0jzdVIOsmnz6l50UddZX1QSBq4v2DRpPrpMnV5CBx0VMYkp cf17AzyJLeERGgRL0JpwvDdALjAdwa+9czJB/4dbsQ0T584wETok1H2LaYlUyA5/Iq+gyIvwq+p4 K3wysnPUR9Wxz+H3Xa9O+JpKXRRZncdUL49oBVkc5vS2fuITXILPix29rWeIpfe8dO6KjrTXuYT3 etbrgDtPLJsdEqjdSazUvZCzQCw7xWhK+AgvQInEvZXPlHwcYCeBvLqqGgjiBppamcRnqo0sd/5o uH6aO0NHNMhBygWRrDwxkzbzWjWTpZE34vs2jYddNAt22IgjC/Lhvemoonm0POeUq+QDHvEm4Urn zGrF0tIC6oSW4zaqTmBAhaa39rrajltv4qtVeCEdmWpcOx5rIvokZ1rJcY8G+TG7iT3gYDtPXGn+ aDL2gvvuGMBI7NY2bSVfcy2r720UzqtOvi6TItW1vCJaDcQr88hXjrW70bD09+7V64AgMEOwhHkk ZQHQ2gU5lwAFKLzqHDyqYGvJqvumM+1tPWWsW4WVTgrYxdUpA+f51/SeT9j0SEybJfm3+BPJ8HRl mXnSjnmiILdt9njRQYklGh3UXn5655McP4u034z5TybLIbfK5aNLh79VPtiPJG15ZP/GVuQrbJV8 J5aX59DB88Aih2hAQ03bbPRJMGF3qeK+o9zhZgvZkpYCCrMMLfrMp23zsTvr49WQsZXyte2VfIZR VU3WVOe8N68ZCwhOXP6WSNxzMVn9QHhHIFgY+ehk+LZ2z7TX7bMNH+Lss2WLtltkLNSp4NWC9YNs gV5OrJ/dTF62fsHwfIG/dn67+TvVVew3exI+GCnLOl2FGPNWGFy2ssMVVZo9x6JE59KV6WTz5qw3 ke+fwv6t4zOSacCGcJSLCAVgiC5L69DlR3H6pd9IJjjylJrSlc6IXDiLZ40NAmmsRdA9UhVgBtzT GY4uROqKHCZCWyGE9aHftLQlb7Xd5489DEl0JQY03QC4aALs8O8+ja6K4bttVyxeLaYvpa0soz6c uXumlf94eJFNXvZ9IqiUivMNESkjuuD5qMfhIR3CH9NOi91p+dPXekDMu+MgwRQC/Pjm019L0CTh EUTUbNT3gOarcT8eJwjOCQD1sHDaU9vG9QzEuunOuKfXZ7Z4NJSRfABx778wIj93IoG95AwbQBdN grNqN3mfSYIRjCtnXnITCeYYstjDaKENCoyAQAf8YAFNgRrUTqi4Zqc1JMCQvsiZ/nAwaFw1gjVK 6cUTwE6Ti0gNG3lEy6ItNfe8q7IOwuWi+qZ/xlqFTwerIPkoV+mV8e3A/jM1JoOIwe+jG+lN0uUh yxr2s7IZL5J7dQ7CC/lEq0srcHgtr7ZUueTlXfAz5RktttF0Z/pX9rn81JIr+a5ubJ4jz53BYyM/ j1SbOnXyRKjrxGw8Gb2MdgW8RqXp8XzAtTi/94ej4Ps9zm84fjwcxeG5o3vuE5ymi8XcdXeuCerN iuWStkN858Uj3NOSY9QwHVgzYjae9LOyjKbWjEGgHSJxpkcIBoCvZY4nH7FiAJCTgxaegfxWk+U6 b8Rx7xgx2JtIzwEJ9U4p9zAVl/qcrct6eQFuC/aiuXBOHFl2sinZu+2PXXGkAzR6x2XwDQ1qRDmk 2Vq3tEPT2veiafAyUzHa1Ht2eoOFFtM0wu+erLvpIJ8spDwkbRSp0Q6WGI+56JB2gXKWXXSmEbn9 F9eiPj0YvnWu6j7VCDixztO3KKIROa18+J/VW//o2Wc2ZWukdHw9OyilfAyVF7E7KGtBiViYsURg dQ00nw1uQNwDqALw2FcAJAi/XHRfSCZp6r5M3UTHmtOqKdgGhJ0fEki9KWuLmOB+mzh7o5jh5yOL qCL2SdSwTddDAEuegKXUjhlHiZWgb6CCTdSRsq6wBGyij761TQy+FPHVmPDSy3OiGQfjp3JuxbdQ B8bOJ2P+wbidRnJwN5kVkmMJdUhBd1BFzzG4acd06Jo+OWNp3fD0bTv1LoJJukqFd212jnSnL0qv iqr3m3AMv1na9hLBgsWICDaaG2dFEaW8a2KCm96zhGOJGt6p2rSNdUfD3NNboMHVD7bTIOCRYMgO 2sAnB0Z3GAA9U6L4ci+PMkR8jk8D4nWkmCNpY11z3duaYqjn9xKPLmvu9J1T1lw7J22bjsJPXid9 jJG4maU2j/B9H3KfdaAPlli/3QJrwQKSYAkDqhlec7Vk1UGijDBh6b3XjGW/rS4lshrX9mpIauSX R0u3h7Pq35dYCiFZaFaf/As7yHoH+RzUhTPAttP56xLax9Gp3j5w4HoiilZFZhtlqd5T9/U83QK0 tXTQBt/3viVriiarbDqITq4GIyJYW7l34lcxEu1YzqnwlnmbVZXb5tDJSaRnuR2Mi/wqIvjUJgOL wz4b+CKUwrDNEAQFMIW0B082vvHBA90woC4fw6AgvImSdAINVLUFRl5EQhbnqBjXtkhms9ct6FvP heY8CUV0wZkGjoA3WHF3/mg4H180soWwbCQorQhw3UMb++Jxr8xLvkdbSTG1ravUYfFauGr6Livk o5qIfG3JngNRqAEO2ALkjEcAHrjFC7P8/xXFSjWPe7htNETqod0vnenImQbwBGjPQzG7RTFDuIYo 3TAEHA4mHjzp9iieA99nwPapHCWTeSIHcSsMAmHpnSVi146VYhlo58jwcOyGMd3VU8r4d/OmG6fu 8aVdjeXQcEdQX8orZKaTyvUGfL0RX2A6yX7k6+/AS2SRruCDQbXiCkCFjyWthj0aLca454w/cOQq KtY6BQxTk+6/GqI5fAFLmlKaNjRAUJ35MJAOtHSUrCVz8LGQTObb8G6KTAr5OTDWMUK6XNhsavn6 M2/aFD1HmFkxa9Pl9r9Gq9WEp2EtaRA0VmiExYerLAH6+WOsftBcIwj1HkeYLNbaPyHZQ1JxSqbo /GJFkGIbR3cWyUwrP6XZRG31LfkkVh9deFZaY8x6eys6vl5yM9Badtoczh8N55PAg8cXnJ0tOFDU inB2aBfxUDntPBht6sEZuNOja2z5dtYQzWc+3ZZnAebmwbbT1gXKMtBIch+aMgS9LUzCdgr6MVlC AjAtKdF9v6cq/00kK9tWHA8girAA0aDewTG/I2FaIVt71h4Z2kdvPpiY7oKiDBZcKxN9aZzMDZrF CWYKtdOOYbmI46A5A/00xie++XQ7Sjefw9MSk64dA28UI5PDAiNPwDUpHS8MY+Vy3TMTCm3YZM1h pqfdo5U2OczCAbQSbM8S8Aiz9Tq6ZPYhL7r28hWfw+DVcKLJs75zu3SrhYIlQz/HL0CyGnZBOYj3 KbF9Bg2x/MHE2uLY/+BGsO7kQPQeWHVxfyjIvvcCUNHID78NP4pjWMer0Ws9/MyZ+/WuVb1G295z CkCmMvJ+QhGztbBNnr0BTinZUR+1C3iOPHe+y+T+CZ2Rf0KX5zGfskSLc5arlFfi2iK2xvzZQL3G v8iLdcXy6xD7ocTdkoZjebnHk1zEm+DJstGhcW9+mHY2v2fjHn3x/UFQiSj5GA9zZA3Q/LNy7aOd Q9S+iTOXeWGedMEPAUoZWaoQ+XjQeZ1R947/eGj0ohunqCc8P5t29rkMK6pw9pJll3jzcumOkf+b Iz+TKeZyE75YZyajF4gV/XIU+0JvfclPPBdNId4bsbda+f8BazaklAplbmRzdHJlYW0KZW5kb2Jq CjY1IDAgb2JqCjQ3NDIKZW5kb2JqCjYzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEg MCBSIC9SZXNvdXJjZXMgNjYgMCBSIC9Db250ZW50cyA2NCAwIFIgL01lZGlhQm94ClswIDAgNjEy IDc5Ml0gPj4KZW5kb2JqCjY2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2Jq CjY4IDAgb2JqCjw8IC9MZW5ndGggNjkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4Ad2dXbPdNJaG7/0rPFe9qQLH3x/cpZMGQsEkk4TpmqL7gg6hgT4BmkD3zPz6eSU/kr328fbR 3ieHPjWkin1kW9LSWu/60JIs/z3/j/zv+Vi0U161bdE3eTs1RT/mfTMW45j//Dr/Y/5D/uDR2yp/ 9TYv/b+3r1SnLKqp6ctyvrSUhrZoqrYc86Fui7Gd6uzVm/z3L/O28nX5efkmf/BRVZR5lb/8Jj/k 7+Uvv8//8FLU7NKT3Yaeqiu6rm9zT0+2R8+X+eHJe/kHbX74QT9TfvhlLr2eSz/rp4v3Xr+X8cif 85efJgziAqZWZVX0/VTlA4NIYeoHd8fUqpSUu66J9KQx9bEYV9X5AQZ+NbPzG/2I1fBYUHClXFz1 P5Qu+/l67uFnNSaBXevvMoFlCVpQ9XXR19N0xKBrWpCttSBVYJsAyna1suo7qWVf30TPrJWZ10pp wXezMMA9EpK80hmXnWk+qqEvymHYpTM7sh634Jtkuc+3YSyGvjmXbwD8xxl+VzMX9XOHfBunoqvL xULMGmkB91sybqqLupS1DRZri548CDICDsb9FBmXzrHoqLI0RyVmFdVQ3RuO1WVTjN1wbFOtBK9z rJpZVc4/0Xqm28t3YWc/Ve9jfvh1doU4TWipDYELuYmSvcDl12NbVHV9zMldl58cgnjjm10YEpV9 UfdNv6ULx7qZGhJtOIObjFoM0fqpL6ZBsdpeiDbr5nn8uTBk7Meh6IcxIbiRb9qE+kuBrSrzw7cz 6IjNeJRAA6eGqXk7Q9dGH9gfa7+/m0OSV3OF/5l7oGka+3W+iMHHbdIDT1L9R6MqPAJlliRbHZIY Cm2+VWNSP6imWzqiTSpANRdR1L+aofwyDzNy0AfAloOWL4yWi/9UYy7G811kIYBWF4n6voFnTRze vspOTzlqOWkFN10OfnbhnFfZOTOOU+SkzIAE5aIZu5QZ0Ck8R7R4Kfwwg4aoFiGCXEpIAcla7PAk kv1qbswCnxAZcT9Hls/cb5UfPjNAoQ/fY3aAKMBHA29cRYXx6IUFdgSv9x30DPoYDRUseKkH4QyY i9+rwyY/cBGNtf7IDjFMSZ46SgXbUH7oyhryx1z/8L3slgDeQUwtu1ePmt6dgZhkg3yBA10cRD+J sPvjr7qpmCZF4zf7q1MKZeECak7g/MlsCa0uATtQxD3UFPA/EWYEekFpBRnZr3eZZnHZmrqbmryH JwlOcxMybVl0TVk2eTd1RamJTlsX03gSNL0ihm6o1e1YlO4PVR/LsaynXFCZFHoNzmR+c3d5nL4r i6EsU/I4mwM+mee6MKjr26poyyFFSc4CJcY2WkLv4q21FphXCDsjkZeUwii97g/53gA1H1mnMDTA 48iEiYH3XwQoNroidPIjyw6oEN4E/eQRdBdnAivgD4oYQxk/qwnuh0apQWtURHWtp1xrd3RtEHPs kv3IrGejB1qJFIY8oTMOqnCZ6OYc7H62p+6rYmiUxN2B5tFM8jxVuTS+b+qiqtqUAD+ZnpOW6nS8 uLi3ui7GetOdHE3HztLcEEv8RX5AyePv5UYUkwBC4GPR+4/5SR4BaB+50ENzGfDuEZ4dNuujGSgB 9f90UANKewZyHrn2FOLM0VzmOOyQSN+AlWCePiEIdP/pvWTQXiCVuhyKtp/kWpKlkgySjSg+fZJc Ncqsia6bg47b0OMnOTsx4gJa5d7rpm8THP4p1D50SFBwCwKeC6ALMI7DfMxXsKUYb3ACQMJN5tvg EIyDLIv4TcR+7ugSJL/wSM0OL6DzpfuVJkCvhSqU0GCYfvJoNNbe9kIXLoqB4TJAvHUOVIhexSvM 5gQZFbEaDK+g13qFmWXR4cEd6vMojdphQ5M8pHEg2buMLpt6Ktq2z/t0rCVj/wLTELHfTW0xtSGB tpvQO4X9gKlPPMaCdczAXAR/mAfCeySBQJES4AJHcZLqoUa9AEebTUHY9iIyp6J/JFvyWN6TcA8E gHhCJYu8oJCgmgQR/dox7eq3zXL5R7MD6mDJgHxLxuZA6f4xVueJBCGdD16Ku5apXLzWXNSAbHfZ eMP832Rum7pzq9eTpkUz5BLM7W+jAmNXaApEzvYiFcAeAZwYe3jcIkY4jRSscaNeFOMcVQT5zYqT HR5iuz9Gz6xcrWWzSLIofSWYKLcJ2AOurReCTMal1iIu3vk0VGtaRaXJspGCXaO5HjraEQWbANUW 1MdI90KxSmUdHkaIsXOPVuASvLsSJ6VodEs9q+A8aU1RoHdtrrKwXL++6Bf2E1m/VsnEBbumLhUg dv05zE9WyTU97HRJjhA7rVk3XcoqyimnZDFgxW2V42sJUXMK+wjahCwQIqYfRFiljWlS3xiIoCOw A6Csou7RCbygjOo2G3A8FO/U7FCg5ZsZq9DCiKjOiCxyEyijaUZEBduDJZcnYSTK9NMsAKspNMZQ xOtELbggFmpKbczq2nwHdEcG6LfRgX4oyr5LmSWdUgKsjoUvnLUQ/essA2QXfALcpwatURFrZ9Hs MRqXqKyGUMEiz0KHHkC6XWuACCq8P4c4VrNAs+2Wet9uaflTPOlH7neZDVlY08da06Kt5t4JWHtl 3Ie1txZFMrqv2dRiKrtxrFsljTXDaKtqzOJf+/tw6kkrw+U45N0Ozo5wv+DsoeOY5rvwmh8YZxEW Be7HimyxOJuGh0fg7XNk9IweP9PvFFMt9BgAa4MY4BtuUkSQEGnX7GgukhzmCBvGJzHLf11Ai6ic gJwYuqYdJYauGKq8UpQsre9ZBajKzlm0b+YcpasQlgvc801dj2a5oJymaqwdSs5dLriJzoTcX9cN xdT3KWH9i0s3Ut6CzKnop9YxOplMwf0T0BcsxReUPQrD2mZE4ya4AVOI+YA1fpGbGD62aEaTteHN 6SJJ77zCAXe6pT/1vgHpk+s4+Q9Z3K98uQS0u1mBfn2eAKB7jyVh2htk9BgZPXS/qwXnJyorWg+3 aRmGYsKRAHaEe5LOedwKu7tli6/ZZ6v+p9WqHrSZTnmZs+AKm64J2407ctLPWewsg3sMG5BgnLGJ dnaDy8rsBvNtm5jgtBamuGWYOTmlkfdFX2leXrf6o9XOR78yOrRTl2Dh9Mi5O2XddGiqysjzrfz0 kUfcjAQT2eCXDNcWXePVqvHR8u+gzQIX2HPvMNT4aYAtKcB21B6xsAdgN/+xOdyTZuPC5d+umbTJ JyxH35QJALr2J6g+V+9FDOF0UH7Pm6TTbsXb7G0ThT7yg5IeuZV1kB3jcHwNivxusvNwFrNpJwrc W3zNyvwQb0EnP1TH/MTIzLs/lvwYtZ5cmeJ3vAOkaZSJGpouDwhMCWU02Dt/0UbbSQqF6myI2NXQ JURHClYYMdDwrpCZNxeRAmihxD37CNEHTc9+NzvExVm/YYz6SBiZAsGYIA3xtQPIR043/OLsOm7Z rA+yCG2i6/Zjsmu0WWzWLbW6tVuItgPaHDMjoBeyply0HGDkCfkTGMDrM4aB+UUMdNpw5IVP2uPz 9hj45GA7KWAGffdGG+Smh0mRfNJrZ/DY/jxyWNPCPUBCmqy12igIiYECcLwHufwwt56xLcDvTHEJ 9yMEgjlIAI+QSeBJiU2qx8SulQe6eIR6MSfpn4wD8eq12VHwO09hTygHdxpWHt7XfR9R+lASYuGQ 1Yzgngg3eRRq1zScsw0D7tMmY47JWU+TqFj5iTP2cS0T7dORU+Pe5OyUntbrQR6J90YzqqrotONw Y1/FUdx6yk1gybByCAhxIby/KZMmNFvryJNgDGhzEWAgJ0qxBy8u7tl66u88GS6T1Juj36rTGy1t JRlewDM7IhDPiH4n3dDeJGshcB6bmgLPaMVqSOSS17fIOq/B1COcQxmQH/zEqFha6IH+/mHyolRA 4PRAdUvL2dKkTehUY4myvSShXw/FOI3VGbI9b2JjHWn6qlbp3uBL2vd0Sj8Jhyz3URsLCN4cs3EO Ql8b3vywO6/waImx3RKFuyUzmnmKt0iK/7y63xD/eXcF2E/Hf3F6Az6jU/K6YjVgzzxtbj6yHIq6 4ilDEU7oyto4ql4iyq/lSJwFu2FL6jQWXVUqgZ8Oq9vAXBSl5RN0QoHSKLfaTneUskdEcBycgwyk /2AOSTb1g0ewQPbVdRoDbTxi4UJ1LlrbD2XcIwbhEVBj4WJpAaX8sBLNUHjyeK3UQ5AKFoJ0RLeF DPuS9YPAl05VNccKYRntcBfPsKFyWYiUGZplCRWoziO0uQQUaIL2Fb37nUW1lk6UJzsDecmacIH/ iZm1dtTJH9pZeouZCoiEt3+T/HzstZ4iw2mLZC5SHa/LI8fS8yaLHrgHlj4814CdFYK12nflXmi3 bNpN+CWLbcOgJvvp1glQuwK24uh/xSZ/bdFRYjhlj/+psMHqOYscwRgsIdnKqVszZ00Z2PLTy2gZ LPwsxCwKwRatPCZ6eCp7tfe6II9bmNqLlG6/bWbltN9xirFuG21smmSqzpHp5qBhMdkKcheYYoRh A0PrH2DWIrY7HLQ2fLbDIEVPHnSynt/KPHddMTU6k+nyRBJctD8vHJS18AjDN/xpzDxZZzlIFxRX F/qR6+5m43s32b2qHt2JDlXewoT7ksPQJnm32Ldle49yGMkYuZUvaAYpbFgcs77pyBekGl8v3FPG 1wdtCcYXi4xhB2nW6tq0ITYYpJ5IDXr48cix0V6nDRejPedRQ/mhM+bzkvvKnOyl3y7Q37pyIqmG vDWy2V0WOQ8rFy5cttKpUi943BvsVu6opbBsdBF2g0DBxD4wPXYXh7KKJnBg1tp9Nls7fv7dQUcp ed9TdggzQGrapRWbhuARJkO2DyZ7qAlzKZBtKSWPxkDtPfwoJ4zQ0RGFtlE6tMTQjK8f46bQDB2j 1/RPDX7QcvqnhJZb9eaRtGGvNPUdRztN3RfDUCnaAYn3xsnoTWxF+bfx/MRdltOkA+A7jp8SoLU2 2uKMCjxJBs8iAkRZtD5Hd55hflGpQsWQAoh71J7MFy1eIGOPNvBps2Wb9RgFakmboNWinKCVR2gM jlKd/IHV+EjLOtXHrMYyHXYxWiss2qQxcpIQoW0KK7XYc2AbwcVNmbKmKt3Ed8xbYHh/1EKnjmr/ 6OXrR0gNzAbbBlMRBvu6kboVDfW5SL3NdHHUP38QJfDaN5Q+ugEfFo9zPiy+HEi/PMr8WDhJh8S5 W88qnRs21Fq6a8szRGDxbL2bHSDMZig4MiqgB8gMdVjydis3DnsREmKxXpFuaWxtgeJ6wUOslOCQ yNBLgkRlx0u3lyedoefFiBeuATVTqVOAb7UGBDqDcqEI1kKGm7d8ffwFovrE/dZZfKX0C18+9Wov +IAifvCCQdOAGYjiJnjmHphlfAALnYQHvNREdMhFzIx1kdDEPXrgYrRWmrbLX9pmKJ1prfxb6Ino vsSDlF1R69zDPMDpvniQZtQOhCn1SGjEYH+iYffbtRA7gqYETigh003DfgJffqaCk9lMf+5ZVosP ++aUJR5Y0xEl6KSEdsAChml7D7rMM2HtBrqh5pqv+qCNbymdPUIYGzucM7NoC5rATWt2eAT6EQyt eS3LXHLrDvXCvWPeKzUQcHhv9GKoi6ZMWgk6zw1dmKpo+qYo3d76y0O9J/IBspYIGYxbBWVuCios 1B/jQrhJfUqAK7gffzMLh5wTtoB4KnLRWgagqlWsOA9yO3O2Xn+3kH8Occ/cr/JZn+l32fCAys16 mYVDQq0mBKWlXcslO2aaI47iSatloTUqbmZDjqiiCHtgKKVNg0CP1PtfjXheabxDbW0avX6u/FRA 473R1q5xC8q3UA6sO+7nBPfXGVXQjIABAYEJIlEpURYXxMuV9kzVTTXlSnanj90C2eoQY+AiY4i7 1fzYmWTALHTXOhbqAU6LZu5hZahnG4ODEGF7oDEqUP0vsg7SdC5iVaw4TkhzbSGCaaDfoL6WNqvF dMVAYSzsIop/XzoZ8jnrMDURFcSZ5yzRNx4VCufSUXGe+7p0FuW+rFKFlbuLMtvJYVSuA+JO75AA DIgNAQd5W4XwN08EZSAzEGVRb5uJiSofxAKUvTRZkmnxqL9cnT34ozr7xhgSnIFPgTP0ZFUANYOJ Xj1j2nLJR5yH9vAqpnbTuY+M7O5gc288lDpwoUlH123QfhM5cRtR07hXvVNerD61BAkE4CwGE8mA tU1LCfK4hwyRXTSKXtpWD2gzSJtZERGSFTpte7TERREq8LNJBa4VlB0pXsKL1Ela4WFtjwiwyrjv 5KxW+JJ98weOWHXHLxV36e5dCrpyaSiwlRDq3AbqyVuv3IpR2SQtt9+GnnTVq5SXbcv/z0dDPvRz nOzwX/43ZmnRPatf0ff4QMSajGgdvD1AMbgIwKPJ8KrARauINiiz2hLNl69O01RImtKs92ZTnTaX QD3RvVwQYjfuoLNWHxTSlxU8qGal2923IIN+bYB3SKHfWdFoEpBO4XlqeGm6wp1k227vZDjaFXSD Czx2Xmsksv+aR+D75fZ+HQWBtn+Zvdd2/EJfFtRU23ByF3u/iWRrrdPoXayUufZ59Fw4s6hHvdun r7pt5MWub/fi00u9LOeybW8wJQTPz2fzPSyffffKhhIEZzZ6fuxMtPbIgMk1Qs95f3JTB6Dwc7d3 UZNMa2shmA65h2uwtl0z1mif3vkRorUC9K7shxwp3Zd8UT3oU3HuoO2bN5KeB+ILzWU9lEU9hFUY Oz1ONJe/d1BT5tMG65vzCFABHAAXwOUe4Dqa3nLTu+440aMiECfgoGS7wJjSNqC0+1NsPZ60IQ15 F2g5BvN6brMZEVGP3i1/IJARvS/NWrI3z1HlZ/AZywCJRFa0yijWtiC+/BaHvU4N2cCM2MYOTW2i p3fyQo6O76z03ZIAxHujqL1O+BmTlmFOxRHWeEb18LL9nYSpd3/jWzreLSA9oScaxv03oC4ILSt9 xFbZiymv0wd4+CDx5BKfNzzPEukcQoUb+paNpecmSwRv0RsAa00ALEZPQoLBvv3AXMBKitZQolBx rVOE2jEJYXURMaLvlNB3Lh7bF2889u3LeiYDvSgvO7S5aE8fIVSg94hBbwLQduoxajgKLcyqGINd HWMosHBh2t1ht6n1NYhe312yWLkHoWmnT0RPSWuk53n1S0NTfUeq04u1CbHpbehJzo3UWr5T+J7y XloyPRfYvpgmrfV5dDfF2Qjdrwc9f3R+t1+vorgQ3mo3gcL7enRx3Jgaq/JoG2pWmApYhRM/65hg 85E/OEIViP23fkUhQQiKCYVek7PVmROJ2npq55G2gS+fn/ff5o6fptf3fZXE0Al8O9yOE6X5y5Dy pEcTFwwXBijY4iXF7wbK0OBJMy/LlTMTrETq+SL3ls/hulY2WUp2+MS9tbD3HvlS3QoWz9yESfIB AnHFbm3ZLU2U/nyXAYHP77qNMDtiOlKKTR3dP8rwy1wH1iqsKbOv53WWRy8EnL0jL188unYi4QcL 1PwHVwa9NN1VLmKsa/dZPAFu0n+5ypXO3Ol1WqEyGVV+lb/wcdRS3SF1p7Wqm3ztztV+kw/6v2vM F+fGkg45dacyVHp1uVWWoFe4pTcbazV37dKVLuk9Yvddvd4fOas/3DV3CKpWLkPVzF07au0q/1YH +H4pxuZfJ/JLVi8blNvxo+m1YKQvbTieXb925UZe6NOuy9h7fahQF0Ktq42WHEmO307glVtG6/R5 dH2i0A1NE/I3R+UrfeVDnWjZOOMJfVlRb23pYONeLxzqOyA6eWe5otfky1bvTW1cu/ZUdu2KqScn 0LgPMDsKQo/6/JXOVdYJ79CkD2LplGwt9WVhFJTVUtvpkJZaWZbwjFpqW30lc3DgC8/pIGGlrdxo aDtbXYECtbU8xbWEK9m6njZjeM44GkKPgX8LVbMMFsrn8qvs+MpN5Vced3X+z0TQOSUVwEvJVCun s1rZ8pXuuwOWJO74TFPqtVP3kU3lwpVq9iUlLJySa+ymvFviWX1uLhgEX3dUWKL+stjx6L6/OYkC T1os6ext9w2yWL5SeZQ6axN+vCYLVOWhwblQe3OkfKUzT7oZynslnu3DKF1Xqht5EDuOPPKkxRKk xrK5m5mS6JoVdd8OS4EXQLU6t9vZinBFKnsb2K1UyAPxRhgeG5PFeIhF3rwEVRZlScZjHtFaacKV +Vz0VqH92MgwS59HHRxS6U3SsdWyo04ArUttgzqOQ6PZc5FROfWj0O4Do3UxtiptUJqSnHY2dLLj Zc7Pyzf5g4+qopQVdV/N/vRZ/p9fvX37+lfFO+Ec0XP6ILOy9NHIfbZTX6lH35VMH1392x31sAwm Hx5U/QMdMFPVH9ZN/uzzpUd35kvrrISbwPRSmrYXg3QCm74EqCvat1v1wzQc833m8e6uDbguddK5 wX38YEbWDJ7t/HheaM/rzIsQkipuc0GoNjoSulNy0b3OCqXEupCbKCu7o5jQhtfbwxoq7SQJw4qB 9rPXP796/dMvv351lf38nVii4bcKBtwwFVf34kSrL1e7D6+vBvPgyZsqf/yjj3Y2KugkO/9p0qYq GpaqlxqJfI8EPnpb8bGem86fWviuCXxZyRfOE68NvgshmYf7qaSay2JKCDbc9pMGHVb0VDfdoUWh /HCeC3zM5Sf6VRyuuyux/B86RqD/CmVuZHN0cmVhbQplbmRvYmoKNjkgMCBvYmoKNjQ2MAplbmRv YmoKNjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jlc291cmNlcyA3MCAw IFIgL0NvbnRlbnRzIDY4IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNzAg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgo+PiAvRm9udCA8PCAvRjEuMCA4IDAgUiAvRjMuMCAx NyAwIFIgL0YyLjEgMTYgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgMjYgMCBSCj4+ID4+CmVuZG9i ago3MiAwIG9iago8PCAvTGVuZ3RoIDczIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAHNnVu33MQRhd/1K/R4WMsI3aXJW7glJgYc2yxWVsJD4gC5AAFMSPLvU2p93dKWNZqWxnM4 8CBL05fqql27qi/S+SH9ffpD2mf1KS3qOmurtD5VWdunbdVnfZ/++GX6efpd+s57r4r05as0d/+/ eml18qw4VW2ej4+mu67OqqLO+7Qr66yvT2Xy8tv03RdpXbi6XF58m77zYZHlaZG++Cq9S99KX/wj /eCFSbMpT3KNPEWTNU1bp06eZEueP6Z3j99K367Tu+/sckrvfhrvvhzvfrRLE3778q2EIl+kLz6K GMQBpRZ5kbXtqUg7BhGj1Ldvp9QiNys3TRXkiVPq+6a4okzvUOCfR3V+ZRdTNTo2KAx3qWnVXbg7 dvnr2MOP1pgZ7LX+jhksifCCoi2ztjydFgp6zQuSuRfEGmwVQMmmVxZtY27ZlpfkGb0ycV5pXvD3 0RjgHguZveIVl+ykj6Jrs7zrNuVMFuxxhd7Mltt66/qsa6u9egPg/xrh982oRbvcUG/9KWvKfGKI 0SMVcPepuFOZlbmxrWesNXlSb8gAOBT3fVBcvMZCoEriApUpKyu64sForMyrrG+6JaeqBV/XWDGq Kh8vgT3j+fJN8OxH1nuf3v17DIUETWQpRcBJ3EjLHgj5ZV9nRVkuNbkZ8qNTEEe+ycGUKG+zsq3a NV9Y+mZsSrQSDC6RWkjR2lObnTrL1bZStNE39+nnYMrY9l3Wdn1EcmOxaRXqBKxXIx5JIniosPzW ihSWYcDR1NAk5OXYjMsbkjuKEAy5e2RFpjzlL3Zn6SJF5tUH53C/vTIfMVehCIOgMYpQ729jBYqQ vHA3Sp/4ZrQGRRmvqsQPW9oZUiOXxP5PutTRUAMNoTYu/Mag/js2BonzEGkYKUL9LPqilclcA0Uk l2cFKy5gc43NuF5VZVY0ZRqPuGgHOEBYk0NaulH1JlfUHAV96QX7oHXi6bdmkQHsaJ8aGI/8m4cY XTFEHv0fM1dRJj4t5Ck9rsIVq1OSLpDt5xEmig+KeJgiIsOgKGXAiXcF4KY1kE1Hw0PSMsU8sznk Vi1+PaJVK/zpzp5Ok4u5FhM/46BDLtqotXa7SFgVNjHvbZ5mrBoLrGigXxMJbTKblb0PhHmW57Ut Jdh/yYuXZzIev1RgGra1gjy1gpep4YgzWsZ/amvTmcgo6wWLYD1FI9Cn1Ad6AaGi4K+jEwAb/ASE wI7gHI5XH+Ah3ZJ/AWx1OhBNSYSgWySDCLj8a5QM4bUxqtMYrUAuCLj0fJdmruqF8dEYHemg6eF3 A/8UIerRE43qWNABzWic+dNbo8tmNsIpdlP/uesjLEfQAM3Z5ZbO2mV9YdlYPPD2+apmZfFZYnPK TiebA1/OEidHQJtcng1KtYWfpyj3iV0tT+JXZfcfRtyRC6F/LaJhzMcK4DDPhQIDg0Zao76vqM2t Yhs3pQt1YTpUl+KOoKiuT1rKQ5SgEQdBiTi0QmjGUVCJ5rg6FPV5OgLKtEIROiL6WdORMD+SeuW2 slzlddqCq4h0PxrnR/jeL1i3TZ51FoiuSL4Uphj4pQHaMn6FArbEGODqV+YWEyEphAJ0XWPYEujR Ebbkt9XsfUnAbl00EL5zSsbgnQPRlP9pe54JJdMEx60FIK/iC9EWbc89NkxFqBiG7Rr1FRXm3K3M nhJPMWhI630CK33G9f1o2B+AWVX2WVMbuQvKNNdZpBXRqF/xwnh2r4uszjufikma8/pqEwbUi0+B vT6BzBkOcxPNJYc53Hs7YPozzuSA4JwpsDtwpEN8iju8aA7V9M4s7eJR4HOXCHCnfE4zSpc+g0AP 89EEyNGaph4MjXrAkeoe3FYR9k0ubIet2P3SxLccSLduTmmL3SPYd4rqm0xBJGI0FGWkY+YWlj3Q jbFRZJw54nAWZ6qusjgjCN9eBXw7cs/swNynKmy/szl1C3k2GcA0D3MpqCdQ3VB/pS3GNdWElIi4 uI+xDq6i2nZMVhRGpSv56IJBJ+QqY2loRcU8pCQrYkpC/AbECTjUw5nhC+IlQN9yDZWF6hqoaIxu ySfofcYaQ0oNwdBodksHK/M8q2zXws4KzA2y7WCmwaid/gMONq2ilWXWl6vzlQU+9uH16PypqGxr 7rQqz+sRlg2S1iKUmdMMOGSEvdwplj8cYlkeiELXABTTj8fWNOzALOoEIeq5aG2giuSZAxGpqG0T oumMp9FTRESKttuBuDHByA45lFXUgZFoea6BdXOqLXRH7R6d4z0AoKhYUo7LhZ4NqLIZ+wfDtUjv 3uP+U64fD1dDpr/6cp/w+5hhJaG+z7jALhLAaDz8weoa5iE2AAkBQ8eGxKEI1ZGch4FrncvoQ0qG +bSDNWkjQtCRMi8d6dxN1ceGDg9Vai2JgJ6xkYky7hKW1pHe5D3qeDYBuLQHYgnJqeqLdAtYRlBy RmUXfythpvn2GZXgeE3fWOYRtS15Duhex5gDjjuTvo57I1iHWAskfTv8CDi40HhYOzFohl1C6lNE cQDAsTFFmHVwYSGG6TrVKQlsGZOiPnjL3E1oDKmz45gyRF2wYVmdsq6zDYcdNtxHnktMbe/zTZiy c0VVE7O1HC3ONbGlabssb2M3+lZzgtNIhWbO2ZoRiebj8aFHLzBSpCkmIUEw6dCb3HmypygsCOKA GkB/aj0OcYKnNEdFthLANr+BX0PlPopLdhxGLU55VtdNl6q+N+dc0fZfyXWiV12apstObcyiyzXi XIoAk3fUvR28qGLO6p5j3GcDAGSJ38VY4KEBFCbit2kyO4R2AKTrNd+MOzVETA9rDaCr/L2o4RzB LRvtw9yeA9CFabWrT21qq307lIpzbHulS83Ut7acEr8/4pPDivWSWhzRfD7YuQ3L2U7ribeaBiNv JwRGDC2j1KJZHvigOtRk1SNtd4Cfh2MhTW9TNW+7h7LmYeswtn/v9yY2+eucgyoKdO0CN/lu3Hoj oUH92yByecYqsW9tTCkUNO9HFi2i2+SKCOQkunG3Ndppl2s4uEEFOAm9MCKcS3tQ9gKyFHli3mEk 9i7R8Bmk+Miu08aO8hY13UOXPkbCeyX8XOL70g4J531jGT9weihT7aayIyC934TYXEE6B29o5b+j AQAtllZupaQm+qtTA0wTOMpFNOUvWuEhoQwD061W0JSIHhR8CM9F2VPjQ0C5k+yMTztEqk8vncsV QWqdz1KS35h6rHa06pRfjYGbClC4moOmtbopJNINjrB8UWZ12TbmBtGw25eGHVzZtgP8dvboqpVt LATmQMt4bm+2++LgMs/1w5KKphPAM8DM4WRpfZeU0JjC7EDocI0pwwaPcb0jEmzPJIILGPLHFCm6 5drqCDpBCjmr0xaKBa10yB0Sas56xhK22GBZMvbhcsESt/SEzmbFXZ8q8jYJ+H48wdammtwvme87 H5j+ZAC46RFBC6P2BlxpahMxZe98sdNgYQt0RvnUfAnz6zErox4Bh8Z8ig1ywSN4wo2yWfIRdqef D5mJzddx5tV8R52DjunijUaJ5zbCQZjfDkKZd3zK9TOuT+xqWdX73KIJdTAeoizUszq1RDv4HsPS NoMnOzrCvSdqjHTIRYbmVmQvrclWla3xG/A3kPWLLMnmw+tcsXtYKFMvIA1Qon2KYC6YmpnDagUw ST1gS3UMSysAFUDQGNVxFxAEmatImn0FvneAoFtQYv51O0AUw3t0dWNUs22Be1+ktze7s1Phd8d0 RrrY1dwXMQ4u8Na9vbdu23URU5pzUwi/tBGiujM2bg/ilBNJd4ATv8EoyyTGNQZSaew1YhlYjt8Q whM8cHQ9JXeaQWsNvEC7ANtI6BuFxCm6dEIXgxBR/QYPU0fjWII2tirMRKSz8VISQX8a5w0+cUU0 pPinxQFbnnpkl2lS/Yzg8HS4WiyxmIFX3uAUVWUziKrvinQH6qK94MCMJizk1sO/Kr91tpnHnfMC rAOmA4odfDXkYiu1MejnN6oHLnZxnGUmimgABm/qJ4F9ncE9el2jid8LVryvQmw1WgSAu6Ow9EuH 2maUDzhkEsDUvVEo2gLDQb1zZ9PB+3e3UBeDUCvRKGqmUa8nuw3xyXzhzX7uoyosF676MvXIi+Df +/EE++JBXl1zSAw1kjmo3kEGi39qxRczfW9/zuRAglgU9n2EfPhOy/nxLRJEc3SgCz4YChAE68BL IY+LeSRRhtZ01P4Q8HP4V+GKK/x9pHUArsTRWUULf5ldjNWr8c4ftOUp0rlLcmeKdief8AXNF3Ug q3yAOryDzUNsuh5iETzkqU5UjTzJEHlmcW0aa3DCeFBEfsqgyu1tunoHJKI9cIHQ4QDApSMAUyxq muF8yaoLLjLEc7EI5SmRKgqx8/fjJBloaj3ulP6BvYKYu7+NjVEPXFFBw5UGRGRBQJaiSWWQjN8W HkXbYdrpcMXDgFIDex0OCKESmkMo85J4kO39Movl1vZ9qDatN8y6WPS4BmbRW+m1nR9s6wezlV5X w5Ja7Fb66skOHuYjj6y+peizXPUFeAncgjgPNaYOkC7OQH2A+/FAqEa+mqpwx1wnAFhOTdGqoTIe gHs/2FLY1yq6yr6p5FUccQD8fhBor/bk7frm7ILorpHn0u7eRLzF8NGi7pqp8Gv4uvyimIJmFV8j FMNrO4DmDL5GKAK3CV+zKR/ZhFI4rUGefgLJUwh2pUbiT87jCsK66R25gXoWHKwDh+5pht/okFYY EyqiFSrQQ8gw3LSLVihCK7tC3eCVt/qSRpGVja3/RGMu2geumghbSmRTEpKPQxNhtWuI+84izwam lNNO85wP8CjMgDAGdlYPq/HaFXYGJqQR6lBgAOysptWZiTgtj9Dm80FuWx2h7ZX18eCdeBAVfRSh Ih2DQcaLiGHYyYFYEPmVydKCfn2y3LLGzhHTTksyl97lNIT0gWKcgRknA+SOkanH6kxcNcpCgGaJ NGb97dPPnoOPVVnYxzdtQ8rr58HESntpqLDlgpV3txah8tycACOscimmDAuTc1MGB3ZGxySacWPY 1cni43Hq+hQHwi38rcLlTeVhwBVkMjiE5Dc+bakY1l14PzN/PBKCF9lffdJnU20X5BmZXwwP/biv 3LBmsNXdbwYN2UeCND4xifrefrRJ/taL7nChDRP3uMX6rSXpeWO7KvbVmQGOEexxL1GrsvPK/XD+ 8Pj3n5RrgqHcGQbFBY6EvimJlzwasQIWln7hGlPX8YkWzRA8NIaoaK7tZPFZBECDFFTXnpAXJHHR A8IEIkrSLY3hqToyQM7DJ+P0/8mI1U8cnsO+DG2ra6JK1aHrKfhBsIRzALXEUr8e+Tf4HHKV28Hz 2l762QG1aOi71aKDZ5/sRaSsse8urUWGxbLCucigplkN1ryJENJrFwt8bqM2xWBLunU06H4LU4YL xhwID2EUfL5fTinS03ZOtZKxKJT1cKvvgv4pykBVCyupTuITJtibIuiZwaw2TcgKorlAvBpXcXUa 2zpAaR3dcBpT2uJCXacehg8mInS205j7lz7f+DxGjR51EHs+0YFap2P7+zLaXa9V1KXt59jnCCo0 EmEhIwrgtQhPPA286wJaJjEP6D4f2N8mTBSFFIglXB7NKiZ3z4gXPr8ijNAeDXi/DOHL+TVOMP4Y PnOGLyHBlB4NszuaU+aiq48HQazMry2cDUP4A0PhZ/xWEzPkoT3QQc+uXnjBkSJ+ICb6AdvH7m/Y qSg7b1cG20cEiX1BSw+dRK89V60JNnyy7fh0ZpWLAzCdswWinX85dg665Yot8MbQ9LBs02EeC1MS 6wMxfuNuZughoNGaEy3kOKuhQKMMgFVMM0DmMmG4bi99Dr4wTkSjJNLjjfSgBxQpqYrRfJTqaMsT hs1Ubhd0hvcxGtu68DCKoLRoWF+zeGb7F1lXrKJ6kYpFi7OykRjvZcNfJinexEYiSOHyCUwNBXqE /2VM/wMoXcZHlVVvVTSqE7E0RxF1EDwLX1BsAnsJFyEiIAxlkImH28K4MIOfUUE9kocIig40sVZ5 9QyZX2tgaLoahmj8RtZMF0ZnN/SzYefIvjOSViDpwThaZX+Wo1zdu1w42rk5D/bSC2pH0bpEpKDT VH44bREZxQ/QS2Fvt5xqe3e0ih71/dCLpf6WWcasSV4jT/T2nf2dFpuK5HUESM+hQimBVeizdDdP MvBR8LRCd+HAnVBT2FGIZzhe6dSpJehU9kMKeAfRoMtQ3a1dKpfpvNxHdGahFMUBeOjaDjsg2hNE dWGGOhxMtXp40Q2WLsveJoTDZ+32wUQpHK2R8oTI42bpqBmlmyUiGWER4aPedrC/ZlUUZRfGciaP vvfD7cMqWV3791E3D7efc0HAo5fVjYH/DPMz20sMdO0SjmAUF7L5jdY0xcC0bmk+pAh4EBU006UC bYIFjfhQxor/BzlpGgzR2FyWsGS6uuimeYpWxxt5uFy/dRMXeges+CY+jd/TCtUZivIb2ZkyC62g QdNLpAMcCInDNyHt1TsLiQK4zWWefTHo4Gpseert72P47XN1gGsyE9SPMfhWnbI9xlDypsgZRDgL 3eZ4Q+H+UMipSr1GIqJytIUOICYc8il7+4y2/UG3lZWHhYGixVkwuDvqeeF9tUmczqayrd+5UsBE buwCCjybi1/E4kfAgd+CCnXtrRyAkroksbrsQMmQXjhOht1gG011+A2uQ06K0IqfYELfCnsdoBt9 cgd36QbYs5gFRhoPrO5IE67W4au+UDvVGSleO8ofVgApOuk0kifnMItdALRTHvZ3qrq03IDZLwP7 PCu79V2rSNijRr1gePgONJEx+0QWw5EoYLF5IhtCdag/rd2HNTtMvHvp34OZ/SZ/CxpAjAF3Dyj2 BavhD+bZl6wbA8V5I/wioGhtotv7PZtNLryGm6MnlGVjfz32lD+Yj9+VtpXT2LujY+x6AMmObS9Y eH8w652l/eVke8dnLbQvOOV+4FPYB80sD4rIfGwy9PkQnez7YBpWlvHEzdZtzW92QhEioiR0CAES uDKpEBjTTVvD3bzNrYcfDILattj8i0Hh9Qr4C5k00r8/VJy+4aFJgefBrUXkyhqwLZR8vKgWymjG PJA8lu5vUNjnEEtMGuGBZlIE1dcSzqj2mC20sT+aYmzf8in7lmBA14upoTKZ8gbFfnFLHbo/qdYW u3Qobvp/AB3NawplbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjUzNjUKZW5kb2JqCjcxIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNzQgMCBSIC9Db250ZW50 cyA3MiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjc0IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9MZW5ndGggNzcgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1aTW/cNhC961fwuAaaCTn8vqZNgQZF0RYL 5BDk0LpO0CJOGjsp+vP7JM5qrbUi07vdiPCBoCVKs28+3hOHH9Uv6qNK5LIyzlGwymVLIalgE6Wk bq7US/VePf321qjLW6WHv9tLrNFksg1al3/tZ9GRNU4nFdlRcpm7y2v1bKucGdbKsL1WT783pJVR 2zdqoy7U9i/1fAtrFu3pTrHHePI+ODXY0y3Z80ptfrhQT5zavMeQ1eZTmV2V2Q0GP167uujkltdq +6LiRxwBqtGGQshGRfkRNaA+OR+oRsPL3tvRnjpQvwNwhtVGAPytwPkGA6AWjBEK/UwB1WGQ2XHD H+UNN3gYHHbvfcc5rKvIAhOYAud8ANC9LOjuZkGtw2YDqFvMShM80jLwQ/aUrOyGrEQW/FmcIXEv HoK/6oHrHlk+TAykY1y0szuoHifgBl8u4xYTxWAfi5sE+IcSfu8KihjOiFvK5FnvK0TJyGnAfU3g MhNrVNtdxZqzR+0cOQacAPf3CFw9YiNRdXVEBbDIRNMMYqwtJR8Pa+rUg/cRMwUqXYaxetbXy/+j zr7A25PafC5UKKQptvDEwL25lZ49gvI5OTLMh0guUn61BBmKb3ekJNKBONgwlwuHuVkriWbI4KGi Nkq0kAPlCK22JNFKbj4OnyMlY0iRQkwV4gbcNBvqUnHHa0Nw/4QI7GXH5xKJ1/0U2uL3Mp2KOlkp zxFpMvyz2/wqz/m5H43a/FgeIEsuMUMOyMqpcDzkg7s5tzNH7Lgtj5FBJMvb8qbpLWKV3CnXpu8V 0+Qpck1EkVwT00TFyo+Qhwn9/zN5O5afMXVB/zlB6EoozEXmKpkCHWCT5zl7Dmry18mUkIlTqMiU anOOKLT7QuIz5QyZ9PC3VbU9pxTa4DVFreVbb0qhq4SPM+R0nC38q4SPZTLG1VTaan+dFD/MlHg2 u1Zxl7EQ03nWnlXchc9ttsG1ku4+O8pup2PW11U+eULKz+qYNeLHg8WsnzVnjfDxIZIOvpmdOO8j 5TBbDFfxlktQnTvympLFKu6yGVpDt5PtVpNOO/JqINsZ5J7dbHqtEj/GkNfNkAVMwc5LO/vuaAFQ NlX77tVa4xRt6BIaHGDTOSm/Rvi4XkXbefJao/w4bBVr24w0dN5TtmhFNfJp4Vyg4NqJHhshNdoh L8cJWqMd8nKm38Bvh7yczoSMb4a8nEbrNjVDXjZrtJ3bIS+bwO25HfKykcnqdsjLBkvatENeKIUU TTPkZfszFaYd8rIWbWBuhrxgCqRGO+SFDjlF1w55WR3JuXbIi3Mi49shL044pIRDDY20rziiBx/a IS+Omji2Q14cNJo77ZAXe5yqyu2QFzuG2DDNdHXYWkLKN/PpxThRqHUz7MXGQWtUsRfa1S/RRDVh PFI17dNKv1V6sd/g1v3ZN7n2aXIgTjq6crKIJguksbs83O1AT+983huK7va/GHH0UY7iSCt47BYP 14bWc9fv2vT27k73icHTVvKuy73UdLfl+IgcZZmiwMUaXDtj8xnxruHPJcce7BDBsfsTLT1cUyyX Z1/2wey6VwXm3emDu0cDuo2ALgunNtmC3etzYmcNviODiQfg1e8W/weL6CIyCmVuZHN0cmVhbQpl bmRvYmoKNzcgMCBvYmoKMTIxMwplbmRvYmoKNzUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCA1MSAwIFIgL1Jlc291cmNlcyA3OCAwIFIgL0NvbnRlbnRzIDc2IDAgUiAvTWVkaWFCb3gKWzAg MCA2MTIgNzkyXSA+PgplbmRvYmoKNzggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgo+PiA+Pgpl bmRvYmoKODAgMCBvYmoKPDwgL0xlbmd0aCA4MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBzZZNT9xADIbv8yt8zB4wY8/3lS8JbpUi9VD1UC2LBAJadun/r8kM2Sa7CkP4EMrB mt0k8+axX3se4Bs8QESbgKxFb8Amgz6CNxFjhPUKvsM9HB5vCJYb0N21WcozGikZr3X+absKFg1Z HSGwxWgTq+UdHLVgqXu2hPYODs8INRC0V9DAAtobOG1FzaQe9RY95NA5b6HTo6b0/IDmfAEHFpp7 CQmax7xa5dVaguv/Wy1UueUntBcVHzEDKmlC7xNBKB9RA/Xg46CSliw7Z3o9dVBPBBwxNAXgr4zz SoKgLoylFJ5WIFS7UFbzwmXeYS0vk4Tt7DcvYarCBeQZPac0ArTjAvW/C2oTtreA1KQryTuxpeeX 9GRXqs6V4oLrnIxS9yVDkq96cOqV7YOCRx3CpE416h5v4Ca5nOYWIgZvXsutFPjvXH63maKED+QW EzrW2w6RHTksuM8ElxhZS7d97lj79MBzIvuCK+D+9ODqifWDStUNKoGFFOjLEGNtMLow7qnDDO4S o4xK59B3z/p++R599kJ2j9D8zaOwDM2ihQcCt3IrMztj5HO0SMxjkpMjv/oI0jVfNfNIpD2yN36f F8berD0S7RkGLzW1/ojmk0PLXOS4PNdKGFpzgOcfsvYTVQplbmRzdHJlYW0KZW5kb2JqCjgxIDAg b2JqCjQ4MwplbmRvYmoKNzkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jl c291cmNlcyA4MiAwIFIgL0NvbnRlbnRzIDgwIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+ PgplbmRvYmoKODIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgo+PiA+PgplbmRvYmoKMyAwIG9i ago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA4MyAwIFIgL0NvdW50IDggL0tpZHMgWyAyIDAgUiAx MSAwIFIgMTggMCBSIDIyIDAgUgozMyAwIFIgMzggMCBSIDQyIDAgUiA0NiAwIFIgXSA+PgplbmRv YmoKNTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgODMgMCBSIC9Db3VudCA4IC9LaWRz IFsgNTAgMCBSIDU1IDAgUiA1OSAwIFIgNjMgMCBSCjY3IDAgUiA3MSAwIFIgNzUgMCBSIDc5IDAg UiBdID4+CmVuZG9iago4MyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEy IDc5Ml0gL0NvdW50IDE2IC9LaWRzIFsgMyAwIFIgNTEgMCBSIF0gPj4KZW5kb2JqCjg0IDAgb2Jq Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyA4MyAwIFIgL1ZlcnNpb24gLzEuNCA+PgplbmRvYmoK ODUgMCBvYmoKPDwgL0xlbmd0aCA4NiAwIFIgL0xlbmd0aDEgMzU2ODQgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBlL0JYBTVHT/+3ptj793Z+0o2u9lkk7DhSsIRiGaUQ7lBCRAkEgTk EiFcxQMJKoeIila8D/AEFQkkYEBaI6VaDwqt1npUpRbxqFHaUmqFbP6f92YDaPv7/frPsjNvjp15 87735/t9A6GEEDtpJBLRp8+ftlC9Vz2IPW/z7/RlS+L3Lfz9MkLoA4Sova5eOGv+pCf/dhEhpt8Q ovxu1jXXXT2+ZPtCQhyPELJg4+yZ02Z05hU+Q8iKUvy+72zs8My3/w7bM7BdMHv+kuWj0rmV2F6H a1Zds2D6tEfWvlRByE38npvnT1u+UP6tfRMhK/n58WunzZ/555wZU7F9K99euGDxEpPJPAHbT2G7 beGimQsvyxz8ipBGnG/txD6KD/+zE5W0YR0nV4g9DM9n/MlEwTETNszEQqzEhnMdxElcRCNu4iFe 4iN+EiBBEsI5YfGjCImSHJJLYiQPV0yQfJIkBaSQpEgRKSYlOKcbSZNS0p30ID2x1Yv0JmVYl+OL pyN9SF/Sj/QnlWQAGUiqyAXkQlJNdHIRuZgMIoPJEDKUXEIuJcPIcDKCjCSjyGhlHwnjG1GeJWE5 xfvS+QW+X/J1Zk7nl/w4X7Ovcf3W7JeQrWQ7nUO2k1fIAXoCv9pB9pIW8hs8zWDyCLmR3EvW4ukn Y89t5DJ8FOy/l4Y7W9DvLRijLeQQzp1IbiL7SICGOr8iK8lq6R38ajVGKR89HksWkDvoyM6lZAr5 VL4FzzWSXEsW0sbOSZ13dt7T+RR5muyVftPZgZGNkOn4HOr8Vnm/808YnSlkE3mQfErvsezG008k jTjzUbKIPCTVybRzVucP6EGC/Ax9kDEGh2gbS+PqM8kXNERvlAbhKk92NnUexFk5pI7MJg+RfbQP vYQllCmdozoPgWrdyXJc9UGyi+zBp5X8gnxI7cqJzqc6T4CWpRjhlRiP39I2KdOxKlONcVMwSiWg zDA81y/J6+QITdJX2QLFrpQpunJ957vgh96kBr19Fr88Tv/FbsJnpfSaPLTzYvDNanI3H23ya/Jn GqE96Rg6gZWwBewxaRE4rBS/7U1mkDkY7wdw9U9omu5hdnZYelJ+Xj6t5maOdjpBkRR5mDxKXqUO PGmcLqY30/foX9ggNpU9zD6T7pW3yb83TcNTX0nmkzvI8+Rf1EP703H0Cjqb3kjX0rvpg/QQPUK/ ZBex8Wwe+06aLTVIv5AvxudyebF8i7JGuV39MjMpczDzu8y/Oss615Bx4IdV6P0m8hiebC85TD7A 51PyGVWojTrxidMEraE34HMTvYM+QbfSbbQFdzlCP6Nf0b/Tf9LTjOCjsihLsHx8kmwR+xm7lz3C DuNzhH3D/i0FpXwpLfWRqqRaaQF6tVbaiM9u6c9yRD4sd2Kcy5T7lMeVrcrzygHlhGo33Wwm5rfP PNnRreOTDMmsy9yX2ZVp6fwz5DIMnsqBFFah99PwmQt63weO20HeoXaMXYR2oxfSkRiZqXQubaDL MZK30ofo06LvL9L9GKU/0u/QZwfLEX3uwfqwi9kYfK5kM1kD28juYS3sPfaDZJJskkvyS92kS6Q6 aaa0RLpOuk9qkt6WPpY+k05JZ/DplK1ynpwvp+S0fIk8VV4qPyZ/IX+hTFHeUj5Xrep8dY3aqv7N 1Nd0oWmsaZypznSXaY/pXXM9uPNXZDd5CRx49o8elVZJQ6Td5E5WLofZb9lvwc9TyQxpFAOnsq10 HVtBW1iBslwdyAbS0eSEnMJYv8YeZ6fYQGkUHUEvJ3NZb+OCqk9+Dq0q+VekXd6PZ/strrxctdOb 2HeqneyihEET019LveS09Bb5UPqUmuQt5CPZSoO0nT0rjQUX/EK+UJlEEtIj5EWpga4gu9kQaNrT 5g3g49H0OeiF8bSMfi91EomNBhf1k/5CbiHz2PukHXK8jtxPZ8izyJ2knN5IviDPQCpKlGvVbqqf vsHmyOuZl7YQJm/D01XSAiopPnIrrZMeUr9jH5Cl5LBsJZ9IL6D3h9mL0ij5hHIZnQ0JWEHWkIbO VeQ6ZZL8ezqLSHQCKZSPQrvdKJXJCaxXQqtMgU7bA+neBz1wkTQKe0LgnJHgixpoiIfweQB6QgYH zYGMT4QW+y1pUcezVjJLcVJoHULktzKXkcmdz5AHO2eRazvvId2hD9Z23ogrbiWfk7vIVro6cwNZ CMvwAWR7pDKUHVaGdnZn69kH7HJ234/pi9EupCHyNT4vQuNfqLxM1st/JJeT6s4NnX8AdxdDwz5I roIVOIan/BZ3uFRqI+WZ0Wxn51BpIZ73UzKu89nOPGolszuvIWPIfvK0SSHTTGl9UM34i/TqCy+o Gjigsn+/PhXlZb179ezRvTTdraS4KFVYkMxPxPNiuTnRSDgUDPh9Xo9bczkddpvVYjapiiwxSkqH JIfWx5tS9U1yKnnppd35dnIadkw7b0d9Uxy7hv74nKY4/900HPrRmTrOvPonZ+rGmfrZM6kWryJV 3UvjQ5LxpkODk/FWOnncJLTvGJysjTe1i/Yo0d4o2g60Ewn8ID4kNHtwvInWx4c0DV02e/2Q+sHd S+lOm3VQctBMa/dSstNqQ9OGVlMwuXAnDV5IRYMFhwzYyYjZgUdsiiQHD2kKJ/FTXEYqHDJtRtPY cZOGDI4mErXdS5vooOnJq5pI8uImV1qcQgaJ2zSpg5pM4jbxOU14GnJ7fGdp2/oNrRq5qj5tn5Gc MW3KpCZpGq4xpMmdxn0HNwWvPxY6t4mLewZNWnv+0ai0fkhoTpyfvH792njT5nGTzvttNMGvUFuL a+C3rHBo/fqhuPUGUGrE5XHcja2undREV+OWcf4k/KmM55uZHML31M+NN1mSFydnr59bD9JE1jeR y65L7IpE9L2dR0lkSHz9+EnJRFN1NFk7bXDOTh9Zf9l1zWE9Hv7xke6lOzW3MbA7na5sw+44vzET g24cEy1xOm+NuOzsyFLeo+SwJh0cNT2OnkxK4pn688XM/mT99P4gAP5qKX7VNAMUmdNkGVS/XhvA 9+MRaZNSqCXj6/9JwAHJ9m9+vGdado9aqP2T8IOcT86yWhOd1tVuSqebunXjLGIaBJqijxeK7T7d S5e1smRyoRbHCsNHxmJsp9UO6InhTyQ4gW9v1clV2GhqHDfJ2I6Tq6K7iN4zXdvE6vmRtq4j/hp+ pLHryNmf1yfByS3CSfU3mVNn/7m0gHfI7AFNNPB/OTzTOD7i8uSIcZMnxYesr89y7YjxP9oyjvMB xbjhWLbV5B00SYoy7OMtFpXEUTDllMlnT8HGJHuTXIh/qmDqGa0mM7hS7KHxoU1a/aXGstaaSGRl 5v/1o9bOE/xXYnXuZ9nHaBqQznbU6HbTwB9t/6h79vXSiPFQOWzE+Mnr11t/dAysZvRyWHYFjifj JyXig5pIDSSzEP9aO9v6829ttEnHkOHIeEiR2F0bzW7+6MRo9ke1+OPc2b10KHTm+vVDk/Gh6+vX T2vtbLwqGdeS6/eyA+zA+oVDoO0Mxmnt3Hd7tGnohlqM2Gw6AOLByMVcjAeNn5R9ckEWzt0gEzfi UMncQVUIPF4TubiF0WOqqZU9qHuJIh+TiNUkH6MkbFaVY0zaD8NvgRvYg4TS2qmqjqrR2smqUR1V pBpt7QwWvXsl3Al3IRYUZu9MXGo7oyvkNInLbbgXuVJqZj9DXKHAc1+6F4HG9835hRVKa+f3en6q pMKmWmFqZEoURbV9azGbJYkRk7nK6rI0WpgFo6j7Ha4KyydUkqsY1R3uChq2NzwbSqMjad4TrSNd h26gQxo+HVVYULenspJ/e/ei6bRX6lPul8rFcmPZoe4f9z7US2qmwRMnMl8ZS95Pf+cXcq3yDmKy PNpbX1uc2z+XWWRLLpvoesn7Us7r3tdzvs9VKfMTiyz5iEVR3QQ2TiMWm0mLWu0mLeRwmbSg06O6 g06v5As6A8wfdIaZP+SIMH/UmiP5otZcyRdyxFR3yJGnuqNWazRaSCw+QiyOUKgw6PQFg04/K/RJ EtFMhW61le7R+zudDofVaiHRUCgYJFa/z+fWLnSaVFViF5LQvY7gvY5Cp+6uHON83MmcSxPWe6OW e3FdDN5ud2UcWqCVbWmOb5vNSViXbj+mHTu7PsnHCyTFMjuCxjhqHRhKd2VPLNcqPdIrtINre4T4 yvWTPwxxXV1D0JvsU+5N9El4yyX+LfcnpYQ/ISW9Ccmb8CZmTdz2+vDMd7TnxPsm0oET75+4/a0R NJB5e+J9EzKvTVxKB4zI/DpMn9tE522i2zOX8++mzKZNmQn0ucwEVk3ngWUpmQyyFQleSul+okhU +RYh+Ko43UgZnatyrsCDtZPqdsEBvXsZpF/XQxDc889/Zr4V17kxM47Vg9YauUC3Frko0Twms6a1 0vJm8rjTjLXuNj3uvJJImhSXJOkF96MbxKU7TrVrp3D9qmqwPa2jKeau6Ne3X7lqwsevUfrppt+O mrx/1XVFFyTTNJ0Zt59+T53ffthx+kjt+vte/kUmL8PJce7+M3V7MSvWmMWqUeKx8B5YH5co1i3k celKJ3RZi6axGjS+b3G5RONYi8MhGt/oLquV1biceSD7C55sH9P4+0k/vUnirihK4VMegJemsY5V kIv8C4quX7V/8qjDmXH0KP3z/r33rZ/8+9MdH36b+XvGLMZJl6azP2CcQmSNPtxGbdYojVplq8Xu dGluk2qjLMR9PhORJXPQ4zDB4+NeoHAC4QP6ZJNkplZVsRGixX3U94oKLfA0mHqT7lCeJrrbW0HC 4YUYWy7Mo052HONqpa4KbOcJVuIfyCjWfNW7F6nz9gsE8RCqqW+/oGoKBE2pItVU1LdfSu/x+KVe erfkm7W6x8rrL1iwfMCY4f2XLSlbJW+/s3/J7sHTN1WU3tnN2WddzZh1dwyvuasHIBhKnst8Qm8B LmAlo3dboQyfR9fG6ikqVTFGrbSKWJmEDaL2Nw0Yg5hpASKAzdBkm21bHgA/nKw7eUxrF5LDl1q7 1iEYr3evcmgcH+9Z3357Do2dWFbZVzp0qOH21KjwNI4cXURb2Vw2H/q3VA8vZAslNoqOwi2ThEWU hTghLC+8gw/KsTrtOOk5qh3P3kDrvH0S/otYCW3dvRvkwWn7sFiL/kukUA8x3t0qo5M7iLwZxzfL op+n6oRMGN3ad+jQIf5bID6sErSVyOV7idT5yS5fJWvt/ESP+yrvlyiTHpd2SExaRiiUE6QL51ml Lwn7Ery5DbeXm6/HCEBztGuGPHAtUQf9wOUinfbTckq3bcxMCivf/IArMFID/epW2iBzubRmJ+P2 SbdGYrLiizkcQSj6LwV/84Ye5gxucRM753gSsNuxtPN9pCeY+xAWhyDj1RiW6E71P690EldSa3Cl 45AU0fhWD9tsaLmJxvcQzW7nS77v7CXPXbNFjYe1HIjeLha3/RIubABfD76uzqP6VbK6lq2zrXO9 4VQsJluIDfGO9A8PD4qO907xTwlfFp1nmmeb7r3GPy9cH72O/UxdZrvetVZ9wHSf9kboQ/ae+p7t I1fk7IMvtuiJZEUvCyUWDfZuY557MdfbuhN744CzGNkYe/12oXzS0D11DWmu3vij07oGwFX9+R/F t7bWq3n6lpcFAh4IuJrML0p5tUB5WV+3lkrmm9Saee9sXrZrycVz39ny7nV37912443btt104/A6 9g6V6QUvTG3OdH6YyWR+tf2Bl+ijmfu/OwEMaO63c9ZwXvkUBDwN2lnJDj0ucRs8T17J7mIPmuUX ZGohqsIki0LtjL5pFb238mciNI7ftnYeFRoMja91tyBojiAojBoIilHWw5xcXTQR9InYFR1WH16C MRK9FBoHbsaUsG0fraKr4Yxw4WhIQ99zfYc/bBh+STVXG9zy15G6dCLpVlVTH8hhOTvdctE74+// rOcS+YYLb8x78ZI3p/JnqwIvm/BsMfp6lpcsbs0R8nrVGkdr58kWt1s0vtUtmoZWzKfEOIsG+Qmx GD8ay3HiSAwMimUre1m3M2swGM/T3IzF8+CG9Hz3EF8eIj3beU+r+fIgAuloVgz4De0eDxM31C0u N1rGfY7qNo+X1cR8fB+/9i5cmouKzcZq0PhGF6P43+7GZYTfj99N3EzvO1AZqL6svKK+bHrd/EaO aZi91j7eOc8+w3m953rvbZ79ns8jn0dPROyv2F7ysqiWo+VqMU39JUBOE5jfjLUF1IrErJpZVd/M ifhyciLmnAi0hTmSIzliWit7qnmMm7pbaWg3fwIihsNFmd26OPgORpvzOn2ZrQLerdH+ut29uxpg 5AK2kslsHyuA63XXToPZoVdOpbl64Rahqrq9o+4YNwLCIKx19kg7oWq4kYdm7JKA/qSO1i2qrS30 J1L9QPG+fftUgPWFGoZcQCHDSKsm2XSmHwsWPvnQd1sfvOHmR+he7/e/e+fUpc8eeGJKbPv2i6qm t9108POr5/38kfXewx98vX3Sc/ufWjeNo1+UTOg8LgfAK2lamyWdLRzSOR+HcgjlzJq2Y4OWJK0O l90Vs1pL/LEcOVaSo5Q4kg57KAwjH4fyYTVxU4rTkZ+e6slV2qGe/EM8ldXVMCTt4Jf217TXPJXa wXQZ/4Jd9GLFEXAMcaxxyEPcE93LotJlgWu0ub4ZgaWO63xrHOt9t0WfdliVuASh0202u8Mpmyju C3PzVLOOB3gZQFEJcdA+LXa7Xw7tY0+RMJutF6GXCrrp8CyeGl8QZ/EQ5+V4o2lxSminFCUpLcXQ 45Mv8SOpjd1DrbT/rvA7dB/tD1PSptvO6avSVnpPlorpdkFHrrVOpoURAiVBSDycJihqEBTCCiUG eaUNtTDxXGsJ0pn6nW12UZGT0RTAkiTzUxNa8jbNW7njiRXlI30e2+LWNXPnbPC1JL5+cfmb866e cfPGzJfvvdpJbwk9uLbp5hu3+B5jy1dMv/nWW+O7X5+1a8bUR3rEfnFnW+afx0FbBgSYyBp8SyuG J6X39Uyyz7Y/ZN9mf8OujJRGOu6VJQ/4nNhVyaRYbZKJ2CHwb0oyXHVZchBmd8DbeZm9DHie0c26 lcgyTiFvWuVWdvVLimLVc/MqrF3aEA1unFgNGt8KK2Vtpf10h0nPT1aYGhN9TBtdMMcYV4evgjCN xZmE7aPiN2gc28PpwHY7W+kGMdbfQAMKZXiSq5gq7TgceAJWOll1Cm48H+bKyrU90rLhwWPAEYDv JQ7YfU8l9Ny7uq28UsrvXinJublV/BK1IAfO0X123VZpbxxbaddTlfb8HKy7V/IT0rUI+frQcjd8 fbfkpuy+jlvZoz9/7bWWTB869Wlpz5nhT2e2QLA3dcwD63H7n1CegZ6dYMjOXkLxfA4+CDTHaY35 /Tkerj1tLlmO5TiclJhCsBnCKxANIWfc9nM54TYQbNRxELLBRaPEI/SvSyxHRK7LXZ97n/dZ76/s 79k/ipot3pCzW0Sy9FJ62fZBl0mQD81r9Xu83jedLp/T63O6HBAS3cs7ojs3w6F2unQ/zXbqJZdM 3+ECBM2mx3n33FO1BdpK7S5N1iAmISEmIUpCWoihs4aYhDbGPftpH+Kim8BU/Xc5d/83ccn7sbic E5g6EJDrPfGgdYjF6qAYjq0190groCIRyo9b/v60AR7XjwQH0uLl4Rf8AeL3meANpGp+4X/wmptb tm+YuKF4253sg46Xxtx6dxs1L7nj5G86aKO2/vaDTzy0a0x1gP3thcyyKZlTv3v97l1HIRqQjVGg nR96L5d0o2Oymi/PRfOQDpFotDimO6jDAcMYVfJjPoc1RkmhhkEw/DgtFtS42Q8KvRcEgdDO+nGH 3j2k/bqLlnXt2sE6Tsvu88J0sEn3Dw4Pjk/2jI/Pk2aYZpjnembEl5iX5qw2r8l5z/xuwG2Kcxko MqRCrUkKpcd3JcQBEz9QFE/GE/yAm/dyrIOhn1H6zlROSig+S1ef4dX21z1kd+FiTZAS0ZiGuAtP ceIl7itqG0utXNXFaKUeqA5ODS4IrgzKQbimak0wwG8abGUFzWnDVYMstnP7JfSe4a8Z2q5nHXfc OM24AHGNV0sRwwgHDUENyOXhZiqZT9xaP2wFqO+cNlSl082h0mHzJlxUcxW7aP+slo6fHbn1z5lj j9725faPO/qNuXP0oqeeuOH65+TLnXN7jep14bd/ml6f+dfv17ffhBTOjXTbq1sPnPm47rna1sce 2LEDdKXIdBHYs2eRg12oOw86qIx/zCxboM+4JPZiVLbYHYsByfBBGSNMtcQiLvNiy1/JGFB/KpOq sVpAV8KJDEMZCcWPYK6uoWrUyfbR2inulfEIgVvxSrfQQxiBBhHLqERSTcm+Hk+/adLuDZn2EX1d e6Wb/3Gb/MP2DZsynszp1o+206/p6ygDQJQCHgyDB4PIkvdixODCFjuJxnpwPQl/jNX06OFJxFSl OOZxxCx2bmYRBJyEqkQj7eKxNGdENAwHijfEQVcIFtMItEWDn4VGloGlAr+d+1t+cUW/YGB/loGN aOS8kAQ6Kd3OgadsZPKS6IgIQnhH0OAdOSYiFN4Q+7L3524wbntGz+cn8tty9uI35Ev+pOeer0to cC8qdKLRExEbcRnq1ydASwLDAsNSx+1f9VIsvZBmW0FvlJeYG2yL7Esd1wdvJ+vpBnmNeZXtVvsa xx3Bt92veT35kJVdOfEIX8XjPfmqexx2/6geK4nbSSxE7OjG5h70XE9ii1+xUEsrm6Vr6cUuPQ7P H4iKS3MxVyu9e09ZaHETgmgc31Ww2N/l0Mf9up/5N/Y+G9qchPSDa+AnZN0ET2VdT/5w3HBlZUbo urpFDaShtpamUn0quISc5w8Q7PH6Al3egyqdLzx07sJrjr/S9vW8+WvvyJz64IPMqbuvWjNv9urb rp61bsCwjZev2rr95pXPStGSB+Zu/vDTzVffX1J6cN3+TkJp212v0vGzb71l6vS1t57pHLVxzDON Nz+3letFbtM4T8agF180ooeXbHkwA4VuGIFTgsjcGggDj8YJvZhTNOQWJHWLKNQdcpembcUxjuKM cUpOp4+MpVQ4kw4N0QXl1gZqVREUP5iuKwOL1bWXiYEB5TkjalyPfvxrznQisD6vE+fsp95NGFC3 4OL/w11/fK+f3Ap3OncjvWJAZGRAT14RmJi8WromMD8yK3l9ZEVsQ+T22EOBbZH9ka8Dx+On4t4L Ao8FtgekASUzVFbEbW8SzBRKxNV4cWyMcyo3tDn88eg7Yw2l3MI7kbePVhIbdLL7x6Z1YynX1C1c UbvP8pJbdzP3xqzuBb7JTShnJa55z9rPLsVL6oCkIFgWbuaFrE9FEde3WBMwE7KXPHROURE4+AUv LdweuHHa5SvG9qV9X56/5ww1vXZX+w3X/+2JFz5kbz29ZPmubTeu2EIv166/duTK9xfaQxPmUfP7 n1LtocxfgKN9kWl+8RWp4uE9Bx/ZwJUuQ0UEoWtQe8Ox9/7wJVA3ZLIwtUqWqqgqA8GBb0NYHGOx xZxFmRq4/kRMIEguxMHLEW189wLMkWoPHTrzLEAdZuBZ4tqoINF7LrbdYvu57UnbCRtgN5qy9rMO tU6wzrTutn5mNdmsThO/p6lKVRWnbHseDuhYPalUyaIbq5AiUE1VsrW/bYDSU66WWVym8hZXV5eq AH0Bewfoxb3Mjo52NDkCJjpJtDe4kieLGro6ehYMO5SFw7p63QWKCXu0kHwmD0RlAWqJdPtdUiNg BUWVzEx5mU3GTolN3sV0dR8dCxd7rO4nz9Pn4zKLmOUqygdsqWniZIGUVHHLQ8I9I6Pa8ReKZPuV xRD7UD+l/oXSW2cyEmOrttKHmlG/8mozuoCL/KgPjewuGR4shc/PeB+Q4UAfFB1+3FiiGH1QnwdE XKWSiDmuUCXbh+N16EHVqHbeif/SB0r78H/ywDN9JHqmU3qLrcpMa6bVtKo5czXvB0OlE1FqlX3g EiedtYcCcWU1cPz/3pJtfC+UCvac1Gu5UuH2Tq1RxLKn1kubZZ5tqdfWSRu1N5TX1DbthGYzK7Uo IxqrzbY1af+w/8PxD6dFtssO2SkhXa/IMuJFs2oy2dE2o14GGCHP0rgEWhM32X04xCQYqO91WCZY yLhs9+FXlpiimGOqpLayhbqFmO1f6Ywyto/aoDxtusceJzNN0mVjUZbzqSxtBBu1UqrbxtrbTJ/a pY12aufbmst02MRWmhpNzPRz13t/FPhqQxg2Af9CYKxIWINEh6qrIu3Vx8Bq+Mcxx67UBF8LAUG0 s1Y7eNB58OBaxViDF0c02S4f0RRDOrNFdklm0z6AGUhFcYtSSxdx/5n/JYFaIm+BjIXEgWWJlf+O Tfr4+Y6Ht3xA//bg0PyccmXfD0Pp/sxgNpnet/dnd9zOaSWhVojIX4FWbuEhe/cSGVS5hKOLsjw0 OSF5dXKx5VaLOieyVFlogVQqt9jUooBFChV1iwVyLRavJ9atW0kJycmNYeTyACsRcyil2jnyryJS 1Mu5R6J6uAJXVT72qplfHU3QXPVxB0EdX5iy5/Bf2K38PDvnDD8/yx4pzY3FKZeQOD8OqnLTlG3w c7HnByACZxtA47ixwnXQqksPnMKlyhginmoDa2NjFEJ64w8qgGM0+MI0IR8H/N7N029UoPYChyt3 J4BMdtlqJ0vSRJkB0KSSCCPL+nFNnEL7Ppba+tbiq2etvmti46sbMj+nF6zqP3zE0Jsfy3xE51+Z GjR5wPhNGzLblX21e2de+Ux50f7GWTvre0uXuQNXjxq2oOT0ZpO9/7yhl10HwIaSqzu/UJYB484l 7+yezubmMphV7vqJ5/tSn8pbcVLmmA6pX5LbSG7N3UgeUp6XnnbslVocrzuOkGO5/8h1Oz257txc qZta7O6WE8+7xDHBN9E/ITxbmZd7g+d2z0PSg86HcrbSp9hW9x+cvNIzovm0iAzZ/GRXcaUw5d2L KzUXoXLUG7NL0Zhs0VKu4SQVh6WP5AVTcTM1w8dUa8zh2HSMNk+H1I3iWgxLjoEh2nVz9YW0DbJt oEmaLqJBVU7mF2DgPAXlZTKSIYgjVOb3ebgLJLccuCDzq8/bM398eAcddOBPtHTgK+UHfr7tL1Pm H1/z5GeM9f7u9Kv02t9/DjT+6FvdN9/zROa7u1/OfLV+P+dphuo9okwGT7swep/rPeN5dJDZ4E+3 FnMRMzptoXkC/LIItrJYOU9ZAB0ZbjdXElBLkbxc7X9mvn+BCwVxvu9ivthPmS/LiNxLzDJd716D rtP7SlGTWTUrZtksq+FQJMRUmxWSYJVUf8AX8AYkNSoFE9TjxCJkzknQgNWdIBjHdLob/lbROs6j QeTHEIIxcGhhoiyLIRaBLx+j/35+8k21SxaPvv7uQ6szO2nl3U/3HjLq/mtGb8+8rezz5468KnP4 4LOZzLZpZdv79h7y1TPH/9UtBh58ArqB19XayCbdryoxs9lkIpLMBd1qidmIGXFqm56reSpM46Xh cWvcwawRh2z5n8eMS+6PBdY+8AqDhYR41nFYXHDSyWPps4OWlVTkhNwACrLfJ+SCM49J6TN/kG5V 9m3PVL+QcWzncgRnV16NZ7CQO/S0eIa7TPTsY+ARHokjU8JYxPY/9Fu3CU0j2B1qJvMf3bdyknMJ MP7O9R/ZwaySqeNa5vy+b5U+PvM5a+oYy/s9YHsHN6KUzIf874X8F1KvHon6on5WX0SvNHupRyoo IAlPkBUSEIITIM4HkVI1GHNKiCEtlKaKCgtg2fFkRfUCfONBW9YGcx6HeH8olKawwVH+e7aosYgW 5abiVmoVzr01nJqepQUEeZRWJ7Qongjdh4I8C2OlwcrY5joTX45qg6UHy8loTiQnnCOp9pRW6E/l pcyFKKErDDlyEyTg8iZwss8bN2ErXylM0BwbeNvnxiJmSSRIgYQFOFzwOHfPsgMKhge3A2ztgwKD 8zUI8qk9GFQIz2X7PDKUSD+3NJLNvytzZPP7mcdbmunYjx6n9J7UjsRVexasPvCzRP+1lN1904kL WfULtOPoosV76ZXvv0cXt8xqvbfXwsZR424ds+7xg5nvG6f1o27QA/X1Sr6Qhfc59timR7z+ClmK WaybrUeszKowZjNDhuPIJHNcVFg9+DxAQTHgqgCQcADxA9eVKuVjrtY1An1iNkNeOCmtuOj/zdJl GVBYUDDgeTonYBg8e9xB4wCL6h0LHfLA2hBwnC7zB/ULUmXpCJhV1J1UVyFWxW6ungGHohqm3J3E 8qkD7IcDBzpUZV/HM2zyD0NZc8cowZevgDlXYRwk8vZuioJBxhNdzf0vEAmv5vIKY929l7EuLjHW SVE209acGzO2QxGxRlynVcSVjcoOBdwKp+0u5KibiNwT2cOxSN2dIIonjp0biSTyaWIsAVQansA3 XZ4AR6ENl0AX40ziwk4+Ib+HAeh6fI4I72qEW1dX27AImfoujuJQMxfHcvcrB7iLBFr36/xCmoZn dJNtujaTzVKXsKXqOsc6t2oREtdi4wLXSiO6TY65LJaU1WpO2Tjgy3smGrxDaHANIRqG6eZ7dAG8 2eriXhr36t6x3nqv7KUpUBMpFcOP+bpLr/wpa0pGePZ0PUm7Vtdg+DPci4R1bU+j+6K8gJvOvn3w IAKGSw3cYVo4fdjc4gO1r9786iG6ObT1xkGLb5L+fibc+ubcT7iOge+nXMZ5mmb0mJTfr9JsGVBk 7aP2tV5inSitkf4omZZZP5A+gCHiHpkwj8XKBnm98pz8tVmxyrSP/J7MK52O6hZPokKK8wVch2Z7 JQpCOo82Y9ucXct8nZuowLqt2RPg+z/RLwjjnoWFF5gt4fAFEF4Lam+tiiTLccXqQ+IBRVVxkwrv XbVaicJkykw2lMJbJWZDPNPKBugu5Fc3K01Km3JUkZXhZr7P1stE4/DGm0wSisPW6HZbPI7H/f/j Qf69y4jbB27l7rzBLXWIyRsA8zSIkLGKlx1VwXms4s4jd+h5Zg/rkMhVoCynylwF9z0E9z0K9537 1u/3rzXAFr5xotnu5uN1Qg+ioWpOd4VZc2oVFt6yapANoQIBkAvvSfSB5zXclnyMW2m4Uubf/Ggl hOOTPQE0A5Wg1CfIvFaa832Vsu6r5MO8uxBNv5H5MB6kll+YNiyqSxMeQHDupwmKfyb3fQfY+9TU 8SC7uZN0nDoBBVDC/tjx4pkH2PGvM7LQATxm6Aa+Uch83U4ZtKBCzDzGbmXP6i4Tgyj/j+N9qovT zzpN6n84TcfrDMtvCGnCjw7+HoL6D5h3EPUBzMNyoS8aO9aVmzF3njL0pNnpQO4ZNg4KAg2M0rd6 MW/ZPVzSFJddsqBAxGyxOYnZwqw2Vcgv6iyEzP6wRwivBtE83lUHYFQyYc8ZQ+dwCIsDl7wCo7qt TTtypI3netNI7MA7S5OuIo88k9BJqlhKYimLpSKWoNLf9STXWkw4FzCb3CY7+dKIjq0iXoLDZQTP +MH3eh7X+SkUL8StngqXWCh2iVAnXDMzfDT+4PyaosEvZX2ZTcCMLo1N0B3E8GLEjfA8xmUJB2TT J3uC3zHo4GzjYZDa4E8j/gyWjOorCXOZfSxqlpfZ19h/g6G0D7MPc0klcqGj1DlJukJe5ljuXOsw 25hirnT0dY5hIySkRsyjHBc7rQ+wB6X7TPeZt0rPmlQPczmdvRQGiWdm4Iu9FDOaZvtlrsuojnDc bLZYbdD9TqfG6VTvafQwzz62FZmp3ruUOIreeutWu8Ua1+0rUeq1Dw/ppDYcYa0I4i2AdOOuhRpF jn/CS3GlXmlUYE7Y1mY3N5BhXgtVVxWCaRRxOtqRsxvH6hC1YxgEQpRdApIR0fvaFaKuECvo33NB +i+IvfM0Kg7eAxDynojRRzTZoQGKhQZwdH6/02nlkXs2ifnunkSlszQhEpl7+lU6y/qJ5u7u2JtN VqZrEeVDTjn2BwtNA8G+/WgCZhoTs9wPYJbIFb0CYeQtqfJyZsKOzCRl3+m/333p2IelMz8Mld86 3Uc+ejouZAXJCCUPsmKhK3Z6YIsMf8McsgdEzuBLPcFbZgAlcZMZStfMTJJktsiMWUxmWYoDbUPd hrC6aGRdG8WQJTgjeoQzm1IXt9G4bayt3rbQ1mhTbGbEA2Aw5Evh3Pw/9ELWv5GF/f6Rf5MN6K2c ZF0mHWlj4dE0CPV81qMBzIgqmsq1co80iNOlbpE3fQla1hzHAjwMlcqdS1ChxawPrYQWbtsztNKs lxnNskoTdCwPg/eE0Swzmnxv0qg1syUrTU4fvl6+fXKPF81co5mLpp83v995VulmxUcID4hYTrmf Rd2PvC6xfa+fyYBkq+SVIFfj6UaQCjHsdPj/HyvvYj5dlLypj424qE/z+aLBaFSWNdlnC9qi8rbg HudrTikYDEVZPFd3j/GOCeqRScoky0Stxj3VOzk4NTQhMjF6e/BBpoVjkuSJ2Sz+VBwBEPc2uLJD w/Ce0Dgh/A80vhZaAw0D/UfjB7AG9Icp0phLc10pTkVV0MhQH+GcrsjfCP2NWAEOJ1DE8yq+EP57 NZIok3mYKrz3fhqgaxR4MoT/ZDpdR/u+RYc+35LZ88rhzL6tv6G5f/yIRq/76u7fZv7I3qTz6aMH Mk//6dPM5t2/oZN/mflX5jCtoNFmavt55nMj7pc7wN8OVH3u0ktnuuf52AhthO8K7QqfbLMjT+Ek wRAPX4nZkzKDpcDtopIO6vSkLuIgcyQeofgXCTni9H/j1q5w8D+j2fD5xky436O1BjE4fGC6UCfh fSOoEUF8DCAISyTcCOh5IYmI31nJPaOuuaf228wbmXX0hv2P1Y3sfWvmNmWf0zNzz/yXMx0dL0h0 w8opt/gdBu9sgZwDZsIo5NMzesJjc1JP35zJeVeb5+cBvuFWwyyWJrEsAO8L0ouiMW7zOAAn9kBJ GA1Pa+dnzZ5IBdYnmvOLKpDB+Kw5t6gCWWaxRj5QrHH8/ebclHEc54vjWPPj+jA0Cp3Dc4bHL7dN yZmfs8iy3Hmda7V1net+xzZXq+tL5xcuDTYv7nb53G6X22W3eDCPMhKwqshuOOxKyGIJBCPhGMrH 2oyySBSVJ/IFRUMhl8tpjqWcj8AFMgoy0TglzDQaR/V8/mSqyp9erYsXLCxoLJAK8kP/K5UNfv9v OinJXcSfBP3ZMCt8LARCC8ORpXaaZx4qe4p6sGAlLwfjFRGwr2cDkrNWVtSwWM26q9KlDXB7BuBA LW0QdsMJJy8SrnRDR3nwdeo5lRocPi0/D9+zSodbiy7oEuiQNyn1YGCopGAuUaaU2MLWH3z7+jff GVVcM7Lz5IGaayd2T4z4M92y+r7R9z+Z6aXsG/Ob6x55L7ewYPTSTAPtfeuG/jZTx1KpvN91l8xe w/2vKcgj/hU4RS/m14umS9PlxdISWS4s6iNV5gyShplG5g7JG1wwtOhyqdY0JXdi8W1eZ5KnArjy AeMZjcKuRqqrUdTVwMmgoXGy0cDJRgMnGw2cfEofyk8qdqQKWIFUVNjXVZEcXDik5+T4hGRN4TW2 uY55zqt9M0PX2a53XO9aoS0tWFy4Rlpvu82x3nWHtrrglsJ7HPe57vPHDHOhd0+kPNFUxJIqQWhG SiIeuax3ChOvGXF0vy56W5RFCwOO7rGiQlqoBGAMT+pGDiPW3RKLBSSh9dLAQ+oMaISv6gB5BFE9 ZnxQKlJY4HTYlASQySgmHGK+oUoLC/KxDzBVtHsEV2Q1d0ETtWMWtwB6hKXVaJyOpfV0IWYOqAhC m3Rvd35LBbdGj4dbUqSElnAl7nSyGjRO6g5+pZJIGZ6JpiCh34hDaGD4oALRyKZKULACkoZ7Z4Gf ulHHwHPIXwjU/Byci/q3NFJodemT/IkA7uLpBGIOo4ocpWBgsUCdr7dfjIm4lOuygiKR+ua5b14A zzFfvy8YQDEKx9eRvSxITXnJMfU3KxY8d/nYKQMz14ybM+umv9/75L/XKPtc27c1bansTz+Y1Hj9 mtOPvp75x4P0j9q1d0y8ePHgIbOSwWnpfk/OXPDqjDlvr3LefueqK8aUl88rHrh72dLDi5fghQic V3shbtkHvWgit6GIn8Uw5AAAMdUTJQCLm0UAQ+lLapyynjztT+luSvmAQJ/oNs6wxJzNPfxdaEcc +KwLejiDPQLKzGAPb+CK5j0PnnNWgPvBtdQ6jtUd596kof7FBCSUxifczJvJlddnoopj+/Yf/mH0 dwt8AI45+cgHujXlmiRPMr9hlgNc+QXgS1XIA81D5eHmZa5nlC9dJjthbpS+tKgWXwrOh+GnoZH1 05iARrB9VM/hppvVxQM0HhgbYPWBhYHGgBRwCPCPX53DUFYRLiN0MBIuosG5BY0fDDfNKtw0bBsw FBrZKM5a5+du2jmViJoiAIhZ4MLwCcQklDSQPMAVhi8gkAtRMuSW6w/MyJx+97eZHxYeuGT7ivf2 KPvO7Pw4c+bJO6njK2nMmV2v7L7qgKjuB65LlKEYIyu9MFvd5VEoYClu4wEZWMwKZUrPj1FjcMhd Xo5Rrwaz8iqTgp4K7UaKpUJrT3sve739NvNtlo32NvsJoAX2sXakTm1mli2MsFA7Qipcsrpa5Onw a6vFEjcrPkB+gJTiTPExplhwq6/iVsQoM810JoNTgSLI4sqxZtpo3mjGNnKFDqYXV05l9C7MUWeI T6jujitjFdYLcclGoBgnFAWxybpmWz2MCo9NGnitOP+GeCoYxiQSbkcmkcMNHG0wZjZlk4Q+xBi7 iAuU+Nsuiwc642+7EKLBxUMcgr9anFaMUKSvCEVQ+orKe255EF3U1SaQQBSRRTllF3X85vd0RY+8 /O50w2sdgMVO/7Fx4fLlcgngMa4g8L6TZdy/oB/pqRKScpd4UqFK0tdd6ekbGkYucQ/zXBKaRCa6 J3kmhrQHzA+4sgOpl2s0Ek77K5QK+2BlsH2Ef7wy3n6Ff4Yywz7Pv0RZYr/B71L8PIb1AOZxMUFH 0IxTLSg0aGVlFFiVjEhRNWHwrUDkLQ6ny2XH/G2PPxAMhVCoU9WMl1jE+drucfO1PtmPMAQIEotT 4qModlTM5pg/5PP7Qx67xRLze9D0uDFrI665fZrm9ljs5pBfcaHShTB0SZFCKAW0AJDCZBcW8njc SHRGgsGIdpGFjiNxYsfSj6+O5Pq4PfE40mPhcCu9fafhHNRFwqM6EFh2RMIdodFDZg4+ftYv6Aou uU8ARcqVqfgihBklQhhO5HPRZnYLCnatE0liLKr4QrTOX4DYLhDbzXnCY+VFPQYHFGJnt3MckA1d ndjTbNcVHSdxplhUB4bwGgzh9SDi9CK/jMSCaqL0scwNr39aEOmP9yJ8/fsxyZzux3+VufblzFtF pqAv8wZktfr+TX8tkD7piGS++cftLdKLCGzqNsRnXnL6SaGH1azM2uncPYAcJXkgwMIvmj1BDgp+ oTvRkMNYSHyBQ+83hwSO+L4+EA25GAtPSi4xd7P2dMqz6Wx1tu0TVcaMfUk1myyqalEli9UOfW2J W20+K3AdSbUgwjsF7BV7kRehEFeq2m0qhQmgtlYW1i2YpoiaCmJ2trKQbrFbLtOtjQD2W+lu3YGC 9DiRLhuDiSNcaHfrSLIQsEkWdbYJsyCq64RN4PYWFiC0x+E8kOCCnBaQLbcAKB43VqA/Rw5R5cxZ G4RHiXPaDJFWOIFFay0vBNCwGNEUBNFyQKIWs91il/d1nkQd8ElRjSlsLhW+okXggvAHgbF+sjPM Ab9aYYf5IuE+J+BuNrDjrW9oYuyQi6+kOZ91vMTmS6MyQ2+8cfFGuuNMc8fPDfuD9/jITZBzlDns 9GAaX5vuwvyZS+kl5kstktVss3SJtdNOnA5qi9khkTEVahIp9Q6jpCGqp5+XMcoU9ZhW2Wy1poAB F1vpv5FnilMZsihbi205FZQvQP73m7FG/9/XvXwvfqLETCqzWWN2KPSX6W7oHxkEiBJTL7MOpTrc Xg3MJ4Kaa0UdR8IObnNheUadhJHlqUMUczZUYdboGcibkelHUbkIx7kKhV6FZEF6hATRRZz1gYhy lNXC8hOVNJSoBAd+shtgAAaWD2RteR/atx/mi/qpKeEvYd+NvfTMb+XImTdqpa0t0vMzhm/ffsY0 azv6eXtmDgth/ExkqJ6WpTRlmqKmickDPjOpL8pKIcJowStmiwXzKvCTF8yPzuY+A6IB9LZrbqvR b8wJRbIziaL12+kdqAKcYxq36d8fbDJoVZSZQ1vEvar1oKykTaom4WVB1KMqsIAvylKhCaz5DXAy zpsvWB7m5UaYhfyfN6GJPsAm+iRoS2bxBx/QOzJzNqlFuAvt/HMGbyjJ/BW5HzinFKVeEQXT/QZd xAf8WNdsPwkDkydvy8y5+WaOYwzv/FLOkS/Emzz6se56qcVh6RZ2RLqVOLp1Ayjo7xcd0G1YtzpH Xbe5jjnd6nutd6wpeSjwcGSbw1/MwzjuqcC9x7w63nom/FzxnvDLxQfDh4t/7/+42Dw4QDGl6aSO ykC1xgP/uKuMqA/3c2r4dl4wL5Qu7VZRKVeWDpMvLZ1grk1fbZ6TXmZfiwkS/3b8O+3uV+Gkstaz oCJYlvCFppYsKGElOT2d1c67MCu506k87tzh/A71jWJOH+TAyPOggSoVPrPKKWoinSovgkVJoIR6 6uf2hDZhjhEf85N6RLiGQ4qsZTmSrWSaNo0gCgUVChOIgL7pCoW+MVKFBTKnEA4cw8OLxkkxCtjz J+6FqjUF4kbYNnzOglZ2he4s0vk8l3iqV2pHSqmErAofHyHSe3t4HJDqzffpjhhKXCvbKtnmSlqJ KPqkfhG/YrAwlN+z4BX1sMry1GqVqTCoiJWFQlNDvD/QlegMXyJ6xsQtLEWWWO3d/xwah9RIexr5 Ka7t6s6W2IDH0p9/ziOiY5jRZUyh4XIE2WtvgKHjtk6ERjx44PvFnADSUMgDAl4pi1IG/kG5Iw8Y TEUXIqBA/BDwo8gxmEyhENsJ0IRnv3CSVDVj79wd+y9ZfGmfeR/OouVD1q28LrcpdO2R29Y9N1az BPP35wSvOrhgStn8ObOfSOXeUjP0+dWjV432OR2RgkLrtd0vqG0INdw+Qp82vMfyE6dXX9Cfflyc oxWP6nlp/RVjLvgZhI2RNeBpjqPy+aCN+sNUsbsKlD7KEEWpzmvKY3l5qLbKuThnYd7GPHWAtypQ hXLTkZE6c51jkqsucGVkrvkax2zXtYFrI215H9g/DH4Y/sz7TfCb8F9yj+Z15oXjSk9XT18vpdql KyNdY5WrlQ9z/yn/oNk1v1OGdo3mwAhb/TlOW6jgiI1qNh1Ya6NNNipabIJLbSJZB/iGZ1hENuOE 4CIB6HA+ReOoCFn4Hr0np6htCVBJItiPyCKIKZcKGWujiDQ30yZ6gsp5qPMbg4kTPLPJrR8aZ/Rc zmBUMAsVQQb1cGaBzwxmwRnf41TROKMH+K0pOApLH78FDccu6fejUIHzxSJeZQBQF0EmZwj+B2bh LIR/oj6L8woc10WkAdMky92IKAGcaZhYVYS3F3BWMObP0e7PtizaedWOBj3z91/sn8cqau5e9sLT S5e9gLTWP+8ac9ebizPfZd57lN73Ss3th9468toh4Z+M7fxSaofOitDJ2ZiiwrnSRV02ytPSC6H/ ZE+OzRTKkfFWML/JzJ/fJJ7fBBQAbWCKWPJUSvrQu68JMADzQzAXrk7MhbvEYqd5OYO8g4KXey8P 1nvrgw+zh6WHHE9pT0XsZkfYOpfNkeYqS+0LHY2OZ+y7LXusu+32ANIsf2GSM3+qa4FrpUtyYWrc c/p1vUSuvB7d2ojk+VHkzC3E5cK09bN9zEHXC5xmPtzO/CiMTIEtnQf/BR6qLkikC/pcKqgSEVQZ luMvOGyieaZqlDQ6+UkmKz/JJFSsqXe04mA2suW5UKMyZFH2nR1iclT/2vZFJ9Pti8SzIzuKKUBa 3TH8EwgBKFeLEjDIN7BfMfP3LBrAaSdV7cz97sUPM/9a9NVt2/+UtyO8cvK65566de6ddHXwpcM0 l1pfoGzVji3Redf86p33Dgg7MxQ0+xQyiTpGWqM/ZWWyo9BR4RjsUPr4+uRMZOOtl/kuz5nFZigz LdN99Tltee8qf/B+HP7c+7nvu+Bfw58L2Qvk5aUjXGBHRLj0oqakwNEjMID1cYxgQxxDfcNyJlon OGY5Ple/CPxATzo16pecNpTHRcEPbrzfAgo+VM6L6F2FmnbETTUUeNe7G90QTs4Thoi6PVx2AKHC cHFF61Y5B+G9GjAK2IuAnY+428lHHNvfCjlF43v9Yk4d9xJPwSuoOP3U1GmSOYnGIM8dEywndLUJ s9I5QwqyCdNkEhbIFI5VjD1P1uoaRrWflS8uYciAwTtFqVI7cn/4npM0nn9K9OH6GArZIBikDjN8 zkqa1H/mwZV/WDr33Vvq7+vZ3BF/Yemyp7fesHzLmsc2nH7ycSqtH3cRc6KOxPP2m6++9uHbB7ke HQE9GoOc+UGzy/VgHsnxwzuvU+osNbaZ0jxlgWWmzYxwjr81QozEMf0y3srN4csizwfKD75TEbm3 Z0C4d85FnlGRi3LGeTCPPQcv2YxMy1muLvefYqdCGl7c6HIEg2MDHOmQAjmujdpmTJDS5GiO1UT2 sef4dL4ufdYGacC444UYdJMXEh7UAYv/ScA8aBgTHtEwajTQaNMtRd0qmlDIE8nDVnNhqoKv9Yu4 qc2jeYFyrcCkF3Sr6KIUEr6gjkEpPAjahoBhajkETNTxcEqdrxXr0qM6jiF1gDhCoGsCQuElLNkJ dlUdDcaLYzi0IYpWRXa/S8SMJIvPlBDoCk2IWVuqdOW+0m/3foU3m/j+9Ae82/DMl9Zdq6dv6PiQ jbP3n3DbjdvohOCTLZgpJ+FFgsWZTzL/1uI79s2mm9YMmv2M0JNeELER2G+QOvSYz0Jd4Z7hXmG8 FiL8sP0RxzaHOeIodjSF28JymI9IcSSvItfskOyuHCv1s7TPK0sqsT6Ot2t0enU5WCijTP4eKCY+ jL37V/C1ns7Jq9hIaFjnghLWHRCUbOBVLIKufC46pFT4U0J0uAImPs77+D331ETjOLKWovGDmBNH ngyF99N9JEFO4c1xXfEZ19f4w7jysEyrAt7SjuIDHqbBA2/HHDBR3ObD3BaLSTXDT9KQoCBu1RWl yCV2W4VXk0BSFnH3ubwP3q4CswTFxlFOP59puuvxx72RW5aNnBLtX3bZ4MOHpYc2NMyrGDrR86h1 aP1VG85cDZm4ODNO+hoyweflLNDrbTbFV2or9I20DfGpltxwbqkt5StNVtr6+obbhvommCbZZtt+ sP7T7+yRLC26MHlh0ciijaWbS019E31LqkuH2oYmhpSMT4wvmWOanpheUl/aWPph0ZeJb5PfFbmD AdXfyna2FOd4TcKWaHFApNySNJI2cgRhSytboZcpOTku65D8HLs14C8vLLcWhkJHglQL6sH6YGNQ LgUYyGpKRTVtUCg24VcKxRYUio1PMhRT/r82FBs/i086zCo2NM7ow7lEB5e4aCHJzyt4xXXY9amr 0yXnuapdY2DqhMy4oMUwBQ4zzLAUGKYxZZbvV2tc4XTpkgRXcOnRXeU6UHCYUPMTHddx7BTQ13aI jphgc8x4Hw4KkxuCvIRWuJFFUHW8OJkTENGQUVB1/vysq3fYygYtWbEu5KTLmj46ce3v7th//TMz P9r8y68ffGbFjVu3X79866TIuMKyGZP7Nd1Oqz5+gNINDzSemfv94eXPS91+1/bK27967VccS1uL InxeY+uj0/biZR1tzX7gHjx4EU52odwH77/c55DFrgHBcEXQ7La7fRIwTleOYvKhULjQopf3rei0 0DYLDWCEWU0AKgzgR7FY+riAIIT9RnfzgcO0CQyiBal6sReVMlxULD5OEpz1PQ9C0EJBtNg+hRoY NEYL0DlY0beiKXAiwBYGNgeaAp0BOcB8iGG5nGrowwk8D5CwI/BCZOz8QahU3tCDQkoN1xLFi5DQ rhT/D4ZPiEnouA9eQoqbk9H+S0DGs3EFLFM2z5/OEjYrp+KFItxSwVBxBEVIp1N1mgqdqj1KHWbI JV54kE6vIhBqo8ARFEWyAcUTYpqU6nevbbmpbdmLI1qWzht7RxXcwr/fU/fUIx1T2Za1N1x+54qO lyGT60AoHILfZyKH9CstffkTjLFstGy2NFnaLJ9aTlhMxJJnWYj3fj2e3XXU0mmx5uHdKHiHKN4w oko3IdZXMEtKNRXipWGPy5vlJrlNPiqrbfIJmRE5Lh/Bliwb/jKrQSM7bpinApLJKIHBUmg2HDM0 GxpGvgGNMzy2x7SN0eafjh7KHUW+IftuKR5wcTOxqCEt5jjBkq9raWmR/3r48Gm/nDr9IdR65xN4 s9IA8cwe8gd9CLAKZaBcjpfmKkGzophkzC1SvIQ6bEzy2fF2HJuJP6FNNeW4XRuh0YGM4i0DhVbr RhvNs1XbxtgkRBo/6P04J9iMEisRLNhEZGmD/4IIBNNGsDTz58ArIMALtrDXtz3BH+isVAtPBfEB 0B0OozaQ6lE8LsBTGSXIBnhaXr5WMyPJgGJkp1lzpcwa3gBlcZqiKCvmHMFfSVTup/24vIvMgwki v6YlMzu/b16/vi3lF90/TP7qd7/79w0POofdI085vfngqBlcXsEL0vcYFxubpkd5hAybrU5QJ1sk l+Mfyikgj11TX4zEObB4owHhMhoQ5S91kXivkX5mZR417hXo5olmTxFHO0+0YO1BThE7EmKHfiv2 qDIQTrWf5RKQQu1unWT9mbTU+qH0F9X0jEqTaspUaK5U+1uqHWMctXKtOslUa1khX6c8aHlN/b38 nnpM/cr0L/XfZr/HigJLSWa82hLFllakSMyFRo0l6i4LjbpLKxhW5gkPGTPpzJBYgndBUBcmnYMX gbHkI5fh0hNxER8IIMAU2QgXyFZIWCHiRQJ0aAwkh9e79hayLyjOX5QD2RecTBAkQtZFQIH3jnK5 D9sdf05ccvX5tOaTsXneA84P5qTzeTvn8ulwUJFBB4jH3wwhyi55/aUJZDdXSWKZTeY6RmC6h+VW iWGGBy/+QfQB/ucYn9VSmltpMeO9ESgR+GRXLi+ffHdXXKx2JgTcx98mgdqrBpTuiNS72tm2KyGK hHYF+OqTXZoousRKbNnFaqfN+DEy9lBW/Faej2Vq9gVwN5+vSixwr1O7QvzH3+yMGqejxMvAQDDB vsEoy8TLqJIoy1zXQp/7KjOXvvJJZstKQOz7aVNmWccMlnd95grOl7dg0U/I61/2KEJBgYPamvv1 NwquK/oY6169jbXxHsM2vRDmxoWisMeVTxV5DBYnFClPWYgSuU4FbzbkbxEzFDy/klD0fng2jxPa hkCTna/teZQP2nIZF4BAFkgwaG34Y3hPHajcpbLQ6OxKmmZ1Fxkt/1h3gVSLBBIKL4yrLL7F/3jB 6i2AO418FGyomoLPlKSv89p8o2oJWLLRgEi9r4+yOSoK5WPyMcufg5/HlT8op+IsaI4nLaFo3CJJ yViO6ucuhYmqSczWsx4ppBsLNxeyQugxZ+FGvBhIFjEbikxEjAawjrO128cZGqEZ3qrE1bObcaZ2 CzUGtxA2FMeMuiAev2XjGFqn20OFG/FGOnG5KDfO4nJRcTlsf6u7+eWiwkpGReiNvRnDOEeB8Kg1 2Dbwv2grrhcgrDxZSI8QyN5mwvIwEXcM7BX/jUGN8+VPaFwSEPLHr5Ily0ndJ5xkYUYA6AuRLChs pcubf6qBOV0wN+dYV2E0SHIe4IeNDpHiAj7DnWd40EKIIa48fdplqJGyS/ns7ij1OPxdhjobvIC+ fu49I/+EhWGuhR99vuHeUvbM3GX359305mPPNSenXLjw3pZJM0auGiCnNo2eetWkfTv2dBSxR6+Z OmDTUx33s13Ll4996O6OD7iscJ/rOPglQFfoXkVSvWyr1qr9RfrCe0I65VVhS0/oVWCY6zT6gHYk dDTUGZLjZp/TF/DA56JqwGF1OO3OgpDws0LC57IJb8smvC0Yuqy3ZROm25bPiSmANuFt2YS3he1/ GwS1CW8L26cw45SbPuHQ2WgnEhujkbjDZBPueYVOhNjC0OZQU6gtJIcww9MfELJ5Ci/6MiTvnAie 73AZInjO4YJrDjE0HC4D5+O38PzUgRsdFFPRhbzxhUgVCHQXqun8P/4CQdCZ2+CzXlhAdVusZqsJ Uwe0FPCNKHVZPVki8yk8UKd1DYLKWSxXENYg8donln5cv2WsZm3pNu/Sxc/Kqft3DFk4qmxFx2K2 5tr5F93zdkd2nt9g4AdFoKODhOm8PXhXKTjWy7MGvIGKsy/1xbwVFgc8JmvYfol6qXmCWmuepc4x myu0AZ4BgT6hIdoIz4jAkNAUZYrlMq3OUxe4LDRfmW+Zoc33zA/MCP2M+i2q4rhCQrLaeoX9Gmmm MtN6jd0azJFNbigNX0FURD9RwQgm+GYGrGMSgE4WDOR2nQscDp8Q/RMNTgnR4GRHo033FhRWYPoC MWmmOGCd3p9CS/D9wzicgLazgOAVliC3mFGL1zRxg4pOYClghKzcCg3EXz8ISuu4JFcIjPSOcFhB ZJeyBGwHqFCHlyyeo6eAWduhbDnmww2X5XLlcstVylUWmVsnfqJXvOAFb+cRCN75YdHgp2779Uc0 cMNfb/80075319o1u5pXr92Fl9oX3bks8+eOQ3+9mcao4+233v7dr996U2Dpa5FTSoCGHryf5ir9 TrvWXbtAG6HJ1fGmOMuLl9iTuWX+styLcxfGN8bNA4IDosODw6O15ivsU4JTonPN8+xztPnBedG2 +Du+j0MfR96JHfMdix2Nd8YDSTmtpf195AEaqmS0ydrntr/mZjSb2wkIiEPoagAQOnGGC45YqWbV rfXI98pxQcS4ICh8t+N4pxNG2ypIiW2uy7NvvuLUFN4dJyIaX+pJPtzWJdRbzso9hYT8d+S8CzAX GjkLmAvA+CxgfkpoZIGtG4C5qC2DmgQz03AeAHN6fnGNoYwBmP8ULkdkxGWS69sutNzbpVhRcCVe F1HkxqtGzqJ4a58acM/sdUfmLv30hsl39XA/s2z5888uWbwzM0f5xfpx4zZ0PvBk5vTtIwd0nJae OnTwrT+89eYfOY53aWaOdBQ01EgO7avfaWNp1i00kI1g19nVan91eER4Y2xzTKnwVkSrY4O9g6OA vaPTvdOj9bHG2LvqHzzH1a/sX4e0EpZvT6Nyuo99GBtqn8zmsA/sH4X+EvgqfDx6hrnwjh9fBDir U/UBlyPOoLMcL2vSjrio5tJd9a5GlxwTYARel8QhAgFGQA1kUVaXACNcAozAXhhTTkpXgFs/riyE LyJOrxb6Y4n7P1HWAi5oHE3FUuAQJiFiJoGam8K5sR8jEP8FYe04yUOxnxAGb0jFux4FGi4wI0AO P8JWS7vdX/OLzHcL3rnp1w1PdCReWL74mR3Llj6J9LJ54Gjag5o2Z2555s4fBknbDx361evvvvc6 RAt2bjWI8xro4iZv6AN7eqkm06RcIQ/Cf4BytbxEVi1us8VscXjdFgfB225tQiiI1VK8EXO68zFB zcvy3f/n+P6sx/e97j4vvkehrLBG5/kVgot5qhvayHD1R3su6cogCNUjQnzkB04u4jNlOdcipBfe QiXeyLHWKSZZ1C3iM50Nz8DA1TDb0736iQvnVF9x5YUXXzzwSl9MTm1puHTAs0WXVNcv6njXGIdq 5AZ2Yhx6SUH9Bjnflz/AMtwyuGBC/sz8Gy13Wm4teMb7fOkByWEJRkLBXiNK3wsqUcwbYloZtYam mKdYplin2KbYpzjmmuda5lrn2uba5zpaUi1FLl7SWFDSt2CytdY2IzWjeElyCcqKf259xH5P8f2l m3o9Zd1mf7LoqeLm1K9TASS0DY80v6uR7GoUdDXEOXycxDm8Ic7hDXEOb+Qi6NA9scrJ5qJCu1WO xFN+2dYjN8LTQfnhUj78eeHq8Jjw1PCO8OGw6grnhReEPw3LeeG7wiz8C1DHD84QqLcOz5wB7MY0 Gw3/iw2KYTS8MRcGp9kXqOBrnc9Fo7THlNxrcllujt8E74gnpAVAwadFAXHgatLLtaCc08OWh4rV grDuDVWU8Z/3FLit8HO5HQaGC4nBMs5/GY7zX4VFABkWyHcYyexdpoJu+OnunMoj3Shax4XORcOo 6hYNPg5ofL2Hi2q3iLhVAjh8fVlbGasuayxjZRzBLyDintlX58aNUUalBW/wDvCG8Q7XeIFLKGGX 6J4rLjQID2bQRWgJMRMrCzfmf9oV3oZ7Z2F6CHoWmuIvSNVQNLvo/2vsWsCjKu79zOxm95yzj/PI srvsbrKbx25CFg1NAjEQyUlM5JFqIsTIIgiIqAgWaiL4oLh8xQeK4OP7EB9XrPVW7OOySSAEsELF ImKp3F7EFqvFirforQX9UEu9yd7fzNlE7OX77s3m/585M/8z55w5c+bxn//jytxGeDL5/fPsTfAc MB9B1PDp97EvxpkZtwlhWh5gcoz/3GY4OBdm2UWFJWAAJ3TN0PI1m6PYEwsTudwZpnkXARX6cFjk LQmTYpjKlMaAxVFeJiuOpB2m4LUCPt/iho7rLcRXosmK5Jo1YIcN/3GLQtAuGrFcWZYog/+fGuyk 84n3+UK64I1y3QTeTSUaetV1d6+6Y3z88QNPtjVeUvHozB/8craecXctXnWL318ZXrv3ic7FB37w 1h/opZElty1qvrQkGK+atubKKXeWR5NT774pOGPOjNqSSEG+UlrduGrO7C3X/Jz3V6XZz1lF3pOw kwYdawVtsCTB+R/YS0EkDQOk2GRWqI34NVgiUzB821yqVgwlB48Rd9OsU2qRW+Y7l0Pz8xGnnWD+ 9BxUQPc5jzjhIwDMZr6AQ4SbWBaRz4WIBFL4ukyk/F20NKRw1qU1M+PjP2Ki70KGNbd07ma3QPpx Qg94Fd+wKfEqhVFtCHid5L08dtC4HXq80+pqYVUIs6x4gNdfYjzfIdBr0ZeV6MLSF9NC362/funY tWv7duzIT5YX/miLNnnR82zheupcOvTw+sHHrxgLM59Y56MvO8H9n9G2XSSEupGxgmexfD9XsThj Vhu+mmQ+LZXy/W6a73dhf0VHNZFqfzwY4MuKkFizBMRqJWDwbhv8dyw/eQ0ExGpFsO/FOiXg47WA 4xxXOCAWnjj+kouUO67OBui+AA1cCZNrcHXAlyihMyG2PPRcKBPKhuwhsKZ5jmANcyvRMfmIfAKO CYZZnDxiDR05rjRWKhbX2WIKy2KNIgumsHzl6G+xBjBgcFXoJLeW9c1fPTfDjsG13ho7BPsvZNe8 HtXD5UW5kQ0sSOzuMPFIusUKhP0MTI5QRG5/swwvBxz/gNgrE6xBW8Oqt6/7cZvm2u7Sv3fVVRsm bX9m+9Rb28Z3sccG+x7+zpSrZm58gNVxtineD16S7RTej0I/yckOBPIkokgO6hgRRy7lDTCvMnm+ VDKfpIV3js+jpFivU3gP79HrZCw4aySOIMT7SR9CdMkiBMXvTbmwqIaUA+HolCmDp0P8QDg6bq4u vxiWBIBU9xhSDhX1OjJemUqmKJ2wo5SSZsk30hvZYmmxfAdZSVeyO6U75JXK/fR+dp9tnfMB6UH5 X8hm+VHl5+R55Zdkp7NHeYP8WjlO3lb+Sj5UviZnlbF4HCVI/Eo54ea52giYaXmm4a/JQ2OqyXHe YFmb8EcnuKezkB5EZ61wc+iYB4DvyNPEpJYLaYtUlpfndqELrHwvCYltwOHk4SSpHBHarlXAjYzL ik+WFWwWgtcopHnzoB3OdcW5UKcTYpyE5lVCaLFYMk3T8sVBwztMMLVgrYCGTTnGTFrs+uR3/OuF 0ufg3MG5oeCnJ7mWBj7XuhHJXF2wF78RvQXbEF2nkE/6ps1ZstNCVBYysvTfhpa+cjIOmbO/7hr6 nj0xuPamZR0r2AOieaB9cNnXnWgfhr1gWF/Z4DNU0QNZYmECo8KOChPLGF2hfcCNLesxjpEB2S50 ZcjA8MpjuimOFd1GYeTXifpWUR8et5AtdMO8LXyy6ULwL8eEwikYeQ4f1o4d1o4K1eWchLV4Pv5o /IMI4yv00Qr7GIVN16/VN8BSLoZFsdbhxnzFwG9FUOwZU44W1WgR6IThsz5j7oyW1tgdbjnfEZZH G3l2Yne4oGctGRqBgxFnRAq7CrCWjTsrpKS3hox3TpQmeZttUxym8wqp1XWZOkWfblyrzjCWwH7q Tcadjruc3dIux2613/jC8bVc7tLLSbmnzFuulhmVvktIrbFSuk/abHvC/SLdyra6IDZD+h27vQfB +/6DfMp+Sv2LcdbxDzniEhpgboE1gb0CqwIbuYYbVryq3SC65ARzXI17+XLO67R5qDuOPf9jZi3v qTxofxU8Ai+FvnyH4tITSlLvsM9Q5uhL9VX6g7qiK3a0Rv46rBfDJ7fnC7NXQtnaUqOBBCV+1gwA OGxik48LuTvzIJksYa2iaNCJG8i2QrbdwLxlmnmjonpj+3UnTCTohpHEbiA2Zrx4z3GP1wdtaQmM nqQiQQBa4pLvuW8F9uechl1SdbfXI27PQF/OLfvwj8eADp2XKL4vNQ/lJkTSHptngL5oKrE2hS5T 7uHy0OxqU4al9GX6PTBdyI9cWh6dL3jGUKumL+6gX+Z/iYERQrijrzg7d24QNhPwzz+zucELS73n vjvM+PH1/T+E3p2QeefAhXY5tGaiM2dt98TcMfYyzDRSgDd7ZDsZp8ag3HRCyEkLBYjWTM1M2GGQ skd6nNyYbao1UwTJ6mohDi9lT/Q4Y1aqgVRucm0XL6gf00GUjf7qSK9zHC+xl1zCuEFIXGmkcFEa Py8gztNh7kKJ2WPcxruQqBe7B97s0X6jjowF4APvyeds/xT/4MQ8EFr3iAlNby59L6Tu8wNC9N5W ZqOtQ3t2v9Rgr35p15bxl/ZvG9q+56Ux76CLefqkfoh9b3Dzm4fZjV8fZ6t2/PdbYixSMRZ9hr5G o3/MjUWjVOpywGIHRBc8aJOqmJerlVD2562SW+kK71QNqkLUmW+ImO2j62arm+ybJJgJU/fl7XPs c76pyqrprwvZ8uVRnpA2nk50raEbXFKlcY095Uy5ZnmfoJuVza6dbMB90HXI+xvtuO1t+d8972of Kcbw5+VyE0NXgx5ML3CdU9jsRkx1YP+XwC2Mg3MTuVEh1E5O3+ZGeAxyQkqaQrqfC/pjVoZR3UNV 1aPBFAjmCC6bW1McsNyqaAfIAZlpOedENuY5gJ2puBv7lG4b1HZgEtgB3gsMnCttBjWmeVa7ixV1 gUNebULYP7zTdLQ70sIk4GWmN2ZbzYrb0G9P01eJBevcs9aAgfFC+wg2/oV1Cj7HtrQ8hUx5bsDg LkW4qes6Vb1fEu3Uwq9Jr/HGi10qjCd8G2q7N1hQB/bv+6arAHbKA7BmHhDH2GiCAi30sUbVUQij y1DzFG0FKCVYqKifuSkMOtWYnU+oreV7RbYyqtK1Q09+8OOLI2Pjfe8MPUofeu/4xKGPWTkdOjdl XFP110Puwd/S6amhuXiuIsib/A1tJES/yrWRAsWnwtFnZLRqOFyOfNOA9IXpjuXayujKZOi9UPAw Nkl4IBbr0F9Aw+lTIxT90/vmrZG6cl+nuk2Buw0TLyRWPq5G4wjmGQ2/J2iUucrcZZ4J7gme8d4n dVe5UZ4/1Z8yUvmpUYuNxfmLR93pWOG5U7/Ld9eoez0P6uuN9fnrfJuVra6XtT36bt8nyl98X3gG tXO+bKRwuEX5oS4QtqvN6lqIi4weuX2LmWApX3LVoVpoCkG5x8DsYbQvPz9uKD4cwOGB7o67FCyG FagRuaEYwp+fRLQIq4zsjbDIAGvYoaIuTN8A6zBdDYZpsHnGXtihGKBN/SotJi1hdI0dVm3BJNc4 d5vb1u7OuhlMRDb1VUIGE2VsD8dWoWtE5Q1y25BoRNw0ZFA7e3I09wnyaQhKXiIGsxNYPvB2xVsU VwsZ2eDkTQqdHtoP+j0v+psg+ps9sDpxiriyp3j3lWtWu4gP5gtq6xRY9oGw+qkdo6AwbCkHo/Wg r4GiA5pPfhnn/wkZ65zGD6YxmEVgoXKPb9LY+qkBPZHnGrr11feSxdHkh9uHljaWjlvVWTN000ta eWl4iVpgLx988vY1q1awJV8f3NaUmsnnweXoe46iXXnpNtMD4/hvSMygVZaKz29hLShQQydj5oo+ 9VVzOiJjWLlcqUEqXZlGL2eXS9PkNm0O7WAd0my5XVtKF7KFYL7cTbulu+WH6L1Q1jtHz7LwaClB x0hJuU76V+kd6uRfy05tVA1DB4tpyFGzBMtpNlFWGHa645RB3YRRbiqULeAqEg5lgYdgPD9rymI8 T3oVaPeo2zEc5jn2MGyswn3IWVPslIHf9xyUTLymd7437T3jzRPy/2AIQqq2myirKd1GaBv8LMHz KxFGvshoVesu4t0Gl13I7WTD49v3609C9YK/3EHOCqjXPsJC8SMhbMlfNnoP6PzkDMiACc+/eHQS O6CJDHW4gaxVexKvSxy9upPXIq9KQQgvFEIXiI9x7/eqQnfFCk7tDGPv2R++lE/PegM8B+qa/jqG PWkW8n/TsUC9xVFiqbdMqC4aVc5e6Jo11Ga7YfBXy+68hf7XYzbJ8djKwevulp/m7xmv2X0488A6 /zy1/gspLCGBkINLbnp3OOSSJNAW5Kw4GNvhqfhD6Jw8dCW5TCP/2DZUrU0cybHyCWlzIIn742Xv kOvsXVCtu5/MBs9qFQdbATGR91PEGxHu5nSguRrwJ0A9oBMQAvC0KwALAPD7TK4G7S5+rv3nZDmH vM7sYF4n2ZT3OrkR8Cziz9s/JFsddeRWHL8A2r12Qmo5Dc7f5Pgp2Yz0Z5C/EGnPIv4jhHNwzrhc XHY+DF/lncSBtDE4/yFAmb0r+wHOnw64D+W1I7wc0Iq8fIRNgPvp6+QB+nr2eeQjJD/Ete7n6YDm XDgVz3wv8htwXinSfoh4CNd1IFQBRQB8e/CvPgFG0ufQNHyG+9hato+dhE+sifag/b68ZxwPYrod xEp8tvKC6xXXX93fdW9w/86z1dutGmq/FtS69Xp9n1Fl/CT/VZ806ll/d8AbeCx4MFQYWhGWwq9G /lzQX9hZuL7wlcLfx5qKqordxf9ZcqB0efzmxESwRc3y9WOUiuKkI3lq7KGLNl0cqvzbuPR32qvm 12wav3XC0dqD4m23oRHYyEJYkWLYOagknXiHHvist+GYtxAj1yYcsIFCpl/Z0Tm7Odl42+IFS6/o EBQgypZxG2YX+GtDmg0lY+EJ65Xcn/2FvNlz39nf+LEvIud7sD/ff73lvb76W17rLZ/1JmkiF/RW j933dnjkngFfxh3wld4Jb8qzSAp+5q+FF+a5PR1qY7EtQE4DsgAbiQJXAtoA8wAbAVsADqLmUpYh vAewF3AG4CCmLdD7WLU5gOAhEfTdsrRKHC6wDufMFYd916Ss8IqrrLB5mkU20SL7To2VfHGTFZaN tUIjXpVG4X2Kp2pfI+SmyREAI8uBKXsNrkEovEc/ZxtFMgAGUV4rxbQZfaWJqi17bXYCxT+sSW8g 0ew+G+316FWNCsuy03i3UfY39qmVwz7t8+pVWxqnsz+TbYC9ABv7M34fsA/IPewEGoIG3ADYAtgL eAtwGuBgJ/D7E37vs/eJyt4jlYAGwDzAFsBewGmAk70HrLE/8mYlMI83ABj7I7DG3sVjvQussuOI HWfHs/vYf/TW1lXtEpFkZS4SjecigXAuYvirBtjves+NiQ6wD/tiyehzjePYUZIBoC0Da4AYoB0w H7Ac4EDsGGLHSBrwCOA5QAYAHgGwBoixQ4DfAI7BwsYx9HrHUMYx6Lcf6cVlBthbvYmmaKMfrtFf B9s0yg6zgyL8DTsgwjfZr0X4BsJC5B9iB3oLo6TRhXyCczSEGsJK5OexX/WVGtFso872opKiwJWA BkAbYB5gI8DB9rLi3huiBgrZQw6hx4+yXvKxCH9CnpeIeUvUTFyGNhbjKDHxUsSAtsS2JJiZ2PQk DjlKbHgMMY4Sa9cjxlHirjWIcZRYugIxjhI33IIYR4nZ8xDjKNHWgRjQAHt2Z2lZtLZtCY01qmwl amklamklamklDJ6v5D9yDn1ilD3dW1GBGnvKTI6piKZ30/TLND2Dpp+n6UU0vZqm19B0PU1fR9NJ mo7QdCFNmzS9B45TKElTc/u3DuvMIE0foulf0HQXTSdoOk7TpTQdo7XmACvqnYYPC0GLCPoa+XfF ivounVyl4h6LUKNFaNZF+Oz3Ar8FyIojE0SxYot4dCEPi/sqGqzjiydWLWucyvbjxP14DfvJnwB2 vKD9aEb7Uch+FKcCNwDmAfYBTgOyAAeoi/EcGwVWgSsBDYB5gHsApwEOcTuncSuMLAPmt7hN3Fgl cAOgjR+x/fgV41fEimD8N6Iltam2jZj7F9K2wmwhqyV+P7pfQ5fgTM3T/5Xn7195iNwosw1sIwwy R9kjuXBj77kCeBDa3JvYE20cRZ8ghZA4i8J5QoLGEV5CusTxeBKReHoNibCfIazqjXTiNLU3MRau Frz8rP7oucjJ6MeYpSN6KrIn+k5swE57o28j5Wf90aORddE3KgckpLycgMmF3ujumCDdFbkk+otD gnQNMp7qja7mQX/0B5Ep0SURkbHIyriuC0emGp2RmB2divKaI9dHzS6U2R9tiFwXrbeoxvNz+qPj cAtJK1qBmx0TERctKRQFXl07QG82xzo3OWdBc2eCs8o51lnkjDoLnGGnTzIkTfJKbkmRJLCr7VBw JpKPy4Mn+Zjoc2g84IM91KBFXEMPQ8WAyPs1KkHllmTyba2sdWYTTADsW0har49lvpxZMkCVq2Zn 8kqaaMZoJa0dTZlLkq0DzuyMTG2yNeNsv3ZWD6UbUkjNsAcGKPw+D9AsT7o3zL2yQ62L6vc+HOZh +b0Pp1Ik6F/REGwwJut1lzdfAM0XifObh1esCDETHvkLJgsym1pnzsr8tCCVqeKRbAHYMY9zt+27 6Of0TEvzLvoZD1Kzdtkm089bZvB02+TmVKp1gHYKOhKjn4EOLQYB6KRCEuN0JCYVWnRPWXRxnA+6 Uh6ATpZJXNDFZVnQ2Smn6+kqbWnuKQUCTSBGugRNVyB2Ps2hOGjiQKDxp8khQXPIn+Y0mcmimEgE JIVAIKEhEhEkERoSJOLOewRJZY5k3QjJOnElm3U3goYjFOM5MUzjOQGakWr8vyKLmsAj6JuUWjin BS7v55e0LALMzzy04uZgJn19LNazMMUz4Hk+Mf/6hTfzcMGiTKpkUXNmYUlzrGeSOO+fsufw7Ekl zT1kTkvHrJ455qLm3knmpJaSBc2pvintNbXfuta6kWvVtF/gWu28MFhrivVMEef907VqefYUfq1a fq1afq0p5hRxLSLaePusHok0pbBGEmEfjAWgvc4PF6Wa/NryyaLxTioKrg7vxoRkK3HBFb27pCnj AfB2fVHjRY08C98Uz/IiWc1lBVdPKgrvpltzWRqS9ZImkuy+vet2EmxZ3Gz9d+EPSd2385dh4SRP u+AfSFoy5oLmrm4C0xsVWL83YP3e43QidX5zCmkTh9NcrhasZ63Ei5E4kRPabCOEPK2ep8lyjvB/ twZxT0gW3Mc029NHzULaTbpStkxhawdDV9AxG9UA//a7MV3ig0QXhLy6u6DQ1DVcGn8OwZlEAsEj dw1D9+25WK4eunOhOJGf0jVcHcNFJXktkf8BLF89NgplbmRzdHJlYW0KZW5kb2JqCjg2IDAgb2Jq CjI1MjY2CmVuZG9iago4NyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5 MDUgL0NhcEhlaWdodCA3MjMgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjY1 IC0zMjUgMjAyOCAxMDA2XSAvRm9udE5hbWUgL0pOVFZaRCtBcmlhbE1UIC9JdGFsaWNBbmdsZSAw IC9TdGVtVgowIC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAwIC9YSGVpZ2h0IDUyNSAvRm9udEZp bGUyIDg1IDAgUiA+PgplbmRvYmoKODggMCBvYmoKWyAyNzggMCAzNTUgNTU2IDAgMCAwIDE5MSAz MzMgMzMzIDM4OSAwIDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2CjU1NiA1NTYg NTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgMCA1ODQgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjEx IDc3OCA3MjIKMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcy MiA2NjcgOTQ0IDAgNjY3IDYxMSAyNzggMAoyNzggMCA1NTYgMCA1NTYgNTU2IDUwMCA1NTYgNTU2 IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYKNTU2IDMzMyA1MDAg Mjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIF0KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvSk5UVlpEK0FyaWFsTVQgL0ZvbnREZXNj cmlwdG9yCjg3IDAgUiAvV2lkdGhzIDg4IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjIg L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago4OSAwIG9iago8PCAvTGVuZ3Ro IDkwIDAgUiAvTGVuZ3RoMSA4Njg0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1Z DXRU1bXe5947wyQzk7kzySSTDJA7uSTE3GBCIpKBUSYkw48RDT/ijDQygQST8BMQVJRaRmmerIFa KAa7ut5aWltf32vt4mbS6gR/SF2V0lZf0Yr6qvVR9NW+pVn+Ilohed+5cxMCIo+32r6b2Wefc/be 5+zfc2dOiBGRgxIkUnj1+taN1EqfYeZ5wODq27cou29O/RsR201kqVuz8Zb1t+XJw0TWXxI5a29Z d+eax1oCXxDlQkZydLS3tp26zr+QyCdB/soOTDjeFx/AOITxlI71W7YqvxH/gHEcY2Vd9+pW6Ydi EuMExp71rVs3WipyAhhDhpQNrevby/IrIOv7GcYVG7s3byE7K8D4OMY1G29t3/h0ve92osI8Ittr mGP444+DrMRlFLrBnDGmL7kRLsApXmDu/zIlkeUcdus5I6IJVo0K4ecjpJ5HMYbSNZxKNPJHo33H aF8nGr5t5C+IyEz0eNT+pscGaQ48fH/T8zNaDk2vHfkxVhmgFvTnj/zgq1dk8+kjdgVzsBn0EptN J1k5QllGRxBObvMZwFOYsdNvzTUG6L/pR3Tkq1fkFPYv4+msHqsO0GHqplPj543+T9FyOPvcc7Z7 kd7DtNGkfj+DxWmCBxl9iPqpl948T3IAOz9Ae+kgy6IPWamg0S72FMult+lF2ka7hCfEfyJUG7T8 8vMmVtsJ6bGHXUanWILq6VW6nqZTP/Ozdnqe5WCPd2HpG/Qu3UuH2MQxn5mSPL78kUj6aSajMuN/ QLsNvn6OVl/6yqycicz3VfyojFLUh1mHZ+3I8Eumt0dQE8g3oz6M3uwMHfmwATkwE3tMZPnINRsT cda9B++/iqwYoD30TdrK42nwXQ4+BT6VmcQE+hxe/YCeoe+NcrF6rKoZWX5s5MeslKZi/NzoThfH ljXc76P1bCPo8eLZmrMcM+s8U+GfjK41/KHRe5wep7/ScXqf/p3J9DhO5lPY91nk225EfTc03Ear 6GPGhkl8FnY14+8ij2WihVty7rONHoD1vFq6ocub7AXsdKHnAeTjeTlubWbHzqskol+gjh/GeuOf x8YPzP4D4lb6hK45h/I27HlReIJ2oW7upQ0GrVt6WBrALhWZv3B4ycIFodmzgnUzr5xxRW3N9Oqq y6dVahWXlU8tK52ilgSU4smTJvqLCn0F+d68XI9bduU4HfbsLNsEq0USBUaVzKf7GqKRLr2wIa47 1EZVVnTHdR8sqtLJ4w+obqW2KjbN5NItmk65TXpec7SPwnUx3aqdz3KdLpbKHwUgvMivRHSpFB/1 mtY2vXxJNKDKr/jH6DEsqxc1RAMBvy6U4rMQJHyuaVXadLkZ8yAYMwt1ao5ySI+cqMMk1QViaJdE 9cmjwxhfLWPKOCVxmowMnqfmdSwp9zkKGxp1yusjxwmdvJztgzrSKaSXa1BERs9Yjap0lveRznJ1 5l0Ek87dgosdr7uADyJtXWqkrRMebYuf9ekHGY8GlKSSXBJ11/oDAUPpJv3I4mifPbtBbWjPhhVk TFBfth0zdj6BsGzsY46rmdERHJFZfQLZnHCfh6sb4dClh3fF0VEb4TdQcs9S0iODu8eTCGIZJgKb 0WPGnrq1QZ+QUULp1MOtOu1S+ioHk7vTMq2Ka442ta31a1FdbIVSfSSWRjqW6RObmm/CFJQAxDsU Hu5Go+HBUyIdShJjzhtHqzZC9Nz5to72OE8TFlcbQctqiN4XGPTrHuCI7tZ0J8Sdd73tF5MRX6fC h8nkfYr+8OLoeGqA8yAJfNMqlWRExW5YLNI1l0esaixsRjYubDOCE97VquiJVV3wGT6tu0fzP5CU dcenAUQH8YEkrw7uYA5t8S5uShckJSAluavdMHW3YRryVYl0NXLggsh+ugHSN0UjHWoE/jQ3hEMg L5aeLxsI6IUaF0wmI1zF1jZozz2DT6FmqJEZoCb8GoM+DXp4mYFomRED7BhubYyZUyYDKBLioIfj jbEYNyoTAH1C6X2Wy1UlyZefUKrnaXLgl6ANTqtsWhKNNPLsBKfQEL1qyOcfQr+peWya+cCTrBri TuKUpWrT4kwWdHD/8Ca+LFPA8JoZebCa/MaqL/j8L0B2njovnkzOU5V5yXiyNT2SWKUqsprscziS GyNxxah8hvmDu/z6vN0xXY53sFkIMs+3eUua9NzFK3h45ikdrZjBZ44aqPMH3Fg6w4OT48Jks86Q 8ch7XmdJ+T1Y7MCJ5Ffm8eMljVPBr8t1vEyhyQ1R1MFqbBFpMxrUx1Is7ueVIsZKI51LTQf5A9jS SBh+7i02Z7FIIMBraFc6TKsw0BOLo5mxQqv8KQpXaYhdnFMGRyneGzglMUoZE4+riJWvCfsbOfFV OY3zfCyfk27VowT5YQ7t8FnYpg8ug42f1ek2eMwId25DVPQLnAU9wS/yXraGV0JIL9AMQe4TnJJJ WVWOqrqs6ZaG6KA/FFNkNw5INpYM5oo8TeWj6q8ZP0QpT9ZZSGf5vKwIhyrciEO/oA7EMUElkoyb 2TfePrBy7raOsTrKWIHC5UbCDbKKuvVn/OH2qNzU53m2j74VSufxokJsDI9dE9Nz+MtOz3nPaGCc vyGq4BhC2S42OkpE6eBR15V4o3EexPycPjqdHjkeb+TnXxSJBha/md/IcrjNrAnTDU3LoqO9JdG7 /XfFpqVpaWVTmrLwJmXs/liajfSkqXHSAGWRuPJmkJdVKkqksxEbYnBDJSYqAugtr0Ru8tSPqjH+ JlnYllR48rfBLAOD0J6MVSFfl0ZxXhLqUA/H/GPd9lhsFta5ka8DEbAnY1ihy1wB2JiqOgOmaGUT Tqqy5igO20QjEr2RlzDMHURVDXKLuSGxMU2h8d2dPlPnm6BzrAL0FZlVkKsJLBFLJvmaS6Mq0jyZ 9CdhhzlOMzp/ImxOpImLwPBImiWaIQukGt8PImpA5Z6PNWKrr8Hvo6dUmlou7uGbx/SG5Epoe7Ph 4fjfycOtl+LhVZfk4dVjmp7j4TbovJp7uP3CHtaFsov4eLxLwxmXhi/g0jXnuPSWi7u0Y0xRaNUJ 9ToMl3b9nVy69lJcuu6SXLp+TNNzXLoBOq/nLu2+sEv/EUm78RwPb7q4h28d0xtKboa2txoe3vJ3 8vBtl+Lh2y/Jw3eMaXqOh7dC5zu4h+/8//PwXeM8TIRfPfgtza+kRJpAOISXammyVeEwBtjkNNFR AB+jL76BPrAELAJb3qCDxiXRcghJ8kEScN/G+4JcPT3gDrhL0TBwnA6LidMJC31BYSkBrk4ithe/ fPme08I+6YDFxQ6Qx3rAYhUswgEWtmWxAzXVGivyyYuGBuVBeYjmDM0Zml5di1UZoJOVD7/Gf50O vyaW8BZmCPzGxHIa9wM2yqWu8IJVdtYts2Zpo5SQ9kjSiglsmchWWJlgZR5ryvqsVVzvYk77JLvg lCfJQpaUtZdyc/cy0bnDkrWdwl5Lt5BHawXNVGRMC7by5paWFmrZhBYPlFLILVOgtLbG475i6uVM YwPC3SzKNgx/ffgHwy/9+eP343MPpg5ajgzvG/7X4e8Mr32JOZnn5W+18l+5ArWMvCP14t4vh3x0 d3jxcpn1uNj9uSzmZfd5WVRidsEvaEKTIGUXlGc7F0j2PPsUuyiSR/YITgt5fSx/v5jvsrt7s2QH 2X3Uk5O3wxouyukQCq1rzhpw5uggzZkzVFNjwPRqbgitbNG4OXhYS2CGVS0RZsie2poC7uoytcTq lWtrZorrbj15+MTIq499i102/Orau9bf+9o3t/7uL6xkmOWxBTuF5s+PidrWl/qGD/CrK9i0HDbN lFaTTF56MDzF7WT1zsXOF51/cn7otPRIrFd6VBKKrMzq8+QvmC/dKAkivk+FizwFC64R2V3ZzPGg y80OuX/nFtzunDz6rozfbmHFlbtAzvmukJ/Xa5Nll4dliZ4ddod7hyVsL8i3wFTmkw8XyYvOPCcP wTiYOzTnzCvakNsTrGrZhAxiLZs0atE2IXibSq0qAncF8bAFPIGamSwgqyXSzN8/PTw0/CxT3//w zTM3Tmaze588s5Qlf54uvZrVsZwRNnP46PATw4cj7J/5xSTjecf+hPiJNDGcQ15GYg8y3UI9YzkM r2eSd4CVW7XPj3EfMbp25B3hfUspsvX6cE22jXpz3b1Cfo7Fbum1uZwuq2R32aRcV09cGpQEVJik IJf34NpDl45LNgkGnTmM4hiUD8uHYSh6sHVIfmF6NbeskKkzameUemu9qjsPIRTe77pqePu2baz8 3XcfLZthLWYdwtyBgZLXB878129yuD4cdgSfeb1qpSt0kvltXEs6svYW4y7NwNDYchqWMnw34/z8 AZ7w1DDul3Dp2HxqtvP4GCVDx2WyFVMCbn7ZX6nTGqUByyJqkXRaLnyPBsSr6VowzsLfGnqWVbJH 2DMCvxXn69toPXLpepwTDJlUjVsgkpLOWng6o63HwLj4RuXQtdcvumn5cu3a21Z3trXOv7V1Q1v7 tLnd69qwjnmTP1JHfPTlh5sq0iTc382nBdjvRqI0bcJRdgugBbBUqy+h64Vc7LcSbTdgO+DbgIcA OEAFD8kABVAN0AEWwQNaPvkNXDgyyN4I35ZlD/7n8fyCiS8fQ7Pt6/n+bV8vfPEl9G+/A836jWjW daNZuyHfv3JD94btG0Ray9Zu2H5r0Zbb8rwTb+lCs6YTTXtHnr+7Y3vHtztEapfblXa9/Xi7ZbCd tXf0bCoq3Jx/V0Nh4E6AIAwI+4Xen88uHh4RtDQT+oHC+Ir5eHZ28IPeCVp9jjBbmEWzqVhQhGJ4 UxPK2Bl4RBsZFCal3O7g08IkYaI5MTFVVR0cAGViqrDI7LhksEwckylK5eYalKKUMweUQlD4qvns TMqqZddXs1eIsWPsJURGYy+b+PcmftHER038AvuVwfe8iX9r4t8AQ0f2axMfMfFh9quUpNnrs9hz iJcds36AMHKU/TJ1ZRB6vYJOccDs5BVkOv1ZOUHXU+weKgYITEvtF+Gry1J7OZrav9fGXVban5Ud BFb77Q4DpzBOM3+qN1CcZoHU3mIgXwZJj8O1X+FxfpjN/rMnN3jvPpu2s1fS9u5jGt3P7u/N1vb2 itq+XkH7bm9N8UMPsqP7j+//YL+4v5dp4d5CfzDcC2enhQ2peyxaWliXOmTReDBW9SOYiSeFBcQw 8veXTYV+wPn5Bk45nEZAvCmlxOwU+IIDeLF4UyIsEwpS+RhDNC+V5QAhj51OGVlyuh9qwuTTKaTu AHuTPZiaHMD4zVReYbA+mz3LDhnR+YWJB9khCFJ9BfsjyQCBFLTVRi/BnkHcn2T4joC4HTTxgImf MPHjJv65iVMZPHKcpVOOHOjQz/qwhf1J1gdjjzJ9NKr6aFT1lBlVPYWoPs12sHvJTcWowHv5Ck+x DtZJNYh0QWq7FeGtSPVwVJ7aKQGVpb7J0ZT+e2DHQVYClUv6wQCjC1OFk7mX0PEZ7kInx40MKA7L OwLFZ07Dl1/AsV8kkDUjg/2feb1BA+MFxGPu+MzpDH56UtROJmwGw8c1tQbDx1OmGAz2j/OLgtV9 4b7mPrwQIdDn9gXDb0+rCspvM75SqmiywXhlSnYH9QMW7UCPRZPfan5rz1vi7h4k6YnCwqByYs6J h04cOHHoxPET1ru3Y/YbLlfwG+aeiVmzjT0T5t6JisrM2G8s3Z9QM7rkJfJ8wUSPoO3pkbR7sMp2 rM+V8t83tzl4X0+2toNv2FNaGgz3FBejQTHU3ymIgiRYyMFOsc/Y58CfsJPsU/w3tljg53YxO0Vz AM0AUXCxk4KbnEIWZOzAVvaZYAN2UUjIAlgBIoXAG2KfAB7C/xC+jzX3sQdYL/Aetpd9B/gnwD8l J3sU9B8BPwL6D4F/AplHAY9wWcA+wB5AHf7DmANdZrMQuwryVayaTQeuZNPY5cDzgRdCvh70BuCr QQ8Dz4dsPeBqwGxAFaAyvC/kn+n1Xen1zvB6rvC6ar2OGm/WdK+12itWeelyb9nUnPKprgotp1Jz lag5U1TX5OIcpdjlkt2OrGy7wzrB5hAli4OY4CDRU1wsXi8eEkdEqdg1x9XsEv1sktM3ocjplQuc HinPWRmqCJWHykJTQiUhJTQ55A/5Qt6QJ+QKZYWsITFEoeZapnuaqGnZXD2XAS+dq9dqTWlRWaLX aE16VvOKzG0LZnVhJ94Fy3RpZ1oA8jTctCKKTOeXMT3+ASQ/6U3xnm/FcNM+V2c7dRW3D0Bh3IQo O3EPuCzaJ7C5uHHWZ+IGiHPFtEl6G7+RS0yK6TW8s2dSDJeMsxbrfnWudqFn8+bxs33lZRG9ItKq V0bijeMJ/3vfWIhdgA8bGHug2XI++ZzNzw42b74gJ0E8o++XyKN7nF2D856/HX5RNET9MQ4arrP1 MMIDrUwfjHNFmr3K79DT7LUM+o8M+kMGvZ5Bb3BkqLSlL4sH9+olc5t0G26Ebc0r9CIVgyMYXImB Q537P9b/TMgKZW5kc3RyZWFtCmVuZG9iago5MCAwIG9iago0ODU3CmVuZG9iago5MSAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NjcgL0NhcEhlaWdodCA3MzIgL0Rlc2Nl bnQgLTIxMSAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTA4NiAtNDQwIDE3MzQgMTE2OV0gL0ZvbnRO YW1lIC9MT01aVlYrTHVjaWRhR3JhbmRlLUJvbGQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDE1MCAv TWF4V2lkdGggMTc1MCAvU3RlbUggMTAwIC9YSGVpZ2h0IDU0MiAvRm9udEZpbGUyIDg5IDAgUiA+ PgplbmRvYmoKOTIgMCBvYmoKWyAzMzAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAyNDcgMCAwIDAgMCAwIDAgMAowIDAgNzkzIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjYzCjU4NiAw IDAgMCAwIDAgMCAzMjUgMCAwIDAgMCAwIDAgMCA0MDUgXQplbmRvYmoKMTcgMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTE9NWlZWK0x1Y2lkYUdyYW5k ZS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo5MSAwIFIgL1dpZHRocyA5MiAwIFIgL0ZpcnN0Q2hhciAz MiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKOTMg MCBvYmoKPDwgL0xlbmd0aCA5NCAwIFIgL0xlbmd0aDEgODg2MCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAG9WQt4VEWWPlW38+6kO48OSRqS21wCyA2Eh48EW+iQdBSi2IGA3aDQDR0I IBBJeEeIaCA2+AAdmW90FHdm/fYxyk0njp1RTEYHP9mVEVlfs84Kvv12ZWVmHfFbXXr/uvd2TDIZ P+bT3eo+9dc5p+rUqVOnKnRBjIis1E4SeVauDzVTKl0NySuggpVbWuXzn37+W7Q/JEr+5arm1es3 59kvEqU8QpQ5Y/Wt21cVWp55gijvFPp4mhpD4QtpRb8ictjBX9kEgXUx7wF/HfhxTetbtyWTmNBx K6rUWzeuDJGMDzlawSevD21rTt6RpYJvAy9vCK1v/PXOz14Fj/motHljS2vcTWHwvwE/vnlTY/P4 96/NB/8ZFnEUMoaPKFZKBhG5hCRZpUKipJepNFHrfczKMosKRDP+jl5/mmhf3BzX20QX3xay71NS MViQ5fsYEWOP00ayxq+OH4x/QX3URHnxqviP41j9CGVPfBedodN0gnroSXqY3kX7OD1PvfSP9AHa L6H1JP2IVmDsz+mn1AH8B3qcHqRNkAsUkuN/bplNHCK7QBfoMKuiecDh5UFYeXC48C/yH8eLRtC9 Gx9LbdTGN/MPaTM+P4HFX9CRQT3XoP231EI76Tg7RyvYc7QK6+lEptzHffF/TzpB+dI2yqeNliMi E4aUh8hP2yksPRL/A/LEluIjGz8a/wNsDS3f1W8j5k6UXjrA0mkX4jaNboSvcxKKoYgYXsAaVmIt e/A5jN3oxqcN8x4c3DO5RnAJv1PJyNZEHiVdbvSNf4L83aa3j4t4mxn7Hm3BDG6aTMVki5cgb66L N8a3x38aP4ZsELv/hJkVfeD+ng6yw/BgBd1Mi/kr7JzObQS/mOaxMSyTHoXtK4wZE7V5qiSDFzku SsI/ixlF82zBS6PExR2jF3aIjUIkXqYXKab78wgdogi1Iw6tyO8l5IPvM3GwjX4f6TksPP+2zzJq QO6hIAdnYT3vGpaNOukN/eyvMrg/80+c/ePSC8YYEUWj4IpLlJPYSeM0dCI2m3H+VmJnL+inR+zf ceza48i1hG7xgPYlfW9F/1k0XXgRnxnfhdj/lm6ijbybTWR3YlxnYqJB+AtIE5lcQO+yWYN0g5vf J+/bcIaO00ODzeG830KNQyTDmOHxG6YegU06xzTE4TT9EvPtxEfc7MNLL/L7OOK0g+qpivZhH9/F +WjCGQ4j4qeZjP15DbfYSCUEu6ewKxulVZK5yyN1Q4aIzwgl6ZwhTCVmQeYP5G6iq5G7CW4IzkqS 6G2Wg/x4gN5GTjxJz+AuWS2kyGKj/HV7tIc20CTzQx7PgrnXua+eWVlx1ZVXXD5j+rSp5VMml6mT Lps4YXzpOGWsSy4pHjPaWVRYMCrfkZebk223ZWVaM9LTUlOSkywSZ1TGCrSCar93rVZYHdSsSo1i lzXr/PM3lGuU43Qp2fKM8sBks5eWpGqUW6fl+fxd5KkIaMnq8C7zNanU/kcXBt/glL2apRRfZV4o rE1c4Hcp9jedA/oAzGpF1X6Xy6nxUnznQoXvvJAc1uw+yKHQJXM18vkFxeLvV0BIFa4A6gV+rTjB BoQ1YymDnOzFieof5uZ8FrF3WQurazTK6yLr+xo5RLfzFaSRW5uowhE7Wro1KtdY3h81lqsxxw1Y 0tApxLCzFSPEwBteq3jDaxDRcPDbmJ43IuqSI3JkgT97htPl0p2u016u93dlpFcr1Y3pWAXpAupK z4AkQwiwLc1dzDqL6Q1u9c7s4pSaifDlCHe9gtZqnv1BNJQaxA2a3G81sXj/gcEqwjCjE6Gb3mL6 nFpytZZiOCGv0TwhjfbLXWX9kQMxO60IqtawEg7d7NekEJzqIqnU29Sgja7zLYEIToCCTbLY7hq9 Epsne5vkCHjRN4haqcHQofJwU2NQpAkLKjXQpVX797n6nVoO0Ktlq1omhmfu+NApRbwFa2TBRiL7 ZO1IvX+w1iX6IAkKJpfJEa+C2WDMu3aO2LHygW3Ts3FuWN8cz/6QrLWvWIuY4Rs6kMh/V8SuWb90 YXewPxgpTocIsKBwcK1YylqMtADkyP5GfakH9KUhX2Xv2hpBYiCynxZh9BK/t0nxIp7mhAgIxkul w8e6XFqhKgZGIl7hYigM70Vk8C1UdTcMBmfCqTL4U615GnSgBn0PMKMnVBMwRWYHaCzYB80TrAkE xKKMDdBSSvclTVHkiDCfUqrlqXbXb6Drn1xWt8DvrRHZiZ682n/NuQLnObTrfANiVoA+kfJzIkhC s1CpqzeyoEnER1TBBuMAI2rmzqOr2V+3erLAeRJja5XaYCRSq8i1kWAkFIu3r1BkuxLpslojzd6g rJ98Bvmv9ju12gMBzR5sYjOxySLfahfUabn1S8X21MpNIUjwna24KpyubJg2+uDmGFltnjNkPPJe nLOI/TOs2IobySnXiuslhlvBqdkrxDGFJ4v8OAcrMYU3rFc4Hwth3ClOihQo9a5ZaAbI6cKUesKI e6/elMKIyyXO0P6Yh1aA0drr/QYv0wpnlDzlKvYuKDT9CY1jkdC0JzQDw4MK9qqgDvPrOfGXchr3 +UA+R7KVHLlSXObwDt+5Ya2/AWv8qkJLRcT07c6t9ktOLrqgxZ2SaKWr+JPg1kap+kARE9ySEbsi n1I0u6olVfv7ne6AbM/GBckGksG0KNLUfko5wcQlSnl2jbk1li+OFeFSRRhx6Y+qgHJgoOyNBM3s G7w+dBW9w00D58hYBQ6uWCTCYFdwbp1GPLJzFLHUV0S2J/4qlNaKQ4W90SM2L6BliT92WtZneoXF Oav9Mq4hHNt6vSF75Sax65ocrNHvg4BT6BPiWPxssEbcf34kGro4zfxGliNs5pkww1DX4E+0Fvhv d+4ITI7RwrK6GKXhLylj9wZiLN4Ro5oxvZRG0vJlUDeUybJ3TQ0mBLOoDIJJLrQWlyE3Rer7lYD4 SzI3HJFF8oexLB2haIwEypGvC/24LwnnUPMEnAPNxkBgJuzcJOxgCLpHArCw1rQA1EXl/4NO/rI6 3FTjfX5ctu01SPQacYSx3H6cqn6xYrGQwICn8Pj2NQWmz0vgc2AS9EsNK8jVdpgIRCLC5kK/gjSP RJwRrMPkY4yGCzymIEZiCBbujbF2H8YCFP3fB17FpYjIB2ow1c2Ie+KWitEt3x3hZQN+Y+RyeLtM j3DwB4pw6FIivOKSIrxywNMhEQ7D55Uiwo0jR1jj478jxoND6jFC6hkhpKuGhHT1d4e0acBReLUG 7jXpIV37A4V03aWE9NZLCun6AU+HhHQDfF4vQrpx5JD+XyRt85AI3/bdEd404DecbIG3m/QIt/5A Ed58KRHeckkR3jrg6ZAIb4PPW0WEt///RXjHoAgT4VcPXvnwwYtmCuU9k8wtJKj85Osn9WraVFe2 K7sUFcNvvW88Uvs37Un0NXks7Ripvx8ms+STi9qk5Tb3n5jT+M378rrV7wi1wIEZCPe5YEQBpjx3 0Yd30eILWy5UZ4qXx6GFG2+fulAmGSh6cNoKuhG+MrLTVPxCpqSzmTPgvdAyytERr6OUS9Rw06L6 hYvU6zevXBMOXbsptCGs/1zn6IkSrxBvoyMUUx+j29QYrQbdAlqoVmVh+lqygzjt5jXE+Gzuxnwq n8XdUaZ+/iy/BsJrwOSV0DHo7CDO9rHOaFGJJ8bu7rbnV1JVFuskO4izO1kHbKnsLhP3so4oV9uf Zbth9gxr86xiZ87mjxr9+huodrblO207S3aW75R2thW+dhqiLVtRrW9GdetGVOs25DuXb9i9jq/b sHtTUevmPMfo1WtRrVqDqrEpz3lf45HGU41SY1PHbUWFLfk7qgtd20G8V1ogzcPM9mNSLflAnDxS ZTQjq7I33i9VRLPMRneatdJXlSFNJiZNlaYh6ir/gv8XHmtV/kH0ea7G+O+7nw9jrfyd7mkzKwVG lQnCChp5eXrjd9EZlWZj0hSz4VLMxqhCs5GVrTdORbPR4O18m3CvSuWt5ANxhPYWtG5BK4NfT07Q OpAErg5cHXE+E2mcTyW8ApgDnM6niWDzqSaWA4shn8KnRYtL5BggJ7+yl11gH0QlNb1KZl8QY5+z /xSj8Lxn4Gcm/oeJn7JPRBjYx0AL8CMg+sf/iX3QnQHXq8ZAwGgL6r1CxR5kh3SDD5h4iN2PbFXZ QWAK8D6gmPBedj+W3NcHllEz6nahYDdFD1nUGFsYPSjgxuhhAVd275ZUJFhlNKegsiqNjWOlulN2 lq2jxXP1NwjfV76vuOfjoqLKnzwsqY88bFEfPpyuPgB7Bw8lq4dg6UegHx/m6kOHJfXIYfbY4aOH +w5Lz0nXSXPF4qS50Q6uipSo7rZnV5Y8L+EQ0FlRS1dIlyNqclWONIOmgjwgH8gizZDyhBPSdBPL pTz0LO8DizOL7JFBnJ+PHktG/rwf7UsVU/D3oqMm6inwXhS5EONno/vSoT/T3WfBUvlb3UqpyK+3 og5sGvqfjsKlqkz+Ej8u4slf4P06/trEA8L35/gWvlUshW81l8JvM5bCN4ml6LWHBxNGg9H0DN36 8uioAr2xLDruMr2xRB9XlceX6gNFbePzUOfzuTQexCmNT6ZCEId7ajTboY+7rDszuxLZpohsO8bH cllsN3dxOWpRT8CejDukGLU4XCWGln3JXtU38ix7Glehi51hT0fHu+QYOxMtdlVWFbF/Y7/Xs+Yd E//VxN+Z+DZ7SzfwFntT7/cmex3ZpfWBZewN9rou/BdduKYqg53GOnpFzU6butd0HWY8FcUl0Iv8 flXkt9rHfkY/B/WApPhZ9kQ014FtYPewA/qE+02MAEVaL47uxTXBFkXbJUBDdG8SYEF0n4D6aKcA X7RT6OZHOwRcLzYqxiqi+wRMi/YJ4VhDmOXJgPK/v7aoX4tO8X5P+p9EYn7Jzn7JBJvW5Rhd6fkI KS+4KUczbZXw1NPj6wn2NPe09/T3nOo523O+J63naLjk008s6t2RFDWyP1k9AMKQZ+6dOr3y3nsw JYbn3VOsVN6zn6v7O1LVPXdY1DvEGuL93e3zbhD2u9tnVxt4eaWBE6fo81rbxyiV7bu4unuXbtVj vd07t/J2MLtgSZiWO2G6EyvcB8HejmT1zrvS1buAzR3tHbyvg1WlSwulBsqSfFI96vnSjaKOSuGS qkXS9dINZJOc0mhpDFklm2SXsoFWKVPKAk4AXkaZkgt6BVgMvQycQG7JBSoGOUE2kJXc/En+FD9K Vv44/xv+M+Cj/DF+BNgLfJYyeTf0TwM16KPAXozpBuGhkD8Jehz0KOgOvoey+C6+G3Ubv13Uur+b +Q6+E2fFzrN5Duxm8ixuAzLOuURWdpHF8RfYips8mx4GcdEXd72dHgP1gc6AknBzZ9Js0G6QRCXs Is5NIcY64VMubDqAhfAjF2QHZYKSQYzc6Otmx9jzrA/zdbEo6wY+xY7il7iVnQD+M2WyF6E/DuyH /gXgCYx5EdQvxoK6QE+B1rMNDP/NyEJsBVsJXMaWs6DOr4qOKimpmsNW0WzQbpDEtkO7E9ZaMGoz sBmjNgG3w1ILqFlYBK0ChUDLQGVsMtnYeDYB9UR2GWWxSUxFXcAKIclhuajzmAOSfPz3UBZLYsmo OZNQ4wiL2vN3SJWLcZvzKkfBlQ7HFY6cyx22GQ7rdEfaNEfyVIdU7qApjvETsiZOsE1Ss8pU21gl a5xiKy7JkktsNnu2NS09w5qckmqVLElWRNpKkie3SCEptyRZGl1SYptt222TZImVSDdKfVJcsjjZ mMyClKJMh31UZo4lL/N+JytzT3JPdI93j3OPdcvuYrfTXeB2uHPcNneaO9ktucntm8G0nDqqa5ij 5TLgwjnaDLUuJskLtOlqnZbmW2q8EUCq8U78SG7QLJ0xDsipXrLUH2OF4gmhw9kr1q3VBTvuCeB9 eI7GOjUFv5kBHvx+lzvxetXg7+JsDt5JtavwbiF6BdQxWli8I7WPCWjTReP+MQE8jc2s15zKHHV4 aRGCllYdvtV1TRzv1SZ5Q1qZN1jzrVhVCQwc9moXvaEY48oQZaLjMGMJMbAFxWRjvM0b4ztghu8a 2czAuJg03xuTrkdXySe6trawAd0IjZZWCJleD9fqk7duhiNDNBCgtCAMYqiIhw6DKt3tFkNBg9U0 YCkhTeCgSQYt27QpRrWorNrvDKh4CtYUJEligGlRAIuxNvH8HGO3G7DLgN0GtBtwhwF7DLjTgLsM 6DBgrwH7DOg04G4B5srwr5KrdSl3G3CNAbMMmG2Ax4AqA+YYUG2A/k4e416DqzXgWgGIG9bW0pUm st+3YE6dloqH3lTfUq1IAfMymCvBWJU59L9aSXrECmVuZHN0cmVhbQplbmRvYmoKOTQgMCBvYmoK NDc0OQplbmRvYmoKOTUgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTY3 IC9DYXBIZWlnaHQgNzMyIC9EZXNjZW50IC0yMTEgL0ZsYWdzIDQKL0ZvbnRCQm94IFstMTA2NyAt NzM3IDE2NDEgMTE2Ml0gL0ZvbnROYW1lIC9UV1VRU1UrTHVjaWRhR3JhbmRlIC9JdGFsaWNBbmds ZQowIC9TdGVtViAxMDMgL01heFdpZHRoIDE2NDAgL1N0ZW1IIDc3IC9YSGVpZ2h0IDUzNiAvRm9u dEZpbGUyIDkzIDAgUiA+PgplbmRvYmoKOTYgMCBvYmoKWyAwIF0KZW5kb2JqCjk3IDAgb2JqCjw8 IC9MZW5ndGggOTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QwW7DIAyG 7zyFj92hIukZIU2dKuWwdlrWByDgREgLIIcc8vYzLO2kIfnA//szP5bn7q0LPoP8oGh7zDD64AiX uJJFGHDyQbQncN7m/VY1O5skJMP9tmScuzBGUEoAyE9GlkwbHF5dHPClaDdySD5McLif+6r0a0rf OGPI0AitweHI495NupoZQVb02Dn2fd6OTP11fG0JgRMx0f5GstHhkoxFMmFCoZpGq8tFCwzun7UD w7h3nlqtSjV8av/DKWj54jOSXYk4Td1DDVoC+IDPVaWYyoO1fgBtmnAQCmVuZHN0cmVhbQplbmRv YmoKOTggMCBvYmoKMjIzCmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAv VHJ1ZVR5cGUgL0Jhc2VGb250IC9UV1VRU1UrTHVjaWRhR3JhbmRlIC9Gb250RGVzY3JpcHRvcgo5 NSAwIFIgL1dpZHRocyA5NiAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1RvVW5pY29k ZSA5NyAwIFIgPj4KZW5kb2JqCjk5IDAgb2JqCjw8IC9MZW5ndGggMTAwIDAgUiAvTGVuZ3RoMSAx MTMwNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdegl8VNX1/7n3vVkzmZkMk2Qm 23vDJDOEISSELCyRvAlJRCISINIMmjJhsVAVggSxtAVEqRpcgguulbghFS0vE8REoET92drFgrUL 3X7m02Jdaj61rdtPyczve98EFH9+/stvwrnnLud7z7nnnnvfffdBjIgctJ0k0lZe3dlFX6M3UPML 0K0rr+1WP5vz2B+IWDuRZdkVXd+4esiy5kUi6yEi05XfuOpbV3QeuncXkVMlyvCtWd25Knm84E0i /wzga9agwrPV+jrKXSgXr7m6+7qyQhlY/90oT7pq/cpO11WOSSgfRTnn6s7ruiyb5WtR/jXK6rrO q1c/8L19/Sh/gHJJ1/qN3bSTvUeUV4ByTdc1q7v+Of/NHJTbiLJ+hTqGP/FzkBljIppFs8drRO35 P35+8f+xJBlyMpm+JG9G2WLUWZHaTM9TgUFPUoEcItibOn2WkmtTp0Wb4PxdGF2YpvEeE/Q0/Y5N YioNsE8plz5hfjaNLiKZPsYsHaQxuoe81EZ7mIeKKYcupYuYDJkI3coeTF2beocuoDvp0dRzbEfq KbTfQT+mT2DBf8qMaukSyF9Kq+kd6U2KpR4gK91EGfDSYpZDnfRb/H0IO+6iu+lH7DupT6DVSzvQ Xx1FKZp6IXWGJtOtcq/plO1Z2k1HmDm1MrWWimgi9fBI6repNyhEMXqMnoZNETYsz6MAXUk76T7m l36M3D30OCWZg3dIc03HoekiWkrraDP10FP0M+ZhraZTpvdT3069hRmcQJNg01p6h1WzBfwJ2ZGa k/oDXUZD9ArGK/6G5cvkJ02XJetT30+9SNn0HLOzo+wFU6Xp9rHrU4+kfohICNE0eOQS6FlBN9AL 9FP6J/2Lb0tto3m0BJpfZoVMZSF4/Lfcz7fyrdLrNBWj7YC1m2gv6ZSg5+kIHYNv/kgj9Cbzsnw2 n61gu9m/uIOv4iekB6VD0q9lJv8A/g5SCXzUTU/QYayjV+kEM6H/CtbKvsnWs3vZ99kI1/l7/GPZ Kt8gfyaPmULJkeRnqUtSH5KP8uhi2kLb4NvHaIAO0S/pN/Qv+jd9xNxsBlvDHmE6G2HvcRufyBfy Lr6HP8GfkS6RdksvyNVyg3yl/Kr8B9P3TLssnZbkmX3Ju5LPJF9LPZd6DbHjRP8haoZHr0dUPEHH 6XX0/nv6M/1FxA/6n82Wsa9Dy0Z2M7ubPcNeZq+xdzFKMv4m8tm8EVrX82vgpx38Ln43tJ/A30n+ B/5n/nf+oWSSJko10gbpEUmXBqWT0t9ktxySp8rT5IXyMjmFmak0XWhaYtpvOmB60fS+uc68ytxl ftuyw3Kj9Rdjk8f+M0nJNUk9OYDYtSKStsATD9OjiPtDmIOfwaO/hMUj9AFmIY8FWBh2z2TNrIUt YF9jl7PVbAe7id3J7mMPskfZDzECjIFb4K0Ij/IlvJOv5jfym/ht/BD+nuc/5b/lp/goLM+VglJE miZdJC2TLpPWYQzd0lbpRnh2t/SUdEJ6XXpLelsaxazlykXyJnmLfL/8pHxIfs10selq/D1qOm4a Nr1mOmM6Y+bmPHOBudz8TfN+818sZkuNpdVyi+XXln9bu1gBmwzLVcT+uR/3Yw0W8ae4V97GRlFd yGRyYeQRzMMSrIp/U72UxLw4RTtsy+Z+eYKAmzVZJ+Ld7AhVs5dpm5lL2AHlEUqwP/ER+SV+Af2G xZlfflJaZ/oZD9AB7Ea9/Cg/whroEK/jS/lDErE32X56E/F+Hd3NrmQb6QAbZbPYd1kt20a/5jnS EnYj1aUe5TKzsYvY+wQL6Hp5FX393BC+MsNm0p/oneTDcqb8HexPg7QHM/o0vcF+QJ8yU+o97G4S dqNO7DK3It53ktj1OrDOtmE9+rGDXGU+QYcY9lZLrXmOvIXep/+id0zPI6IasJu+lVwrPyz/NVWb KsMKwyqj/Vh3a+hCrJg3ESXHUBaly7HS7dhLKrGqW2kZraLvYtfbndJTD6VuSH0rtZ5+DuynbAr7 lPVhRQwCUUev4O8O+j3bhXV44VcO7/9amVxFw/Qu87ESVon1MGq61tRresp0yPQj06vmafD2jfQg IvoviGY7RrCSXqN36WNmxdz4aQpVwd4ZsL2druIx6RjNZXnUhTU7Cft4w/hINqKXHfDeQ1jPx7A2 3sc+cTn9iE4xznIxopXQb0U/LfDzctpI+zCDN7AB1KzCrj2Z/o5xO9kM3g19Gnrag11rGDb9if4G b6cMu6ZgX2hkS9HXxzgfrIKGGmpleC6nDtNM7KyN0i/g72LmpgY2kT0OXBwr1EmFNNP0V8ZpSvKS 1Ay+VjqGZ0wK9X14euXTBWwDrHBhHGOUzRZSdXIxbHidSbLOfmVYcT9fnbpJ2py8in5OP8CcaPK1 lkYiLdqm1c+5oG72rJkzaqurpldOqyifWjYlMrl0UjhUUhycGFCVosKC/Dy/Lzcn2zvBk+V2OTMd GXab1WI2yRJnNKUp2BxX9VBcl0PBefPKRDnYiYrOL1TEdRVVzefL6KrAdaLpPEkNkld8SVJLS2rn JJlbraO6silqU1DVX20MqoNs2aJ25G9rDMZUfdTILzDyvUY+E/lAAAC1ybemUdVZXG3Sm69d09MU byybwvoz7HODc1fby6ZQvz0D2Qzk9NxgVz/LncOMDM9tmtXPyZqJIep5wcYm3R8EFN1IJU2dq/TW Re1NjfmBQKxsis7mrgyu0CnYoLsihgjNNdTo5rm6xVCjrtUxGtql9k8Z7rl10E0r4hHHquCqzsvb dakTfTTpWRHobdRzt5z2fV5E55657Td9sTVf6mnyrVWFcE/PTao+vKj9C9j8gOghFkMfwPKS5nhP M1TfiplqWaJCG98Za9fZTqhUxUjEqNLjWx1sEjXxb6q6LdgQXNPzzTimJq9Hp8XfCiTy8rSh1Ajl Nak9be3BgF6fH4x1Nhb0e6ln8bcG/JrqP7+lbEq/Oyvt2H6nazzjyPxiZjWcnm4zcoa4yLUsPudZ JiwKXqRriKiVKixpD2JMM0Syegb1rJyBCcAvxoDSV2FG1uq2ufEe9yxRjyEy3VTiDqo9HxIiIDj6 3vk1neM15hL3hyQaRZycCzWddZ7N65GIPnmyCBHLXMwpbJxjlKvLplw7yGuCXW4VDO6jVvi2Mzar HO4PBMQE7xrUaAUK+vZF7emySivyE6SVR2I6j4sWTGC6JftS0bL9bMs5eDyISD5kHMezdWvo3D+X O2dC05pZOsv5PzSvTre3LAm2LFrWrjb1xMejtqXtvFK6XTgUfkPbeE6fMLddyueoEzmeLxmtCMrL l50TQaHdocsl+GcWRmN1SAhKo4Kpzbo7Pi+dxuyBwPiS+Z+YQYv1C6DB1PsCZbDPYeOj0GdFxu1M W63PPq98nnWOHqmlDTsOb2lb1tNjP6+tGXtZT09zUG3uifd0Dqa2rwiq7mDPEH+SP9nT1YRdKD2h g6nnd+XrzbfGMJQ1bBbCllNDf5DdvKhfYzcvWdY+5CZSb25rT3DG58YbYrEyHC3EC5VJvO5IeL9p OMRZ0mwZ5PXaBDLJSYnsFjnJyG81m5JcOspCZMMB1Ue+iPujurG6S9wf1C0Yq6N65N1nkEyrCGQF skqQMDz0z6jS8BnNRJ+RKg9DF87mxP6CE4rQNVXLl2Yws3mGbLcdlDg3h5hqqjBx00HrqwdE/x2i 07qPqH60fnRaxQT0y0A/Zf7kW3jZyBT8zL9FihEg7O7FuehGvHfZ6Bqt3mqSzaYSi2qtsB63vmGV y629Vm61kiSXYPA2slrqzQtxjFsswQM8T82oyOAZsk1lKlXAzkG+a8A+bYkvggF2iBFe4u6APQtQ wFjFaD0zyzs2gEsmdx1GPT0rkI1Bg+6VRsdm81VjD5me/yT5xCdju8W4L0q9jTPyHLw7VLIN2hpL nrXAVJiTNz9/XsFFJX90v5Flq/E3+78WusL/jdD3Qnf678rblzeU/5O8V/IdZnNmdo7ZnxM2l2bH /Jv59/g+87PmH5sdx6t+7+aFxZXTsqZkFmuRqVXF2sRJSPyFVeuLzxTz4ubCwdSwVuF0VV1QyKjQ XagX/lehXFg4hU0nDbUuUmDapQGtIKs+oOW7kfjyqgKDvPtZ2eLItE8BfABtBkezwSExBRKa5s0o mhayltomZcYUx14HVxws5WAOzZlT5chbWMWq4piT2ysYY9NLA8tz2Ru5bGHu8tz1uVKuf/raaNq1 G65ZMPrBhtEO4d5Ih1E6LcJpNBKJwM9jYB90RE4bzo70m/lcBG95IdsQG00Xhqg4NfxcfmFVW/Gq Yt4RiXUAkeWZKTkxK5gWtqGDOjawcE3N9MqcnGzJm5MbCIVDYbM5ODFUXVVTU1uDE0YoONGMQLSY s7050ytRVVPNVqcivzpxdLBFyi9JvpvhtkjzHu94/NjSB+98+eLW9S1t7Os17xbXtjde3DTdncH/ MvWBu2O3PJccvHXnxQW1fmtzc+LmZbe1FJSoBYuaZid/5an0hetmL60M1RavRqxyakM8dCJWXXhv 79XKPDFzzB7zLM1Z6osV3Ge53/aJzdZVtL2Iz5KqHLOyq/zzpUbH/OxG//02mxfeT5gy8sQkODMs ThfcbM8tdWaG2CAr1VwuyrujiBW5A1Z/YXud4eYFo5e4N3xUt2B0rO5vRvimVxR1wD1z27XMtea1 9rWeK3Ku8K0tMHfgRFIt/ENZbs/0ylysZG8u3FKT9pPcmfws2r/sueRnyRcTO5h/zFPeuKXz5hu/ seqmhy6L4XXNiuOm/27uPtP11MXrnnj8uUf2YrxRjDeM+PdSAXtsiNypT7TmjJn32x7I3OPeb3rS fsR2JHMwz2r1snn8QnOzfWHR/szD5sN5P7G/4vit/ZTjE8vHmZkFroJsDXOdrTmzqlzZx7NPZEvZ IkZdRfUGd+aC89s0h8vpaXXGndzp8zAIHPbnV7HpHhKyhWqVwSeWpnmkLM19BQbXXFgYfXApuWH2 co8Hbh6QMzw+4e7iDAsFWHl2YKGTOfPKi5YXrS/aWyQXuQJWLdNVBYePx3VEeBwbBoJ7FMGMB4/m 9WmTvPU+rciFBIvJJ1YdgjUSqx9D+xB5YBwkPMJICBkccoInzop+0LFBQCIGgNDgmSkGk8gVTB+w 2ecYxWigPkKi69NiLXQY6p0avOQUSp1CvVODs4RMJFZeh2V2TSRSx7KmY8V0bKCOCDMhAtRwqNpN 0ytJCuSIAJgQwkKxmHP5p8xX887B5N93rmXe10eZxzymSTs6G5aFpeuWXl5Xx9ji8gceeXb3nxEL keRPkse+u2seu2rLtrlzN4p9eiveau9DLITZ7CEqxQ7VkWWvhz5HtjnHUSVVWat8VcFG3mRt8jUG HapUXrrEFi/dXrq39HHzk5Z9jmfNzzr00pOlI6VOKi0vbUXD8dI3Ss2lWl5BVT3K241GkyUgW/IK c8RysVvErqYVyRZ3VlY4v6AgFLYzMrvcIU+Wtqw6nsXW49kyyJs1V15+qLAAdesLWLyAFaDuUEko FBZrK0EUFrPjstULrtXA7jBEw1oUVAcqDleFtVkXVJWHT4TfCEuusBLeHpYorIYrwqmwHPZP+mt6 RWKrE77Hr26Be9Q9VvcRZhZPk482dAhmLFI8+8SfWKsM00ggTM81EbGlsciEQLbY03KNnQ2vQXgy VoXFRmY2smKqjOxWJu0avmJPRfOjl296dFJh8q3C8KLZa6Ym3yqqr4muKUu+JYd2/6Dt0kvbll/e eN9YjC9/eGrdvF17kpw3P7hsSvON94+dwUJYjPX7AOYsE++t92rz3mZvWT+e8HG2/BP+tol7/Ca/ jcfcSycszYn57uX3me+z3usYtP2G/9H0J9tvHG+Z3jK/nel+0vpz/gvzS9YfO0ybrLeYb7RK8Djm JiNXzI1XtnhnWvLi+V35PN8ZIH9ee/oZkd68Foh1JI4BtKEDIYpdy7bWfQX2rLU+mXXE4JGOCVUe eISyvRScWBwqEVv5+J61uGfsoX+yquRP37sz+XEPU/esW3fPPevW7eETb2XmnuRP/vHP5Es3pvY/ vH9/30P794sYvQnHoVqM1037tUn3mpjNyZaYrjBtMknlnnbnGmeXB4cWl0Nx8DscKQevdyx0cMcg 36yVWizYjiVutk8im9tWYeuyyba8bZ69Hr7cs81z0HPSI3vcFGKS2KwzON/O+vAm78+qH2IFOFXh vLFhPCSwg2z4qMO/4DT5xJGjfhRBMxPvwkw80qhFz13SolfjsNxvr5wBBwTE8UNEQ67FmPss1odz kmnulY3x2NcuvGD24nI5dO+VjdUfTo0+lfwnxqik3ua7Td/HjL6qlaqksqC91DXLOd8Zc1n82eST crIp1zPBy3I93Mt8ks1itzh8g4xpLsrty9VzpTjYMJ7ng0xOZDPxYBqgbHF6xJPJkWErt5cTlbPl GB8ktEk+KZTruTS73rvXe9Arxb3bvb3ek973vSbyur2qt8Ire/151/WdPRm06LUY4WyMcIi8qeEZ sboF4oSJI5j7A79wyqhx6sSeeBpLI2u6Cz/hHZYdzPKKDas214ynPB731VnB6unVJVl8y3BGuCA8 37fiOxdvmZlhu/56lieHRpJtOyIF+X+YPH1R07R72ImR1x9P3gL/4FjM7/jZfzzTuNxV96HVb0UF 0StXfuOP5zg8aL4PT3GGM6eQFz9wy5zkJTTXTZ9++ukWnLjPtqTbiexmVPGn6KfyX+leeSNdBN4G HrUU0lbkF0uFdBPaFQBqcIuTYM/zSmmG7JF75DOmW9M6cN/1L6zLO3CLzhGl5bj9IfOn/EUc5Lkh 4RnXK27ZqW3R/LZLlkSi16ztvKqsYf1Vqxbgg4o4hxi/VJh+l859KbWjXEil1Ij7sXm4x1kMLV8j 6m/bHs2UnqaDIChHqoL6QBJp0tMDlsxKbRDc4zV4IidSOZQalp5OzJpu1JfdXbn9qHQA11XTUX0g camoPjCgNQrxAwPTZ6d5+TSDJ6zpZou3UonmAVYO4uQazy0EvwO0F3QcZIZBB+gNUAokSfulRxPN Cjp+Ah25ol7pCThGQ3oClAJJsP4JjOUJ+sd4jQyrHhuwOYT6xwxUvvQYUC6kbtB20EHQCZCJ1iPd C0qBJORwlQ3i0qPSIwm34o7apYdpG4hLD5CLiWU3LN034DZ8c/+Aa0KlFnVL91AriJMuLaBhEEe3 uwHbTRziLYmyaYYLWwbszko35HfB6F0wZBdU9iFlRllDTsjvGpiQI4y/IeHKMnDfTlRUpTMDbl9l K7xwHTFptbQOLyQKLsHX4apQkVaCF4KvkFZhoxd2agMud+V26KuHeD3uhEvRHJVycNOqSI1SHm75 hNimhDOtZ1Ni0uRKjHiu5DNEXFImLjkVySpZEpWKekTSDOffPGDLEPbdnHBnVx6TdkoWHAwVaTuk chXXMcmOObYbI2kbsGVW9kYdUhuG2Qa3KLCRwcsi1aR1CXQUzZKapAJ8mFGkK7F0ssGbpSKDPyk9 gs8hivT9gVCBMnxEustA3Sk6hfo56dCaM5DprByO2qQ5aNWl2zEBtxvKewdCM3ClHJImUQWIw8fb kNuGnFvqQa4Hs9aDmerBTPXAqB5EH0m3oOUWyJRLW6hL2ky9oL3Ii7DKTsChYjFkJ4onVQ5JfskH x7iPwJUMtXkDNqewzJfwTDDEfAMOZ2X9MWkjLQRxDLl7INdXuf6INNkYypQBX74AdCUQrsfwicOY GvSUI6bkmFQARwjHFEpFiWxFjyooi0BWiPGf8ZPCSfx1/hsx3eIrj8F/Ps5fHee/TPPUMD+ZXhT8 V4KPRAv4m+hsOf8z7UWO8yP8Jbw8K/hUNChmn/+eD1E9+CmUV4EPgU8Hfz4ReEUZ5IMDYLD9wURm jhgsfykRKR/PKCXjmdz88YwnpzJawl/kL+CNSeG/Ay8Gf4EP48ukwo+D+8CHeTdu9RX+LK/GN08F X4DS/D/4URHi/Dl+GDfuCh9IOIUJesIi2MGEWbAfJihdai1XjvIf8gOUB9FnEqE8NO4fCBUrriPo j+GbWHeiUPFE7fwR1s4+gFAf7uPBycMfTdSKTnoTR1VliPfyXs1Xq5VoZdo+qaKkoqxin6SWqGVq rbpPjbr57dhA9nKsX74LaS2pHNED0kC9/JaEXKtHxzAmMS5O25H2Gbk40i4jR0jdRk60vm/k6vlO Wgji6GMraBtoO+h6XMn08i2gb4O+A/quUdON3CbQZuwmXUB0AdEFRJeB6AKiC4guILoMhNDcBUSX gYgDEQciDkTcQMSBiAMRByJuIIS9cSDiBqIViFYgWoFoNRCtQLQC0QpEq4FoBaIViFYDoQGhAaEB oRkIDQgNCA0IzUBoQGhAaAaiAogKICqAqDAQFUBUAFEBRIWBqACiAogKA6ECoQKhAqEaCBUIFQgV CNVAqECoQKgGwg2EGwg3EG4D4QbCDYQbCLeBcAPhBsJtIEaAGAFiBIgRAzECxAgQI0CMGIgRIEaA GOGb+6WT0ZcBOQnISUBOGpCTgJwE5CQgJw3ISUBOAnJyfOjCESJghoEdBnYY2GEDOwzsMLDDwA4b 2GFIDgM7bGB1IHQgdCB0A6EDoQOhA6EbCB0IHQjdQPQB0QdEHxB9BqIPiD4g+oDoMxB9QPQB0Wcg eoHoBaIXiF4D0QtELxC9QPQaiF4geoHoNRD/31PDr2ftVjxrcbwuNfg2es/gW+mUwb9L/Qb/Du0z +Ldph8G3UK3BN1PI4Jhqg3eTYmUJpdYVzcEWsBC0HLQetBd0EHQcZDFyJ5B7A5Ti1dpE2WVZaNlr OWg5bjEdtIxYuAv3jnvNB83HzaaD5hEzV6P5PNPYR7G10B3AMdqG9B8gPESQ1hu5el4FvVXYZ6vx V8WrtKxR9R+T2YnJ7PhkdnAyu2Myi9r4hUw2djqVanG1q7B2zRGao5wC1YbCc7Az3X74vVwlEapR BtnRNCvVIii+B+oH7QPtANWCKkFloBKQAqoNTQasXZs43uVR8DAoAFJBtZSD/61DniyrNsQz2b6B lzPJJvSEJwF3JBGuABtMhBeCPZcIr1CiNnYYFwHC0GexqA6AH0wop9H8TJo9nVCOoLQ/oVSBdSTC U8EuS4RfVaKZ7FJS8H9eFNY2zpdgwkV5cUJZCrFFCaUULJIIh4T0ZCgqQWspa6fT4Mgb6OK0pmBC mQ3piQllppC2UlhMPL5NlxnmmZAXZWkABv1jiLXLTMtQRpW7lPdg79/hWITH79VBGexEySBbqtmV o2UPQziqJKJ2IY/nQ/841wV/VtlXcovyIPpiJYeV+5Wpyu1lg1ZU3wa7bzFUJJQd+GZzQJugbFcq lO6y08pGZb7SqSxWOkpQn1AuV44KMynG2vmBw0orOrwIoyhJKBeWwBaY2Kx8S9GUsDJTPSr8SzOE akRy2VHhAdxHG9qnwL+TS6A9oVxaO8iytMmW9y29lsssDZbZlqBloqXIUmjxWj1Wt9VpdVjtVqvV bJVxpU5W72BqRIuI9xyv2XjdMcuiIBt5N94xGOJYpLhpt3KaT/oEqYW3LGlgLfrwSmpZoeofLQkO MvuiZbop2MB0Twu1tDXoMyItg5bUYr020qJbWi9r72fs9hhqdX7zIKO29kGWElU788W3x35GO2/L HyLG/Dtvi8XIl3Ntva/eMydrZnPjVyRxozLemL6DMVLf53lfpFDf07KkXX+qMKZXikyqMNaiXy++ TA5xF89sahziTsFi7UNyF3c1LRb1cldjDGKnDTFEsxNiFBYMYtYGUoUY9pMGIYY5SsuFAIdcQDDI 2TMpZMiF7JmGnMyEXP8ptamxH9+JhUwJ0SlD5lQJfUEGEQNsY38ICaSCKmsXUgxfoA3DSo2OFAUi ZUggwnDuMzpSmKFML/9cpGRcpPqcSLWhS0rbY3QjEnTjnXRWxjsJMp878n+XW90QYQPTNm19qQkf e+PBptWguL7r2jU+ffsKVe3fukk04JtrKL5i5RrBO1frm4KrG/WtwUa1f5qB+1LzS6J5WrCxn15q amvvf0lb3ZiYpk1rCnY2xgbq69qj5+m65Zyu9rqv0FUnOmsXuuoN3Jd0RUVzvdAVFbqiQle9Vm/o alor4r61vd9KDTFczBp8gGfYEcPx/ECsIcfdNUcE9NDsgG9r/vMy4X/uZOAjrAOf7TNBoqksWhYV TVhnoskpvuiPN/m2zg7kP8/2jze5UZ0VbDAuesVkkMCLa6MWPYAPgiJU8Nn9q+dso/gZzT5qWtuI fyh3G9S9sfuLU0tC8n/+ur/qt2nTpo3dSDZFcBncok/GFU+NuMSyWKAq3hhD3dSzdZJk1PXbbE24 b0VjBEawbqFO5CJMXIRrdjKThfeZ+yxcvEV0D+QVVq4/hnPDNhBeh/nmBK4SRNPmgYkleFuCSHl1 muN1VZQTeYFKcbNbC6jgJWmuZZUh01vSW9Zb21fSV9ZXa0br4X2oVPaJR2mifJ9E3ZGNZ52BbHcM zhb389D3SKKg0FDcJzK4ao9sZMYsnJX/nBv1KH7uWIzR+G00uhf+NjyMVGQxlaIV85HWvkmUxC+d MbDwswFCLaTSJaNKJJ//UCL6b6MwRIYKZW5kc3RyZWFtCmVuZG9iagoxMDAgMCBvYmoKNzkxMApl bmRvYmoKMTAxIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDkwNSAvQ2Fw SGVpZ2h0IDcyMiAvRGVzY2VudCAtMjEyIC9GbGFncyAzMgovRm9udEJCb3ggWy02MjggLTM3NiAy MDAwIDEwMTFdIC9Gb250TmFtZSAvVFFKVE5TK0FyaWFsLUJvbGRNVCAvSXRhbGljQW5nbGUKMCAv U3RlbVYgMCAvTGVhZGluZyAzMyAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA1MjUgL0ZvbnRGaWxl MiA5OSAwIFIgPj4KZW5kb2JqCjEwMiAwIG9iagpbIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCA1 NTYgMCAwIDYxMSA1NTYgMCAwIDAgMCAwIDAgMCA4ODkgMCA2MTEgMCAwIDM4OSAwIDMzMyBdCmVu ZG9iagozNyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9UUUpUTlMrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgoxMDEgMCBSIC9XaWR0aHMgMTAy IDAgUiAvRmlyc3RDaGFyIDU4IC9MYXN0Q2hhciAxMTYgL0VuY29kaW5nIC9NYWNSb21hbkVuY29k aW5nCj4+CmVuZG9iagoxIDAgb2JqCjw8IC9UaXRsZSAoc2VjdGlvbi0xNi1mb3ItUlBMLXJldi0x MSkgL0F1dGhvciAoSlAgVmFzc2V1cikgL1N1YmplY3QgKCkgL0FBUEw6S2V5d29yZHMKWyAoKSBd IC9LZXl3b3JkcyAoKSAvQ3JlYXRvciAoTWljcm9zb2Z0IFdvcmQpIC9Qcm9kdWNlciAoTWFjIE9T IFggMTAuNS44IFF1YXJ0eiBQREZDb250ZXh0KQovQ3JlYXRpb25EYXRlIChEOjIwMTAwNzIwMTQ0 ODU5WjAwJzAwJykgL01vZERhdGUgKEQ6MjAxMDA3MjAxNDQ4NTlaMDAnMDAnKQo+PgplbmRvYmoK eHJlZgowIDEwMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAxNDE4MzAgMDAwMDAgbiAKMDAwMDAw NTQ0MiAwMDAwMCBuIAowMDAwMDk1NDY5IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAw MDAwNTQyMiAwMDAwMCBuIAowMDAwMDA1NTQ2IDAwMDAwIG4gCjAwMDAwMDY1NTggMDAwMDAgbiAK MDAwMDEyMTg0NiAwMDAwMCBuIAowMDAwMDA1NjQ0IDAwMDAwIG4gCjAwMDAwMDY1MzggMDAwMDAg biAKMDAwMDAxMzY2OCAwMDAwMCBuIAowMDAwMDA2NTkzIDAwMDAwIG4gCjAwMDAwMTM2NDcgMDAw MDAgbiAKMDAwMDAxMzc3NSAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAxMzMwNjEg MDAwMDAgbiAKMDAwMDEyNzQzNyAwMDAwMCBuIAowMDAwMDE0NjYzIDAwMDAwIG4gCjAwMDAwMTM5 MDAgMDAwMDAgbiAKMDAwMDAxNDY0MyAwMDAwMCBuIAowMDAwMDE0NzcwIDAwMDAwIG4gCjAwMDAw MjUxMzYgMDAwMDAgbiAKMDAwMDAxNDg2OSAwMDAwMCBuIAowMDAwMDI1MTE0IDAwMDAwIG4gCjAw MDAwMjUyNDMgMDAwMDAgbiAKMDAwMDAyNTQxOSAwMDAwMCBuIAowMDAwMDI1Njc3IDAwMDAwIG4g CjAwMDAwMjg2NjcgMDAwMDAgbiAKMDAwMDAyNTY5NiAwMDAwMCBuIAowMDAwMDI1OTA5IDAwMDAw IG4gCjAwMDAwMjU5MjggMDAwMDAgbiAKMDAwMDAyODY0NiAwMDAwMCBuIAowMDAwMDMyMzgwIDAw MDAwIG4gCjAwMDAwMjg3MDQgMDAwMDAgbiAKMDAwMDAzMjM1OSAwMDAwMCBuIAowMDAwMDMyNDg3 IDAwMDAwIG4gCjAwMDAxNDE2NTAgMDAwMDAgbiAKMDAwMDA0MDExMiAwMDAwMCBuIAowMDAwMDMy Njc2IDAwMDAwIG4gCjAwMDAwNDAwOTEgMDAwMDAgbiAKMDAwMDA0MDIxOSAwMDAwMCBuIAowMDAw MDU0NzUzIDAwMDAwIG4gCjAwMDAwNDAzOTUgMDAwMDAgbiAKMDAwMDA1NDczMSAwMDAwMCBuIAow MDAwMDU0ODYwIDAwMDAwIG4gCjAwMDAwNjE4OTUgMDAwMDAgbiAKMDAwMDA1NTA0OSAwMDAwMCBu IAowMDAwMDYxODc0IDAwMDAwIG4gCjAwMDAwNjIwMDIgMDAwMDAgbiAKMDAwMDA2NzA3MyAwMDAw MCBuIAowMDAwMDk1NTkyIDAwMDAwIG4gCjAwMDAwNjIxNzggMDAwMDAgbiAKMDAwMDA2NzA1MiAw MDAwMCBuIAowMDAwMDY3MTgxIDAwMDAwIG4gCjAwMDAwNzEyNDAgMDAwMDAgbiAKMDAwMDA2NzI4 MCAwMDAwMCBuIAowMDAwMDcxMjE5IDAwMDAwIG4gCjAwMDAwNzEzNDggMDAwMDAgbiAKMDAwMDA3 NTQwMyAwMDAwMCBuIAowMDAwMDcxNDQ3IDAwMDAwIG4gCjAwMDAwNzUzODIgMDAwMDAgbiAKMDAw MDA3NTUxMSAwMDAwMCBuIAowMDAwMDgwNDQ5IDAwMDAwIG4gCjAwMDAwNzU2MTAgMDAwMDAgbiAK MDAwMDA4MDQyOCAwMDAwMCBuIAowMDAwMDgwNTU3IDAwMDAwIG4gCjAwMDAwODcyMTMgMDAwMDAg biAKMDAwMDA4MDY1NiAwMDAwMCBuIAowMDAwMDg3MTkyIDAwMDAwIG4gCjAwMDAwODczMjEgMDAw MDAgbiAKMDAwMDA5Mjk1OSAwMDAwMCBuIAowMDAwMDg3NDk3IDAwMDAwIG4gCjAwMDAwOTI5Mzgg MDAwMDAgbiAKMDAwMDA5MzA2NyAwMDAwMCBuIAowMDAwMDk0NDc2IDAwMDAwIG4gCjAwMDAwOTMx NjYgMDAwMDAgbiAKMDAwMDA5NDQ1NSAwMDAwMCBuIAowMDAwMDk0NTg0IDAwMDAwIG4gCjAwMDAw OTUyNjIgMDAwMDAgbiAKMDAwMDA5NDY4MyAwMDAwMCBuIAowMDAwMDk1MjQyIDAwMDAwIG4gCjAw MDAwOTUzNzAgMDAwMDAgbiAKMDAwMDA5NTcxNyAwMDAwMCBuIAowMDAwMDk1ODA5IDAwMDAwIG4g CjAwMDAwOTU4NzQgMDAwMDAgbiAKMDAwMDEyMTIzMSAwMDAwMCBuIAowMDAwMTIxMjUzIDAwMDAw IG4gCjAwMDAxMjE0ODggMDAwMDAgbiAKMDAwMDEyMjAxOCAwMDAwMCBuIAowMDAwMTI2OTY1IDAw MDAwIG4gCjAwMDAxMjY5ODYgMDAwMDAgbiAKMDAwMDEyNzIzMyAwMDAwMCBuIAowMDAwMTI3NjIw IDAwMDAwIG4gCjAwMDAxMzI0NTkgMDAwMDAgbiAKMDAwMDEzMjQ4MCAwMDAwMCBuIAowMDAwMTMy NzIwIDAwMDAwIG4gCjAwMDAxMzI3NDIgMDAwMDAgbiAKMDAwMDEzMzA0MSAwMDAwMCBuIAowMDAw MTMzMjI4IDAwMDAwIG4gCjAwMDAxNDEyMzAgMDAwMDAgbiAKMDAwMDE0MTI1MiAwMDAwMCBuIAow MDAwMTQxNDkzIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTAzIC9Sb290IDg0IDAgUiAvSW5m byAxIDAgUiAvSUQgWyA8YTViOWUzOWE2ZmQ1Mzc4ODkxNDYwOGUyZGUxNTk2MzA+CjxhNWI5ZTM5 YTZmZDUzNzg4OTE0NjA4ZTJkZTE1OTYzMD4gXSA+PgpzdGFydHhyZWYKMTQyMTAxCiUlRU9GCg== --Apple-Mail-75-682593164 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi = Mathilde,

On Jul 19, 2010, at 9:35 AM, Mathilde Durvy = (mdurvy) wrote:

Hi = JP,
Thanks for updating = Section 16. A few minor points = below.

Sure, in = line.

Best,
- In 16.2.3, 16.2.4 It is not very clear which = parameters are configured versus negotiated dynamically through = messages.
All the parameters are the ones that a RPL MAY/SHOULD/MUST = allow for configuration = only. I will add some text to = clarify.
[Mathilde] I'm not sure what you mean by 'configuration only'. = Do you mean not negotiated dynamically? =

Right.
Then it seems = to me that parameters that are part of the policy must be configured = while other may be. For some parameters (OCP, Route information, = DODAGID, MOP) it is still not specified in which category (may, should, = must) they = belong
JP> I see what you're referring to; a sentence was = missing in 16.2.3 and 16.2.4. Added.


- In 16.2.4 =93A = RPL implementation SHOULD allow configuring whether a non-storing node = provides the transit information in DAO messages.=94 Shouldn=92t a node = always include the transit info in DAO messages?Correct, what = I meant was the requirement to configure the MOP (this was already in = 16.2.5), which implies to send transit information for non storing mode, = but this was not clear indeed. I removed it from there. By the way, I = added the Route information and Prefix information that were = missing.
[Mathilde] Shouldn't = Route information and Prefix information be in 16.2.3 (right now they = are also in 16.2.4 and 16.2.5, so we have a problem :-) ). =  
=
JP> Yes ! Done.

I would also add some text on what it = means to configure the target prefix. This is not very clear to me. Do = you mean decide which of the node's addresses / prefixes should be in a = target = option?


JP> Yes. I prefer to leave it as is, since = the target option may be augmented in the future.

Aren=92t the 2 = first bullet related to the DAO mechanism and hence more appropriate in = Section 16.2.6 (or maybe we should just remove Section = 16.2.6)
Yes I updated 16.2.6, which was outdated after we removed the = DAO FSM. Thanks.
[Mathilde] Thanks. Maybe 16.2.4 Target option should also go = there

- In general, = Sections 16.3 to 16.5 can be difficult to implement on constrained nodes = without interface or file system. I would emphasize that it is expected = that constrained nodes do not implement these = parts.
Not sure is you saw it, = but there is already pretty explicit text in Section 16.1:
   When memory is highly =
constrained, it may
   not be possible to =
satisfy all the requirements listed in this
[Mathilde] Well the =
=91may=92 is a bit weak in my opinion. But I'm OK to keep it as =
is.
Attached the =
changes. Let me know if you agree with the proposed resolution and I'll =
close the ticket.

= --Apple-Mail-75-682593164-- --Apple-Mail-74-682593163-- From jpv@cisco.com Tue Jul 20 07:53:54 2010 Return-Path: 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 075923A69EF for ; Tue, 20 Jul 2010 07:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6unwPWz9qhEd for ; Tue, 20 Jul 2010 07:53:52 -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 298D93A6BF6 for ; Tue, 20 Jul 2010 07:53:47 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACtVRUxAZnwN/2dsb2JhbACBQ54qcaVemy2FMgSIWYI1 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 14:54:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KEs1VT001567 for ; Tue, 20 Jul 2010 14:54:01 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 16:54:00 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 16:53:52 +0200 Message-Id: From: JP Vasseur To: "Mathilde Durvy (mdurvy)" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-76-682709216 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 16:53:39 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 14:53:52.0551 (UTC) FILETIME=[5E89D370:01CB281B] X-Mailman-Approved-At: Tue, 20 Jul 2010 07:54:38 -0700 Cc: roll WG Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Tue, 20 Jul 2010 14:53:54 -0000 --Apple-Mail-76-682709216 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Just had a quick discussion with Mathilde to clarify a few things. =20 Mathilde, here is the new version. Let me know if we are in sync. Cheers. JP. On Jul 20, 2010, at 3:02 PM, JP Vasseur wrote: > Hi Mathilde, > > On Jul 19, 2010, at 9:35 AM, Mathilde Durvy (mdurvy) wrote: > >> Hi JP, >> >> Thanks for updating Section 16. A few minor points below. > > Sure, in line. > >> Best, >> Mathilde >> >> >> - In 16.2.3, 16.2.4 It is not very clear which parameters are =20 >> configured versus negotiated dynamically through messages. >> All the parameters are the ones that a RPL MAY/SHOULD/MUST allow =20 >> for configuration only. I will add some text to clarify. >> [Mathilde] I'm not sure what you mean by 'configuration only'. Do =20 >> you mean not negotiated dynamically? > > Right. > >> Then it seems to me that parameters that are part of the policy =20 >> must be configured while other may be. For some parameters (OCP, =20 >> Route information, DODAGID, MOP) it is still not specified in which =20= >> category (may, should, must) they belong > > JP> I see what you're referring to; a sentence was missing in 16.2.3 =20= > and 16.2.4. Added. > >> >> - In 16.2.4 =93A RPL implementation SHOULD allow configuring whether =20= >> a non-storing node provides the transit information in DAO =20 >> messages.=94 Shouldn=92t a node always include the transit info in = DAO =20 >> messages? >> Correct, what I meant was the requirement to configure the MOP =20 >> (this was already in 16.2.5), which implies to send transit =20 >> information for non storing mode, but this was not clear indeed. I =20= >> removed it from there. By the way, I added the Route information =20 >> and Prefix information that were missing. >> [Mathilde] Shouldn't Route information and Prefix information be in =20= >> 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a =20= >> problem :-) ). > > JP> Yes ! Done. > >> I would also add some text on what it means to configure the target =20= >> prefix. This is not very clear to me. Do you mean decide which of =20 >> the node's addresses / prefixes should be in a target option? >> > > JP> Yes. I prefer to leave it as is, since the target option may be =20= > augmented in the future. > >> Aren=92t the 2 first bullet related to the DAO mechanism and hence =20= >> more appropriate in Section 16.2.6 (or maybe we should just remove =20= >> Section 16.2.6) >> Yes I updated 16.2.6, which was outdated after we removed the DAO =20 >> FSM. Thanks. >> [Mathilde] Thanks. Maybe 16.2.4 Target option should also go there >> >> - In general, Sections 16.3 to 16.5 can be difficult to implement =20 >> on constrained nodes without interface or file system. I would =20 >> emphasize that it is expected that constrained nodes do not =20 >> implement these parts. >> >> Not sure is you saw it, but there is already pretty explicit text =20 >> in Section 16.1: >> When memory is highly constrained, it may >> not be possible to satisfy all the requirements listed in this >> section. >> [Mathilde] Well the =91may=92 is a bit weak in my opinion. But I'm OK = =20 >> to keep it as is. >> >> Attached the changes. Let me know if you agree with the proposed =20 >> resolution and I'll close the ticket. >> [Mathilde] I think once we implement the minor changes above we can =20= >> close the ticket. > > Here is the new version. Let me know what you think. > > Cheers. > > JP. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-76-682709216 Content-Type: multipart/mixed; boundary=Apple-Mail-77-682709217 --Apple-Mail-77-682709217 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Just had a quick discussion with Mathilde to clarify a few things. Mathilde, here is the new version.
Let me know if we are in sync.

Cheers.

JP.

--Apple-Mail-77-682709217 Content-Disposition: inline; filename=section-16-for-RPL-rev-11.pdf Content-Type: application/pdf; x-mac-hide-extension=yes; x-unix-mode=0644; name="section-16-for-RPL-rev-11.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnVu33MQRhd/1K7TyNF7LCN0veQPHZJFgx7HPWjwAD2Ag kGBuhhD+fUqtr3tm62g0LY0PPvAgS9OX6qpdu6ov0vkp/Wf6U9pn9ZAWdZ21VVoPVdb2aVv1Wd+n P3+Vfpx+n7776HWRvnyd5u7/1y+tTp4VQ9Xm+fToeNfVWVXUeZ92ZZ319VAmL1+l79+kdeHqcrl5 lb77QZHlaZHefJ1+kh6KB+k7Q3pop0tmlzo9pHJ58iB5p7Cnn09lvp8u3P1ruvtKHn4x3X1rF6v3 3XRxd8nhl+nu96kIPT2yu6JMDz9MT+nitd316YFmvpx+o6efTagmyESjlLzVymfpzd/Sxzem81Wt J9u1XgyNKbsYgtZTp/VkTeujem/+HSGPQ0GyEwVFkzVNW0/yKAoSRcE2eRSVSZ5GojJvs7Kt2iV5 Ui9P4lGpAOTuZgRJnh6+ESDwI3AEAa+ALD8CiK+t4hHdYIbWqAjkqOfukgOQe2nVDY5rWKPeYmO/ mEzWO7JQEvehwn+XRka3c1AnK66RRroGQixKpupBBVR4ZXKeYYTksJERgkKNEcRPkzfJjlWZG9dW ZdqBwwh2jPaLHbwR2Lod2mzojLYv84axNfrXyyK6n48eYIz6bDRVkR4+mqD10C5HF1BGh2BpHL9w jSeH38ZmrDl+fM7trHV+9YVBNfzvLolvgRChuGIkP06yBqZfgPNXNjwLWyoy/RE9EIYxcocauDx1 w0gOmV2PWqHoKt3AE+qbP05CLY4pjntOHCB5s+lBVXRZNzRF6gF3bxyg77K2A/+rceoc/rEFaj/D 0g4uiowzLO2gABKBgpr5+8nMdEsr8+zEYZbqa1T6tTV2jAqnrhJCxcydGAQ0SxcO5ckBmdSBVCMU od4id/joqfTA3UZ6nyd8f56x/IYc2HKNC9lGaWTalWWTtudBNUs2okn+mpTc8J1VfROZkmMavSxC EFIBgljm14k9f7aLJMgn3LI29dgRzIqizerWgqsfZ1wwQ2wgCKwfChX7ROOHyeUoQ0XcivqMl9/U SbRRXA48oy48jzbRve/+vCOE5NAXhYXon+a0f1rDosGwjqGQRqtHjEkl/PJBEmntHaguh8FmqJb+ eWvfm0jSDlnZL84wZjOec5FEeRNE4WQBZm7e6c2teseWsQlAsjyVQQq6p18FewCNm7x/N8UQQKto 4SHw5jeYghRPMY+rreUrOj7k1PCL1D6SeHWpdxAz0SFiICIN4AguaIXckRBGYyr+3FqOBCli48Ut kgsrATvcoiqbrC7zNm0nGN4br2iGbBhnPvsnGIuI+mQC3XPj63Fi8MF4tcn5I+4bu1qC3k2XfLqw yvSZ3VnOk92lOYoqz/q8NpZi/PfHHnnW5TkLM29/oaiti6zOu0jaXFwu5KHZ8/Ys6sPpITkzjqjU Bg0Q+qC2c2wwOnByeSlvhwMX48rrkHep18i9QUxVZkVRxywRbMtmdy4ttmWZ9SWEsmvG9sRAMa4f QfLwuRL55jhEOPiftW3EA2eFpt0sS4lMZ1AA9fEomq2X3IxX4zPPa5IRJjFr4csxTwf52kj0uKSo yYRGR1yGhwwLoajHkjh64LcXjId+aWbR13joioS8lmawlEXXHYllEreDUdmSdT6Y/0Xjaxvcd65c t0WVNeWwiPfZZPJcXunxrgbmTifUPmPCijoRwBiBUx3SFzOeCXwBp1gf/GtuZY1G2nTP1LArs6Ed qlS1uBr2TIufHgy2Nnv16PUKZOSfPph+dvpIDqwlok98AwXiMGhOfQqtUC+dEhrvtiiJGrRGGq3u 54UVIZPD+3geXS+3i8/RLr3Q/HGUjryQ1uSKNNdiDExWt2uq0hZQmsG2IeNBf40TXlrQOS6T53VW Vm0dEZPPOeHMAGQkuMRRuWPwgCWxnHqtAmpqNPgZ7rro2bRGEUxNv36Jj6BH//8xBB33P6moUUvh yf4RY3o5BRcFVbYXPm717dL6W9lnRVmbt2OuM7t9ycke9HXwWYdzgE8z1NlQR+0+XidP5G5o0zdZ 2+T9FXD2iQk8RfBXyCrk4BrvB7oDcwr5xCdmhBaa2bsuAZ3pIhjAZwkCjNIRLP8YAr0Zr3kyT8V0 DcSPyl8ZLE6jXv67OYZ5Ob0hgkYPfqOVtZDC5mn8QFxOGUnhOyJuVfRZWeZN6jEWMfHfhvmd04am a7OquWaj5wWAADuLvPz5ZFvgrGT9ZKxv0w6tuEjWE4xCFgyM6BhweA+kL9rxAATSq8yuLgFI6Qt4 kxkARMbz7ZSqUFIjwppjeQXSkx8kjq1JCIN8OurM1ncYDq0fR+VS0BCv7nDZ2Q432cmnfkjBUQR1 RsN6h5sdQ0vbZXnbXLO+dg6XjqXm04MJwphjEZfPcBOs4gJE2IYjXCh5YnlM/onVNy95juU9zB9x X00eVtutkShrPyzwsbKnuF5HpB1TsOk2ZRDZ0B5JkKc5buQ0s6wqywXsyFYjlru0kIHGEBR/RF6s gf5QcQieLns/Z2OnxEgbf5ZEHWM71Unk4cGqsIOEXVcHndwb72o6mz9GLk6if72QTOApGCUkTW6W 6efcMDgmhiQpSv0YF0kO5eQbzXRhDbyf7hZdRCNSiFqCHAYym1ZSVkXnDmE9zTMSaoBZXJ8MhxqL WgqtXT4NiurQmcYnHrru3bmiHZ4ei+p8sOMAvaF6QtG9AXXd25GXq7ZkzuTiDjDYeZHisXMWTbA7 QuN4HCAv8jJt4scZHaodue3NQKvBjmH4rZdVwt8mz86Vxcb2qPJ+eeslcmXxPSOVMX6q/4IOgBC8 0eUTsBvuH6jm9NQTwY2S+H1oxUUsFssupApKgOQIugnoUoWws0uXi5MpxfNEaunBXwNNn07tVA9Q HQOhOT2HvjhI1Rgh3/erikeKEPqPWk0OCIPiaUZ5m+7DWGKzoB1OWpW2LZyXlgUJCFcXZrc5xV4n tZO63eB3u1ad9NxKH0ol0ijEvd2YJ1KGGpF52Mkup0NqWP5TMOgCC3anQ5yKh+xZcX50UfxFfwWZ 4IU2qY6HbnYBdUEaY5FDqUBH6xWLMOcz47knqEbODSkyS9jjCVWTdd3Qpo0g7x54QlFkjYXRhfd4 Is8zYSGwg2oxYqAqlzPwULVPkWOKeHdGKEz3ed3ZqtWOQS86DCPysNQyeP92f8edQLdTUNTUWn1l kfy/mebVGIsiahddqlTHoQcsyHKwxjp+w54a+dRftcjachMYMVnuDhxVaa/GuTw+GhzbQtXe/C0v szK/amc4kLXLFLChZiGAlEN+wANcLMAxrKVgGU2bMCzBgf7I9ygJyOgBARW/L8g6n47XMjk8Ga+2 ZPSM51k0GmZrFTGbTMVgLwwUtslk3Lim/j98k8neucyGYvmVu1k6fw08o/dM6350m6qNmPaey6Q+ NIOaXQPTuFhR2kNb+cvlUk13D6cKi7Sl0P1Q1rChJiU/uuUhRWj6PetonPg43koOil0cSBulCA/B vNIebuGXWPAgXICimk76vX8U5aWaWkgOxy18p0ed1+CL2iCdMcrjOrub1iAC+8L4JI0iLIxA/UV2 fuNvFjVZkduLzBvwFo3/HflcWJmvx39VV71aNxHc7d2P6d06tKtWQfOeErEnUObuNO9IwhQWnFNU 4X5hou28Lzkw38YXuWPBEbloVjMJ7cveHhj9GycCZXgPbsNDLgiuQA4ducYoghDUo4j6IMNHRaEV Rzkcl6MVVa31HpmBEHOSDS/XV8WQNX1Xpoqp1dlpNMZnMXB8XT/6teq6tTNz1eKm6izknKN4TzFY CKVCMRiD31C/Wp07bIJL6AIIRfhtysjD1ioVIdDH0PrNeL19/NLkiTTyDuIoejvXWpT2KYbzSr09 8UI3ANVrc40avAIUvwvUcFzdopNFamDVAC+iY8ThDufljrijhgvCOHdVV9bqk/ipX8+iojoxzng3 B7Wr8YMZQ1V4O0XkN9G+uAM2x3jTNNlQ2cc79r9poXSH1f32FJ6iplW/I/pTEZtgIVcv8bQOFkAU RcLs4DTrozEuIAMq0HSPIgBLZQFDBBXtj6mNTkgVdMgJr9AKMUJTOab2aImSOtrsLlmkbO2oWZ5b OhQPh2h4XrP7Uddt1tYxW6nbxNk5ea6rzo4D+U0wjaSRoesfY5CwsymAA/jhEVgeMIJXoKIlgbRW AH5n8p0FkvTMD7SVXRf92gmaHLQLRDPXjQx0p9lD7AmIvMrq2rKGNRvMIt3hnS0frdmGCXtrLiss 7G5CBGpTYoDxMCW6pAhmhuN0TYuSASzu3K1Sq6Y0c4M6QFCBdX+EoHdggYBKdTQNSbF058MsFa3D uwNEVdqSSrNqgDkcbKzx3zDaBodjQLXjxLkdJV5aAY+kCHSqxntBkvkU/ngyXt3y1XQYCTvGzLnS Q22VF85BuZWSzH6zdmmPy4fTQ3DBwzme2GR11TnHrcSiFLY4zI8mybhMgw2fiNDIDVaRApk8ApWg Qhk3Qt3joiJDQygqIDBeOB+2858j1E+0tvjwlrpOfONNL2/Y/mjnsk3QeG/STTvo27X+9MDqdtW5 uR9qxPre3nxbBxMtQssHu/gwtSOxdudI8rK23GDLSBXL3AFJMsYAfofhW2Aa/ZnRPzIfGlMMtPCc 28fj1VYfKfXxeNuGY/OQfMTrG3+lPWrQy6/TAowu5TEQzStwDpIVNWf4mJjzre+sJ6MiDTzejPR7 Ue5wToMKptUTx1v7qshpluJOb13+mEuVN1lZ2Av1av5bmeIfv85vx8psHeiaRRc0rWlHsL4jf4ro SzzgzXsq5gfc3IFx2vZF3W3iU2WQsubiEDXNRLxZRGPqcDwkBnF5Cuodls98fcvHaMU0KObycMJ0 6PjUm8NDB3v1GrIBhkZjqhJ9qyMiBh3dM9IjdhBiNZ5ntANjaS0IXKX+bXO5nWd26tyOD/dv7qTC Ip/pN4CwLxyp/KlgVSAHJDiwYDXvJLSmdAgw1NdO0RI+eUiiRKP0q/UYGdBjEIFNT2cRuq3jmZoa z/GgZ+PV4tBHdj0GLfxKW0A40K5p2GIWF/TmpEI1VEdiogmjocLD6KCwxwXGz3qMH/mJh9w2D9g5 VakGk6u/6igAOkXR6BRgKwHpxw9N37fTZUKCmtnD/BSS4eyahg0qZtG2tACfbPxicdH29iJG16Vr ynsb886qt4NXw/3ZyK/sJfoqv2oj/z2IQumPO2U47tSpNZyCLh5e/yWgUwgnhz+ZrG168CLTyxJ4 3at8dxdvC/vSWdNXBlAMELeyr57k5UafqC7Ej9MwxG/z5SDeUTGmtwRemYBQ46gjJHczhcErgc5d pIDHKQoOQsBwjH8rYEQqepbqxxzpGd9Z7Ttb6FFFv/1Uv2qr8VWGa1J9TIRtif+oHxUH05zGfwyN hShCY9iLxmiFh1xY38T46rA81EUxn2EsnAwI0z7tfoYzBKYr7tQX2Jsh3UAJOMYpB6The8NIQ8cM 2D0MQtET49bwSQW8jSLIHbTgXJCHlKRbE20b6LedKahs/aYxdlkB2VsJf40JVlyDeYygWTmqRe1Y hqRe6QgIAQwueIDaicZ4+IWcoOVh6MjxHk0DfWAFSPEjpF5LslZ8JawJMVyXIs+PvJ8B4mkex8gU zmwNgHh6YBBUYIDaAxXCyJgsOODzGxbgQmN+nGoC89RIr9iT4I9bEX3RpLY3eA6Fb8UpxkMHhd/c vxWZpr+qsf73C7w2Fxg2oCZ4jvvKKGY44zk+kN+dMQp7SSgv2jJ1Ry7C6NcXHN7ZsjO0bcGhqApb ALEVYZVHrTFDh619r4UGvEcJAc7gOCjoD+upp0SCadTdfMp3Si/hW6/UgJ2wMB1yUSIydzuZ3/1m HDcuSJ8PjAFLF+UOm0FKlTACTBK41Q3b2rw7uFXjPnDZVzPzrsPN5IvfiNwGt7ARWdkrQvZprKV9 yNtoQ2F60SiEgdEwiFgLOGoSDYUG3bszSTF+e7K1g4+bVACqiTdoYkZ/OAeKAc57PU71Q4fkFvMQ 6qZTVFBmVXnxaSSjMSxHmFRDLK6iYWNlcpJzJR0NskyCM3F+BnYzTub9H8IJBymRN95DZxM1d+r0 wge+xrdGy9xywxU4zHbmr1l+i37VYfxuXV5V13xgH0SEWOHmYtgEkIIWJXvqzXMrx9lh1uYyLeop yfOQi2IAc+MpgY9dYzRNBSRDFioA0jOtOAF1m4PGqAA6QS6NceGhd2nXYVh/IJ2mGR2ZahJBaY0B clTLkB9Ja7dwPJ6gXv8QW9nnWdNVlkjEAycayDuy3mOksW8ndLU/8nIPIl/e2VExf8jgUqKFyfXy fGQry1iejddbexUThMKxVIUZDS0SK0ys8OLVBeoprniIj3BHUqdODCwJyPiW7pzTND5CY+qTugul +7hITT16WJsX+JTSCZrMtvG1ouapdKH0RPca0yiCh8IFKih3qJ6S1vvoqHd01ts+1lSPf7aoAoj3 5fRNOdinLu0DJ3FLwlhBL4BOVewPe6N/b3fwho0Ui4sYZt0BKEOtysyAlzbpwXeIqMFbXNBRaC0K Q6OI7wMErf3dUUD4YC/DAP6LiOM3hKMZNIZ/LgqF3BoC8RPNvnFallYQgodH02wLRZuWAXNb+7ZD 46kiyv7Opx0itz/zaf8lNy+VeUOKNf0Zz8MPpnWbBOWpFbz8bfwd8Wn8NHfTVMNMyLcfn8retGcL FPu/kTBhMvUfkT6DSfeZdvUJfAqo8Bv4UUxSkiJPxhm87eQQ1c506E4gWw50MvWn/sejE9n+mENz yP61D+/FiONv11iEOckR8mPPeAwsAn3wEN9CfoQjJhBZEIo28WVoAw9VglL3e+iH78iHkrRCf35k tGbCRHrqHicYP5kzbgbFgy46Z1zIYaPfASw726Zso84eXCPPpZw65LBll2dlF/Wt7mh5dpjrKE+b Z0PvP/58DzirKez9teVNxdvLSd7d1VE0ZuJSwV8ca2j6ir9oXFzkF0rOL84H5w9P6emxC+7pIXzM yC0YIjYSOv+eLzv+ZaxoEwScXxNQ7+A6B6A5losqa8BOP+XTRbVQym/6tdL5aC4OcV7hdPjz31xj vELgpz5oHx5lvFQcJkGR0F7aDkRmf6zqDf8tUMul7UMVbVqCxK1J9f8BuHWJuwplbmRzdHJlYW0K ZW5kb2JqCjUgMCBvYmoKNTMyNgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2Jq CjkgMCBvYmoKPDwgL0xlbmd0aCAxMCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT 9StTtmXVTAlinX13nRxnp5ndLUUihOiYdYwuVkSHiE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+ MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8nemHZ6dEzb/BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqU sdb7NnyrdpkQUDQqd2QDPix5PODjki/knTw1ZyQbE6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5Mz HJdxIjvILUUjK2M+IOt22rTJ76U97RlT1LDfyDc5C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4R YPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAqfa8DNt8Afl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb 7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C+x8C2x8DiWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/ onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkmTFkFztlf23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe0 6OomN5DvZ8yePnI9r/cZt2c4YOWAme8bCjhyyrbiPBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334u dSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMTnfHf/MYtJGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsY GuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVdFhW9WOGeFX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l39 83xtob7imXPPmsara18ZV2aW1ci4QY0yvqwpiG+w2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8 NdSlCGVqxDjjya5l90WyxTfh51vL9q/pUft89klNJdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxr oe5VD6p9aovaCk09prarbWoX346qA+Udw5yViQus22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0 +Q9NuLmMaQnfEdw2cIeU/8NfswMN3gplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjc5MgplbmRv YmoKNyAwIG9iagpbIC9JQ0NCYXNlZCA5IDAgUiBdCmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3Ro IDEzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVnVub3MZxhu/xK5BcrZ5H AnE++I6mIod+pJAhN/GFrAuZkiw7pGyJlp3k1+frxts9KAwG0zO7q2XICyww6O7qqq8OXX3Aj/m/ 5z/mY9FOedW2Rd/k7dQU/Zj3zViMY/7Tt/nv8h/yJ8/eV/mb93np/79/ozJlUU1NX5bzo8Pd0BZN 1ZZjPtRtMbZTnb15l//6Nm8rX5bL7bv8yWdVUeZVfvtdfpN/lN/+Of+XW1GzS092F3qqrui6vs09 PdkePV/mN88/yj9p85sfdJnym7/Nd9/Odz/p0sXfvv0o45Wv8tvfJnTiCqZWZVX0/VTlA51IYeon D8fUqpSUu66J9KQx9VMxrqrzGxj49czO73QRq+GxoODucnHVX7i77vLN3MJPqkwCO2rvOoFlCVpQ 9XXR19O0YtCRFmRLLUgV2CaAsl2trPpOatnX5+iZtTLzWikt+NMsDHCPhCSvdMZlF5qPauiLchh2 6cxW1uMOfJMs9/k2jMXQN5fyDYD/ZYbf25mLujwg38ap6OryYCFmjbSA+yUZN9VFXcraBou1RU8e BBkBB+P+GhmXzrHoqLI0RyVmFdVQfTAcq8umGLthbVOtBI85Vs2sKudLtJ7p9vI+7Oxv1fqY3/w8 u0KcJrTUhsADuYmSvcLl12NbVHW95uSuy08OQbzxza4Micq+qPum39KFtW6mhkQbzuCcUYshWj/1 xTQoVtsL0WbdvIw/V4aM/TgU/TAmBDfyTZtQB3oY3r+ZIOIPMxBxZhTH0lDg/YxjLng/yr2dK7PF cYkUp06KE27wCpXx23dzZf8zk6RyidqwIe28POP6B8WO1VjncDdB2OIuxB9c1yIao0ffb/ETA05Q /OP8ys/zBRbEV3xo/U6/VYr04KsNuD23siBqiLGchBiKE/AhCN6M9sibOkv9obLLJJBdMCSqx16W vdKgasb3lgQeRf0V3DRjV2/Rc+xo4Km9AGe4/0aylBuwiEc3fph9Q6FX5rj+Mn7bIegZxFcaWQ7j lMuWXNDB1w6J1Zr8TQ0ANXQ0os3jC5bw8B+uUg154ALYtxjk1SW8sxuqsbwEyX9UpRqVUm5PVf8y c50hFgVs68jOSpI3NxWI9qJWeYFSy3/PlGEaeBP1X/fIc+vvcwEVfzg81GNXlF7/0vGw6e/asuia smzyblKNGhS0dTGdTpL08q7dIMOrMU3f1qNyJt1YjmU95VNRTpOMsotuvtvPeWya/P1Ry8HB91Mh 63MHhwpykOR7wUkKjnhBR1RwD8qPJdDDwN1iZW2dPQKCAzjE/K48eAo/cgvmADAPvU5FhQG5Qe+g cVOLN/UAO0U1UExLG+3mN4FEqyu+RPRcgRrLOMwlD2kRbq411rOKN6HmoLGXqc5Frmsai6lvhlzZ J4ekLVfxKK6rm4pp0rj8fOR6KlS0Ych+pOIzfEHQsN9iEWEgRCSLLLF/HoPZjVWCzaCUylAeUAe+ +I0AkoeQZKumOLRYkug8Bf40R6Ob3oXW6Qr929Qcfvt6djkYdoiwasjDGFgvPQi1ROl41tNpy09e oWMHpUjUhisGlo1S2kpOdXlv4Pf4A8u+K4uhLMlt25TBSj1PqQO8tV59LWcvDCRkTSPiRs6SycNJ oZIUuraSTTK9zsqiLCdNSLg5ids3lgkxnGXC4dvCJ8f9iw8y7VA1lYb6k5y/JXJv2mEz5jg5LXNl DqJvq6Ithw/Hkjd1UVVtSg5C0CV91M9Ro4ToYoXa3AFPLs/02yL+xrvjXUEr4TRmGrOyaXzXSuK9 8heuCZFBCTSIO+rGOp10IV9lDzZ1NMlmdc6Dw+iEYDAZiEc2tJjKbhzrVqFuU09tpUHv4a/dTPsh Zq3rYqyvnjbcjtGPCA0TmTFGr0vNd/YmRK8nZRIHF3+fCdGPar8PNlSNEvpJ06fSi1uHwXIdmdug hOAdKOI2sfBowhrfXr1ikODvqPPNPBKwQzt+O7hiN1hAEdeuZDmCpTLb+vU66r2UdWRB8S7V0Ww1 A2xHN4wqYB69txyFjD/OQVECLxgGYYVgCXVyZ9kFEVRNcfppbVlgAvLxlWZhpMWrFjLIgHZ5hZaO xjTeGAKrw5hmIw7YVtHlONdP4ZxTotli5H0lBzK0eaMVCxoSBBWuys5r7mG2Nqq60kOdGzssh+PS tEHq/0i6run0uunbBNMsXYfF+9rideAKj+Z1PADFoyiqwGUebZEEiPrhkwfABzCBRUDMnR07oELo QCFL5/ML2VXI8qtYjpGl4DH4K3mpgKxSnmhU9FA1SuCM1Rpa+3mbe3QKtXxB0yjh1KcDZdOHb2ve EaVHzlGMUN7LefVDAutRNaZTVDO1TUpm6z4ZIbOhQYaC5w+HEcptaoiROGf22oUJSnFjO4Keo3Zo ZnrOmAKvXK3Kcb+k9s91Denp7OZSjxRzf2uP5P2LdWxrwn27NGj9sLWW5CiwOtGkeMty63pxCKVs E9Zq+aRRpmlv3y5mzr6yYrG1ZfAvellvtCnPb0nG3je/Nva+sj0m0EICRxk1wa67TlrK1l49SmhG rTRsyj7vLsI9fQQZXOgOYiOo4s1Tqalkn3NkU8/1GZ/Tae1CPXV93mhuoZykVrOpUTjjqvzOm2a/ aCmEM93YFIMbQK9s0uMNXTrNdzRdokkCoTa1DTRR2r/OwfMdsYycbX7fjl/QddmDh5fzoBmkUnNC ujZaTrkW8+4y2GWofCKgUX0ENGfmSttJ/qPrcoSWkFC/wKEeEbqOLDrBvq0DyOeZsTmwmNF+GRtC 7Qmrk7t+KMq+uzrNsJWWO9L5S+jpBk20pGTl0rJgJMqsa2NR7XP5K4XQ+CL0wmoXZtCayP9VOQ3o +Y3FNRS3/hX9/cK5UrXEj4eM8YZ63RNDq34symaY8i6ZoZt43iJnA83JS626dtTSpqQJq7vQI8Sl Zdm6ZtLSiDJxyIk87eWfJd0+v3nqhKyYkkXWNgFgwYV95RUQt45bfDDDYisafBmb8AvvqRT8UhsP rW/3Da6nhkEjURdN7Lmh52re68sypKIvRGvQwkMqg0G08OVcyyvXlzq7+cxdFWY+8/cxsz3pVrFz N1/G+fKVLiLg4/lCfSGWZ6mVZSrc2NTKZq4U00ATqtspZXZ+MmRDC86hrimnonJLWy9AXbIW3Mnq Npo0GsNkyO48nswujLcXEmaI3NpG4MArvzLiW2kPKQ8Ehvi8wYyLCPgNhNPgpqBpEEKhicAHI8xv VMYrgJm71dCFBlEpXrUtrVKCdN/qBh3lN4yGpYaOUjcXOroZmANlu2fkqdjt7BLNH0YtTpXO8jJm vdR8orc6pRjZ6XCkadw6oqaVYiyBeHLuMrtks9QpelI2b2krQTFMbWIMbzViDTtv0L4xCfArYcfO obVBByEMIRAtboUIxqIeEGE5oRcDSnFQg5MAfJsThSDZdpBa0BJasIpAZbx5UOeHM8O1YhCNNYb8 MuliDpb6n69WsdB5dIx+rswIPITN/Ih4uPjy0d5Za0TzdpyoVxKV8wov0WgKf6i0CTKwax4b7XqJ ZK/llfPKKfzOTWAoG7yx9ilxsYdlJrJAbID1nRT2eFYbrTotvfymMG7O15adnZ9MlKK4ZjeUncuq nDa9VdcV7dBUOdxMm3sBxFgcdW6D8MQk+znSPYFacSQClfNqtSd3VOqrqqZuzhUMY1k+zCC56jX1 3Ghh60WswQ7CGiw8D1F61pntoQf0AVBMAKijMl6xi9Z4+Pkc23L5NxcCKDF9EJfz/VtRShb2pNo2 rJ7Y31AXaAvB0h9mP8er1v5j6uVTNlCzNeC8xmjJcU+N8knpRmLTZm2D+Cik8LOrGnHGZKQi/U5p jHUuUnNnV0ytXpI/0RRVXWq9VdLubtBiL4f0hBuBEaeCMgCMWC2eguiBtQ00Y6ihKCh6NtwdBQCJ XSkEabwC1mIU46dCVu1aPFodo7aNECe7SQhxqAxtwAbaQInY+8g+OoXjIQTSHqykajjKmygRbOLN 4tiv7Kx7iRqW3XcKUduoi7Zz1hHIJXiOTRW7J42fJw60iU9nLRRTlXrAgcU+d0RXViiIdonkOEeH TCkOQCj+XxKY0oWIL77psWshQTkQRWXUAmYtdDG6DGkpTjlbtaXMRo/8FvXep3csElHKSLzPwxzs uEM3tbzC17x01yq7wQXx65bPiecgwCEYbO0HWdZNwj+lyRdcw/1TT0J+85uVo8nu85yPpnHHe/RV hN0HowaaD+u1muYOngCLjJy52M2kxDf2zegzPEwirvwA2PoMJqBBB/ASqqPZ2l9bsvLDhzVOO/Fu q4UCVasDXgx/jlINyxMplPMKTsZqP92G/E19YNIOLaYAd6FSgI/+cserS35lYUshLdEu5TZ1wzI/ Cma5Ro32lg3lN3+W7jQxP2Rtib07s6TvMklesienKTV11dbSvB1JrgaCyQ5ohSwXgSXPcbTOFTVJ 28lPZVODCXtx2qT5iP5j/d7GeMoCAedg5QryAAI4QqBkL9bi9WoL1HA/R8G+f2cJ3JibookV1G11 vIP6rwMx745o0eoP/YVgW4vVyei4PPAtnyCbArRAZTRLgWUH3WhquY4PxtKQ1O4BgV/reABtZc/3 gPYowNfpOmWTuIUBftsL7gTuW7bD2ih0L0rYTohMZUDeyhDBguC10fOVUQAAUllALiijbhuHLZGb hTifmOla5P7+RvjSaU1QWjhNz2+olDtIRJstL2g3dnQJ1s2Owlj4RHfpJzFsHIl4naT1KBBPYGDX Wld8DCxzlagW1wz5K3dwm4vETsPwUbRCGbapUf50I08Z92PFk39gqr0gbnv5/UeChABiscAo5bVz HGmb+JGfDR88CuKieKgBYCAECdvfiDe4AKK9JRIWtFT2ylH/C62ktN2HHB7avp0m7uG2LdWj1l6X /ZC3oOiDGV60bjN/4kIdOGcvgCMYDJn+h7MNbvNXM/V5ewnV0dr56CbQCex/EESVHgMoFjYky7Cy vEnn8R9om3VRNIjyUMCu0eUVyoXhNK9CDD/ycDliiZHiafcV01Sb7ovOEynKnC9G/oEYumYdCA9j nzzzNo2MNR3W3eLTeMjF0kQLtC7eJ4JqFfCnDCWbWjMRlXbG7aBKBn45krzL+OPcAUeHBFgzaN1p 0hqrU+MPaxRhJvyGw5H7PhYAUJSjgFUA+alEWVzh/Kta2Y7GxcSm848/SanzTrTAMmlL+l3AkT44 rdxJjmGpz1HaY3XwZcI+Y7vC0t7ZlSif4tWfz2bjtbtViAKegn0FNJiBZZCRheUqNkCnAEMHChCj rO2yt1ds7LB2GdNiByD2FSwp7XFRbJOI6pWF8ZM6Z5Yp1rUOyGlGhbRILcX7f/Jw593WbilA3baR HpKLlxw58LNYrEOOH+7IgVpzdv0kq7yD9EcZB2hOUCP2lHHAXSyBOJu29LUtNZ+uo5f2hiXzMRGn vMTvnAZr6WscOnhXYJUGDUTJ+e20jsfww2ZXbE4I5cYD4XNowSrwHJPEcQwFY8TgoxAKWgOgRYqJ an2Ns/KnCU3KQc8i2BoZPgZCm8lt/g+Tx7u+4RdBqCyfdiin7gdGjvay549uHXxP7XA7i9QszgkA cTthZf0X4RFxkf0NJwmMUQ16YSG+2RCvULU9nZNOUPV2uE6llOdVfxfXfjIUgKZNQq1m0V30jOEQ WaqlR89vVjHBi4dUO23d1fZdLSAKuEqYGrsM51cuZGsGt684TNVZvVvZgVOm2KLe3oXIinWeAIYL 4kfECIffqAbji4gBaFgXxzuSY6K93AiDzgWvVdcUtTu1fY9Rx6k0gclnkQLGnhJw/obnkE6HbFBp FQDIwx2LdXjFK9Sp5K3PzcFdxstWA6hmqXFxiRbaiP5a/bNzpjRvvZd1grYhOoENwvgEVn3mWCOT SDcgHzJUJFHGV/jERsfydL3b8GmU4fEHcI1WAZbV9mze/SsnaEBkwABziqifSEaaCeAh6EVEEYx+ PoNakKLFFA1RIOSSN+S+PqmPlmjXwp7agNgBNvM2+OWEDb9ZnxkMFWAm12UVxHc7C5vvYn+Xiaig 789nRgVs07fQSDR1fmKEimDVkTV8QNzrTItBm5xzi7MPAPcyulr2nRCbXuOTELFduQRCkTvy4qEF GiMOxIXwsGV7SxfWxs/Dhlpob0ZPdhNgE9D01JlGpSuC9yge0hpWLhLX7k2l8RKFcFmgYg+mP+d/ Y2axcd9GclsB9saMv+BB+W7fUFOnnH5yCqO1pKo0voQ5Z7K9jQIJt07i/y/GBycMru+TdRB2rw+/ 4SdWBtL+SBMrJcHEvkY3VjVEE+snf/dN7HJ6OkRPUEA0Y/2A7RYq7C1HdoMBkXNJtNsbMalPo+xu WdNG9bFz5215DO6qRF79YjvWpA5KGTZ3SesgxXhZ6gRQQbI/ztqDMbfituLC39vFYsG0bjtqAnIL Q4jy8o6zWSBLOLlW3n66ZzdtVg06e2rS0WiBwScEvpztkdGBJwRr+DJ6xh2/0bPAkxdu35GmwMP9 2v2sIrajqMaqnE/M2ahmyck47rAPERoPIReXzZ2V8lIN4yAC9QU5iDPOSj5g9txJSkcNKLRK14lk N3rFEOfgRrV0fmjDnNBuqHfKbyGT9cWr6p7iIFJgibwQDTKJMbmvLODvhTPxO3hEBz/Wa4fF4NS/ ueU6wmmZhAVOMaG8/I3K2BRBe3SEbqFKPIQ5IA6u8HDuVha+bxh6x69ntMlTZbXJpqs3+2ZNJ1qx 6arkdu51ibpbL6ilGm7HhoNdQsb/l1EDLeBt2zAVee9qAF6QO8gCGsgCcYMlgGKEH30M0OId8GYN OYjAG9KERS3itgAFCpY0IER738yONiLa23OLaGuJTSfWR2YstSzOjVA3PbPtWnpD3XTN2gsopYT1 e/Y3GoQYNbhw3vetAW6QPTRd7taMO8h9KCpQayao0pk4czBx7yoABhEmFxgO+xEid0AKmFKAhKMF GDgB8xSfrWq+M3aegxrbNlVZjKOTNAqV9Mc/jJq56QmozBpiS2yAMV/ro8+2l+CX5i1Nqz4/d57v kDbg19AI+kANXKh27Ul86FY85LqCOTLSUtmAvw9GH0Z9blmJ/o38wirXmuyhNsZ2yfmOenDbeOOE qFvmoCnbzS8rHJEnAKQvc1gSmfjdTvdFVs2NNvmKSPNlhRVVh2jyqQvnDotvXrnbEwtumZI/zHfa 0AVkr4COTlv1jbrlI0usC2+iL6+h618h6AXX/+D6ua7K1wRDQ8oPRUKFrfUKyxJp4LQf31+4v2dJ 6FeMWr13pj07+oFZmFnusGpceBitoedV4C4840depSV+U90LR7r3VfMrhjCNOy6tVALQgm7XcV2m qVdOodZDWdRD2PR71RQq/NuMxgDY3kJ2pAD4gIv1GJuipWq7uMzOFFK1RTnkRj+8BF3APFRYfFKb fbiE0voQCJvloc4TaPWjP1hI3MCbUB+QTINQwR2vwjUInbOBUTutvTjqxQNi3x034w4isVj7ALDf 66yL8U7LB+A4Yti0kcxhI5Qgxk2DZE94OxLR4gQIhMmQKVQak0Pe1gMKGj5YuUXCPriD5/IOyj4E J7Kild7RVy7A0sdgcSzEb5TnFWiNhtk3ZdUA5bcBM83acjAFZQodt2owp/gyNzmRiOplGOEPxPWL THfzmloQo+N0FHLVoOiDCQU7fa93CvPuH4CW6SDqTudKJMSmCrNYd9bP4Yok6HBZ79yBNQKaFaBf qKALzxIAGUo+dUV0/sKq6K/943h4LUAHd1T/hXtH5K71xU/RLPUlvpJAV6DD+4a4kR38o9RomNW+ Z/TdvkMExdIyRlCHzMt1+uJnAc4sn6317WKdK6QIaAcPq10fwgNss2p/6FIivddEbPpUxqDV0Hvk rkYJlwVsV04l143WdE0fzlRy7b5pWKYkhg6DqKizXrtfAdSXqNjn8xFYvASobXSJo0ULIqZ9dVb7 7ECHOtGXS71nPOuIaqAJVwYoQSp3NiLAzUETxUE4tXC3cmxUat2c50zM5tiWrEWAT3hSWwu/MdVg Mz00G8dny1mF6LKXsUbMyDz07JQ7PykdecmKeYWdiJNTtbZRD1XYPbbrd09pwgmse/+BLIDJCroA EtChDzwEUR5t8WsqdrQFds7YWpc/iC7Gj67DcMkCBBKBGVQAM3rBw7DLgB8hKmqJV2cb01KQ7kMN LRFoEzPwJpdbZ1sOS1JsT3mH2vxvcdSEznx8fSh5forcf1+81aolCyE7GF+5xk1I7x+696U2pVSK iMv8m/m4mGevdc7e3qdUXj87Ouv3E+190UfS3DdS/VTboDNkusrFvnWtT5V3g86WKcsq133V6Ywz BaOT/uVv89f+SKJDcZ0Mk+/UVnXuDP66aF3pd+6A48PtXNmTZ++rpK9XVPrCW9Mpx9ErLVn2+mjG u/z42Vs9q9Q5hSjug+udJv7cI+UutSokFs3cs3V1b/Pv9WWVLz1rEzmmaDjr9FkwfThDqaHO9/Bw 99Yf6KzfAgP0wH21lpfdz8uXv88cc510K7eHqRv1re3J90K9dVXbByo+uSF518R33Iepmk6riHvZ s1o7wLLFEydClyFSsfgWzxKeZMty+u5xr6/vOApCVfrOgvCkQ4UjTdqx37lZ/kB2uH+TteJHXSui 1ydH5nfeahOxPuU9CGvxWatzinX6qToT6l48mQlQVYeX5kfnH+ibwLHQAANc+3NrWWDdgiLhyEng QDYPVFPsyYl3Fn2NhRzK6vwf6RDTvJ0Oee06fexsViN3L1Rx/1a/+48ZOkXlmT4TpzNte31Wxf0x 3zkCnFK/yez93t2buWwvdPu2XVuqsJdB6KZhUk20rBN59JPIcn+8kRlxHz3Wn2/1p77WJDL8rczL obQzNrqjbiHM3O/e8a77XI3vk2tGdYUeZ7HRyBFPUbyDwnhvfzV3out7b/b2raw0NmBIPdWnj0an s4dHQE2WZ/Fs1tK7QU2IPYnPoHu88YgmA44sex8fzd/VbYWpUYfgaxdEUTnrUGkv+9jKalfKuneC 3zqui6bSnXdXTr2OQhYA/f/DbaxWn4QZ44gr0+fb3Ytcbt/NO79led3Z+r99mf/n1+/ff/uzgiDN YvmvYVzSBkmkQxuN/Gs7SR2079c1pW+V0tQ/PVALVVHSQj48qfonCpuq+ldyvy+V3wh9coeitvoy ub4w5sys1sdITSt9GrzTfiNFBl01aj/Kmu0zi3fTajDdqfpY1PowITP8+gC1K83Fs0LbS2ZCFU77 7I2m5VwoqDNDCSG5c0EnB0LpN8JEl2vVQX2K/WwO4XyvlsnCxDnHVl9lk3tyn5xf9ip0Z+7VXjbh /wBgav4vCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKNjk3OAplbmRvYmoKMTEgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE0IDAgUiAvQ29udGVudHMgMTIg MCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iagoxNCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9G MS4wIDggMCBSCi9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgPj4gPj4KZW5kb2JqCjE5IDAgb2Jq Cjw8IC9MZW5ndGggMjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVWTW/U MBC9+1fMMZVa144dx7kWigTiAChSD1UPZWkLiN3S3YL4+Uzsl6RTRZB0W+Uw8seM33y8mdzRR7qj qH1D1nsdHPnG6RApuKhjpO0VndGGjl/tLK12ZNK3W7GO0bZxwZi8Na5qr531JlJdeh19U6rVmk5a 8jbpQrRrOn5jtSFL7TWdU0EHdOQfi5+82VBxmcX2QB1VVNznm9+yWLGIVPzKV37kzUGBOgWYxibU 79kYv3eV9TZZSNO34gxWvuZNGNvxil+nbOxzPoNNaRrqN/kKwP8WCgABY8ACEFCHf1Bfs7plJ7CU 6JM1VeBB6OMKnABCnOF5RLK3Pfikukxs+cUxosB2zZtj6iafQJz4wQtq36nTlsvuuQuPq06HuqqW FF5XG+13+j8etQ8RbKWrKnhKRFDPQYSUhUuuOs5JnylkE/HHCgkb6jRlSqYolbLqaYVi6I2iGqAP RdwZSiORFJsrBsWMkNxBhaBOUZIwDYTA+yUzAsZus4cDMRJ63AQDmf9dSb1MCkvXtbCae9miFIJe cOJTx9KSig+dtFS8f+Ci6hmFeCEmkznUrDfSDMbf5s1NDpRMkwwUInsorHAQXy56rix17bxbEr3Z hEyTST1xMpmgy+BCJqScTEpOpmV45KRUhuZNytAE3dQ8Mv81KVWalPvg4fk7E0+suZPGGYN7Npx9 +idD0S5W5bz+ecYFbsMwFNE7Jhl1yKwZGQW6yB6HLoO5O0lBMBFje1hNkFWenXZAuR/8YcltHP86 qUcObQGYZPt+3SlyQ8Eh/oCw6hv30Jwn5rbLL5osZEcoxZkVq8UuSocfrx4GH2fn/B5npG+ViD4G BjzE1SZDS3hVcTG7kT3hl9aZWjc2BOorcSkz/gK+xjnYCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBv YmoKNjY3CmVuZG9iagoxOCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNv dXJjZXMgMjEgMCBSIC9Db250ZW50cyAxOSAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4K ZW5kb2JqCjIxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjIzIDAgb2Jq Cjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdVdSbvd tpHd81ewd8/fZ9OcB+8UuztR2okcSU4vnCzcsp3hkzJYGf99nwJOgSheXF6Q7z1JLS34iEtiKFSd GlAA/1r+qvxrOVf9UjZ9X41d2S9dNc7l2M3VPJc/fl/+T/mn8tPP3zblq7dl7f6/fYV36qpZurGu fdF6N/VV1/T1XE5tX8390hav3pQ/eVn2jXuXl5dvyk//q6nqsilf/lDelR+VL/9Y/udL9Ga3P8V9 +tMM1TCMfen6U+z155vy7ulH5Sd9efcnXJby7m/+7nt/9yMuQ/jt+48KPvLb8uXPMwZxgqhN3VTj uDTlxEHkEPWTxyNqU2OWh6EL/ckj6hcgXNOWdyTgt56cP+ACUpPGYAW5K0FVd+Hduct3voUfURkm 7KK9cxNWZEhBM7bV2C7LhkAXUlDEUpA7YUkGKnalshkHiOXY3uqPl8rCSSWk4A9+Msj3nCHMVz7h ioPw0UxjVU/Tbj+LDXrcg26Yy326TXM1jd1RupHB/+zZ77WnIi6PSLd5qYa2XhHCS6RluHdJuKWt 2hpoq4iV6k+pExkYjoT7SyBcPsWCoiryFBWIVTVT88FQrK27ah6mLabaGbykWONJVftLQM98vHwI nP05Wp/Lu797VUilyb60poNrdzNn9oTKb+e+atp2S8ldlZ9tgjjwLU6aRPVYtWM3pmRhK5u5JlFC GdwCtWCijctYLRNstT0TzcvmMfqcNBnHearGac4wbqCbkqxO1vu757k34McGVsT/+ltrvvF9YjSN EBZS0/0+eq/QBmlTsDK+R9OC7RLwrUXzD1/Zt15G+AhfYGVv8QjEiJ145e9YtRWqMCJne/IFVsZa WCe7+zEqW+0pWycfocn1TzwpRlo8+GDssiXCNJv4K96Akczmnc1QqI1ne3GdvOXd2m2DDMVDOidd 28IMapcyn9OyGf8EUK2CCDOjm4fWC+IuUF3jfKpMziwniMz25ojlEfRopsPXQG8tNTxHSK4bRJ74 kjEoI7xjt4McON2UJQeOA8leJAUro4D/w8sdLVorxEEAnIxQtv7tufoKy8Zy9wUl5hmvev9E7pvy 7qcst8LDfv3Z98tihcUfK9eshRNNHOGFlakIc7CEjt+hGxBTvk/gYi9AKyN110MCJ9gc8QDYgiJ1 +WyeLXb30cdwqat2zlHH16SOnENeIaE5NZA6p33+gBkG9JKNSf4r4upmSF9MiEjAVVazgmYUpiD3 JGe/ChNd3Ii1JAwLRHBuektd3yB65AmbgQTZ83yC71Z4HZZqWeDF3Q79ZPfnXnw31NVU1wxFWQt/ YwdeYzzFFvLBc0LMV3IF5Hwpsh5MFnKC8hV5j5hBLtMfeUtWJitRj1jGInTwSXbkBTvwM3ZIMfFr 3n/p4U4hkm9dATMnDQpmfJRi5BovND5HMOM4CXSETaqBpDSwzr95CbUWD3+zOLmFW9ND10Tok4Vb q4zYNUtPEhLvEYofQUK7rqv6aenLkSz4wYho31R9PRGL72MBWUpzasmrMfOUd5xMTvRtRC7uEogc opmEYgBsZGizbpVWa9iwRfbNMihZgw1SzbA2vhCYKPbgKUm0YfgkXQ9W9rHpIbmOT5JcfJLtsS8U D7bAQj7CQt6RsEQNTgjlwVad1F92mBBAkYfi9urACY3VtXVVDwNME/LfByMPXVs1TU/X/D7ywKnh LKwegbNNOBuW2/hoYFbH0GTPuLBQm4bMQ1a6BsaPZ2A2w1w1wwIX5BDVOE7SICljHBJdYysIlpNV oz2jotP7J3JvnAAnrmyblAvS50gNCHk8WrWyzLfU4Ph8Wr0bowi++dzSRtu1iY51x8ai8mNjTYeA +pLsz9Uo7IjJhouFCRQd0Jq7ztwR43j5CgaIMInlCrIbmWNPd6nZ52Q9+AiU/I1llyHroeHYyw0h JzdEdtx2ah8AXGVHZM4RkVJmVRgX9KyLbokXtGNcCx9h54PGjYe5J+Nf+ink5ZfnxRQBk2Ge2x6r 6F279A1cpvWvXRerg9SO9VCOZM+z+qqvq6Gr664clqGqsb7Vt9UyX3WyRgSKh6lFs00FoG3R3WGu Z3Hq4UIv7QQvGmvzPxxcvj9Ph9W3w1J02439uyZEjUiiuHAfDCGGpa+WvhszCAGnUtUSReE5OFuC vgokjsXfh//4C+kIsPNrduiFXIGML+Vah7wAQhsNTV4IlDsOY4hjOxul0PXtEw6jQ5XgMMYActRh DH1yvQg0T85IiN7ddlZKOCuuW3t4/1kSwjKx4ZbwehEFwECRznNfAiSqul5GLzJTvwwCNzcg44xN P4hojgtazpaIpEmRSQfNiVKMlAHX4so+DDRo9RkpV8M8VHDsc5yG5ICvpoCdXO8ckMzRDcnlxcww F0WaKJUEq8IHu7YpW3RUyP3ECxootFpoWjwFtABxvhAbDBDIRr7RUg+MfOiZwND60Ma0YptvUROW 8dim9Xs/9tWykWCBxDaVeg6uyeJu0yTNMFbOFq0rcrxXv/W9ot1qqf1EhgwEJsg6gha6Osj5obHF oRIWWQ1nIGCl9W0ednmvQ1raNPUlGS9DFWbLwVXTKEcux6mqx3st79k54d1zsqzR2tcF4fGcyqYZ q17yAYdDI82SShU45zYra5PhrJCTKjcdlRCivRapEB+OrgIl60pwINb7F3weLbapSKss673K1k8t 9rBtChcvrD8JIPzNEaC4yyESSU+hJh3RkuGRBxZOLHpMyG9SHvlgpHOYqmW8zypgUji3bBgvAnJK 9/1lpxOusKGrjHPIyWMnWMg72olsj7NNrUMt+G/w3rosbHvGWq744C4L2vrgf/KVsRZKjdVOSZ3H Fzja8J7rGQvZF7I6X2BheMHRjI+wWb6uuUC2eTxjOP76undsiGZmGHY1YH+ANspmsGxtFPeGeRrZ ka2hn5FlpauhNtJ2GdkihTMu6netml74Krm2ZqfUTj5bomzwtwBwjvF5ZxtKvmcZg49QYH5veJUa hSLC9/jCH2ECdeUd+2I5iI8wrs67pHvGXlvps81SeBneYmVfiAEGm/MZr3r/hIbZT1metN5+Sc1i 6Wgl0pKTfUBhpmScsIy6dkJGCILQlhd3lzmOycZZj6VbkMN0r5V5zpq9WFSmg8BZSMZQLQM+5xSn DL1gzVhjiC1SjKzHw76xMDwZ64Gt9nIuUrKnV4yoGLo5UDsmciQ7yC5ZVgxs6qTeIgIr4yOwih6P W9sZAYVlasrBcMcut655GwFtnG7iqK3Yf2dUMAEiXwA3ygCKQP7vh5GRkjXOHXSTGdKFMjD7UzBH Wbu0Nv1xvan396eEcC6C0lU9ax7ARX82+1OskO3dWX4OjOy4VO3lwG6O2amjOGEWP9kSCxlMZKEV dUoH1Qpf4CNkdqtPfmd4QbH+2W3sf0T+b+pqbJDhaSdnl//fDVpj9R7JLDkBpmP9OblmOMjqCBZT bqfTr/BgmZYMshaendVbwdnrUYsFAliP7VRyNBluGkbzJRgU1h552aqiIC1O2igRLOSTxEPaTdZr oSBSWoIuUW2VoFA6cHsBS0qjYl17W/8CfGJL1bIMIwiB7a29bIptsArGta9pxtbX2/HrE8ZRMzTY eovNtzvsdBk+VYQg0NFkJbWIdxZwwpKqUlKioJ8TaMiIVstyztQK4TMxfhWbbZy/uUN92HqpvdPq tYrffPSoihsrAdPYDAcomcSJTH5yihd8ExYCauzJQ2Bhsw4wN6fWSm8r9VWJYnGyrTV34f3jNHaB V0ujW6+tUr/k5BX8okQ68pr9bQs6LuxOJueTfO8E6Lgtw1vQcSDHqjdmAx8lWlEonOAVurcFy23R kLjC8DRbAgA3h7fTzqNswh+xrT97Cu4+OW/n3QpCNLJNtUO+3V5/LoMQagbRxSVxCW4kPKY4oQpS S1onMLmtsbdl7OR4hJiO+6J1iI7HHNYWlkZ9cF6hpa1NS6MUl0ckXAtlhrWPD4ZwOJUCczht+nML kyzhaK2Q8ciNdE+xBhZRs3jYwzXafkGi47RSM8M4yxbnM2IhpkrfzRtq7ooF2DAbOWVXoAN1LFBG VH3gI0vaWXxOrHGqcOdQFUogyxk+QdWgx/sZZ7EguSlj38o1h8IqTN6RqDSzrY1IbqbCtEhLY521 BEc3js5QNHSGrdtNKeL7CdW8rl1ZbE8o1bBh1PaGUmgjKjR/2SAfsT4KW+CYrEgzhG1Hz4GykN2l ucwukYZsNgz+Zghbtd0z2uJ6/0TufSoxheExdoi02KM+I9ilzPfBCIOIRZeV3HJIGH4AwsDxsbOk /JuM1Fg+ok2COZdJeZxtCk07VDOWTnvSIGNOVhq8FLZB6hyXSyzjMrM9yLIzUJ+T8dRLo51NtqZw KImIIs6YCDtk9EfKBUWOCjODqOwWpYs9J905AFovVuRYNX/jZbMrlsNIgoKFPeazsEEnwCFnkEPi I6yTA1wXpjKV1gklgbxhpFx0sKTz5SLp3KYsZBcqOWaRrkoLRw3VMAkSQbBMX4/EtBfOJZmPGoz0 5pPkD84hCzecyDcIxq62sI3FArydS8uzrNtKTcbaN3mO75GFbGV85JW3eyg/lDE7XFuLlQOyLFug NmRlHDtHyzqTlVXAAUAjO8jLU4+XlsqWEqqwnvr3n2Ubb2fkQGKujRj02Xx3TAxOxoKRDlUtHaJ4 CTm4dHAtiffuggDER4VwwZgTTBbiHV8I0T4XwrDcoiv3FAfL+eyMneHbUiUb3p3pbt8PHOm68aln EAouGZMvbPHZRSkt0/IFdo0DZQtWVuyQ7HZmtpckLCtjB22dQcZcz0jRPRljLbzghUfUDjgncFnE pTFsuOuYHROLs9qhH6uxf/Bkqy0HOZOOzMJ5IobyYl/gxHLyOJUfK/q5yshkVkfwjnVa8SM/WYuC OflW/Czjkh1foHUx9m2l7Kh7o1CblUzKFye8iJWYyvd+8HdhLA7QrTSwT3zdcnw+k3J1pThwVGgr hyQODUyYI0xBgrC7Cl2cT841jQVL5j8Cj25m8TjaYVofUzRxwmEDPyZ/1Mck86zC6iYk6z98WphV HJwZ8hx/s7bEBQcKO3PWwdWPNzM4GKpa2hagaUhxHDSvrhelw/e6XtR3Q9U32GX3MAtGuryJ6g5u Mlxt+RZbdsb6XW+u6xGDaLBReUuI97fLEIfaYCVxytxcRzAiROFylmfPTyEih0hbwlaITc9lcb/H qc1ycPPLVzbsHcxSPZUZPUeM0z14+/SFC9v9Hp2fQOwB6YGbzt84s/krqkyahYQMq4D/BSUAOOHU WM3LJ61poJYuoSpDAePJzPmmznTHa7uc4vMkw6oAjpbEDoxjJCMcc8hEXhvT+CcoJumnpJW1HUhH OhekESvlC7ESLnRTFFuKfyvvaEYlp4+Tyd+sv2Nrsa1zTvl6PHu6DBFiVhwLB5HsoR08KjUT7bdL XAV/e7DejakuPAZjOifoBOwUb3FASdsiG8UrhwZ7wG9nn1zEcW60unOueycnj4/YqH6AwZJ2S5o+ F+ih6Q5BOWKL0YwjrLc64WQ2xXlCrMoR6R0Ivt3nuFKyXLg4T+NLb7JnsOMTAh4fJa87AQiSRmGm pwL76TKic2uro+uV4iAlifXxQplhW3zkY9OWB+dwNgWf2YKzM785nKf+fQriFpxdeoZ2iu1b8bag xkpZSKhxL4SQrn0hZ08kK30u8wCI1GM8MIMGGPyukjTjxzrA7eRQzryWlabAgIyEpkFmRysnNyA5 7QguXEibNopaDtqKHQCq6/q27PPF4UFxAZtsBomzbYzm92gr1kgXnHO+e7Gu0ZCRrlycAFKdKsuT g52wB/dIf6R0UXQoFk5IQoIeq7M8z/ZfCD8j9vAz8vUzXr/mFfwtpwt+wVu+RSFkj3hh/eqm89Fk bM9iAbGEDj31PjvNcVk7hb9xOY8NXSjsyPjziBSSYhKIVNz9S0YazMWnuEM8/AoiuURHnYEtIrkp XIn96PDQLfh+SwtYaJGi0c/IvXtf+CBLlz2+hAGvI1MsHhIehA4t4o0bdHh/VkOH/Op5zvosziF4 UBmNNVsw2lfGi7hZWZUi5lR5gAfKj83fsNJLFg8mueN/SmEyzqkgwGesbF4X2HAkiuINxVBHzDd1 OJTjKwaK8/74iG2SNGIhfQp2lZWxxwGMnFCTRKQiH0m2gGXhhNyn1l8fUj/LZyUmOIYHGE+ibRfJ TWnz5XBPab50LhEUbg2ObMBuA8KTJNVLjUcPhdkzX/Y3HiGhBImdcCuUPBnrdQfw6cK627o1sFyw pyB5oNa7JURwa7pZjvhKJ2uHCFH4YAvFJeNCYKLwUECorSlmVtuyMFvbBuzii0nQ27oRDrTYewIa v2JCSUYtmUJ7MdfKldcs+et7cJoJp6pJmvTeZGyyKbLzPB+yn+AVFzE/0E9ota3552ysDPPPrtsm p7nyJprlx6fGbuNvdmO6tdf4CPvJ36gEyLkfm4ZsZRb9n+NJ7x16qxrWc4KjHhpea5g9aBVchPxr bJEL5t+7hZVO9k6Ny7DLyRtYeVB8hSSNWMFIGIDvlhArvk5yPJkm9SKc5lTC5ruIJ/CV4qBmUPAP nZFCjtQfeUtoJdJZEUhIVzDEfiEcDUdI/cEXcg9/8aVc3SF9zk9ihQmHsLhTWzAIo3tjTZyL7FS+ zw5ZU4x5goR6QgjrvKJwXEOsjAqH5GBSme2SNQuT9jDHSZMxJNo4U5PqjiS2Y2CzfI/N8hFMTQQS uo0gDRJXAR1MfxHNEXNIbbCpxomRcjJfj4NKOrCkA4nMnY1o1S5nqrpLtXpjNzo2iXT4UFzZUTYy 8lsPgIQIevIzhBpb7kCIDqt7W5B4fzEk7DVySQIZhDjkJZIPk3L2FaV4a6FdCEzAgad442Q8xL3I xFzCEAXgmXQDwVSKr5UcSqN9w8lfoQfU2UdsjEhRh0JmqRHk3iFmkkTWcCGhLL2IT+y9HaF1KjkI 20NCGDGPyMJHiE+VgQbdC3MQGq7ZpAoN2Oo84mu5DxNdVqfnusHrosiQf7J9ygnbmruYrkwf9QIf txt14QDio6PBSAqnGp+MEt0e7moMDF01YVEtkSSaM95U7OBitGV9a1fm2h05HL65V9Kq1ZeUKTUQ +GPQ6E7SKFRWJpO6cR9vTq4IpVa/ijvtMQewMZwg5JF2VhFMzcZV3XNdFhqELHGIK6TBzMZuGhKU AIHHQgbJ+LEHag6GH6SyIKoD3k6RA+rrU1TcWfNlf4ruGSJPETjB7mD4/cNvsD2+luRYS+BdUzxp bmT3Z9/8WcUPzlrXZiYZcTL3L07AOKUZCnVvzfM+J4lFa85U1pb5nlPnqwnyJe7XZRcig8ogx0EQ YaRZfyTDs3oqeMrETVNiFfufsUPPeFVPhx37gsUkPutnj9wlJOeqycFHrQXBbu6HPhyukQZ8AQZB Jv5sxMNpvltnQ4ELp7YH/nh2TCkneOzv/GgoSIZ4Kfc5XicpLDpD1uLjbh6+QXBlkJ+TyBf4yIYD +Ya7bJMxyKR8xDbBSimzbJCcZXe1Jn1R1pkUAzZEbuUALXyzPbIZf2NltHNZi6FaSKFIUsZqD1bD QjaoxLP7ukJPHRrwDUu8j7Ml4YQm7pAHPDhJMKy3q4mPKYqTuyiQB1VN/aMdU0h2s86L9VN0+olL VzwpZzw4jt5m2SUzBskMnGEyGiUhxHacSrPt2ReuKBNrmVAurYIg21tGYzf4uiI/+C5Sar+WHEkE wD71pXyWd/oKK9r38LCrq5C9G+fg3XkeN+DdfR3drXiRiTJiDNlMfULIVusHmTx9r0f/vX8ha2GH NzigNKX/Ns7ZtRgMeZczz8t/i/EAZgn84DiaMkfIu4eCPx+Ga+Scvw5bd3XkGZyBkdtTjRQYVm0q rHxmW/zeQPYNfLeRo0FOmg6EUyjJ78uV5PfNjN79CdOTn/wem1n3zeTuZIdcM4XO580CGYdMRSQj /wU9rrnvZ9HlckqiONKuz4XjI6sB/8Ko8qSK5sy+UaS+QjQqDZhneWiXo4pC2G9foS6sYS3dKHsm 3P9w546zGrHLYsNo6UWdsile/lCurjrVFnUQZ25PsxnkKO72NAlro3omO7BQFdITAtEzZvjzZ7XF rKHFmVjxSRw0PBIRXeMg6VDkhWq4QfZS4GiSjXLtAmtnQaqrkLvpdYPU2WSR2+G5dlmqeZTcWqqA PBEk/TYBpZXKEtcOsfNjVBZiW5MjGcS5nFkfS2fP6DFwDmNXwXUreypjtOPp8yBqdPKhzFgrccTL tDthg6PpPbdnLBgRLfJp5jEz+TZvDuKUsXucQ6XsHiHmujy3j53IrG6XGuzoB5cBnWJCno2O3+po g+50bm1ghntUS44polb4kq4usuftTbnAg9uz3MhZDx3C5QcIAdY/S4jtMkGLwxSX9qFWCW8Pd2Vq JDEM44dznmeL9dJ2SqeIbeyoQ5bxL0QhYUHxmVwBlRoOJHzpYbL62Na6UTtAHDP+Zr1GX29YWqSC Y0CCqEj9S8XJaqg/5bTaT4YA4Rugp9enjbDTNzDGgQtda/Zni/PO0UxrcNNk6Nd1mA9Ox/FenUY+ 4N35r53igO+lEeQjx2Uo4gPQdwFBt3oqnwtfJJsImfWAAsmvctCHP95XflXbwUnFGQpKoZRyeMT8 KiFEJ5GojaZH6sQZTb83Afs+3wqWI+ZoDvlVexueN1h1V5ZeW2TueI7NoHs6fcijrLtpBD+x9zmM nq/aLhhdlY9mwLTDgvNkLzNgTq6A701j5lqY7FvBd8ozd1cSCAPcO8zculLq/Yp+0CAhAZ6RR75B ICaC/wGgv8lyCas71B0Kpxk6xFZqU87Yi9gwL3V91WoFNsTK/GBWffklepy9fOYe1QFw5FwbIDny R/ULUdyg1ddyRQ7PC7k2RX5iYLlNDGQsNuhhN4ecZk4MtSeJxxmxk2Zj14EvYssepEz4P4fiB8ct e8l3W3p89F65PYXeG5SCRZXJvInxPJBr7sEWvYYH0yFLSPRiC1p5LTBhQ4MH//AlmoAzOMDYpRzG 6qLGSVXLJGh6wzG8gLGHwBlsnx1wOH0G4ILyxBlaY+RDMmfAAqwFQAbypUbtWryRmLIUCz4gIXC2 AA4/RpRb9hHnE4IUYGSROMSVeRKCK/MkkjW2A8449LELLt7KDqaqs7LXzaacgWNWtmslWNlO7C2e WrgwsBp8iYSOCCZ3Fl94bLzCF65T1sonX5GqRC32NACiG5o1zjX4mRb22GoxG84hvHvZwu4Aig5O n9gKY6O2ggh7hujikQfLFu46nKyIzxEd4NjkAlaaPheydWEr4T2XGxljWLvgFPEmgxBXq78eZV5N W4wcIUmuSH0AK2SCHfDOPpDsRWggBIxzE0QabySN/lLhAtBuzV1v7ogKvOhZDwQ7yiOFlHfWeHnt mwjvi2lENRGOxSA4bMwx1mohlFYiqwsNOxxhYTJDxHbKajKCS7CoXGUBzh3UWMS3MMRm2c+wEcK9 xyN7tp+Ldb+ttbx7/dfOOClTvhmu3JNnCHCoGnB/hrkVg1fvn8g9DN+fshyPJ4aWBqCrAH3NvnRD kGh723SIzM7Ia0Q6M5KaV3PscYBJzD6cJgbz1UjeLjDBiLIiw8knA5Ou4RHHgQnN62pJkDRlLZGg R46m7OQ4LXy61w7MZohu7PIDKuZihi8izQ0+XDXpQte8JqSrivkGR7Q1YKm6/M6dHlZ+/gKTzThb kk9efH5xuNMn67LmjI+ilBMOjRsaQfO2Rds4w6Qt8HcDjsKG1Ll8Xb4of3WklgY7WOXNaijfFPJJ Od74ikJ/U4aHRAmarqkacS/kPMYZvlL5JpQVoex16Zb75ag7l6+IWJQUYRlIjs2KH7uo7nX5+/KH 4htPxq3+vU4d5Ehg3QNT0UwAD4yt1JKCJa9LjBa/hPGO2OEkt+55/LqpQToitJVJbWToA1Y62wWD lLPU0YC/dyPE/esShrp8RwnHvfknhkUk35EKJkKNyYpKJGbZ4wzHy7Kskvg9HIMon8ctpAfaItKI MEso0C4BDLoGHoV2Wu9x3CA+yIYDNnFYkJa9LnpxCSfwWCjr8YHqxg2GVUcFvv0SVa0PsUxLAD+b ElSdeA9fGhW6gJr6JqhJ6mmndAbWjnt6x0PxJdsntvevCvBa2Zb/PCBAnWQcNPKhwTfl+vfroqtl IQyT7H7rahxZir9wGhmgmHcoehX9vZauf/nfCyiOETRg+QK2RcVrC0s94U76IX+9AjRgHcr9/Rp/ 48s50qi7B2g0qI01yB16hbrlHf079Vf4HX2WOt2zfjTF2oJQwbctf2k/bGn8uxeogDFJTISgrVOP c2rAxW+ikh0Gibg2Pf35DKIspkKvIn1/IfcjitlbS3ycpZevN+EbwCJ4s3zoshGc7WFAN1hvlM+0 bZ2VgE8CljVOHZNkKucfRbehWkDgPGJ52LkHBb5aJY/y8vKN/5Qv4A45MXc//6r89bdv337/dyh+ Xa490gaNtrWNDroM30eDCeQXP9pK+i5N/ccjtYAIPlsop0/b+lNshO4/wymNXyEoqkMS7elUbdry U3LvavektszW7kIoiJhMseN2r91nnJB0RrtD3HF0t0gN1oAg7e7GVxTOAVerJNlvSOAEFYrtBkUP lT30wOM3WlSGoteyZbl3h2ZLJjbWntHdCViNL3aZp7Z1OQ1fHtbwnRtIM4uahgkU3wpUyuyto8Xp d+5WHna/CkX8u7iNFLssYAWdKMt2kLRVtcN2dyWx3GtZpGyxU7rrirUAQOm/lx1pZC27fOqiJLYK kPoJawMRnki7yx6QacGnz1W7o3Woa2RlcSTh/lURVF4oE+yhdg9lAXG16qiA7aOqoN11LDGMQfuh urXuXukUehBKol6FssunLkteiWl4QF2LXFFNNmKwrX+LalV1veA3r2hxakqkrhegsKpr/A0FLypd Ste/+HuL2oTL5Im2g59g1DXScMQEEF0pf72CAoWEuL8jde3unaINNfAOdas6ltZVHbO3kTqWkdAU wF+qjm1p/PthdYxjq/rJCUgOL0T6eIcXYvuT0nYx8ysXB365lNocGQ3yWMjJmJcyyvHFfK1jfs2F ENWkDmEGHFIVFPQESWnraVaNoWh7TEHX8pEQRu9W1QktvXVtT6tn18IjKue8+v+fqeYW0AoIcaoZ Jz6LUjnueBfyJhQRFAykiDcHVXMjYYi+G4sW7iiUICrTIqTg+SL42oJuM9qQbw0L3EgR/AJJCIyf 2tR1UjXjrFeMqh3gSYpqjm/RMMbqfnVDxy2sBX3Y/bq+i9u0apZhuANlg2oOJZHYh7KgUWVfDbby j6tuxgH8HsMiDzqURe/xqYuSWDe3I1KScWykjEI973acsFMAn4ALyhknwGMKkPtC5az3qCkAnZah pqCcQ1nA2lB3VOJ7IHWpdg69yimJ3yNlEEdY3yT9ol7pTKx915J4PCxbgTvMTeq9k2odAjSpWnd/ R2rd3XuFPEzjqtYhx3B+qKrxt1frrpRPR7/L2f2q1scRFmXshWM2xBQQtS5/qVqXv2O17nYiiP/c ag1erUvdVOuYaVHc7hn+Vbgy/V36TLXf6miCF+5G6k0KoQfVfigVzMG+FWdy+N83av+aD7AyAeg3 C6kiPzyIzElmMcyvDHTJGpclQe8rQ7mwF6NcWhaJozLwKqA7AJCAif33SBkntoyPwQ/y1NoaDJh/ sCF8qWAwqEe/DT0fMhha5CF306C5EsZkCDmG9/Tor7bxYB59dgvGbGhG8eib5jNIzZMP06VHVryo aG83LAjon7MbkJ/j7IZmxBdYWn930HDoEO5GctBcoC/YLOUi91om/fNlgDtZQBKthphwhWiSwBny +5FaCw/fPLet76T10IzyGQuMCm6tmA/mHo3LmN3vjgbuXrx6/7z7PXof9zQhcFxfFLYHAmL1wZlL qodZEBsQLFqFHuGyGsohAgYsr2OTk7iG0VMsyygx9gMIDEshth7kZEbst42sBzkLVz67pL3W+8iJ brUsth60bIVxrTsqce1Hnr1MuXy+NtgS6fvYalB6rIoAHqmnWmQ1kLArnrMgthmuPBPZEOGlYwaD eFOiqGEyw3BnHMD9HRsM8ps3AWYJbGnY3gmwGgwizPIMauJfsu1Fwun+zWWoMZ38GwdYWYNhgYb3 BoP85RV10crfscEg994YQKjU1cA71K0GgbSzloa/wFz+b+mTGgw6mtVgkJF6g0D+UoPBlDJG4X8/ bDBAsTWjwJ4yEqqjiKxsIl11wnWITSTc4eT4gpUuClZTga9cSnos1+zMpQxnSXpcUwIhSJF49KHI Bv5FmLFmjGBwFPiHu7c5L/GYjQDoH+f2UaP+WEJ0bTxeYCG7hZSN0H4GQ30b9u+RK4tDp7CYDQ2C THvYZvii09CiBOoWofO63dI9ZM9ul6bXdXtGiPDJQnyGBdqDh+MU3eQWW3hxiy04UNKbZsjAcGkq SD6STJ251JMTeSeZGEP4jWfOyCZ/fDzzIo8lPSyc5dmGYQWT86vvf3z1/V/+9vdvXxc//gErIRh+ D29DhomFfjmSoseOQsBEPJhPn75pyi/+jMVxWTwJzUnwGKleERXhDGO5/V5E7BasAeLYALdghcNI Ixr6iNhpGro0p0DDwiau3B5UIOHnbwHmb12//DEfWNdMb03Hua6SpYjF2+uDsjZ7AcZg+o29SIYO uOT63D/oZMhmb38g/43JCKK39tvxNQ4gdulYuOq9pGNhQ4TLxkIxs3X9ryGHN97Otz6kVdl8Ya2Y NfmHQk2SdweCSTIfLpKoNwV5ekdU9Eu7sAHg8LqIkOPpFC7EZORMS8YxOs6ULEkK5HdzUSgJg7j8 FmcGIF+SjMKR8rfv/CP8bUNWToWS1T1U3LmER+TPEYJIMl5Yu2QlomU+wtrdcSOYLTkhwv3ovjnO jvAZjiM84p7kbzqRuD0qlPeB6w4B/H7N5DVQY6VSzotgCr0kkGIiLDk4Ds4cvqeQMwyHzwTMgC0r PJfX4FmM1RnQrt0XBXwUoEN7GyzbOWYjaDk5qLmRANib8icvLUBHVOMpG6RMxuU6g3DfARgsxbf8 hGQu3zrWZHcoVORwFlqkYK90O0QVcWhxXReenNoB67Sj+CGewnZik6p6gOmJs4Lk7Fx838kpzaOs cC8Jwsm5OJuNvHAL2JJMQJnBb5HMgA3vo48R4byij3EAzoIgLrtN0/WG4LPbzyH4cq4+OyzpsMA6 8odss8EdH6VCIgBGG5TwCJNqFWuJI6zGMaTf14hHLYBGG5SkKf5oYZ46g22wU9Hen7V9AjhrkXT0 VTsqs8dzssPsznze4tgGVy7y7dYZWnGll5DUooHNG7Oy0WgkudFoggz+s7n5Gs1aGAQIR6VgWNxg hJiPrxrLMUAEAbyN/bKyhvxVJL94UgkGR/L+aGITDBkci4Xwgu4HvjFFlIb9i7Ng7icwlMlCZYIN UlCz7Cg7aYhA0U+UFTgQHEmeWz/xmgbN4XTZrz8hunodf477OA5/BA1gYgcfxw5rxdTdYdktYs7N Qc7UjvurTo4OK2UZbJMZKpuPtxIcoV98KXGf3m6ff0bHlG1bLI7XXThE0LDtO/EpkQx+e1RHfcq9 UUWGGPItC/NZqv8DZJYgrQplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjEwMTY5CmVuZG9iagoy MiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjUgMCBSIC9D b250ZW50cyAyMyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjI1IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBS IC9GMi4xIDE2IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKMjYg MCBvYmoKPDwgL0xlbmd0aCAyNyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4IC9IZWlnaHQgNiAvQ29sb3JTcGFjZQoyOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NN YXNrIDI5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp4Afv/HydQKHmpWvVKoxaBIEqBgiY9r62nvIFwgWwIA6gSKOi64C2Eq98GFYdw7aZD1QOV QUSwkgB/Y3mJCmVuZHN0cmVhbQplbmRvYmoKMjcgMCBvYmoKNjEKZW5kb2JqCjI5IDAgb2JqCjw8 IC9MZW5ndGggMzAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOCAv SGVpZ2h0IDYgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGb9h8MpkEoTBIm wcAw7f80IAIAVBQq9AplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjI1CmVuZG9iagozMSAwIG9i ago8PCAvTGVuZ3RoIDMyIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUFNcXx9/MbC+0XZYiZem9twWkLr1IlSYKy+4CS1nW ZRewN0QFIoqICFYkKGLAaCgSK6JYCAgW7AEJIkoMRhEVlczGHPX3Oyf5/U7eH3c+8333nnfn3vvO GQAoASECYQ6sAEC2UCKO9PdmxsUnMPG9AAZEgAM2AHC4uaLQKL9ogK5AXzYzF3WS8V8LAuD1LYBa AK5bBIQzmX/p/+9DkSsSSwCAwtEAOx4/l4tyIcpZ+RKRTJ9EmZ6SKWMYI2MxmiDKqjJO+8Tmf/p8 Yk8Z87KFPNRHlrOIl82TcRfKG/OkfJSREJSL8gT8fJRvoKyfJc0WoPwGZXo2n5MLAIYi0yV8bjrK 1ihTxNGRbJTnAkCgpH3FKV+xhF+A5gkAO0e0RCxIS5cwjbkmTBtnZxYzgJ+fxZdILMI53EyOmMdk 52SLOMIlAHz6ZlkUUJLVlokW2dHG2dHRwtYSLf/n9Y+bn73+GWS9/eTxMuLPnkGMni/al9gvWk4t AKwptDZbvmgpOwFoWw+A6t0vmv4+AOQLAWjt++p7GLJ5SZdIRC5WVvn5+ZYCPtdSVtDP6386fPb8 e/jqPEvZeZ9rx/Thp3KkWRKmrKjcnKwcqZiZK+Jw+UyL/x7ifx34VVpf5WEeyU/li/lC9KgYdMoE wjS03UKeQCLIETIFwr/r8L8M+yoHGX6aaxRodR8BPckSKPTRAfJrD8DQyABJ3IPuQJ/7FkKMAbKb F6s99mnuUUb3/7T/YeAy9BXOFaQxZTI7MprJlYrzZIzeCZnBAhKQB3SgBrSAHjAGFsAWOAFX4Al8 QRAIA9EgHiwCXJAOsoEY5IPlYA0oAiVgC9gOqsFeUAcaQBM4BtrASXAOXARXwTVwE9wDQ2AUPAOT 4DWYgSAID1EhGqQGaUMGkBlkC7Egd8gXCoEioXgoGUqDhJAUWg6tg0qgcqga2g81QN9DJ6Bz0GWo H7oDDUPj0O/QOxiBKTAd1oQNYSuYBXvBwXA0vBBOgxfDS+FCeDNcBdfCR+BW+Bx8Fb4JD8HP4CkE IGSEgeggFggLYSNhSAKSioiRlUgxUonUIk1IB9KNXEeGkAnkLQaHoWGYGAuMKyYAMx/DxSzGrMSU YqoxhzCtmC7MdcwwZhLzEUvFamDNsC7YQGwcNg2bjy3CVmLrsS3YC9ib2FHsaxwOx8AZ4ZxwAbh4 XAZuGa4UtxvXjDuL68eN4KbweLwa3gzvhg/Dc/ASfBF+J/4I/gx+AD+Kf0MgE7QJtgQ/QgJBSFhL qCQcJpwmDBDGCDNEBaIB0YUYRuQRlxDLiHXEDmIfcZQ4Q1IkGZHcSNGkDNIaUhWpiXSBdJ/0kkwm 65KdyRFkAXk1uYp8lHyJPEx+S1GimFLYlESKlLKZcpBylnKH8pJKpRpSPakJVAl1M7WBep76kPpG jiZnKRcox5NbJVcj1yo3IPdcnihvIO8lv0h+qXyl/HH5PvkJBaKCoQJbgaOwUqFG4YTCoMKUIk3R RjFMMVuxVPGw4mXFJ0p4JUMlXyWeUqHSAaXzSiM0hKZHY9O4tHW0OtoF2igdRzeiB9Iz6CX07+i9 9EllJWV75RjlAuUa5VPKQwyEYcgIZGQxyhjHGLcY71Q0VbxU+CqbVJpUBlSmVeeoeqryVYtVm1Vv qr5TY6r5qmWqbVVrU3ugjlE3VY9Qz1ffo35BfWIOfY7rHO6c4jnH5tzVgDVMNSI1lmkc0OjRmNLU 0vTXFGnu1DyvOaHF0PLUytCq0DqtNa5N03bXFmhXaJ/RfspUZnoxs5hVzC7mpI6GToCOVGe/Tq/O jK6R7nzdtbrNug/0SHosvVS9Cr1OvUl9bf1Q/eX6jfp3DYgGLIN0gx0G3QbThkaGsYYbDNsMnxip GgUaLTVqNLpvTDX2MF5sXGt8wwRnwjLJNNltcs0UNnUwTTetMe0zg80czQRmu836zbHmzuZC81rz QQuKhZdFnkWjxbAlwzLEcq1lm+VzK32rBKutVt1WH60drLOs66zv2SjZBNmstemw+d3W1JZrW2N7 w45q52e3yq7d7oW9mT3ffo/9bQeaQ6jDBodOhw+OTo5ixybHcSd9p2SnXU6DLDornFXKuuSMdfZ2 XuV80vmti6OLxOWYy2+uFq6Zroddn8w1msufWzd3xE3XjeO2323Ineme7L7PfchDx4PjUevxyFPP k+dZ7znmZeKV4XXE67m3tbfYu8V7mu3CXsE+64P4+PsU+/T6KvnO9632fein65fm1+g36e/gv8z/ bAA2IDhga8BgoGYgN7AhcDLIKWhFUFcwJTgquDr4UYhpiDikIxQODQrdFnp/nsE84by2MBAWGLYt 7EG4Ufji8B8jcBHhETURjyNtIpdHdkfRopKiDke9jvaOLou+N994vnR+Z4x8TGJMQ8x0rE9seexQ nFXcirir8erxgvj2BHxCTEJ9wtQC3wXbF4wmOiQWJd5aaLSwYOHlReqLshadSpJP4iQdT8YmxyYf Tn7PCePUcqZSAlN2pUxy2dwd3Gc8T14Fb5zvxi/nj6W6pZanPklzS9uWNp7ukV6ZPiFgC6oFLzIC MvZmTGeGZR7MnM2KzWrOJmQnZ58QKgkzhV05WjkFOf0iM1GRaGixy+LtiyfFweL6XCh3YW67hI7+ TPVIjaXrpcN57nk1eW/yY/KPFygWCAt6lpgu2bRkbKnf0m+XYZZxl3Uu11m+ZvnwCq8V+1dCK1NW dq7SW1W4anS1/+pDa0hrMtf8tNZ6bfnaV+ti13UUahauLhxZ77++sUiuSFw0uMF1w96NmI2Cjb2b 7Dbt3PSxmFd8pcS6pLLkfSm39Mo3Nt9UfTO7OXVzb5lj2Z4tuC3CLbe2emw9VK5YvrR8ZFvottYK ZkVxxavtSdsvV9pX7t1B2iHdMVQVUtW+U3/nlp3vq9Orb9Z41zTv0ti1adf0bt7ugT2ee5r2au4t 2ftun2Df7f3++1trDWsrD+AO5B14XBdT1/0t69uGevX6kvoPB4UHhw5FHupqcGpoOKxxuKwRbpQ2 jh9JPHLtO5/v2pssmvY3M5pLjoKj0qNPv0/+/tax4GOdx1nHm34w+GFXC62luBVqXdI62ZbeNtQe 395/IuhEZ4drR8uPlj8ePKlzsuaU8qmy06TThadnzyw9M3VWdHbiXNq5kc6kznvn487f6Iro6r0Q fOHSRb+L57u9us9ccrt08rLL5RNXWFfarjpebe1x6Gn5yeGnll7H3tY+p772a87XOvrn9p8e8Bg4 d93n+sUbgTeu3px3s//W/Fu3BxMHh27zbj+5k3Xnxd28uzP3Vt/H3i9+oPCg8qHGw9qfTX5uHnIc OjXsM9zzKOrRvRHuyLNfcn95P1r4mPq4ckx7rOGJ7ZOT437j154ueDr6TPRsZqLoV8Vfdz03fv7D b56/9UzGTY6+EL+Y/b30pdrLg6/sX3VOhU89fJ39ema6+I3am0NvWW+738W+G5vJf49/X/XB5EPH x+CP92ezZ2f/AAOY8/wKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iagoyNjE1CmVuZG9iagoyOCAw IG9iagpbIC9JQ0NCYXNlZCAzMSAwIFIgXQplbmRvYmoKMzQgMCBvYmoKPDwgL0xlbmd0aCAzNSAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVxbk922DX7Xr2Df1jO1LFIUJfkt TeKZZNLWrbfNg5OH7XrdpHPWdnyZ5Of3AwmA1OWclY7XTuwHHUIkCIIA+BGk9hfzD/OLGWo/Gut9 HVrjx7YOgwntUA+DeXtjvjevzKMv31lz/c408f+7a7Rpaju2oWkSKZd6X7fWN4Ppna8HP7rq+tb8 5dJ4G9vy4/LWPHpi68ZYc/nSPDcX5oF56O96VEer/Jyav8JjVC7vE/GnRLyZvPvuQUU1v0vEvz0w P5rLb83Xl9DHPo3UY9MNg/NVU7du9NYOUI38Oqkp29radX2rmjIrmqqmmiI9Xf5vJqdv6q5tmtZ0 Y1c3zvTe1eNy7iqaKkgUQj12Pao5VLOtg7zd0AyNG81Yu9H1Q6B5f3laEdXcNEQRxfA3KiKbjO3q rgt+g8nsUMRCUjFiVYSFybvG/4EU0YTahTZsUAR85wsYsbVq9v+kojMXT5kcbbwSD2NPuaWXcLg3 eMIPDnigxD4iL7nIXsXudJU8h0vM7nViM/W/v3If/6InBHpGT8h5Sc+G5I0OfYViFoElYYa/clMO D9coDuZi2ttLEH11wZL8N3H7kB5v8eiMvGPxuArznEeJGBfwbiUgbHQ08YRjISHZu+kbj5qDN3Zo 67YdxRFt053jf2LVx0Mzgk3dNxSa2bxSwKnuCM0yXTxPrFJWIpsIK5FnlI2Ka3KVOE06Fb+l+eE5 eI4SzO8rPMhQkkFXF39fnYVNC5XMQY5GxWycDMst1q3R9+NMS9MFbBaW8wI2c513GBEMlh+swaw6 srFquujstLE8vvyrwvhaR0tByEbWouxt4Bi3zcZghtXO5b/txnp0vtupvT8nA2BzWF3NT4e1jUa6 4tRr5nR0yTjuXN762vYtaTzF7g3OtWMROzoVuoghmrSulwn+2NX87miiq3YYASh6hJUIX+6KJhy7 OURw3DiyipTLA8fuFzCUjPAkYHyTzAfxIsYPNqOJL1bihMd8kdjyux83x52FoSzjTvZLAl/HDciG sR5csEb0uWHxv6g3w8HdkpI8PaAt5OnqYLtgHAystaOYGGIIMb0DJ9JSNokhpzREkeuEhnpXNwGA WTS0BpiNAOYqbi32udhUUvEBcTFSRNN6AvgTwDz4/hxFCPvjA84uNvR16IctFgHb37hBWFiECKTj Hboae4n5cM/cHwj3LcPth7odOrchoqzO71pIj3ZYnbeVDXAFh13Rmfuzo+JMd9bYn500/2wNtMaO 2LityLPF/DfKgwnbKk9DuPLsbduaPEeNc4v5eFv7Bkvh3QvS5zGf1tXWIm6szNcSSH5Pi1hQoMzr Hi+UjKUZWU9R081kY8Zr4HRzheXiaAqFG+jjeLKFq3xNgmI7x1CeV3Reykvsr0svN5RVmwfDmzou yaL9H3DHijwdMO8v2vSuSY+pFtzknZ2UdGyshTuHOG9wSnuRGW9knqJbUs0C8BfYZUyi8VhKyFHt y0DdHVjbpkemJwRk9ZIlfpqF5DmyeRb75sa8SBnDL59h7eD8WAGDclro2ZeL5f5hTiXGtGSPzXFn SWDnkLTyGMGIfwZl2w0GmUYqD+ZgnsWEVW5O6a4T3Gw3ovWI1Cda3xrrhj6XEzdNe54aBGEW10EK C68l8N97hB6It6AdQMMOnPZGvnYtEDNRAsAEkgDSsiLanNvB/ASc9Typdh4B18eIYFNZh2RuZ1oA dIySdDanHOK4UUc1ESm2bEUU4lMpHxKHtE3TbWmR6AbKHGIMLbbOSKTdLigHJCfBte2Q7uRaVQeu LfJ9oMAsHTKXSgkjwHBPIXOFtqiVOa2265s6eOQVSAbuMQQgjBEWoFIFoJ6u70LFY5EyJPCdq50D A6UdjPdYgwGPM837obY0GuFdZYpIAF5aS2gbKFXZTjRDMnCPqj+VSnScZRcK8ZLxCG0T5TraoDO/ 7nBZZKUbJE4QBJL5TcsH0zYWRgH/0zpt46zxrsEC7vCaCkiTU3MIPimfLHHdbojRghwttu1Gj+4A pLXjQMZIwkXRtASXRibcaBlO6YYklNIQjyzshzmmkvRH7emtlE+VuK6Ok/pCW1GCdqw6iqJpiUXV 8uRtNSnBlpPjno7KcGg1rYDxuUAuXZjz72eCs0CDYKkOrMasTq5uoZTV8MCjWQkid7RjzRSOKNqC XGlb7DtbD61HTOgRHAJyvW2PUzFg9xZZoga76fn+WGMqhflmDANcSM7YtKhsEdn7vpczNiwtVJUf shFGiMYZ28W3T82/r969u/kAaCY7xI/qo8XK7EckLJq06UAM567+9Il60APDC9M/cs0jHCK4xwji T3HSIENS7LSeSJV9xefAKoS2MHmWwMAfEqswCplglQKZMFZhRDPBKqnWFKtoy4/BKopDFKsoRbFK gUOA2girTOpErFJQ1rFKCF2NnG2GKkIoQgqTisgQgIPGdiiBhK2REvIToBKYluMHU0pOK+2wnvfB +wlQ8YAliBIa5vC+DuMwKE7h8gSnJNoIRooIuB0wr6CGwKyFUAXpv4z/QpNaRmstKbldFUQHZXQU 7WWheBIUkcgkZJACTmmiFnUWhLMRSkAguWUEgJ8FLqE3ETkEi51C4xiTBGCS6NmMM6QMXAHEIiVu Oa+LBCrDkR77MkI/ikZ62ye+hEYqLfES31sk2tNeR0GB0iJmEIaxgCwpjIJ+VvRTafqDgYeKy8BD h6qdkBYSHrINYJj8XPmxG2BUoUOSESvkbWGYZ9mOGkq2HSy7221HcX9sUiIL4VK486YwkEYGTtlT eLALeOC72vWYJIUHMLcOu6UJPKhwA2cfPMBG0nVyMiO4IMGDWeLpfHjAfXBKIUOQ+4MHW3uYwAMb CB5Y9xjr7xn4QLf+EVFxHlTxVwRkGZ0pHEOw7PJJWNYF1Y9wzMuVp4snr9/eXr1/f/PiccYuJ+EY ttg9mQjFX+pkoXDtpNDDRt7Ymg/WAabu4P3k9av3j3+4+Orm5dWHw/sfHmzrqgPutZ4umO3oCmk4 gXenVNThzprdq6Iv3v58dUAKcVMHnUes2qmnrcIjEdQHnHnsUYxFCnST4AGCj5/GeDokToa9SnmD fLYIfhKKF7c2zkgbUsYdyx1dicOlDvyrPgaKR25l2hDc7GAn8JPSYnfurlsscLh4R0k/geDVkgaQ QAc9FE8kOUjAAdFwaJCb0LagzflhzTkHhGM0bgKnaXxEqQo4TSOepQchzwyEz/gUCUMcy+aEYfBY SFvMjyYMlVLCcKmVF2Cc8AAdFXC6BTwDFprAcKHlZkcpQDW5loNBD8jhlvlCXAoK3tEVS6iDspgB tycH4EGBDVy8rjIsZVIJwpmUAYHwLSjcOzghRKaMoki0hZJBOIBo0soEgiTVlRsDnoMsuOi7RFJM K4YntdbakfWdkSqMV1IpG8doXMsEmDlVqLSItRGOc6qwh0jRyxmWSzkB8SMlrosbsCkRSF0BxA/I QU5ThYOjY1dJFWqJ8bCWi1Sh0iLkVo6pJP0xCtf+p2+nJa4rI8G8xveiBAXsqqMI1bXEomp58jal CvXdbiQPa2vrgS4Wl6lC8bgSBO+xwE32tmaB4pdipQcEC3FdoWWXZ5EyQeQu44KM71B4ptLmCT+H 5FjjhtOIHnfqEQ/p/1aECfjU9sg2xDv1c4BZFXfqzwf0qYsFvLw/PL+xgwLG9o9+FziPsIuMblJ2 NVc2PmC4DzSf+lho+z7A/HbWH4vlt/e0FQ0rlN/O+jwkv53/VtEVyG9nvR/Hb+e9VWyF8dtZf24U PwAPU9pNUTyO02Mabs/hf0bxaN0lbgMuLHsuAvZtAvG47IvML07G6NCHcsIAy0xCvi2RkLLGnUXb x1uUfe07nGgTDaENL7QlkWbMBMDjUtiLjQeuNLAB503FUOYEAAYMNY4aANCnuw+gYbUrWoEwZVPA 97RUpcW1CtgbeBx3F/BdKCV8F1peXZHdQvY5KOauAhKfvsERe7neCq1ox7WWlNyuwmklshlQb4nf ccOg6/FtVgYBDS6tddgxCFCQcga94MR1SggvtIzFhXdBYQkyFs9SLWstKbmdUc1kBAVtsf5yIl10 nKGQUPJ4sGfh+ZJaeQaFkuucnU0fcMQZvZJBvJYLEK+0hLVxEoHZp0N4Qt7Y4UYvF2TO5enbWYnr joBdHBEir7Gl4/nivH+E1ccK8bxfS4yMx7SBiBdz5LxfaRFqC8NUkN4Yl2vv07fTEtfVUTKGH0QH CuJVRxGma4lF1fLkbQLx+u4MEI9dFi74wqULkCuOmE0QZrndBMsrJwsTzAa3ZoLinGy4iF/ZgcWY i2AwCyvZeXJ4AC2NcLIpllEvEvMNjukoU3PPiXl8LNI2+FhkBcffW2Ke+1hAy/sD8lt7+P2RPJaE 4ETfnwrKcycLhd8Hlt/B+2PB/I6utmJLRfM7eJ8H53d0sFV4xfM7eO8H9DuYbxVcEf0O3iWkp6s0 vqNbSIBJdIOpp1StRa6kc6DgC0Mknrv47cvkC5/yyGz9jwTwgRmOygccB9FNuxgIq7aPbfkRT8yw ngNzpj8SEC+O41o1XQrHV5UHPPijZZTohjw+9eV3L9JleByuPWzjl9HTL//Wh9VbnL/IsPRi1tOb t9c3b95/uDpUb3+GSjB8D0BPXo00foAmPH2e000G8+ibW2u+eh2vJK80iAdJOATrcRus8fHLidxi o95VwPKPM5z+girrHV+04BtXWYBW9I6Ynb6gyt+2wu6KrwfoQz6oPROnGo6Xt0/fwVqcscJg418m UFvLH1rhzNPi3lxLg8bVuv8DzxCA7AplbmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjM1NzkKZW5k b2JqCjMzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzNiAw IFIgL0NvbnRlbnRzIDM0IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMzYg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgo+PiAvRm9udCA8PCAvRjEuMCA4IDAgUiAvRjMuMCAx NyAwIFIgL0YyLjEgMTYgMCBSIC9GNC4wIDM3IDAgUiA+PiAvWE9iamVjdAo8PCAvSW0xIDI2IDAg UiA+PiA+PgplbmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngB1V3Llt22lZ3zK9iz8loyRYJvzxQ57cjLXlKkcjxwMnAkOXYi+SHZ cXd/fe8DbDwOLy8vyFJJFWnAIkgCBwf7PPG4v5R/Ln8pp6qby6brqqEtu7mthqkc2qmapvLNy/Lr 8sfy/sO3Tfn8bVnb/2+f45u6auZ2qGtXFO/Grmqbrp7K0XTV1M2meP66/MN12TX2W16uX5f3/7up 6rIpr78rr8qPyut/ln+8BjWb9BQ3oafpq74futLSU2zR80159eij8uOuvPoRl7m8+tXdvXR3b3Dp w7OXHxV85W/l9ecZnTjA1KZuqmGYm3JkJ3KY+vHtMbWpMcp93wZ68pj6KRjXmPKKDPzWsfM7XMBq 8hhQkLsSXLUX3h27vHAtvEFlGLCT9o4NWJEhBc1gqsHM84JBJ1JQpFKQO2CrACo2pbIZeojlYC7R 46SysFIJKfjBDQZxzxHCeOUzrtipPppxqOpx3KSzWGiPG/ANY7nNt3GqxqHdyzcC/CcHv1eOi7jc It+muepNHTWEk0gNuPfJuNlUpoa29RprjZ7SD2QAHBn3c2BcPseCoSryDBWYVTVjc2c4Zuq2mvpx qVP1CJ5yrHGsqt0laM98ffku9OznaH0qr35zppBGk7QYRWAkN3NkD5h8M3VVY8ySk5smP9sFscq3 OOgS1UNlhnZYk4WlbOa6RCvG4JJSCy7aMA/VPMJX23LRnGzu489Bl3GYxmoYJzo3dVXXHRxM8TGv n5+RA+9AOnbZF2/HjYQdmIeuLUnjGssWQwj7SRF4ABGAovG3lA9aB/ootLH84ndIknhK3zvh4atv nZjpV71T9VgawSf+3jf6GatizVSt9IWob1mj9nb5QdposfDS6B/wFX7Ayl4LPXDh2CCdh/91HaJ7 598hNeGh1V5/d6+yuue4g4ohJ/yH9mHhGcs2yDR+SKo8W86zSdgXqtIWnK1qF5WFdF/ZDHpCxVZc iGVWBBcR0qY30vZzNUO7eRDmRAGg6yS06uqqb+u6Lfu5r2o4N52p5umsph2gJfrRoNW+wqsI/fqp nmozl3NlZjNOg/Tlu9sL3aATqnbqjRO6TT0ehY4DwgtHia4Yh+5bZ684rAQzheAfHqgWi5fR4+S1 wlcnYQtjSY0ej+AV6Bc+UiG1FC8SzQ6lYrkMntiTX9E9EKOl0/fkASgVnfSZXKE2nvBeawSyjTGu fkZGUTC1tLHN31Apwme+QrmE7Gfa/gMiYqapGhr4nR4zGTICzGjNwTHRA/aD4+ay0I43uruvS8WO jAritqprTB+6lGF7bmKu892HAfIP4b/sPZyTSgKc2CFoNF5pPhjC880ASwsvwlKj84WD3qpAXotJ rIN1JUp1u8QApe3pQkq+cLXbp4UPk71Ik2TdOf+QPaDwEE0BcFZgKb6Ud75JQr4UQiDUX5GgZ3KF GF/LFV3ia9RsJIEXVvg7P+Wr2rCyNTLYUlJcUReST+QzqeQHWl2yW9EQ36JNbMeqrztkLB0aM+Q9 WzjOWsSM9OcgtnpG5iAr3cix0BcCkogJisdihGPJcQqjnqpbfrCKpoB1W5kergDG1JTpV0gSmyUE fnLWlIKnX2F72p0lnohOfsc6qW1ZNfuge6Tp1O1pcNLb1H3gK4ETtrcUBlatB+ATp+SLy/HFEbtl g7J6LD1u7g6O62pEIJaB42y5svw5GEMPXVN19bhqdc4GYFqutCPFZ8+oSAkSKlDqOhYGbFqssFAD aKFjLX5DUPHXKzSCRDSlVqtlDWcNYGrXv34EEcP3pMO7co+p0P39A3bFu3YAbuKUBimw0xZabChu LFwYCl/9aXOwpokn+cg1518nsd7+aWOrGft3p0E0TRftU7lun+izvtjrmu2Z7Gq7Fmn1eig9Ku+M 1LamahpYxePWh+OmL1ot8xmRC06Ls88LAcwB5h2lgzDTapnPWKf+XMuYR5bGeXEphEl9RUIMhGT6 7QdcgWbuqm7sG8ylqsGQvNaUmdd6DkIRvt9eXsvUCP1ncZ80kVvTo+9HzxtTTYbuk07+LdT8PnJ0 ajI/1mlazK/Mq/ScJuW10PBOA5yFPuzmQ8L+LRRhTHYFcUnNTvStRehYG1NmtFqs81+usgj55AOG Ktr2sGrW6Y2WlcHiitXwwndCkGbNG9ul4uabVAshhrCGTNfCzuvuervMV1lpqlYKnxTUH45OHVXO GpmNu949E+uaqQ2OOHjItY+wF+VAJN0ZU4G5fNNmrYvYJ2kHHbweanPusiZJzqUVViXtGqMsEXII X23oQ8+KF4KMrxDcFA7eaactxAvWmeIzvslaWKeWNEIdr2Qi7oj9GVpkdesZWd6Uo5vp0/czwsgj D/36tNOH0O091hy0fc4sGADHCczhsj6h5iEaeHkCZSzOMkFFjPDO+8iEDJWcBmXqCoXpGA14PXHC hrfd6FQWgoq2ypytU32zMranFS7J/X7Nifcu22MRwtVJKlfO+skWZhTYGurPFJZV9by9QMaMI9a7 jU2ZD4Z9sqL9jkszPWGKth/Gqh76O7OKru/Hah5uEn0/AgSQwNTYoQAQZS8chKgkiSveaejdc5UR NpQNQvbfTkT13AUb0po6Akwo054VocgWfnaUvSPp1dWQbLa0La+WhTRaXHVBQjPklZ3Xs62Br9aS kYgg0jZ2QtX7BHDXLEcNYHUTBDAbYTcRwGzHv+8woTT6PK4ORDId/13Kr/AOCgdEY5PjQuBQhrRu 5jPKUBCCNPrVEqWlRldGofvRwZ6tg6R9ONAplW1F3Mxj1Qwz5qZ3MZ7ule5ZwLTtfGo5w5xkEEEb j1CG2OtVUQocsXWSI36EH4k6Kq4e4yJWjk8XZp108EICtAPKZ9VtBiRt00DghsDnuxKP9O2Myf67 k3DGSomqnm6UcH4geIDTpxHIOyKXZopqnyhLp+FKH3qfkdAUj88gr9IgEcxKt4SDUNVBcysWtLjS RpaA5QdPCfUn7OIX8klAPrvhBYDWk/aHxPmHvKVOI61sbIXyYuFB+Gr4xb9ABzIorFQzXqegyXj2 hyoDjD+m4mBX5P/2Mp56rrA7oi+3oAXbohaHg76TdTzZWza2VW50Ng3meiQZeHxGnyOlFSnxxzEJ w7/iaSwAw+FjbXoU2ZIdsDDDQjXKUVw1ftrxZC3B50tpYnsamJQ+EsrK2OwSQzaqYqEyEeV+ExFm 4TWkK+AcPisb4eVahDGub+AXgTrbx6B2rLySw+fFzTrsmSJxIFfRmhHLxSVXoSB4B3IVsJI9lsit SMQiVXEhGaVn6rdgx2dZIpQqWw7eK+h+IEJLgq5Mt+41J/FBZFvwB7ki6okkfs871u2r0ZLBd+iN sgkmKHQAQvL5ipY9NqgRrDm6J17SkLfiQJKCbrpF9W+QCTbDDPV/HlsfRPtjKsjUN5rioFLhUGql 4vERMGRhqjHEUb+nlJqfhqaOBr5uTw812PbYmR56SDFjUw9B8Ak+PXHypWhhSOJXckU08EyuTbFc qnUgW8fo3wJXZ+vI+RM0Jz4ZX6HlCs6kHQ2tGPimFj49thw+Cmb43FLGZ9re8nM2u2qgWUvQQ3Yq jJXhu8zBP5ADbGUKFN6PHvvNkP8mKYhLbmJwy7CJtpqxpjUjQjtnhJYad2W09VB+StD6UNbfP7Ag jsuGOYdPUaffxcsqcKhh+crSf3rXdGljRJj6vjxCXyCfvot8utBTtIPUTITvmWg9F5sHHCTZ09RP I7ZnOyxkOCQ3wWZ2eqybsF0c04dr9CzSYzehJ19WRGra2u8h2lrGcE5WCE3CgQA/gxlCiDAm4ClJ lAnqOIuc4orw99WxLSpxrbY1dgk54pBUfeMQ7GtbAFqbUV2dEoWYsfI1nYq5FZWLTlaIUlbNktbs WgWQIBYyU7D1wd+yTcEBcWtlWcyIzZgd8eTwvekH7MP3wdnxDhu563Y1Ql/EI/vI0dNT+eLf99Xc 4qCIlfhoIf654maB5nG4QPQjF9vkilvpxc27YqkMhNjmHQgRsm1w8B7TZnriDwmRtYAU9v9wITIT jgWpOxgthZI7IETdUA1Ifa+A9oMIEbYwtP2NppioNoPN2hKip5IcBlyjSy3RAbFG0XoBKKOQ7g4L qf0Ztj+0aF8uvqJ9guI+4Kdn7txvRqQpsXCx7DYYtxhIaB/dGZoWcmxLBywT4KkSCZk3L/PbOiDo nIuGNCRwzugAqyZICQefo7Q0pHYgtw3pLS57a5sJq8uwF9+PVUYQk225Dhj2GFSZCQsr7s40UwdG jcONpploLDUOiHoK9NGVFayF2HpK0c+c9LEIpONLpbMIsji/TJSysS3MkpBnQgjmuf5kCfIWuAgp ly9QDjXmhZNfsX5SxAuFyCeb+Op3zuHgQ3r0fHZAhu0ks9YfNPWsk30O0xG5WvSAJLSml22lsM4K eXfAOmN6DG73qk95qtXJOH1hapjDdmagnRXcGg0aM2KWY8OWWLdtKah1JxhxMzXxx0/ysqM2d8a2 dCRJcrgPLeOksQOokOUXQ4Nlyp0ahbuACjiTU85ETLb5WEkRZgc+7VxjveCNkuVEkEauV6laB3JN JV91nlc4C4P6npChjtLQ54dOXYb9yv8H7RjnyPnOlidULpYCrO4G8sr2MXWyv38g99DVn7Gc7QUt anHPvlB+KZsHoiFbGVsgKyh9ZBOr5jM2e6spBYMTunCymSk1dD68ZLUTpjhxts1dCYfa0VRtnZVS 3JVTWEsCiOvg7IBGiVfkFEPigwsYHgHByBuzkAC2che2x/A7bUD2SVjq4bMpVuAlKlvCVjYTRQnb F6ftWdJpsIIPx1115daInlr0A+JuvTzmRPVAfjBxB4KracQRmbrzd0DcsS2kbu7O7gtkPqqxWfX2 FhnEmxj2ixMIAw6H7XHICsk5GqYePFqp7bEYc+wHdbZSPc/i8dzu2UqtHPvb+Azuh4Nn4L+iR0++ LnTFKh7WB+DE1bPr9LBKz59t1eIIrGEykxoA7Pecmts+3KptcTSruTPJSJCCCYasZOQq/7PXJG6v kQx5Gjn9aOzqnMnvbHoOxEWRHuxT6Dqfp9mUF3gnX4uzO4SDdGnHV6O7ey7VQBu/GnPSq2A8Wzk3 hB8sL9Z9WBZav2W18I9CKLzz/8EVGRM6y9ZLDjsSSBOdGlbjnRE+pDfEO5/mCWtcrF/OEIUVtK7F 2l3u4QLfis+MehbPDhUSae5Xe3OgcIVfDIUWIRndE/aQLc2O0E4uxVV+HHGil2CnLq4exkaZBluw WiLxdkzVNzhZs0H6qS5fuO0bD59BN851P02mw1+tmbsGZjv+9ezhybHwH8dz4e0Z8yNWC/SNEGwM IiFsqMdZCDi0GPcNNmD2dV++Kp/ZgwTjl8KR9YoQsRT4UFZr4Wx31NLiAHv3t6smnLK2STjMAGaq aoNddgOOj5Njsl/7Ehx66EpelTiEcJLDW+UYxKHDaYQoGnE2jhyM6N9hPb6keFV+j4MRv3FsXJ4a dbZT6AdOc7ZrPXrHHltQyOIPW/BKeoo3fF9b7JlK3pfHqgIhQ9gqQ9pA8RY9glGc3yhdabHRBv1d lrzCtmHEhXCH4ls9fhsAx74LC9B6KyvYWQLGNTgLTvIhoQxvscy/tVUSvyuGpq466H0wOH5Zg8UT RiZShcN0W4iBJ5y3OCi2xzpGgxmuwRVhELoOh3GNQBiLUIDqbE9cvch3hRLfOmoKZeyJrcp/6XkQ K/fcjBT4kpQqlhWnb52WPLf4MeXvO0QLJ3vWQMYo8uD/BCJqWW06i5CNuDHYaCfnCtY4YsPdyXyI gO25vi/0U33HdyegYJ5RtzSDmqElpKkGd2x0brAFHf9QG4jzd2jLyJka4f4V7iFCoCqWQVP4GsdJ 9EZT+vYK+V727Hra5Xu59z0LtUmnbVPyB1tNy4rkoROVbV0HlRHBMUIfSL76dSiL4iDYuxlgUBeF 9BQepyUQo4VoR0GONUWx8iBOSlYE2fcw9qYYYpk7+bVDCDMh2BcRw76yqWwwOzt18CRlazXUfbM0 dkEbiWKs58EeimMNYHIbqoX6bWD3mKUae/siL/oc+avPn5R/+fbt25e/wdPwm2Z2tlHgJ0tiGy3Y 1M1DgzZtU1gnCj0qv1zyX8daoM0+30Ly2yjj/Wa4j+0cjfkEJ009QRrL9yn8Vsp60OPd3Pdhyo3p OwiANeMGwrTXjsuXM6QQHoE15DCvvNlpyQVscz8UMGtViz9AFIsQ2rMIhtsexoISYHZE8IsSqCxs ylIvLas6as37CZ2CSUKMW0ApJ7eiMWGu5KntOW6xNsW/bJ/Gb3GbmHHZ00VZl260sm8rmPFQEqXf dta+FWS9hVnsx24okhIsRbHHHEXT23YsO33rpAQaOZbJ1L+4BIkZl2iu7lo5k4TOBX4sCNYabpXv C+9RU9Bu4Z3EkoeyoF9D3UmJo0Dq8lrYLkgQqnJK0u/IhdQF8PxDXfQvAt8j7X5s0v6wLLoAm9+J C3nABQBXxZG1Ftf+nTgB9t7aamPsgYr0AiDGrfcA5G9n/W0p306edzhBnBYflWB9MjyAYPFNJ8Ik 1t7+9dxZWPt3YuXtvbXZoQbeoW5adyPtxFL5q7Bl/rnQTMsfehMsv+2pte72L9r+UAqywKX0+V7z 34J/I7YNQLIjpLzIRIMJwXbClgMWBX4PoFNInZacqATANYqarymKqKcpKTmvAFbUxIXvHGcwOAln yK1XPDDe23eRZ+z67qLb0EJVwCs46zZYl/iS2yDpTQPNcGJwJar0bgNt+VG34Wwb78xtyG5BuQ2m Freh+wSe1131GjqIbvAa8LNPO6N/7zXAwkevwd4c9Rq6HktWkQZOvAZfFL0G5Ip7nHueOA3JO95p iEXHUgD0Egbo1cRpkFs07J0G9tU7DeGpcxp4e8ZpaHDA4oAfk4hOgy9JdYYvi5KOkA7nbZtEGyCG xs9BYAonMf6+LH53tiR1GgyChhl6DX0MXxpkyAcEj1GTmVYm1+bgNPj7VG/6MtQUzHMoC/oo1J2U OAqU0+BpTzUZ+RBrbz2vol5mSUrX+bdSh4djczj+N0igBOMvf6fGX+6dOe8QOUi0zTv5iY34N42/ jMbp8wm5P2/8J/FdlfGf4OI54y9/eeMvf6fGX+6dYfc18E6mA73Jt1ig+XfUwmYzSWB76Yy39Mkb d/k7lsa/hJuSBguxfRGzl/GvNLaXWVxMjomQBIBgd5GD+woYigC1jWFOPcHzkDkBkYiXi+1D3R9Q UANnUi54bi2Nu2lxFK4stj3JCfgY1WdqfU4gz7gjzzTWAlr5idEiRtPv0rizjRMH4t0Z99wWco17 10v+BKmSATMEvcFcVQMftUf8aac7J0TH+39HlX4aTjPGiXR9OJ+zaEebiOHFelRYX+A8KkyA2ekh nkSDtWacupLJE9zJPBiOM+cd1ybLaeWtnQHSK1Mu9yrNL2VuJeiwrXLAiWOLXmHRRtKrxbRzXHQk S03QDT3bdO0KOcklU3Z4BRN/0pv42wH7epP527s91mwOIzK6fowIWtWbhdeL3siE3ujmKMF4Tk6y UzIDiEJZoI1uJOtqcccu2kk+7CdhV/k9PySLZOLTc6q4StcY4piSB3iICT27nAm3cQpwLwBuBGv8 XoeJ6yAusOzcIEsnl+xMZxYDOy079rLTbbZBEyk73TpQFMqcLS5b/MfEpMyufqKmmsl+DvhTvCJn x8isJwbli+VGnnXg4lc+BXU4bzZRLk9evnn+8udff/v2VfnmByh06KAOuTZRzvjpTfxKU9ljFguH ImNeJuH+/Uevm/LTn2Cn/1z8Ap/okjJLxT5TUKIyQ+3T7BcXoKX0Fwe3MHBV2n82F6tOZ0dO5zYI lrN82wG/AaUI3qIQgk20eQElQEQHQ6SpdV9z/SNviSyCKFek3eEWmPm2GzGAHi/LXxFNgJFg01oD PCbWWD0J4sVqjOLKbsRwr+5VAwtA2KU+FybVIyAkthtkHtP+avmSwemRXGCwrHaA5tRKLi6tFDbL cgH0XLZx4UKVaQfGnWCGQr5CpviOyx4QPExMJSRXF7I2roQgN1kNBzKStpeLB5QpZovl6D6Is+Li mo8QfZmP9XzGZfE5RBgm6qGb9hAWDSOFgaxMhzBo4n84+7jK+xdhIHOG4KgmRUTUY3405fx7VaTw 8E3XeU26lBv3u+LBKySfti/WblJnkekcAjlSIToskb8iL7S+rJpDJ/snoizpZ6ya0kOxWdrwdFGS 7HqwLpGVz702XGuLsHNIOwak0KvLB+hv4iDhaQ6S3pnDj41iY1igqEb21DP2toZqi3zkhTymvtOv nJx1uq4IUvEIev6yo9EhcB4lYTS4zohjHMVjzTXpMFk44qCFocF6vxqrSdQXMvO6TuA74zp8efzM lf/drX2uyalbEqltG1HScNdCUAiWNMP5n3+VmfMGzofM5dj/4S5YzRb5uH7yWzbW9P0tx4TnOhUg 8vAtlp29dfRvrzwNIaHuVGZISMmlouIdL9fOEGgbTuOt1ciKR1QGj0iritR5KHyAxlcoYayNepKy qH8U7EuQFo6wsN6/30F1RtPkMJzO+KU9dRFFAKLB+sIzvpezIe7nyGGc/e/SeNLJcm0N9HCQySx8 LJ4v+koTQ2Zpc0D7QX6yCdoI/F6MTV/cwwWHPrNWr7MfC0dRu7+nDv+MxU9whUpna2zb0uf2EMFa 6WdslB4nPsgZGKstF+J9WVn2WHA0SVpNtgj7AYnaUkVlO3AA4UNqNUebYJHA3L5zV4KjvyUbHMNF fuKRDLCPacJA77d0Figh+PmU8FO1h6d/cPigxaTMEiYa1LK2eiqu/olLjOoIE8L3ZD1yMF1q+I6i RfKBSDLK+gsM28JQpiG8TLbU2HMeTQ9TBidzvM7S5MHFyI+YY+3O+WTXfuNj3UVRJZDRiwnJzW4V X+ujlS5Kgc9I+m6tacNTv4uY0NDQhU/RHdFI1GKMSPkj4RpalBHqHG2bqJY8/IlQizS3sxgo1IqS ZHiFTXPENghtIjXQn6YbUXhG2W1yvvSczzX8WB6BBYyYOppkdRiWr6zkAE45ryOUVJOHBIxsqkC8 wmfsMQ2/D/fJDvKBPgLZsdWErVRt0YDpODEWEv14e8VKzyk5ZxT5kh9lTTp7sOrOQ8mFwSqUm6wG K/Xjo/Tn2CYk7GX2wQ+S9uTPN5j65bFBuIUhZbh9SHrwUgwWoiY/QKvioZBbD14K+Zhx0TLHD+xZ TSsyaw0SB4WvPgLIYKXOy2xx5UczldkA0lWZZSEBSHAyANYfnLcxm+Pu1GPGuMsRYjNSSyn7o0+y FcEZHBdVY2vf+0fKgIz3gCVNK3okEynksYbPNUYa8rwaR/AZP6DmpsaN8hok1G61Cd6AGiklMAdy bt2MH84RY28UG9aCw5AMhFtPykkrKeeF3PAqU34lE2pV95Xv0ErxGYHLQkoaI6eQjbAmR79CYUpj rDDPharfCxuDVcI+adMihWHRdImN7AdVBHGgC6nFmRsjp8g+fqDZtwSc1TeMt8LQOPNBxvmR4miy fX7CylnICoJXgspDJERKqzyOr5mW4n6OioHZx0+tlVhPGjgdVUymaTkiKWGIsVgRe2EYAF8aYvIv 4/IAggJHlm8+pR/IEPQLp034kLLhLQUVP+WPvoZ/SHBxrCljF2yLEpk4V3Ze86QZnGCqtwPJHitH m7HD2iLy83xksKJ5noEfYNafyKXHvLqZrEImREX5+rAebFNdinm2C13ad/5r9D7QN2x4XLEop54p xYYixaHkheJG4ePYEQN+SpBDyfFlNVox8wu2RECwNnsJIQFr0aqUVGRpGzsdcO24z2YzzNv/A3L5 YCUKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago3MzM5CmVuZG9iagozOCAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDEgMCBSIC9Db250ZW50cyAzOSAwIFIg L01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjQxIDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEg NyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBSIC9GMi4xIDE2IDAgUiA+ PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0 aCA0NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzX3briS3seV7fkUO5mG2 AHUp71llDAZoS7ItQ1L3SO1jGLYfdFrSOTrTkmxd7PF8/awgV5CMvBWz9q5UtwDVTiaTDAbjshi8 /b383+Xfy/Opu5R1152Gtuwu7Wk4l0N7Pp3P5Q9flX8svyvfe//Hunz9Y1m5/358jW+qU31ph6ry SfFp7E5t3VXncmy607m7NMXrb8tfvyq72n3Ln1fflu/9pj5VZV2++rp8KN8pX/1X+eErULNJT/EY eur+1PdDVzp6ii16/lw+fPRO+awrH77Dz6V8+Mk/feWffsBPH9599U7BLH8tX/0+oxE3MLWu6tMw XOpyZCNymPrsfkytK/Ry37eBnjymfgDG1U35QAZ+4dn5NX7AavIYoiBPJbjqfvh028+XvoYfUBg6 bFbfbR1WZGhBPTSnoblcJgyaaUGRakFuhy0KULGplfXQQy2H5ho9XisLp5XQgm98Z1Du2UPor3zG FTvNRz0Op2ocN+ksJtbjEXxDX27zbTyfxqHdyzcK+Pde/N54LuLnjnw7X059U0UL4TXSCtyRjLs0 p6aCtVWLtURPqR0ZBI6M+1tgXD7HgqMq8hwVmHWqx/qt4VhTtadzP05tqu3BOcdqz6rK/wTrqfYy k383ONamhsT1bT/p4WuOdUbhhpm/zQX8Hqw4lw8/e47Qg9OfNIZbkXeZbKLlLXbgoebcneqm2e7W qWLm4qEFT3DNokV8Vg2nZmiHDMXMxmcL9AD1bVrYQM9wGU6XsTrnQJtc/twg1pGe83gaxjPZU52q qgPaxb/i1esVpVQ0W8o/h76qEplvwLWnS9Wfz00HmN02l66uz8lfm/wE1eNQ1305ePrJTqH/4ukX krbQ78P3vxTtl+7Unc9AKZb2LWIBUhRVvoBuC7rU5+fyXJcPv3XphUJ6fY1Giun5s//RVOJ+Letd /5Z5faZQkmbi239HXowViDJ/xBOsEKETsxAQ0L395DEuQRbf0V791VTMMvnuS1/RtAGFa722ekLc t/imRnNJD6njD4v/D18uBzQs/p97UEvwwW6wqEJc7BbiBrZgOLe1CsKSjZrYTAjCfyr9rh+C4Xfd TOxqs7CJH6AfRHD4yPEIUZvlDbOwr/KR8MwQKW8StY5c2lRwjLtO5/HSKm/uai8fQ+YZfq+a2qEr urzdTV6/n0t3Qa8TCV9w31116tuqasv+0p8qAPiuOV3mAQ1t4JqMOiMKOzycB1ji5ly2gI1NVw/o uP5cnWu0EEGJr2NoZIAb60exYf0JlTJf1VzKy6m5NON5EGH4ejvQMXOkSueSvGwP/aJDw1imPffN kjLNceUug+EUjrpBc/Yjegn2j4nWGrKX//IOFBbj8tOiiVnuwN2K5JtfDuN4EmE4I45SjZfYe8d2 Rt22p6rrB9CT3RmL6GuZOzOx0XhdEEoMr4cOYuyl10tldbnU5+YWRmjxGeFAhK9ODWT/xmjgcntn 0qAEhfYOIwJVprVeB73S3i3YOPSX0+WCuEFWsJFKYn8UkahDVxjDXJ+JQ4fToiviDzWLeYhI6PPp ++jQ/gH9BFqx4IPD71+h7Bh8YxbrT6nQrPZbMckRXbD61ygGJoAVWhPAJ4uvXM5CbQYrZBUEPRZP qZFiFf9ChWgTq//Ot3CRM0A1jnv8kFVZ7vHJfR+IInQjGeTXhAyWxjy27DcgCowCpQs+64lC8C1c XVWfx1Kl8FalW6JnVeVybEBfnUaMox6hFewwilboMMdUvqNoUQqYyCeL7SgazMLCvvE9xG4jJubn qpMvKD76/Fyew1AjSCDjzqyGP4Fmp2NULtLFaphoc74GXVGbSB5/Fov+LxDVBgMx1eKUY6yWbaVQ s0wbRrFayCfGVpQZL64w54T30bqw7t/IR5VQ68wSaLijfogTrivRDy+Pb41+dPWpq0aGZG6KpNHo /F+wM45F1TzHsKp0gDWlVk/sWJaC6H4K/Y5i8ghL5iZSNsc6ddef6uECMG04MwtfHDaN0o2I0fYY 1GzTM5lGoSot+g5rfNgnQbGcplhHZlWQ6jPxQFNH6ITBUVFM5tn2OsJg277wijo1xI5gtmmPIXZa b3lhLRaMU6ZFuMFDtTX6tWkAy02/bmrgIixf8pgOlBe3TaJj6ulU151GIc3oeR4AoTDYnwyz/Nfi bhPXdXUaELzUdmRYWgRy2ADriKhEwSk6B0a/yXf8gJ9bi8ZwDnNOvbsrbFE/KYX8ziomE63ztlE9 VUwq9qLve0XfR4BOj+u0J+BO25jP5AuA/5fyC9zxsTf3bDhJ1qqD1XeNJCH6ko/kB5m7qIcp5wJZ nwgB8CXPScifsrWUQ9U9Uylte0FEBUqarxT7lNSudMmeSRmaRqxHXlzFKiefaCnZ8+ww/pDvlG1K F79jfy1GNdmJ9OSUCWoBn1iY9RYsk9WyIpr5VAbKB8o9C/sP7xDYBpJL8WIp6mwsvQuNKHSJCD+0 PGAiZZbvWArfBXVxMm9zLjpQ20A2gtwKSu8KY9G7HN8dPVdTn1rEb8oNIZw4imN0om6xHgHIbSve E6b92Wv2h+JlDTe5z96m6BEgPXKs5mKRHH8sClW+swnS5GANxW+qLg6ULapLEDiHpmgHOC1DxWLL Saf9gImsj0y1HNMRQXRLmSK6EGG8ZicbBOOGQUBzvkw8RkYRA9wcVMSAOFaxNe3QZYCSbHpuAJ+B nh7zn5dOZ+Q3wWcESVZnPhA/DGDwnP74t+45uOt/YzK7nbJE72NFikLL4j9luT97I6/owQYYWRw/ +QifABmwHGpE6haKBy1mEYTYIGQw6K7Qz0jOS7bnY08Wa2ZDtHTqD+0I69KXC1UXGrG0KkOtsnzR Ykie9aQcIrHiaMduUzU3Wr4i2i00rLmMmPNKJWlzuAxJUrdM9rFT0ZZMQm+QeSxqwPJizJJZSjdl PlsHHzPg6jFrh7DQYwZcwfg7A095mRp/5xis8V90bYtSZ3My/EZptdiKXapm4QX1Rp+fU3+8mZCB l4M41FLWzR+WzxL5xHdMTLVb4GFaGBWNtoZU2sI2SC/CbO866c4ysHySZxnlSCgemIV175b21ANm LjUUtRwRlcf0Y7Z07ZP2G0cuPaYD235R2OczwmSY/aEI08Z+CXmKYUd2As3xIkhjlo2ej/P8tucL ruspH/Y7tejNHLkKhha92QlNmkWrVW/IC+uOiszhuCv3ijtKRxyWndQ8644+pz7/Tn4BA17w9w/u NxCmnCT51JKZn5KuhG+4oxfoh9N4rjEtvy6Hv8TgpcescTXkrpSwCsGnLCfAEYDOeMhaiKAs7p0d 0aifttqSqtA0OE9iKCs0z0yk5PAdS+G7v3k8ReHkdySNH1DVmcjmrtTnpJiF/QOiCLniE4mwtfPJ VktWMMpgKeMTSSIRCs34khSSd07kCwWnbAQdg35o/QSVhEShUKMWxVNuoWpb7Pa59HWpcvjWDFD6 8XQZFlcMT9R0bXxCd0HWLvbbv3vZs1A6FfIgPOxotWZq7PTZG+noJ5idPUgxXhR/1sZ3/I7zr0y0 gmvLpCHdJK+QIZoRoSfdhdeICJ0hQb7HMgQIPaYo8IpDddps2fAp/Qy7VzVo0aEGdmJxSKFrNqld 5Cp1neLBD/7ygEpgISdWMBggNzsO9b4fU9vufGp6LAnP52o2irthDBXjBqBrGB+12GjF5DrPZHuD or5oHNlT/CAOeMXgU63Z0VZFolGVnMSSzMn+ZRbWwJG1JYJP/NyafZZiR2HB/LhmsmjmpCQy8XOR b8yz2ELJNH7hNCK4FH7Yem93wg9ApH1qwrtMkb1BRiT2hlWrQFj5MpIts48aZ2Mupz3rUiAboZj4 kn303DoSarFD4qxLLyw986EQNw4NoQeld2N/ypN9R3Hgz/twccnaPcqaFU4qES0qxZ86kQpeoSsA rcTSPtsY8Gegd33a8KVQBSFnJbZKNenUAFLAJ2alArpGhhkcZqHC2wbwncVtLJoNmKwtei4tAI0v brLzmcP1BmuFz2fYUywgXxWKqZA+y9xtnYYPuKX+agD9jNW6w6XbpGcupPS+ZDk7Z5Hlk84NUNnZ RX5P8aKxY2n6IR7vZ8NarNKqRqzitd3xFsQKGywfu2QtzjjGhtX1qcdWh9un3Cx0jvED2i3tbidE IZBGWaCcWLTAd/yeWWguKIrUcOo7vXdq4cISRoogS7EQIkipk1lrUTIGHYteX/cFwdg4sznlzm+Z bhtJ0tOBphxu4FAz+WAZ8HcUA9hDKkmJzcLv2CzOUSoQJlv00TIZn9xRMzvENS/wKP265E3tJJqS ddTHDXYyAuJKNp8/avKZ/KdUsm+sVJLvjEiwi6wYU8RZGHvGlsIPWNjJyAnKzOy8BW6V1fa+IKwq O7XYi1LCZOzg1isReizUpXxbf0AmUCHYerqT0OyF8SO/o3zzO6vnVsm8sBcaLmPZpIml2cRgbdJp AiZa7WSPWOhkByW2QydmkfWybGYF+Td0ZSZgaSvEZZoOAGGjK38JRcTxP6dLrWfuXEPV7Df7Q/6R m9swMh3HsRfYmSxzasFf0ILzdexIVxJFjj8UR+vf+CHfUYkpxnzHWCrbQXoYBaX2WLm3km7bb4NQ Sq/+kkmWjHWrEwartkaSyFLYikVlCr6quEG2M8+TkrkznFwz4mAqL0sZsaxstHXDiDo4me6Mg7Kw fOQRm1loGS3DOW1K3uYOA6cg6eTtTXH97IFF17G9gqbG7H0nx1EpD96aPpHeaXX2/k4jhK2tuNt8 i7KD45iqNueoC4Rln4uRwpjXaimfqJcMiFnXY+0QBcqq9ecsm5bDCWTYIsAvrHjSHpzxIUArxEyC HZ1/etc/MQs3UpEmJN5qJJTha3u013eeYe+IrMyFoHqGLw2Npn4Rrb4NoD6CzBHR+rrD4XvZZEIu rDxM/YTbesmuU//gf8MkIUXBeh8rNOw8lsOODR84L2ldcv60DckPPisduFlZpQ1k7aTFwrMPIHkS 2fK6EleL8Bv6QD7ZzLNRbgr1pmEssoxssT1gibbUcidg4JxTHnYZci5oxvKGZ2es070kKnRL5wKI MfImB4IlpzrK8QUYsnUdEFk4vkB84MLxBfJFc8FO9flOcSHiyvkFM8d6jc51HY5GEwdfXNpzptWc Se4Cj5d26zwh5QAIzbkZu7LbRblqK4WWW/koXfqSxvX/Qe5np8yw6RwNUcEojyG25ySQVXBpDt/x AyvcM3aK2bdTLRRn4heqKROVbFLBVOaxo+uU3rAUkyaAP/ycOZnItpBQsos1sIH0VssKtyQMM2yk YrzfFTUjNmUP0CcVhgxfBCP/Bxo2sjq0x3Wf5SbZEXrRGVTywY43aMXAuOOVom3k+JqxD3zIwI7g A5t6zZD7eRVmVqGzAk25ZkkUHmZJAUyAQTM9WmDahrUuv4t7nFR8rlnrvsPhMhhatA2On8T/vBEe zzh8bMVa44uq0ozncNrMGQfV/ELWupOTRnLO+0DvUiAp3dZLsjN5ngw7w1oOQhB+xw+sFaSNCUbN BaH4xJyUCBoXJoYPHM5dEr8ApxaB0BWsEa2VCNUto7UtkdoOADYI2mJepSmBB6SrlgzSfFZpolTk VrSs4heei9HCiIU98Rlt2EuXHFYh8u3EsdHQkZnUy0mlFBeG7dgpkZVCwqKh/EQISOj7U2IAi82z YFYdwZImb7Ndlr53nYxJ9rCdzGJbyR3+sK06AcCsBMh8SQDKd/QRlkn8gP1Bw0i9YTfz3a6lvNnW cjfyUmyLQwKaCwb9cu5JN54zsC2OOh9rg2xvPxVoSwFzwwGtnFLU5hyVDmOpJoW6sWJ2vCdUTXxB FWT/W12ZaFdUaXYdVCMox6aji+fEbzFF1EO7rgWkx6lsAwYZl0GP5RI/l+G1kGX36dItzqRv23PZ keNLNm8aEADPZgGBTDa4PTtorh5H1aG9XY1tL+mgCqL3C7ppIIxqqG7eA7fMiJkqT8/l6poBpwNi xmLCCJyOl9Hzs+K3xC1XB2s56XvMBCwfQZ/gSOiIqFU0znwiYKGqBTPs1jAGO+pgPE0tv1Nt5BcO 1ASMgTwL9vTOQ5fa3QWBSyE68ihDa2Cn2AAbqGHi4sgxOHIHzsgjfkBOv+v5vsJwNxaeMtwd/b/F cBad8jus9DN9Ekaj+VvjVnHDDQNINyiQoPuuXmALLAPo/2np10CWG0CSnSxGfc8r8SeYBf5cfoH0 PpVfxN8Wa7MrPFipk+vAZybyc9uFTAzEplFHNouSwxVP9IiLoUiWwu84d28HgZaWqNQLipdp/a6Z J/WGOIWmg1UEkMFZsDgJmdYRZ4yuDfvqAf4sHEb6Ngz7KqDbscsM0nF0RQG0ohbMR7pyRuXvOeXu hZU7olVaF4pYMCsw2cGQ2nEdbRR7njWrIbYyTSLt8aYQpwXpuLdZxjLFrq0vZUee55llbZb+kvlk llUoNtZlCZvIaTw4EucH1DmWEnTV+bep7XYdyl6x/cCO4zuWsiIWzgEvblilFPA7Ekgi2FprU9jh 3Ny++J310cxCOq3ZCTW4Zl6VyGACLSdYNKn+EsuCMNsGqhfEbNkI7fY8aoQqnNtcXyT2hEHJiBXR HqKtH3SME+tw1HKwVsEI/XInHeOg/hNOtF3Sh/WABjluxYUdzT5lb9i+4ZIMZjktdtG9LQEOIBq7 C2Kq6w2fjGpiSPU5TSlV4jNa1JdM/hi/XvQE8DruxIMbqK9UfrJgYljINKsyQcecklD/mJOEfCIE 2GBNGlRiJ7Bq9xOWwl+JhDgIzlpWIiGOLIrCdiRkAcGTNNZAT0HmsOF8x4ZbiEyzR8theWvdDk0G e4E1sEUknkUTC1nhtisXSdnt0e7dozJanPaCq+YaDC9a3Bg3DGF0vA575IsGAcvJ4PGXG0W3lwo7 BrLuuoPikdPsZytlAYo6g88s1jWwSyk7zEKBUnz0SpQn4PNiG5/njQacoNuVkrolTzXeGkYKsFXU VPDD5DoTKcCcq+JTNB8Lrm/Jru4Ww/Wp5wZRol4c347+fXi2EC66N52AAHDZ4x46IYcZG0RwRL8b Py+7tadFHq1cYdZ2ZY2FfudGVx5kBgOfstex+7+uml3cFGiWGSScUTqNjQFK4QYJzMtMzNuNsTEt fl3MvR2WAPoZG0guulz3Tsvn9tCDOfO20iWWdvnwBM8sdsCS2s1wMdbJXzlVKfIHa2JwcHTOeSmP oQccyjvADHMGmMfIGWtnk7MqnTniIzfI1hgIZF168EdxUcP0xAv6Rhp/Ord3za4IvmNO+g7rZWCu BK3y3fTHgbtp4voHHwqhiHFxIQ7RlnPbwYORJuuo1RnzJd0sn9Rn0gjb0/1IXIuagb0r//NuaNSt nvC66jWAYBVuzEEIak9fNobQeK1eMnII/N7J/fDdYge5wniF10sQIf1EUQhIKh2/XDyhvf/BJVuB lTvnf6+z0m3KqHFahrIyY6HLopoue1lV1D/j0rkazajKL/302/ufw3FsXR/3+fuz65ufxfub3UEm I5au9bUQ3GDdUomDPLG6BJeL4rnGcVE9INGb8nM3Kxi/lGtxlwuCQSjw4UU+PPUoBREr/u2LCfcp bhIOoyiuEeu7iwF/yHW232oKrlvyKW9KdwOenBkvh211OMUHSVjgIOfqJ5l8QZpSvCn/E2sa/+z5 OLV1q62CS5IGydaE3vPHJRQh4Y0LzskeK8knT2BszI8EW4CQIXyVPq3hBYoeoAhXR0lbWuzhR4On KW9whh7cNnxBzNXjEm/cEyYNRn2tbPJiCjiH+6swVClfhzTkYprm2kqJ3xWD7P+T5fZCg9YoJ6jj jPyEKmz1x/mfcvqZb4s+4xrCHlvPmropBk0DRzpcnTNCykJah51qtWuNlp2kkAKUxVyRKk3Bqe7M NU+J38U2Cw2+RnCL/ItUaU8o7fiOfRPbE9M0F0piLk2JeV472WvKf+7QS1xtVkGqRghE+PONXE4m CE40FPC1wiKTHjMEXYXDqf2TzPaKoL62z4V9a5+Yd8RJwxf8Q2e79yNu0egvOA0lVOquWEMOlAbi 9Al1NXIQcHh+g2fsaAdVMQ1mBhfxaon+ifUV8r281fq3npi313ZKXfhWuVCEmoVBjiz5gxSatOSl V8kFo5pM4sE2qdDgbi8YHsyBiKELoqsqFoULAjARrm0hmQvOekosCeo6MSFPYTC0hWlrYppfHN71 NSancHUeHJhEa2qMps+dW2+Go6GxRlFdmFp/NXpODarLgGUgkCP33yk8hlJxgVqNvYUEm1hQKhn5 o/dKw4a++rp8+P3L8t+++PHHr34GntRRmtj4UOiVOui5Yx0teq67DDVqdFXhkgZW9d/uVAOW6rGG cnyvqd5DcKf7FU6UfIkwqTbpyiIdZfcRiGHEjhZnaIgYOig8jUc+bHD4Q2BDB+XpxPS40rBNRp93 oAdZddRh7bG7X2eASuDYQejnJAXyLIf5y2qyATG9RgRM0vQ7eNpOFmqlab6sGwEEYBGMQNEBtAgw 8o9ooDzCeNUC/tL2agYom0MckkdK0E8Kix+C8mMJRy8j6YgfNCU1B5qm3hx+GcgJK6YS/44lVB1W UEUYAEftk/Sr1QSY8pgH5vzcdwY64EbxocIKoAhoMCM+nrGiT22YPr8uou3zaQ5dBeigadH+atkx hQSgqGCkmXQ9IbX2bH00hZFrETUoZyPZmpKiBk3TXCiJ/aYp4C1TbkYNmCmCGNBHe3dO1CBvvG/H PZkRNYwjTGWCGvTZowZ94peTvGec20LAcMZ6V8EmAS+ccfynK1doKcITvTEwpJgMAZfBa4c059W1 QP+Airz3L6TOkBb+IDQI5BIaAGn6poZKhAtELBcHPhx4iWnhJepbhQbwLnpxdwINigHA5CybhlNo MBMgdDLVbl2AomhsCVAUlyUB8loVS9oyBZGmqMIzUxDbF7UBN1OwzW+4ayy4cCxkauV2r4AMoKQ9 RjIXBOnM0s59yABnH2IFDW8ZVEjgnfc0angzMmAdd0QGuTUsIgO0/gZkoEDMgy7IbRZIgtHEnbp6 qWMESVKKQ0cIKRG7/Ob7H7794qefvvoSh/sratmsA751HLEYYWAlM36HShI2ZJYNX36W1VZ7yv5U GoApWSV+E0slw4NoDbKjLwJsYbwaRDhah50KYqkboi8CEjTi4qIvhQYkBI0tjGys+WLUBQMWH2OZ RV2Ah26JusC07466iARMgiazBBgfLIm6FnVJozQrqAmD50FmpiNq0pTUVDKtiIaxxjLzCqG/JAUR ogErJFMEVDNtlistaf6doCOEUwx0EksOZBuRUy8I8jycNYCkzyAgeAKmCQQIfiakBQykRWsCiGP9 CQgKaZrLUeKonKfE7wqwxPMl9RfKvUDUoFwPpIeU2ByUxd6a55qn3IyezgPDIIRQ4TmJvoQ0B6bO GAtJsMM/nHGKCf4BWJjnzSfmlWueiKVqbPYzYKqoK0iXA3XuL4Io93cCoNyzg0ShBPckRRMg4U+E SRA0kbTwB1+eSb4DZcijbQvgKTTdISh9Uhilzx5CrTxloSo3nAu4vRpwcY7T0yBt+yQrHU5QiqJk 4eKifMmSMQ6UUWK2+tWCrUgtw5qtkJJCVFVbmOpJTLMBl96ZaYS7A67CUr4zNkY9MuIiy0yBTO8a cWEdMz//dBGX3BoSQBEjLoio3oCrNlFC4mpvQAnCKCgpMHTVVfBTcPQ3zc84hEBU4BBCmLIQhBCA Yeb8jCIFQJYpdrgVKSCw8RbPz8DVnhAlkgkpan9ISbQ/pAW97s+YZsVsmibAXWPJA9ZgpEAhpGku 1MFc85RoNAqcGQv0jFkgIYHTM3KlAM5RxWQMvLibNOpx5oyEyL3R4lNi/HyKRLw0usI8wdSGMpMU 1hxdPS4z8Gkx3KIpMUoeUtLvtK2J6SPbUBTnigJng6cPKWlTtJdmuaL9T74TicuflRGz6AIZ8LGC GNUXSwAjhDzcO+f4ZYVRhAV11V7Q5XyDv+Uv+HT+Be1O3kPVAw6oZf4wDarUdYPZewRUSveXxwGF +zvFAZLLOfdaS+CTDOT0Df6OqeEv58whMY4mRlFCawIQcC11IMD95enAN+BNSAXOkNG/pGU5fVkW E2UMd8aM6EiwWtOi9sxlJRHfVSkAFSoZKIoarSnQkNWU4PNDnqj1saSohBOtj/octdfdiePaF9tS yD05TJu4fDnnXaLWweUnoZTyj8mh6BpKKTbH3Zy66UcgGUyzQ7R//cpGUsJC+rIuHjPHYqooYvTg yRw+K7iKKBb9fdW+tf4eYf+n8/fu7FC/RGGXv7/Ad1QA3rrWAg5/mgRThdsIe9FUjR8gBe5IDjjR 7yTTtKgbggMiqB2OC9ehP59CtKPDqia7/EKi6QHqpJ9OV2LQQcKpSmMwJRE9vaZEnYezY66o8wP2 aOA4qOCKURImweVMrlTpNS35jrnmKfG7ou+A8C9Yepe6epyLMMiC2ujqsQ4CkzlhJUavz6nd07TU 4WuaGlpcJ8GykxRSEE10pGqea54SvwP32ObU9Cn/os9XHkcLrSmxPbEnNFfsQU2JeW6OCtR1K6uj 6Hfxd+rz5Z337DKdF0IBcLwSD+KbvvHTKS41pIX3TT26MjEAqeFjJz6/wYScr1v+ek2/Kn+nPl+e vRfXEviEstXnSz0xVf4qaknT90Kz+nxtTfT50lLv0+Uv9fmaChQyeb9z+gQX72CwPJw7mJkoQHNh QYdS2TKEBXBmLgg5KdHpU+yAkaOqqSgmajsxAFHMoyKHtBgCDMqQlLRgOMgZdE7kjHJrOvHSwwx2 2FuVDRayJgLkVqT2DDneRguPWpGxWsfTwYW1VkxrWMYLx827iMkfKzEhAs4S5BSmRJ5g3kUryelT rNTVaZFNbKnzLnvK/s333/30q788fPDV11/8/OYn7ErJqqrHNGotccE9VWU2AzteT7VMTe0p+/kP 33zxBuu4c/gktg6nc8F9s6OfsA+wmBKHnUB29pRdYx16FuEwfeNlJ2dyuY5xDm7m2ceUv2GrgBK+ GYp7ogm7uhnGJ5usqzGRFPBr1mwdwkcnRAsCtAYssSnwU7j0V+4Fw+Qnp/QkSS49TbC84A37IVJ2 R+FEamvMswaYPXl8g7cIZBtUjpSI4SVD/By0L8/V9f7wrwSWMyF1ykxSTwqAWgEiy41+IT4GtXZn cKQ+WdPmuTSlEHMw+06OuhQmp6C8wWItuY8thN8wsz1iiUQIwPHZwBLNk2JyTYvunkUnCb5+KUqn SnqlKScl/Y7tc3FAvzgaxoPciyiLDI7wiQkpxprkQSe4Y9sSFBY+2heBE1EjCsaK9/TvFI03eOfx dQMLG9E4rsqLaHsYiMYllbmT97ihVbRDFljXcuqcjcC1MKyeDvlL0bj8naJxefZIW0vgE5GzRNik npjq0bikKRoX6hSNa2siGpeWejQufyka11Tg+sn73Wi8BaJF7PHbJKSrapDC0B1iksRh16RiQbY0 ds1PosYH2VI9jTIbU5Rko/G+ZbEVUHBNmkTesF4Uh2onk21PE3nDSXEtrujZDL0Vj1vejPC/1lGY 8N4U6t68vFlrmEGXaQ2/OJiGWcQyVrL7XmCalcy4ERB7woYIWfLA9I6yHwumd1SVC+uggx5M7yj7 NjC9o4Jc4gOY3lH2fjC9o/BcwgOY3lH24WAat8QGMH3BdJ9fEixIWBSjvrSDTHbJf+vb9NzyN+ST XQRnlIbloThz1D/CgWbBallxP8pyQTePCXjBhIIJb+RQ0052h+MME9wTjTArknAFADYD6kdIsKVY QI3xR157WllKDcSIGUTwQ6COTXhTyBFyfdrGFot1k0+AXiafrOFqXHI5YG0RuKZuliloXoJifa4E SMsphXIDeUDWWA4DfwCQlcS2NG2ea56S+ueqw8AeoaYUWVdYzynCEYlCD1duiM65bX1O0SjTHK7V yWTNFzGylp2keAoAq2ZpCRwinfM85jvlQoQb2LHm2JfMcCvXI/7RlLQ5mjbLlSArzbM32i1YRHBt UWP4GPC1/J3ia3kmMoYeRHzd4nhfjXbL35IHJfEviUXG9x3uwlF83QGlW3wt15d4fC1/eVxbIM4j A62IfuXZY2ctgU8oW/Gz1BNTw19hhltoUnzdsjWxBmmpx9fyl+Jrk8pIvH+/G1/XWJmL3bFgtcpY ITsZnRbNZQWZVIC1h2dSACo1rejXc2ke7PymXkP5qESaErU/lpQo7ar2pxaB7YttQftC2gRnQynd MvM0aI34BMwfLji4fYYb18u57Ux3nOFOq0ig5RQD346yfQUzWDmtIEGXcUUb1ni8rSva5EBwrmir B7dVbL/XL+RLOD7v8/mwY9ugLDlRRy+3c401PFjw/e7CLpcUvb9cnFT7qVj1/uHD4P+LJGl3SM3Z Yee9cbUmVnE5QCOAwD+K5XTeP7TW+/7krcmcxNNkVS31vJMpNBmABr8fUqLmo/3MFTS/w3TcGYtx o5PvEGscBAQlDjykxe801ywF1jimYQ/xBVPaid+XM9URxUx2DXbYRy6zhKEp+pzsGgx5xPbQbIY0 tbY4Jp5lJymegGTXoJwlLzTN8swSEqwQGJDYPmVdQpGyNxjkwPBoyGMnaC5IF7tFU2KevU4/BtUQ KBU1ckvL5O/U6cuzd/oDBhXR6Q+IrarTx98Mqkkqcyfvx3PYKihjwYnTR5CYdctfGlSTv1OnL8/e jWsJfELZ6vSlnpgqfxW1pOl7oU6dvrYmOn1pqXf68pc6fU0Vc2Pf73X62F6MqyFxgHJ0+nDZ1KAo LOhQr2c5wpLGkjdEY0lYJtbAAW4uHA0lRe1UmmKKUp7qMNMWLMSV7zxn0DlRs5Rb0ynuTvYmitEJ cAHLLWETMCJZgQtZc9xyeVcPDDbztQshnFv3Fq7WMfXnNwOG7BoWEUPdzxCDLJyqZK+8+KOqAaao xTE1SIHtRTec9fCBsJLcjdi5xTAd9MYhMLeJ1m48jaVK0Ho3092O7lv+uB2GEAy/wxCnGrpTt3AM lJyzhavxkvNT8SSHhvXhHY9VxmbEZ+3C6crXW5XKUuZd3Vg6hiknGAmJEsRWlaZV022qOOtTJzAl 7HEnwmBkxI/tISw5UON+hGGqDKuUd9GVRMDuSBeAHq5u2UUYDkW9f09ecICl+KE9PYlj7e5OWI8w SgPntouwI2RfdsM23U4Zw8m0B3AMC7DH876uPEL4exwZgethfbAz14wl6zDuppW9uy9ett/tsK84 9Pr+XYkzSVrZu72HMDix+xOGlQQ4c1aC1Pke6RAZw4KGrpJz7XYQdoi5kK073U4Zw/Gf9+9KHBpR jW8lYVgTJjdD7OnKI3ylrNsZO4wa9xB2BOrpAaCxl3OfVh5DGFYwjThOYg/HDrFjWCc5YGpiF2GH OHHsphp6xPH3cOwQc4HRLADsPsIO6UpZdygnSe/h2CEuCac/tJh12EXYIS4Jsel2lB1VO3wlbpK4 v0sCPbg+YR9hx3SlOzJlH7TG2dL35ximDTrMWe7qykM4hokQBP32GVgciX4Ax3A+9WUnYYfYMRzd VGPz966uPGSUhNOI6w7HRuwxF0fIWAz6wQU04TKBtyA8Bl+J027gknYQdoSB7bBu/4x/uwg7pisx r4bLBHYRdoRWygztBVN7uwjDrUR3t2Od+G4cnbuLsEM4hiOsBtiLXYQdAa07uCR3ytgerTzCwHa4 nBMLA/fJ2CFaiSMdhjP2Dezh2BFOvIOvxFW2+zh2RIhADmPG3QvwlTss/xHDtw4nVF9wqtcuwo4I deIqSswC4mbaPRw7RPgxM1LhnrFdhB2C+TEzggtK3j6t7LGCFSd87CPsiK7ssWlwxAV9u7ryCMvf 4wJdRBT3EXaEViIChePAZM/nDjt2BLqQNa1yd+ceug4RMazBxnEpbx8c6+WOglF2GuzoSVxfdncA 2zdYtlVhUfUewg6ZeW6xHWKnp8QNb/dnGHYV1j0OnN/DsEOi/LJdZGz2KeUhnhITNgOOm9vFsUPs vmxzbcZ9sn+IjGFbbCNLMvfI2CExa6xhbnC8+y7CjhhV9ljO1spC7z0cO8Qj4b40nN+1j7BDuhJ7 INsRp+Xt4VhWdAyr67Gb3i8iDMvtXn71w+uv/vbTz1+8KX74BgvisNawQwRMFmFi1hQHL+McJaxP mUTr3vvo27r84HvsHMxbffKoNYsQISyD5/btzcV9RwiOrCo+uynIt40uRFUHmeV+2+iSoKosPXnb 6JKYavP20SWn4teQ97eNXxLqbV1QKVsfj0AxEum9jJ0MLbLpOsROYHMzzv3fpY+HhLowJ4p7WnbR dYTfc2FenLe/px+PQDByQ95w2Sf3We44XdMf3PH7P+Ku4B+d+71ydbkEecdalinky/0RGBk31uK+ rn38wgXTdx8fdth02w5u4JptJw6JiWNXf1e5CG82XUcMWyXyfK7dtEs2XYfYe5xcce7dzF42XbgZ /u7yhTshBabusl/J9Vd5OPoGO+Gup6qwEW+HnTgkVCn3Srm1Ofn26wi/LcvxceitTJ5ly9chcTdc T4CDVnb57UP6Ua4DbffJ1xH2SyK7FU7+3NOPR/jHHkvxcTbkLrqOwF89VuJjemoXjv7yCLuKhfgj Noa/df2ISArO4NlF1xH4Xk7qvfhVCdn26xC72mJlYbWvH48JNrt9trv84yF2ArHmod3Hr2+P0Eec fwrzJaHmbPk6xA8hoDs2LqCbTdchfgirHXG8/y6/fcrpx5vDudhgjks10v6L4dylALAc+jTiwgMM noCMLu5U+viFAa5yX94oV3qETevYqofL0s8pcC2TAa67O2dt0zo+HUe5dAOTxzKH4Dat2/Wr/u4c t2ld7s7Zu2m9fHYpH2ab1otJWHt3q2bn6SVb8TEMxdlqoVE8/kCuBcdRzfKvfIVjPuYb82GlePXv //zv/8vJh8v54atpEH6V2huC8D3uxuxqXFtk+6DYog998LE/MABmUk4DwJK3Z6M/MKBzZwM8ww8g jZwp8PU7hTzBAckP7NczRKb0wAGYf0mFlspJAywNPlRKY6H8EAPPZ+fiAfEgKRSwRH7w7q/lq9+X O1hEMS12na0QxLTCPl4sBF8Q08kpBGARm0E2kHDLKbbbtS00/zswjKcvgDWWCwhXyDsmwuhaZggv EZmSH1b7AwoDZ8lEshsLaOQ7fs537iiIqnx4gZc1fvX5OZ6hQr91ycUDDFcOy53pmlqGOBNV/vAN 7MLSTBRuucdG6R6r9ZTTa4ZIDuQcMXsVDBEueqnP7Ti7uNMfeHnl+Azt4gFHk8uZHL/U8Rn9arNS A5sdQaQpMq3CSaCpKdpU9YdrpmiV3EfZIkPvJoFQNAqw/aH8x0SR2mLBUMgxCziMfiJG4s4nZ99k iRGO1WwxUyFWdcS9xe6gvAVTuv8MFmcTxOwtubOZg0gb5VTR6YZvVOHO/zO6uDgrLEt5EeT1TRF9 WFPEtDIX8tbKbhCBsKWlwz1oOPdNb2xZ4GFwl9kiIHbxJQwiWEjLSxNIm0n/g8Vf4n8oOkyk/V60 rurUaMdpZfmhtf8slDnlvB24T5cl+DaEysU6M+c/8STmmKVZC8482G4hBIdCCymUH0RPKa1nlmwv ep+uxd2QwMsbNjbtWkTehB2LHcbu4zv6ukWvSE6TKexF5rT95TuzmHjHNcYJU22foFDjIHGWLM97 cie6PLmpkVk1wc7rxiblJiVm+8cBNiI85txq/3P0EFSKOclbMvwLD2Yo08QtwBDCN0vEn32iwo6P /KOiEZe3mMJHlscf0si62Lnvmrpe4slpv0NFzLKm/aYb4zlS6934KHuHyWRFPLih6oq9I3dWjJID 09EopXCSCrBolJhIhbNaET5whf3VM3WxH600fIacYr7IeAhV4CrGYMnpXOtcfYwfloP/ANi7p1YO slF5TJZR5ilW+pKP7Cuy1clqoaZjq1c+9yL7OzJSFeIPfAZHxTx+AD0TPlt1JUH8YR+qR0HW0Bd2 kdd6XzxKwhG+Gbpx42S61FAtjp6splLRf/Ymhk6ArCS3rS/lO5ZCVk2ttxNwvgvmIj0IzxJhwcJH 6A1YtqCXzpKS7yRQxYLWCtUf0QtyQRrOYsDNUbt6YSaYR9AaMSCuXmxxmuj6YCyVGPZZxs8LKsu2 pUtRmHaaHX870SlU5zAFPR9VU4zZ2QGopOEO2gc5X3Ef7JtKbiS4CKN3CqRaDTDn2B7EmcByzcDC QGgeMFEmkyEZzp19/RNYB62jnjGRwJcSzMLIMmsr2HHsWxZGIkINTq9j4ORYLspxrLje8Kn14G/G crLFW+aNzAzmbSHSpJ0YzZt0zcyOJKLOClMrGXSKpYSu0QqPYH8vK+4x7112+ex/eLYS17+TS8XM PI4/zhxJ3epSM7ry5P0etYU/tD2MZy5qki2aWazNpOZSOt/1qr5YmFXZz0DSCvI8BO1gkQnWHmei HbYn4+cbMACje1WzG5EnB63FpmJ+IhxErF6hJpHoK+/nSCt78I0naxVpihFY91f+5GENWhQa3+YH rIkGIqK3I4xAxCKI6GGhVaYNZrfQz2xZ1q+8DaaUs6lsuHVoi/iC7Kez+wcKQyCI9bF2FmYdIbPY 6FA078Law4KlLUJ9uMX0yQdpW/K2B9k7cBGMmUNZCz4r6qQ1amSq68sQ42M/v6CNygeiVt1Q6G4l mA2nCwlsb86O9AjHVz32nmlPEc/ZeQQ7pTmBdw/f/QfajCWaa1Oaq5FG0Osj1lg4nc4rb83A4gxB F4bHDetYSbo8rzwhEEFkHRizx6z4WM2MQNADGSci1r9S+6wJoJqzv6nfhFMBsDoDz0Q7gKXY0cpS FpiFRcMTJyKBSbYQfpT7ObDpLEyXyUbyDqDyEdMcHQZoF0z+r4dX7jzRsd2mXZO8etS8timR8c5P 2xfXpu3LclPGV4i9JaaC6VGs5LvgbgffAXkjg+cwN4h+UrQo0ZT2GaBwUkg3oS/5yAKoIOvmjlUF NE8AcTWU5YEb6EskOY0VPiEj1VLgxgRs4cbelNV53zTUQFdM/eXohFyxLpWjyam9cOMY65gnPF6w N4VO3/DDhSzB9/PdYodxnuRfkIbZNJfFIcHbuGkqC+4CSk/DyxFWXO86v0TAGKHivevTkj1seofN qmmPrcxM3kNOGtwFjyXHWQENdoL9ob5ZJbS+hpiQ3yn8/pRg4TP+fui1mUr9PlNVuZj8ayBCqPzH eIvgEj9hwezrRTVmR57wHZB7aIHzc0rQohdj1mmDNDYVxMJG/1d66lG+CWPjS+PXsuHC5isTKmzv 3z2fqNHsqjC96iSdWsAP2I1WI/mOoWGyiYURD/zrnSKwwg5Hn44VcuoP9mkNZbeLFexBGrc43DJD OMcKtpMfWKRjMQr5ww9gIpPG3xujYCA+VN1jRhekPnhKTLXEJWxsNpnwlwdIEBZcqZKyxWrcp4A9 Tg4/Xbd3OLfr3OAoSdzRsaPllHIS/MorQmiyjwTQMLHJf3nHt/Vd/EQjQWYtejwW7pQmTH6xtOiO EtnI8PqPGR902NHVyKW3WeZ8N3wRrjioMF1NQMtLM0MDwR+yg6xiTv6Q/4QYU+PseoEdR/azBn5O GaVXL+EaQKBK6kv0ovcUu/lf/rH4rty1oFLHZxj5jwOUKYv/JN/+TCSUTLRG+lu0NNFYa7PJDavj dmTGGj8Bh3C38wNd6588wyxTWTF/WIwOLJk1BA+cEWV/892a9uzrk1uGFIqEW6zOAbb65WPK5MiK H3Kyu2hkVKDnplcg0IKZC1FQtdL8kj0DNTuQ+3JhOg75yBuHkEX2548ipoilkjlUEAZo2bQr0iZ2 gTmtspAlQC/Xhg6slp9v13d/KBTCuC3O3sCx7OsBi3SYp0D3U+EoFleoZH3oNd/ZgeJhFXmrPc1G 3k6mbQ8FW+2MO7lJlaAbsB987mn7nZg8kPyCpGtTPsazWy7iW4R+OVC2ca4ObpjMDKGrMpID/weE x9A25QnvhPyFSPUTwqlgGBFrwf0fjwGSVB/2GNfG0TmzU9nFbDUDDdadxcZLV9Jj2GlrZR7dIfNY LWSFTExJKx74HbPwnS2FvF/Ye7HC+xucUi87q3BGKO5o9rzfZRZVbdGKuwu5LNvHRav9HkpXJ4uf kIGI3GOnaL2HLETCiQUphBaTQF4Sbt558NYiLId16BsB5tRek1Ar2EHZnOF77T0XfSNlnx+sDHXd d9bIfuCsakCCL2hkWRyVh9xLFSvEXkkpVf90QDAgekCsZrhwj9/1uAibZH9eeSdCJtKMsUnMSTPG 8YeaIzuFSc7wC9cJhW5fYqKVQFbBvtBCrY0LQx3nTD+RnsFY/Tl+MbixkN1SgxoTuc4YeN5gz2In yJEKCN7n2TM7sUTWUlqJsxbXQpJ7i07kdGhzMXl+kZNTsqLr7Hv7M0G1lIGttSVWZckLiof1ueQv l1ZYmWMpxFqk6TMqPF9SLinPLpAR5jwUHdLGUCHYh1agrT5sjRJJ4qEi22CsjrMQskbqyp8Pvdo9 9z/Kit+Re0z+tX/rkGmhIWqNo9ETkdFkGzvDDjGoARqUYnTDfjjrqOM0vsGwusXi20eoAOWDTaIM WIfGd8EIulFDlBYZ16nZZCqD1I6XcX/FxG5T7Mk+2n1LDqvku+/hZoFNiVvZX++io0HAYmEknO+m veZsOet7RJywxM63XXPCCv1xq7C/qT1L+imXthPopciR0HnpoMauALbSTdbTimSw8A8cAH5KZbtZ JWXW6MABeoMACK6CyUR8ZIT9IePJMgtPrJyxG6xZYWHKOLA8WIm7TVrhxDOsLevLHa0/YvSARTnd iBvZlKw840WbTeZao0HmBmvhzIT1jdZo8ANgmNALWfNlN6AznFUmNwU0O5trRYotI6SgOWQWKjiN K9sZ3s2mSO/VzoBCGwTD6jE3ILNogthcNiIokutWdt3id1YqLAtZCqWCTGOW/wFzBjzPalmDH44F lP/iAFmJPMR+mnPfZCJ5Emx/rL4Et+p4SF6QXWz2yThSFvYKiXC5VuL4TidAFnx+BATZPj/MZpGc 4PMdAYvquzYOO9KxIISEE9AyHctsbCjIhUpNweTYY2Uc5njBviTbt8ZhDGH+f3L99wEKZW5kc3Ry ZWFtCmVuZG9iago0NCAwIG9iagoxNDI2MAplbmRvYmoKNDIgMCBvYmoKPDwgL1R5cGUgL1BhZ2Ug L1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDQ1IDAgUiAvQ29udGVudHMgNDMgMCBSIC9NZWRpYUJv eApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago0NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+ IC9Gb250IDw8IC9GMS4wIDggMCBSIC9GMy4wIDE3IDAgUiAvRjIuMSAxNiAwIFIgL0Y0LjAgMzcg MCBSID4+IC9YT2JqZWN0Cjw8IC9JbTEgMjYgMCBSID4+ID4+CmVuZG9iago0NyAwIG9iago8PCAv TGVuZ3RoIDQ4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXV2T3baRfeev 4D7tuMqmSPA7+6TITiJHjrTWxCmvkkopIyl2duQPjR0n/z4HwGmQzYvLC/JqRlPzwAEuCTS6T3+g AYI/5v+b/5gPRTPmVdMUXZ03Y110Q97VQzEM+bvX+Z/y7/IHj26q/OomL93fzRWeKYtqrLuy9FVT qW+KumrKIe9NUwzNaLKrt/mvL/Omcs/ycvk2f/CbqijzKr98k1/kH+WX/8g/uwQ1q/Rk59BTtUXb dk3u6MnW6HmRXzz+KP+kyS++w2XML37ypde+9A6XNvz2+qOMt/wlv/w8YRA7mFqVVdF1Y5X3HEQK Uz+5PaZWJaTctnWgJ42pn4JxlckvyMCXnp1vcAGryWNAwZZycNVdWNp3eeV7eIfGILCD/vYJLEvQ gqozRWfGccGgAy3I5lqQKrAogLJVray6FmrZmVP0eK3MnFZCC771wiDuKSHIK51x2UbzUfVdUfb9 Kp3ZwnqcwTfIcp1v/VD0Xb2VbwT49x5+156LuNwi34axaE05WQivkRpwd8m40RSmhLUVixWjJxdB BsCRcT8ExqVzLDiqLM1RgVlF1Vf3hmOmrIuh7Zc2VUvwkGOVZ1XpL8F6ptvL92FnP0fvQ37xs3eF dJqkxSgCJ3ITJbvD5ZuhKSpjlpxcdfnJIYgzvtnOkKjsCtPVXUwXlrqZGhJFnMEpoxZCtG7sirFH rLYWonnd3MafnSFjN/RF1w8JwQ18UxTqDwE2qLTEbYwi6Mbe2h8RVEzWxYYYdG7yI4s68HORQyYh Cpujdddov/Ga8I0HPW/52ZfoB155LSH9fIC3kDRe+DiNog6QWPnSNzYFqIlqFYFNXq7HEKYai6pt +5xiSkHNGa4Z04VV12xMhflFNQo5aaihDBaIYJFc/BY8BTAo2L974VFcvIXyJVi0KDWCKG32EG2T YmYczMYkVhZEP0X0kN3W/KKGaNsRoXm6BiYbhB0GfDJQCL/qoTUeaqsG/JhFWOg11e0GIobD4oyA IqbgeEsBuR/MQC5RWZX5xVz+mZgiqiSbIdLYxaSgdrLIeQlFTW2nKgfFdjPPBfm6Gd5KgtnaF5bE JrsQ4HxtyzCJ/PlvKIICjdwrVIIdBCJBSjxSG8gj2ilNJNvkiNk0+Jdoi3YgxMBT9A3mV3AXc4SU RVk2SErYvMTl1ZHYSZIO4AiyDu7GW0k9GBsD1wZapYlcSz1E1aopi7Yuyzpvx7YoMRlpTDHa5Ex8 dtXBq7e97bYrusYMyNW0QzmUZszHohzHajDW/L+5vVwLchWFGe5PnNOOxThiFnc6zoEZYYjaeUWh GTCq1KsSNYuXT2FabJKDakAtohnQkQC1mQ9+hUatovJWp00ZYuq5vkLVE5XqwMG7tMWqR4VzL8Y6 79K5FUXr+04kdm1Z9FDrBAefTM8OkzM5paYqmrInunc5pYUbYXBAp0Q40EfQJtNCEw0Lr0CDPYdT dkGvQOdCNLIZdhgsvPN0vEV7E4Yvm8H8Tw/bOZbd/HAvek8nnk2FfHLfV3lH+STgBdoeHTUZQ94z fUi5kMvzCCA4V/0c/SEvbOwXmoe1gJAiIGlzsQYf7XoKkceX1nTA5jyjCXmy1UxkGzL8dTUUpkGq SRgdM6sfZDpbm6KqmpTp7LFoUcOWUQ5FRSyHYMdNEjR8frWV77KykpRTtrn/DsEw8pFr41Q5ZYA2 aWXlwF1YhVufD04G0ZhiQJiT5F2pRQkXmQF9RlD/xl4Rez+0GgQ/+UeCHmC3Ea3Y1L/6oqjCQ3sX 7paff8eneNsjquNTVv+BV7ldNEt+Z2d8+jkbf4wr5gr/ZxsDhaD4bDuXTUtqbr0hLLeZqkOesG3y LoHtLtR1ZmI/Ctan4RMKqhoZ6KT1vmPatwSF07DjMPCCXYeBPP0YooGERIyUH+W2FLogToQvkZlg 6QkaA+LYiJ9whSVDNLZF+NtSiUipYxGzavOO3I4p3QexvVgRNLWsrh6ZeIU0/1LQkZk2bxH5iUi2 GQF5mnI+Jn0fsIvKS1fHpe/sDaUvXfi2s2CVfk3TQIOxQNpvaWZgQBLBsiNiNTVmYX0LR62Esxqx JkfQzmFsA28wFe3YFGOTlAdPNRUOQSILL8HsYgLLNlPhGlNgyS4EDYIO6UvMj9gQqRdbIfWPKPGv rY+APyJ8pFp6k9vFswgol82h3gInO524iHr2dZtuWuwBKcsW+QYvqIRQOhk4O4A8AWdoC0wHGeGt AnkjcLwJEOFuA86BA/CNUcIScIiEJTDhz4KrpYB/7+xHJjhZ2A+BjTwthEsrAh/U075kJ7bW7IEJ 9gjVQ5W3lMq9QQnyXnUbnQZ8CNfYdn1R2rh9f3xM6f8ETEwp6W996QYX5G7pLzlXfY1KRCic7n/v S5I1kCtv+s7/+spfWOlKYX7JjtkOu2LHCQmGf/t4ic/pjt4EhJ7a/EWEbpmqVmOPNX4k/tZksMAE DMdLzwomW65RAtc18/VEkbdw/Zss1IKhtMhssoK8e4cesD+J7A3MdkGmFiE7YtP/4yljY3yOiQmO IVDtwl+d/NckIcF/e6GIXWBC1LpBDMn+JGK4khfAsZpZjF00T32404Js1hdKgtwmR4nwj5V4uLyj UcE7tSpT5IQfH+AlqKcDB2nRgmTlC9+7eAhxaeI5WvwMC+Ey2dlF6Uudv/zFP6rpP1BbqxRLTXEo C5hzenNEU1zvUU3x5imTtv/taeKoxHax4//HjzB+bIf3UElC426pT/Odj0+m7xahj2l6bzAzWgHb wgTdDfabAZstUhdFyFp9WTLayUIzOsDW4ZX8DpUOBIVHm25aYCvR0pMZCjLZl6i7okzZjrap1CUi M+iLI4orm3xu3SRHvCqZwK0m60bYKYRWdnZLsP7LD/MH7zBZSXvApllJdeTj/E076GDt57ZCW5Vo Y4E9t+kQsHujHrDbrVUwXA3pt6nF3rkpJs31UHKbuE5kLNT02BRDA5GYJ9/Ffv1NSZhgpTApRURG s2hPxwFsNEDCSZjgYaVWjl/QmF0h0MsW7JcocN1nsu+FlWxNnidtfJDml3STxBCAOKJ4J3kShTJv 0XrBfll5BXbBzusxsUTO6t5JErvVz/2ExuC7NCv4wDFpzd0V6A3uAtOq9/v+RF0jJGn7IW8JxHsz q6qxuWIIy57bdlrkwM2t7rXAFLRFvgtcm1N5Sn21ilH2hLiOd4igj0UnHYJo+id7aSMqrRMEIJvW Rjv05xQl2h9RSWVgKEQXRQXV2NabiOaKHaKk4GPmmI4qpt6pSCLIHlKmoztqsg7ZSKDeR8Sxk3WU Q1B2F0ho1rF3spwzymKmieu7WSKzhFMbDGssKLeN3XVDTN0bTTTYEDHKOueqyzzmoi6tO5j2sYWg wFnZAPL5vFdbS8pU40sj+I23spQie6D4KMwohngLHwggd5TxAbZJtGki+DihpOcH/E2nI6Kw1s5E I5HxYujWmQLxj+yXjZJpWos1J/mb6zCTFAC1g62wJ+3eNSv4ACRwe+m+GrAbse6I10wc/O6NOlg9 xa64SHptW8CmLakWId/y05KkYDRYKAqaSUKOJUJHA3ABHT7BCztkT7S287azC1byFpjEWdTIxx/7 ygkl1lHxAV5o6z9Wjz9BCXfy8geUbAxJPv03ivUs8ehyWK617ILUU3E0jrUT1L8tWek843y4IUsW WCmIP5U+3LHuUJfYZVraqCIZYtvmKPo9ifS0VWlfrhqjkE/MW/35AtJDzlGjhkzVGPrGT1W00aUQ Bbv6RzaqseQgEabuhKIOljRqGEWwMRp7Yu/PH4EokE9806SSCq0QvCVMhudRD6ng3J09RZQsFyWj eedzYFeYCKyHHzvAZ5oe+zxqTASUtBPdPeVDrpExMvlkkfMgjomqx98oCl50QEd91Gw+sUkukU87 cvw13jNHhAa/pPi0GvrfiZbi3fdirM7aEsFInzIh9mkxiWuGzvRPoo/8UasQm9GaxDv5mwN2tng/ gf2uzbOPWHFnvqksa1acEKQCsj9NmV7Y4m98YMuMxqm/TtaRMrapXdCcL/kF7SO7DQTOhzmFYKcc UnRKsr7lrq5gEwwWLDZg6xysn5oihYX5ZsCOAez/SYgJj01JltbXMZX2R5saLShKjygjdggoWkEq hzaGdAhRC6fNPPsjxukONQYIGtIidlY3Q/CwNaeamfjfqGoWye4FUIq/CnL8nA5jsEhemyoX0SXE z+dAKTm4aSyoatnjoc34Irg5h550aOPohLI+56XUSxs3T5NtPZWIrjewknAipok4Ypow+qcKzgjm 5dx5vkFAI02j+DvfGLvVfobqwsfXSAoK6TSYdLIjPYdlZVR1lyrvZtk6iCMRmk5qIllAlecl9Oco 089pOXCYbIx3Up1Zycbw0sa22Ea2fNsN1qdAWNc4Q6fFVvsmGYTJOrEjJJ3MvXtTCOcDuTl3YkhK JPBCDlP2AdROzGsY1ZY2Cp2o1ae4Qkfz3BYRS8o0yFjJBYiAbRdGaC0gyAhcjkFDJ4DaAXCTfQ/H WySew2SQpSlbpOsbyirBNd8Ndhr7VmJ0z8UiXZNMTiSSSnc3WG+p29Rl8Oi7gTXsO7Ik6eLcoXr2 VVIcuITzuRS921TvC+uIsPKlUUyzxtkgfyOY1yIY3qnXUL60XZhs/iaS5Q216Kn7NZzAQJ1kX1GN +d67JOj57VnZahxwDAYgILy9N6piBuwclLXoVVlv05Wda+MN3vzq8VZxQqh4LMp/bhGA7c8UfTCI ToMCEOaxP6HjgaVecZsBS0+UQztoNbuQaJxd0iJr7NGSsy+WmFUizrm5jyGW9iNRlyH98nm6KqdR 4SgR/kaCSZNum/TyTlIY+OY4xceprFRInbNhK8fXHqxVmDemSZoCoUQ13GHiane2HQL+ZJBtA/3O ZGtTjgXmJNHtxIv5yDHQU3YEqUbe0uq5AEhDhjJnpba3a3JlyoTPMSLmA2uGXYfCfFy7Bx2FUSdI J0dEvEfBHJ1D8wGtppLQIhVE5TxtHFLKHBmVl82QNDKtgPWB/yOhvFxak+SmZw7/5AyaSYR6JPo4 9eqkwTkOdY+1tA3gOgfsp+YZU2Bf4rXDIeXMzmNY1+xn2KxBR1lS3pQCBTVx3+730SLVWbuoKdO9 83H2wG6D/jhNWzHSoXuNvYjmhH3yx91QnuiG5svcS4IddnX3HKE2KSzxOAHeAujfIp4HvHtflZhs ePzEAoSFrbwTONdjiVNsk95JTaZnh2cL6oW3ZXDOkiwJrAZ00K8Tkw1ryXhLAdd9YNdORPsOTRFo hw2AOl9Jq05d+pSB/FNepfxQoSx7v1vj8CYHDt7o2lzYmBCng42/JY0k/YiOOtsv1kD7IK1d6Y5h B1KM2yzemDDEhAxLMnKdo9oZ+te9Keoy6ZXNbfTsjMrqrrYW55yoDFh1UxHi4kvC5Bmrn+A6zVy5 e00AQhDRaREg8iOL9G+0v9QfVwohC9VPe8LnJOB3JEh07I8skzCvckvXwwCJDXOaQJ/BUIzkcdjB nzgFoHPk42xMxjUfQjgbODKE8OoGp0W8RQeg7J7ciTpz7iDj4+Q1L6yU8DCMwskMlivR1+1QUbtB tzUNrJCC4Kox36YSe1UUb+32VVQjFom1Y7HbEdPoeCog4OoF5XZgGm3Uln4Kyg72V1jux1lmQ46k XeJwt3F/r0Gyx+dXkhL/8MtWdY0phjlnQZYqRkVl8C2O/imNkZTFmC6c7Ve0ZUucuDCXSst+tBFk iTZDwKfzLM48BQPI992EoMfoGSGR0MlRSEOkh9MFXrh3mnEPb/nYt7O0lnPfEO0y0EWaaTzZFRvf TRXe0Eu0cIvZKfLip1ed7Akz3djkxNCRaP7OzxkCnLESm5SqP0flkyfLOFAfh1AmHUx3zOJGdUwC gEjkYM9Qc9AjjgggNhOmtoB+SDFGXetCTfkgfSuhSj2g4r8P9QLl2WIPzV71skkcN+c5X70iVO1W LyR+TqqXsS+ltzifQPBzb/QL212bJp7e/xCzd4N1mQrvB6ZN86gK+vKh9OsL6/dm7kcmFaSO+kYH yJCK2vdqr2l3hv3EmW0VpnF4u6zJhbdHsLf4DgjJPssGOJevTctOF5stvfoZNuA4VZttwJaDKey7 RWWLYH1NDouo/RyflrwcbgZ89wnfiYm8TPFBTECPg8m7+5PAM32JI7WSEnjbxLVzzmc6vJMz3J+0 jGnxoaoxNS3zJ2slu5BK0AkTGgfmIHScwN+4JkXrRNtCM1qouF17hSOlSA6Vd35mCcWqtd5oTPNN CkmTC8xC8C9TA/6ot47JZCQyqwlrVLVflC1BAJJRmgvGV/I3poJZ2jzEIw+4SVT0txc+/hLPFrXs fHD0hHb+km5Yd6QH7Cs72HTf5RqJ27Mz62euv8DBmhWmYGX+yu/ne/Qcp6yPZTsMpsF/tRmbCuZ9 +u/5o4OP5n0yHfHpvsDXYxN1W9loxxgc3972ODeqxOY/lCuEizj3EaeY48z76/y5e9tketzGnCut VS1eYWoNvvKHp9/aL/2hdSn71sL5v2uDsJvTrYMYq7HD6fI4TL7D6fIg76DuGnV4dwpU20PoW2z3 sjX4zy5+yJOZrVu2dp1/g5PpX3jWLrcvx8cIZ5VhTEOBA4bw0nzrhzgVr92I7a/TmCscPxjudzeE +0HWN47DVsSVPSmvxce1cHi+HQpGjOYXFdc4KA8LO8hIhXtafEYRX8jrsg6LPwZ7GnCLr8EtVo7W h0TqDu+SGrQUeQ5fAuitECwJ0r6FbtXb0/uEKBzU1o0WUm4gmf24oyvjCwlgCb6kYg8VZt113jQ4 Lt/JTuosczFlgdClbanJ8IEBTwHamu5iXUrN9Nw0QkuD9Cj8m6iiGCbSWTGNBi15UR3cc1Bx5fBm 8l82qCe+xVACTDgb0SuULl/ndWnfF8QXGsI9dYmd9vj4JNav8I8vWRKh3tmVLq+WeC/OExJT4Nrq Iah27Mcs9Gw3rDiy3M4VGBS8LWj/hcqZobRkuCIMDT6Axqet2UGJbYMuVV4t8V7sN/Umy3aDtmTE Weg0cMRRFEr2eVAYyisl0OXVc93eQm0nDOGLGDU+evF2VkVlgrJPt+2BWtB4QdZx7B0YkhW7gWa9 3cgmvY7pv9Qd3nVQA8ZNdeTIfPShyn8YpIG7GWpYa3eK7JBXWPcYGmTfYDjxrbpqXHrnYC6t1S7H bgC6fbZxVgytdphnjJIuz2Ct7K28yGcBYX3t12E/f5Z/9fLm5vXPiLTkGOstfTB/MPVRw9E2Y1eh R9cVjlNnV/91Sz3MPnXbP6i6B9hvVJlfIfZ9hkyBjCkcJROPPYTfdxF79D0+BeKN2/uOPRCbzfyw jWTSYw+4uBbPSwBhQ49lFSwP9kojK2vjjBB6wBMa+yUcedKGHodP7ow8kFOZRx6zog0soFaLyANz Nrnf3jDdfzzysGuONfzvFHpIzdyGSJ2oORx9izUye2ZDCA5qQL9XoYevWd6xKM+NR4tJ8IgNAfOg o4U+4wPFNsxh0AFBFUMPiDNYkjJaElMJ/8B7ZkFHqAt2ObQ91ZAC21YIFPw45hZNRj+FDsKhQEHH mjlVUjfRuVKzO37A9j8J772jlvIsfgj3eC+PBWd8d2P0EUIPB2FVFJT7X1leLfHeqkRwYvtBMFKh 4IIViR2yqnJ9wHi7/+ib3f+z8MGVnZcPLfiSbdvHA5nQ6MIOG1vICEI8EEboIxThAftUv8JJkGPL ezfHA8a+Wo/gfB4QfCj4yFxCgLim0HDGCQoto5urAusgCO3d7YmsUIZmcu/4dBfepMe5A7NvrdtP 6m5z7zgyCRZCTtGbXC+8/DKtudu9s49bdO+pPRxx7+2Be2/wLasS+Qk3kSod3/G1ohbf9EDCoqgQ M9Xi5oNXdJHR6oe7GFThoP8Wn+aZzkeve/csLy7Uwa4pH+pgRdIlp/guBrZtMHFmU1XcesvzQVDi 6TDY2cEjX/Tqc3xY8DwmDCvA6dnrd1evf/jp55fX2btvMenC8BvEgTb8wweZO3CisZ+BxScuZoN5 8PhtlX/6vUt7RB6AYcAkBkzFxNXveZgesFFVnD7F9kDfo5sqvGK3/jb+xHbIsCsxifZZ8wjbAZD4 d3QDZdbJucXtSgCB4XddOdQHlJ1eYpwow7nLUEPRwyVlWMLfDQiXkAyAWLwEu2dYxDk2jerE1lRq 8GHnzn2Bdn1YfvUqrzLMHoBzl2bGSUV2JRxYJsBtthklpiht2rb3B6bjou/Eitwng/8SHx6waoLG bPIXF7Zi18qnxrhwbxcfp0r0QKXhUfxn8OggVzHxyE6hS2t5O/KI5nEpeuGRnWGBR5opbsSBNza1 68ZxN0L2804YMyRRaiTKVrUqCNkZM7zF8RDEIlP+FBf7UofOmHMkWvSU5Fvks+3pVj/40VLM5ItL 1eNHzabZBg3whyXXnD/JDZW6K6KM8CI+7I4O3MkOJ9bfBVomQ4Gvz5dIEG1Cy4+ecg6AfLR7TqFC djPVNKoo3zhivKh2xJsom+i8idjE4CQnb5If8yaY+pT2I+cdh2jxNHMPsDe3o4mBt/YrKn2bxtno UgthE+DmOMtlJ1byuaCqbt1mjki+gDJh2D0fFqrkPDBRIwqMImKz9pVCiFbuUaqWXeBMLnekGElh 59oIEt1rrWNfTwocnPMWOBy4yARfImamxbKEwVacNDNDUWg8c1RUgDWX4DTfn/oC5SCnovxcmi6y k6aDKmdf8YFA2I72WhQdzVkCbXj/M4XxSg8D4xd6mB0GaW2HHIxNEMz4PVPDeZSm9F4JOuj9PEpb /5jRpIZYTxvLjhuksxMOkTzVFzKTmKZI7PadydJrnaPiUBaTwZtJjbcwgvi7b4zKTZjxN94Zup1H F1EM+Y/AAiAFNPPg/aBLVIJujRqMNwUE708odrqJ1Hwkcl7ME2XCAqe+Zj6OMIJy1NJZeHUy/Y5Y 0OJTfki5QCG2sADpYhel0PZ+jeL0kordSACJkj0cst1zAAjYt7snlM42oCGIJb5oVMgGoo1tErps Gu+bzVDyH3E5N/kKZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iago2NzQ5CmVuZG9iago0NiAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNDkgMCBSIC9Db250ZW50 cyA0NyAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjQ5IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNl IDw8IC9DczEgNyAwIFIKPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIgL0YzLjAgMTcgMCBSIC9GMi4x IDE2IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDI2IDAgUgo+PiA+PgplbmRvYmoKNTIgMCBvYmoK PDwgL0xlbmd0aCA1MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7Z1Nt9zE EYb3+hVajjm20PdHdg4mYIJjx76EkwNeENsQAjYBQ75+fapbT/eoNC1NS8O9vgvshY5G6u5S1ftW VVe3dH9M/5z+mPZZPaRFXWdtldZDlbV92lZ91vfpT6/Sz9M36fsfvC3SF2/T3P5/+0La5FkxVG2e jz8dz7o6q4o679OurLO+Hsrkxev091dpXdi2HK5ep+//ocjytEivvk4P6Z306h/ph1cizao8ySXy FE3WNG2dWnmSNXm+SA8P76T36vTwRg5Devh5PHs1nv0kh8Zfe3Un4Zbn6dUnEQ+xQ6lFXmRtOxRp x0PEKPXe9Sm1yMXKTVN5eeKU+kAUV5TpAQV+NarzazmIqtGxQMGcpaJVe+Bs3+HlOMJP0pkY7GS8 fQZLIlhQtGXWlsMwU9AJC5IpC2INFgRQssrKom2Elm15Tp6RlYllpbDg29EY4B4Lib3iFZdsdB9F 12Z5163Kmcy8xwV6E1uu663rs66ttuoNgP8wwu/7UYtyuEa99UPWlPnRQ4yM1IC7ScUNZVbm4m2d xwrJkzpDesChuH96xcVrzAeqJC5QibKyoitujcbKvMr6ppv7VG3BU40Vo6ry8eC9Z7y//DX87Ccy ep8efhlDIUETWUol4FHcSMvuCPllX2dFWc41uRryo1MQ63yTnSlR3mZlW7UhLsy5GZsSBYLBOafm U7R2aLOhk1xtLUUbublNPztTxrbvsrbrI5IbiU1BqONx/TUL7r8IAoXnLv7jjn8ZcUlsowXtSUn4 0ca95PD3UAOX0lyZMfL08Iyx/mSOkurQxRdyKunMeHfissvH+qbX5lTuQqS3ciqk4kDy8o38KAkp t9xVWRLRWtPPCUhCOxvyb2N3tvPEDaVVsl2q53eSSHIHwCuzhNWIXA6SyTRNl8aDJRq7O3zNkUuS KVR9U45ceve+RqYLWdnHuJpYLsVmLzu0OORZnrelGHWL1Bfw2voF8tkgr/UUBUp9NzJyzunEMj1M sK3sSQ53ZZDjzOcSTtt5Ke7jMk4nh+dbklefikXWDEpJXvNepreYPyIA3AynmyEbBsn+z5cMouW5 JH9omzzr8pwShs4MZ/lDNKmPYSk93BfoFUVycEHCBTPA8+MYLHTghBovRmpw5+8chi3PYIa+E4LR YEYTboWg9p7kwGQe9hEPuYUf6Y1ryAS/uUXnqNAr+GQ0cAF0VE7qlWMvJ4eZ5FFBe0pwRH4hkVyC PbKShnBNP3jQI8xd2TUGYAm+2VDlTerQeGvYWhdZnXeEvNUIvMQOTK4PD8Q0JpWbAGB/enMuNy/y Jivrok1b9TSa67NZ4OFeZKVvR7pV5F02lJ0UhJEnwtqiXaerD4xHEd390RwlBUezI2kSl8ZGkIaG Ko8+DvMYE3EX/MeLaPoE6BxpzR15TVm0Wd81EtiUNVexuc2a22aiZSFVoraoZvJodJ1Gkihr+knJ 1JqJm3TpeQu3bEoqtlYSy67LqqGXnFLpfvVZt0VxPcs9x+zjTKEqs6Kob8+suyyzvoxZp1lym4Qr 7zZt1H8K9blI1jAN6d4d6ASBybdtl7i1AhdmoTbdEAsZAr6HXcXDcar8GKm4yXVLpJ1C19cLNHRt ep44R3b5Q9oknWTISRP/kDy5rZcmbgklqBXh2mRa8eVBTmVJhFoILXj8n0dVoSKG2FT1n04AhBfm /+qkvirbTNzkkLYjFhcKUmq1RMSLWjMMBr311ZIjVYtKquoDEwBZ85TkW5Y8zarn1YszniQ1/6yM 9ubzi5tTQSNr2FIv69qikFxMC6oWN0/9OXx7YrggQflfcpSaUjseMDsleJ2mfz0iA7j8Z2yguaOb c41e9LWvpDMZVo+gM38awAfAqtkOO1kv/Ld5JMk3kFCnxfSmMY+3QVDbIHHNHR+5qKUJZhdzrdkn 1EMEn1dPn+Lj4p6cZOizppDKkMbMek4ijx5Ptm05yZFssqhcVm6B/gy7tsizM043Q50NdbhaP8vA YwOjdcFXBqNSKgYIQJUJICUmMKqBB7hgA805U1D1kUDTD/cuk/PIjFc80tasq5CSSV4XXbqmvZlH upGsq+mbTGastybramShu2ouWevAHfmDzbreE3C1PrHimpvz4PddDsSpdrkWMj7tIjRoB+y6wxGT 2bGUoL3rm9HH46QBIFLN5nIz4e7Kg8zKoInbjjN7LPc8Tq77hmAS1z4yx+MaDD7WSu27wjdDQuTk iTTDFlJO6+ERCIXA04UGNtZeq4evclmKaKo+BWOhbOqdULDtsrx1SyTawc8c6iUu4Vyy6QOOrCJl Q9vGVTQw8frhxij4yEBb6AFut8x8AsTye9nOEksqYevE8l2dJZYvDazxJIpYloKoIJ5Y03Tbr1Os zwtKiSF1LxoAOSFivRMg172sm1cxU/hoYu3ILI/EqgZZC3XrFKuZ5VLmFOTZexJNYoPbU5w/KdBL OZXJBp7dgsWvKBDdQBBh4r9jA1fAxLVzj58o2xjFRIZrwJkHiA1yPiNLVjfABkG7PrcuizxrC9nZ 22CVOH8X9Cwuwh4jri6Nr0TcCMfgsw4Mst8xWD+sTbbbMcTVL2TTdC61RqfjBc9w4wWMppKaRe/W RG5ByC1lBXOoL0l7Mat3ENbWTwzbJTJp5OiVvzCVAZnN9ZIDnZPEMsYzOocS/5NTWarTc7MTnlux HE9+i7kr7xOci7kyoey6MpXdrRY6C9Sa7lyODnI73OkxyBVF1uS3J+bmZsOtK1XuirlzZtng9khi 7mmm+bGhhEytaMKMx8VcHVApaTyUJrWfdxFlmWLBJdoRXX8jmJvv7o5dtvKerxOsMvuOO3mXQ8A8 QdC7jxXy7lA2FG0dka9EE/6SrLbuJchLgXJ0QLsYtrRjzc5gwLsukhCeiGQ6vBGeXOnPXkwOJK5c pCqjueRawF4SV8IbI/4Qqs6TRdO3bk7M1MP7W6ZlEv1MWrTTDHN0NPeJwR8Zd3Ss6eA/GIaD9O/T 6V/9fTKzrCxb1Yp0Axyi4Wnj0c7yeW0ik5R+QvHxXVR7annlKJci1Pm95UtzQMwJ2jhcGSAcq+cw gjoj3NFIpqGNP/NZCEMAo5EXWwoTs7TPofQx4VHvz14S3c5Mz4ruQ6dUViLhvZTeJMuvb447RCQa xJgvLRJ5e1PMF1LjPBnHKNyKz5l6kuQQVzg1ZWG/wdDmKE7t9PYUH+EmBZ9eorBz2zpkJ1wmU+w2 SmE3+C5Fbbfp9ZfMtFCnP9gpDWZ0IQST4fzx5e4ip7owYhnrV6jWUPEMn++STceqz2CX2PXekPBS hV/zwCMgEQdQ55aHeSSSUA9JG6TOFi7nVVcWDehzHGL+tkgw5OF1aBi8hWVtnAP65E7aIX28V9iR A1WyCzAvyyZ1qIrIgW4m6NVt1taXvOWAFvVBT0tYmkX7IJaVMX7UidGKo/cv2dCNtuVDQbR4NwgD EjGwilHGuVq00n6NRrRfd662M2CGLjgj9aQXCqjQSj+2zzWnyR63ICB9aq8BY8kc5xoN1PIQkGdH QGkXGRb3EKCQvQllKV4+GnDb8L9zj0JdySbHxr2hsDpnW8qyNPI5W07DgytAYBOMcMA82YhpPYwF us9ogvbUiOEWPDaI8W7RAu6uGugEHKb8Ty9P5U4ziZgkCP7qfFWAfhhx+r6cfzUPxNI5T89WKX6c O5RpBZEHXXcoovZA0hvOHK+TBrLQ1A4SBxTuVufC23iwd/JT9rK07FacNA9mk59NPLA4nTjkqTM6 ccjWGuAFowIGne1a2PoMgVvWHOsxpbk+09ovVtSDeDilylXTiiqhIA+hWaofnl2lPAv6QTE6nV+j LpFDRz+JAJGKCc6I1utjZVVleXOiGI2x+arvvf37085tXyirJuvqZvCGiqiPHQ2Frwq+8MQkGh/L ndqrevVPsU4AnhvfOmUMjEl1nCCJkBEirbcrcA+yMtcetXVrMtfCfFkkvDJ3iceaW8h6LG0h9A4F yTIxt3ZfaiLnN71DYUyrc0A9vA57HgtWJuBCZ/TCQbfDx3DIFFyklPFrfr2qNLP5RrYv1pgnglzR AW4HfP1qU50PmVT4KKeteuVoeS6qNubyya/ebYw/s9+cj360knZJEiYGNJOcSp2V6gxsMPt9JNfM EpSOJ8AXwHIN4OjoYifoc/QyxHKiK2OebnWyHfu8dV4/CKRjgBYpIRlEYF6JsFyjgWYHDTTVoDFP Tr0e/tGcBprbnCG8JrxX8XW+QCr7vLtBKDZC6LYwrJKPEPR91ALqjTCs6mV9eYjaDr+U0jpwr9vf emNA6O1voQyK+JFAsUqcxL/5OdsKpBkZRRz7QvQCcez8aY04XPNssg8ZDE6aAEims3FiFM7le6m8 iDfSC1200/4n2DWdwV5cnFYPKn5q/J6epl5nolRlnXwDMtW4e/eRpurKTNaoL6nx4T41DVwtGHTz jUA2K4AbQhX24HBlzCKTcZIqoOKRZnc5YE8AQMM5Jm0YBDHaKSPTa7OQIVBTaZifjWrnLmfXBw75 kpt8UastUm2MVXAcnVKwjolOYAM0CCDeF2Z82d1pAzZDJBQ4XvRvlmN57MBgmpZBl8ctBFVkZUAs RjvKNtj2aJPrM0YltZe8rbotxriZiNXKTLmIWoE+ggPdajig6aDC/zkWvrECeteWBQv06fCiDW0b +mUorulOAY9e3/HIsBGSdoSENa9x33gNSSgRag3pJ+8friDd70NcQPrZ4P4MuT4m2Dzm+BnHT+Uo Sbv7CAbiBy2zRIUJhcVOhhjJtrdh/fb89Z3OldngXMhXpCqAeGtSy8bE1uBWiMipvk6YCDna5HyH GAhjJ84gBFbTYNfe0GN+uobDLQQ8zS4aIJLjml8KEvD4bd3IxPA6nYTA3KJlcp3yhNNI6z8bvCYb Ax598whISw3aMbzuWjdAJp4eg/gfrbpowEPQpygoMhZQnEw2fG27Mt+D7romlUWgSIhtCwU716Uq 8zHxQj4gvn/3D54dfGkC8CPm+nZMyDnzJrF+SzfXObvLABnJNvRl+SCBGAIeBaHgEWzhBfQ0Ijh7 MPO47vy++V2VHmxXDAqqNLF5Sh79rnQgWSPDIGU2/vjNGD054xYUoBlJZ0FijaIePxS2JPrDcVB3 meFOOPc8ua4Pp1e1lKm6oUodIG9NSJAqvnz1IsSPbSHhqMxIL7OjCikvwue1eJi0UlKbz2EM4+cw kvnnMPyCCF/4f/PNq5cCOvmIQOTXMHaIKR/VkUV6+ei6FnOtOHkzzlC+bpJXUYv0l8hzbuHI15Ll Q/CygpTHbKxeytM/Nz5KXsXz3mG62APNdbaB6/Qu27oo0gQ9hWMu6KK+zlZ08kFqjjM8BlwT4G1G krgv3Gi3qf0e3jM4TXVS6AVHHCai0Z5OGYlH4xbSI3xqsOizHuGsuhYinNU9zXWEeylmElWgNEYP hi3/RM6Qkd4kuKB6Lk2XPVtVL94kHofRvNjhNo68kF1ude2W5CKLG1idAxaCFt74VqmgHJvQYJoo +5ANc4A1vfjZlc0GtGU501GdEe4bqi5NPJMD8ztuBgYO9Qii+ekugiPQr5f3gZpH1TQXY6hHRi5J U5x8f53K6fcCL+jA0kHrgG41jfTXPjUB6FpMFon1HdiqCnlbwCw/mx2UkdiKxvol63elfAWoaNx6 ot7MEJmAoD9goL091wAFMAApwXqKDyQWKdiSBn5uOVZDNWUYiRZwRWey2rFbMPu4QIPZVCAoqX4K jzPnMI2j1dFtwV3bJ6Q5faLDt5Kcy5ulmz7QM/3U2vi617r3LeWjF/LJ/zZ1CLgtGXHZy1+ckr9Q E5gxzgC5jSA7Z7BlZz6V6ZYDNUF8cuv/bgnw0wewpX98gpsjTQAH342WBwf4KfBDe0032tEAGBEi qJPoQDNDOENAO4Z4bGQ7vlxlieaLkbTgVmTTAnPNfVyQFl4N08A14x2E+/KOSCCfJaQjiMuT02QM P4Hl/EgvfpKx2Bf8Vz9PKH+zQz6ZJmtjZ0Axfb1fMmceCrmD0WrJKtapoAVByt5HMw5hfXdbZRbj u+rso93469Vll2dlF/X259IkBf35g8UfiIcxxCIdfXRI4Qy+YlPh6yU2WXfRhezALIq+ELhF6yDa J+5IYnyCXLZ5NvRuKXY1QY6W56IkppE/izdELThtk2dvzKhL2bIh8+JADJvFjEvkiZ7om62rEuZj 3gGLluci/MifhJS/8xFSzzsJ8VIv6oqouoy4GFfywHPgCIhxxEF8xV2JYicFWP1VXdwJM6tMNfAO a9rL/EfrzOY/2gYfmiguEz4+z0pijthIiLw2ivtQ+sA0lPDPRZ1iuFnfWvZdjcXlXPqRZFhroRx/ 5Bo7AjkLPgZFkoVra6oJXPtCJBOLPEE1aB/vz/My0jAK2o2H+E8v7CCGmRSKu5BcXCEx3rH+H1Pm QYwKZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iago0Nzk4CmVuZG9iago1MCAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDUxIDAgUiAvUmVzb3VyY2VzIDU0IDAgUiAvQ29udGVudHMgNTIgMCBS IC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago1NCAwIG9iago8PCAvUHJvY1NldCBb IC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4w IDggMCBSCj4+ID4+CmVuZG9iago1NiAwIG9iago8PCAvTGVuZ3RoIDU3IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlnF2T3cQRhu/1K3R5XGWERt/KnYMhMQW2YzahUsAFGAgQ bAKGfP36tGaeGam1ks5I6909Vam90OpIM9Pqefvtjxnp5/RP6c9pl1V9aqoqa8q06sus6dKm7LKu S3/5Jv00fZ2++94bk758k+b2781LaZNnpi+bPHc/jWdtlZWmyru0Laqsq/oiefkq/f1VWhnblsPV q/TdD0yWpya9+jY9pQ/Sqx/S969Emk15kpvIY+qsrpsqtfIkW/J8lp6ePEjfqdLTazn06elXd/aN O/tFDnW49s2DhFu+SK8+jHiIA0o1ucmapjdpy0PEKPWd21OqyWWW67oM8sQp9bEozhTpCQV+6dT5 rRxE1ehYoDCcpaJVe+Ds2OFrN8Iv0plM2LXxjk1YEmEFpimypuj7mYKuWUEytYLYCVsEULJplaap xSyb4pw8zioTa5ViBd+7yQD3zJDMV7zikp30Ydomy9t2U85kxh430JvM5bbe2i5rm3Kv3gD4Tw5+ PzotyuEW9db1WV3kI0M4i9SAu0vF9UVW5MK2nrGW5En9RAbAobh/BMXFayw4qiTOUYmyMtOai9FY kZdZV7dzTtUzeF1jxqkqd4fAnvF8+TZ49kMZvUtPvzlXiNNElkIJOIobObMHXH7RVZkpirkmN11+ dAhiyTc5GBLlTVY0ZbNkC3PbjA2JFpzBOVILIVrTN1nfSqy2FaI529ynn4MhY9O1WdN2EcGN+KZF qMO44ZoF93NBoNi59/8vHVj/7g7at71xP9IeNrK3JCfa0QDX+E9pIAEiPxJv0Pxfcm0Id7gV9/md MxLuecY9nH7lutMtFqRJT1bSxA+sg6fPT9KNBDz8qpXymxsCiv38gbuVeItYTPuvV3KLGYMxwiik wtgZwyogSMUta3qwmuMe3Ske8yenKt9elBxJGgeMoizyrGrqJgWEMTYhaopKWxbEkWRoM/AoizIz tem9OBE2EW2iByh1pAwJiMquLpx6Nil1zUaZcX3QITqgEhM9NuFRIbr426ouy1QYZ/JI1/ytCtFF 6OMzvh2ijypu+qzoFp3EzP1Hz/gBAI7i1H3W92VMHr8245qAoJqnA6sIO8JHnmRgQAgVIgIr9ANJ 2R+TE0QGgcSTu2eVwLXWV3zn2JEBA2VPSZ5rHwzy58EPTZk78czLrXgVnkk6jUf13vypMJ2UbwTU zNoSjd1LqFHnWZvnVF+uGdk077wbVFcmq/K2ieDV/ytUv8AqQe7FoFqy286kDbN2Magui8yY6nIC 6KLIuiKSqknFGsd4mRwkxqvUma7CfTxgQ+6BhnHSgT9te67B21yzdyanv7m+gdYCmYeIFRaGMGng oflcosIhnP9IdUfojRuAuHVUCQ1zzYqYePeD3+AaPomnQAxpHsnbBwKsosylotpK+Omm8GIQbkqp K/XEexfA21J5LsqmiuPtCIgbl2MAf6DG4b0B8BKiACMAD9LA9hR3we9r4D6lG36lIdYA1CHaYD62 YI0Yj7UYi9j+ZLhHjGIKbmKrkLmugTsS1RJE7o5Gil6SqrZKG6btUmBd91XWV8uVmPsIsuuuzpo6 v0np4xEIADSvHa4BFCjVuJyyc4hjAcmcgW1wDEnGmkNAox4WyfZYg61m8GDUBhD+jTymVB6RmlvC NVuV5EftC7DluXrsUh4NtJ3jPFAB7XT1R7uLr90E0Bn2/Z9oHzJL2WIy2qLvsroqitSjacnaBN3T jHYMbq9NfCQtHHB2pTGSUrZzQTerCfuygoMFWnHA4oUXw7lZ0jTqjQnmAEzAh09qtQG8EmQMcRS/ anOiA7rT10Ak134Wg+9DAMOd2jrIlLEHxtO9MO2U2uianJqn4BaaYzn8SNd69B/lAeX5BOxDbZQ+ sQB60Xa0rCfbaeLb6zxf25qWiQF9FXRM9K1UGufcC93xNKNrvkUbkDivzMVlx2NunwnoGnz0mkDd tFne+ALfZsC3ZgMaKICIkHpUrYOGnZJQ7rV40V6Ga8yThg3THlBuO9Oujltoh2S+6J0JQAWn9M3h kfWjAXYvhlOJAZ/bn+dZB4Dx+AWjyMxoM3PXWMVwtDWhMu5ELhfhJac/ItAzjn/m+JEcxdoec0or JMJc6Ni6rcSvS2iF0Q65OPMmxK9zL5a8zQ1EZSX7dHrZ6+KRGBHqR1vGAWcVCqF13WZ9s1iXjXQO zDKzgG49dsKk2xgEYOkWzCINNZEBNq4FG7KdASQmmq450wDUvdCOH793rK4teJ63bEVqNhpDaioL Hlj6cWFjnuW8S01OXomIyiDoi87RCb1yjQZQCI6LH2lAZ/SCTkQLt+gbJD7K675N4yEXbQGzuHLY lBfvGyopLreyG+b8evGab9hD9TayD2Zh2S1QvSVuzVzMjKZ6ZltiAZtRb9mM7g2Ya5gADMCLaMik 0cpAWJdYye2hpchlq2ZV9mmtpmczmpbpAc9MiDZAHbkRG+rn3NLknDfsZAXesJS0yBtYunfPaBQd ysVb1KHUA/JKtk/t0OE+kzuakZS9LE4ur5tEep0ZN47qdFt2rF2x/Aq+sQT0z1RpTGyQcgidZgOD mEVSprtsNsdvNbAwnexSLhqZY3R6MYGF1H7zTmq/53cm3w3mZCtE2y+vakRi7tEQhUo5Egi9IChV QXTACdzj4bISREuHY84MwwSWtZzCGd1px4EgHw+CSDdevr9qOe3Qid+fTA8UeehWewlNUZzhgaBN Eh8tMYaGLdBO+xrUgBAYqH5E+oRZ6YVb5gU8y8E0YJ+eVzgGvijT6ONuj3zL0sjacJnK/tVY3O2z g6OpsIRhdX6TaEdPl9c3iobzAoQshjWE4GqmDehpIHILI9E1AQrt+JF2wQ9b4l/0wwgBhL6U0EkS Sy2uxgwjMB7N9Xhcwyg01Hmwh2KMYzrOeAgBDjEmghZdYo0Cvn1oPxHThwhWj/S7gT8NrCO3IJdS A2ob2eRVryNtRrh3A/x82Lwdtei3FufDgVEAnpJ3APCUr/YA2Ib5Gqs0/7fAS3Cs8wOugUDd7leX 8C4yqYcQD0jfQN5fBK3uNLg7mnBRozawvc2j6e6/IriscQRRp0SBc6JP7IKuaZDNgqr1170OVEfK XNaty6pKhSgnmNlMPvZh+GDgLG+eZb3xr3vpOuZ92FTVyXt1snIdlztHLFwXDs4yuxPShLweC3KH oiUIANbaG0HIIEdfA4b2loDbZzLS0CncDTgZgt7oJkDVWtxMKBpqF4BVbrV/NIwvMaW9NfGrCzTU aSw/MvAftOA8MfGV3o7t1wwe08SP6buYpaZXw22yB5Auv3KeEllECZEx09R1hNcst3eLlpL0t728 obkDV/vsTgdN5/YrhyppNfwn0l1KciV7urO8vMmS3gdMsuZmsAXSiZHAHR4j4N7ZjbefNWw9lHFs +GOXMYAUfbwAj8+H47W9TzO3A7ItDMNefO+TFu2VwdZJYMjkrFgMpR0lfeIEGZ4fUcncsKc+jGvo lyfWr2fQGV1zC+301nHGozl30vWZCtZgrcn5l5AXrfXMbv6qyKpKXjkGjRdjHHWd9aWwyPnKw1qg h07RMNRHHZ0fZ0V+XIXOWr1RPAPo/vzR4MkE8J6A9dQH3rV+ZuRdt7ZozWkaICUnbtEBEmD+3R6+ 3rsTyvSS48rr8GmlVH4BcUnVZE0VE5bcjfsoW9mB8fbfNlgh0CeOc4GkjpMAF9csrwQ2pZ2g9KiL txt6Nl8BGj7IUNS9fJIBnayEjtPtPDebo+2QY3TxRSdbBJZr0vexea6Sdx7a5u3v5fccdJ2TnBP2 nLQbDAfyLFPIq5HD20r+YSMoex8YjuZZuWzxbKOKxfvk0fFn9BplJQmp6W5StMNr4Wk4rGNB+6e/ EKARsJDkQCwETwwAsTzF450ryu4hmn1zaVrZfFpKGWpDd/eRMpd9Lt+giSpD3QRa0alN2Uk9uI/d e67xw9kcWzam9r5JO5ydLz/unPJhzbiU72z4Z1ryLfcy5+2wLS6qTHI3c96UWW6i0tm1CHlxzp8d jxyGLRvb6Ya81l90edul5S7pKYf/IIRUhtqRzt/YA0RQDcmB7fcgMp73azmVcqu+x+ev9p6wAw0m lHxuD8lNHURENCV1ABuAe50sIX62OfpmCIuMpiTazVqzWKC4j2BKarlZY7qY+s0uwD8a0DGuCOMR QQeZvCZJna07B5ycxHBsFdI7ZN+vD8bowwMNTsUPM5zFW3hZR0Q5CjtMMVn/HJpp5WXu4bs8Xq8r sPOfQ0v2fA7tQCUiBPFlKV+EKmLef422ggNh7ShOId99Kv3Wss3lg1jY2fTf1w+AxW7YUXGy+AnZ H8gknKPsBbYYYRHKtOOLcRqT0CXtKFAwui+gaDDbFslsXZZbqHNAxfCrrrhgc2F1a1qR88a1YWyR JnMAE4WEo6aTDcACz1hMRGPUmsy+WGnEqGmytlrOe+8lVspbqSr6fUO6lDRzHbts5mqgWFnVAKDA /KVU4mQVksLqYq0NSNFgVnGmN2sfYU0JnGuz1KZAp0AZ+wDK7CbQ4QgDAXoazNE+XZgKo1sToB1C 8CyLFoRIy37qiShRqvneghBjphNG5oDt8myBT6zaac9YjMyTrj3i7ZloKdUII/uTyw0E3odFDG/A GdnCuelkw8fm0FvEYZ0PQ/Yfqex1l52M31C1H5gM31c1RkqilWnSqKezX1S19nX8QzXb2UXgw6KT JLKJ+dpAND0fcBejOBJq1Y0vF7y9EOIjt6oLE2Cr8AnY2WCCca+ho4JAffh27dOnAWp4q1WGjETX AfWZRjZwDK+1FPHqi57Om3jbos2zor2cDRyFKKrvoioTu7yt55YrvO4nw1ESpacPkshZX+eU1a80 m+EN3KY2qX+qS1mRLGr50nHvP0m4acR3g0JZua1lH9GSR7kXD1eWmfiBGA+3Tz/Tasr5CtNIuvKV 7zy/mDSyMJUUU2LTyE8HU2vCqzAEeVA7VEyM9dBtf4DvuaadgE69Mhf/rQQXtu577doxe7e1rzMV QSPZftEVXaoVdC1nmK4lrrHY+xCU3u6Be0RdpLg4Sx7UMx3ao7LImY+Mp3tySUGCyyxlZCkp5u7w UGm4UNfYP8edQdHLar++fy40YEfO4mHa2WdOludyGLh7MZKn094J2rnDF86339K2EwnPhbvEt2MW e1n+fyBBF7sKZW5kc3RyZWFtCmVuZG9iago1NyAwIG9iagozODYzCmVuZG9iago1NSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDUxIDAgUiAvUmVzb3VyY2VzIDU4IDAgUiAvQ29udGVudHMg NTYgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3OTJdID4+CmVuZG9iago1OCAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8 IC9GMS4wIDggMCBSCj4+ID4+CmVuZG9iago2MCAwIG9iago8PCAvTGVuZ3RoIDYxIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNnEm33DQWx/f+FF6+9AnGsjz2Lg1pCCdN6PA4 LIAFHcLQhzCFofn2fSX/JNf1s10qF5VXpxY+nqSrq//930Fy/Zz/O/8574t6yE1dF63N68EWbZ+3 ti/6Pv/lZf5p/kP+9juvTf7idV763+sX8k5ZmMG2ZTlems66urCmLvu8q+qir4cqe/Eq/8dtXhv/ LofbV/nb/zRFmZv89uv8Jn+Q3/43f3wr0mzKk50jj2mKpmnr3MuTbcnzWX7z5EH+Vp3f/CCHIb/5 dTx7OZ79Iocm3nv5IOORL/LbDxIGsUOppjRF2w4m7xhEilLfupxSTSmz3DQ2ypOm1HdFcabKb1Dg l6M6v5aDqBodCxTcWS5a9QfO9h2+Gnv4RRqTCbvT374JyxKswLRV0VbDMFPQHSvIDq0gdcIWAZRt WqVpGzHLtjomz2iVmbdKsYLvxskA98yQzFe64rIT6cN0bVF23aac2Yw9ztCbzOW23rq+6Fp7qt4A +I8j/L4ftSiHC+qtH4qmKieGGC1SA+5NKm6oiqoUtg2MtSRPHiYyAg7F/RQVl66x6KiyNEclyipM Z65GY1Vpi77p5pyqZ/CuxsyoqnI8RPZM58u/gmc/kN77/Oa30RXiNJGlUgJO4ibO7A6XX/V1Yapq rslNl58cgnjyzXaGRGVbVK1tl2xhbpupIdGCMzhGajFEa4e2GDqJ1bZCtNE2T9PPzpCx7bui7fqE 4EZ80yLUYdx4z4P7Q0GgCzu4SVCAU+PR1yOCcXFECpz95hCc3fAIL3x+I1clqNBU7x+NsYyOF3nx 99FI9D3a5nXdE+6DF3QQ8/mDB1miIS0ARSLyTe9XlVUxDIKP9IlJxskOu55wK17Z9k014vb+7VpC 86LqU8x6DbePHERNBPVzdyqI/YjLT+UoCARBRGWv3E2JkSdn6SJmYBJucqrzmC9HCAJvmsM6NHl/ jADvu6MI9IzjJxyfji2FwB4BwegU9zjBaP8P3uRRgn9/MwvGxL0wBi0Z4iI897BC7v0wSvWNdCXJ G63xwrfjRfTCPQyOizzJvR/Hxk6KemMskpg0W8mnus7WOUhKYMA3Y2jNIAQg4W9SzozC9AF0Agnm CQCGCdZ654xHF7mQefb3spA58h70jhT0+59x1gUtiWy5g55M0xetkbCj1Vori7IcpFDiaiW3L1bi OQohv78sfNbun7xIPcQIV9muM3Mpt+ohyVg7Jzhqm7LoypL6jFbTvQRHtSnqsltk9dUwvB1xJpPo KK9WZ1adaSt5LiRzEKLoMCKymqczzWq30qgpY23D4zy70SGDNgUIXptJIPDgh565ZoXvKcMEfwTb pov32LUjfs13Gi1VszV2K8acaJuCslPLClXdFk1ZdXm7Mav3gjJbFcbU1xOCV1XRVylF2+RQZkS2 CmWiUwbawREcCWV8oRX84qThd85oDpjyJPAPffg3slDaWmxNG5z2QJwB2sVgHpkwQrrXbR6GPTGH eOVIQGgjfUxIoc19HGgWIkE9Qj0YDFE3o7unvC10kW6dJ4c/tpRycpW3yeBL9kg7/PiUZhgrNbXh nOgHXAJIoPCrzLNM82IkGog4EHA4fwSRvheJ2XsYAinmWCYpMeCdNzt2FzMMAKGhs8barvLDyEJS /PU4QobNizwDArVmdNv0Gz2dVxcXaZOhIihtSjbsc/JCDqJgOuTwxF3MwooOF5FicSpeyAsyNMxB 2z1+EWHOzA22S/fWmqKqpJLaKjjqAGkWkCSbx46iwGQekrRUtq0TkpU1X4FumQzSNpTKfHPvEqh5 qGCiZYFSYe3AzJyCGsCnrY5mgrdhMERMfkwxDGJoE4gOQEtPKOEvchc0ii7pXiR1zJ4dzzZ2gKXq BllN7oTaTwILStRKQOvx3iErTFOxz0ulrOlZUxW1ZOpxLCtlU7WmJ0pOWtle1O02MURDbIa6GOrl svKMGNYMMRD3Fh/C0dRD0nMAPW9k4jFk8TEdUFzDp4+KMBNNBDTzp1jyVB9D0AkTzikiL6Su79E9 gjJALmpa0F6AF3hy0Y7fJbF7JhK6hGrueGf+fLFagrDQI51qI0ZK1IEkkIe40USj2BEs2aqTdT7Z PqJBeP812aZvCikpLCZWs0RvzShCqRJYonhiBSb9hcyvBAlcZBoAIGdAjteZTB3wRFB7TqM/3tMT vQgyLRk9EKIEwCUCEJl1p8H9RSD6MJNekVZjjicXXGN2M9XinF3+7kw3lq1DBId2wwzo+Czat+eO RYkRSscQd9R0YBbZX7sLytqm6IzUGwIME4Kk5KBth5lOvkL2V9jmHKvYDot94D2VzA8imohxHvHT rs1gIqyDNEZHhSAKfNHmQxXI6WkGCRHQhxa2HV0JYW8m4/NcYt6THyfoxPuQ0YTgMNpT2EHm1LVo OsEQ6EMPEWPxuszCOssR/3wA/a0NgDugZo3s65NdH3mTDLVk5C9EScmL3U3bFWUbFg0306c1hxDn 65D/NIQjML1bKJJd78LIjq3OmrKTfZtlm4eRXQ3HNF0xtIuF85nnfTMTX8u6TBcWsXZN/CMXvR1Z no31hu/G4kcw8iM1TQ8liAizhjPk7IvsYjtKZbWlsV2fN2gnATxiFvCPdvbwz8co6f1ZyPuJuy6h 71M5iqcPAQlvoR6siIYJCtCk5nze0xSI2XEPBRJoIPP347RoBvWJQ5w52kQIGgvzeDjmWD7WbzCI NQkvybm26Bo7zWbCgu1ptrdzx1NjZbWxT1rUWyNdXfsgw9GJzh8gjrldDCMWMyuAEqbYoyiWZ8AU k0oA8fdTGP3UVSojxNmZ0uYnqO20adQbs9J9pxToyz5pLfQceY55vCmKrWSteKgvtlOMqf/fyFgY OWb9PnQGH4Arbo51lCyS3DMeDqQXHEly2h+DTIRwCVIij8xCipQSl5GkWSpJkrag4KspcUlQKeu3 K+Ic7lp/M/iTjXFVmfRtyxqtaSdDsv4hcNmNvyfSwLTIAWY0kcGnUN9UD0tE1Y6MwNFa1crXIjKD Xm3X4p3k66RiMOGTIB0Z3kekWvfy7ZUsqSTAPBVWPgn9yMFKwlfmHFh8K15T4rFZmANYeEYnN4sV KR+rZaFtHDPZJ43RhfbkOljiSdYz6UiX2gKHJnPqYXmI3uhmircvh/rKfU83lEOuZ/X+K6O1c6M2 qTJ6DpkmBxe1fJtUSux6fBP6GuiDVwVnASjhcgCMv53dPIdkYeAjhZIDE7l1Lx7utfIAA/Ea6o+x uAlorrQDCHXS4bEeyza8MNGy658YA5tEYIxZB8R/KpumFQaqZeF1HTLHKpmnja19CtqWtRD0p2pW MY5JX42YxS/+81G3YV1KtdPnpv5bvPgpqpUPLIyVz9xSMJWb7JRvT9fESfkWtm4krrL9OfEq+Ipo 89hTiUv8IhWc6MkMK3wycZfjPCNh41CbNg8DTvD0YtQARnsExGcw8RH/JadGLVVVrB+Y84KuHWiV UKbmBTSLcYaFiPR8b0dgVJWSxjRdc4q6TqPknWl7Ldsl23oxDrmXuMh2smhxVgUPOIARDsFBAJK4 FOVtCzSCPxAHgLbw9yHuxRtsLBSBUSIavQSmcf9E3hdfASojzx7KFMweDtciMlJ5/3J2XrnSc99L bKNm5gpim6qXIn9Svek0Q9pZOKmN+344qXCyFtwsIheQhMAe5LbK+8/QDcgBG+4EPMvhcmAxgpGh ly3OWhlXAJZyKCQYXow874XmxB2YPqXIsQcrEApkwbZe0ADLwCc6+IQrQVyIrbnqW4vBKxdD4AfZ QZa0upzTBaw+o5JLSwHfCKaxqwekXbvvJSal+h4a0NLpR7CO2INfNKZ3Hb3D5Lyg32MQWuqfRhvF qrkXJ8WvkIilXs4arfyDyDBINaBeR9t9gN8OpfzhTNhsrWsxs01s5zB3conZ9lJxHM7a3Tpnbo+i 54fhQfxSeBFb7/Ao7ZD3eVAuLFIkQuZOGuPrwpufAcvf+cgO5CoPKknI1N/MFHVVYUvbJixdJsuz I4qPqxK2tUVpQmFl07+dROB8ZAsMiCQ1q0KQ5DAQD2z0s8BIigjAhzVVIgb9nqYvSInG6B1PwcWw u3Gi73Gpl9szAEc69QHuvDNvHenp1h0c+/rAJo4rI/8t48q9YaKuBjiNLN+aq4lDrKtcGvn3r/0V OQCgD38TILax4JwGoY8dB0rpehHLGkJsxZSLe6nwOIRMIx+Fuv1zQUdXAyHZcGirq8nYRRSp6Z6V sWvscLYHQk9H/hPCTMTFDh9gKiP7HCrBhRr4MR8Am4JjCBdmD0k+eL7M9xmmtq6yIpSI3FeDZ+Hq rg6J/KYek327dxk7K2LWVTzq5UR+Fi6v+fYkQHsvGJKsFbc6y4p0PkMv75BI4ba16yXa5J4EDRc0 DPdfCO7bFK3A+5/QaugLI5vflpzcbEJPA9jOSlHVyx9uysrFfp/LdGqYBShBMaS5rOzANICDWFCz kMYPbQcAehzFD40hMxpl7wxvhNUHmgOA3Aww/2pMjSX9dfEqz2jBdZq+2Nq/XMQgeyCoNzCqOHAf e9Lxe+5R2Zmo7YFA+adRDFkIuOQ/LMnWiLaXAIfpvxb6dd/tNW3Ixq/AWjtJQbuknRpr9BtQxtw/ Z+4Dln2UED+AnvlgsEB6BSQPHLTDq6bYS//FEhJp5JLUITx2hLR+2HE5AmExWW1HYVzbfODXI9Al T+pVDcxIZ5HaV0XRvNfTJqp7j09680Vekf5yjkuCV6n/WLFMBb0rMIVW1lj75U1CM8e1ZgpoExWv FGbHv+145MxE8q9nmMvMepgJPdfarXwzsjov3rp2DvdQeK7XhsWjSHloV/EfwnQRNgE5PFJEyGRH /mp6Z32hH/our5iiq2FzyVplKxKxzhVAuHa2JdsEFoKdGYTfTOxlbSHx4GIseB+150r+Or0sr6au WRn5dzoTkvlN+AjjfOosXMo8mgUgfmwat/VQqEGWurW9a4cBR0EQYr4HL/BePBw2Fi+uv/DYCSrU RqSKR/ViR55BXtiDRmcxNfzJo8F7xoWhw4V7GrDSs0QM5Xh4qAZVqXvT3+W6F9glfGdsiV5wRmkp G8Ir+UxoaAebawzcWZ45/M+DNa9zR+yVqYxB2GejYj6Sg5snoED9G3XT6DBqjcMXl2R5l8gKd7VR Jaey/P8BwsZd0AplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjM4NTkKZW5kb2JqCjU5IDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNjIgMCBSIC9Db250ZW50 cyA2MCAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjYyIDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjY0IDAgb2JqCjw8IC9MZW5ndGggNjUgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdWdSZPcthXH7/wUPLaqZJoE99wUy3bkkj2K PCkfbB9seYkdS14UO8unzyP4A5qPDXJA9rTUqTmwuAB4wPv/3way59f0r+mvaZdVfVpUVdaUadWX WdOlTdllXZf+9m36Wfoqffe910X64nWa27/XL6RNnhV92eT5eOl41lZZWVR5l7amyrqqN8mLl+mf b9OqsG053L5M3/2gyPK0SG+/Sw/pg/T2x/T9W5FmVZ7kHHmKOqvrpkqtPMmaPJ+nhycP0neq9PBK Dn16+Od49u149pscan/v2wcJj3yZ3n4UMYkdi1rkRdY0fZG2TCJmUd+53KIWuWi5rksvT9yiPpaF K0x6YAG/GpfzOznIUrPGAoXhLJVVtQfO9h2+GUf4TToThZ2Mt09hSQQLisZkjen72QKdsCCZsiBW YUEAJausLJpaaNmYu+QZWZlYVgoLfhiVAe7RkOgrfuGSjeajaJssb9tVOZOZ9Thj3USX6+vWdlnb lFvXDYD/PMLvp3EV5XDBdev6rDb50UKMjNSAe5ML15vM5GJtncUKyZM6RXrAsXC/+IWLXzHvqJI4 RyWLlRVtcTUrZvIy6+p2blO1Bk9XrBiXKh8P3nrG28v7sLMfyehdevh9dIU4TWQxSsCjuJGa3eHy TVdlhTHzlVx1+dEhiDW+yc6QKG8y05RNiAtzbsaGRAFncJdR8yFa0zdZ30qsthaijdzctj47Q8am a7Om7SKCG/FNIKkZ4ZXJQeKFWp3pIOIDuVfkPgz4fXwU46yjj4+HR6U7IgYL6MSdfT82xCm+5FFO jwHj5fBdNFWW51Wdsl4h9b0VOImzLLvahOSZGa43A6emz0zXxMEpaDlPIGND/SBkHA6mkPEACkEm OZxAZhLxEnm9FnSJYUU4+ubsxXiP4JYG4JgzHqEdcuvmxCij+MkBz8tV0LwmKDRCUJ78ZnQEjESA T5+4eO4hrw6Y6PPrkWg/jakAXTPQ38d79MlBTx7hWfuHY/SV3J1kBiyqpK6rYWJpCkG++G5J0iIh F82AHQ7waODrPut7CV+jcl5Uog9/jAvN6qOnH0aVoNgg2LQuNJ4YgYvfjZ1pQKBfhuUecKYdsnDg yRfSmRCG0WnnuElDskLdtxfmGDklBy5CCr0GkCpqntZssFoR82Q8TQoG+lkmKBUJvRTC7Eh3MwN3 TC5rhtSikly2UWg6CUxVLit0i6rozOQZK0zruazpi6ztJXC/Q55pLhvNtqA86+SfsC3PWnHMZzgc bXD/OTLjX0LBoWyicf8PuXp0DRrTGEmIaS1g4mpZopmJn9Huil6AKM3nPmjqA7mHZLTTbgo5Ic9/ RnPCk7CV5o6mm32QbZ8cNMHmS2lnHbOUv4wM02wP+jAnsF5EqCntB05eyuH0EgJ2AyejMRfNgbM8 TlVkVd6S4qymXBLDAwN9cKsKKtAjLsdbQVuX9e7IKlc7/EzhnCEeycWiSNzAz4dTYdYzezk9PJWj GFceBv9OHmAptnbgD/B4KWAZMgVOEQEpwUWEi/jUCpAc/jIcRaAbjn/jiGCPOUVA+kciDpDBIZ1H gy4F3848IT9nfjEt3emFmRyd8zavk2zYRyiLPGuKvE0bhSjtdd5KllOarCiqmKR5CeHamATUlx6c +oC910YAn9zTncIMh12LlMSFRahYEwwV0xA8I5sGMjse2lloYtIZMtF8IeO2BSglqN9boWEofQpS LjngkP60NyAaAxBx+MnyFpeUcCQgamSPLAIJaZFs2eE6K/4wJuvM1Wy4NYUsk+nPST5AKGji8LE2 uQ45PAt+dZzBvUAu46OGqfU80o8hwaF+Zs5Ji+Mjb62X0AaT3vRFmMY9Gzz4UlMwuebJLw7iDGRX i/aZnIkfgiqcUQBjTVgFOkWKubmfGhgeYfZfj3ERi8CwwrdtPsDtJUdlHlKfNG1ZpRpK2gdIZUll HrI8l8o8jpG+7H+a0u0ln8gzzTyWfABa1IcFnNrdS2ypxqCD28NR+/SG9vXhiweiquRiO9Sl7FD3 Q02SpYlIgt5IQFr3VdZXrua+GpBGy2ON9M49gLqrMwnag+HDLJxZgg4o0dD5hNAQdru4lBoabMUQ 0JJ+ABYXtVkYjasvVeJdeRS7wBkRJhdJgnTyRz5LA13C0MGBji1eydwkLEdeJMS26QnSNXIya5r7 dlPL7NfSWm89Ixdt37C07vzRcF6khw+5Pl8AGzHrOOoowjZruS1i7gajZNINENsGeb2tE73NVMue flkHET/bFlhCPCusD9ogorrvRyelI0aNJp7UWCY04B5GluBbmm/TmvNxPphceV+qqGTb15giZZWu xm42bZY3bjPnCuxm3WZ9E7N1ugQiT3XLf7D0/2c2Sb6DKNbGUJs/Jsx2EfeOtarBwBIL6jBZkwfS sZZ0RtcuGEFCemMILvIotpiLVhhflFmLVhFbHolk5I5alt3MafsqraMh92bMaNXJ7rjbzLm/oBMF oy6vbusQFzyvZZAGogYNagakuGrt8FGz9pMYZWIJUIYQXs6pZBh6xnuOR36Gh34qR8H1EzlIbkQ/ jGEh6DMt7mk+0O7xJdFmRKtlbrq0Vuq9AoNb9rKnmfO+rIbbLFB9M/Av8yzvXGVZyxMZRsR5AAnu BCxku0eDM+TawIx+7g6cyc59WepIi0jzdVIOsmnz6l50UddZX1QSBq4v2DRpPrpMnV5CBx0VMYkp cf17AzyJLeERGgRL0JpwvDdALjAdwa+9czJB/4dbsQ0T584wETok1H2LaYlUyA5/Iq+gyIvwq+p4 K3wysnPUR9Wxz+H3Xa9O+JpKXRRZncdUL49oBVkc5vS2fuITXILPix29rWeIpfe8dO6KjrTXuYT3 etbrgDtPLJsdEqjdSazUvZCzQCw7xWhK+AgvQInEvZXPlHwcYCeBvLqqGgjiBppamcRnqo0sd/5o uH6aO0NHNMhBygWRrDwxkzbzWjWTpZE34vs2jYddNAt22IgjC/Lhvemoonm0POeUq+QDHvEm4Urn zGrF0tIC6oSW4zaqTmBAhaa39rrajltv4qtVeCEdmWpcOx5rIvokZ1rJcY8G+TG7iT3gYDtPXGn+ aDL2gvvuGMBI7NY2bSVfcy2r720UzqtOvi6TItW1vCJaDcQr88hXjrW70bD09+7V64AgMEOwhHkk ZQHQ2gU5lwAFKLzqHDyqYGvJqvumM+1tPWWsW4WVTgrYxdUpA+f51/SeT9j0SEybJfm3+BPJ8HRl mXnSjnmiILdt9njRQYklGh3UXn5655McP4u034z5TybLIbfK5aNLh79VPtiPJG15ZP/GVuQrbJV8 J5aX59DB88Aih2hAQ03bbPRJMGF3qeK+o9zhZgvZkpYCCrMMLfrMp23zsTvr49WQsZXyte2VfIZR VU3WVOe8N68ZCwhOXP6WSNxzMVn9QHhHIFgY+ehk+LZ2z7TX7bMNH+Lss2WLtltkLNSp4NWC9YNs gV5OrJ/dTF62fsHwfIG/dn67+TvVVew3exI+GCnLOl2FGPNWGFy2ssMVVZo9x6JE59KV6WTz5qw3 ke+fwv6t4zOSacCGcJSLCAVgiC5L69DlR3H6pd9IJjjylJrSlc6IXDiLZ40NAmmsRdA9UhVgBtzT GY4uROqKHCZCWyGE9aHftLQlb7Xd5489DEl0JQY03QC4aALs8O8+ja6K4bttVyxeLaYvpa0soz6c uXumlf94eJFNXvZ9IqiUivMNESkjuuD5qMfhIR3CH9NOi91p+dPXekDMu+MgwRQC/Pjm019L0CTh EUTUbNT3gOarcT8eJwjOCQD1sHDaU9vG9QzEuunOuKfXZ7Z4NJSRfABx778wIj93IoG95AwbQBdN grNqN3mfSYIRjCtnXnITCeYYstjDaKENCoyAQAf8YAFNgRrUTqi4Zqc1JMCQvsiZ/nAwaFw1gjVK 6cUTwE6Ti0gNG3lEy6ItNfe8q7IOwuWi+qZ/xlqFTwerIPkoV+mV8e3A/jM1JoOIwe+jG+lN0uUh yxr2s7IZL5J7dQ7CC/lEq0srcHgtr7ZUueTlXfAz5RktttF0Z/pX9rn81JIr+a5ubJ4jz53BYyM/ j1SbOnXyRKjrxGw8Gb2MdgW8RqXp8XzAtTi/94ej4Ps9zm84fjwcxeG5o3vuE5ymi8XcdXeuCerN iuWStkN858Uj3NOSY9QwHVgzYjae9LOyjKbWjEGgHSJxpkcIBoCvZY4nH7FiAJCTgxaegfxWk+U6 b8Rx7xgx2JtIzwEJ9U4p9zAVl/qcrct6eQFuC/aiuXBOHFl2sinZu+2PXXGkAzR6x2XwDQ1qRDmk 2Vq3tEPT2veiafAyUzHa1Ht2eoOFFtM0wu+erLvpIJ8spDwkbRSp0Q6WGI+56JB2gXKWXXSmEbn9 F9eiPj0YvnWu6j7VCDixztO3KKIROa18+J/VW//o2Wc2ZWukdHw9OyilfAyVF7E7KGtBiViYsURg dQ00nw1uQNwDqALw2FcAJAi/XHRfSCZp6r5M3UTHmtOqKdgGhJ0fEki9KWuLmOB+mzh7o5jh5yOL qCL2SdSwTddDAEuegKXUjhlHiZWgb6CCTdSRsq6wBGyij761TQy+FPHVmPDSy3OiGQfjp3JuxbdQ B8bOJ2P+wbidRnJwN5kVkmMJdUhBd1BFzzG4acd06Jo+OWNp3fD0bTv1LoJJukqFd212jnSnL0qv iqr3m3AMv1na9hLBgsWICDaaG2dFEaW8a2KCm96zhGOJGt6p2rSNdUfD3NNboMHVD7bTIOCRYMgO 2sAnB0Z3GAA9U6L4ci+PMkR8jk8D4nWkmCNpY11z3duaYqjn9xKPLmvu9J1T1lw7J22bjsJPXid9 jJG4maU2j/B9H3KfdaAPlli/3QJrwQKSYAkDqhlec7Vk1UGijDBh6b3XjGW/rS4lshrX9mpIauSX R0u3h7Pq35dYCiFZaFaf/As7yHoH+RzUhTPAttP56xLax9Gp3j5w4HoiilZFZhtlqd5T9/U83QK0 tXTQBt/3viVriiarbDqITq4GIyJYW7l34lcxEu1YzqnwlnmbVZXb5tDJSaRnuR2Mi/wqIvjUJgOL wz4b+CKUwrDNEAQFMIW0B082vvHBA90woC4fw6AgvImSdAINVLUFRl5EQhbnqBjXtkhms9ct6FvP heY8CUV0wZkGjoA3WHF3/mg4H180soWwbCQorQhw3UMb++Jxr8xLvkdbSTG1ravUYfFauGr6Livk o5qIfG3JngNRqAEO2ALkjEcAHrjFC7P8/xXFSjWPe7htNETqod0vnenImQbwBGjPQzG7RTFDuIYo 3TAEHA4mHjzp9iieA99nwPapHCWTeSIHcSsMAmHpnSVi146VYhlo58jwcOyGMd3VU8r4d/OmG6fu 8aVdjeXQcEdQX8orZKaTyvUGfL0RX2A6yX7k6+/AS2SRruCDQbXiCkCFjyWthj0aLca454w/cOQq KtY6BQxTk+6/GqI5fAFLmlKaNjRAUJ35MJAOtHSUrCVz8LGQTObb8G6KTAr5OTDWMUK6XNhsavn6 M2/aFD1HmFkxa9Pl9r9Gq9WEp2EtaRA0VmiExYerLAH6+WOsftBcIwj1HkeYLNbaPyHZQ1JxSqbo /GJFkGIbR3cWyUwrP6XZRG31LfkkVh9deFZaY8x6eys6vl5yM9Badtoczh8N55PAg8cXnJ0tOFDU inB2aBfxUDntPBht6sEZuNOja2z5dtYQzWc+3ZZnAebmwbbT1gXKMtBIch+aMgS9LUzCdgr6MVlC AjAtKdF9v6cq/00kK9tWHA8girAA0aDewTG/I2FaIVt71h4Z2kdvPpiY7oKiDBZcKxN9aZzMDZrF CWYKtdOOYbmI46A5A/00xie++XQ7Sjefw9MSk64dA28UI5PDAiNPwDUpHS8MY+Vy3TMTCm3YZM1h pqfdo5U2OczCAbQSbM8S8Aiz9Tq6ZPYhL7r28hWfw+DVcKLJs75zu3SrhYIlQz/HL0CyGnZBOYj3 KbF9Bg2x/MHE2uLY/+BGsO7kQPQeWHVxfyjIvvcCUNHID78NP4pjWMer0Ws9/MyZ+/WuVb1G295z CkCmMvJ+QhGztbBNnr0BTinZUR+1C3iOPHe+y+T+CZ2Rf0KX5zGfskSLc5arlFfi2iK2xvzZQL3G v8iLdcXy6xD7ocTdkoZjebnHk1zEm+DJstGhcW9+mHY2v2fjHn3x/UFQiSj5GA9zZA3Q/LNy7aOd Q9S+iTOXeWGedMEPAUoZWaoQ+XjQeZ1R947/eGj0ohunqCc8P5t29rkMK6pw9pJll3jzcumOkf+b Iz+TKeZyE75YZyajF4gV/XIU+0JvfclPPBdNId4bsbda+f8BazaklAplbmRzdHJlYW0KZW5kb2Jq CjY1IDAgb2JqCjQ3NDIKZW5kb2JqCjYzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEg MCBSIC9SZXNvdXJjZXMgNjYgMCBSIC9Db250ZW50cyA2NCAwIFIgL01lZGlhQm94ClswIDAgNjEy IDc5Ml0gPj4KZW5kb2JqCjY2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2Jq CjY4IDAgb2JqCjw8IC9MZW5ndGggNjkgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4Ad2dXbPdNJaG7/0rPFe9qQLH3x/cpZMGQsEkk4TpmqL7gg6hgT4BmkD3zPz6eSU/kr328fbR 3ieHPjWkin1kW9LSWu/60JIs/z3/j/zv+Vi0U161bdE3eTs1RT/mfTMW45j//Dr/Y/5D/uDR2yp/ 9TYv/b+3r1SnLKqp6ctyvrSUhrZoqrYc86Fui7Gd6uzVm/z3L/O28nX5efkmf/BRVZR5lb/8Jj/k 7+Uvv8//8FLU7NKT3Yaeqiu6rm9zT0+2R8+X+eHJe/kHbX74QT9TfvhlLr2eSz/rp4v3Xr+X8cif 85efJgziAqZWZVX0/VTlA4NIYeoHd8fUqpSUu66J9KQx9bEYV9X5AQZ+NbPzG/2I1fBYUHClXFz1 P5Qu+/l67uFnNSaBXevvMoFlCVpQ9XXR19N0xKBrWpCttSBVYJsAyna1suo7qWVf30TPrJWZ10pp wXezMMA9EpK80hmXnWk+qqEvymHYpTM7sh634Jtkuc+3YSyGvjmXbwD8xxl+VzMX9XOHfBunoqvL xULMGmkB91sybqqLupS1DRZri548CDICDsb9FBmXzrHoqLI0RyVmFdVQ3RuO1WVTjN1wbFOtBK9z rJpZVc4/0Xqm28t3YWc/Ve9jfvh1doU4TWipDYELuYmSvcDl12NbVHV9zMldl58cgnjjm10YEpV9 UfdNv6ULx7qZGhJtOIObjFoM0fqpL6ZBsdpeiDbr5nn8uTBk7Meh6IcxIbiRb9qE+kuBrSrzw7cz 6IjNeJRAA6eGqXk7Q9dGH9gfa7+/m0OSV3OF/5l7oGka+3W+iMHHbdIDT1L9R6MqPAJlliRbHZIY Cm2+VWNSP6imWzqiTSpANRdR1L+aofwyDzNy0AfAloOWL4yWi/9UYy7G811kIYBWF4n6voFnTRze vspOTzlqOWkFN10OfnbhnFfZOTOOU+SkzIAE5aIZu5QZ0Ck8R7R4Kfwwg4aoFiGCXEpIAcla7PAk kv1qbswCnxAZcT9Hls/cb5UfPjNAoQ/fY3aAKMBHA29cRYXx6IUFdgSv9x30DPoYDRUseKkH4QyY i9+rwyY/cBGNtf7IDjFMSZ46SgXbUH7oyhryx1z/8L3slgDeQUwtu1ePmt6dgZhkg3yBA10cRD+J sPvjr7qpmCZF4zf7q1MKZeECak7g/MlsCa0uATtQxD3UFPA/EWYEekFpBRnZr3eZZnHZmrqbmryH JwlOcxMybVl0TVk2eTd1RamJTlsX03gSNL0ihm6o1e1YlO4PVR/LsaynXFCZFHoNzmR+c3d5nL4r i6EsU/I4mwM+mee6MKjr26poyyFFSc4CJcY2WkLv4q21FphXCDsjkZeUwii97g/53gA1H1mnMDTA 48iEiYH3XwQoNroidPIjyw6oEN4E/eQRdBdnAivgD4oYQxk/qwnuh0apQWtURHWtp1xrd3RtEHPs kv3IrGejB1qJFIY8oTMOqnCZ6OYc7H62p+6rYmiUxN2B5tFM8jxVuTS+b+qiqtqUAD+ZnpOW6nS8 uLi3ui7GetOdHE3HztLcEEv8RX5AyePv5UYUkwBC4GPR+4/5SR4BaB+50ENzGfDuEZ4dNuujGSgB 9f90UANKewZyHrn2FOLM0VzmOOyQSN+AlWCePiEIdP/pvWTQXiCVuhyKtp/kWpKlkgySjSg+fZJc Ncqsia6bg47b0OMnOTsx4gJa5d7rpm8THP4p1D50SFBwCwKeC6ALMI7DfMxXsKUYb3ACQMJN5tvg EIyDLIv4TcR+7ugSJL/wSM0OL6DzpfuVJkCvhSqU0GCYfvJoNNbe9kIXLoqB4TJAvHUOVIhexSvM 5gQZFbEaDK+g13qFmWXR4cEd6vMojdphQ5M8pHEg2buMLpt6Ktq2z/t0rCVj/wLTELHfTW0xtSGB tpvQO4X9gKlPPMaCdczAXAR/mAfCeySBQJES4AJHcZLqoUa9AEebTUHY9iIyp6J/JFvyWN6TcA8E gHhCJYu8oJCgmgQR/dox7eq3zXL5R7MD6mDJgHxLxuZA6f4xVueJBCGdD16Ku5apXLzWXNSAbHfZ eMP832Rum7pzq9eTpkUz5BLM7W+jAmNXaApEzvYiFcAeAZwYe3jcIkY4jRSscaNeFOMcVQT5zYqT HR5iuz9Gz6xcrWWzSLIofSWYKLcJ2AOurReCTMal1iIu3vk0VGtaRaXJspGCXaO5HjraEQWbANUW 1MdI90KxSmUdHkaIsXOPVuASvLsSJ6VodEs9q+A8aU1RoHdtrrKwXL++6Bf2E1m/VsnEBbumLhUg dv05zE9WyTU97HRJjhA7rVk3XcoqyimnZDFgxW2V42sJUXMK+wjahCwQIqYfRFiljWlS3xiIoCOw A6Csou7RCbygjOo2G3A8FO/U7FCg5ZsZq9DCiKjOiCxyEyijaUZEBduDJZcnYSTK9NMsAKspNMZQ xOtELbggFmpKbczq2nwHdEcG6LfRgX4oyr5LmSWdUgKsjoUvnLUQ/essA2QXfALcpwatURFrZ9Hs MRqXqKyGUMEiz0KHHkC6XWuACCq8P4c4VrNAs+2Wet9uaflTPOlH7neZDVlY08da06Kt5t4JWHtl 3Ie1txZFMrqv2dRiKrtxrFsljTXDaKtqzOJf+/tw6kkrw+U45N0Ozo5wv+DsoeOY5rvwmh8YZxEW Be7HimyxOJuGh0fg7XNk9IweP9PvFFMt9BgAa4MY4BtuUkSQEGnX7GgukhzmCBvGJzHLf11Ai6ic gJwYuqYdJYauGKq8UpQsre9ZBajKzlm0b+YcpasQlgvc801dj2a5oJymaqwdSs5dLriJzoTcX9cN xdT3KWH9i0s3Ut6CzKnop9YxOplMwf0T0BcsxReUPQrD2mZE4ya4AVOI+YA1fpGbGD62aEaTteHN 6SJJ77zCAXe6pT/1vgHpk+s4+Q9Z3K98uQS0u1mBfn2eAKB7jyVh2htk9BgZPXS/qwXnJyorWg+3 aRmGYsKRAHaEe5LOedwKu7tli6/ZZ6v+p9WqHrSZTnmZs+AKm64J2407ctLPWewsg3sMG5BgnLGJ dnaDy8rsBvNtm5jgtBamuGWYOTmlkfdFX2leXrf6o9XOR78yOrRTl2Dh9Mi5O2XddGiqysjzrfz0 kUfcjAQT2eCXDNcWXePVqvHR8u+gzQIX2HPvMNT4aYAtKcB21B6xsAdgN/+xOdyTZuPC5d+umbTJ JyxH35QJALr2J6g+V+9FDOF0UH7Pm6TTbsXb7G0ThT7yg5IeuZV1kB3jcHwNivxusvNwFrNpJwrc W3zNyvwQb0EnP1TH/MTIzLs/lvwYtZ5cmeJ3vAOkaZSJGpouDwhMCWU02Dt/0UbbSQqF6myI2NXQ JURHClYYMdDwrpCZNxeRAmihxD37CNEHTc9+NzvExVm/YYz6SBiZAsGYIA3xtQPIR043/OLsOm7Z rA+yCG2i6/Zjsmu0WWzWLbW6tVuItgPaHDMjoBeyply0HGDkCfkTGMDrM4aB+UUMdNpw5IVP2uPz 9hj45GA7KWAGffdGG+Smh0mRfNJrZ/DY/jxyWNPCPUBCmqy12igIiYECcLwHufwwt56xLcDvTHEJ 9yMEgjlIAI+QSeBJiU2qx8SulQe6eIR6MSfpn4wD8eq12VHwO09hTygHdxpWHt7XfR9R+lASYuGQ 1Yzgngg3eRRq1zScsw0D7tMmY47JWU+TqFj5iTP2cS0T7dORU+Pe5OyUntbrQR6J90YzqqrotONw Y1/FUdx6yk1gybByCAhxIby/KZMmNFvryJNgDGhzEWAgJ0qxBy8u7tl66u88GS6T1Juj36rTGy1t JRlewDM7IhDPiH4n3dDeJGshcB6bmgLPaMVqSOSS17fIOq/B1COcQxmQH/zEqFha6IH+/mHyolRA 4PRAdUvL2dKkTehUY4myvSShXw/FOI3VGbI9b2JjHWn6qlbp3uBL2vd0Sj8Jhyz3URsLCN4cs3EO Ql8b3vywO6/waImx3RKFuyUzmnmKt0iK/7y63xD/eXcF2E/Hf3F6Az6jU/K6YjVgzzxtbj6yHIq6 4ilDEU7oyto4ql4iyq/lSJwFu2FL6jQWXVUqgZ8Oq9vAXBSl5RN0QoHSKLfaTneUskdEcBycgwyk /2AOSTb1g0ewQPbVdRoDbTxi4UJ1LlrbD2XcIwbhEVBj4WJpAaX8sBLNUHjyeK3UQ5AKFoJ0RLeF DPuS9YPAl05VNccKYRntcBfPsKFyWYiUGZplCRWoziO0uQQUaIL2Fb37nUW1lk6UJzsDecmacIH/ iZm1dtTJH9pZeouZCoiEt3+T/HzstZ4iw2mLZC5SHa/LI8fS8yaLHrgHlj4814CdFYK12nflXmi3 bNpN+CWLbcOgJvvp1glQuwK24uh/xSZ/bdFRYjhlj/+psMHqOYscwRgsIdnKqVszZ00Z2PLTy2gZ LPwsxCwKwRatPCZ6eCp7tfe6II9bmNqLlG6/bWbltN9xirFuG21smmSqzpHp5qBhMdkKcheYYoRh A0PrH2DWIrY7HLQ2fLbDIEVPHnSynt/KPHddMTU6k+nyRBJctD8vHJS18AjDN/xpzDxZZzlIFxRX F/qR6+5m43s32b2qHt2JDlXewoT7ksPQJnm32Ldle49yGMkYuZUvaAYpbFgcs77pyBekGl8v3FPG 1wdtCcYXi4xhB2nW6tq0ITYYpJ5IDXr48cix0V6nDRejPedRQ/mhM+bzkvvKnOyl3y7Q37pyIqmG vDWy2V0WOQ8rFy5cttKpUi943BvsVu6opbBsdBF2g0DBxD4wPXYXh7KKJnBg1tp9Nls7fv7dQUcp ed9TdggzQGrapRWbhuARJkO2DyZ7qAlzKZBtKSWPxkDtPfwoJ4zQ0RGFtlE6tMTQjK8f46bQDB2j 1/RPDX7QcvqnhJZb9eaRtGGvNPUdRztN3RfDUCnaAYn3xsnoTWxF+bfx/MRdltOkA+A7jp8SoLU2 2uKMCjxJBs8iAkRZtD5Hd55hflGpQsWQAoh71J7MFy1eIGOPNvBps2Wb9RgFakmboNWinKCVR2gM jlKd/IHV+EjLOtXHrMYyHXYxWiss2qQxcpIQoW0KK7XYc2AbwcVNmbKmKt3Ed8xbYHh/1EKnjmr/ 6OXrR0gNzAbbBlMRBvu6kboVDfW5SL3NdHHUP38QJfDaN5Q+ugEfFo9zPiy+HEi/PMr8WDhJh8S5 W88qnRs21Fq6a8szRGDxbL2bHSDMZig4MiqgB8gMdVjydis3DnsREmKxXpFuaWxtgeJ6wUOslOCQ yNBLgkRlx0u3lyedoefFiBeuATVTqVOAb7UGBDqDcqEI1kKGm7d8ffwFovrE/dZZfKX0C18+9Wov +IAifvCCQdOAGYjiJnjmHphlfAALnYQHvNREdMhFzIx1kdDEPXrgYrRWmrbLX9pmKJ1prfxb6Ino vsSDlF1R69zDPMDpvniQZtQOhCn1SGjEYH+iYffbtRA7gqYETigh003DfgJffqaCk9lMf+5ZVosP ++aUJR5Y0xEl6KSEdsAChml7D7rMM2HtBrqh5pqv+qCNbymdPUIYGzucM7NoC5rATWt2eAT6EQyt eS3LXHLrDvXCvWPeKzUQcHhv9GKoi6ZMWgk6zw1dmKpo+qYo3d76y0O9J/IBspYIGYxbBWVuCios 1B/jQrhJfUqAK7gffzMLh5wTtoB4KnLRWgagqlWsOA9yO3O2Xn+3kH8Occ/cr/JZn+l32fCAys16 mYVDQq0mBKWlXcslO2aaI47iSatloTUqbmZDjqiiCHtgKKVNg0CP1PtfjXheabxDbW0avX6u/FRA 473R1q5xC8q3UA6sO+7nBPfXGVXQjIABAYEJIlEpURYXxMuV9kzVTTXlSnanj90C2eoQY+AiY4i7 1fzYmWTALHTXOhbqAU6LZu5hZahnG4ODEGF7oDEqUP0vsg7SdC5iVaw4TkhzbSGCaaDfoL6WNqvF dMVAYSzsIop/XzoZ8jnrMDURFcSZ5yzRNx4VCufSUXGe+7p0FuW+rFKFlbuLMtvJYVSuA+JO75AA DIgNAQd5W4XwN08EZSAzEGVRb5uJiSofxAKUvTRZkmnxqL9cnT34ozr7xhgSnIFPgTP0ZFUANYOJ Xj1j2nLJR5yH9vAqpnbTuY+M7O5gc288lDpwoUlH123QfhM5cRtR07hXvVNerD61BAkE4CwGE8mA tU1LCfK4hwyRXTSKXtpWD2gzSJtZERGSFTpte7TERREq8LNJBa4VlB0pXsKL1Ela4WFtjwiwyrjv 5KxW+JJ98weOWHXHLxV36e5dCrpyaSiwlRDq3AbqyVuv3IpR2SQtt9+GnnTVq5SXbcv/z0dDPvRz nOzwX/43ZmnRPatf0ff4QMSajGgdvD1AMbgIwKPJ8KrARauINiiz2hLNl69O01RImtKs92ZTnTaX QD3RvVwQYjfuoLNWHxTSlxU8qGal2923IIN+bYB3SKHfWdFoEpBO4XlqeGm6wp1k227vZDjaFXSD Czx2Xmsksv+aR+D75fZ+HQWBtn+Zvdd2/EJfFtRU23ByF3u/iWRrrdPoXayUufZ59Fw4s6hHvdun r7pt5MWub/fi00u9LOeybW8wJQTPz2fzPSyffffKhhIEZzZ6fuxMtPbIgMk1Qs95f3JTB6Dwc7d3 UZNMa2shmA65h2uwtl0z1mif3vkRorUC9K7shxwp3Zd8UT3oU3HuoO2bN5KeB+ILzWU9lEU9hFUY Oz1ONJe/d1BT5tMG65vzCFABHAAXwOUe4Dqa3nLTu+440aMiECfgoGS7wJjSNqC0+1NsPZ60IQ15 F2g5BvN6brMZEVGP3i1/IJARvS/NWrI3z1HlZ/AZywCJRFa0yijWtiC+/BaHvU4N2cCM2MYOTW2i p3fyQo6O76z03ZIAxHujqL1O+BmTlmFOxRHWeEb18LL9nYSpd3/jWzreLSA9oScaxv03oC4ILSt9 xFbZiymv0wd4+CDx5BKfNzzPEukcQoUb+paNpecmSwRv0RsAa00ALEZPQoLBvv3AXMBKitZQolBx rVOE2jEJYXURMaLvlNB3Lh7bF2889u3LeiYDvSgvO7S5aE8fIVSg94hBbwLQduoxajgKLcyqGINd HWMosHBh2t1ht6n1NYhe312yWLkHoWmnT0RPSWuk53n1S0NTfUeq04u1CbHpbehJzo3UWr5T+J7y XloyPRfYvpgmrfV5dDfF2Qjdrwc9f3R+t1+vorgQ3mo3gcL7enRx3Jgaq/JoG2pWmApYhRM/65hg 85E/OEIViP23fkUhQQiKCYVek7PVmROJ2npq55G2gS+fn/ff5o6fptf3fZXE0Al8O9yOE6X5y5Dy pEcTFwwXBijY4iXF7wbK0OBJMy/LlTMTrETq+SL3ls/hulY2WUp2+MS9tbD3HvlS3QoWz9yESfIB AnHFbm3ZLU2U/nyXAYHP77qNMDtiOlKKTR3dP8rwy1wH1iqsKbOv53WWRy8EnL0jL188unYi4QcL 1PwHVwa9NN1VLmKsa/dZPAFu0n+5ypXO3Ol1WqEyGVV+lb/wcdRS3SF1p7Wqm3ztztV+kw/6v2vM F+fGkg45dacyVHp1uVWWoFe4pTcbazV37dKVLuk9Yvddvd4fOas/3DV3CKpWLkPVzF07au0q/1YH +H4pxuZfJ/JLVi8blNvxo+m1YKQvbTieXb925UZe6NOuy9h7fahQF0Ktq42WHEmO307glVtG6/R5 dH2i0A1NE/I3R+UrfeVDnWjZOOMJfVlRb23pYONeLxzqOyA6eWe5otfky1bvTW1cu/ZUdu2KqScn 0LgPMDsKQo/6/JXOVdYJ79CkD2LplGwt9WVhFJTVUtvpkJZaWZbwjFpqW30lc3DgC8/pIGGlrdxo aDtbXYECtbU8xbWEK9m6njZjeM44GkKPgX8LVbMMFsrn8qvs+MpN5Vced3X+z0TQOSUVwEvJVCun s1rZ8pXuuwOWJO74TFPqtVP3kU3lwpVq9iUlLJySa+ymvFviWX1uLhgEX3dUWKL+stjx6L6/OYkC T1os6ext9w2yWL5SeZQ6axN+vCYLVOWhwblQe3OkfKUzT7oZynslnu3DKF1Xqht5EDuOPPKkxRKk xrK5m5mS6JoVdd8OS4EXQLU6t9vZinBFKnsb2K1UyAPxRhgeG5PFeIhF3rwEVRZlScZjHtFaacKV +Vz0VqH92MgwS59HHRxS6U3SsdWyo04ArUttgzqOQ6PZc5FROfWj0O4Do3UxtiptUJqSnHY2dLLj Zc7Pyzf5g4+qopQVdV/N/vRZ/p9fvX37+lfFO+Ec0XP6ILOy9NHIfbZTX6lH35VMH1392x31sAwm Hx5U/QMdMFPVH9ZN/uzzpUd35kvrrISbwPRSmrYXg3QCm74EqCvat1v1wzQc833m8e6uDbguddK5 wX38YEbWDJ7t/HheaM/rzIsQkipuc0GoNjoSulNy0b3OCqXEupCbKCu7o5jQhtfbwxoq7SQJw4qB 9rPXP796/dMvv351lf38nVii4bcKBtwwFVf34kSrL1e7D6+vBvPgyZsqf/yjj3Y2KugkO/9p0qYq GpaqlxqJfI8EPnpb8bGem86fWviuCXxZyRfOE68NvgshmYf7qaSay2JKCDbc9pMGHVb0VDfdoUWh /HCeC3zM5Sf6VRyuuyux/B86RqD/CmVuZHN0cmVhbQplbmRvYmoKNjkgMCBvYmoKNjQ2MAplbmRv YmoKNjcgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jlc291cmNlcyA3MCAw IFIgL0NvbnRlbnRzIDY4IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKNzAg MCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgo+PiAvRm9udCA8PCAvRjEuMCA4IDAgUiAvRjMuMCAx NyAwIFIgL0YyLjEgMTYgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgMjYgMCBSCj4+ID4+CmVuZG9i ago3MiAwIG9iago8PCAvTGVuZ3RoIDczIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAHNnVu33MQRhd/1K/R4WMsI3aXJW7glJgYc2yxWVsJD4gC5AAFMSPLvU2p93dKWNZqWxnM4 8CBL05fqql27qi/S+SH9ffpD2mf1KS3qOmurtD5VWdunbdVnfZ/++GX6efpd+s57r4r05as0d/+/ eml18qw4VW2ej4+mu67OqqLO+7Qr66yvT2Xy8tv03RdpXbi6XF58m77zYZHlaZG++Cq9S99KX/wj /eCFSbMpT3KNPEWTNU1bp06eZEueP6Z3j99K367Tu+/sckrvfhrvvhzvfrRLE3778q2EIl+kLz6K GMQBpRZ5kbXtqUg7BhGj1Ldvp9QiNys3TRXkiVPq+6a4okzvUOCfR3V+ZRdTNTo2KAx3qWnVXbg7 dvnr2MOP1pgZ7LX+jhksifCCoi2ztjydFgp6zQuSuRfEGmwVQMmmVxZtY27ZlpfkGb0ycV5pXvD3 0RjgHguZveIVl+ykj6Jrs7zrNuVMFuxxhd7Mltt66/qsa6u9egPg/xrh982oRbvcUG/9KWvKfGKI 0SMVcPepuFOZlbmxrWesNXlSb8gAOBT3fVBcvMZCoEriApUpKyu64sForMyrrG+6JaeqBV/XWDGq Kh8vgT3j+fJN8OxH1nuf3v17DIUETWQpRcBJ3EjLHgj5ZV9nRVkuNbkZ8qNTEEe+ycGUKG+zsq3a NV9Y+mZsSrQSDC6RWkjR2lObnTrL1bZStNE39+nnYMrY9l3Wdn1EcmOxaRXqBKxXIx5JIniosPzW ihSWYcDR1NAk5OXYjMsbkjuKEAy5e2RFpjzlL3Zn6SJF5tUH53C/vTIfMVehCIOgMYpQ729jBYqQ vHA3Sp/4ZrQGRRmvqsQPW9oZUiOXxP5PutTRUAMNoTYu/Mag/js2BonzEGkYKUL9LPqilclcA0Uk l2cFKy5gc43NuF5VZVY0ZRqPuGgHOEBYk0NaulH1JlfUHAV96QX7oHXi6bdmkQHsaJ8aGI/8m4cY XTFEHv0fM1dRJj4t5Ck9rsIVq1OSLpDt5xEmig+KeJgiIsOgKGXAiXcF4KY1kE1Hw0PSMsU8sznk Vi1+PaJVK/zpzp5Ok4u5FhM/46BDLtqotXa7SFgVNjHvbZ5mrBoLrGigXxMJbTKblb0PhHmW57Ut Jdh/yYuXZzIev1RgGra1gjy1gpep4YgzWsZ/amvTmcgo6wWLYD1FI9Cn1Ad6AaGi4K+jEwAb/ASE wI7gHI5XH+Ah3ZJ/AWx1OhBNSYSgWySDCLj8a5QM4bUxqtMYrUAuCLj0fJdmruqF8dEYHemg6eF3 A/8UIerRE43qWNABzWic+dNbo8tmNsIpdlP/uesjLEfQAM3Z5ZbO2mV9YdlYPPD2+apmZfFZYnPK TiebA1/OEidHQJtcng1KtYWfpyj3iV0tT+JXZfcfRtyRC6F/LaJhzMcK4DDPhQIDg0Zao76vqM2t Yhs3pQt1YTpUl+KOoKiuT1rKQ5SgEQdBiTi0QmjGUVCJ5rg6FPV5OgLKtEIROiL6WdORMD+SeuW2 slzlddqCq4h0PxrnR/jeL1i3TZ51FoiuSL4Uphj4pQHaMn6FArbEGODqV+YWEyEphAJ0XWPYEujR Ebbkt9XsfUnAbl00EL5zSsbgnQPRlP9pe54JJdMEx60FIK/iC9EWbc89NkxFqBiG7Rr1FRXm3K3M nhJPMWhI630CK33G9f1o2B+AWVX2WVMbuQvKNNdZpBXRqF/xwnh2r4uszjufikma8/pqEwbUi0+B vT6BzBkOcxPNJYc53Hs7YPozzuSA4JwpsDtwpEN8iju8aA7V9M4s7eJR4HOXCHCnfE4zSpc+g0AP 89EEyNGaph4MjXrAkeoe3FYR9k0ubIet2P3SxLccSLduTmmL3SPYd4rqm0xBJGI0FGWkY+YWlj3Q jbFRZJw54nAWZ6qusjgjCN9eBXw7cs/swNynKmy/szl1C3k2GcA0D3MpqCdQ3VB/pS3GNdWElIi4 uI+xDq6i2nZMVhRGpSv56IJBJ+QqY2loRcU8pCQrYkpC/AbECTjUw5nhC+IlQN9yDZWF6hqoaIxu ySfofcYaQ0oNwdBodksHK/M8q2zXws4KzA2y7WCmwaid/gMONq2ilWXWl6vzlQU+9uH16PypqGxr 7rQqz+sRlg2S1iKUmdMMOGSEvdwplj8cYlkeiELXABTTj8fWNOzALOoEIeq5aG2giuSZAxGpqG0T oumMp9FTRESKttuBuDHByA45lFXUgZFoea6BdXOqLXRH7R6d4z0AoKhYUo7LhZ4NqLIZ+wfDtUjv 3uP+U64fD1dDpr/6cp/w+5hhJaG+z7jALhLAaDz8weoa5iE2AAkBQ8eGxKEI1ZGch4FrncvoQ0qG +bSDNWkjQtCRMi8d6dxN1ceGDg9Vai2JgJ6xkYky7hKW1pHe5D3qeDYBuLQHYgnJqeqLdAtYRlBy RmUXfythpvn2GZXgeE3fWOYRtS15Duhex5gDjjuTvo57I1iHWAskfTv8CDi40HhYOzFohl1C6lNE cQDAsTFFmHVwYSGG6TrVKQlsGZOiPnjL3E1oDKmz45gyRF2wYVmdsq6zDYcdNtxHnktMbe/zTZiy c0VVE7O1HC3ONbGlabssb2M3+lZzgtNIhWbO2ZoRiebj8aFHLzBSpCkmIUEw6dCb3HmypygsCOKA GkB/aj0OcYKnNEdFthLANr+BX0PlPopLdhxGLU55VtdNl6q+N+dc0fZfyXWiV12apstObcyiyzXi XIoAk3fUvR28qGLO6p5j3GcDAGSJ38VY4KEBFCbit2kyO4R2AKTrNd+MOzVETA9rDaCr/L2o4RzB LRvtw9yeA9CFabWrT21qq307lIpzbHulS83Ut7acEr8/4pPDivWSWhzRfD7YuQ3L2U7ribeaBiNv JwRGDC2j1KJZHvigOtRk1SNtd4Cfh2MhTW9TNW+7h7LmYeswtn/v9yY2+eucgyoKdO0CN/lu3Hoj oUH92yByecYqsW9tTCkUNO9HFi2i2+SKCOQkunG3Ndppl2s4uEEFOAm9MCKcS3tQ9gKyFHli3mEk 9i7R8Bmk+Miu08aO8hY13UOXPkbCeyX8XOL70g4J531jGT9weihT7aayIyC934TYXEE6B29o5b+j AQAtllZupaQm+qtTA0wTOMpFNOUvWuEhoQwD061W0JSIHhR8CM9F2VPjQ0C5k+yMTztEqk8vncsV QWqdz1KS35h6rHa06pRfjYGbClC4moOmtbopJNINjrB8UWZ12TbmBtGw25eGHVzZtgP8dvboqpVt LATmQMt4bm+2++LgMs/1w5KKphPAM8DM4WRpfZeU0JjC7EDocI0pwwaPcb0jEmzPJIILGPLHFCm6 5drqCDpBCjmr0xaKBa10yB0Sas56xhK22GBZMvbhcsESt/SEzmbFXZ8q8jYJ+H48wdammtwvme87 H5j+ZAC46RFBC6P2BlxpahMxZe98sdNgYQt0RvnUfAnz6zErox4Bh8Z8ig1ywSN4wo2yWfIRdqef D5mJzddx5tV8R52DjunijUaJ5zbCQZjfDkKZd3zK9TOuT+xqWdX73KIJdTAeoizUszq1RDv4HsPS NoMnOzrCvSdqjHTIRYbmVmQvrclWla3xG/A3kPWLLMnmw+tcsXtYKFMvIA1Qon2KYC6YmpnDagUw ST1gS3UMSysAFUDQGNVxFxAEmatImn0FvneAoFtQYv51O0AUw3t0dWNUs22Be1+ktze7s1Phd8d0 RrrY1dwXMQ4u8Na9vbdu23URU5pzUwi/tBGiujM2bg/ilBNJd4ATv8EoyyTGNQZSaew1YhlYjt8Q whM8cHQ9JXeaQWsNvEC7ANtI6BuFxCm6dEIXgxBR/QYPU0fjWII2tirMRKSz8VISQX8a5w0+cUU0 pPinxQFbnnpkl2lS/Yzg8HS4WiyxmIFX3uAUVWUziKrvinQH6qK94MCMJizk1sO/Kr91tpnHnfMC rAOmA4odfDXkYiu1MejnN6oHLnZxnGUmimgABm/qJ4F9ncE9el2jid8LVryvQmw1WgSAu6Ow9EuH 2maUDzhkEsDUvVEo2gLDQb1zZ9PB+3e3UBeDUCvRKGqmUa8nuw3xyXzhzX7uoyosF676MvXIi+Df +/EE++JBXl1zSAw1kjmo3kEGi39qxRczfW9/zuRAglgU9n2EfPhOy/nxLRJEc3SgCz4YChAE68BL IY+LeSRRhtZ01P4Q8HP4V+GKK/x9pHUArsTRWUULf5ldjNWr8c4ftOUp0rlLcmeKdief8AXNF3Ug q3yAOryDzUNsuh5iETzkqU5UjTzJEHlmcW0aa3DCeFBEfsqgyu1tunoHJKI9cIHQ4QDApSMAUyxq muF8yaoLLjLEc7EI5SmRKgqx8/fjJBloaj3ulP6BvYKYu7+NjVEPXFFBw5UGRGRBQJaiSWWQjN8W HkXbYdrpcMXDgFIDex0OCKESmkMo85J4kO39Movl1vZ9qDatN8y6WPS4BmbRW+m1nR9s6wezlV5X w5Ja7Fb66skOHuYjj6y+peizXPUFeAncgjgPNaYOkC7OQH2A+/FAqEa+mqpwx1wnAFhOTdGqoTIe gHs/2FLY1yq6yr6p5FUccQD8fhBor/bk7frm7ILorpHn0u7eRLzF8NGi7pqp8Gv4uvyimIJmFV8j FMNrO4DmDL5GKAK3CV+zKR/ZhFI4rUGefgLJUwh2pUbiT87jCsK66R25gXoWHKwDh+5pht/okFYY EyqiFSrQQ8gw3LSLVihCK7tC3eCVt/qSRpGVja3/RGMu2geumghbSmRTEpKPQxNhtWuI+84izwam lNNO85wP8CjMgDAGdlYPq/HaFXYGJqQR6lBgAOysptWZiTgtj9Dm80FuWx2h7ZX18eCdeBAVfRSh Ih2DQcaLiGHYyYFYEPmVydKCfn2y3LLGzhHTTksyl97lNIT0gWKcgRknA+SOkanH6kxcNcpCgGaJ NGb97dPPnoOPVVnYxzdtQ8rr58HESntpqLDlgpV3txah8tycACOscimmDAuTc1MGB3ZGxySacWPY 1cni43Hq+hQHwi38rcLlTeVhwBVkMjiE5Dc+bakY1l14PzN/PBKCF9lffdJnU20X5BmZXwwP/biv 3LBmsNXdbwYN2UeCND4xifrefrRJ/taL7nChDRP3uMX6rSXpeWO7KvbVmQGOEexxL1GrsvPK/XD+ 8Pj3n5RrgqHcGQbFBY6EvimJlzwasQIWln7hGlPX8YkWzRA8NIaoaK7tZPFZBECDFFTXnpAXJHHR A8IEIkrSLY3hqToyQM7DJ+P0/8mI1U8cnsO+DG2ra6JK1aHrKfhBsIRzALXEUr8e+Tf4HHKV28Hz 2l762QG1aOi71aKDZ5/sRaSsse8urUWGxbLCucigplkN1ryJENJrFwt8bqM2xWBLunU06H4LU4YL xhwID2EUfL5fTinS03ZOtZKxKJT1cKvvgv4pykBVCyupTuITJtibIuiZwaw2TcgKorlAvBpXcXUa 2zpAaR3dcBpT2uJCXacehg8mInS205j7lz7f+DxGjR51EHs+0YFap2P7+zLaXa9V1KXt59jnCCo0 EmEhIwrgtQhPPA286wJaJjEP6D4f2N8mTBSFFIglXB7NKiZ3z4gXPr8ijNAeDXi/DOHL+TVOMP4Y PnOGLyHBlB4NszuaU+aiq48HQazMry2cDUP4A0PhZ/xWEzPkoT3QQc+uXnjBkSJ+ICb6AdvH7m/Y qSg7b1cG20cEiX1BSw+dRK89V60JNnyy7fh0ZpWLAzCdswWinX85dg665Yot8MbQ9LBs02EeC1MS 6wMxfuNuZughoNGaEy3kOKuhQKMMgFVMM0DmMmG4bi99Dr4wTkSjJNLjjfSgBxQpqYrRfJTqaMsT hs1Ubhd0hvcxGtu68DCKoLRoWF+zeGb7F1lXrKJ6kYpFi7OykRjvZcNfJinexEYiSOHyCUwNBXqE /2VM/wMoXcZHlVVvVTSqE7E0RxF1EDwLX1BsAnsJFyEiIAxlkImH28K4MIOfUUE9kocIig40sVZ5 9QyZX2tgaLoahmj8RtZMF0ZnN/SzYefIvjOSViDpwThaZX+Wo1zdu1w42rk5D/bSC2pH0bpEpKDT VH44bREZxQ/QS2Fvt5xqe3e0ih71/dCLpf6WWcasSV4jT/T2nf2dFpuK5HUESM+hQimBVeizdDdP MvBR8LRCd+HAnVBT2FGIZzhe6dSpJehU9kMKeAfRoMtQ3a1dKpfpvNxHdGahFMUBeOjaDjsg2hNE dWGGOhxMtXp40Q2WLsveJoTDZ+32wUQpHK2R8oTI42bpqBmlmyUiGWER4aPedrC/ZlUUZRfGciaP vvfD7cMqWV3791E3D7efc0HAo5fVjYH/DPMz20sMdO0SjmAUF7L5jdY0xcC0bmk+pAh4EBU006UC bYIFjfhQxor/BzlpGgzR2FyWsGS6uuimeYpWxxt5uFy/dRMXeges+CY+jd/TCtUZivIb2ZkyC62g QdNLpAMcCInDNyHt1TsLiQK4zWWefTHo4Gpseert72P47XN1gGsyE9SPMfhWnbI9xlDypsgZRDgL 3eZ4Q+H+UMipSr1GIqJytIUOICYc8il7+4y2/UG3lZWHhYGixVkwuDvqeeF9tUmczqayrd+5UsBE buwCCjybi1/E4kfAgd+CCnXtrRyAkroksbrsQMmQXjhOht1gG011+A2uQ06K0IqfYELfCnsdoBt9 cgd36QbYs5gFRhoPrO5IE67W4au+UDvVGSleO8ofVgApOuk0kifnMItdALRTHvZ3qrq03IDZLwP7 PCu79V2rSNijRr1gePgONJEx+0QWw5EoYLF5IhtCdag/rd2HNTtMvHvp34OZ/SZ/CxpAjAF3Dyj2 BavhD+bZl6wbA8V5I/wioGhtotv7PZtNLryGm6MnlGVjfz32lD+Yj9+VtpXT2LujY+x6AMmObS9Y eH8w652l/eVke8dnLbQvOOV+4FPYB80sD4rIfGwy9PkQnez7YBpWlvHEzdZtzW92QhEioiR0CAES uDKpEBjTTVvD3bzNrYcfDILattj8i0Hh9Qr4C5k00r8/VJy+4aFJgefBrUXkyhqwLZR8vKgWymjG PJA8lu5vUNjnEEtMGuGBZlIE1dcSzqj2mC20sT+aYmzf8in7lmBA14upoTKZ8gbFfnFLHbo/qdYW u3Qobvp/AB3NawplbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjUzNjUKZW5kb2JqCjcxIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNTEgMCBSIC9SZXNvdXJjZXMgNzQgMCBSIC9Db250ZW50 cyA3MiAwIFIgL01lZGlhQm94ClswIDAgNjEyIDc5Ml0gPj4KZW5kb2JqCjc0IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQg PDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjc2IDAgb2JqCjw8IC9MZW5ndGggNzcgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1aTW/cNhC961fwuAaaCTn8vqZNgQZF0RYL 5BDk0LpO0CJOGjsp+vP7JM5qrbUi07vdiPCBoCVKs28+3hOHH9Uv6qNK5LIyzlGwymVLIalgE6Wk bq7US/VePf321qjLW6WHv9tLrNFksg1al3/tZ9GRNU4nFdlRcpm7y2v1bKucGdbKsL1WT783pJVR 2zdqoy7U9i/1fAtrFu3pTrHHePI+ODXY0y3Z80ptfrhQT5zavMeQ1eZTmV2V2Q0GP167uujkltdq +6LiRxwBqtGGQshGRfkRNaA+OR+oRsPL3tvRnjpQvwNwhtVGAPytwPkGA6AWjBEK/UwB1WGQ2XHD H+UNN3gYHHbvfcc5rKvIAhOYAud8ANC9LOjuZkGtw2YDqFvMShM80jLwQ/aUrOyGrEQW/FmcIXEv HoK/6oHrHlk+TAykY1y0szuoHifgBl8u4xYTxWAfi5sE+IcSfu8KihjOiFvK5FnvK0TJyGnAfU3g MhNrVNtdxZqzR+0cOQacAPf3CFw9YiNRdXVEBbDIRNMMYqwtJR8Pa+rUg/cRMwUqXYaxetbXy/+j zr7A25PafC5UKKQptvDEwL25lZ49gvI5OTLMh0guUn61BBmKb3ekJNKBONgwlwuHuVkriWbI4KGi Nkq0kAPlCK22JNFKbj4OnyMlY0iRQkwV4gbcNBvqUnHHa0Nw/4QI7GXH5xKJ1/0U2uL3Mp2KOlkp zxFpMvyz2/wqz/m5H43a/FgeIEsuMUMOyMqpcDzkg7s5tzNH7Lgtj5FBJMvb8qbpLWKV3CnXpu8V 0+Qpck1EkVwT00TFyo+Qhwn9/zN5O5afMXVB/zlB6EoozEXmKpkCHWCT5zl7Dmry18mUkIlTqMiU anOOKLT7QuIz5QyZ9PC3VbU9pxTa4DVFreVbb0qhq4SPM+R0nC38q4SPZTLG1VTaan+dFD/MlHg2 u1Zxl7EQ03nWnlXchc9ttsG1ku4+O8pup2PW11U+eULKz+qYNeLHg8WsnzVnjfDxIZIOvpmdOO8j 5TBbDFfxlktQnTvympLFKu6yGVpDt5PtVpNOO/JqINsZ5J7dbHqtEj/GkNfNkAVMwc5LO/vuaAFQ NlX77tVa4xRt6BIaHGDTOSm/Rvi4XkXbefJao/w4bBVr24w0dN5TtmhFNfJp4Vyg4NqJHhshNdoh L8cJWqMd8nKm38Bvh7yczoSMb4a8nEbrNjVDXjZrtJ3bIS+bwO25HfKykcnqdsjLBkvatENeKIUU TTPkZfszFaYd8rIWbWBuhrxgCqRGO+SFDjlF1w55WR3JuXbIi3Mi49shL044pIRDDY20rziiBx/a IS+Omji2Q14cNJo77ZAXe5yqyu2QFzuG2DDNdHXYWkLKN/PpxThRqHUz7MXGQWtUsRfa1S/RRDVh PFI17dNKv1V6sd/g1v3ZN7n2aXIgTjq6crKIJguksbs83O1AT+983huK7va/GHH0UY7iSCt47BYP 14bWc9fv2vT27k73icHTVvKuy73UdLfl+IgcZZmiwMUaXDtj8xnxruHPJcce7BDBsfsTLT1cUyyX Z1/2wey6VwXm3emDu0cDuo2ALgunNtmC3etzYmcNviODiQfg1e8W/weL6CIyCmVuZHN0cmVhbQpl bmRvYmoKNzcgMCBvYmoKMTIxMwplbmRvYmoKNzUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCA1MSAwIFIgL1Jlc291cmNlcyA3OCAwIFIgL0NvbnRlbnRzIDc2IDAgUiAvTWVkaWFCb3gKWzAg MCA2MTIgNzkyXSA+PgplbmRvYmoKNzggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgo+PiA+Pgpl bmRvYmoKODAgMCBvYmoKPDwgL0xlbmd0aCA4MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBzZZNT9xADIbv8yt8zB4wY8/3lS8JbpUi9VD1UC2LBAJadun/r8kM2Sa7CkP4EMrB mt0k8+axX3se4Bs8QESbgKxFb8Amgz6CNxFjhPUKvsM9HB5vCJYb0N21WcozGikZr3X+absKFg1Z HSGwxWgTq+UdHLVgqXu2hPYODs8INRC0V9DAAtobOG1FzaQe9RY95NA5b6HTo6b0/IDmfAEHFpp7 CQmax7xa5dVaguv/Wy1UueUntBcVHzEDKmlC7xNBKB9RA/Xg46CSliw7Z3o9dVBPBBwxNAXgr4zz SoKgLoylFJ5WIFS7UFbzwmXeYS0vk4Tt7DcvYarCBeQZPac0ArTjAvW/C2oTtreA1KQryTuxpeeX 9GRXqs6V4oLrnIxS9yVDkq96cOqV7YOCRx3CpE416h5v4Ca5nOYWIgZvXsutFPjvXH63maKED+QW EzrW2w6RHTksuM8ElxhZS7d97lj79MBzIvuCK+D+9ODqifWDStUNKoGFFOjLEGNtMLow7qnDDO4S o4xK59B3z/p++R599kJ2j9D8zaOwDM2ihQcCt3IrMztj5HO0SMxjkpMjv/oI0jVfNfNIpD2yN36f F8berD0S7RkGLzW1/ojmk0PLXOS4PNdKGFpzgOcfsvYTVQplbmRzdHJlYW0KZW5kb2JqCjgxIDAg b2JqCjQ4MwplbmRvYmoKNzkgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA1MSAwIFIgL1Jl c291cmNlcyA4MiAwIFIgL0NvbnRlbnRzIDgwIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+ PgplbmRvYmoKODIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgo+PiA+PgplbmRvYmoKMyAwIG9i ago8PCAvVHlwZSAvUGFnZXMgL1BhcmVudCA4MyAwIFIgL0NvdW50IDggL0tpZHMgWyAyIDAgUiAx MSAwIFIgMTggMCBSIDIyIDAgUgozMyAwIFIgMzggMCBSIDQyIDAgUiA0NiAwIFIgXSA+PgplbmRv YmoKNTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgODMgMCBSIC9Db3VudCA4IC9LaWRz IFsgNTAgMCBSIDU1IDAgUiA1OSAwIFIgNjMgMCBSCjY3IDAgUiA3MSAwIFIgNzUgMCBSIDc5IDAg UiBdID4+CmVuZG9iago4MyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEy IDc5Ml0gL0NvdW50IDE2IC9LaWRzIFsgMyAwIFIgNTEgMCBSIF0gPj4KZW5kb2JqCjg0IDAgb2Jq Cjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyA4MyAwIFIgL1ZlcnNpb24gLzEuNCA+PgplbmRvYmoK ODUgMCBvYmoKPDwgL0xlbmd0aCA4NiAwIFIgL0xlbmd0aDEgMzU2ODQgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBlL0JYBTVHT/+3ptj793Z+0o2u9lkk7DhSsIRiGaUQ7lBCRAkEgTk EiFcxQMJKoeIila8D/AEFQkkYEBaI6VaDwqt1npUpRbxqFHaUmqFbP6f92YDaPv7/frPsjNvjp15 87735/t9A6GEEDtpJBLRp8+ftlC9Vz2IPW/z7/RlS+L3Lfz9MkLoA4Sova5eOGv+pCf/dhEhpt8Q ovxu1jXXXT2+ZPtCQhyPELJg4+yZ02Z05hU+Q8iKUvy+72zs8My3/w7bM7BdMHv+kuWj0rmV2F6H a1Zds2D6tEfWvlRByE38npvnT1u+UP6tfRMhK/n58WunzZ/555wZU7F9K99euGDxEpPJPAHbT2G7 beGimQsvyxz8ipBGnG/txD6KD/+zE5W0YR0nV4g9DM9n/MlEwTETNszEQqzEhnMdxElcRCNu4iFe 4iN+EiBBEsI5YfGjCImSHJJLYiQPV0yQfJIkBaSQpEgRKSYlOKcbSZNS0p30ID2x1Yv0JmVYl+OL pyN9SF/Sj/QnlWQAGUiqyAXkQlJNdHIRuZgMIoPJEDKUXEIuJcPIcDKCjCSjyGhlHwnjG1GeJWE5 xfvS+QW+X/J1Zk7nl/w4X7Ovcf3W7JeQrWQ7nUO2k1fIAXoCv9pB9pIW8hs8zWDyCLmR3EvW4ukn Y89t5DJ8FOy/l4Y7W9DvLRijLeQQzp1IbiL7SICGOr8iK8lq6R38ajVGKR89HksWkDvoyM6lZAr5 VL4FzzWSXEsW0sbOSZ13dt7T+RR5muyVftPZgZGNkOn4HOr8Vnm/808YnSlkE3mQfErvsezG008k jTjzUbKIPCTVybRzVucP6EGC/Ax9kDEGh2gbS+PqM8kXNERvlAbhKk92NnUexFk5pI7MJg+RfbQP vYQllCmdozoPgWrdyXJc9UGyi+zBp5X8gnxI7cqJzqc6T4CWpRjhlRiP39I2KdOxKlONcVMwSiWg zDA81y/J6+QITdJX2QLFrpQpunJ957vgh96kBr19Fr88Tv/FbsJnpfSaPLTzYvDNanI3H23ya/Jn GqE96Rg6gZWwBewxaRE4rBS/7U1mkDkY7wdw9U9omu5hdnZYelJ+Xj6t5maOdjpBkRR5mDxKXqUO PGmcLqY30/foX9ggNpU9zD6T7pW3yb83TcNTX0nmkzvI8+Rf1EP703H0Cjqb3kjX0rvpg/QQPUK/ ZBex8Wwe+06aLTVIv5AvxudyebF8i7JGuV39MjMpczDzu8y/Oss615Bx4IdV6P0m8hiebC85TD7A 51PyGVWojTrxidMEraE34HMTvYM+QbfSbbQFdzlCP6Nf0b/Tf9LTjOCjsihLsHx8kmwR+xm7lz3C DuNzhH3D/i0FpXwpLfWRqqRaaQF6tVbaiM9u6c9yRD4sd2Kcy5T7lMeVrcrzygHlhGo33Wwm5rfP PNnRreOTDMmsy9yX2ZVp6fwz5DIMnsqBFFah99PwmQt63weO20HeoXaMXYR2oxfSkRiZqXQubaDL MZK30ofo06LvL9L9GKU/0u/QZwfLEX3uwfqwi9kYfK5kM1kD28juYS3sPfaDZJJskkvyS92kS6Q6 aaa0RLpOuk9qkt6WPpY+k05JZ/DplK1ynpwvp+S0fIk8VV4qPyZ/IX+hTFHeUj5Xrep8dY3aqv7N 1Nd0oWmsaZypznSXaY/pXXM9uPNXZDd5CRx49o8elVZJQ6Td5E5WLofZb9lvwc9TyQxpFAOnsq10 HVtBW1iBslwdyAbS0eSEnMJYv8YeZ6fYQGkUHUEvJ3NZb+OCqk9+Dq0q+VekXd6PZ/strrxctdOb 2HeqneyihEET019LveS09Bb5UPqUmuQt5CPZSoO0nT0rjQUX/EK+UJlEEtIj5EWpga4gu9kQaNrT 5g3g49H0OeiF8bSMfi91EomNBhf1k/5CbiHz2PukHXK8jtxPZ8izyJ2knN5IviDPQCpKlGvVbqqf vsHmyOuZl7YQJm/D01XSAiopPnIrrZMeUr9jH5Cl5LBsJZ9IL6D3h9mL0ij5hHIZnQ0JWEHWkIbO VeQ6ZZL8ezqLSHQCKZSPQrvdKJXJCaxXQqtMgU7bA+neBz1wkTQKe0LgnJHgixpoiIfweQB6QgYH zYGMT4QW+y1pUcezVjJLcVJoHULktzKXkcmdz5AHO2eRazvvId2hD9Z23ogrbiWfk7vIVro6cwNZ CMvwAWR7pDKUHVaGdnZn69kH7HJ234/pi9EupCHyNT4vQuNfqLxM1st/JJeT6s4NnX8AdxdDwz5I roIVOIan/BZ3uFRqI+WZ0Wxn51BpIZ73UzKu89nOPGolszuvIWPIfvK0SSHTTGl9UM34i/TqCy+o Gjigsn+/PhXlZb179ezRvTTdraS4KFVYkMxPxPNiuTnRSDgUDPh9Xo9bczkddpvVYjapiiwxSkqH JIfWx5tS9U1yKnnppd35dnIadkw7b0d9Uxy7hv74nKY4/900HPrRmTrOvPonZ+rGmfrZM6kWryJV 3UvjQ5LxpkODk/FWOnncJLTvGJysjTe1i/Yo0d4o2g60Ewn8ID4kNHtwvInWx4c0DV02e/2Q+sHd S+lOm3VQctBMa/dSstNqQ9OGVlMwuXAnDV5IRYMFhwzYyYjZgUdsiiQHD2kKJ/FTXEYqHDJtRtPY cZOGDI4mErXdS5vooOnJq5pI8uImV1qcQgaJ2zSpg5pM4jbxOU14GnJ7fGdp2/oNrRq5qj5tn5Gc MW3KpCZpGq4xpMmdxn0HNwWvPxY6t4mLewZNWnv+0ai0fkhoTpyfvH792njT5nGTzvttNMGvUFuL a+C3rHBo/fqhuPUGUGrE5XHcja2undREV+OWcf4k/KmM55uZHML31M+NN1mSFydnr59bD9JE1jeR y65L7IpE9L2dR0lkSHz9+EnJRFN1NFk7bXDOTh9Zf9l1zWE9Hv7xke6lOzW3MbA7na5sw+44vzET g24cEy1xOm+NuOzsyFLeo+SwJh0cNT2OnkxK4pn688XM/mT99P4gAP5qKX7VNAMUmdNkGVS/XhvA 9+MRaZNSqCXj6/9JwAHJ9m9+vGdado9aqP2T8IOcT86yWhOd1tVuSqebunXjLGIaBJqijxeK7T7d S5e1smRyoRbHCsNHxmJsp9UO6InhTyQ4gW9v1clV2GhqHDfJ2I6Tq6K7iN4zXdvE6vmRtq4j/hp+ pLHryNmf1yfByS3CSfU3mVNn/7m0gHfI7AFNNPB/OTzTOD7i8uSIcZMnxYesr89y7YjxP9oyjvMB xbjhWLbV5B00SYoy7OMtFpXEUTDllMlnT8HGJHuTXIh/qmDqGa0mM7hS7KHxoU1a/aXGstaaSGRl 5v/1o9bOE/xXYnXuZ9nHaBqQznbU6HbTwB9t/6h79vXSiPFQOWzE+Mnr11t/dAysZvRyWHYFjifj JyXig5pIDSSzEP9aO9v6829ttEnHkOHIeEiR2F0bzW7+6MRo9ke1+OPc2b10KHTm+vVDk/Gh6+vX T2vtbLwqGdeS6/eyA+zA+oVDoO0Mxmnt3Hd7tGnohlqM2Gw6AOLByMVcjAeNn5R9ckEWzt0gEzfi UMncQVUIPF4TubiF0WOqqZU9qHuJIh+TiNUkH6MkbFaVY0zaD8NvgRvYg4TS2qmqjqrR2smqUR1V pBpt7QwWvXsl3Al3IRYUZu9MXGo7oyvkNInLbbgXuVJqZj9DXKHAc1+6F4HG9835hRVKa+f3en6q pMKmWmFqZEoURbV9azGbJYkRk7nK6rI0WpgFo6j7Ha4KyydUkqsY1R3uChq2NzwbSqMjad4TrSNd h26gQxo+HVVYULenspJ/e/ei6bRX6lPul8rFcmPZoe4f9z7US2qmwRMnMl8ZS95Pf+cXcq3yDmKy PNpbX1uc2z+XWWRLLpvoesn7Us7r3tdzvs9VKfMTiyz5iEVR3QQ2TiMWm0mLWu0mLeRwmbSg06O6 g06v5As6A8wfdIaZP+SIMH/UmiP5otZcyRdyxFR3yJGnuqNWazRaSCw+QiyOUKgw6PQFg04/K/RJ EtFMhW61le7R+zudDofVaiHRUCgYJFa/z+fWLnSaVFViF5LQvY7gvY5Cp+6uHON83MmcSxPWe6OW e3FdDN5ud2UcWqCVbWmOb5vNSViXbj+mHTu7PsnHCyTFMjuCxjhqHRhKd2VPLNcqPdIrtINre4T4 yvWTPwxxXV1D0JvsU+5N9El4yyX+LfcnpYQ/ISW9Ccmb8CZmTdz2+vDMd7TnxPsm0oET75+4/a0R NJB5e+J9EzKvTVxKB4zI/DpMn9tE522i2zOX8++mzKZNmQn0ucwEVk3ngWUpmQyyFQleSul+okhU +RYh+Ko43UgZnatyrsCDtZPqdsEBvXsZpF/XQxDc889/Zr4V17kxM47Vg9YauUC3Frko0Twms6a1 0vJm8rjTjLXuNj3uvJJImhSXJOkF96MbxKU7TrVrp3D9qmqwPa2jKeau6Ne3X7lqwsevUfrppt+O mrx/1XVFFyTTNJ0Zt59+T53ffthx+kjt+vte/kUmL8PJce7+M3V7MSvWmMWqUeKx8B5YH5co1i3k celKJ3RZi6axGjS+b3G5RONYi8MhGt/oLquV1biceSD7C55sH9P4+0k/vUnirihK4VMegJemsY5V kIv8C4quX7V/8qjDmXH0KP3z/r33rZ/8+9MdH36b+XvGLMZJl6azP2CcQmSNPtxGbdYojVplq8Xu dGluk2qjLMR9PhORJXPQ4zDB4+NeoHAC4QP6ZJNkplZVsRGixX3U94oKLfA0mHqT7lCeJrrbW0HC 4YUYWy7Mo052HONqpa4KbOcJVuIfyCjWfNW7F6nz9gsE8RCqqW+/oGoKBE2pItVU1LdfSu/x+KVe erfkm7W6x8rrL1iwfMCY4f2XLSlbJW+/s3/J7sHTN1WU3tnN2WddzZh1dwyvuasHIBhKnst8Qm8B LmAlo3dboQyfR9fG6ikqVTFGrbSKWJmEDaL2Nw0Yg5hpASKAzdBkm21bHgA/nKw7eUxrF5LDl1q7 1iEYr3evcmgcH+9Z3357Do2dWFbZVzp0qOH21KjwNI4cXURb2Vw2H/q3VA8vZAslNoqOwi2ThEWU hTghLC+8gw/KsTrtOOk5qh3P3kDrvH0S/otYCW3dvRvkwWn7sFiL/kukUA8x3t0qo5M7iLwZxzfL op+n6oRMGN3ad+jQIf5bID6sErSVyOV7idT5yS5fJWvt/ESP+yrvlyiTHpd2SExaRiiUE6QL51ml Lwn7Ery5DbeXm6/HCEBztGuGPHAtUQf9wOUinfbTckq3bcxMCivf/IArMFID/epW2iBzubRmJ+P2 SbdGYrLiizkcQSj6LwV/84Ye5gxucRM753gSsNuxtPN9pCeY+xAWhyDj1RiW6E71P690EldSa3Cl 45AU0fhWD9tsaLmJxvcQzW7nS77v7CXPXbNFjYe1HIjeLha3/RIubABfD76uzqP6VbK6lq2zrXO9 4VQsJluIDfGO9A8PD4qO907xTwlfFp1nmmeb7r3GPy9cH72O/UxdZrvetVZ9wHSf9kboQ/ae+p7t I1fk7IMvtuiJZEUvCyUWDfZuY557MdfbuhN744CzGNkYe/12oXzS0D11DWmu3vij07oGwFX9+R/F t7bWq3n6lpcFAh4IuJrML0p5tUB5WV+3lkrmm9Saee9sXrZrycVz39ny7nV37912443btt104/A6 9g6V6QUvTG3OdH6YyWR+tf2Bl+ijmfu/OwEMaO63c9ZwXvkUBDwN2lnJDj0ucRs8T17J7mIPmuUX ZGohqsIki0LtjL5pFb238mciNI7ftnYeFRoMja91tyBojiAojBoIilHWw5xcXTQR9InYFR1WH16C MRK9FBoHbsaUsG0fraKr4Yxw4WhIQ99zfYc/bBh+STVXG9zy15G6dCLpVlVTH8hhOTvdctE74+// rOcS+YYLb8x78ZI3p/JnqwIvm/BsMfp6lpcsbs0R8nrVGkdr58kWt1s0vtUtmoZWzKfEOIsG+Qmx GD8ay3HiSAwMimUre1m3M2swGM/T3IzF8+CG9Hz3EF8eIj3beU+r+fIgAuloVgz4De0eDxM31C0u N1rGfY7qNo+X1cR8fB+/9i5cmouKzcZq0PhGF6P43+7GZYTfj99N3EzvO1AZqL6svKK+bHrd/EaO aZi91j7eOc8+w3m953rvbZ79ns8jn0dPROyv2F7ysqiWo+VqMU39JUBOE5jfjLUF1IrErJpZVd/M ifhyciLmnAi0hTmSIzliWit7qnmMm7pbaWg3fwIihsNFmd26OPgORpvzOn2ZrQLerdH+ut29uxpg 5AK2kslsHyuA63XXToPZoVdOpbl64Rahqrq9o+4YNwLCIKx19kg7oWq4kYdm7JKA/qSO1i2qrS30 J1L9QPG+fftUgPWFGoZcQCHDSKsm2XSmHwsWPvnQd1sfvOHmR+he7/e/e+fUpc8eeGJKbPv2i6qm t9108POr5/38kfXewx98vX3Sc/ufWjeNo1+UTOg8LgfAK2lamyWdLRzSOR+HcgjlzJq2Y4OWJK0O l90Vs1pL/LEcOVaSo5Q4kg57KAwjH4fyYTVxU4rTkZ+e6slV2qGe/EM8ldXVMCTt4Jf217TXPJXa wXQZ/4Jd9GLFEXAMcaxxyEPcE93LotJlgWu0ub4ZgaWO63xrHOt9t0WfdliVuASh0202u8Mpmyju C3PzVLOOB3gZQFEJcdA+LXa7Xw7tY0+RMJutF6GXCrrp8CyeGl8QZ/EQ5+V4o2lxSminFCUpLcXQ 45Mv8SOpjd1DrbT/rvA7dB/tD1PSptvO6avSVnpPlorpdkFHrrVOpoURAiVBSDycJihqEBTCCiUG eaUNtTDxXGsJ0pn6nW12UZGT0RTAkiTzUxNa8jbNW7njiRXlI30e2+LWNXPnbPC1JL5+cfmb866e cfPGzJfvvdpJbwk9uLbp5hu3+B5jy1dMv/nWW+O7X5+1a8bUR3rEfnFnW+afx0FbBgSYyBp8SyuG J6X39Uyyz7Y/ZN9mf8OujJRGOu6VJQ/4nNhVyaRYbZKJ2CHwb0oyXHVZchBmd8DbeZm9DHie0c26 lcgyTiFvWuVWdvVLimLVc/MqrF3aEA1unFgNGt8KK2Vtpf10h0nPT1aYGhN9TBtdMMcYV4evgjCN xZmE7aPiN2gc28PpwHY7W+kGMdbfQAMKZXiSq5gq7TgceAJWOll1Cm48H+bKyrU90rLhwWPAEYDv JQ7YfU8l9Ny7uq28UsrvXinJublV/BK1IAfO0X123VZpbxxbaddTlfb8HKy7V/IT0rUI+frQcjd8 fbfkpuy+jlvZoz9/7bWWTB869Wlpz5nhT2e2QLA3dcwD63H7n1CegZ6dYMjOXkLxfA4+CDTHaY35 /Tkerj1tLlmO5TiclJhCsBnCKxANIWfc9nM54TYQbNRxELLBRaPEI/SvSyxHRK7LXZ97n/dZ76/s 79k/ipot3pCzW0Sy9FJ62fZBl0mQD81r9Xu83jedLp/T63O6HBAS3cs7ojs3w6F2unQ/zXbqJZdM 3+ECBM2mx3n33FO1BdpK7S5N1iAmISEmIUpCWoihs4aYhDbGPftpH+Kim8BU/Xc5d/83ccn7sbic E5g6EJDrPfGgdYjF6qAYjq0190groCIRyo9b/v60AR7XjwQH0uLl4Rf8AeL3meANpGp+4X/wmptb tm+YuKF4253sg46Xxtx6dxs1L7nj5G86aKO2/vaDTzy0a0x1gP3thcyyKZlTv3v97l1HIRqQjVGg nR96L5d0o2Oymi/PRfOQDpFotDimO6jDAcMYVfJjPoc1RkmhhkEw/DgtFtS42Q8KvRcEgdDO+nGH 3j2k/bqLlnXt2sE6Tsvu88J0sEn3Dw4Pjk/2jI/Pk2aYZpjnembEl5iX5qw2r8l5z/xuwG2Kcxko MqRCrUkKpcd3JcQBEz9QFE/GE/yAm/dyrIOhn1H6zlROSig+S1ef4dX21z1kd+FiTZAS0ZiGuAtP ceIl7itqG0utXNXFaKUeqA5ODS4IrgzKQbimak0wwG8abGUFzWnDVYMstnP7JfSe4a8Z2q5nHXfc OM24AHGNV0sRwwgHDUENyOXhZiqZT9xaP2wFqO+cNlSl082h0mHzJlxUcxW7aP+slo6fHbn1z5lj j9725faPO/qNuXP0oqeeuOH65+TLnXN7jep14bd/ml6f+dfv17ffhBTOjXTbq1sPnPm47rna1sce 2LEDdKXIdBHYs2eRg12oOw86qIx/zCxboM+4JPZiVLbYHYsByfBBGSNMtcQiLvNiy1/JGFB/KpOq sVpAV8KJDEMZCcWPYK6uoWrUyfbR2inulfEIgVvxSrfQQxiBBhHLqERSTcm+Hk+/adLuDZn2EX1d e6Wb/3Gb/MP2DZsynszp1o+206/p6ygDQJQCHgyDB4PIkvdixODCFjuJxnpwPQl/jNX06OFJxFSl OOZxxCx2bmYRBJyEqkQj7eKxNGdENAwHijfEQVcIFtMItEWDn4VGloGlAr+d+1t+cUW/YGB/loGN aOS8kAQ6Kd3OgadsZPKS6IgIQnhH0OAdOSYiFN4Q+7L3524wbntGz+cn8tty9uI35Ev+pOeer0to cC8qdKLRExEbcRnq1ydASwLDAsNSx+1f9VIsvZBmW0FvlJeYG2yL7Esd1wdvJ+vpBnmNeZXtVvsa xx3Bt92veT35kJVdOfEIX8XjPfmqexx2/6geK4nbSSxE7OjG5h70XE9ii1+xUEsrm6Vr6cUuPQ7P H4iKS3MxVyu9e09ZaHETgmgc31Ww2N/l0Mf9up/5N/Y+G9qchPSDa+AnZN0ET2VdT/5w3HBlZUbo urpFDaShtpamUn0quISc5w8Q7PH6Al3egyqdLzx07sJrjr/S9vW8+WvvyJz64IPMqbuvWjNv9urb rp61bsCwjZev2rr95pXPStGSB+Zu/vDTzVffX1J6cN3+TkJp212v0vGzb71l6vS1t57pHLVxzDON Nz+3letFbtM4T8agF180ooeXbHkwA4VuGIFTgsjcGggDj8YJvZhTNOQWJHWLKNQdcpembcUxjuKM cUpOp4+MpVQ4kw4N0QXl1gZqVREUP5iuKwOL1bWXiYEB5TkjalyPfvxrznQisD6vE+fsp95NGFC3 4OL/w11/fK+f3Ap3OncjvWJAZGRAT14RmJi8WromMD8yK3l9ZEVsQ+T22EOBbZH9ka8Dx+On4t4L Ao8FtgekASUzVFbEbW8SzBRKxNV4cWyMcyo3tDn88eg7Yw2l3MI7kbePVhIbdLL7x6Z1YynX1C1c UbvP8pJbdzP3xqzuBb7JTShnJa55z9rPLsVL6oCkIFgWbuaFrE9FEde3WBMwE7KXPHROURE4+AUv LdweuHHa5SvG9qV9X56/5ww1vXZX+w3X/+2JFz5kbz29ZPmubTeu2EIv166/duTK9xfaQxPmUfP7 n1LtocxfgKN9kWl+8RWp4uE9Bx/ZwJUuQ0UEoWtQe8Ox9/7wJVA3ZLIwtUqWqqgqA8GBb0NYHGOx xZxFmRq4/kRMIEguxMHLEW189wLMkWoPHTrzLEAdZuBZ4tqoINF7LrbdYvu57UnbCRtgN5qy9rMO tU6wzrTutn5mNdmsThO/p6lKVRWnbHseDuhYPalUyaIbq5AiUE1VsrW/bYDSU66WWVym8hZXV5eq AH0Bewfoxb3Mjo52NDkCJjpJtDe4kieLGro6ehYMO5SFw7p63QWKCXu0kHwmD0RlAWqJdPtdUiNg BUWVzEx5mU3GTolN3sV0dR8dCxd7rO4nz9Pn4zKLmOUqygdsqWniZIGUVHHLQ8I9I6Pa8ReKZPuV xRD7UD+l/oXSW2cyEmOrttKHmlG/8mozuoCL/KgPjewuGR4shc/PeB+Q4UAfFB1+3FiiGH1QnwdE XKWSiDmuUCXbh+N16EHVqHbeif/SB0r78H/ywDN9JHqmU3qLrcpMa6bVtKo5czXvB0OlE1FqlX3g EiedtYcCcWU1cPz/3pJtfC+UCvac1Gu5UuH2Tq1RxLKn1kubZZ5tqdfWSRu1N5TX1DbthGYzK7Uo IxqrzbY1af+w/8PxD6dFtssO2SkhXa/IMuJFs2oy2dE2o14GGCHP0rgEWhM32X04xCQYqO91WCZY yLhs9+FXlpiimGOqpLayhbqFmO1f6Ywyto/aoDxtusceJzNN0mVjUZbzqSxtBBu1UqrbxtrbTJ/a pY12aufbmst02MRWmhpNzPRz13t/FPhqQxg2Af9CYKxIWINEh6qrIu3Vx8Bq+Mcxx67UBF8LAUG0 s1Y7eNB58OBaxViDF0c02S4f0RRDOrNFdklm0z6AGUhFcYtSSxdx/5n/JYFaIm+BjIXEgWWJlf+O Tfr4+Y6Ht3xA//bg0PyccmXfD0Pp/sxgNpnet/dnd9zOaSWhVojIX4FWbuEhe/cSGVS5hKOLsjw0 OSF5dXKx5VaLOieyVFlogVQqt9jUooBFChV1iwVyLRavJ9atW0kJycmNYeTyACsRcyil2jnyryJS 1Mu5R6J6uAJXVT72qplfHU3QXPVxB0EdX5iy5/Bf2K38PDvnDD8/yx4pzY3FKZeQOD8OqnLTlG3w c7HnByACZxtA47ixwnXQqksPnMKlyhginmoDa2NjFEJ64w8qgGM0+MI0IR8H/N7N029UoPYChyt3 J4BMdtlqJ0vSRJkB0KSSCCPL+nFNnEL7Ppba+tbiq2etvmti46sbMj+nF6zqP3zE0Jsfy3xE51+Z GjR5wPhNGzLblX21e2de+Ux50f7GWTvre0uXuQNXjxq2oOT0ZpO9/7yhl10HwIaSqzu/UJYB484l 7+yezubmMphV7vqJ5/tSn8pbcVLmmA6pX5LbSG7N3UgeUp6XnnbslVocrzuOkGO5/8h1Oz257txc qZta7O6WE8+7xDHBN9E/ITxbmZd7g+d2z0PSg86HcrbSp9hW9x+cvNIzovm0iAzZ/GRXcaUw5d2L KzUXoXLUG7NL0Zhs0VKu4SQVh6WP5AVTcTM1w8dUa8zh2HSMNk+H1I3iWgxLjoEh2nVz9YW0DbJt oEmaLqJBVU7mF2DgPAXlZTKSIYgjVOb3ebgLJLccuCDzq8/bM398eAcddOBPtHTgK+UHfr7tL1Pm H1/z5GeM9f7u9Kv02t9/DjT+6FvdN9/zROa7u1/OfLV+P+dphuo9okwGT7swep/rPeN5dJDZ4E+3 FnMRMzptoXkC/LIItrJYOU9ZAB0ZbjdXElBLkbxc7X9mvn+BCwVxvu9ivthPmS/LiNxLzDJd716D rtP7SlGTWTUrZtksq+FQJMRUmxWSYJVUf8AX8AYkNSoFE9TjxCJkzknQgNWdIBjHdLob/lbROs6j QeTHEIIxcGhhoiyLIRaBLx+j/35+8k21SxaPvv7uQ6szO2nl3U/3HjLq/mtGb8+8rezz5468KnP4 4LOZzLZpZdv79h7y1TPH/9UtBh58ArqB19XayCbdryoxs9lkIpLMBd1qidmIGXFqm56reSpM46Xh cWvcwawRh2z5n8eMS+6PBdY+8AqDhYR41nFYXHDSyWPps4OWlVTkhNwACrLfJ+SCM49J6TN/kG5V 9m3PVL+QcWzncgRnV16NZ7CQO/S0eIa7TPTsY+ARHokjU8JYxPY/9Fu3CU0j2B1qJvMf3bdyknMJ MP7O9R/ZwaySqeNa5vy+b5U+PvM5a+oYy/s9YHsHN6KUzIf874X8F1KvHon6on5WX0SvNHupRyoo IAlPkBUSEIITIM4HkVI1GHNKiCEtlKaKCgtg2fFkRfUCfONBW9YGcx6HeH8olKawwVH+e7aosYgW 5abiVmoVzr01nJqepQUEeZRWJ7Qongjdh4I8C2OlwcrY5joTX45qg6UHy8loTiQnnCOp9pRW6E/l pcyFKKErDDlyEyTg8iZwss8bN2ErXylM0BwbeNvnxiJmSSRIgYQFOFzwOHfPsgMKhge3A2ztgwKD 8zUI8qk9GFQIz2X7PDKUSD+3NJLNvytzZPP7mcdbmunYjx6n9J7UjsRVexasPvCzRP+1lN1904kL WfULtOPoosV76ZXvv0cXt8xqvbfXwsZR424ds+7xg5nvG6f1o27QA/X1Sr6Qhfc59timR7z+ClmK WaybrUeszKowZjNDhuPIJHNcVFg9+DxAQTHgqgCQcADxA9eVKuVjrtY1An1iNkNeOCmtuOj/zdJl GVBYUDDgeTonYBg8e9xB4wCL6h0LHfLA2hBwnC7zB/ULUmXpCJhV1J1UVyFWxW6ungGHohqm3J3E 8qkD7IcDBzpUZV/HM2zyD0NZc8cowZevgDlXYRwk8vZuioJBxhNdzf0vEAmv5vIKY929l7EuLjHW SVE209acGzO2QxGxRlynVcSVjcoOBdwKp+0u5KibiNwT2cOxSN2dIIonjp0biSTyaWIsAVQansA3 XZ4AR6ENl0AX40ziwk4+Ib+HAeh6fI4I72qEW1dX27AImfoujuJQMxfHcvcrB7iLBFr36/xCmoZn dJNtujaTzVKXsKXqOsc6t2oREtdi4wLXSiO6TY65LJaU1WpO2Tjgy3smGrxDaHANIRqG6eZ7dAG8 2eriXhr36t6x3nqv7KUpUBMpFcOP+bpLr/wpa0pGePZ0PUm7Vtdg+DPci4R1bU+j+6K8gJvOvn3w IAKGSw3cYVo4fdjc4gO1r9786iG6ObT1xkGLb5L+fibc+ubcT7iOge+nXMZ5mmb0mJTfr9JsGVBk 7aP2tV5inSitkf4omZZZP5A+gCHiHpkwj8XKBnm98pz8tVmxyrSP/J7MK52O6hZPokKK8wVch2Z7 JQpCOo82Y9ucXct8nZuowLqt2RPg+z/RLwjjnoWFF5gt4fAFEF4Lam+tiiTLccXqQ+IBRVVxkwrv XbVaicJkykw2lMJbJWZDPNPKBugu5Fc3K01Km3JUkZXhZr7P1stE4/DGm0wSisPW6HZbPI7H/f/j Qf69y4jbB27l7rzBLXWIyRsA8zSIkLGKlx1VwXms4s4jd+h5Zg/rkMhVoCynylwF9z0E9z0K9537 1u/3rzXAFr5xotnu5uN1Qg+ioWpOd4VZc2oVFt6yapANoQIBkAvvSfSB5zXclnyMW2m4Uubf/Ggl hOOTPQE0A5Wg1CfIvFaa832Vsu6r5MO8uxBNv5H5MB6kll+YNiyqSxMeQHDupwmKfyb3fQfY+9TU 8SC7uZN0nDoBBVDC/tjx4pkH2PGvM7LQATxm6Aa+Uch83U4ZtKBCzDzGbmXP6i4Tgyj/j+N9qovT zzpN6n84TcfrDMtvCGnCjw7+HoL6D5h3EPUBzMNyoS8aO9aVmzF3njL0pNnpQO4ZNg4KAg2M0rd6 MW/ZPVzSFJddsqBAxGyxOYnZwqw2Vcgv6iyEzP6wRwivBtE83lUHYFQyYc8ZQ+dwCIsDl7wCo7qt TTtypI3netNI7MA7S5OuIo88k9BJqlhKYimLpSKWoNLf9STXWkw4FzCb3CY7+dKIjq0iXoLDZQTP +MH3eh7X+SkUL8StngqXWCh2iVAnXDMzfDT+4PyaosEvZX2ZTcCMLo1N0B3E8GLEjfA8xmUJB2TT J3uC3zHo4GzjYZDa4E8j/gyWjOorCXOZfSxqlpfZ19h/g6G0D7MPc0klcqGj1DlJukJe5ljuXOsw 25hirnT0dY5hIySkRsyjHBc7rQ+wB6X7TPeZt0rPmlQPczmdvRQGiWdm4Iu9FDOaZvtlrsuojnDc bLZYbdD9TqfG6VTvafQwzz62FZmp3ruUOIreeutWu8Ua1+0rUeq1Dw/ppDYcYa0I4i2AdOOuhRpF jn/CS3GlXmlUYE7Y1mY3N5BhXgtVVxWCaRRxOtqRsxvH6hC1YxgEQpRdApIR0fvaFaKuECvo33NB +i+IvfM0Kg7eAxDynojRRzTZoQGKhQZwdH6/02nlkXs2ifnunkSlszQhEpl7+lU6y/qJ5u7u2JtN VqZrEeVDTjn2BwtNA8G+/WgCZhoTs9wPYJbIFb0CYeQtqfJyZsKOzCRl3+m/333p2IelMz8Mld86 3Uc+ejouZAXJCCUPsmKhK3Z6YIsMf8McsgdEzuBLPcFbZgAlcZMZStfMTJJktsiMWUxmWYoDbUPd hrC6aGRdG8WQJTgjeoQzm1IXt9G4bayt3rbQ1mhTbGbEA2Aw5Evh3Pw/9ELWv5GF/f6Rf5MN6K2c ZF0mHWlj4dE0CPV81qMBzIgqmsq1co80iNOlbpE3fQla1hzHAjwMlcqdS1ChxawPrYQWbtsztNKs lxnNskoTdCwPg/eE0Swzmnxv0qg1syUrTU4fvl6+fXKPF81co5mLpp83v995VulmxUcID4hYTrmf Rd2PvC6xfa+fyYBkq+SVIFfj6UaQCjHsdPj/HyvvYj5dlLypj424qE/z+aLBaFSWNdlnC9qi8rbg HudrTikYDEVZPFd3j/GOCeqRScoky0Stxj3VOzk4NTQhMjF6e/BBpoVjkuSJ2Sz+VBwBEPc2uLJD w/Ce0Dgh/A80vhZaAw0D/UfjB7AG9Icp0phLc10pTkVV0MhQH+GcrsjfCP2NWAEOJ1DE8yq+EP57 NZIok3mYKrz3fhqgaxR4MoT/ZDpdR/u+RYc+35LZ88rhzL6tv6G5f/yIRq/76u7fZv7I3qTz6aMH Mk//6dPM5t2/oZN/mflX5jCtoNFmavt55nMj7pc7wN8OVH3u0ktnuuf52AhthO8K7QqfbLMjT+Ek wRAPX4nZkzKDpcDtopIO6vSkLuIgcyQeofgXCTni9H/j1q5w8D+j2fD5xky436O1BjE4fGC6UCfh fSOoEUF8DCAISyTcCOh5IYmI31nJPaOuuaf228wbmXX0hv2P1Y3sfWvmNmWf0zNzz/yXMx0dL0h0 w8opt/gdBu9sgZwDZsIo5NMzesJjc1JP35zJeVeb5+cBvuFWwyyWJrEsAO8L0ouiMW7zOAAn9kBJ GA1Pa+dnzZ5IBdYnmvOLKpDB+Kw5t6gCWWaxRj5QrHH8/ebclHEc54vjWPPj+jA0Cp3Dc4bHL7dN yZmfs8iy3Hmda7V1net+xzZXq+tL5xcuDTYv7nb53G6X22W3eDCPMhKwqshuOOxKyGIJBCPhGMrH 2oyySBSVJ/IFRUMhl8tpjqWcj8AFMgoy0TglzDQaR/V8/mSqyp9erYsXLCxoLJAK8kP/K5UNfv9v OinJXcSfBP3ZMCt8LARCC8ORpXaaZx4qe4p6sGAlLwfjFRGwr2cDkrNWVtSwWM26q9KlDXB7BuBA LW0QdsMJJy8SrnRDR3nwdeo5lRocPi0/D9+zSodbiy7oEuiQNyn1YGCopGAuUaaU2MLWH3z7+jff GVVcM7Lz5IGaayd2T4z4M92y+r7R9z+Z6aXsG/Ob6x55L7ewYPTSTAPtfeuG/jZTx1KpvN91l8xe w/2vKcgj/hU4RS/m14umS9PlxdISWS4s6iNV5gyShplG5g7JG1wwtOhyqdY0JXdi8W1eZ5KnArjy AeMZjcKuRqqrUdTVwMmgoXGy0cDJRgMnGw2cfEofyk8qdqQKWIFUVNjXVZEcXDik5+T4hGRN4TW2 uY55zqt9M0PX2a53XO9aoS0tWFy4Rlpvu82x3nWHtrrglsJ7HPe57vPHDHOhd0+kPNFUxJIqQWhG SiIeuax3ChOvGXF0vy56W5RFCwOO7rGiQlqoBGAMT+pGDiPW3RKLBSSh9dLAQ+oMaISv6gB5BFE9 ZnxQKlJY4HTYlASQySgmHGK+oUoLC/KxDzBVtHsEV2Q1d0ETtWMWtwB6hKXVaJyOpfV0IWYOqAhC m3Rvd35LBbdGj4dbUqSElnAl7nSyGjRO6g5+pZJIGZ6JpiCh34hDaGD4oALRyKZKULACkoZ7Z4Gf ulHHwHPIXwjU/Byci/q3NFJodemT/IkA7uLpBGIOo4ocpWBgsUCdr7dfjIm4lOuygiKR+ua5b14A zzFfvy8YQDEKx9eRvSxITXnJMfU3KxY8d/nYKQMz14ybM+umv9/75L/XKPtc27c1bansTz+Y1Hj9 mtOPvp75x4P0j9q1d0y8ePHgIbOSwWnpfk/OXPDqjDlvr3LefueqK8aUl88rHrh72dLDi5fghQic V3shbtkHvWgit6GIn8Uw5AAAMdUTJQCLm0UAQ+lLapyynjztT+luSvmAQJ/oNs6wxJzNPfxdaEcc +KwLejiDPQLKzGAPb+CK5j0PnnNWgPvBtdQ6jtUd596kof7FBCSUxifczJvJlddnoopj+/Yf/mH0 dwt8AI45+cgHujXlmiRPMr9hlgNc+QXgS1XIA81D5eHmZa5nlC9dJjthbpS+tKgWXwrOh+GnoZH1 05iARrB9VM/hppvVxQM0HhgbYPWBhYHGgBRwCPCPX53DUFYRLiN0MBIuosG5BY0fDDfNKtw0bBsw FBrZKM5a5+du2jmViJoiAIhZ4MLwCcQklDSQPMAVhi8gkAtRMuSW6w/MyJx+97eZHxYeuGT7ivf2 KPvO7Pw4c+bJO6njK2nMmV2v7L7qgKjuB65LlKEYIyu9MFvd5VEoYClu4wEZWMwKZUrPj1FjcMhd Xo5Rrwaz8iqTgp4K7UaKpUJrT3sve739NvNtlo32NvsJoAX2sXakTm1mli2MsFA7Qipcsrpa5Onw a6vFEjcrPkB+gJTiTPExplhwq6/iVsQoM810JoNTgSLI4sqxZtpo3mjGNnKFDqYXV05l9C7MUWeI T6jujitjFdYLcclGoBgnFAWxybpmWz2MCo9NGnitOP+GeCoYxiQSbkcmkcMNHG0wZjZlk4Q+xBi7 iAuU+Nsuiwc642+7EKLBxUMcgr9anFaMUKSvCEVQ+orKe255EF3U1SaQQBSRRTllF3X85vd0RY+8 /O50w2sdgMVO/7Fx4fLlcgngMa4g8L6TZdy/oB/pqRKScpd4UqFK0tdd6ekbGkYucQ/zXBKaRCa6 J3kmhrQHzA+4sgOpl2s0Ek77K5QK+2BlsH2Ef7wy3n6Ff4Yywz7Pv0RZYr/B71L8PIb1AOZxMUFH 0IxTLSg0aGVlFFiVjEhRNWHwrUDkLQ6ny2XH/G2PPxAMhVCoU9WMl1jE+drucfO1PtmPMAQIEotT 4qModlTM5pg/5PP7Qx67xRLze9D0uDFrI665fZrm9ljs5pBfcaHShTB0SZFCKAW0AJDCZBcW8njc SHRGgsGIdpGFjiNxYsfSj6+O5Pq4PfE40mPhcCu9fafhHNRFwqM6EFh2RMIdodFDZg4+ftYv6Aou uU8ARcqVqfgihBklQhhO5HPRZnYLCnatE0liLKr4QrTOX4DYLhDbzXnCY+VFPQYHFGJnt3MckA1d ndjTbNcVHSdxplhUB4bwGgzh9SDi9CK/jMSCaqL0scwNr39aEOmP9yJ8/fsxyZzux3+VufblzFtF pqAv8wZktfr+TX8tkD7piGS++cftLdKLCGzqNsRnXnL6SaGH1azM2uncPYAcJXkgwMIvmj1BDgp+ oTvRkMNYSHyBQ+83hwSO+L4+EA25GAtPSi4xd7P2dMqz6Wx1tu0TVcaMfUk1myyqalEli9UOfW2J W20+K3AdSbUgwjsF7BV7kRehEFeq2m0qhQmgtlYW1i2YpoiaCmJ2trKQbrFbLtOtjQD2W+lu3YGC 9DiRLhuDiSNcaHfrSLIQsEkWdbYJsyCq64RN4PYWFiC0x+E8kOCCnBaQLbcAKB43VqA/Rw5R5cxZ G4RHiXPaDJFWOIFFay0vBNCwGNEUBNFyQKIWs91il/d1nkQd8ElRjSlsLhW+okXggvAHgbF+sjPM Ab9aYYf5IuE+J+BuNrDjrW9oYuyQi6+kOZ91vMTmS6MyQ2+8cfFGuuNMc8fPDfuD9/jITZBzlDns 9GAaX5vuwvyZS+kl5kstktVss3SJtdNOnA5qi9khkTEVahIp9Q6jpCGqp5+XMcoU9ZhW2Wy1poAB F1vpv5FnilMZsihbi205FZQvQP73m7FG/9/XvXwvfqLETCqzWWN2KPSX6W7oHxkEiBJTL7MOpTrc Xg3MJ4Kaa0UdR8IObnNheUadhJHlqUMUczZUYdboGcibkelHUbkIx7kKhV6FZEF6hATRRZz1gYhy lNXC8hOVNJSoBAd+shtgAAaWD2RteR/atx/mi/qpKeEvYd+NvfTMb+XImTdqpa0t0vMzhm/ffsY0 azv6eXtmDgth/ExkqJ6WpTRlmqKmickDPjOpL8pKIcJowStmiwXzKvCTF8yPzuY+A6IB9LZrbqvR b8wJRbIziaL12+kdqAKcYxq36d8fbDJoVZSZQ1vEvar1oKykTaom4WVB1KMqsIAvylKhCaz5DXAy zpsvWB7m5UaYhfyfN6GJPsAm+iRoS2bxBx/QOzJzNqlFuAvt/HMGbyjJ/BW5HzinFKVeEQXT/QZd xAf8WNdsPwkDkydvy8y5+WaOYwzv/FLOkS/Emzz6se56qcVh6RZ2RLqVOLp1Ayjo7xcd0G1YtzpH Xbe5jjnd6nutd6wpeSjwcGSbw1/MwzjuqcC9x7w63nom/FzxnvDLxQfDh4t/7/+42Dw4QDGl6aSO ykC1xgP/uKuMqA/3c2r4dl4wL5Qu7VZRKVeWDpMvLZ1grk1fbZ6TXmZfiwkS/3b8O+3uV+Gkstaz oCJYlvCFppYsKGElOT2d1c67MCu506k87tzh/A71jWJOH+TAyPOggSoVPrPKKWoinSovgkVJoIR6 6uf2hDZhjhEf85N6RLiGQ4qsZTmSrWSaNo0gCgUVChOIgL7pCoW+MVKFBTKnEA4cw8OLxkkxCtjz J+6FqjUF4kbYNnzOglZ2he4s0vk8l3iqV2pHSqmErAofHyHSe3t4HJDqzffpjhhKXCvbKtnmSlqJ KPqkfhG/YrAwlN+z4BX1sMry1GqVqTCoiJWFQlNDvD/QlegMXyJ6xsQtLEWWWO3d/xwah9RIexr5 Ka7t6s6W2IDH0p9/ziOiY5jRZUyh4XIE2WtvgKHjtk6ERjx44PvFnADSUMgDAl4pi1IG/kG5Iw8Y TEUXIqBA/BDwo8gxmEyhENsJ0IRnv3CSVDVj79wd+y9ZfGmfeR/OouVD1q28LrcpdO2R29Y9N1az BPP35wSvOrhgStn8ObOfSOXeUjP0+dWjV432OR2RgkLrtd0vqG0INdw+Qp82vMfyE6dXX9Cfflyc oxWP6nlp/RVjLvgZhI2RNeBpjqPy+aCN+sNUsbsKlD7KEEWpzmvKY3l5qLbKuThnYd7GPHWAtypQ hXLTkZE6c51jkqsucGVkrvkax2zXtYFrI215H9g/DH4Y/sz7TfCb8F9yj+Z15oXjSk9XT18vpdql KyNdY5WrlQ9z/yn/oNk1v1OGdo3mwAhb/TlOW6jgiI1qNh1Ya6NNNipabIJLbSJZB/iGZ1hENuOE 4CIB6HA+ReOoCFn4Hr0np6htCVBJItiPyCKIKZcKGWujiDQ30yZ6gsp5qPMbg4kTPLPJrR8aZ/Rc zmBUMAsVQQb1cGaBzwxmwRnf41TROKMH+K0pOApLH78FDccu6fejUIHzxSJeZQBQF0EmZwj+B2bh LIR/oj6L8woc10WkAdMky92IKAGcaZhYVYS3F3BWMObP0e7PtizaedWOBj3z91/sn8cqau5e9sLT S5e9gLTWP+8ac9ebizPfZd57lN73Ss3th9468toh4Z+M7fxSaofOitDJ2ZiiwrnSRV02ytPSC6H/ ZE+OzRTKkfFWML/JzJ/fJJ7fBBQAbWCKWPJUSvrQu68JMADzQzAXrk7MhbvEYqd5OYO8g4KXey8P 1nvrgw+zh6WHHE9pT0XsZkfYOpfNkeYqS+0LHY2OZ+y7LXusu+32ANIsf2GSM3+qa4FrpUtyYWrc c/p1vUSuvB7d2ojk+VHkzC3E5cK09bN9zEHXC5xmPtzO/CiMTIEtnQf/BR6qLkikC/pcKqgSEVQZ luMvOGyieaZqlDQ6+UkmKz/JJFSsqXe04mA2suW5UKMyZFH2nR1iclT/2vZFJ9Pti8SzIzuKKUBa 3TH8EwgBKFeLEjDIN7BfMfP3LBrAaSdV7cz97sUPM/9a9NVt2/+UtyO8cvK65566de6ddHXwpcM0 l1pfoGzVji3Redf86p33Dgg7MxQ0+xQyiTpGWqM/ZWWyo9BR4RjsUPr4+uRMZOOtl/kuz5nFZigz LdN99Tltee8qf/B+HP7c+7nvu+Bfw58L2Qvk5aUjXGBHRLj0oqakwNEjMID1cYxgQxxDfcNyJlon OGY5Ple/CPxATzo16pecNpTHRcEPbrzfAgo+VM6L6F2FmnbETTUUeNe7G90QTs4Thoi6PVx2AKHC cHFF61Y5B+G9GjAK2IuAnY+428lHHNvfCjlF43v9Yk4d9xJPwSuoOP3U1GmSOYnGIM8dEywndLUJ s9I5QwqyCdNkEhbIFI5VjD1P1uoaRrWflS8uYciAwTtFqVI7cn/4npM0nn9K9OH6GArZIBikDjN8 zkqa1H/mwZV/WDr33Vvq7+vZ3BF/Yemyp7fesHzLmsc2nH7ycSqtH3cRc6KOxPP2m6++9uHbB7ke HQE9GoOc+UGzy/VgHsnxwzuvU+osNbaZ0jxlgWWmzYxwjr81QozEMf0y3srN4csizwfKD75TEbm3 Z0C4d85FnlGRi3LGeTCPPQcv2YxMy1muLvefYqdCGl7c6HIEg2MDHOmQAjmujdpmTJDS5GiO1UT2 sef4dL4ufdYGacC444UYdJMXEh7UAYv/ScA8aBgTHtEwajTQaNMtRd0qmlDIE8nDVnNhqoKv9Yu4 qc2jeYFyrcCkF3Sr6KIUEr6gjkEpPAjahoBhajkETNTxcEqdrxXr0qM6jiF1gDhCoGsCQuElLNkJ dlUdDcaLYzi0IYpWRXa/S8SMJIvPlBDoCk2IWVuqdOW+0m/3foU3m/j+9Ae82/DMl9Zdq6dv6PiQ jbP3n3DbjdvohOCTLZgpJ+FFgsWZTzL/1uI79s2mm9YMmv2M0JNeELER2G+QOvSYz0Jd4Z7hXmG8 FiL8sP0RxzaHOeIodjSF28JymI9IcSSvItfskOyuHCv1s7TPK0sqsT6Ot2t0enU5WCijTP4eKCY+ jL37V/C1ns7Jq9hIaFjnghLWHRCUbOBVLIKufC46pFT4U0J0uAImPs77+D331ETjOLKWovGDmBNH ngyF99N9JEFO4c1xXfEZ19f4w7jysEyrAt7SjuIDHqbBA2/HHDBR3ObD3BaLSTXDT9KQoCBu1RWl yCV2W4VXk0BSFnH3ubwP3q4CswTFxlFOP59puuvxx72RW5aNnBLtX3bZ4MOHpYc2NMyrGDrR86h1 aP1VG85cDZm4ODNO+hoyweflLNDrbTbFV2or9I20DfGpltxwbqkt5StNVtr6+obbhvommCbZZtt+ sP7T7+yRLC26MHlh0ciijaWbS019E31LqkuH2oYmhpSMT4wvmWOanpheUl/aWPph0ZeJb5PfFbmD AdXfyna2FOd4TcKWaHFApNySNJI2cgRhSytboZcpOTku65D8HLs14C8vLLcWhkJHglQL6sH6YGNQ LgUYyGpKRTVtUCg24VcKxRYUio1PMhRT/r82FBs/i086zCo2NM7ow7lEB5e4aCHJzyt4xXXY9amr 0yXnuapdY2DqhMy4oMUwBQ4zzLAUGKYxZZbvV2tc4XTpkgRXcOnRXeU6UHCYUPMTHddx7BTQ13aI jphgc8x4Hw4KkxuCvIRWuJFFUHW8OJkTENGQUVB1/vysq3fYygYtWbEu5KTLmj46ce3v7th//TMz P9r8y68ffGbFjVu3X79866TIuMKyGZP7Nd1Oqz5+gNINDzSemfv94eXPS91+1/bK27967VccS1uL InxeY+uj0/biZR1tzX7gHjx4EU52odwH77/c55DFrgHBcEXQ7La7fRIwTleOYvKhULjQopf3rei0 0DYLDWCEWU0AKgzgR7FY+riAIIT9RnfzgcO0CQyiBal6sReVMlxULD5OEpz1PQ9C0EJBtNg+hRoY NEYL0DlY0beiKXAiwBYGNgeaAp0BOcB8iGG5nGrowwk8D5CwI/BCZOz8QahU3tCDQkoN1xLFi5DQ rhT/D4ZPiEnouA9eQoqbk9H+S0DGs3EFLFM2z5/OEjYrp+KFItxSwVBxBEVIp1N1mgqdqj1KHWbI JV54kE6vIhBqo8ARFEWyAcUTYpqU6nevbbmpbdmLI1qWzht7RxXcwr/fU/fUIx1T2Za1N1x+54qO lyGT60AoHILfZyKH9CstffkTjLFstGy2NFnaLJ9aTlhMxJJnWYj3fj2e3XXU0mmx5uHdKHiHKN4w oko3IdZXMEtKNRXipWGPy5vlJrlNPiqrbfIJmRE5Lh/Bliwb/jKrQSM7bpinApLJKIHBUmg2HDM0 GxpGvgGNMzy2x7SN0eafjh7KHUW+IftuKR5wcTOxqCEt5jjBkq9raWmR/3r48Gm/nDr9IdR65xN4 s9IA8cwe8gd9CLAKZaBcjpfmKkGzophkzC1SvIQ6bEzy2fF2HJuJP6FNNeW4XRuh0YGM4i0DhVbr RhvNs1XbxtgkRBo/6P04J9iMEisRLNhEZGmD/4IIBNNGsDTz58ArIMALtrDXtz3BH+isVAtPBfEB 0B0OozaQ6lE8LsBTGSXIBnhaXr5WMyPJgGJkp1lzpcwa3gBlcZqiKCvmHMFfSVTup/24vIvMgwki v6YlMzu/b16/vi3lF90/TP7qd7/79w0POofdI085vfngqBlcXsEL0vcYFxubpkd5hAybrU5QJ1sk l+Mfyikgj11TX4zEObB4owHhMhoQ5S91kXivkX5mZR417hXo5olmTxFHO0+0YO1BThE7EmKHfiv2 qDIQTrWf5RKQQu1unWT9mbTU+qH0F9X0jEqTaspUaK5U+1uqHWMctXKtOslUa1khX6c8aHlN/b38 nnpM/cr0L/XfZr/HigJLSWa82hLFllakSMyFRo0l6i4LjbpLKxhW5gkPGTPpzJBYgndBUBcmnYMX gbHkI5fh0hNxER8IIMAU2QgXyFZIWCHiRQJ0aAwkh9e79hayLyjOX5QD2RecTBAkQtZFQIH3jnK5 D9sdf05ccvX5tOaTsXneA84P5qTzeTvn8ulwUJFBB4jH3wwhyi55/aUJZDdXSWKZTeY6RmC6h+VW iWGGBy/+QfQB/ucYn9VSmltpMeO9ESgR+GRXLi+ffHdXXKx2JgTcx98mgdqrBpTuiNS72tm2KyGK hHYF+OqTXZoousRKbNnFaqfN+DEy9lBW/Faej2Vq9gVwN5+vSixwr1O7QvzH3+yMGqejxMvAQDDB vsEoy8TLqJIoy1zXQp/7KjOXvvJJZstKQOz7aVNmWccMlnd95grOl7dg0U/I61/2KEJBgYPamvv1 NwquK/oY6169jbXxHsM2vRDmxoWisMeVTxV5DBYnFClPWYgSuU4FbzbkbxEzFDy/klD0fng2jxPa hkCTna/teZQP2nIZF4BAFkgwaG34Y3hPHajcpbLQ6OxKmmZ1Fxkt/1h3gVSLBBIKL4yrLL7F/3jB 6i2AO418FGyomoLPlKSv89p8o2oJWLLRgEi9r4+yOSoK5WPyMcufg5/HlT8op+IsaI4nLaFo3CJJ yViO6ucuhYmqSczWsx4ppBsLNxeyQugxZ+FGvBhIFjEbikxEjAawjrO128cZGqEZ3qrE1bObcaZ2 CzUGtxA2FMeMuiAev2XjGFqn20OFG/FGOnG5KDfO4nJRcTlsf6u7+eWiwkpGReiNvRnDOEeB8Kg1 2Dbwv2grrhcgrDxZSI8QyN5mwvIwEXcM7BX/jUGN8+VPaFwSEPLHr5Ily0ndJ5xkYUYA6AuRLChs pcubf6qBOV0wN+dYV2E0SHIe4IeNDpHiAj7DnWd40EKIIa48fdplqJGyS/ns7ij1OPxdhjobvIC+ fu49I/+EhWGuhR99vuHeUvbM3GX359305mPPNSenXLjw3pZJM0auGiCnNo2eetWkfTv2dBSxR6+Z OmDTUx33s13Ll4996O6OD7iscJ/rOPglQFfoXkVSvWyr1qr9RfrCe0I65VVhS0/oVWCY6zT6gHYk dDTUGZLjZp/TF/DA56JqwGF1OO3OgpDws0LC57IJb8smvC0Yuqy3ZROm25bPiSmANuFt2YS3he1/ GwS1CW8L26cw45SbPuHQ2WgnEhujkbjDZBPueYVOhNjC0OZQU6gtJIcww9MfELJ5Ci/6MiTvnAie 73AZInjO4YJrDjE0HC4D5+O38PzUgRsdFFPRhbzxhUgVCHQXqun8P/4CQdCZ2+CzXlhAdVusZqsJ Uwe0FPCNKHVZPVki8yk8UKd1DYLKWSxXENYg8donln5cv2WsZm3pNu/Sxc/Kqft3DFk4qmxFx2K2 5tr5F93zdkd2nt9g4AdFoKODhOm8PXhXKTjWy7MGvIGKsy/1xbwVFgc8JmvYfol6qXmCWmuepc4x myu0AZ4BgT6hIdoIz4jAkNAUZYrlMq3OUxe4LDRfmW+Zoc33zA/MCP2M+i2q4rhCQrLaeoX9Gmmm MtN6jd0azJFNbigNX0FURD9RwQgm+GYGrGMSgE4WDOR2nQscDp8Q/RMNTgnR4GRHo033FhRWYPoC MWmmOGCd3p9CS/D9wzicgLazgOAVliC3mFGL1zRxg4pOYClghKzcCg3EXz8ISuu4JFcIjPSOcFhB ZJeyBGwHqFCHlyyeo6eAWduhbDnmww2X5XLlcstVylUWmVsnfqJXvOAFb+cRCN75YdHgp2779Uc0 cMNfb/80075319o1u5pXr92Fl9oX3bks8+eOQ3+9mcao4+233v7dr996U2Dpa5FTSoCGHryf5ir9 TrvWXbtAG6HJ1fGmOMuLl9iTuWX+styLcxfGN8bNA4IDosODw6O15ivsU4JTonPN8+xztPnBedG2 +Du+j0MfR96JHfMdix2Nd8YDSTmtpf195AEaqmS0ydrntr/mZjSb2wkIiEPoagAQOnGGC45YqWbV rfXI98pxQcS4ICh8t+N4pxNG2ypIiW2uy7NvvuLUFN4dJyIaX+pJPtzWJdRbzso9hYT8d+S8CzAX GjkLmAvA+CxgfkpoZIGtG4C5qC2DmgQz03AeAHN6fnGNoYwBmP8ULkdkxGWS69sutNzbpVhRcCVe F1HkxqtGzqJ4a58acM/sdUfmLv30hsl39XA/s2z5888uWbwzM0f5xfpx4zZ0PvBk5vTtIwd0nJae OnTwrT+89eYfOY53aWaOdBQ01EgO7avfaWNp1i00kI1g19nVan91eER4Y2xzTKnwVkSrY4O9g6OA vaPTvdOj9bHG2LvqHzzH1a/sX4e0EpZvT6Nyuo99GBtqn8zmsA/sH4X+EvgqfDx6hrnwjh9fBDir U/UBlyPOoLMcL2vSjrio5tJd9a5GlxwTYARel8QhAgFGQA1kUVaXACNcAozAXhhTTkpXgFs/riyE LyJOrxb6Y4n7P1HWAi5oHE3FUuAQJiFiJoGam8K5sR8jEP8FYe04yUOxnxAGb0jFux4FGi4wI0AO P8JWS7vdX/OLzHcL3rnp1w1PdCReWL74mR3Llj6J9LJ54Gjag5o2Z2555s4fBknbDx361evvvvc6 RAt2bjWI8xro4iZv6AN7eqkm06RcIQ/Cf4BytbxEVi1us8VscXjdFgfB225tQiiI1VK8EXO68zFB zcvy3f/n+P6sx/e97j4vvkehrLBG5/kVgot5qhvayHD1R3su6cogCNUjQnzkB04u4jNlOdcipBfe QiXeyLHWKSZZ1C3iM50Nz8DA1TDb0736iQvnVF9x5YUXXzzwSl9MTm1puHTAs0WXVNcv6njXGIdq 5AZ2Yhx6SUH9Bjnflz/AMtwyuGBC/sz8Gy13Wm4teMb7fOkByWEJRkLBXiNK3wsqUcwbYloZtYam mKdYplin2KbYpzjmmuda5lrn2uba5zpaUi1FLl7SWFDSt2CytdY2IzWjeElyCcqKf259xH5P8f2l m3o9Zd1mf7LoqeLm1K9TASS0DY80v6uR7GoUdDXEOXycxDm8Ic7hDXEOb+Qi6NA9scrJ5qJCu1WO xFN+2dYjN8LTQfnhUj78eeHq8Jjw1PCO8OGw6grnhReEPw3LeeG7wiz8C1DHD84QqLcOz5wB7MY0 Gw3/iw2KYTS8MRcGp9kXqOBrnc9Fo7THlNxrcllujt8E74gnpAVAwadFAXHgatLLtaCc08OWh4rV grDuDVWU8Z/3FLit8HO5HQaGC4nBMs5/GY7zX4VFABkWyHcYyexdpoJu+OnunMoj3Shax4XORcOo 6hYNPg5ofL2Hi2q3iLhVAjh8fVlbGasuayxjZRzBLyDintlX58aNUUalBW/wDvCG8Q7XeIFLKGGX 6J4rLjQID2bQRWgJMRMrCzfmf9oV3oZ7Z2F6CHoWmuIvSNVQNLvo/2vsWsCjKu79zOxm95yzj/PI srvsbrKbx25CFg1NAjEQyUlM5JFqIsTIIgiIqAgWaiL4oLh8xQeK4OP7EB9XrPVW7OOySSAEsELF ImKp3F7EFqvFirforQX9UEu9yd7fzNlE7OX77s3m/585M/8z55w5c+bxn//jytxGeDL5/fPsTfAc MB9B1PDp97EvxpkZtwlhWh5gcoz/3GY4OBdm2UWFJWAAJ3TN0PI1m6PYEwsTudwZpnkXARX6cFjk LQmTYpjKlMaAxVFeJiuOpB2m4LUCPt/iho7rLcRXosmK5Jo1YIcN/3GLQtAuGrFcWZYog/+fGuyk 84n3+UK64I1y3QTeTSUaetV1d6+6Y3z88QNPtjVeUvHozB/8craecXctXnWL318ZXrv3ic7FB37w 1h/opZElty1qvrQkGK+atubKKXeWR5NT774pOGPOjNqSSEG+UlrduGrO7C3X/Jz3V6XZz1lF3pOw kwYdawVtsCTB+R/YS0EkDQOk2GRWqI34NVgiUzB821yqVgwlB48Rd9OsU2qRW+Y7l0Pz8xGnnWD+ 9BxUQPc5jzjhIwDMZr6AQ4SbWBaRz4WIBFL4ukyk/F20NKRw1qU1M+PjP2Ki70KGNbd07ma3QPpx Qg94Fd+wKfEqhVFtCHid5L08dtC4HXq80+pqYVUIs6x4gNdfYjzfIdBr0ZeV6MLSF9NC362/funY tWv7duzIT5YX/miLNnnR82zheupcOvTw+sHHrxgLM59Y56MvO8H9n9G2XSSEupGxgmexfD9XsThj Vhu+mmQ+LZXy/W6a73dhf0VHNZFqfzwY4MuKkFizBMRqJWDwbhv8dyw/eQ0ExGpFsO/FOiXg47WA 4xxXOCAWnjj+kouUO67OBui+AA1cCZNrcHXAlyihMyG2PPRcKBPKhuwhsKZ5jmANcyvRMfmIfAKO CYZZnDxiDR05rjRWKhbX2WIKy2KNIgumsHzl6G+xBjBgcFXoJLeW9c1fPTfDjsG13ho7BPsvZNe8 HtXD5UW5kQ0sSOzuMPFIusUKhP0MTI5QRG5/swwvBxz/gNgrE6xBW8Oqt6/7cZvm2u7Sv3fVVRsm bX9m+9Rb28Z3sccG+x7+zpSrZm58gNVxtineD16S7RTej0I/yckOBPIkokgO6hgRRy7lDTCvMnm+ VDKfpIV3js+jpFivU3gP79HrZCw4aySOIMT7SR9CdMkiBMXvTbmwqIaUA+HolCmDp0P8QDg6bq4u vxiWBIBU9xhSDhX1OjJemUqmKJ2wo5SSZsk30hvZYmmxfAdZSVeyO6U75JXK/fR+dp9tnfMB6UH5 X8hm+VHl5+R55Zdkp7NHeYP8WjlO3lb+Sj5UviZnlbF4HCVI/Eo54ea52giYaXmm4a/JQ2OqyXHe YFmb8EcnuKezkB5EZ61wc+iYB4DvyNPEpJYLaYtUlpfndqELrHwvCYltwOHk4SSpHBHarlXAjYzL ik+WFWwWgtcopHnzoB3OdcW5UKcTYpyE5lVCaLFYMk3T8sVBwztMMLVgrYCGTTnGTFrs+uR3/OuF 0ufg3MG5oeCnJ7mWBj7XuhHJXF2wF78RvQXbEF2nkE/6ps1ZstNCVBYysvTfhpa+cjIOmbO/7hr6 nj0xuPamZR0r2AOieaB9cNnXnWgfhr1gWF/Z4DNU0QNZYmECo8KOChPLGF2hfcCNLesxjpEB2S50 ZcjA8MpjuimOFd1GYeTXifpWUR8et5AtdMO8LXyy6ULwL8eEwikYeQ4f1o4d1o4K1eWchLV4Pv5o /IMI4yv00Qr7GIVN16/VN8BSLoZFsdbhxnzFwG9FUOwZU44W1WgR6IThsz5j7oyW1tgdbjnfEZZH G3l2Yne4oGctGRqBgxFnRAq7CrCWjTsrpKS3hox3TpQmeZttUxym8wqp1XWZOkWfblyrzjCWwH7q Tcadjruc3dIux2613/jC8bVc7tLLSbmnzFuulhmVvktIrbFSuk/abHvC/SLdyra6IDZD+h27vQfB +/6DfMp+Sv2LcdbxDzniEhpgboE1gb0CqwIbuYYbVryq3SC65ARzXI17+XLO67R5qDuOPf9jZi3v qTxofxU8Ai+FvnyH4tITSlLvsM9Q5uhL9VX6g7qiK3a0Rv46rBfDJ7fnC7NXQtnaUqOBBCV+1gwA OGxik48LuTvzIJksYa2iaNCJG8i2QrbdwLxlmnmjonpj+3UnTCTohpHEbiA2Zrx4z3GP1wdtaQmM nqQiQQBa4pLvuW8F9uechl1SdbfXI27PQF/OLfvwj8eADp2XKL4vNQ/lJkTSHptngL5oKrE2hS5T 7uHy0OxqU4al9GX6PTBdyI9cWh6dL3jGUKumL+6gX+Z/iYERQrijrzg7d24QNhPwzz+zucELS73n vjvM+PH1/T+E3p2QeefAhXY5tGaiM2dt98TcMfYyzDRSgDd7ZDsZp8ag3HRCyEkLBYjWTM1M2GGQ skd6nNyYbao1UwTJ6mohDi9lT/Q4Y1aqgVRucm0XL6gf00GUjf7qSK9zHC+xl1zCuEFIXGmkcFEa Py8gztNh7kKJ2WPcxruQqBe7B97s0X6jjowF4APvyeds/xT/4MQ8EFr3iAlNby59L6Tu8wNC9N5W ZqOtQ3t2v9Rgr35p15bxl/ZvG9q+56Ux76CLefqkfoh9b3Dzm4fZjV8fZ6t2/PdbYixSMRZ9hr5G o3/MjUWjVOpywGIHRBc8aJOqmJerlVD2562SW+kK71QNqkLUmW+ImO2j62arm+ybJJgJU/fl7XPs c76pyqrprwvZ8uVRnpA2nk50raEbXFKlcY095Uy5ZnmfoJuVza6dbMB90HXI+xvtuO1t+d8972of Kcbw5+VyE0NXgx5ML3CdU9jsRkx1YP+XwC2Mg3MTuVEh1E5O3+ZGeAxyQkqaQrqfC/pjVoZR3UNV 1aPBFAjmCC6bW1McsNyqaAfIAZlpOedENuY5gJ2puBv7lG4b1HZgEtgB3gsMnCttBjWmeVa7ixV1 gUNebULYP7zTdLQ70sIk4GWmN2ZbzYrb0G9P01eJBevcs9aAgfFC+wg2/oV1Cj7HtrQ8hUx5bsDg LkW4qes6Vb1fEu3Uwq9Jr/HGi10qjCd8G2q7N1hQB/bv+6arAHbKA7BmHhDH2GiCAi30sUbVUQij y1DzFG0FKCVYqKifuSkMOtWYnU+oreV7RbYyqtK1Q09+8OOLI2Pjfe8MPUofeu/4xKGPWTkdOjdl XFP110Puwd/S6amhuXiuIsib/A1tJES/yrWRAsWnwtFnZLRqOFyOfNOA9IXpjuXayujKZOi9UPAw Nkl4IBbr0F9Aw+lTIxT90/vmrZG6cl+nuk2Buw0TLyRWPq5G4wjmGQ2/J2iUucrcZZ4J7gme8d4n dVe5UZ4/1Z8yUvmpUYuNxfmLR93pWOG5U7/Ld9eoez0P6uuN9fnrfJuVra6XtT36bt8nyl98X3gG tXO+bKRwuEX5oS4QtqvN6lqIi4weuX2LmWApX3LVoVpoCkG5x8DsYbQvPz9uKD4cwOGB7o67FCyG FagRuaEYwp+fRLQIq4zsjbDIAGvYoaIuTN8A6zBdDYZpsHnGXtihGKBN/SotJi1hdI0dVm3BJNc4 d5vb1u7OuhlMRDb1VUIGE2VsD8dWoWtE5Q1y25BoRNw0ZFA7e3I09wnyaQhKXiIGsxNYPvB2xVsU VwsZ2eDkTQqdHtoP+j0v+psg+ps9sDpxiriyp3j3lWtWu4gP5gtq6xRY9oGw+qkdo6AwbCkHo/Wg r4GiA5pPfhnn/wkZ65zGD6YxmEVgoXKPb9LY+qkBPZHnGrr11feSxdHkh9uHljaWjlvVWTN000ta eWl4iVpgLx988vY1q1awJV8f3NaUmsnnweXoe46iXXnpNtMD4/hvSMygVZaKz29hLShQQydj5oo+ 9VVzOiJjWLlcqUEqXZlGL2eXS9PkNm0O7WAd0my5XVtKF7KFYL7cTbulu+WH6L1Q1jtHz7LwaClB x0hJuU76V+kd6uRfy05tVA1DB4tpyFGzBMtpNlFWGHa645RB3YRRbiqULeAqEg5lgYdgPD9rymI8 T3oVaPeo2zEc5jn2MGyswn3IWVPslIHf9xyUTLymd7437T3jzRPy/2AIQqq2myirKd1GaBv8LMHz KxFGvshoVesu4t0Gl13I7WTD49v3609C9YK/3EHOCqjXPsJC8SMhbMlfNnoP6PzkDMiACc+/eHQS O6CJDHW4gaxVexKvSxy9upPXIq9KQQgvFEIXiI9x7/eqQnfFCk7tDGPv2R++lE/PegM8B+qa/jqG PWkW8n/TsUC9xVFiqbdMqC4aVc5e6Jo11Ga7YfBXy+68hf7XYzbJ8djKwevulp/m7xmv2X0488A6 /zy1/gspLCGBkINLbnp3OOSSJNAW5Kw4GNvhqfhD6Jw8dCW5TCP/2DZUrU0cybHyCWlzIIn742Xv kOvsXVCtu5/MBs9qFQdbATGR91PEGxHu5nSguRrwJ0A9oBMQAvC0KwALAPD7TK4G7S5+rv3nZDmH vM7sYF4n2ZT3OrkR8Cziz9s/JFsddeRWHL8A2r12Qmo5Dc7f5Pgp2Yz0Z5C/EGnPIv4jhHNwzrhc XHY+DF/lncSBtDE4/yFAmb0r+wHOnw64D+W1I7wc0Iq8fIRNgPvp6+QB+nr2eeQjJD/Ete7n6YDm XDgVz3wv8htwXinSfoh4CNd1IFQBRQB8e/CvPgFG0ufQNHyG+9hato+dhE+sifag/b68ZxwPYrod xEp8tvKC6xXXX93fdW9w/86z1dutGmq/FtS69Xp9n1Fl/CT/VZ806ll/d8AbeCx4MFQYWhGWwq9G /lzQX9hZuL7wlcLfx5qKqordxf9ZcqB0efzmxESwRc3y9WOUiuKkI3lq7KGLNl0cqvzbuPR32qvm 12wav3XC0dqD4m23oRHYyEJYkWLYOagknXiHHvist+GYtxAj1yYcsIFCpl/Z0Tm7Odl42+IFS6/o EBQgypZxG2YX+GtDmg0lY+EJ65Xcn/2FvNlz39nf+LEvIud7sD/ff73lvb76W17rLZ/1JmkiF/RW j933dnjkngFfxh3wld4Jb8qzSAp+5q+FF+a5PR1qY7EtQE4DsgAbiQJXAtoA8wAbAVsADqLmUpYh vAewF3AG4CCmLdD7WLU5gOAhEfTdsrRKHC6wDufMFYd916Ss8IqrrLB5mkU20SL7To2VfHGTFZaN tUIjXpVG4X2Kp2pfI+SmyREAI8uBKXsNrkEovEc/ZxtFMgAGUV4rxbQZfaWJqi17bXYCxT+sSW8g 0ew+G+316FWNCsuy03i3UfY39qmVwz7t8+pVWxqnsz+TbYC9ABv7M34fsA/IPewEGoIG3ADYAtgL eAtwGuBgJ/D7E37vs/eJyt4jlYAGwDzAFsBewGmAk70HrLE/8mYlMI83ABj7I7DG3sVjvQussuOI HWfHs/vYf/TW1lXtEpFkZS4SjecigXAuYvirBtjves+NiQ6wD/tiyehzjePYUZIBoC0Da4AYoB0w H7Ac4EDsGGLHSBrwCOA5QAYAHgGwBoixQ4DfAI7BwsYx9HrHUMYx6Lcf6cVlBthbvYmmaKMfrtFf B9s0yg6zgyL8DTsgwjfZr0X4BsJC5B9iB3oLo6TRhXyCczSEGsJK5OexX/WVGtFso872opKiwJWA BkAbYB5gI8DB9rLi3huiBgrZQw6hx4+yXvKxCH9CnpeIeUvUTFyGNhbjKDHxUsSAtsS2JJiZ2PQk DjlKbHgMMY4Sa9cjxlHirjWIcZRYugIxjhI33IIYR4nZ8xDjKNHWgRjQAHt2Z2lZtLZtCY01qmwl amklamklamklDJ6v5D9yDn1ilD3dW1GBGnvKTI6piKZ30/TLND2Dpp+n6UU0vZqm19B0PU1fR9NJ mo7QdCFNmzS9B45TKElTc/u3DuvMIE0foulf0HQXTSdoOk7TpTQdo7XmACvqnYYPC0GLCPoa+XfF ivounVyl4h6LUKNFaNZF+Oz3Ar8FyIojE0SxYot4dCEPi/sqGqzjiydWLWucyvbjxP14DfvJnwB2 vKD9aEb7Uch+FKcCNwDmAfYBTgOyAAeoi/EcGwVWgSsBDYB5gHsApwEOcTuncSuMLAPmt7hN3Fgl cAOgjR+x/fgV41fEimD8N6Iltam2jZj7F9K2wmwhqyV+P7pfQ5fgTM3T/5Xn7195iNwosw1sIwwy R9kjuXBj77kCeBDa3JvYE20cRZ8ghZA4i8J5QoLGEV5CusTxeBKReHoNibCfIazqjXTiNLU3MRau Frz8rP7oucjJ6MeYpSN6KrIn+k5swE57o28j5Wf90aORddE3KgckpLycgMmF3ujumCDdFbkk+otD gnQNMp7qja7mQX/0B5Ep0SURkbHIyriuC0emGp2RmB2divKaI9dHzS6U2R9tiFwXrbeoxvNz+qPj cAtJK1qBmx0TERctKRQFXl07QG82xzo3OWdBc2eCs8o51lnkjDoLnGGnTzIkTfJKbkmRJLCr7VBw JpKPy4Mn+Zjoc2g84IM91KBFXEMPQ8WAyPs1KkHllmTyba2sdWYTTADsW0har49lvpxZMkCVq2Zn 8kqaaMZoJa0dTZlLkq0DzuyMTG2yNeNsv3ZWD6UbUkjNsAcGKPw+D9AsT7o3zL2yQ62L6vc+HOZh +b0Pp1Ik6F/REGwwJut1lzdfAM0XifObh1esCDETHvkLJgsym1pnzsr8tCCVqeKRbAHYMY9zt+27 6Of0TEvzLvoZD1Kzdtkm089bZvB02+TmVKp1gHYKOhKjn4EOLQYB6KRCEuN0JCYVWnRPWXRxnA+6 Uh6ATpZJXNDFZVnQ2Smn6+kqbWnuKQUCTSBGugRNVyB2Ps2hOGjiQKDxp8khQXPIn+Y0mcmimEgE JIVAIKEhEhEkERoSJOLOewRJZY5k3QjJOnElm3U3goYjFOM5MUzjOQGakWr8vyKLmsAj6JuUWjin BS7v55e0LALMzzy04uZgJn19LNazMMUz4Hk+Mf/6hTfzcMGiTKpkUXNmYUlzrGeSOO+fsufw7Ekl zT1kTkvHrJ455qLm3knmpJaSBc2pvintNbXfuta6kWvVtF/gWu28MFhrivVMEef907VqefYUfq1a fq1afq0p5hRxLSLaePusHok0pbBGEmEfjAWgvc4PF6Wa/NryyaLxTioKrg7vxoRkK3HBFb27pCnj AfB2fVHjRY08C98Uz/IiWc1lBVdPKgrvpltzWRqS9ZImkuy+vet2EmxZ3Gz9d+EPSd2385dh4SRP u+AfSFoy5oLmrm4C0xsVWL83YP3e43QidX5zCmkTh9NcrhasZ63Ei5E4kRPabCOEPK2ep8lyjvB/ twZxT0gW3Mc029NHzULaTbpStkxhawdDV9AxG9UA//a7MV3ig0QXhLy6u6DQ1DVcGn8OwZlEAsEj dw1D9+25WK4eunOhOJGf0jVcHcNFJXktkf8BLF89NgplbmRzdHJlYW0KZW5kb2JqCjg2IDAgb2Jq CjI1MjY2CmVuZG9iago4NyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5 MDUgL0NhcEhlaWdodCA3MjMgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjY1 IC0zMjUgMjAyOCAxMDA2XSAvRm9udE5hbWUgL0pOVFZaRCtBcmlhbE1UIC9JdGFsaWNBbmdsZSAw IC9TdGVtVgowIC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAwIC9YSGVpZ2h0IDUyNSAvRm9udEZp bGUyIDg1IDAgUiA+PgplbmRvYmoKODggMCBvYmoKWyAyNzggMCAzNTUgNTU2IDAgMCAwIDE5MSAz MzMgMzMzIDM4OSAwIDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2CjU1NiA1NTYg NTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgMCA1ODQgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjEx IDc3OCA3MjIKMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcy MiA2NjcgOTQ0IDAgNjY3IDYxMSAyNzggMAoyNzggMCA1NTYgMCA1NTYgNTU2IDUwMCA1NTYgNTU2 IDI3OCA1NTYgNTU2IDIyMiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYKNTU2IDMzMyA1MDAg Mjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAgNTAwIF0KZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvSk5UVlpEK0FyaWFsTVQgL0ZvbnREZXNj cmlwdG9yCjg3IDAgUiAvV2lkdGhzIDg4IDAgUiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAxMjIg L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago4OSAwIG9iago8PCAvTGVuZ3Ro IDkwIDAgUiAvTGVuZ3RoMSA4Njg0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1Z DXRU1bXe5947wyQzk7kzySSTDJA7uSTE3GBCIpKBUSYkw48RDT/ijDQygQST8BMQVJRaRmmerIFa KAa7ut5aWltf32vt4mbS6gR/SF2V0lZf0Yr6qvVR9NW+pVn+Ilohed+5cxMCIo+32r6b2Wefc/be 5+zfc2dOiBGRgxIkUnj1+taN1EqfYeZ5wODq27cou29O/RsR201kqVuz8Zb1t+XJw0TWXxI5a29Z d+eax1oCXxDlQkZydLS3tp26zr+QyCdB/soOTDjeFx/AOITxlI71W7YqvxH/gHEcY2Vd9+pW6Ydi EuMExp71rVs3WipyAhhDhpQNrevby/IrIOv7GcYVG7s3byE7K8D4OMY1G29t3/h0ve92osI8Ittr mGP444+DrMRlFLrBnDGmL7kRLsApXmDu/zIlkeUcdus5I6IJVo0K4ecjpJ5HMYbSNZxKNPJHo33H aF8nGr5t5C+IyEz0eNT+pscGaQ48fH/T8zNaDk2vHfkxVhmgFvTnj/zgq1dk8+kjdgVzsBn0EptN J1k5QllGRxBObvMZwFOYsdNvzTUG6L/pR3Tkq1fkFPYv4+msHqsO0GHqplPj543+T9FyOPvcc7Z7 kd7DtNGkfj+DxWmCBxl9iPqpl948T3IAOz9Ae+kgy6IPWamg0S72FMult+lF2ka7hCfEfyJUG7T8 8vMmVtsJ6bGHXUanWILq6VW6nqZTP/Ozdnqe5WCPd2HpG/Qu3UuH2MQxn5mSPL78kUj6aSajMuN/ QLsNvn6OVl/6yqycicz3VfyojFLUh1mHZ+3I8Eumt0dQE8g3oz6M3uwMHfmwATkwE3tMZPnINRsT cda9B++/iqwYoD30TdrK42nwXQ4+BT6VmcQE+hxe/YCeoe+NcrF6rKoZWX5s5MeslKZi/NzoThfH ljXc76P1bCPo8eLZmrMcM+s8U+GfjK41/KHRe5wep7/ScXqf/p3J9DhO5lPY91nk225EfTc03Ear 6GPGhkl8FnY14+8ij2WihVty7rONHoD1vFq6ocub7AXsdKHnAeTjeTlubWbHzqskol+gjh/GeuOf x8YPzP4D4lb6hK45h/I27HlReIJ2oW7upQ0GrVt6WBrALhWZv3B4ycIFodmzgnUzr5xxRW3N9Oqq y6dVahWXlU8tK52ilgSU4smTJvqLCn0F+d68XI9bduU4HfbsLNsEq0USBUaVzKf7GqKRLr2wIa47 1EZVVnTHdR8sqtLJ4w+obqW2KjbN5NItmk65TXpec7SPwnUx3aqdz3KdLpbKHwUgvMivRHSpFB/1 mtY2vXxJNKDKr/jH6DEsqxc1RAMBvy6U4rMQJHyuaVXadLkZ8yAYMwt1ao5ySI+cqMMk1QViaJdE 9cmjwxhfLWPKOCVxmowMnqfmdSwp9zkKGxp1yusjxwmdvJztgzrSKaSXa1BERs9Yjap0lveRznJ1 5l0Ek87dgosdr7uADyJtXWqkrRMebYuf9ekHGY8GlKSSXBJ11/oDAUPpJv3I4mifPbtBbWjPhhVk TFBfth0zdj6BsGzsY46rmdERHJFZfQLZnHCfh6sb4dClh3fF0VEb4TdQcs9S0iODu8eTCGIZJgKb 0WPGnrq1QZ+QUULp1MOtOu1S+ioHk7vTMq2Ka442ta31a1FdbIVSfSSWRjqW6RObmm/CFJQAxDsU Hu5Go+HBUyIdShJjzhtHqzZC9Nz5to72OE8TFlcbQctqiN4XGPTrHuCI7tZ0J8Sdd73tF5MRX6fC h8nkfYr+8OLoeGqA8yAJfNMqlWRExW5YLNI1l0esaixsRjYubDOCE97VquiJVV3wGT6tu0fzP5CU dcenAUQH8YEkrw7uYA5t8S5uShckJSAluavdMHW3YRryVYl0NXLggsh+ugHSN0UjHWoE/jQ3hEMg L5aeLxsI6IUaF0wmI1zF1jZozz2DT6FmqJEZoCb8GoM+DXp4mYFomRED7BhubYyZUyYDKBLioIfj jbEYNyoTAH1C6X2Wy1UlyZefUKrnaXLgl6ANTqtsWhKNNPLsBKfQEL1qyOcfQr+peWya+cCTrBri TuKUpWrT4kwWdHD/8Ca+LFPA8JoZebCa/MaqL/j8L0B2njovnkzOU5V5yXiyNT2SWKUqsprscziS GyNxxah8hvmDu/z6vN0xXY53sFkIMs+3eUua9NzFK3h45ikdrZjBZ44aqPMH3Fg6w4OT48Jks86Q 8ch7XmdJ+T1Y7MCJ5Ffm8eMljVPBr8t1vEyhyQ1R1MFqbBFpMxrUx1Is7ueVIsZKI51LTQf5A9jS SBh+7i02Z7FIIMBraFc6TKsw0BOLo5mxQqv8KQpXaYhdnFMGRyneGzglMUoZE4+riJWvCfsbOfFV OY3zfCyfk27VowT5YQ7t8FnYpg8ug42f1ek2eMwId25DVPQLnAU9wS/yXraGV0JIL9AMQe4TnJJJ WVWOqrqs6ZaG6KA/FFNkNw5INpYM5oo8TeWj6q8ZP0QpT9ZZSGf5vKwIhyrciEO/oA7EMUElkoyb 2TfePrBy7raOsTrKWIHC5UbCDbKKuvVn/OH2qNzU53m2j74VSufxokJsDI9dE9Nz+MtOz3nPaGCc vyGq4BhC2S42OkpE6eBR15V4o3EexPycPjqdHjkeb+TnXxSJBha/md/IcrjNrAnTDU3LoqO9JdG7 /XfFpqVpaWVTmrLwJmXs/liajfSkqXHSAGWRuPJmkJdVKkqksxEbYnBDJSYqAugtr0Ru8tSPqjH+ JlnYllR48rfBLAOD0J6MVSFfl0ZxXhLqUA/H/GPd9lhsFta5ka8DEbAnY1ihy1wB2JiqOgOmaGUT Tqqy5igO20QjEr2RlzDMHURVDXKLuSGxMU2h8d2dPlPnm6BzrAL0FZlVkKsJLBFLJvmaS6Mq0jyZ 9CdhhzlOMzp/ImxOpImLwPBImiWaIQukGt8PImpA5Z6PNWKrr8Hvo6dUmlou7uGbx/SG5Epoe7Ph 4fjfycOtl+LhVZfk4dVjmp7j4TbovJp7uP3CHtaFsov4eLxLwxmXhi/g0jXnuPSWi7u0Y0xRaNUJ 9ToMl3b9nVy69lJcuu6SXLp+TNNzXLoBOq/nLu2+sEv/EUm78RwPb7q4h28d0xtKboa2txoe3vJ3 8vBtl+Lh2y/Jw3eMaXqOh7dC5zu4h+/8//PwXeM8TIRfPfgtza+kRJpAOISXammyVeEwBtjkNNFR AB+jL76BPrAELAJb3qCDxiXRcghJ8kEScN/G+4JcPT3gDrhL0TBwnA6LidMJC31BYSkBrk4ithe/ fPme08I+6YDFxQ6Qx3rAYhUswgEWtmWxAzXVGivyyYuGBuVBeYjmDM0Zml5di1UZoJOVD7/Gf50O vyaW8BZmCPzGxHIa9wM2yqWu8IJVdtYts2Zpo5SQ9kjSiglsmchWWJlgZR5ryvqsVVzvYk77JLvg lCfJQpaUtZdyc/cy0bnDkrWdwl5Lt5BHawXNVGRMC7by5paWFmrZhBYPlFLILVOgtLbG475i6uVM YwPC3SzKNgx/ffgHwy/9+eP343MPpg5ajgzvG/7X4e8Mr32JOZnn5W+18l+5ArWMvCP14t4vh3x0 d3jxcpn1uNj9uSzmZfd5WVRidsEvaEKTIGUXlGc7F0j2PPsUuyiSR/YITgt5fSx/v5jvsrt7s2QH 2X3Uk5O3wxouyukQCq1rzhpw5uggzZkzVFNjwPRqbgitbNG4OXhYS2CGVS0RZsie2poC7uoytcTq lWtrZorrbj15+MTIq499i102/Orau9bf+9o3t/7uL6xkmOWxBTuF5s+PidrWl/qGD/CrK9i0HDbN lFaTTF56MDzF7WT1zsXOF51/cn7otPRIrFd6VBKKrMzq8+QvmC/dKAkivk+FizwFC64R2V3ZzPGg y80OuX/nFtzunDz6rozfbmHFlbtAzvmukJ/Xa5Nll4dliZ4ddod7hyVsL8i3wFTmkw8XyYvOPCcP wTiYOzTnzCvakNsTrGrZhAxiLZs0atE2IXibSq0qAncF8bAFPIGamSwgqyXSzN8/PTw0/CxT3//w zTM3Tmaze588s5Qlf54uvZrVsZwRNnP46PATw4cj7J/5xSTjecf+hPiJNDGcQ15GYg8y3UI9YzkM r2eSd4CVW7XPj3EfMbp25B3hfUspsvX6cE22jXpz3b1Cfo7Fbum1uZwuq2R32aRcV09cGpQEVJik IJf34NpDl45LNgkGnTmM4hiUD8uHYSh6sHVIfmF6NbeskKkzameUemu9qjsPIRTe77pqePu2baz8 3XcfLZthLWYdwtyBgZLXB878129yuD4cdgSfeb1qpSt0kvltXEs6svYW4y7NwNDYchqWMnw34/z8 AZ7w1DDul3Dp2HxqtvP4GCVDx2WyFVMCbn7ZX6nTGqUByyJqkXRaLnyPBsSr6VowzsLfGnqWVbJH 2DMCvxXn69toPXLpepwTDJlUjVsgkpLOWng6o63HwLj4RuXQtdcvumn5cu3a21Z3trXOv7V1Q1v7 tLnd69qwjnmTP1JHfPTlh5sq0iTc382nBdjvRqI0bcJRdgugBbBUqy+h64Vc7LcSbTdgO+DbgIcA OEAFD8kABVAN0AEWwQNaPvkNXDgyyN4I35ZlD/7n8fyCiS8fQ7Pt6/n+bV8vfPEl9G+/A836jWjW daNZuyHfv3JD94btG0Ray9Zu2H5r0Zbb8rwTb+lCs6YTTXtHnr+7Y3vHtztEapfblXa9/Xi7ZbCd tXf0bCoq3Jx/V0Nh4E6AIAwI+4Xen88uHh4RtDQT+oHC+Ir5eHZ28IPeCVp9jjBbmEWzqVhQhGJ4 UxPK2Bl4RBsZFCal3O7g08IkYaI5MTFVVR0cAGViqrDI7LhksEwckylK5eYalKKUMweUQlD4qvns TMqqZddXs1eIsWPsJURGYy+b+PcmftHER038AvuVwfe8iX9r4t8AQ0f2axMfMfFh9quUpNnrs9hz iJcds36AMHKU/TJ1ZRB6vYJOccDs5BVkOv1ZOUHXU+weKgYITEvtF+Gry1J7OZrav9fGXVban5Ud BFb77Q4DpzBOM3+qN1CcZoHU3mIgXwZJj8O1X+FxfpjN/rMnN3jvPpu2s1fS9u5jGt3P7u/N1vb2 itq+XkH7bm9N8UMPsqP7j+//YL+4v5dp4d5CfzDcC2enhQ2peyxaWliXOmTReDBW9SOYiSeFBcQw 8veXTYV+wPn5Bk45nEZAvCmlxOwU+IIDeLF4UyIsEwpS+RhDNC+V5QAhj51OGVlyuh9qwuTTKaTu AHuTPZiaHMD4zVReYbA+mz3LDhnR+YWJB9khCFJ9BfsjyQCBFLTVRi/BnkHcn2T4joC4HTTxgImf MPHjJv65iVMZPHKcpVOOHOjQz/qwhf1J1gdjjzJ9NKr6aFT1lBlVPYWoPs12sHvJTcWowHv5Ck+x DtZJNYh0QWq7FeGtSPVwVJ7aKQGVpb7J0ZT+e2DHQVYClUv6wQCjC1OFk7mX0PEZ7kInx40MKA7L OwLFZ07Dl1/AsV8kkDUjg/2feb1BA+MFxGPu+MzpDH56UtROJmwGw8c1tQbDx1OmGAz2j/OLgtV9 4b7mPrwQIdDn9gXDb0+rCspvM75SqmiywXhlSnYH9QMW7UCPRZPfan5rz1vi7h4k6YnCwqByYs6J h04cOHHoxPET1ru3Y/YbLlfwG+aeiVmzjT0T5t6JisrM2G8s3Z9QM7rkJfJ8wUSPoO3pkbR7sMp2 rM+V8t83tzl4X0+2toNv2FNaGgz3FBejQTHU3ymIgiRYyMFOsc/Y58CfsJPsU/w3tljg53YxO0Vz AM0AUXCxk4KbnEIWZOzAVvaZYAN2UUjIAlgBIoXAG2KfAB7C/xC+jzX3sQdYL/Aetpd9B/gnwD8l J3sU9B8BPwL6D4F/AplHAY9wWcA+wB5AHf7DmANdZrMQuwryVayaTQeuZNPY5cDzgRdCvh70BuCr QQ8Dz4dsPeBqwGxAFaAyvC/kn+n1Xen1zvB6rvC6ar2OGm/WdK+12itWeelyb9nUnPKprgotp1Jz lag5U1TX5OIcpdjlkt2OrGy7wzrB5hAli4OY4CDRU1wsXi8eEkdEqdg1x9XsEv1sktM3ocjplQuc HinPWRmqCJWHykJTQiUhJTQ55A/5Qt6QJ+QKZYWsITFEoeZapnuaqGnZXD2XAS+dq9dqTWlRWaLX aE16VvOKzG0LZnVhJ94Fy3RpZ1oA8jTctCKKTOeXMT3+ASQ/6U3xnm/FcNM+V2c7dRW3D0Bh3IQo O3EPuCzaJ7C5uHHWZ+IGiHPFtEl6G7+RS0yK6TW8s2dSDJeMsxbrfnWudqFn8+bxs33lZRG9ItKq V0bijeMJ/3vfWIhdgA8bGHug2XI++ZzNzw42b74gJ0E8o++XyKN7nF2D856/HX5RNET9MQ4arrP1 MMIDrUwfjHNFmr3K79DT7LUM+o8M+kMGvZ5Bb3BkqLSlL4sH9+olc5t0G26Ebc0r9CIVgyMYXImB Q537P9b/TMgKZW5kc3RyZWFtCmVuZG9iago5MCAwIG9iago0ODU3CmVuZG9iago5MSAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5NjcgL0NhcEhlaWdodCA3MzIgL0Rlc2Nl bnQgLTIxMSAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstMTA4NiAtNDQwIDE3MzQgMTE2OV0gL0ZvbnRO YW1lIC9MT01aVlYrTHVjaWRhR3JhbmRlLUJvbGQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDE1MCAv TWF4V2lkdGggMTc1MCAvU3RlbUggMTAwIC9YSGVpZ2h0IDU0MiAvRm9udEZpbGUyIDg5IDAgUiA+ PgplbmRvYmoKOTIgMCBvYmoKWyAzMzAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAyNDcgMCAwIDAgMCAwIDAgMAowIDAgNzkzIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjYzCjU4NiAw IDAgMCAwIDAgMCAzMjUgMCAwIDAgMCAwIDAgMCA0MDUgXQplbmRvYmoKMTcgMCBvYmoKPDwgL1R5 cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTE9NWlZWK0x1Y2lkYUdyYW5k ZS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo5MSAwIFIgL1dpZHRocyA5MiAwIFIgL0ZpcnN0Q2hhciAz MiAvTGFzdENoYXIgMTE2IC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKOTMg MCBvYmoKPDwgL0xlbmd0aCA5NCAwIFIgL0xlbmd0aDEgODg2MCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAG9WQt4VEWWPlW38+6kO48OSRqS21wCyA2Eh48EW+iQdBSi2IGA3aDQDR0I IBBJeEeIaCA2+AAdmW90FHdm/fYxyk0njp1RTEYHP9mVEVlfs84Kvv12ZWVmHfFbXXr/uvd2TDIZ P+bT3eo+9dc5p+rUqVOnKnRBjIis1E4SeVauDzVTKl0NySuggpVbWuXzn37+W7Q/JEr+5arm1es3 59kvEqU8QpQ5Y/Wt21cVWp55gijvFPp4mhpD4QtpRb8ictjBX9kEgXUx7wF/HfhxTetbtyWTmNBx K6rUWzeuDJGMDzlawSevD21rTt6RpYJvAy9vCK1v/PXOz14Fj/motHljS2vcTWHwvwE/vnlTY/P4 96/NB/8ZFnEUMoaPKFZKBhG5hCRZpUKipJepNFHrfczKMosKRDP+jl5/mmhf3BzX20QX3xay71NS MViQ5fsYEWOP00ayxq+OH4x/QX3URHnxqviP41j9CGVPfBedodN0gnroSXqY3kX7OD1PvfSP9AHa L6H1JP2IVmDsz+mn1AH8B3qcHqRNkAsUkuN/bplNHCK7QBfoMKuiecDh5UFYeXC48C/yH8eLRtC9 Gx9LbdTGN/MPaTM+P4HFX9CRQT3XoP231EI76Tg7RyvYc7QK6+lEptzHffF/TzpB+dI2yqeNliMi E4aUh8hP2yksPRL/A/LEluIjGz8a/wNsDS3f1W8j5k6UXjrA0mkX4jaNboSvcxKKoYgYXsAaVmIt e/A5jN3oxqcN8x4c3DO5RnAJv1PJyNZEHiVdbvSNf4L83aa3j4t4mxn7Hm3BDG6aTMVki5cgb66L N8a3x38aP4ZsELv/hJkVfeD+ng6yw/BgBd1Mi/kr7JzObQS/mOaxMSyTHoXtK4wZE7V5qiSDFzku SsI/ixlF82zBS6PExR2jF3aIjUIkXqYXKab78wgdogi1Iw6tyO8l5IPvM3GwjX4f6TksPP+2zzJq QO6hIAdnYT3vGpaNOukN/eyvMrg/80+c/ePSC8YYEUWj4IpLlJPYSeM0dCI2m3H+VmJnL+inR+zf ceza48i1hG7xgPYlfW9F/1k0XXgRnxnfhdj/lm6ijbybTWR3YlxnYqJB+AtIE5lcQO+yWYN0g5vf J+/bcIaO00ODzeG830KNQyTDmOHxG6YegU06xzTE4TT9EvPtxEfc7MNLL/L7OOK0g+qpivZhH9/F +WjCGQ4j4qeZjP15DbfYSCUEu6ewKxulVZK5yyN1Q4aIzwgl6ZwhTCVmQeYP5G6iq5G7CW4IzkqS 6G2Wg/x4gN5GTjxJz+AuWS2kyGKj/HV7tIc20CTzQx7PgrnXua+eWVlx1ZVXXD5j+rSp5VMml6mT Lps4YXzpOGWsSy4pHjPaWVRYMCrfkZebk223ZWVaM9LTUlOSkywSZ1TGCrSCar93rVZYHdSsSo1i lzXr/PM3lGuU43Qp2fKM8sBks5eWpGqUW6fl+fxd5KkIaMnq8C7zNanU/kcXBt/glL2apRRfZV4o rE1c4Hcp9jedA/oAzGpF1X6Xy6nxUnznQoXvvJAc1uw+yKHQJXM18vkFxeLvV0BIFa4A6gV+rTjB BoQ1YymDnOzFieof5uZ8FrF3WQurazTK6yLr+xo5RLfzFaSRW5uowhE7Wro1KtdY3h81lqsxxw1Y 0tApxLCzFSPEwBteq3jDaxDRcPDbmJ43IuqSI3JkgT97htPl0p2u016u93dlpFcr1Y3pWAXpAupK z4AkQwiwLc1dzDqL6Q1u9c7s4pSaifDlCHe9gtZqnv1BNJQaxA2a3G81sXj/gcEqwjCjE6Gb3mL6 nFpytZZiOCGv0TwhjfbLXWX9kQMxO60IqtawEg7d7NekEJzqIqnU29Sgja7zLYEIToCCTbLY7hq9 Epsne5vkCHjRN4haqcHQofJwU2NQpAkLKjXQpVX797n6nVoO0Ktlq1omhmfu+NApRbwFa2TBRiL7 ZO1IvX+w1iX6IAkKJpfJEa+C2WDMu3aO2LHygW3Ts3FuWN8cz/6QrLWvWIuY4Rs6kMh/V8SuWb90 YXewPxgpTocIsKBwcK1YylqMtADkyP5GfakH9KUhX2Xv2hpBYiCynxZh9BK/t0nxIp7mhAgIxkul w8e6XFqhKgZGIl7hYigM70Vk8C1UdTcMBmfCqTL4U615GnSgBn0PMKMnVBMwRWYHaCzYB80TrAkE xKKMDdBSSvclTVHkiDCfUqrlqXbXb6Drn1xWt8DvrRHZiZ682n/NuQLnObTrfANiVoA+kfJzIkhC s1CpqzeyoEnER1TBBuMAI2rmzqOr2V+3erLAeRJja5XaYCRSq8i1kWAkFIu3r1BkuxLpslojzd6g rJ98Bvmv9ju12gMBzR5sYjOxySLfahfUabn1S8X21MpNIUjwna24KpyubJg2+uDmGFltnjNkPPJe nLOI/TOs2IobySnXiuslhlvBqdkrxDGFJ4v8OAcrMYU3rFc4Hwth3ClOihQo9a5ZaAbI6cKUesKI e6/elMKIyyXO0P6Yh1aA0drr/QYv0wpnlDzlKvYuKDT9CY1jkdC0JzQDw4MK9qqgDvPrOfGXchr3 +UA+R7KVHLlSXObwDt+5Ya2/AWv8qkJLRcT07c6t9ktOLrqgxZ2SaKWr+JPg1kap+kARE9ySEbsi n1I0u6olVfv7ne6AbM/GBckGksG0KNLUfko5wcQlSnl2jbk1li+OFeFSRRhx6Y+qgHJgoOyNBM3s G7w+dBW9w00D58hYBQ6uWCTCYFdwbp1GPLJzFLHUV0S2J/4qlNaKQ4W90SM2L6BliT92WtZneoXF Oav9Mq4hHNt6vSF75Sax65ocrNHvg4BT6BPiWPxssEbcf34kGro4zfxGliNs5pkww1DX4E+0Fvhv d+4ITI7RwrK6GKXhLylj9wZiLN4Ro5oxvZRG0vJlUDeUybJ3TQ0mBLOoDIJJLrQWlyE3Rer7lYD4 SzI3HJFF8oexLB2haIwEypGvC/24LwnnUPMEnAPNxkBgJuzcJOxgCLpHArCw1rQA1EXl/4NO/rI6 3FTjfX5ctu01SPQacYSx3H6cqn6xYrGQwICn8Pj2NQWmz0vgc2AS9EsNK8jVdpgIRCLC5kK/gjSP RJwRrMPkY4yGCzymIEZiCBbujbF2H8YCFP3fB17FpYjIB2ow1c2Ie+KWitEt3x3hZQN+Y+RyeLtM j3DwB4pw6FIivOKSIrxywNMhEQ7D55Uiwo0jR1jj478jxoND6jFC6hkhpKuGhHT1d4e0acBReLUG 7jXpIV37A4V03aWE9NZLCun6AU+HhHQDfF4vQrpx5JD+XyRt85AI3/bdEd404DecbIG3m/QIt/5A Ed58KRHeckkR3jrg6ZAIb4PPW0WEt///RXjHoAgT4VcPXvnwwYtmCuU9k8wtJKj85Osn9WraVFe2 K7sUFcNvvW88Uvs37Un0NXks7Ripvx8ms+STi9qk5Tb3n5jT+M378rrV7wi1wIEZCPe5YEQBpjx3 0Yd30eILWy5UZ4qXx6GFG2+fulAmGSh6cNoKuhG+MrLTVPxCpqSzmTPgvdAyytERr6OUS9Rw06L6 hYvU6zevXBMOXbsptCGs/1zn6IkSrxBvoyMUUx+j29QYrQbdAlqoVmVh+lqygzjt5jXE+Gzuxnwq n8XdUaZ+/iy/BsJrwOSV0DHo7CDO9rHOaFGJJ8bu7rbnV1JVFuskO4izO1kHbKnsLhP3so4oV9uf Zbth9gxr86xiZ87mjxr9+huodrblO207S3aW75R2thW+dhqiLVtRrW9GdetGVOs25DuXb9i9jq/b sHtTUevmPMfo1WtRrVqDqrEpz3lf45HGU41SY1PHbUWFLfk7qgtd20G8V1ogzcPM9mNSLflAnDxS ZTQjq7I33i9VRLPMRneatdJXlSFNJiZNlaYh6ir/gv8XHmtV/kH0ea7G+O+7nw9jrfyd7mkzKwVG lQnCChp5eXrjd9EZlWZj0hSz4VLMxqhCs5GVrTdORbPR4O18m3CvSuWt5ANxhPYWtG5BK4NfT07Q OpAErg5cHXE+E2mcTyW8ApgDnM6niWDzqSaWA4shn8KnRYtL5BggJ7+yl11gH0QlNb1KZl8QY5+z /xSj8Lxn4Gcm/oeJn7JPRBjYx0AL8CMg+sf/iX3QnQHXq8ZAwGgL6r1CxR5kh3SDD5h4iN2PbFXZ QWAK8D6gmPBedj+W3NcHllEz6nahYDdFD1nUGFsYPSjgxuhhAVd275ZUJFhlNKegsiqNjWOlulN2 lq2jxXP1NwjfV76vuOfjoqLKnzwsqY88bFEfPpyuPgB7Bw8lq4dg6UegHx/m6kOHJfXIYfbY4aOH +w5Lz0nXSXPF4qS50Q6uipSo7rZnV5Y8L+EQ0FlRS1dIlyNqclWONIOmgjwgH8gizZDyhBPSdBPL pTz0LO8DizOL7JFBnJ+PHktG/rwf7UsVU/D3oqMm6inwXhS5EONno/vSoT/T3WfBUvlb3UqpyK+3 og5sGvqfjsKlqkz+Ej8u4slf4P06/trEA8L35/gWvlUshW81l8JvM5bCN4ml6LWHBxNGg9H0DN36 8uioAr2xLDruMr2xRB9XlceX6gNFbePzUOfzuTQexCmNT6ZCEId7ajTboY+7rDszuxLZpohsO8bH cllsN3dxOWpRT8CejDukGLU4XCWGln3JXtU38ix7Glehi51hT0fHu+QYOxMtdlVWFbF/Y7/Xs+Yd E//VxN+Z+DZ7SzfwFntT7/cmex3ZpfWBZewN9rou/BdduKYqg53GOnpFzU6butd0HWY8FcUl0Iv8 flXkt9rHfkY/B/WApPhZ9kQ014FtYPewA/qE+02MAEVaL47uxTXBFkXbJUBDdG8SYEF0n4D6aKcA X7RT6OZHOwRcLzYqxiqi+wRMi/YJ4VhDmOXJgPK/v7aoX4tO8X5P+p9EYn7Jzn7JBJvW5Rhd6fkI KS+4KUczbZXw1NPj6wn2NPe09/T3nOo523O+J63naLjk008s6t2RFDWyP1k9AMKQZ+6dOr3y3nsw JYbn3VOsVN6zn6v7O1LVPXdY1DvEGuL93e3zbhD2u9tnVxt4eaWBE6fo81rbxyiV7bu4unuXbtVj vd07t/J2MLtgSZiWO2G6EyvcB8HejmT1zrvS1buAzR3tHbyvg1WlSwulBsqSfFI96vnSjaKOSuGS qkXS9dINZJOc0mhpDFklm2SXsoFWKVPKAk4AXkaZkgt6BVgMvQycQG7JBSoGOUE2kJXc/En+FD9K Vv44/xv+M+Cj/DF+BNgLfJYyeTf0TwM16KPAXozpBuGhkD8Jehz0KOgOvoey+C6+G3Ubv13Uur+b +Q6+E2fFzrN5Duxm8ixuAzLOuURWdpHF8RfYips8mx4GcdEXd72dHgP1gc6AknBzZ9Js0G6QRCXs Is5NIcY64VMubDqAhfAjF2QHZYKSQYzc6Otmx9jzrA/zdbEo6wY+xY7il7iVnQD+M2WyF6E/DuyH /gXgCYx5EdQvxoK6QE+B1rMNDP/NyEJsBVsJXMaWs6DOr4qOKimpmsNW0WzQbpDEtkO7E9ZaMGoz sBmjNgG3w1ILqFlYBK0ChUDLQGVsMtnYeDYB9UR2GWWxSUxFXcAKIclhuajzmAOSfPz3UBZLYsmo OZNQ4wiL2vN3SJWLcZvzKkfBlQ7HFY6cyx22GQ7rdEfaNEfyVIdU7qApjvETsiZOsE1Ss8pU21gl a5xiKy7JkktsNnu2NS09w5qckmqVLElWRNpKkie3SCEptyRZGl1SYptt222TZImVSDdKfVJcsjjZ mMyClKJMh31UZo4lL/N+JytzT3JPdI93j3OPdcvuYrfTXeB2uHPcNneaO9ktucntm8G0nDqqa5ij 5TLgwjnaDLUuJskLtOlqnZbmW2q8EUCq8U78SG7QLJ0xDsipXrLUH2OF4gmhw9kr1q3VBTvuCeB9 eI7GOjUFv5kBHvx+lzvxetXg7+JsDt5JtavwbiF6BdQxWli8I7WPCWjTReP+MQE8jc2s15zKHHV4 aRGCllYdvtV1TRzv1SZ5Q1qZN1jzrVhVCQwc9moXvaEY48oQZaLjMGMJMbAFxWRjvM0b4ztghu8a 2czAuJg03xuTrkdXySe6trawAd0IjZZWCJleD9fqk7duhiNDNBCgtCAMYqiIhw6DKt3tFkNBg9U0 YCkhTeCgSQYt27QpRrWorNrvDKh4CtYUJEligGlRAIuxNvH8HGO3G7DLgN0GtBtwhwF7DLjTgLsM 6DBgrwH7DOg04G4B5srwr5KrdSl3G3CNAbMMmG2Ax4AqA+YYUG2A/k4e416DqzXgWgGIG9bW0pUm st+3YE6dloqH3lTfUq1IAfMymCvBWJU59L9aSXrECmVuZHN0cmVhbQplbmRvYmoKOTQgMCBvYmoK NDc0OQplbmRvYmoKOTUgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Bc2NlbnQgOTY3 IC9DYXBIZWlnaHQgNzMyIC9EZXNjZW50IC0yMTEgL0ZsYWdzIDQKL0ZvbnRCQm94IFstMTA2NyAt NzM3IDE2NDEgMTE2Ml0gL0ZvbnROYW1lIC9UV1VRU1UrTHVjaWRhR3JhbmRlIC9JdGFsaWNBbmds ZQowIC9TdGVtViAxMDMgL01heFdpZHRoIDE2NDAgL1N0ZW1IIDc3IC9YSGVpZ2h0IDUzNiAvRm9u dEZpbGUyIDkzIDAgUiA+PgplbmRvYmoKOTYgMCBvYmoKWyAwIF0KZW5kb2JqCjk3IDAgb2JqCjw8 IC9MZW5ndGggOTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2QwW7DIAyG 7zyFj92hIukZIU2dKuWwdlrWByDgREgLIIcc8vYzLO2kIfnA//szP5bn7q0LPoP8oGh7zDD64AiX uJJFGHDyQbQncN7m/VY1O5skJMP9tmScuzBGUEoAyE9GlkwbHF5dHPClaDdySD5McLif+6r0a0rf OGPI0AitweHI495NupoZQVb02Dn2fd6OTP11fG0JgRMx0f5GstHhkoxFMmFCoZpGq8tFCwzun7UD w7h3nlqtSjV8av/DKWj54jOSXYk4Td1DDVoC+IDPVaWYyoO1fgBtmnAQCmVuZHN0cmVhbQplbmRv YmoKOTggMCBvYmoKMjIzCmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAv VHJ1ZVR5cGUgL0Jhc2VGb250IC9UV1VRU1UrTHVjaWRhR3JhbmRlIC9Gb250RGVzY3JpcHRvcgo5 NSAwIFIgL1dpZHRocyA5NiAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1RvVW5pY29k ZSA5NyAwIFIgPj4KZW5kb2JqCjk5IDAgb2JqCjw8IC9MZW5ndGggMTAwIDAgUiAvTGVuZ3RoMSAx MTMwNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdegl8VNX1/7n3vVkzmZkMk2Qm 23vDJDOEISSELCyRvAlJRCISINIMmjJhsVAVggSxtAVEqRpcgguulbghFS0vE8REoET92drFgrUL 3X7m02Jdaj61rdtPyczve98EFH9+/stvwrnnLud7z7nnnnvfffdBjIgctJ0k0lZe3dlFX6M3UPML 0K0rr+1WP5vz2B+IWDuRZdkVXd+4esiy5kUi6yEi05XfuOpbV3QeuncXkVMlyvCtWd25Knm84E0i /wzga9agwrPV+jrKXSgXr7m6+7qyQhlY/90oT7pq/cpO11WOSSgfRTnn6s7ruiyb5WtR/jXK6rrO q1c/8L19/Sh/gHJJ1/qN3bSTvUeUV4ByTdc1q7v+Of/NHJTbiLJ+hTqGP/FzkBljIppFs8drRO35 P35+8f+xJBlyMpm+JG9G2WLUWZHaTM9TgUFPUoEcItibOn2WkmtTp0Wb4PxdGF2YpvEeE/Q0/Y5N YioNsE8plz5hfjaNLiKZPsYsHaQxuoe81EZ7mIeKKYcupYuYDJkI3coeTF2beocuoDvp0dRzbEfq KbTfQT+mT2DBf8qMaukSyF9Kq+kd6U2KpR4gK91EGfDSYpZDnfRb/H0IO+6iu+lH7DupT6DVSzvQ Xx1FKZp6IXWGJtOtcq/plO1Z2k1HmDm1MrWWimgi9fBI6repNyhEMXqMnoZNETYsz6MAXUk76T7m l36M3D30OCWZg3dIc03HoekiWkrraDP10FP0M+ZhraZTpvdT3069hRmcQJNg01p6h1WzBfwJ2ZGa k/oDXUZD9ArGK/6G5cvkJ02XJetT30+9SNn0HLOzo+wFU6Xp9rHrU4+kfohICNE0eOQS6FlBN9AL 9FP6J/2Lb0tto3m0BJpfZoVMZSF4/Lfcz7fyrdLrNBWj7YC1m2gv6ZSg5+kIHYNv/kgj9Cbzsnw2 n61gu9m/uIOv4iekB6VD0q9lJv8A/g5SCXzUTU/QYayjV+kEM6H/CtbKvsnWs3vZ99kI1/l7/GPZ Kt8gfyaPmULJkeRnqUtSH5KP8uhi2kLb4NvHaIAO0S/pN/Qv+jd9xNxsBlvDHmE6G2HvcRufyBfy Lr6HP8GfkS6RdksvyNVyg3yl/Kr8B9P3TLssnZbkmX3Ju5LPJF9LPZd6DbHjRP8haoZHr0dUPEHH 6XX0/nv6M/1FxA/6n82Wsa9Dy0Z2M7ubPcNeZq+xdzFKMv4m8tm8EVrX82vgpx38Ln43tJ/A30n+ B/5n/nf+oWSSJko10gbpEUmXBqWT0t9ktxySp8rT5IXyMjmFmak0XWhaYtpvOmB60fS+uc68ytxl ftuyw3Kj9Rdjk8f+M0nJNUk9OYDYtSKStsATD9OjiPtDmIOfwaO/hMUj9AFmIY8FWBh2z2TNrIUt YF9jl7PVbAe7id3J7mMPskfZDzECjIFb4K0Ij/IlvJOv5jfym/ht/BD+nuc/5b/lp/goLM+VglJE miZdJC2TLpPWYQzd0lbpRnh2t/SUdEJ6XXpLelsaxazlykXyJnmLfL/8pHxIfs10selq/D1qOm4a Nr1mOmM6Y+bmPHOBudz8TfN+818sZkuNpdVyi+XXln9bu1gBmwzLVcT+uR/3Yw0W8ae4V97GRlFd yGRyYeQRzMMSrIp/U72UxLw4RTtsy+Z+eYKAmzVZJ+Ld7AhVs5dpm5lL2AHlEUqwP/ER+SV+Af2G xZlfflJaZ/oZD9AB7Ea9/Cg/whroEK/jS/lDErE32X56E/F+Hd3NrmQb6QAbZbPYd1kt20a/5jnS EnYj1aUe5TKzsYvY+wQL6Hp5FX393BC+MsNm0p/oneTDcqb8HexPg7QHM/o0vcF+QJ8yU+o97G4S dqNO7DK3It53ktj1OrDOtmE9+rGDXGU+QYcY9lZLrXmOvIXep/+id0zPI6IasJu+lVwrPyz/NVWb KsMKwyqj/Vh3a+hCrJg3ESXHUBaly7HS7dhLKrGqW2kZraLvYtfbndJTD6VuSH0rtZ5+DuynbAr7 lPVhRQwCUUev4O8O+j3bhXV44VcO7/9amVxFw/Qu87ESVon1MGq61tRresp0yPQj06vmafD2jfQg IvoviGY7RrCSXqN36WNmxdz4aQpVwd4ZsL2druIx6RjNZXnUhTU7Cft4w/hINqKXHfDeQ1jPx7A2 3sc+cTn9iE4xznIxopXQb0U/LfDzctpI+zCDN7AB1KzCrj2Z/o5xO9kM3g19Gnrag11rGDb9if4G b6cMu6ZgX2hkS9HXxzgfrIKGGmpleC6nDtNM7KyN0i/g72LmpgY2kT0OXBwr1EmFNNP0V8ZpSvKS 1Ay+VjqGZ0wK9X14euXTBWwDrHBhHGOUzRZSdXIxbHidSbLOfmVYcT9fnbpJ2py8in5OP8CcaPK1 lkYiLdqm1c+5oG72rJkzaqurpldOqyifWjYlMrl0UjhUUhycGFCVosKC/Dy/Lzcn2zvBk+V2OTMd GXab1WI2yRJnNKUp2BxX9VBcl0PBefPKRDnYiYrOL1TEdRVVzefL6KrAdaLpPEkNkld8SVJLS2rn JJlbraO6silqU1DVX20MqoNs2aJ25G9rDMZUfdTILzDyvUY+E/lAAAC1ybemUdVZXG3Sm69d09MU byybwvoz7HODc1fby6ZQvz0D2Qzk9NxgVz/LncOMDM9tmtXPyZqJIep5wcYm3R8EFN1IJU2dq/TW Re1NjfmBQKxsis7mrgyu0CnYoLsihgjNNdTo5rm6xVCjrtUxGtql9k8Z7rl10E0r4hHHquCqzsvb dakTfTTpWRHobdRzt5z2fV5E55657Td9sTVf6mnyrVWFcE/PTao+vKj9C9j8gOghFkMfwPKS5nhP M1TfiplqWaJCG98Za9fZTqhUxUjEqNLjWx1sEjXxb6q6LdgQXNPzzTimJq9Hp8XfCiTy8rSh1Ajl Nak9be3BgF6fH4x1Nhb0e6ln8bcG/JrqP7+lbEq/Oyvt2H6nazzjyPxiZjWcnm4zcoa4yLUsPudZ JiwKXqRriKiVKixpD2JMM0Syegb1rJyBCcAvxoDSV2FG1uq2ufEe9yxRjyEy3VTiDqo9HxIiIDj6 3vk1neM15hL3hyQaRZycCzWddZ7N65GIPnmyCBHLXMwpbJxjlKvLplw7yGuCXW4VDO6jVvi2Mzar HO4PBMQE7xrUaAUK+vZF7emySivyE6SVR2I6j4sWTGC6JftS0bL9bMs5eDyISD5kHMezdWvo3D+X O2dC05pZOsv5PzSvTre3LAm2LFrWrjb1xMejtqXtvFK6XTgUfkPbeE6fMLddyueoEzmeLxmtCMrL l50TQaHdocsl+GcWRmN1SAhKo4Kpzbo7Pi+dxuyBwPiS+Z+YQYv1C6DB1PsCZbDPYeOj0GdFxu1M W63PPq98nnWOHqmlDTsOb2lb1tNjP6+tGXtZT09zUG3uifd0Dqa2rwiq7mDPEH+SP9nT1YRdKD2h g6nnd+XrzbfGMJQ1bBbCllNDf5DdvKhfYzcvWdY+5CZSb25rT3DG58YbYrEyHC3EC5VJvO5IeL9p OMRZ0mwZ5PXaBDLJSYnsFjnJyG81m5JcOspCZMMB1Ue+iPujurG6S9wf1C0Yq6N65N1nkEyrCGQF skqQMDz0z6jS8BnNRJ+RKg9DF87mxP6CE4rQNVXLl2Yws3mGbLcdlDg3h5hqqjBx00HrqwdE/x2i 07qPqH60fnRaxQT0y0A/Zf7kW3jZyBT8zL9FihEg7O7FuehGvHfZ6Bqt3mqSzaYSi2qtsB63vmGV y629Vm61kiSXYPA2slrqzQtxjFsswQM8T82oyOAZsk1lKlXAzkG+a8A+bYkvggF2iBFe4u6APQtQ wFjFaD0zyzs2gEsmdx1GPT0rkI1Bg+6VRsdm81VjD5me/yT5xCdju8W4L0q9jTPyHLw7VLIN2hpL nrXAVJiTNz9/XsFFJX90v5Flq/E3+78WusL/jdD3Qnf678rblzeU/5O8V/IdZnNmdo7ZnxM2l2bH /Jv59/g+87PmH5sdx6t+7+aFxZXTsqZkFmuRqVXF2sRJSPyFVeuLzxTz4ubCwdSwVuF0VV1QyKjQ XagX/lehXFg4hU0nDbUuUmDapQGtIKs+oOW7kfjyqgKDvPtZ2eLItE8BfABtBkezwSExBRKa5s0o mhayltomZcYUx14HVxws5WAOzZlT5chbWMWq4piT2ysYY9NLA8tz2Ru5bGHu8tz1uVKuf/raaNq1 G65ZMPrBhtEO4d5Ih1E6LcJpNBKJwM9jYB90RE4bzo70m/lcBG95IdsQG00Xhqg4NfxcfmFVW/Gq Yt4RiXUAkeWZKTkxK5gWtqGDOjawcE3N9MqcnGzJm5MbCIVDYbM5ODFUXVVTU1uDE0YoONGMQLSY s7050ytRVVPNVqcivzpxdLBFyi9JvpvhtkjzHu94/NjSB+98+eLW9S1t7Os17xbXtjde3DTdncH/ MvWBu2O3PJccvHXnxQW1fmtzc+LmZbe1FJSoBYuaZid/5an0hetmL60M1RavRqxyakM8dCJWXXhv 79XKPDFzzB7zLM1Z6osV3Ge53/aJzdZVtL2Iz5KqHLOyq/zzpUbH/OxG//02mxfeT5gy8sQkODMs ThfcbM8tdWaG2CAr1VwuyrujiBW5A1Z/YXud4eYFo5e4N3xUt2B0rO5vRvimVxR1wD1z27XMtea1 9rWeK3Ku8K0tMHfgRFIt/ENZbs/0ylysZG8u3FKT9pPcmfws2r/sueRnyRcTO5h/zFPeuKXz5hu/ seqmhy6L4XXNiuOm/27uPtP11MXrnnj8uUf2YrxRjDeM+PdSAXtsiNypT7TmjJn32x7I3OPeb3rS fsR2JHMwz2r1snn8QnOzfWHR/szD5sN5P7G/4vit/ZTjE8vHmZkFroJsDXOdrTmzqlzZx7NPZEvZ IkZdRfUGd+aC89s0h8vpaXXGndzp8zAIHPbnV7HpHhKyhWqVwSeWpnmkLM19BQbXXFgYfXApuWH2 co8Hbh6QMzw+4e7iDAsFWHl2YKGTOfPKi5YXrS/aWyQXuQJWLdNVBYePx3VEeBwbBoJ7FMGMB4/m 9WmTvPU+rciFBIvJJ1YdgjUSqx9D+xB5YBwkPMJICBkccoInzop+0LFBQCIGgNDgmSkGk8gVTB+w 2ecYxWigPkKi69NiLXQY6p0avOQUSp1CvVODs4RMJFZeh2V2TSRSx7KmY8V0bKCOCDMhAtRwqNpN 0ytJCuSIAJgQwkKxmHP5p8xX887B5N93rmXe10eZxzymSTs6G5aFpeuWXl5Xx9ji8gceeXb3nxEL keRPkse+u2seu2rLtrlzN4p9eiveau9DLITZ7CEqxQ7VkWWvhz5HtjnHUSVVWat8VcFG3mRt8jUG HapUXrrEFi/dXrq39HHzk5Z9jmfNzzr00pOlI6VOKi0vbUXD8dI3Ss2lWl5BVT3K241GkyUgW/IK c8RysVvErqYVyRZ3VlY4v6AgFLYzMrvcIU+Wtqw6nsXW49kyyJs1V15+qLAAdesLWLyAFaDuUEko FBZrK0EUFrPjstULrtXA7jBEw1oUVAcqDleFtVkXVJWHT4TfCEuusBLeHpYorIYrwqmwHPZP+mt6 RWKrE77Hr26Be9Q9VvcRZhZPk482dAhmLFI8+8SfWKsM00ggTM81EbGlsciEQLbY03KNnQ2vQXgy VoXFRmY2smKqjOxWJu0avmJPRfOjl296dFJh8q3C8KLZa6Ym3yqqr4muKUu+JYd2/6Dt0kvbll/e eN9YjC9/eGrdvF17kpw3P7hsSvON94+dwUJYjPX7AOYsE++t92rz3mZvWT+e8HG2/BP+tol7/Ca/ jcfcSycszYn57uX3me+z3usYtP2G/9H0J9tvHG+Z3jK/nel+0vpz/gvzS9YfO0ybrLeYb7RK8Djm JiNXzI1XtnhnWvLi+V35PN8ZIH9ee/oZkd68Foh1JI4BtKEDIYpdy7bWfQX2rLU+mXXE4JGOCVUe eISyvRScWBwqEVv5+J61uGfsoX+yquRP37sz+XEPU/esW3fPPevW7eETb2XmnuRP/vHP5Es3pvY/ vH9/30P794sYvQnHoVqM1037tUn3mpjNyZaYrjBtMknlnnbnGmeXB4cWl0Nx8DscKQevdyx0cMcg 36yVWizYjiVutk8im9tWYeuyyba8bZ69Hr7cs81z0HPSI3vcFGKS2KwzON/O+vAm78+qH2IFOFXh vLFhPCSwg2z4qMO/4DT5xJGjfhRBMxPvwkw80qhFz13SolfjsNxvr5wBBwTE8UNEQ67FmPss1odz kmnulY3x2NcuvGD24nI5dO+VjdUfTo0+lfwnxqik3ua7Td/HjL6qlaqksqC91DXLOd8Zc1n82eST crIp1zPBy3I93Mt8ks1itzh8g4xpLsrty9VzpTjYMJ7ng0xOZDPxYBqgbHF6xJPJkWErt5cTlbPl GB8ktEk+KZTruTS73rvXe9Arxb3bvb3ek973vSbyur2qt8Ire/151/WdPRm06LUY4WyMcIi8qeEZ sboF4oSJI5j7A79wyqhx6sSeeBpLI2u6Cz/hHZYdzPKKDas214ynPB731VnB6unVJVl8y3BGuCA8 37fiOxdvmZlhu/56lieHRpJtOyIF+X+YPH1R07R72ImR1x9P3gL/4FjM7/jZfzzTuNxV96HVb0UF 0StXfuOP5zg8aL4PT3GGM6eQFz9wy5zkJTTXTZ9++ukWnLjPtqTbiexmVPGn6KfyX+leeSNdBN4G HrUU0lbkF0uFdBPaFQBqcIuTYM/zSmmG7JF75DOmW9M6cN/1L6zLO3CLzhGl5bj9IfOn/EUc5Lkh 4RnXK27ZqW3R/LZLlkSi16ztvKqsYf1Vqxbgg4o4hxi/VJh+l859KbWjXEil1Ij7sXm4x1kMLV8j 6m/bHs2UnqaDIChHqoL6QBJp0tMDlsxKbRDc4zV4IidSOZQalp5OzJpu1JfdXbn9qHQA11XTUX0g camoPjCgNQrxAwPTZ6d5+TSDJ6zpZou3UonmAVYO4uQazy0EvwO0F3QcZIZBB+gNUAokSfulRxPN Cjp+Ah25ol7pCThGQ3oClAJJsP4JjOUJ+sd4jQyrHhuwOYT6xwxUvvQYUC6kbtB20EHQCZCJ1iPd C0qBJORwlQ3i0qPSIwm34o7apYdpG4hLD5CLiWU3LN034DZ8c/+Aa0KlFnVL91AriJMuLaBhEEe3 uwHbTRziLYmyaYYLWwbszko35HfB6F0wZBdU9iFlRllDTsjvGpiQI4y/IeHKMnDfTlRUpTMDbl9l K7xwHTFptbQOLyQKLsHX4apQkVaCF4KvkFZhoxd2agMud+V26KuHeD3uhEvRHJVycNOqSI1SHm75 hNimhDOtZ1Ni0uRKjHiu5DNEXFImLjkVySpZEpWKekTSDOffPGDLEPbdnHBnVx6TdkoWHAwVaTuk chXXMcmOObYbI2kbsGVW9kYdUhuG2Qa3KLCRwcsi1aR1CXQUzZKapAJ8mFGkK7F0ssGbpSKDPyk9 gs8hivT9gVCBMnxEustA3Sk6hfo56dCaM5DprByO2qQ5aNWl2zEBtxvKewdCM3ClHJImUQWIw8fb kNuGnFvqQa4Hs9aDmerBTPXAqB5EH0m3oOUWyJRLW6hL2ky9oL3Ii7DKTsChYjFkJ4onVQ5JfskH x7iPwJUMtXkDNqewzJfwTDDEfAMOZ2X9MWkjLQRxDLl7INdXuf6INNkYypQBX74AdCUQrsfwicOY GvSUI6bkmFQARwjHFEpFiWxFjyooi0BWiPGf8ZPCSfx1/hsx3eIrj8F/Ps5fHee/TPPUMD+ZXhT8 V4KPRAv4m+hsOf8z7UWO8yP8Jbw8K/hUNChmn/+eD1E9+CmUV4EPgU8Hfz4ReEUZ5IMDYLD9wURm jhgsfykRKR/PKCXjmdz88YwnpzJawl/kL+CNSeG/Ay8Gf4EP48ukwo+D+8CHeTdu9RX+LK/GN08F X4DS/D/4URHi/Dl+GDfuCh9IOIUJesIi2MGEWbAfJihdai1XjvIf8gOUB9FnEqE8NO4fCBUrriPo j+GbWHeiUPFE7fwR1s4+gFAf7uPBycMfTdSKTnoTR1VliPfyXs1Xq5VoZdo+qaKkoqxin6SWqGVq rbpPjbr57dhA9nKsX74LaS2pHNED0kC9/JaEXKtHxzAmMS5O25H2Gbk40i4jR0jdRk60vm/k6vlO Wgji6GMraBtoO+h6XMn08i2gb4O+A/quUdON3CbQZuwmXUB0AdEFRJeB6AKiC4guILoMhNDcBUSX gYgDEQciDkTcQMSBiAMRByJuIIS9cSDiBqIViFYgWoFoNRCtQLQC0QpEq4FoBaIViFYDoQGhAaEB oRkIDQgNCA0IzUBoQGhAaAaiAogKICqAqDAQFUBUAFEBRIWBqACiAogKA6ECoQKhAqEaCBUIFQgV CNVAqECoQKgGwg2EGwg3EG4D4QbCDYQbCLeBcAPhBsJtIEaAGAFiBIgRAzECxAgQI0CMGIgRIEaA GOGb+6WT0ZcBOQnISUBOGpCTgJwE5CQgJw3ISUBOAnJyfOjCESJghoEdBnYY2GEDOwzsMLDDwA4b 2GFIDgM7bGB1IHQgdCB0A6EDoQOhA6EbCB0IHQjdQPQB0QdEHxB9BqIPiD4g+oDoMxB9QPQB0Wcg eoHoBaIXiF4D0QtELxC9QPQaiF4geoHoNRD/31PDr2ftVjxrcbwuNfg2es/gW+mUwb9L/Qb/Du0z +Ldph8G3UK3BN1PI4Jhqg3eTYmUJpdYVzcEWsBC0HLQetBd0EHQcZDFyJ5B7A5Ti1dpE2WVZaNlr OWg5bjEdtIxYuAv3jnvNB83HzaaD5hEzV6P5PNPYR7G10B3AMdqG9B8gPESQ1hu5el4FvVXYZ6vx V8WrtKxR9R+T2YnJ7PhkdnAyu2Myi9r4hUw2djqVanG1q7B2zRGao5wC1YbCc7Az3X74vVwlEapR BtnRNCvVIii+B+oH7QPtANWCKkFloBKQAqoNTQasXZs43uVR8DAoAFJBtZSD/61DniyrNsQz2b6B lzPJJvSEJwF3JBGuABtMhBeCPZcIr1CiNnYYFwHC0GexqA6AH0wop9H8TJo9nVCOoLQ/oVSBdSTC U8EuS4RfVaKZ7FJS8H9eFNY2zpdgwkV5cUJZCrFFCaUULJIIh4T0ZCgqQWspa6fT4Mgb6OK0pmBC mQ3piQllppC2UlhMPL5NlxnmmZAXZWkABv1jiLXLTMtQRpW7lPdg79/hWITH79VBGexEySBbqtmV o2UPQziqJKJ2IY/nQ/841wV/VtlXcovyIPpiJYeV+5Wpyu1lg1ZU3wa7bzFUJJQd+GZzQJugbFcq lO6y08pGZb7SqSxWOkpQn1AuV44KMynG2vmBw0orOrwIoyhJKBeWwBaY2Kx8S9GUsDJTPSr8SzOE akRy2VHhAdxHG9qnwL+TS6A9oVxaO8iytMmW9y29lsssDZbZlqBloqXIUmjxWj1Wt9VpdVjtVqvV bJVxpU5W72BqRIuI9xyv2XjdMcuiIBt5N94xGOJYpLhpt3KaT/oEqYW3LGlgLfrwSmpZoeofLQkO MvuiZbop2MB0Twu1tDXoMyItg5bUYr020qJbWi9r72fs9hhqdX7zIKO29kGWElU788W3x35GO2/L HyLG/Dtvi8XIl3Ntva/eMydrZnPjVyRxozLemL6DMVLf53lfpFDf07KkXX+qMKZXikyqMNaiXy++ TA5xF89sahziTsFi7UNyF3c1LRb1cldjDGKnDTFEsxNiFBYMYtYGUoUY9pMGIYY5SsuFAIdcQDDI 2TMpZMiF7JmGnMyEXP8ptamxH9+JhUwJ0SlD5lQJfUEGEQNsY38ICaSCKmsXUgxfoA3DSo2OFAUi ZUggwnDuMzpSmKFML/9cpGRcpPqcSLWhS0rbY3QjEnTjnXRWxjsJMp878n+XW90QYQPTNm19qQkf e+PBptWguL7r2jU+ffsKVe3fukk04JtrKL5i5RrBO1frm4KrG/WtwUa1f5qB+1LzS6J5WrCxn15q amvvf0lb3ZiYpk1rCnY2xgbq69qj5+m65Zyu9rqv0FUnOmsXuuoN3Jd0RUVzvdAVFbqiQle9Vm/o alor4r61vd9KDTFczBp8gGfYEcPx/ECsIcfdNUcE9NDsgG9r/vMy4X/uZOAjrAOf7TNBoqksWhYV TVhnoskpvuiPN/m2zg7kP8/2jze5UZ0VbDAuesVkkMCLa6MWPYAPgiJU8Nn9q+dso/gZzT5qWtuI fyh3G9S9sfuLU0tC8n/+ur/qt2nTpo3dSDZFcBncok/GFU+NuMSyWKAq3hhD3dSzdZJk1PXbbE24 b0VjBEawbqFO5CJMXIRrdjKThfeZ+yxcvEV0D+QVVq4/hnPDNhBeh/nmBK4SRNPmgYkleFuCSHl1 muN1VZQTeYFKcbNbC6jgJWmuZZUh01vSW9Zb21fSV9ZXa0br4X2oVPaJR2mifJ9E3ZGNZ52BbHcM zhb389D3SKKg0FDcJzK4ao9sZMYsnJX/nBv1KH7uWIzR+G00uhf+NjyMVGQxlaIV85HWvkmUxC+d MbDwswFCLaTSJaNKJJ//UCL6b6MwRIYKZW5kc3RyZWFtCmVuZG9iagoxMDAgMCBvYmoKNzkxMApl bmRvYmoKMTAxIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDkwNSAvQ2Fw SGVpZ2h0IDcyMiAvRGVzY2VudCAtMjEyIC9GbGFncyAzMgovRm9udEJCb3ggWy02MjggLTM3NiAy MDAwIDEwMTFdIC9Gb250TmFtZSAvVFFKVE5TK0FyaWFsLUJvbGRNVCAvSXRhbGljQW5nbGUKMCAv U3RlbVYgMCAvTGVhZGluZyAzMyAvTWF4V2lkdGggMjAwMCAvWEhlaWdodCA1MjUgL0ZvbnRGaWxl MiA5OSAwIFIgPj4KZW5kb2JqCjEwMiAwIG9iagpbIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NjExIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCA1 NTYgMCAwIDYxMSA1NTYgMCAwIDAgMCAwIDAgMCA4ODkgMCA2MTEgMCAwIDM4OSAwIDMzMyBdCmVu ZG9iagozNyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250 IC9UUUpUTlMrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgoxMDEgMCBSIC9XaWR0aHMgMTAy IDAgUiAvRmlyc3RDaGFyIDU4IC9MYXN0Q2hhciAxMTYgL0VuY29kaW5nIC9NYWNSb21hbkVuY29k aW5nCj4+CmVuZG9iagoxIDAgb2JqCjw8IC9UaXRsZSAoc2VjdGlvbi0xNi1mb3ItUlBMLXJldi0x MSkgL0F1dGhvciAoSlAgVmFzc2V1cikgL1N1YmplY3QgKCkgL0FBUEw6S2V5d29yZHMKWyAoKSBd IC9LZXl3b3JkcyAoKSAvQ3JlYXRvciAoTWljcm9zb2Z0IFdvcmQpIC9Qcm9kdWNlciAoTWFjIE9T IFggMTAuNS44IFF1YXJ0eiBQREZDb250ZXh0KQovQ3JlYXRpb25EYXRlIChEOjIwMTAwNzIwMTQ0 ODU5WjAwJzAwJykgL01vZERhdGUgKEQ6MjAxMDA3MjAxNDQ4NTlaMDAnMDAnKQo+PgplbmRvYmoK eHJlZgowIDEwMwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAxNDE4MzAgMDAwMDAgbiAKMDAwMDAw NTQ0MiAwMDAwMCBuIAowMDAwMDk1NDY5IDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAw MDAwNTQyMiAwMDAwMCBuIAowMDAwMDA1NTQ2IDAwMDAwIG4gCjAwMDAwMDY1NTggMDAwMDAgbiAK MDAwMDEyMTg0NiAwMDAwMCBuIAowMDAwMDA1NjQ0IDAwMDAwIG4gCjAwMDAwMDY1MzggMDAwMDAg biAKMDAwMDAxMzY2OCAwMDAwMCBuIAowMDAwMDA2NTkzIDAwMDAwIG4gCjAwMDAwMTM2NDcgMDAw MDAgbiAKMDAwMDAxMzc3NSAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAxMzMwNjEg MDAwMDAgbiAKMDAwMDEyNzQzNyAwMDAwMCBuIAowMDAwMDE0NjYzIDAwMDAwIG4gCjAwMDAwMTM5 MDAgMDAwMDAgbiAKMDAwMDAxNDY0MyAwMDAwMCBuIAowMDAwMDE0NzcwIDAwMDAwIG4gCjAwMDAw MjUxMzYgMDAwMDAgbiAKMDAwMDAxNDg2OSAwMDAwMCBuIAowMDAwMDI1MTE0IDAwMDAwIG4gCjAw MDAwMjUyNDMgMDAwMDAgbiAKMDAwMDAyNTQxOSAwMDAwMCBuIAowMDAwMDI1Njc3IDAwMDAwIG4g CjAwMDAwMjg2NjcgMDAwMDAgbiAKMDAwMDAyNTY5NiAwMDAwMCBuIAowMDAwMDI1OTA5IDAwMDAw IG4gCjAwMDAwMjU5MjggMDAwMDAgbiAKMDAwMDAyODY0NiAwMDAwMCBuIAowMDAwMDMyMzgwIDAw MDAwIG4gCjAwMDAwMjg3MDQgMDAwMDAgbiAKMDAwMDAzMjM1OSAwMDAwMCBuIAowMDAwMDMyNDg3 IDAwMDAwIG4gCjAwMDAxNDE2NTAgMDAwMDAgbiAKMDAwMDA0MDExMiAwMDAwMCBuIAowMDAwMDMy Njc2IDAwMDAwIG4gCjAwMDAwNDAwOTEgMDAwMDAgbiAKMDAwMDA0MDIxOSAwMDAwMCBuIAowMDAw MDU0NzUzIDAwMDAwIG4gCjAwMDAwNDAzOTUgMDAwMDAgbiAKMDAwMDA1NDczMSAwMDAwMCBuIAow MDAwMDU0ODYwIDAwMDAwIG4gCjAwMDAwNjE4OTUgMDAwMDAgbiAKMDAwMDA1NTA0OSAwMDAwMCBu IAowMDAwMDYxODc0IDAwMDAwIG4gCjAwMDAwNjIwMDIgMDAwMDAgbiAKMDAwMDA2NzA3MyAwMDAw MCBuIAowMDAwMDk1NTkyIDAwMDAwIG4gCjAwMDAwNjIxNzggMDAwMDAgbiAKMDAwMDA2NzA1MiAw MDAwMCBuIAowMDAwMDY3MTgxIDAwMDAwIG4gCjAwMDAwNzEyNDAgMDAwMDAgbiAKMDAwMDA2NzI4 MCAwMDAwMCBuIAowMDAwMDcxMjE5IDAwMDAwIG4gCjAwMDAwNzEzNDggMDAwMDAgbiAKMDAwMDA3 NTQwMyAwMDAwMCBuIAowMDAwMDcxNDQ3IDAwMDAwIG4gCjAwMDAwNzUzODIgMDAwMDAgbiAKMDAw MDA3NTUxMSAwMDAwMCBuIAowMDAwMDgwNDQ5IDAwMDAwIG4gCjAwMDAwNzU2MTAgMDAwMDAgbiAK MDAwMDA4MDQyOCAwMDAwMCBuIAowMDAwMDgwNTU3IDAwMDAwIG4gCjAwMDAwODcyMTMgMDAwMDAg biAKMDAwMDA4MDY1NiAwMDAwMCBuIAowMDAwMDg3MTkyIDAwMDAwIG4gCjAwMDAwODczMjEgMDAw MDAgbiAKMDAwMDA5Mjk1OSAwMDAwMCBuIAowMDAwMDg3NDk3IDAwMDAwIG4gCjAwMDAwOTI5Mzgg MDAwMDAgbiAKMDAwMDA5MzA2NyAwMDAwMCBuIAowMDAwMDk0NDc2IDAwMDAwIG4gCjAwMDAwOTMx NjYgMDAwMDAgbiAKMDAwMDA5NDQ1NSAwMDAwMCBuIAowMDAwMDk0NTg0IDAwMDAwIG4gCjAwMDAw OTUyNjIgMDAwMDAgbiAKMDAwMDA5NDY4MyAwMDAwMCBuIAowMDAwMDk1MjQyIDAwMDAwIG4gCjAw MDAwOTUzNzAgMDAwMDAgbiAKMDAwMDA5NTcxNyAwMDAwMCBuIAowMDAwMDk1ODA5IDAwMDAwIG4g CjAwMDAwOTU4NzQgMDAwMDAgbiAKMDAwMDEyMTIzMSAwMDAwMCBuIAowMDAwMTIxMjUzIDAwMDAw IG4gCjAwMDAxMjE0ODggMDAwMDAgbiAKMDAwMDEyMjAxOCAwMDAwMCBuIAowMDAwMTI2OTY1IDAw MDAwIG4gCjAwMDAxMjY5ODYgMDAwMDAgbiAKMDAwMDEyNzIzMyAwMDAwMCBuIAowMDAwMTI3NjIw IDAwMDAwIG4gCjAwMDAxMzI0NTkgMDAwMDAgbiAKMDAwMDEzMjQ4MCAwMDAwMCBuIAowMDAwMTMy NzIwIDAwMDAwIG4gCjAwMDAxMzI3NDIgMDAwMDAgbiAKMDAwMDEzMzA0MSAwMDAwMCBuIAowMDAw MTMzMjI4IDAwMDAwIG4gCjAwMDAxNDEyMzAgMDAwMDAgbiAKMDAwMDE0MTI1MiAwMDAwMCBuIAow MDAwMTQxNDkzIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTAzIC9Sb290IDg0IDAgUiAvSW5m byAxIDAgUiAvSUQgWyA8YTViOWUzOWE2ZmQ1Mzc4ODkxNDYwOGUyZGUxNTk2MzA+CjxhNWI5ZTM5 YTZmZDUzNzg4OTE0NjA4ZTJkZTE1OTYzMD4gXSA+PgpzdGFydHhyZWYKMTQyMTAxCiUlRU9GCg== --Apple-Mail-77-682709217 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi = Mathilde,

On Jul 19, 2010, at 9:35 AM, Mathilde Durvy = (mdurvy) wrote:

Hi = JP,
Thanks for updating = Section 16. A few minor points = below.

Sure, in = line.

Best,
- In 16.2.3, 16.2.4 It is not very clear which = parameters are configured versus negotiated dynamically through = messages.
All the parameters are the ones that a RPL MAY/SHOULD/MUST = allow for configuration = only. I will add some text to = clarify.
[Mathilde] I'm not sure what you mean by 'configuration only'. = Do you mean not negotiated dynamically? =

Right.
Then it seems = to me that parameters that are part of the policy must be configured = while other may be. For some parameters (OCP, Route information, = DODAGID, MOP) it is still not specified in which category (may, should, = must) they = belong
JP> I see what you're referring to; a sentence was = missing in 16.2.3 and 16.2.4. Added.


- In 16.2.4 =93A = RPL implementation SHOULD allow configuring whether a non-storing node = provides the transit information in DAO messages.=94 Shouldn=92t a node = always include the transit info in DAO messages?Correct, what = I meant was the requirement to configure the MOP (this was already in = 16.2.5), which implies to send transit information for non storing mode, = but this was not clear indeed. I removed it from there. By the way, I = added the Route information and Prefix information that were = missing.
[Mathilde] Shouldn't = Route information and Prefix information be in 16.2.3 (right now they = are also in 16.2.4 and 16.2.5, so we have a problem :-) ). =  
=
JP> Yes ! Done.

I would also add some text on what it = means to configure the target prefix. This is not very clear to me. Do = you mean decide which of the node's addresses / prefixes should be in a = target = option?


JP> Yes. I prefer to leave it as is, since = the target option may be augmented in the future.

Aren=92t the 2 = first bullet related to the DAO mechanism and hence more appropriate in = Section 16.2.6 (or maybe we should just remove Section = 16.2.6)
Yes I updated 16.2.6, which was outdated after we removed the = DAO FSM. Thanks.
[Mathilde] Thanks. Maybe 16.2.4 Target option should also go = there

- In general, = Sections 16.3 to 16.5 can be difficult to implement on constrained nodes = without interface or file system. I would emphasize that it is expected = that constrained nodes do not implement these = parts.
Not sure is you saw it, = but there is already pretty explicit text in Section 16.1:
   When memory is highly =
constrained, it may
   not be possible to =
satisfy all the requirements listed in this
[Mathilde] Well the =
=91may=92 is a bit weak in my opinion. But I'm OK to keep it as =
is.
Attached the =
changes. Let me know if you agree with the proposed resolution and I'll =
close the ticket.

= --Apple-Mail-77-682709217-- --Apple-Mail-76-682709216-- From pthubert@cisco.com Tue Jul 20 08:38:51 2010 Return-Path: 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 B6DDA3A68B5 for ; Tue, 20 Jul 2010 08:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 g-SYV7QM6uTC for ; Tue, 20 Jul 2010 08:38:50 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A29CC3A68CC for ; Tue, 20 Jul 2010 08:38:50 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 15:38:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KFcmcp020877; Tue, 20 Jul 2010 15:38:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:38:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 20 Jul 2010 17:38:17 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260A1FE@XMB-AMS-107.cisco.com> In-Reply-To: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #67: DODAG Default Path Lifetime thread-index: AcskO9yWV41+VzevSfWbLJkXe7fL/QD5GqVA References: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 20 Jul 2010 15:38:45.0751 (UTC) FILETIME=[A3CF8870:01CB2821] Subject: Re: [Roll] [roll] #67: DODAG Default Path Lifetime 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: , X-List-Received-Date: Tue, 20 Jul 2010 15:38:51 -0000 V2hpbGUgd2UgYXJlIGF0IHJlZmluaW5nIHRoZSB0cmFuc2l0IG9wdGlvbiBmb3JtYXQ6DQoNCkl0 IGFwcGVhcnMgdGhhdCBpbiBtYW55IGNhc2VzLCB0aGVyZSB3aWxsIGJlIGEgc2luZ2xlIHN1Ym5l dCBpbiBhbiBpbnN0YW5jZS4gSW4gdGhhdCBjYXNlLCBhbGwgdGhlIHBhcmVudHMgd2lsbCBoYXZl IHRoZSBzYW1lIHByZWZpeC4NCkluIGEgc291cmNlIHJvdXRlIERBTywgd2UgY2FuIHRoaXMgc29t ZXRpbWVzIGVsaWRlIHRoZSBwcmVmaXggb2YgdGhlIHBhcmVudC4gRWl0aGVyIGJ5IHBsYWNpbmcg aXQgb25seSBvbiB0aGUgZmlyc3QgcGFyZW50LCBvciBtYWtpbmcgaXQgZnVsbHkgaW1wbGljaXQu DQpGb3IgdGhlIHRpbWUgYmVpbmcsIEkgcHJvcG9zZSBhIGZsYWcgaW4gdGhlIHRyYW5zaXQgc2F5 aW5nIHRoYXQgdGhlIHByZWZpeCBvZiB0aGUgcGFyZW50IGlzIGVsaWRlZCwgZm9yIHVzZSBpbiBh bGwgdGhlIG5leHQgcGFyZW50cy4NCklmIHlvdSBkaXNhZ3JlZSBwbGVhc2UgY2hpbWUgaW4uIA0K SWYgeW91IHdhbnQgdG8gZWxpZGUgaXQgaW4gYWxsIHBhcmVudHMsIHBsZWFzZSBwcm9wb3NlIGEg c2ltcGxlIG1lY2hhbmlzbSB0aGF0IGFsbG93cyB1bmFtYmlndW91c2x5IHRvIGZpbmQgd2hhdCB0 aGUgcHJlZml4IGlzLg0KDQpUaGFua3MgYWdhaW4hDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygcm9sbA0KPiBpc3N1ZSB0cmFja2Vy DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE1LCAyMDEwIDY6MzYgUE0NCj4gVG86IHdpbnRlcnRA YWNtLm9yZzsganB2QGNpc2NvLmNvbQ0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBb Um9sbF0gW3JvbGxdICM2NzogRE9EQUcgRGVmYXVsdCBQYXRoIExpZmV0aW1lDQo+IA0KPiAjNjc6 IERPREFHIERlZmF1bHQgUGF0aCBMaWZldGltZQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiAgUmVwb3J0ZXI6ICBqcHZA4oCmICAgICAg ICAgICAgfCAgICAgICBPd25lcjogIHdpbnRlcnRA4oCmDQo+ICAgICAgVHlwZTogIGVuaGFuY2Vt ZW50ICAgICAgfCAgICAgIFN0YXR1czogIG5ldw0KPiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAg ICAgIHwgICBNaWxlc3RvbmU6DQo+IENvbXBvbmVudDogIHJwbCAgICAgICAgICAgICAgfCAgICAg VmVyc2lvbjoNCj4gIFNldmVyaXR5OiAgSW4gV0cgTGFzdCBDYWxsICB8ICAgIEtleXdvcmRzOg0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0K PiAgRW1haWwgc2VudCBmcm9tIFJvZ2VyIEp1bHkgMTQNCj4gDQo+ICBTdWJqZWN0OiBbUm9sbF0g RE9EQUcgRGVmYXVsdCBQYXRoIExpZmV0aW1lDQo+ICBEYXRlOiBXZWQsIDE0IEp1bCAyMDEwIDE2 OjAyOjIwIC0wNDAwDQo+ICBGcm9tOiBBbGV4YW5kZXIsIFJvZ2VyIDxSb2dlci5BbGV4YW5kZXJA Y29vcGVyaW5kdXN0cmllcy5jb20+DQo+ICBUbzogcm9sbCA8cm9sbEBpZXRmLm9yZz4NCj4gDQo+ ICBIaSBXRywNCj4gDQo+ICBJIHdvdWxkIGxpa2UgdG8gcmVjb21tZW5kIHVzZSBvZiBhIERPREFH LWRlZmluZWQgRGVmYXVsdCBQYXRoIExpZmV0aW1lICBhcw0KPiBvcHBvc2VkIHRvIHRoZSBjdXJy ZW50IG1vZGVsIGluIHdoaWNoIFBhdGggTGlmZXRpbWUgaXMgc3BlY2lmaWVkIHBlciAgcHJlZml4 DQo+IHVzaW5nIHRoZSBUcmFuc2l0IEluZm9ybWF0aW9uIE9wdGlvbi4NCj4gDQo+ICBBcyBpbiBv dGhlciByb3V0aW5nIHByb3RvY29scywgc3VjaCBhcyBSSVAgZm9yIGV4YW1wbGUsIHRoZSB2YWxp ZGl0eSAgcGVyaW9kIG9mIGFuDQo+IGFkdmVydGlzZWQgcHJlZml4IGlzIGRlZmluZWQgbm90IHBl ciBkZXN0aW5hdGlvbiBhZGRyZXNzICBidXQgaXMgc3BlY2lmaWVkIHRocm91Z2gNCj4gYSBwcm90 b2NvbCBjb25maWd1cmF0aW9uIGVsZW1lbnQgc3VjaCBhcyB0aGUgIHJvdXRlLXRpbWVvdXQgdGlt ZXIuIEluIHRoZSBzYW1lDQo+IHZlaW4sIGEgZGVmYXVsdCB2YWxpZGl0eSBwZXJpb2QgY2FuIGJl ICBkZWZpbmVkIGZvciBhbGwgYWR2ZXJ0aXNlZCBkZXN0aW5hdGlvbnMNCj4gdGhyb3VnaCBhIERl ZmF1bHQgUGF0aCBMaWZldGltZSAgc3BlY2lmaWVkIHdpdGhpbiB0aGUgRE9EQUcgQ29uZmlndXJh dGlvbg0KPiBvcHRpb24uIFRoaXMgZGVmYXVsdCB2YWx1ZSB3aWxsICBhcHBseSB0byBhbGwgYWR2 ZXJ0aXNlZCBwcmVmaXhlcyB1bmxlc3Mgb3RoZXJ3aXNlDQo+IHNwZWNpZmllZCB1c2luZyBhbiAg b3B0aW9uYWwgUGF0aCBMaWZldGltZSBpbmZvcm1hdGlvbiBlbGVtZW50IHdpdGhpbiB0aGUNCj4g VHJhbnNpdCAgSW5mb3JtYXRpb24gb3B0aW9uLiBUaGUgYmVuZWZpdCBvZiBhIERlZmF1bHQgUGF0 aCBMaWZldGltZSBpcyB0aGF0IGl0ICB3aWxsDQo+IGFsbG93IDQtYnl0ZXMgdG8gYmUgc2F2ZWQg cGVyIGFkdmVydGlzZWQgREFPIGRlc3RpbmF0aW9uIHVubGVzcyBhICBzcGVjaWZpYywNCj4gZGVk aWNhdGVkIFBhdGggTGlmZXRpbWUgaXMgbmVlZGVkIGZvciBhIGdpdmVuIHByZWZpeC4gVGhlICBM aWZldGltZSBmb3IgYQ0KPiBkZXN0aW5hdGlvbiBhZGRyZXNzIHdpbGwgY29udGludWUgdG8gYXBw bHkgZnJvbSB0aGUgdGltZSAgb2YgcmVjZWlwdCBhdCBhIG5vZGUuDQo+IA0KPiAgTm8gYWRkaXRp b25hbCBjb250cm9sIGJpdHMgd2lsbCBiZSByZXF1aXJlZCB3aXRoaW4gdGhlIFRyYW5zaXQgIElu Zm9ybWF0aW9uDQo+IE9wdGlvbiBhcyB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiB0aGUgUGF0 aCBMaWZldGltZSAgaW5mb3JtYXRpb24gZWxlbWVudA0KPiBjYW4gYmUgZGlyZWN0bHkgZGVkdWNl ZCBmcm9tIHRoZSB2YWx1ZSBvZiB0aGUgT3B0aW9uICBMZW5ndGguDQo+IA0KPiAgVGhhbmtzLg0K PiANCj4gIFJvZ2VyDQo+IA0KPiAtLQ0KPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9zdm4udG9vbHMu aWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC82Nz4NCj4gcm9sbCA8aHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL3JvbGwvPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From jpv@cisco.com Tue Jul 20 08:46:30 2010 Return-Path: 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 4F1423A687E for ; Tue, 20 Jul 2010 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 o07cDtJidPoZ for ; Tue, 20 Jul 2010 08:46:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DB09D3A68D7 for ; Tue, 20 Jul 2010 08:46:28 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB9hRUyrRN+J/2dsb2JhbACfbXGlcJsyhTIEiFmCNQ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 15:46:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KFkYCa023195; Tue, 20 Jul 2010 15:46:44 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:46:40 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:46:39 +0200 Message-Id: <5EE13385-1D67-4461-9216-1CBD34D47433@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260A1FE@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 17:46:36 +0200 References: <055.24afab409f6fd66bd5fdf29f9aaaa70b@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D0260A1FE@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 15:46:39.0777 (UTC) FILETIME=[BE5A2910:01CB2822] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #67: DODAG Default Path Lifetime 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: , X-List-Received-Date: Tue, 20 Jul 2010 15:46:30 -0000 On Jul 20, 2010, at 5:38 PM, Pascal Thubert (pthubert) wrote: > While we are at refining the transit option format: > > It appears that in many cases, there will be a single subnet in an =20 > instance. In that case, all the parents will have the same prefix. > In a source route DAO, we can this sometimes elide the prefix of the =20= > parent. Either by placing it only on the first parent, or making it =20= > fully implicit. > For the time being, I propose a flag in the transit saying that the =20= > prefix of the parent is elided, for use in all the next parents. > If you disagree please chime in. > If you want to elide it in all parents, please propose a simple =20 > mechanism that allows unambiguously to find what the prefix is. > I would not add anything to the spec at this point. Could be a =20 separate ID to optimize bw. Thanks. JP. > Thanks again! > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Thursday, July 15, 2010 6:36 PM >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #67: DODAG Default Path Lifetime >> >> #67: DODAG Default Path Lifetime >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Email sent from Roger July 14 >> >> Subject: [Roll] DODAG Default Path Lifetime >> Date: Wed, 14 Jul 2010 16:02:20 -0400 >> From: Alexander, Roger >> To: roll >> >> Hi WG, >> >> I would like to recommend use of a DODAG-defined Default Path =20 >> Lifetime as >> opposed to the current model in which Path Lifetime is specified =20 >> per prefix >> using the Transit Information Option. >> >> As in other routing protocols, such as RIP for example, the =20 >> validity period of an >> advertised prefix is defined not per destination address but is =20 >> specified through >> a protocol configuration element such as the route-timeout timer. =20= >> In the same >> vein, a default validity period can be defined for all advertised =20= >> destinations >> through a Default Path Lifetime specified within the DODAG =20 >> Configuration >> option. This default value will apply to all advertised prefixes =20 >> unless otherwise >> specified using an optional Path Lifetime information element =20 >> within the >> Transit Information option. The benefit of a Default Path Lifetime =20= >> is that it will >> allow 4-bytes to be saved per advertised DAO destination unless a =20= >> specific, >> dedicated Path Lifetime is needed for a given prefix. The Lifetime =20= >> for a >> destination address will continue to apply from the time of =20 >> receipt at a node. >> >> No additional control bits will be required within the Transit =20 >> Information >> Option as the presence or absence of the Path Lifetime information =20= >> element >> can be directly deduced from the value of the Option Length. >> >> Thanks. >> >> Roger >> >> -- >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Jul 20 08:49:24 2010 Return-Path: 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 9245E3A68BC for ; Tue, 20 Jul 2010 08:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 tAboV6J0JxxL for ; Tue, 20 Jul 2010 08:49:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0D6B33A683C for ; Tue, 20 Jul 2010 08:49:23 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMNiRUyrR7Hu/2dsb2JhbACBQ54qcaV3mzKFMgSIWYI1hw8 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 15:49:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KFna3l028376; Tue, 20 Jul 2010 15:49:38 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:49:36 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 17:49:35 +0200 Message-Id: <271188C6-2DB2-4A44-9275-E4D933CC28DB@cisco.com> From: JP Vasseur To: Omprakash Gnawali , roll WG , "dominique.barthel@orange-ftgroup.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF016C115B@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/alternative; boundary=Apple-Mail-97-686063466 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 17:49:34 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF016C115B@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 15:49:35.0469 (UTC) FILETIME=[2712A1D0:01CB2823] Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08 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: , X-List-Received-Date: Tue, 20 Jul 2010 15:49:24 -0000 --Apple-Mail-97-686063466 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On Jul 13, 2010, at 3:38 PM, = wrote: > Hello Omprakash, > > Thanks for your time reading the draft and commenting. > > Yes, the semantic behind ordering is intentional. Some priority =20 > mechanism was needed and we proposed to use order of appearance in =20 > the packet as the semantic. We welcome comments on that use, =20 > especially if this is improper practice in the IP world. > It is not improper. Still WG feed-back on this issue is welcome ? Further, comments on Section 8 are really welcome: 8. Metric usage This section describes how metrics carried in the DAG Metric Container shall be used. When the DAG Metric Container contains a single aggregated metric (scalar value), the order relation to select the best path is implicitely derived from the metric type. For example, lower is better for Hop Count, Link Latency, ETX and Fanout Ratio. For Node Energy or Throughput, higher is better. An exemple of using such a single aggregated metric is optimizing routing for node energy. The Node Energy metric (E-E field) is aggregated along pathes with an explicit min function (A field), and the best path is selected through an implied Max function because =20= the metric is Energy. When the DAG Metric Container contains several aggregated metrics, they are to be used as tie-brakers in the order that they appear in the DAG Metric Container. A node propagating a DAG Metric Container MUST keep the order of metric objects unchanged. An example of such use of multiple aggregated metrics is the following: Hop-Count as the primary criterion, LQL as the secondary criterion and Fanout Ratio as the ultimate tie-braker. In such a case, the Hop-Count, LQL and Fanout Ratio metric objects need to appear in that order in the DAG Metric Container. The use of compound metrics, such as a polynomial function of individual metric values, will be described in a future revision of this document. The use of recorded metrics will be described in a future revision =20= of this document. > Regarding nodes making their own decisions on objective, that's a =20 > different issue. I don't see that a node by itself should have the =20 > right to prefer one objective versus another one. It is my =20 > understanding that the RPL instance dictates what the objective is, =20= > and the nodes that join that instance have to adhere to it or become =20= > leaf nodes. Am I mistaken here? You are correct. This is specified in the RPL spec. > > So far, to my knowledge, there is no case in the -08 draft, other =20 > than the ones listed in 8 and 3.2, where order matters. > We have strong langage with MUSTs in these paragraphs, the text "the =20= > order is significant" you quote is just a forewarning early in the =20 > draft. > > Thanks again, and comments welcome from all. > Best, > > Dominique > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part =20= > de Omprakash Gnawali > Envoy=E9 : samedi 10 juillet 2010 01:17 > =C0 : ROLL WG > Objet : [Roll] metric ordering according todraft-ietf-roll-routing-=20 > metrics-08 > > "8. > ... > When the DAG Metric Container contains several aggregated metrics, > they are to be used as tie-brakers in the order that they appear in > the DAG Metric Container. A node propagating a DAG Metric Container > MUST keep the order of metric objects unchanged. > > An example of such use of multiple aggregated metrics is the > following: Hop-Count as the primary criterion, LQL as the secondary > criterion and Fanout Ratio as the ultimate tie-braker. In such a > case, the Hop-Count, LQL and Fanout Ratio metric objects need to > appear in that order in the DAG Metric Container. > > ..." > > Is the semantics behind the ordering intentional? > > A packet could be forwarded from a node that prefers to use one set =20= > of objective to a node that prefers to use a different objective. =20 > For example, from a low power energy scavenging sensor to a powered =20= > node. > Not allowing the nodes to change the order allows a node to dictate =20= > the relative importance of this metric to rest of the network =20 > without regard to their preference. > > If we had already considered that scenario and determined to be not =20= > important, it might be worth making the last sentence in the =20 > following paragraph stronger - are there other cases besides those =20 > mentioned in > 8 and 3.2? > > "2. > ... > Note that the Routing Metric/Constraint objects defined in this > document can appear in any order in the DAG Metric Container. > However, for some of them, the order is significant (as described in > Section 8 and Section 3.2, for example). > " > > - om_p > _______________________________________________ > 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 --Apple-Mail-97-686063466 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,


Hello = Omprakash,

Thanks for your time reading the draft and = commenting.

Yes, the semantic behind ordering is intentional. = Some priority mechanism was needed and we proposed to use order of = appearance in the packet as the semantic. We welcome comments on that = use, especially if this is improper practice in the IP = world.


It is not improper. = Still WG feed-back on this issue is welcome = ?

Further, comments on Section 8 are really = welcome:

8.  Metric =
usage

   This section describes how metrics carried in the DAG Metric
   Container shall be used.

   When the DAG Metric Container contains a single aggregated metric
   (scalar value), the order relation to select the best path is
   implicitely derived from the metric type.  For example, lower is
   better for Hop Count, Link Latency, ETX and Fanout Ratio.  For Node
   Energy or Throughput, higher is better.

   An exemple of using such a single aggregated metric is optimizing
   routing for node energy.  The Node Energy metric (E-E field) is
   aggregated along pathes with an explicit min function (A field), and
   the best path is selected through an implied Max function because the
   metric is Energy.

   When the DAG Metric Container contains several aggregated metrics,
   they are to be used as tie-brakers in the order that they appear in
   the DAG Metric Container.  A node propagating a DAG Metric Container
   MUST keep the order of metric objects unchanged.

   An example of such use of multiple aggregated metrics is the
   following: Hop-Count as the primary criterion, LQL as the secondary
   criterion and Fanout Ratio as the ultimate tie-braker.  In such a
   case, the Hop-Count, LQL and Fanout Ratio metric objects need to
   appear in that order in the DAG Metric Container.

   The use of compound metrics, such as a polynomial function of
   individual metric values, will be described in a future revision of
   this document.

   The use of recorded metrics will be described in a future revision of
   this document.

Regarding nodes making their own decisions on = objective, that's a different issue. I don't see that a node by itself = should have the right to prefer one objective versus another one. It is = my understanding that the RPL instance dictates what the objective is, = and the nodes that join that instance have to adhere to it or become = leaf nodes. Am I mistaken = here?

You are correct. This is = specified in the RPL spec.


So = far, to my knowledge, there is no case in the -08 draft, other than the = ones listed in 8 and 3.2, where order matters.
We have strong langage = with MUSTs in these paragraphs, the text "the order is significant" you = quote is just a forewarning early in the draft.

Thanks again, and = comments welcome from all.
Best,

Dominique

-----Message = d'origine-----
De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = De la part de Omprakash Gnawali
Envoy=E9 : samedi 10 juillet 2010 = 01:17
=C0 : ROLL WG
Objet : [Roll] metric ordering according = todraft-ietf-roll-routing-metrics-08

"8.
...
=   When the DAG Metric Container contains several aggregated = metrics,
  they are to be used as tie-brakers in the order = that they appear in
  the DAG Metric Container.  A = node propagating a DAG Metric Container
  MUST keep the = order of metric objects unchanged.

  An example of = such use of multiple aggregated metrics is the
=   following: Hop-Count as the primary criterion, LQL as the = secondary
  criterion and Fanout Ratio as the ultimate = tie-braker.  In such a
  case, the Hop-Count, LQL and = Fanout Ratio metric objects need to
  appear in that order = in the DAG Metric Container.

..."

Is the semantics behind = the ordering intentional?

A packet could be forwarded from a node = that prefers to use one set of objective to a node that prefers to use a = different objective. For example, from a low power energy scavenging = sensor to a powered node.
Not allowing the nodes to change the order = allows a node to dictate the relative importance of this metric to rest = of the network without regard to their preference.

If we had = already considered that scenario and determined to be not important, it = might be worth making the last sentence in the following paragraph = stronger - are there other cases besides those mentioned in
8 and = 3.2?

"2.
...
  Note that the Routing = Metric/Constraint objects defined in this
  document can = appear in any order in the DAG Metric Container.
=   However, for some of them, the order is significant (as = described in
  Section 8 and Section 3.2, for = example).
"

- = om_p
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll
_______________________________________________
= Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

= --Apple-Mail-97-686063466-- From nicolas.dejean.ietf@googlemail.com Tue Jul 20 08:56:19 2010 Return-Path: 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 33D563A68D6 for ; Tue, 20 Jul 2010 08:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6] 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 FzCd9-0Z+Rof for ; Tue, 20 Jul 2010 08:56:18 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D761D3A6858 for ; Tue, 20 Jul 2010 08:56:17 -0700 (PDT) Received: by ewy22 with SMTP id 22so2043694ewy.31 for ; Tue, 20 Jul 2010 08:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=uvyGyFP28kLVLFfh89AmGZ3E+kbWmqQHzjG9bY/Seyc=; b=Wov7PBVrzGKdXYoBRYMGztgo4uUkmdDUCK7h/wi0IKcA7/lQA1Ao5TwWuY2DGb3Dyb reW1QPWwaR9KMInUfwFxs2zEFsILRYIN/I2mAkHH5/rTt+8SbDPU4+RYDw1nVnD5gVIC XWWuDucxefE9qFdqr1vKxzNiQMYLziJfrHAT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=p/14EAoXTMijLYlm+jIQi/Z9vqzf076/r6CPgUzoetau739xXkNXKv33SgyVmiBAHa frzWkh+CqV1OgqS+/O1O0h25wopPz1zvAxOIREJ1xiBd0YgKqWSkwFeSA+TO9Hg7GuLf BNGJkswXCTkuTZTelmYg5l3bbp9OSCVi7HMCk= MIME-Version: 1.0 Received: by 10.213.34.77 with SMTP id k13mr4319316ebd.9.1279641391421; Tue, 20 Jul 2010 08:56:31 -0700 (PDT) Received: by 10.213.28.80 with HTTP; Tue, 20 Jul 2010 08:56:31 -0700 (PDT) Date: Tue, 20 Jul 2010 17:56:31 +0200 Message-ID: From: Nicolas DEJEAN To: roll WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 15:56:19 -0000 Hello all, Based on our experience of having deployed many smart metering networks (totalling several million nodes), we have an issue with the way DIS and DIOs are currently handled by RPL. To solve this issue, we suggest minor modifications into the RPL core spec that only impacts the connection process of a leaf node to the LLN. As part of the everyday life of a smart metering network, every so often, a meter needs to be replaced or an extra one needs to be added. After physical installation, the technician stands by to witness the network hook-up. He/she will not leave the premises before the meter is satisfactorily connected. Every elapsed minute is an operation cost. We are talking real money. There's no way a meter will wait for a DIO to arrive by itself after some random number of hours. The meter has to solicit DIOs from yet unknown neighbor routers, and that's done by multicasting DIS'es. In our case of interest, the meter will be a leaf node, therefore its presence will not modify the network topology. Currently, RPL mandates that, in response to a multicast DIS, DIOs are multicasted and Trickle timers at the routers are reset. Firstly, resetting the Trickle timers generates much more control traffic than is needed. Neither the meter being installed nor neighbor nodes need the frequent repeats of the very same DIO (remember the topology is not changing). This is only a waste of energy at the routers and at the nodes that are the destination of the DIOs. Secondly, multicast makes the problem even worse by enlarging the audience for the DIO. Other than the meter being installed, nodes nearby do not need to receive the DIO, because they have long settled and the topology is not changing. In dense environments, the two effects combine to drastically reduce the network lifetime compared to our currently deployed, non-RPL, protocol. It is our industrial experience that this is a real and significant problem and we worked hard to solve it. Let's leverage that experience to the benefit of RPL users. Therefore, here are two possibilites for RPL. Option A) * In section 5.2, specify an L bit ("Leaf node") in the DIS format. * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a cleared L-bit and a Solicited Information option and when the node matches all of the predicates in the Solicited Information option." * In section 7.3, specify the algorithm to be run for responding with a unicast DIO to a multicast DIS with L-bit set. This text shall be described in a further email. This could advantageously be a temporary Trickle timer. Option B) * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior." * describe the L bit and RPL behavior in a separate I-D, together with the DIS option TLVs. Would the WG please voice their opinion on these options? Thanks From jpv@cisco.com Tue Jul 20 09:05:33 2010 Return-Path: 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 339B33A6BFD for ; Tue, 20 Jul 2010 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] 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 PM6frgPWZQwv for ; Tue, 20 Jul 2010 09:05: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 BF11B3A6B1F for ; Tue, 20 Jul 2010 09:05:30 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEZmRUxAZnwN/2dsb2JhbACfbXGlc5svhTIEiFmCNQ Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2010 16:05:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KG5eY6029685; Tue, 20 Jul 2010 16:05:45 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:05:43 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:05:42 +0200 Message-Id: From: JP Vasseur To: Nicolas DEJEAN In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 18:05:41 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 16:05:43.0083 (UTC) FILETIME=[67D0CFB0:01CB2825] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:05:33 -0000 Hi Nicolas, On Jul 20, 2010, at 5:56 PM, Nicolas DEJEAN wrote: > Hello all, > > Based on our experience of having deployed many smart metering > networks (totalling several million nodes), we have an issue with the > way DIS and DIOs are currently handled by RPL. To solve this issue, we > suggest minor modifications into the RPL core spec that only impacts > the connection process of a leaf node to the LLN. > > As part of the everyday life of a smart metering network, every so > often, a meter needs to be replaced or an extra one needs to be added. > After physical installation, the technician stands by to witness the > network hook-up. He/she will not leave the premises before the meter > is satisfactorily connected. Every elapsed minute is an operation > cost. We are talking real money. There's no way a meter will wait for > a DIO to arrive by itself after some random number of hours. The meter > has to solicit DIOs from yet unknown neighbor routers, and that's done > by multicasting DIS'es. In our case of interest, the meter will be a > leaf node, therefore its presence will not modify the network > topology. Thanks for sharing your experience, and we can expect similar behavior in a number of situations. > Currently, RPL mandates that, in response to a multicast > DIS, DIOs are multicasted and Trickle timers at the routers are reset. > > Firstly, resetting the Trickle timers generates much more control > traffic than is needed. Neither the meter being installed nor neighbor > nodes need the frequent repeats of the very same DIO (remember the > topology is not changing). Indeed, because the newly inserted node is a leaf. > This is only a waste of energy at the > routers and at the nodes that are the destination of the DIOs. > > Secondly, multicast makes the problem even worse by enlarging the > audience for the DIO. Other than the meter being installed, nodes > nearby do not need to receive the DIO, because they have long settled > and the topology is not changing. Agree. > > In dense environments, the two effects combine to drastically reduce > the network lifetime compared to our currently deployed, non-RPL, > protocol. > > It is our industrial experience that this is a real and significant > problem and we worked hard to solve it. > Let's leverage that experience to the benefit of RPL users. > > Therefore, here are two possibilites for RPL. > > Option A) > * In section 5.2, specify an L bit ("Leaf node") in the DIS format. > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a cleared L-bit and a Solicited > Information option and when the node matches all of the predicates in > the Solicited Information option." > * In section 7.3, specify the algorithm to be run for responding with > a unicast DIO to a multicast DIS with L-bit set. This text shall be > described in a further email. This could advantageously be a temporary > Trickle timer. > > Option B) > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a Solicited Information option and > the node matches all of the predicates in the Solicited Information > option, unless a DIS flag restricts this behavior." > * describe the L bit and RPL behavior in a separate I-D, together with > the DIS option TLVs. > You raise an important point. Agree with the conclusion. At this point, I would vote for B. > Would the WG please voice their opinion on these options? > > Thanks > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Tue Jul 20 09:08:15 2010 Return-Path: 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 9F2BD3A69F1 for ; Tue, 20 Jul 2010 09:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 D1W2TXjCGZV1 for ; Tue, 20 Jul 2010 09:08:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 860043A69A6 for ; Tue, 20 Jul 2010 09:08:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ObFMk-0004AR-J4; Tue, 20 Jul 2010 09:08:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Tue, 20 Jul 2010 16:08:22 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/71 Message-ID: <055.50900f39e20babf74687f0e1e7779730@tools.ietf.org> X-Trac-Ticket-ID: 71 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #71: DIS Behavior X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:08:16 -0000 #71: DIS Behavior --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email From Nicola Dejean July 20 Hello all, Based on our experience of having deployed many smart metering networks (totalling several million nodes), we have an issue with the way DIS and DIOs are currently handled by RPL. To solve this issue, we suggest minor modifications into the RPL core spec that only impacts the connection process of a leaf node to the LLN. As part of the everyday life of a smart metering network, every so often, a meter needs to be replaced or an extra one needs to be added. After physical installation, the technician stands by to witness the network hook-up. He/she will not leave the premises before the meter is satisfactorily connected. Every elapsed minute is an operation cost. We are talking real money. There's no way a meter will wait for a DIO to arrive by itself after some random number of hours. The meter has to solicit DIOs from yet unknown neighbor routers, and that's done by multicasting DIS'es. In our case of interest, the meter will be a leaf node, therefore its presence will not modify the network topology. Currently, RPL mandates that, in response to a multicast DIS, DIOs are multicasted and Trickle timers at the routers are reset. Firstly, resetting the Trickle timers generates much more control traffic than is needed. Neither the meter being installed nor neighbor nodes need the frequent repeats of the very same DIO (remember the topology is not changing). This is only a waste of energy at the routers and at the nodes that are the destination of the DIOs. Secondly, multicast makes the problem even worse by enlarging the audience for the DIO. Other than the meter being installed, nodes nearby do not need to receive the DIO, because they have long settled and the topology is not changing. In dense environments, the two effects combine to drastically reduce the network lifetime compared to our currently deployed, non-RPL, protocol. It is our industrial experience that this is a real and significant problem and we worked hard to solve it. Let's leverage that experience to the benefit of RPL users. Therefore, here are two possibilites for RPL. Option A) * In section 5.2, specify an L bit ("Leaf node") in the DIS format. * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a cleared L-bit and a Solicited Information option and when the node matches all of the predicates in the Solicited Information option." * In section 7.3, specify the algorithm to be run for responding with a unicast DIO to a multicast DIS with L-bit set. This text shall be described in a further email. This could advantageously be a temporary Trickle timer. Option B) * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior." * describe the L bit and RPL behavior in a separate I-D, together with the DIS option TLVs. Would the WG please voice their opinion on these options? Thanks ________________________ -- Ticket URL: roll From jhui@archrock.com Tue Jul 20 09:13:44 2010 Return-Path: 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 8C9173A6858 for ; Tue, 20 Jul 2010 09:13:44 -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 F0rMbyd33rma for ; Tue, 20 Jul 2010 09:13:43 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 451413A684A for ; Tue, 20 Jul 2010 09:13:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C3A25AF94C; Tue, 20 Jul 2010 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIC-TiqzQThh; Tue, 20 Jul 2010 09:12:06 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 03E23AF8E1; Tue, 20 Jul 2010 09:12:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: Date: Tue, 20 Jul 2010 09:13:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> References: To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:13:44 -0000 Nicolas, On Jul 20, 2010, at 8:56 AM, Nicolas DEJEAN wrote: > Option A) > * In section 5.2, specify an L bit ("Leaf node") in the DIS format. > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a cleared L-bit and a Solicited > Information option and when the node matches all of the predicates in > the Solicited Information option." > * In section 7.3, specify the algorithm to be run for responding with > a unicast DIO to a multicast DIS with L-bit set. This text shall be > described in a further email. This could advantageously be a temporary > Trickle timer. >=20 > Option B) > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a Solicited Information option and > the node matches all of the predicates in the Solicited Information > option, unless a DIS flag restricts this behavior." > * describe the L bit and RPL behavior in a separate I-D, together with > the DIS option TLVs. >=20 > Would the WG please voice their opinion on these options? Without a better understanding of the "response algorithm" and = additional information needed to drive how nodes respond, I would lean = to have this functionality described in a separate I-D and not change = the current RPL spec. For example, it's unclear to me whether it should = be a flag, an option, or a sub-option of an updated solicited = information option. Note that the rules in Section 7.3 are SHOULDs, so = it is OK to do something else if there is a valid and well-understood = reason. =20 -- Jonathan Hui From pal@cs.stanford.edu Tue Jul 20 09:33:26 2010 Return-Path: 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 064A43A69FF for ; Tue, 20 Jul 2010 09:33:26 -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=[AWL=0.000, 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 Bowhut82t2zm for ; Tue, 20 Jul 2010 09:33:21 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 2BA593A6AFD for ; Tue, 20 Jul 2010 09:33:15 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ObFl4-00049y-9h; Tue, 20 Jul 2010 09:33:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 20 Jul 2010 09:33:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <84A5FBBF-D2F2-4D40-AA7D-AAC8FB1D27D8@cs.berkeley.edu> <5263.1277904523@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D02397386@XMB-AMS-107.cisco.com> <7145CDF9-0FD9-4993-9819-5994188A932C@cs.stanford.edu> <4C3B9001.3050505@acm.org> <68D2C614-FA5E-4245-A6BE-D131AF925253@cs.stanford.edu> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 8ab272620d4bdfee2f14268d9892c5ce Cc: ROLL WG Subject: Re: [Roll] Proposed DIS flags (Re: LC RPL-10) 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:33:26 -0000 On Jul 16, 2010, at 9:06 AM, Nicolas DEJEAN wrote: >>=20 >=20 > We indeed don't want unicast responses to suppress one another. The > "flood" will be kept under control by the DIS options. It is our > experience in smart metering network that the LLN node (via the > technician impatiently standing in front of it during installation) > does have enough understanding of the network to craft DIS predicates, > and does not want to wait one minute more than absolutely necessary. > Note that the Trickle max period is anticipated to be several hours in > water/gas smart metering networks. >=20 >> It's useful to note that if a message does not reset the timer, = handling suppression in a safe way becomes an open problem. That is, I = do not know of any existing solutions that have been evaluated in real = networks. E.g., let's say we're close to the end of an interval. If a = message does not reset the timer, then if there have already been enough = transmissions in the interval a node won't respond. Responding without = suppression can lead to a flood response. There might be ways out of = this (e.g., resetting the counter), but I'd consider such approaches = highly highly experimental. >>=20 >> It sounds like you want to be able to send a multicast message and = get an immediate, single response from every neighbor? Your original = mail said: >>=20 >> "Just to re-inforce this calculation, it has been our experience that >> node insertion into a dense low-power network, if done wrong, is a >> significant energy drain." >>=20 >> So I guess I have 3 questions: >>=20 >> 1) Why does the unicast/multicast distinction not solve the problem? >=20 > When inserting a new node in a dense environment, without pre-existing > information about the qualifications of routers around, running > through their list one by one is an expensive proposition. >=20 >> 2) If the issue is discovery on inserting a new node, can you = explain how unicast responses from many neighbors (or an iterative DIS = with options search) is more efficient than suppression over a = logarithmic number of intervals? >=20 > With our MAC layer of interest, unicast responses will not induce > overhearing at other receivers in the neighborhood, while multicast > will. With the DIS search options, there won't be that many neighbors > to respond, and we will quickly get responses from all nodes we are > interested in, not at some random later time depending on suppression. >=20 >> 3) If the issue is inserting many new nodes at the same time and = many triggering resets, why doesn't a simple DIO timeout (e.g., 5 = minutes) before issuing a DIS work? >>=20 >=20 > See explanation above about technician not having to wait one minute > more than strictly necessary. >=20 >> I feel like there's some very specific use case you're trying to = describe and I just don't understand it yet. Sorry to be slow. >>=20 This seems like a really narrow use case, which is a mix of application = requirements and a particular way you are trying to use DIO = transmissions. Correct me if I'm wrong, but I think the requirement is: R1) A technician needs to be able to deploy a node in a dense network = and have it come up very quickly with little energy spent=20 The proposed solution assumes: A1) The network is engineered in such a way, combined with node = knowledge of the network, that nodes can issue iteratively broader DIS = queries to optimize the responses; A2) The MAC layer is such that broadcast operations are much more = expensive than unicast A3) The MAC layer is such that broadcast operations are expensive with = respect to receive energy A4) On a multicast request, the MAC layer is such that a response = implosion is not a problem Doesn't this seem like a very narrow set of assumptions to use as a = basis for including a new mechanism? Can you walk me through the math for the energy cost? Here's how I see = it, how am I wrong: Let us suppose an Imin of 1 sec and a max doublings of 14 (max interval = length is then 4.5 hours). Assuming that the network starts at Imax, = over the 4.5 hours after a multicast DIS, nodes will hear 14k rather = than k messages. Is the concern the receiver energy cost or transmitter = energy cost? What sort of low-power MAC is used? If it is a strobing = MAC, there shouldn't be a large receive energy cost; if it is a preamble = MAC, then there can be. So is there an assumption of a preamble MAC? Please note with respect to R1, Trickle has been demonstrated to = accomplish this goal (please see the CTP paper). The one caveat is that = when the node first comes up, it might start with a "good enough" route. = Then, over time, as it learns about more of its neighbors it improves = the route. Is this an unacceptable problem in your domain?=20 Phil From jhui@archrock.com Tue Jul 20 09:34:24 2010 Return-Path: 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 9BC553A688F for ; Tue, 20 Jul 2010 09:34: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 G4mm5jns2sYX for ; Tue, 20 Jul 2010 09:34:21 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 274AC3A67F8 for ; Tue, 20 Jul 2010 09:34:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BB680AFA27; Tue, 20 Jul 2010 09:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfIF1nzO6E2N; Tue, 20 Jul 2010 09:32:44 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 11C5FAF8E1; Tue, 20 Jul 2010 09:32:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> Date: Tue, 20 Jul 2010 09:34:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> To: Nicolas DEJEAN X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:34:24 -0000 On Jul 20, 2010, at 9:13 AM, Jonathan Hui wrote: > Nicolas, >=20 > On Jul 20, 2010, at 8:56 AM, Nicolas DEJEAN wrote: >=20 >> Option A) >> * In section 5.2, specify an L bit ("Leaf node") in the DIS format. >> * In section 7.3, change the third item of the list to read "When a >> node receives a multicast DIS with a cleared L-bit and a Solicited >> Information option and when the node matches all of the predicates in >> the Solicited Information option." >> * In section 7.3, specify the algorithm to be run for responding with >> a unicast DIO to a multicast DIS with L-bit set. This text shall be >> described in a further email. This could advantageously be a = temporary >> Trickle timer. >>=20 >> Option B) >> * In section 7.3, change the third item of the list to read "When a >> node receives a multicast DIS with a Solicited Information option and >> the node matches all of the predicates in the Solicited Information >> option, unless a DIS flag restricts this behavior." >> * describe the L bit and RPL behavior in a separate I-D, together = with >> the DIS option TLVs. >>=20 >> Would the WG please voice their opinion on these options? >=20 > Without a better understanding of the "response algorithm" and = additional information needed to drive how nodes respond, I would lean = to have this functionality described in a separate I-D and not change = the current RPL spec. For example, it's unclear to me whether it should = be a flag, an option, or a sub-option of an updated solicited = information option. Note that the rules in Section 7.3 are SHOULDs, so = it is OK to do something else if there is a valid and well-understood = reason. =20 Oops. I remembered Section 7.3 wrong and it does read MUST, my mistake. = My preference is still for Option B. I'm OK with including a flag to = that disables the Trickle reset. But does it make sense to limit its = use to the Solicited Information option, as you proposed? If you claim = that the link-layer will guarantee collision-free unicast transmissions, = then I guess it would be OK to allow neighbors to reply. But in either = case, we might want to put some text in describing the dangers of the = "disable Trickle reset" flag. -- Jonathan Hui From pal@cs.stanford.edu Tue Jul 20 09:38:00 2010 Return-Path: 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 BC7F73A683A for ; Tue, 20 Jul 2010 09:38:00 -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 Hod0+hQ2JdhP for ; Tue, 20 Jul 2010 09:37:59 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D14EF3A67F8 for ; Tue, 20 Jul 2010 09:37:59 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ObFpe-0004KL-JE; Tue, 20 Jul 2010 09:38:15 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> Date: Tue, 20 Jul 2010 09:38:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:38:00 -0000 On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >=20 > On Jul 20, 2010, at 9:13 AM, Jonathan Hui wrote: >=20 >> Nicolas, >>=20 >> On Jul 20, 2010, at 8:56 AM, Nicolas DEJEAN wrote: >>=20 >>> Option A) >>> * In section 5.2, specify an L bit ("Leaf node") in the DIS format. >>> * In section 7.3, change the third item of the list to read "When a >>> node receives a multicast DIS with a cleared L-bit and a Solicited >>> Information option and when the node matches all of the predicates = in >>> the Solicited Information option." >>> * In section 7.3, specify the algorithm to be run for responding = with >>> a unicast DIO to a multicast DIS with L-bit set. This text shall be >>> described in a further email. This could advantageously be a = temporary >>> Trickle timer. >>>=20 >>> Option B) >>> * In section 7.3, change the third item of the list to read "When a >>> node receives a multicast DIS with a Solicited Information option = and >>> the node matches all of the predicates in the Solicited Information >>> option, unless a DIS flag restricts this behavior." >>> * describe the L bit and RPL behavior in a separate I-D, together = with >>> the DIS option TLVs. >>>=20 >>> Would the WG please voice their opinion on these options? >>=20 >> Without a better understanding of the "response algorithm" and = additional information needed to drive how nodes respond, I would lean = to have this functionality described in a separate I-D and not change = the current RPL spec. For example, it's unclear to me whether it should = be a flag, an option, or a sub-option of an updated solicited = information option. Note that the rules in Section 7.3 are SHOULDs, so = it is OK to do something else if there is a valid and well-understood = reason. =20 >=20 >=20 > Oops. I remembered Section 7.3 wrong and it does read MUST, my = mistake. My preference is still for Option B. I'm OK with including a = flag to that disables the Trickle reset. But does it make sense to = limit its use to the Solicited Information option, as you proposed? If = you claim that the link-layer will guarantee collision-free unicast = transmissions, then I guess it would be OK to allow neighbors to reply. = But in either case, we might want to put some text in describing the = dangers of the "disable Trickle reset" flag. My concern is that we're adding a specialized mechanism under the = assumptions of how the underlying link layer operates. Using this = mechanism with link layers that do not have that property could be = disastrous (response implosion, hidden terminal collisions). That being said, it's clear we need to figure out if there's a safer way = for RPL to meet the application requirements. Phil= From prvs=8107c8147=mukul@uwm.edu Tue Jul 20 09:40:00 2010 Return-Path: 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 3C11E3A683A for ; Tue, 20 Jul 2010 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 zNxbC-eHb-BR for ; Tue, 20 Jul 2010 09:39:58 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 323343A67F8 for ; Tue, 20 Jul 2010 09:39:58 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 20 Jul 2010 11:40:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 13D3F2B3EF6; Tue, 20 Jul 2010 11:40:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF9T6SB0TkMZ; Tue, 20 Jul 2010 11:39:59 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C3FAB2B3F02; Tue, 20 Jul 2010 11:39:59 -0500 (CDT) Date: Tue, 20 Jul 2010 11:40:13 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <2003132478.138614.1279644013270.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <295854024.138467.1279643848531.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] determining downward routes at the root 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:40:00 -0000 Hi Pascal I think, in the absence of any explanation in the text, there is a risk of misinterpretation. So, this is my interpretation of how it will work: Root needs to determine the source route to node N. Root starts with node N's DAO, finds its highest preference parent, adds it to the route and then repeats the procedure with this parent. This continues until the route is complete. So, this is a greedy approach to route discovery. The underlying assumption seems to be that a more preferred parent is infinitely better for downwards routing than a less preferred parent. Another possibility is to let the DAG root reverse the path control field and use it as link cost to determine shortest paths to a destination using dijkstra. It seems to me that there needs to be some guidance, perhaps in the objective function, regarding how path control is to be used (for non-storing operation) and how would the root calculate the downwards routes. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" Sent: Tuesday, July 20, 2010 6:26:00 AM Subject: RE: [Roll] determining downward routes at the root Hi Mukul: This is a pretty classical recursive route lookup. Only the highest preference 1hop route should show up so recursively the root will quite naturally build the source route header. Routing protocols usually do not describe such operation. Do you think there is a risk of misinterpretation? Would someone else please shime in? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, July 20, 2010 11:25 AM > To: roll > Subject: [Roll] determining downward routes at the root > > I was wondering if it makes sense to add some text to the RPL draft regarding > how does a root, in non-storing LLN, determine the _shortest_ downward > routes to different destinations using the "path control" values as the (inverse) > link costs. > > Thanks > Mukul > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Tue Jul 20 09:43:01 2010 Return-Path: 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 6F7DB3A6912 for ; Tue, 20 Jul 2010 09:43:01 -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 mkSoE5lMymLQ for ; Tue, 20 Jul 2010 09:43:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id 8D4F33A688F for ; Tue, 20 Jul 2010 09:43:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 29C14AF99B; Tue, 20 Jul 2010 09:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcvVwmWkFVcL; Tue, 20 Jul 2010 09:41:23 -0700 (PDT) Received: from [192.168.7.62] (69-12-164-135.sfo.archrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 6A5FCAF8E1; Tue, 20 Jul 2010 09:41:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> Date: Tue, 20 Jul 2010 09:43:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:43:01 -0000 Phil, On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: > On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >=20 >> Oops. I remembered Section 7.3 wrong and it does read MUST, my = mistake. My preference is still for Option B. I'm OK with including a = flag to that disables the Trickle reset. But does it make sense to = limit its use to the Solicited Information option, as you proposed? If = you claim that the link-layer will guarantee collision-free unicast = transmissions, then I guess it would be OK to allow neighbors to reply. = But in either case, we might want to put some text in describing the = dangers of the "disable Trickle reset" flag. >=20 > My concern is that we're adding a specialized mechanism under the = assumptions of how the underlying link layer operates. Using this = mechanism with link layers that do not have that property could be = disastrous (response implosion, hidden terminal collisions). >=20 > That being said, it's clear we need to figure out if there's a safer = way for RPL to meet the application requirements. I share your concerns. What I wanted to convey in my mail wasn't clear, = but I meant to say that disabling a Trickle reset in response to a DIS = is OK from my perspective - it's what other actions nodes do after that = we need to think carefully about, and I'm arguing that those latter = mechanisms go in a separate (possibly domain specific) draft. Or is it = that you do not want any mechanism to avoid a Trickle reset? -- Jonathan Hui From jpv@cisco.com Tue Jul 20 09:48:25 2010 Return-Path: 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 D4B7A3A68ED for ; Tue, 20 Jul 2010 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lDop83dOOGta for ; Tue, 20 Jul 2010 09:48:25 -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 EE6253A69CD for ; Tue, 20 Jul 2010 09:48:24 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB9wRUyrR7H+/2dsb2JhbACfbXGmHpsuhTIEiFmCNQ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 16:48:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KGmd7d022179; Tue, 20 Jul 2010 16:48:40 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:48:39 +0200 Received: from [192.168.3.55] ([10.61.88.164]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 18:48:38 +0200 Message-Id: From: JP Vasseur To: Jonathan Hui In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 18:48:37 +0200 References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 20 Jul 2010 16:48:38.0563 (UTC) FILETIME=[66EBDF30:01CB282B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17518.000 X-TM-AS-Result: No--23.557500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 16:48:25 -0000 On Jul 20, 2010, at 6:43 PM, Jonathan Hui wrote: > > Phil, > > On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: > >> On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >> >>> Oops. I remembered Section 7.3 wrong and it does read MUST, my >>> mistake. My preference is still for Option B. I'm OK with >>> including a flag to that disables the Trickle reset. But does it >>> make sense to limit its use to the Solicited Information option, >>> as you proposed? If you claim that the link-layer will guarantee >>> collision-free unicast transmissions, then I guess it would be OK >>> to allow neighbors to reply. But in either case, we might want to >>> put some text in describing the dangers of the "disable Trickle >>> reset" flag. >> >> My concern is that we're adding a specialized mechanism under the >> assumptions of how the underlying link layer operates. Using this >> mechanism with link layers that do not have that property could be >> disastrous (response implosion, hidden terminal collisions). >> >> That being said, it's clear we need to figure out if there's a >> safer way for RPL to meet the application requirements. > > I share your concerns. What I wanted to convey in my mail wasn't > clear, but I meant to say that disabling a Trickle reset in response > to a DIS is OK from my perspective - it's what other actions nodes > do after that we need to think carefully about, and I'm arguing that > those latter mechanisms go in a separate (possibly domain specific) > draft. Agree, this is option B. > Or is it that you do not want any mechanism to avoid a Trickle reset? > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jul 20 11:27:46 2010 Return-Path: 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 0BE003A67CC for ; Tue, 20 Jul 2010 11:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] 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 FAhgeX05tA7X for ; Tue, 20 Jul 2010 11:27:44 -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 93F473A67A7 for ; Tue, 20 Jul 2010 11:27:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJyHRUxAZnwM/2dsb2JhbACfcnGlcZsshTIEiw4 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 18:27:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KIRxTQ022665; Tue, 20 Jul 2010 18:27:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 20:27:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 20:27:51 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260A27B@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Soliciting WG comments on DIS for RPL Last Call thread-index: AcsoJDq0o26OjagnR86H0d886h3FtgAFBbzA References: From: "Pascal Thubert (pthubert)" To: "Nicolas DEJEAN" , "roll WG" X-OriginalArrivalTime: 20 Jul 2010 18:27:59.0558 (UTC) FILETIME=[47F38660:01CB2839] Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 18:27:46 -0000 Hi Nicolas: Thanks a bunch for these excellent suggestions. In my view, this is related to section 16.7 and we could have some words there about the first discovery as we have words about maintenance. Like for 16.7, I tend to think that there might be more than one behavior to address different media, and that your option B is the one that enables further drafts and eventually different drafts / specs in different environments to specify the behavior that they expect. What's different though is that the mechanism needs to be related to RPL, because of the DIS filters. You have my vote to adopt B). Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Nicolas DEJEAN > Sent: Tuesday, July 20, 2010 5:57 PM > To: roll WG > Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call >=20 > Hello all, >=20 > Based on our experience of having deployed many smart metering networks > (totalling several million nodes), we have an issue with the way DIS and DIOs > are currently handled by RPL. To solve this issue, we suggest minor > modifications into the RPL core spec that only impacts the connection process > of a leaf node to the LLN. >=20 > As part of the everyday life of a smart metering network, every so often, a > meter needs to be replaced or an extra one needs to be added. > After physical installation, the technician stands by to witness the network > hook-up. He/she will not leave the premises before the meter is satisfactorily > connected. Every elapsed minute is an operation cost. We are talking real > money. There's no way a meter will wait for a DIO to arrive by itself after some > random number of hours. The meter has to solicit DIOs from yet unknown > neighbor routers, and that's done by multicasting DIS'es. In our case of interest, > the meter will be a leaf node, therefore its presence will not modify the > network topology. Currently, RPL mandates that, in response to a multicast DIS, > DIOs are multicasted and Trickle timers at the routers are reset. >=20 > Firstly, resetting the Trickle timers generates much more control traffic than is > needed. Neither the meter being installed nor neighbor nodes need the > frequent repeats of the very same DIO (remember the topology is not > changing). This is only a waste of energy at the routers and at the nodes that > are the destination of the DIOs. >=20 > Secondly, multicast makes the problem even worse by enlarging the audience > for the DIO. Other than the meter being installed, nodes nearby do not need to > receive the DIO, because they have long settled and the topology is not > changing. >=20 > In dense environments, the two effects combine to drastically reduce the > network lifetime compared to our currently deployed, non-RPL, protocol. >=20 > It is our industrial experience that this is a real and significant problem and we > worked hard to solve it. > Let's leverage that experience to the benefit of RPL users. >=20 > Therefore, here are two possibilites for RPL. >=20 > Option A) > * In section 5.2, specify an L bit ("Leaf node") in the DIS format. > * In section 7.3, change the third item of the list to read "When a node receives > a multicast DIS with a cleared L-bit and a Solicited Information option and when > the node matches all of the predicates in the Solicited Information option." > * In section 7.3, specify the algorithm to be run for responding with a unicast > DIO to a multicast DIS with L-bit set. This text shall be described in a further > email. This could advantageously be a temporary Trickle timer. >=20 > Option B) > * In section 7.3, change the third item of the list to read "When a node receives > a multicast DIS with a Solicited Information option and the node matches all of > the predicates in the Solicited Information option, unless a DIS flag restricts this > behavior." > * describe the L bit and RPL behavior in a separate I-D, together with the DIS > option TLVs. >=20 > Would the WG please voice their opinion on these options? >=20 > Thanks > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Jul 20 11:28:27 2010 Return-Path: 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 3458E3A6803 for ; Tue, 20 Jul 2010 11:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.177 X-Spam-Level: X-Spam-Status: No, score=-6.177 tagged_above=-999 required=5 tests=[AWL=0.422, 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 4rjnAS8sBZee for ; Tue, 20 Jul 2010 11:28:26 -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 D92FC3A67DB for ; Tue, 20 Jul 2010 11:28:25 -0700 (PDT) Received: from [172.27.75.101] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1ObHYX-0003Cc-Ad; Tue, 20 Jul 2010 11:28:41 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 20 Jul 2010 11:28:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> To: Jonathan Hui X-Mailer: Apple Mail (2.1081) X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 18:28:27 -0000 On Jul 20, 2010, at 9:43 AM, Jonathan Hui wrote: >=20 > Phil, >=20 > On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: >=20 >> On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >>=20 >>> Oops. I remembered Section 7.3 wrong and it does read MUST, my = mistake. My preference is still for Option B. I'm OK with including a = flag to that disables the Trickle reset. But does it make sense to = limit its use to the Solicited Information option, as you proposed? If = you claim that the link-layer will guarantee collision-free unicast = transmissions, then I guess it would be OK to allow neighbors to reply. = But in either case, we might want to put some text in describing the = dangers of the "disable Trickle reset" flag. >>=20 >> My concern is that we're adding a specialized mechanism under the = assumptions of how the underlying link layer operates. Using this = mechanism with link layers that do not have that property could be = disastrous (response implosion, hidden terminal collisions). >>=20 >> That being said, it's clear we need to figure out if there's a safer = way for RPL to meet the application requirements. >=20 > I share your concerns. What I wanted to convey in my mail wasn't = clear, but I meant to say that disabling a Trickle reset in response to = a DIS is OK from my perspective - it's what other actions nodes do after = that we need to think carefully about, and I'm arguing that those latter = mechanisms go in a separate (possibly domain specific) draft. Or is it = that you do not want any mechanism to avoid a Trickle reset? Let's be more precise: we're not really talking about disabling a = Trickle reset, we're talking about requesting an immediate response. The = transmission is independent of Trickle timers, although it could affect = suppression. This is fine as a mechanism: currently, unicast DIS transmissions cause = this behavior (e.g., to obtain the DODAG Configuration). My concern is = that the proposal is to allow this from a multicast transmission. A protocol shouldn't allow a node to trigger immediate responses from = many nodes simultaneously, due to the MAC layer failures this can = introduce in wireless. The proposed solution is even a worst-case = scenario, where the responses are all unicast so cannot suppress each = other. The failure scenario is: I have a hundred nodes in a box, one = node sends a multicast DIS that requests immediate unicast responses. If = your link layer does not promise collision free unicast transmissions = (any CSMA scheme), you waste an enormous amount of energy to create a = lot of packet collisions. This seems to be a mechanism that only works = for certain link layers and could be disastrous in others. Phil= From yoav@yitran.com Tue Jul 20 11:58:46 2010 Return-Path: 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 D24EB3A6BB2 for ; Tue, 20 Jul 2010 11:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jRQw2Cb8SshA for ; Tue, 20 Jul 2010 11:58:45 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id EA0D73A6B3E for ; Tue, 20 Jul 2010 11:58:44 -0700 (PDT) Received: from source ([209.85.212.44]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTEXx89iWHU+qXJ5au0e0Hf/vPhF9fRjQ@postini.com; Tue, 20 Jul 2010 11:59:00 PDT Received: by vws13 with SMTP id 13so796708vws.3 for ; Tue, 20 Jul 2010 11:58:59 -0700 (PDT) Received: by 10.224.104.132 with SMTP id p4mr6017972qao.322.1279652339410; Tue, 20 Jul 2010 11:58:59 -0700 (PDT) From: Yoav Ben-Yehezkel References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsoOWVrybkrmGxPTh6xlRS7375ybgAA4hbA Date: Tue, 20 Jul 2010 21:58:05 +0300 Message-ID: <8d5f05443df64db59a6652a6507078f8@mail.gmail.com> To: Philip Levis , Jonathan Hui Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 18:58:46 -0000 I have an alternative suggestion to this. If instead of disable trickle reset bit we say that we put a few more bits specifying the amount of time nodes may respond - this would at least put a time-limit on the congestion of the channel. BTW - the worst case scenario is when you install a large group of nodes in network (can be hundreds) and turn all of them on, and have a technician run around till he sees all nodes are connected. This is a typical installation scenario in metering applications as well sometimes denoted as "synchronous wakeup". Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Tuesday, July 20, 2010 9:29 PM To: Jonathan Hui Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call On Jul 20, 2010, at 9:43 AM, Jonathan Hui wrote: > > Phil, > > On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: > >> On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >> >>> Oops. I remembered Section 7.3 wrong and it does read MUST, my mistake. My preference is still for Option B. I'm OK with including a flag to that disables the Trickle reset. But does it make sense to limit its use to the Solicited Information option, as you proposed? If you claim that the link-layer will guarantee collision-free unicast transmissions, then I guess it would be OK to allow neighbors to reply. But in either case, we might want to put some text in describing the dangers of the "disable Trickle reset" flag. >> >> My concern is that we're adding a specialized mechanism under the assumptions of how the underlying link layer operates. Using this mechanism with link layers that do not have that property could be disastrous (response implosion, hidden terminal collisions). >> >> That being said, it's clear we need to figure out if there's a safer way for RPL to meet the application requirements. > > I share your concerns. What I wanted to convey in my mail wasn't clear, but I meant to say that disabling a Trickle reset in response to a DIS is OK from my perspective - it's what other actions nodes do after that we need to think carefully about, and I'm arguing that those latter mechanisms go in a separate (possibly domain specific) draft. Or is it that you do not want any mechanism to avoid a Trickle reset? Let's be more precise: we're not really talking about disabling a Trickle reset, we're talking about requesting an immediate response. The transmission is independent of Trickle timers, although it could affect suppression. This is fine as a mechanism: currently, unicast DIS transmissions cause this behavior (e.g., to obtain the DODAG Configuration). My concern is that the proposal is to allow this from a multicast transmission. A protocol shouldn't allow a node to trigger immediate responses from many nodes simultaneously, due to the MAC layer failures this can introduce in wireless. The proposed solution is even a worst-case scenario, where the responses are all unicast so cannot suppress each other. The failure scenario is: I have a hundred nodes in a box, one node sends a multicast DIS that requests immediate unicast responses. If your link layer does not promise collision free unicast transmissions (any CSMA scheme), you waste an enormous amount of energy to create a lot of packet collisions. This seems to be a mechanism that only works for certain link layers and could be disastrous in others. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Tue Jul 20 12:54:35 2010 Return-Path: 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 1ADA13A6B47 for ; Tue, 20 Jul 2010 12:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.716 X-Spam-Level: X-Spam-Status: No, score=-5.716 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 NE-PQ58jVdYG for ; Tue, 20 Jul 2010 12:54:33 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 3129A3A6891 for ; Tue, 20 Jul 2010 12:54:32 -0700 (PDT) Received: from source ([209.85.216.177]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTEX/B4lfIvWS6UIGJXAXXfCT7+cVvR4A@postini.com; Tue, 20 Jul 2010 12:54:49 PDT Received: by qyk1 with SMTP id 1so3021914qyk.1 for ; Tue, 20 Jul 2010 12:54:46 -0700 (PDT) Received: by 10.224.74.1 with SMTP id s1mr6530309qaj.26.1279655686639; Tue, 20 Jul 2010 12:54:46 -0700 (PDT) From: Yoav Ben-Yehezkel References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> 8d5f05443df64db59a6652a6507078f8@mail.gmail.com In-Reply-To: 8d5f05443df64db59a6652a6507078f8@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsoOWVrybkrmGxPTh6xlRS7375ybgAA4hbAAAIUzPA= Date: Tue, 20 Jul 2010 22:54:44 +0300 Message-ID: <5e2f5006f0687fd357c6baf5081ed31e@mail.gmail.com> To: Yoav Ben-Yehezkel , Philip Levis , Jonathan Hui Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Tue, 20 Jul 2010 19:54:35 -0000 I take this idea back. Reviewing the list of related emails once more - option B seems good to me. Yoav -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Tuesday, July 20, 2010 9:58 PM To: 'Philip Levis'; 'Jonathan Hui' Cc: 'roll WG' Subject: RE: [Roll] Soliciting WG comments on DIS for RPL Last Call I have an alternative suggestion to this. If instead of disable trickle reset bit we say that we put a few more bits specifying the amount of time nodes may respond - this would at least put a time-limit on the congestion of the channel. BTW - the worst case scenario is when you install a large group of nodes in network (can be hundreds) and turn all of them on, and have a technician run around till he sees all nodes are connected. This is a typical installation scenario in metering applications as well sometimes denoted as "synchronous wakeup". Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Tuesday, July 20, 2010 9:29 PM To: Jonathan Hui Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call On Jul 20, 2010, at 9:43 AM, Jonathan Hui wrote: > > Phil, > > On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: > >> On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >> >>> Oops. I remembered Section 7.3 wrong and it does read MUST, my mistake. My preference is still for Option B. I'm OK with including a flag to that disables the Trickle reset. But does it make sense to limit its use to the Solicited Information option, as you proposed? If you claim that the link-layer will guarantee collision-free unicast transmissions, then I guess it would be OK to allow neighbors to reply. But in either case, we might want to put some text in describing the dangers of the "disable Trickle reset" flag. >> >> My concern is that we're adding a specialized mechanism under the assumptions of how the underlying link layer operates. Using this mechanism with link layers that do not have that property could be disastrous (response implosion, hidden terminal collisions). >> >> That being said, it's clear we need to figure out if there's a safer way for RPL to meet the application requirements. > > I share your concerns. What I wanted to convey in my mail wasn't clear, but I meant to say that disabling a Trickle reset in response to a DIS is OK from my perspective - it's what other actions nodes do after that we need to think carefully about, and I'm arguing that those latter mechanisms go in a separate (possibly domain specific) draft. Or is it that you do not want any mechanism to avoid a Trickle reset? Let's be more precise: we're not really talking about disabling a Trickle reset, we're talking about requesting an immediate response. The transmission is independent of Trickle timers, although it could affect suppression. This is fine as a mechanism: currently, unicast DIS transmissions cause this behavior (e.g., to obtain the DODAG Configuration). My concern is that the proposal is to allow this from a multicast transmission. A protocol shouldn't allow a node to trigger immediate responses from many nodes simultaneously, due to the MAC layer failures this can introduce in wireless. The proposed solution is even a worst-case scenario, where the responses are all unicast so cannot suppress each other. The failure scenario is: I have a hundred nodes in a box, one node sends a multicast DIS that requests immediate unicast responses. If your link layer does not promise collision free unicast transmissions (any CSMA scheme), you waste an enormous amount of energy to create a lot of packet collisions. This seems to be a mechanism that only works for certain link layers and could be disastrous in others. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jul 20 13:34:50 2010 Return-Path: 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 A63AB3A6954 for ; Tue, 20 Jul 2010 13:34:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 SU9OryGjIYJW for ; Tue, 20 Jul 2010 13:34:47 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279658090-14507-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A287C3A63EC for ; Tue, 20 Jul 2010 13:34:47 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 20:35:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKYa5m005678 for ; Tue, 20 Jul 2010 20:35:03 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:15:03 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:31:36 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 06:26:37 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 11:26:26 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQ8R7027225; Tue, 20 Jul 2010 11:26:26 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 11:26:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC07A3A6A0A; Tue, 20 Jul 2010 04:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2103A67B5 for ; Tue, 20 Jul 2010 04:26:08 -0700 (PDT) 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 pJC28v5Z4Jpv for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 426153A688E for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 11:26:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQEts000369; Tue, 20 Jul 2010 11:26:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:26:04 +0200 Date: Tue, 20 Jul 2010 06:26:00 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> In-Reply-To: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> References: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu><1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" Subject: Re: [Roll] determining downward routes at the root 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: , X-List-Received-Date: Tue, 20 Jul 2010 20:34:50 -0000 This is a multi-part message in MIME format... ------------=_1279658090-14507-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279658090-14507-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A287C3A63EC for ; Tue, 20 Jul 2010 13:34:47 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 2939 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACKlRUyrR7Ht/2dsb2JhbACfc3GmYJsYhTIEhACHDocP Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 20:35:03 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKYa5m005678 for ; Tue, 20 Jul 2010 20:35:03 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:15:03 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:31:36 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 06:26:37 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27FE.6A5F5480" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 11:26:26 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQ8R7027225; Tue, 20 Jul 2010 11:26:26 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 11:26:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC07A3A6A0A; Tue, 20 Jul 2010 04:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2103A67B5 for ; Tue, 20 Jul 2010 04:26:08 -0700 (PDT) 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 pJC28v5Z4Jpv for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 426153A688E for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 11:26:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQEts000369; Tue, 20 Jul 2010 11:26:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:26:04 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] determining downward routes at the root Date: Tue, 20 Jul 2010 06:26:00 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> In-Reply-To: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> Thread-Topic: [Roll] determining downward routes at the root Thread-Index: Acsn7YE0s6sQ0MIeS+uyprxTvkf+VwAEDwMA References: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu><1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 20 Jul 2010 11:31:36.0738 (UTC) FILETIME=[1D07B820:01CB27FF] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27FE.6A5F5480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mukul: This is a pretty classical recursive route lookup. Only the highest preference 1hop route should show up so recursively the root will quite naturally build the source route header. Routing protocols usually do not describe such operation.=20 Do you think there is a risk of misinterpretation?=20 Would someone else please shime in? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, July 20, 2010 11:25 AM > To: roll > Subject: [Roll] determining downward routes at the root >=20 > I was wondering if it makes sense to add some text to the RPL draft regarding > how does a root, in non-storing LLN, determine the _shortest_ downward > routes to different destinations using the "path control" values as the (inverse) > link costs. >=20 > Thanks > Mukul > _______________________________________________ > 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 ------_=_NextPart_001_01CB27FE.6A5F5480 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiULAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMwAAAFJlOiBbUm9sbF0gZGV0ZXJt aW5pbmcgZG93bndhcmQgcm91dGVzIGF0IHRoZSByb290AJoSAQWAAwAOAAAA2gcHABQABgAaAAAA AgAeAQEggAMADgAAANoHBwAUAAYAGgAlAAIAQwEBCYABACEAAAA0QTU3QkE5RjZEODM1NDRCQUZC MTMyNUU4M0FGRDg1MABTBwEDkAYAfAoAAC0AAAADADYAAAAAAEAAOQAAlFFU/ifLAR4APQABAAAA BQAAAFJlOiAAAAAAHgBwAAEAAAAvAAAAW1JvbGxdIGRldGVybWluaW5nIGRvd253YXJkIHJvdXRl cyBhdCB0aGUgcm9vdAAAAgFxAAEAAAAbAAAAAcsn7YE0s6sQ0MIeS+uyprxTvkf+VwAEDwMAAB4A GgwBAAAAFgAAAHJvbGwtYm91bmNlc0BpZXRmLm9yZwAAAB4AHQ4BAAAALwAAAFtSb2xsXSBkZXRl cm1pbmluZyBkb3dud2FyZCByb3V0ZXMgYXQgdGhlIHJvb3QAAAIBCRABAAAAnQMAAJkDAAAPBgAA TFpGdW/EHsQDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUO UQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYW UAumIEiCaQXQdWt1bDoKolMKhAqAVGgEACAeYWGMIHAYIAJAeSBjC2DXBBAN4AdAIBggYwhwAJBc dmUf4AhgDrAgF7BvgR1AcC4gT25sHzAsdGggcB5QZyHQc3RbHYQe4WYEkAnwYyBwMWhob3AghXMj kB1QZO8kIgfgITAkIG8f6CGVA2AWbwVAA/BsAyBxdWnjDrAdhG5hdAhwB0Ahkf5iJwAkcSHCJSAI cCNRIJR9IdBhBIEhUAgAILALgGcbHtEmcG8XkQQgdXN1eSfzZG8nRSZxAQAE8mJzJBEa0GggI6AE kCewadcCICFQHYpEJTB5CGAhsb0LgGshshggHoQFEHMvkHBvZiBtBAALgA6wcmse4i2zPy4VVyRU A3Bl3wIgIHAl0BQQHtBsKcAzcd8kMAdxHoAx4B2KUB9wH7GjHYodhD4gLTcCTwUQFmcLgB/BTQeQ c2Fn1mU3AzaGRgNhOiCBJsDKLQbgdSNBc0AIkAAwdi4FsCqQWwDAAxAq4DqLOY86kl0hYSBCZRPg dGxmHYRPPVU24B0jIPhHb3k1pjbgBmACMDlgAlQKUHNkYXksIL5KHVAfMAHQQGAB0DEWUFgxMToO MBDATTaGVMc7QDlzPxd1YmoFkD/B/lsIACbAPLABADExMOADAOMqgSvQd253CxEghB6h7wVAJhY2 hjaGSSaQH3AmkH8CIASBKnIGkB6ABUAAwGu/B5EUEACAIHAq4B6wZDK0jyGwDsJJ8SHCUlBMK8Dv J+ABgB2EGCBnCxEqcTaGvySyK9BF8iZDQGALgCAsUBxuLSJQBbAqckxMTu9AYERmSdEh0V8kMQAg IkH+X0UXNoZFtUnxTLABICMSvyxzKmEtsysyKnIhwiIKsI8hwB9AAiE7YSIgdgdA20ABHrBzHYQh wigLgCBgdRQBKTaGbC9yBaAiUHPuLkbeHkAAcGtWdT5FNob+X1ufXK9dejaGRAJJIQMQfypyWDAi Vl7kOkdM9wJAcKBzOi8vd2JgLjpWdi868gOBL1/SC4ACEC//Qqhdf2XvXb8KgF8PZ9hg3Rdh72L/ ZAx9beAAAAAeADUQAQAAAEEAAAA8NkEyQTQ1OTE3NURBQkU0QkIxMURFMjAyNkFBNTBBNUQwMjU3 NTI2RUBYTUItQU1TLTEwNy5jaXNjby5jb20+AAAAAB4AORABAAAAlQAAADwyMTQ0MTM5MzkwLjEy NTg3MC4xMjc5NjE3ODI5OTA4LkphdmFNYWlsLnJvb3RAbWFpbDAyLnBhbnRoZXJsaW5rLnV3bS5l ZHU+PDE0MzE1MjU4ODIuMTI1ODc4LjEyNzk2MTc5MjU4NzQuSmF2YU1haWwucm9vdEBtYWlsMDIu cGFudGhlcmxpbmsudXdtLmVkdT4AAAAAHgBCEAEAAABLAAAAPDE0MzE1MjU4ODIuMTI1ODc4LjEy Nzk2MTc5MjU4NzQuSmF2YU1haWwucm9vdEBtYWlsMDIucGFudGhlcmxpbmsudXdtLmVkdT4AAB4A QxABAAAALAAAADxtYWlsdG86cm9sbC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4AHgBE EAEAAABeAAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD4sPG1h aWx0bzpyb2xsLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+AAAAHgBFEAEAAABg AAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD4sPG1haWx0bzpy b2xsLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4ACwDyEAAAQAAfAPMQAQAA AHIAAABSAGUAJQAzAEEAIABbAFIAbwBsAGwAXQAgAGQAZQB0AGUAcgBtAGkAbgBpAG4AZwAgAGQA bwB3AG4AdwBhAHIAZAAgAHIAbwB1AHQAZQBzACAAYQB0ACAAdABoAGUAIAByAG8AbwB0AC4ARQBN AEwAAAAAAEAABzAmz9Zq/ifLAUAACDABu+Jq/ifLAQMA3j+vbwAAAwDfP/////8DAPE/AAAAAB4A +D8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+T8BAAAAHgAAAAAAAADcp0DIwEIQ GrS5CAArL+GCAQAAAAAAAAAuAAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAA AgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAA AAEAAwAaQAAAAAAeADBAAQAAABYAAAByb2xsLWJvdW5jZXNAaWV0Zi5vcmcAAAAeADFAAQAAAAkA AABQVEhVQkVSVAAAAAAeADhAAQAAAAIAAAAuAAAAHgA5QAEAAAACAAAALgAAAB4AP0ABAAAABQAA AFNNVFAAAAAAHgBAQAEAAAATAAAAcHRodWJlcnRAY2lzY28uY29tAAAeAEFAAQAAAAUAAABTTVRQ AAAAAB4AQkABAAAAEwAAAHB0aHViZXJ0QGNpc2NvLmNvbQAAHgBBgIYDAgAAAAAAwAAAAAAAAEYB AAAAHAAAAGMAbwBuAHQAZQBuAHQALQBjAGwAYQBzAHMAAAABAAAAHAAAAHVybjpjb250ZW50LWNs YXNzZXM6bWVzc2FnZQALACkAAAAAAAsAIwAAAAAAAwAGEBx2ZHYDAAcQKgMAAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABISU1VS1VMOlRISVNJU0FQUkVUVFlDTEFTU0lDQUxSRUNVUlNJVkVS T1VURUxPT0tVUE9OTFlUSEVISUdIRVNUUFJFRkVSRU5DRTFIT1BST1VURVNIT1VMRFNIT1dVUFNP UkVDAAAAAAIBfwABAAAAQQAAADw2QTJBNDU5MTc1REFCRTRCQjExREUyMDI2QUE1MEE1RDAyNTc1 MjZFQFhNQi1BTVMtMTA3LmNpc2NvLmNvbT4AAAAA7M0= ------_=_NextPart_001_01CB27FE.6A5F5480-- ------------=_1279658090-14507-1-- From pthubert@cisco.com Tue Jul 20 13:44:17 2010 Return-Path: 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 D5DC03A69B2 for ; Tue, 20 Jul 2010 13:44:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 u8I7p9g4wU3v for ; Tue, 20 Jul 2010 13:44:17 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279658657-17029-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 47ACD3A6964 for ; Tue, 20 Jul 2010 13:44:17 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 20:44:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKiWEv001877 for ; Tue, 20 Jul 2010 20:44:33 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:15:03 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:31:36 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 06:26:37 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 11:26:26 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQ8R7027225; Tue, 20 Jul 2010 11:26:26 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 11:26:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC07A3A6A0A; Tue, 20 Jul 2010 04:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2103A67B5 for ; Tue, 20 Jul 2010 04:26:08 -0700 (PDT) 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 pJC28v5Z4Jpv for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 426153A688E for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 11:26:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQEts000369; Tue, 20 Jul 2010 11:26:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:26:04 +0200 Date: Tue, 20 Jul 2010 06:26:00 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> In-Reply-To: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> References: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu><1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" Subject: Re: [Roll] determining downward routes at the root 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: , X-List-Received-Date: Tue, 20 Jul 2010 20:44:18 -0000 This is a multi-part message in MIME format... ------------=_1279658657-17029-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279658657-17029-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 47ACD3A6964 for ; Tue, 20 Jul 2010 13:44:17 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 2939 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPamRUyrR7Hu/2dsb2JhbACfc3GmWpsYhTIEhACHDocP Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 20:44:32 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKiWEv001877 for ; Tue, 20 Jul 2010 20:44:33 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:15:03 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:31:36 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 06:26:37 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27FE.6A5F5480" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 11:26:26 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQ8R7027225; Tue, 20 Jul 2010 11:26:26 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 11:26:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC07A3A6A0A; Tue, 20 Jul 2010 04:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2103A67B5 for ; Tue, 20 Jul 2010 04:26:08 -0700 (PDT) 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 pJC28v5Z4Jpv for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 426153A688E for ; Tue, 20 Jul 2010 04:26:07 -0700 (PDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 11:26:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KBQEts000369; Tue, 20 Jul 2010 11:26:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 13:26:04 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] determining downward routes at the root Date: Tue, 20 Jul 2010 06:26:00 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> In-Reply-To: <1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: <6A2A459175DABE4BB11DE2026AA50A5D0257526E@XMB-AMS-107.cisco.com> Thread-Topic: [Roll] determining downward routes at the root Thread-Index: Acsn7YE0s6sQ0MIeS+uyprxTvkf+VwAEDwMA References: <2144139390.125870.1279617829908.JavaMail.root@mail02.pantherlink.uwm.edu><1431525882.125878.1279617925874.JavaMail.root@mail02.pantherlink.uwm.edu> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" X-OriginalArrivalTime: 20 Jul 2010 11:31:36.0738 (UTC) FILETIME=[1D07B820:01CB27FF] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27FE.6A5F5480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mukul: This is a pretty classical recursive route lookup. Only the highest preference 1hop route should show up so recursively the root will quite naturally build the source route header. Routing protocols usually do not describe such operation.=20 Do you think there is a risk of misinterpretation?=20 Would someone else please shime in? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Tuesday, July 20, 2010 11:25 AM > To: roll > Subject: [Roll] determining downward routes at the root >=20 > I was wondering if it makes sense to add some text to the RPL draft regarding > how does a root, in non-storing LLN, determine the _shortest_ downward > routes to different destinations using the "path control" values as the (inverse) > link costs. >=20 > Thanks > Mukul > _______________________________________________ > 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 ------_=_NextPart_001_01CB27FE.6A5F5480 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiULAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAMwAAAFJlOiBbUm9sbF0gZGV0ZXJt aW5pbmcgZG93bndhcmQgcm91dGVzIGF0IHRoZSByb290AJoSAQWAAwAOAAAA2gcHABQABgAaAAAA AgAeAQEggAMADgAAANoHBwAUAAYAGgAlAAIAQwEBCYABACEAAAA0QTU3QkE5RjZEODM1NDRCQUZC MTMyNUU4M0FGRDg1MABTBwEDkAYAfAoAAC0AAAADADYAAAAAAEAAOQAAlFFU/ifLAR4APQABAAAA BQAAAFJlOiAAAAAAHgBwAAEAAAAvAAAAW1JvbGxdIGRldGVybWluaW5nIGRvd253YXJkIHJvdXRl cyBhdCB0aGUgcm9vdAAAAgFxAAEAAAAbAAAAAcsn7YE0s6sQ0MIeS+uyprxTvkf+VwAEDwMAAB4A GgwBAAAAFgAAAHJvbGwtYm91bmNlc0BpZXRmLm9yZwAAAB4AHQ4BAAAALwAAAFtSb2xsXSBkZXRl cm1pbmluZyBkb3dud2FyZCByb3V0ZXMgYXQgdGhlIHJvb3QAAAIBCRABAAAAnQMAAJkDAAAPBgAA TFpGdW/EHsQDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUO UQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYW UAumIEiCaQXQdWt1bDoKolMKhAqAVGgEACAeYWGMIHAYIAJAeSBjC2DXBBAN4AdAIBggYwhwAJBc dmUf4AhgDrAgF7BvgR1AcC4gT25sHzAsdGggcB5QZyHQc3RbHYQe4WYEkAnwYyBwMWhob3AghXMj kB1QZO8kIgfgITAkIG8f6CGVA2AWbwVAA/BsAyBxdWnjDrAdhG5hdAhwB0Ahkf5iJwAkcSHCJSAI cCNRIJR9IdBhBIEhUAgAILALgGcbHtEmcG8XkQQgdXN1eSfzZG8nRSZxAQAE8mJzJBEa0GggI6AE kCewadcCICFQHYpEJTB5CGAhsb0LgGshshggHoQFEHMvkHBvZiBtBAALgA6wcmse4i2zPy4VVyRU A3Bl3wIgIHAl0BQQHtBsKcAzcd8kMAdxHoAx4B2KUB9wH7GjHYodhD4gLTcCTwUQFmcLgB/BTQeQ c2Fn1mU3AzaGRgNhOiCBJsDKLQbgdSNBc0AIkAAwdi4FsCqQWwDAAxAq4DqLOY86kl0hYSBCZRPg dGxmHYRPPVU24B0jIPhHb3k1pjbgBmACMDlgAlQKUHNkYXksIL5KHVAfMAHQQGAB0DEWUFgxMToO MBDATTaGVMc7QDlzPxd1YmoFkD/B/lsIACbAPLABADExMOADAOMqgSvQd253CxEghB6h7wVAJhY2 hjaGSSaQH3AmkH8CIASBKnIGkB6ABUAAwGu/B5EUEACAIHAq4B6wZDK0jyGwDsJJ8SHCUlBMK8Dv J+ABgB2EGCBnCxEqcTaGvySyK9BF8iZDQGALgCAsUBxuLSJQBbAqckxMTu9AYERmSdEh0V8kMQAg IkH+X0UXNoZFtUnxTLABICMSvyxzKmEtsysyKnIhwiIKsI8hwB9AAiE7YSIgdgdA20ABHrBzHYQh wigLgCBgdRQBKTaGbC9yBaAiUHPuLkbeHkAAcGtWdT5FNob+X1ufXK9dejaGRAJJIQMQfypyWDAi Vl7kOkdM9wJAcKBzOi8vd2JgLjpWdi868gOBL1/SC4ACEC//Qqhdf2XvXb8KgF8PZ9hg3Rdh72L/ ZAx9beAAAAAeADUQAQAAAEEAAAA8NkEyQTQ1OTE3NURBQkU0QkIxMURFMjAyNkFBNTBBNUQwMjU3 NTI2RUBYTUItQU1TLTEwNy5jaXNjby5jb20+AAAAAB4AORABAAAAlQAAADwyMTQ0MTM5MzkwLjEy NTg3MC4xMjc5NjE3ODI5OTA4LkphdmFNYWlsLnJvb3RAbWFpbDAyLnBhbnRoZXJsaW5rLnV3bS5l ZHU+PDE0MzE1MjU4ODIuMTI1ODc4LjEyNzk2MTc5MjU4NzQuSmF2YU1haWwucm9vdEBtYWlsMDIu cGFudGhlcmxpbmsudXdtLmVkdT4AAAAAHgBCEAEAAABLAAAAPDE0MzE1MjU4ODIuMTI1ODc4LjEy Nzk2MTc5MjU4NzQuSmF2YU1haWwucm9vdEBtYWlsMDIucGFudGhlcmxpbmsudXdtLmVkdT4AAB4A QxABAAAALAAAADxtYWlsdG86cm9sbC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscD4AHgBE EAEAAABeAAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD4sPG1h aWx0bzpyb2xsLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+AAAAHgBFEAEAAABg AAAAPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD4sPG1haWx0bzpy b2xsLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4ACwDyEAAAQAAfAPMQAQAA AHIAAABSAGUAJQAzAEEAIABbAFIAbwBsAGwAXQAgAGQAZQB0AGUAcgBtAGkAbgBpAG4AZwAgAGQA bwB3AG4AdwBhAHIAZAAgAHIAbwB1AHQAZQBzACAAYQB0ACAAdABoAGUAIAByAG8AbwB0AC4ARQBN AEwAAAAAAEAABzAmz9Zq/ifLAUAACDABu+Jq/ifLAQMA3j+vbwAAAwDfP/////8DAPE/AAAAAB4A +D8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+T8BAAAAHgAAAAAAAADcp0DIwEIQ GrS5CAArL+GCAQAAAAAAAAAuAAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAA AgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAA AAEAAwAaQAAAAAAeADBAAQAAABYAAAByb2xsLWJvdW5jZXNAaWV0Zi5vcmcAAAAeADFAAQAAAAkA AABQVEhVQkVSVAAAAAAeADhAAQAAAAIAAAAuAAAAHgA5QAEAAAACAAAALgAAAB4AP0ABAAAABQAA AFNNVFAAAAAAHgBAQAEAAAATAAAAcHRodWJlcnRAY2lzY28uY29tAAAeAEFAAQAAAAUAAABTTVRQ AAAAAB4AQkABAAAAEwAAAHB0aHViZXJ0QGNpc2NvLmNvbQAAHgBBgIYDAgAAAAAAwAAAAAAAAEYB AAAAHAAAAGMAbwBuAHQAZQBuAHQALQBjAGwAYQBzAHMAAAABAAAAHAAAAHVybjpjb250ZW50LWNs YXNzZXM6bWVzc2FnZQALACkAAAAAAAsAIwAAAAAAAwAGEBx2ZHYDAAcQKgMAAAMAEBAAAAAAAwAR EAAAAAAeAAgQAQAAAGUAAABISU1VS1VMOlRISVNJU0FQUkVUVFlDTEFTU0lDQUxSRUNVUlNJVkVS T1VURUxPT0tVUE9OTFlUSEVISUdIRVNUUFJFRkVSRU5DRTFIT1BST1VURVNIT1VMRFNIT1dVUFNP UkVDAAAAAAIBfwABAAAAQQAAADw2QTJBNDU5MTc1REFCRTRCQjExREUyMDI2QUE1MEE1RDAyNTc1 MjZFQFhNQi1BTVMtMTA3LmNpc2NvLmNvbT4AAAAA7M0= ------_=_NextPart_001_01CB27FE.6A5F5480-- ------------=_1279658657-17029-1-- From pthubert@cisco.com Tue Jul 20 15:59:01 2010 Return-Path: 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 B2FBE3A68A2 for ; Tue, 20 Jul 2010 15:59:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 QVZq4kMS5V3E for ; Tue, 20 Jul 2010 15:59:00 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279666741-17911-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4B01B3A685B for ; Tue, 20 Jul 2010 15:59:00 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 22:59:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMxFVg022172; Tue, 20 Jul 2010 22:59:15 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:00:54 -0700 Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 00:06:27 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 01:46:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 06:46:14 +0000 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6kD3p003114; Tue, 20 Jul 2010 06:46:13 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 20 Jul 2010 06:46:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56033A6BE8; Mon, 19 Jul 2010 23:45:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEF03A6BE9 for ; Mon, 19 Jul 2010 23:45:55 -0700 (PDT) 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 V6CSBzVlw3BW for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 63CC03A6BE6 for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:46:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6k3FB011735; Tue, 20 Jul 2010 06:46:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 08:45:34 +0200 Date: Tue, 20 Jul 2010 01:45:30 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02575106@XMB-AMS-107.cisco.com> In-Reply-To: References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> <12834.1279413508@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "Michael Richardson" , "ROLL WG" Subject: Re: [Roll] The word Up! 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: , X-List-Received-Date: Tue, 20 Jul 2010 22:59:01 -0000 This is a multi-part message in MIME format... ------------=_1279666741-17911-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279666741-17911-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4B01B3A685B for ; Tue, 20 Jul 2010 15:59:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 4688 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvGRUyrR7H+/2dsb2JhbACfdnGmPYxjjieFMgSEAIcO Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 22:59:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMxFVg022172; Tue, 20 Jul 2010 22:59:15 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:00:54 -0700 Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 00:06:27 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 01:46:20 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27D7.42A8C600" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 06:46:14 +0000 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6kD3p003114; Tue, 20 Jul 2010 06:46:13 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-a.cisco.com with ESMTP; 20 Jul 2010 06:46:13 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56033A6BE8; Mon, 19 Jul 2010 23:45:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEF03A6BE9 for ; Mon, 19 Jul 2010 23:45:55 -0700 (PDT) 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 V6CSBzVlw3BW for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 63CC03A6BE6 for ; Mon, 19 Jul 2010 23:45:54 -0700 (PDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:46:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6k3FB011735; Tue, 20 Jul 2010 06:46:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 08:45:34 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] The word Up! Date: Tue, 20 Jul 2010 01:45:30 -0500 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02575106@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: <6A2A459175DABE4BB11DE2026AA50A5D02575106@XMB-AMS-107.cisco.com> Thread-Topic: [Roll] The word Up! Thread-Index: Acsmfu3y0Rlbyf4HTMmHoZTHoF6dEABVEhwAAACqywA= References: <4BBF63CC.3060101@gmail.com> <4550E708-B354-49A9-94F4-2EBD9210ED4E@cs.jhu.edu> <4BBF69C8.3010409@gmail.com> <4BBFA883.2040505@gmail.com> <7ECB820F-7178-476D-9E41-FA2B054B6587@cs.jhu.edu> <4BBFB78D.4080801@gmail.com> <16320.1271118718@marajade.sandelman.ca> <12834.1279413508@marajade.sandelman.ca> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "Michael Richardson" , "ROLL WG" X-OriginalArrivalTime: 20 Jul 2010 07:06:27.0280 (UTC) FILETIME=[12411500:01CB27DA] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27D7.42A8C600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yoav: =20 > Maybe define in the terminology or introduction: > Spatial movement - RPL can be used by mobile nodes, but this movement will > not be discussed/affect explicitly RPL nodes. > Topology movement - where the terms up/down in the RPL spec mean:.... =20 [Pascal]=20 Agreed. RPL can be used by mobile nodes. They will probably rather build trees than DAGs (see MANEMO). > BTW - just a thought - should spatial movement capability be an explicit part of > the OF/metric definitions in the metrics draft as a special object (for example, > describing speed, heading, azimuth, etc.), such as Node Energy (NE), or is this a > TLV for example in the Node State/Attribute (NSA)? [Pascal]=20 Great point. When applying this sort of technology to cars or trains (e.g. ITS), we found that the capability to detect nodes along a same trajectory was crucial, in order to setup peerings that would persist enough to enable classical interaction. Also, when using GPS and common topological maps, it is possible to advertise "going along road 109", which is another way of qualifying a direction. It could even be possible to affect 8::/3 prefixes to routes for the purpose of local addressing (like Autoconf and CoA) and document that in the GPS tables. As far as RPL is concerned, this is left open for new metrics drafts to dig in.=20 > Best regards, > Yoav >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Sunday, July 18, 2010 3:38 AM > To: ROLL WG > Subject: Re: [Roll] The word Up! >=20 >=20 > {my appologies for time warp email, I'm cleaning out my RPL unread folder...} >=20 > >>>>> "Philip" =3D=3D Philip Levis writes: > >>> I suggest that we might want to come up with a different term > >>> than "move" to describe topology changes. > >> Makes sense. > >> > >> If you change > >> > >> Root / \ A B / C > >> > >> By C--A--Root--B, now things move left <-> right, no more up and > >> down. > >> > >> I believe the whole movement concept is confusing. >=20 > Philip> What terminology do you think would be better? >=20 > Philip> The notion of up/down and shallower/deeper are basic > Philip> terminology in tree data structures and algorithms. E.g., > Philip> depth first search. >=20 > The issue I have is that the nodes usually do not move in physical space. > There are situations where they *do*, and it's important to distinguish this. >=20 > Philip> "Move" could be "change its position within the DODAG?" >=20 > I suggest that we a term like "reattach" or something like that. > Or some other synonym for move. What was it called in M.A.S.H. when they > had to invoke the "Mobile" part of the name? >=20 > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video > > then sign the petition. >=20 > _______________________________________________ > 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 ------_=_NextPart_001_01CB27D7.42A8C600 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhsHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGAAAAFJlOiBbUm9sbF0gVGhlIHdv cmQgVXAhAIUHAQWAAwAOAAAA2gcHABQAAQAtAB4AAgBKAQEggAMADgAAANoHBwAUAAIABgAYAAIA HgEBCYABACEAAAA4RDFFOTM4Q0E1Q0U2RDRGODVBNDVENzlDNDBBQUE2NQBrBwEDkAYAbBEAADAA AAADADYAAAAAAEAAOQAAYdsk1yfLAR4APQABAAAABQAAAFJlOiAAAAAAHgBwAAEAAAAUAAAAW1Jv bGxdIFRoZSB3b3JkIFVwIQACAXEAAQAAACAAAAAByyZ+7fLRGVvJ/gdMyYehlMegXp0QAFUSHAAA AKrLAB4AGgwBAAAAFgAAAHJvbGwtYm91bmNlc0BpZXRmLm9yZwAAAB4AHQ4BAAAAFAAAAFtSb2xs XSBUaGUgd29yZCBVcCEAAgEJEAEAAACRCQAAjQkAAOkQAABMWkZ14GntBAMACgByY3BnMTI14jID Q3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYz BEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSIBpIFlvYXY6CqIXCoAK4wqA PgXQYXliPGUgAQELgB6gC4AgdGZoHqAOsHJtC4AXoWeseSAFsQuAdANgZBrQ3HRpAiAdZR5AUwqw IRBlB0AgBGB2ZQeAAjAgwi0H8FBMIGMDkR6RunUUEGQjgCBABGBiAxCnHqAf8AEAcywjgHUFQN8f YAQAIlcddAPwbBgAHfVvH/AFQB6SBABjI8Aj0S9+YQEgBZAFQA7AC1AN4GlcdGwgQCMSJLMuHeZU 7G9wIAQiaXcfcBggH1eBBCB1cC9kb3cDoLMfNSMSc3AFkCJQZQBwjDouLrEde1tQYQTwlQdAXR3V QQnCZC4jDzskHTEQVB9wIEAmkiBw7QNgYgGgKVFyIgAr8SUR/wMQCzEdkiCwCeAEIB9gA5FoREFH BCAoFBAeoE3AQU5FTU8pKhU3atEeQEJUVyLhajHgBUCmYR9RCGBnaCLSczmB/zUQLgEiDTFwCrAk YSkwIEB/HpEAcB10KNYz0ArABUBvxmYd5h9iT0YvB4AgsP8N4B60KTAhIQQgHzU+5AQg/mQ0cAGA OUAEIDlQLhIiIu0kUGookR10KAIQBcAOwORhbQtQZSwd5iTRBQF5JGBuZy4CCYAlAB9wYWcnwETA JQBhegdwJTBooyUAFCBjLiklAHMa0EpoQVJOBHEgRR8Acv0gMSg3AEbAHXQgYjXSJYHiYSonTFYg QwkfJkdz5lMBkA6wL0ECQESBJTDDHqBIMFNBKT83ai/NbkcYICIAM9BvIJExEFdvH3ADoDugC1B5 RLIlY3OfF8E9wR+RE9Af9XRvMWEvFAAgUiCwC3FzQpVlLqJnMRBJVFNGwXceoPkCEHVuMhA18SVC HqA7mf9SIQEAUXEFQCSzOUAXsETB60GRQ2BlNTZhQlIFsDNx/0FhBQAa0AcxJQAfMQWwBIH/UhIU ESzgM9AJ4AUQRMA10/0FQHc6My4gFAAEACYlCfD/OZJSEgnwNCFVUQtgBBAN4D8iMSCRBJAA0CES MRBBbJ9Q8FQxT9Ix4ESyR1AF8PcAcDIQBaBtBGA8hVIgKsP7XlMAwHAk8T1RJYEqwF4xf13CUiFF gCKAACAEAB6gIj5nT2FXYVczA2BFgCAx+DA5IkO1K+AN4EcgSWKfJ1E0oljwIEFRUHF1B0C/BpBQ UzlQJ8AYIF8FSTtxfTozZSKAMZIddGNLKHQ4sDo6LzMz0R7ReDXCv1IwA2BMoQQgQwIfYnAIcP9j QR6gUUEXsDABHXRFgEEAqweQYDMoKQBrHqBBJTD/btACIFFQYMIIUE0QYLMtEP8n8CKjVOMfNWCC AZEkgCoGfkFtcQrBQWExMiWBcMFj/wSRRSIlYyWBJIBBMSqwT+H/QwIfAAfgQIts0h10J8BE0L8L gDEQN80HkAVAGCBnCxFfJPAd5h0iHeZ8Di19gk8vBRBiIF2gAyBNb7FhZ9ZlfYMd5kYDYTplYSaw zi0G4FSgdYBzQAiQADB2LgWwRNBbAMADEFIgOneAD4ESMDBPA6B6cBPgbJU95U89501mkWFlAyB+ UoTyewFhRiHBIrF/4FM3VKEecCUASjpAIEAxOAclAAHQZcAgMzozOI0QwE0qKH/gUk9MMVC0V0ch Z3VCQ4lRZX/gflsIACawMDAzQVuxCyAgmFVwIXwPjHZ7bSBA/1ARYfNtZgdxWOFuMCjAgXLxJQBJ J21d8S5xRLJtMf8iUClkVKBPATUlAhA1EASQtS7CfYzuPpQiZJBQJXCBKQBwIiA9PSCUlCwgTGoA JYE8CrBsQH1A0C45IABwQwExAAmAdX0eQHcFEG1RIVeYUpRCSf1G4Wd+sDkhW3RAYXkgOcH/WPBy QlIxA3AxwVrAA/AfYH9okyhxGCByQh+xl+418yL/ImKU8FYjRGNjsirFE9FEwP8p+ZhkHlFwUFDR CfAUEKA99aBNSVFQeQhgn7Wh/6B66wgAJ2EvAzBcEMA4kKahVkOkn6B6QiBAQ32AQfd9gKZifYBC JQAf8AfgJWHnWzIiYnZ0PC0eQH3hOcD/qkIiUSwRLOBvFVSwoE0tEv+h76L8MaEpAGoBH1Mr4Abw 30BhOxd1YgUxdSRmYCMqF/+X6pSUHkBPwFUCH7ktEKPj/aqia1u1HpEekAJABJBNNf+0L7Uzi6In USEhUTIs5mDC7zoQB0AXsFRQci0ACeBcIf85QCwRNBAN0bjvtVEfqh8y/wnRHrAiAEGRILAg8Qhw VvJvVLEHQGSwl4FoLLAxEEX/U7FDt7TKAQAFMEcgHuAUAP8FQBQQCsAT0LO/i6IEAQpQ/5jRE+Cr MUkTVQVWxDHgaAEfKVG2kSdSqxMfMXBoef9eQx10OoF1gCoYK/O80gCQX1qgIgE/0ivnIEAqLRAq 90XRVLEpMCc/8UNwF8GadP94tjkgRLE08DoQJVPEn7TK3CJNniNppB6RIp/EYtFPYyM/o5tTHzVE TzZBP34ijO6Y7zlCH7FusHBCIv9PAgGQE9CU8AWxUPA+4aqyf9fUVOIqF33Q2QMgUDSTc/p5H/Bu BsBKUyJiMRC1dD9Y8j1RMAEkgM2BA6BNLuBBLlMuSDEQX9I1NT8zUR3mE+BUwVIwC4B2b//Z02SB 0fAkYpTwPYXHJFex77hffwgwMOSkSLFjSQNo0fMyEFFBV2Vo0DIQX3Dle9loIWUh5KWYUnwd5sPR vwfQu+EEIIFQ5BqE724lAKsGEQEAbAOCUz3QdI9x1R6gVwWwayTxT9hxWPD97WFO6FMfACYlHkDE UpeR6yEA6dltBQBAV6DsBYEQv+2TgRBfQDFwRVACQHBsILwvd/KAloDwv/HCLx10/nwBAJXQdYBD xwUQZCHp1+2YUUuj8FIhUApAl8BY4X9GkM+yHqCV0AEAeKUeQDz/8hmj8VqgHpDx0ANw8nD3cgA/ dj1rengxecBjTFhRU0WvpwyC3+fpmFMfYQOgAJBnH0QuIPchEF8TjO5f/88A3wGqHeb/i0JicTvh 2YNcdgMUgMfft3/yIZfA8mSA1j7QgYHxAS/3BAILgEpgL4Hi/08JvwrP/wJ/A48EnwWvBr8Hzx2S Cx//E48LXxqgDK8VeA59D48QnwUIPH0bgAAAAB4ANRABAAAAQQAAADw2QTJBNDU5MTc1REFCRTRC QjExREUyMDI2QUE1MEE1RDAyNTc1MTA2QFhNQi1BTVMtMTA3LmNpc2NvLmNvbT4AAAAAHgA5EAEA AAAAAgAAPDRCQkY2M0NDLjMwNjAxMDFAZ21haWwuY29tPgk8NDU1MEU3MDgtQjM1NC00OUE5LTk0 RjQtMkVCRDkyMTBFRDRFQGNzLmpodS5lZHU+CTw0QkJGNjlDOC4zMDEwNDA5QGdtYWlsLmNvbT4J PEIzQUI5OEQ1LUI0QjUtNDgwMC1BMzVCLTAwOTlBQkREMzY0RkBjcy5qaHUuZWR1Pgk8NEJCRkE4 ODMuMjA0MDUwNUBnbWFpbC5jb20+CTw3RUNCODIwRi03MTc4LTQ3NkQtOUU0MS1GQTJCMDU0QjY1 ODdAY3Muamh1LmVkdT4JPDRCQkZCNzhELjQwODA4MDFAZ21haWwuY29tPgk8MTYzMjAuMTI3MTEx ODcxOEBtYXJhamFkZS5zYW5kZWxtYW4uY2E+CTx6MmwyMDI3MDViMTAwNDEyMjAyN3NjYzUwMjc5 M3ZhNTI4NmI1ZjA2NmNhQG1haWwuZ21haWwuY29tPgk8QjFCMjZEODMtNkY3Ri00RUQzLUFDNkIt NTdDMTVDNjk3OUFCQGNzLnN0YW5mb3JkLmVkdT48MTI4MzQuMTI3OTQxMzUwOEBtYXJhamFkZS5z YW5kZWxtYW4uY2E+PGQ4YTk2OTQ4YThiNzhlMWFjYzk4NTEwMjE2NjBiYjZlQG1haWwuZ21haWwu Y29tPgAeAEIQAQAAADIAAAA8ZDhhOTY5NDhhOGI3OGUxYWNjOTg1MTAyMTY2MGJiNmVAbWFpbC5n bWFpbC5jb20+AAAAHgBDEAEAAAAsAAAAPG1haWx0bzpyb2xsLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD1oZWxwPgAeAEQQAQAAAF4AAAA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yb2xsPiw8bWFpbHRvOnJvbGwtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXN1YnNjcmli ZT4AAAAeAEUQAQAAAGAAAAA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y b2xsPiw8bWFpbHRvOnJvbGwtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXVuc3Vic2NyaWJlPgAL APIQAAAAAB8A8xABAAAAPAAAAFIAZQAlADMAQQAgAFsAUgBvAGwAbABdACAAVABoAGUAIAB3AG8A cgBkACAAVQBwACEALgBFAE0ATAAAAAsA9BAAAAAACwD1EAAAAAALAPYQAAAAAEAABzDaKktD1yfL AUAACDDQHXQQ2ifLAQMA3j+vbwAAAwDfP/////8DAPE/AAAAAB4A+D8BAAAAFQAAAFN5c3RlbSBB ZG1pbmlzdHJhdG9yAAAAAAIB+T8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAu AAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANyn QMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAEAAwAaQAAAAAAeADBAAQAA ABYAAAByb2xsLWJvdW5jZXNAaWV0Zi5vcmcAAAAeADFAAQAAAAkAAABQVEhVQkVSVAAAAAAeADhA AQAAAAIAAAAuAAAAHgA5QAEAAAACAAAALgAAAB4AP0ABAAAABQAAAFNNVFAAAAAAHgBAQAEAAAAT AAAAcHRodWJlcnRAY2lzY28uY29tAAAeAEFAAQAAAAUAAABTTVRQAAAAAB4AQkABAAAAEwAAAHB0 aHViZXJ0QGNpc2NvLmNvbQAAHgBBgIYDAgAAAAAAwAAAAAAAAEYBAAAAHAAAAGMAbwBuAHQAZQBu AHQALQBjAGwAYQBzAHMAAAABAAAAHAAAAHVybjpjb250ZW50LWNsYXNzZXM6bWVzc2FnZQALACkA AAAAAAsAIwAAAAAAAwAGED0lAuUDAAcQxwkAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABI SVlPQVY6TUFZQkVERUZJTkVJTlRIRVRFUk1JTk9MT0dZT1JJTlRST0RVQ1RJT046U1BBVElBTE1P VkVNRU5ULVJQTENBTkJFVVNFREJZTU9CSUxFTk9ERVMsQlVUVEhJU01PAAAAAAIBfwABAAAAQQAA ADw2QTJBNDU5MTc1REFCRTRCQjExREUyMDI2QUE1MEE1RDAyNTc1MTA2QFhNQi1BTVMtMTA3LmNp c2NvLmNvbT4AAAAALFI= ------_=_NextPart_001_01CB27D7.42A8C600-- ------------=_1279666741-17911-1-- From jpv@cisco.com Tue Jul 20 19:22:48 2010 Return-Path: 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 D79C93A6B43 for ; Tue, 20 Jul 2010 19:22:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 EsK1hloHLSSW for ; Tue, 20 Jul 2010 19:22:47 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279678968-2885-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 73B023A6B27 for ; Tue, 20 Jul 2010 19:22:47 -0700 (PDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2010 02:22:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6L2M15A017672; Wed, 21 Jul 2010 02:22:48 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:24:47 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 02:47:19 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:44:43 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 09:44:41 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9ievD028274; Tue, 20 Jul 2010 09:44:40 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 09:44:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABFA3A6C1F; Tue, 20 Jul 2010 02:44:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446D43A69DF for ; Tue, 20 Jul 2010 02:44:23 -0700 (PDT) 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 z+H2PrpPfRD8 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6168E3A6452 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 09:44:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9iL1P026616; Tue, 20 Jul 2010 09:44:37 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Received: from [192.168.3.55] ([10.61.107.218]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Date: Tue, 20 Jul 2010 04:44:27 -0500 Message-ID: In-Reply-To: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> References: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> From: "JP Vasseur" To: "Mukul Goyal" , "Philip Levis" Cc: roll WG Subject: Re: [Roll] Section 3.4 in RPL-10 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: , X-List-Received-Date: Wed, 21 Jul 2010 02:22:49 -0000 This is a multi-part message in MIME format... ------------=_1279678968-2885-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279678968-2885-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 73B023A6B27 for ; Tue, 20 Jul 2010 19:22:47 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 3089 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFv3RUyrRN+J/2dsb2JhbACfc3GlPJsQhTIEhACEWYI1hw8 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2010 02:22:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6L2M15A017672; Wed, 21 Jul 2010 02:22:48 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:24:47 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 02:47:19 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:44:43 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27F0.2E24F780" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 09:44:41 +0000 Received: from sj-inbound-b.cisco.com (sj-inbound-b.cisco.com [128.107.234.205]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9ievD028274; Tue, 20 Jul 2010 09:44:40 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-b.cisco.com with ESMTP; 20 Jul 2010 09:44:39 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABFA3A6C1F; Tue, 20 Jul 2010 02:44:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446D43A69DF for ; Tue, 20 Jul 2010 02:44:23 -0700 (PDT) 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 z+H2PrpPfRD8 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6168E3A6452 for ; Tue, 20 Jul 2010 02:44:22 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 09:44:37 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K9iL1P026616; Tue, 20 Jul 2010 09:44:37 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Received: from [192.168.3.55] ([10.61.107.218]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 11:44:29 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] Section 3.4 in RPL-10 Date: Tue, 20 Jul 2010 04:44:27 -0500 Message-ID: In-Reply-To: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Section 3.4 in RPL-10 Thread-Index: Acsn8C54OBzX/oeGRZmdIzzm84C25A== References: <385564394.125717.1279612637994.JavaMail.root@mail02.pantherlink.uwm.edu> List-Help: List-Subscribe: , List-Unsubscribe: , From: "JP Vasseur" Sender: To: "Mukul Goyal" , "Philip Levis" Cc: "roll WG" X-OriginalArrivalTime: 20 Jul 2010 09:47:19.0106 (UTC) FILETIME=[8B30DA20:01CB27F0] This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27F0.2E24F780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Phil and Mukul, On Jul 20, 2010, at 9:57 AM, Mukul Goyal wrote: > Hi Phil > > "...In the case of a storing > network, P2P packets travel upwards towards a DODAG Root until they > reach a common ancestor with the destination, at which point they > travel down to the destination." > > Not quite. Since the DAO parent set is just a subset of DODAG parent =20 > set, the first common ancestor (of source and destination) may not =20 > know about the destination. Some common ancestor would know but we =20 > dont know which one. We'll make it clearer. Note that there are many other clarifications =20 to be done in Ticket #70. > > Also, the packet may travel upwards in a manner that it does not =20 > reach the first common ancestor that does know about the destination. > JP. > Thanks > Mukul > > > > ----- Original Message ----- > From: "Philip Levis" > To: "Mukul Goyal" > Cc: "roll" > Sent: Monday, July 19, 2010 7:45:15 PM > Subject: Re: [Roll] Section 3.4 in RPL-10 > > On Jul 19, 2010, at 11:55 AM, Mukul Goyal wrote: > >> Here is a quote from Section 3.4 of RPL-10 >> >> "Any given RPL Instance is either >> >> >> >> Winter, et al. Expires December 30, 2010 >> [Page 15] >> >> Internet-Draft draft-ietf-roll-rpl-10 Jun >> 2010 >> >> >> storing or non-storing. In both cases, P2P packets travel up to a >> DODAG Root then down to the final destination (unless the >> destination >> is on the upward route). >> " >> >> I dont think that a P2P packet necessarily always travels to the >> DODAG root in storing mode. It is possible that it turns around at >> a common non-root ancestor of the source and the destination. > > Mukul, > > You're right. I'd suggest removing the last sentence and replacing it > with: > > "In the case of a non-storing network, P2P packets travel up to a > DODAG Root then down to the final destination (unless the destination > is on the upward path to the DODAG Root). In the case of a storing > network, P2P packets travel upwards towards a DODAG Root until they > reach a common ancestor with the destination, at which point they > travel down to the destination." > > What do you think? > > 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 ------_=_NextPart_001_01CB27F0.2E24F780 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhMJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAIQAAAFJlOiBbUm9sbF0gU2VjdGlv biAzLjQgaW4gUlBMLTEwAJ8JAQWAAwAOAAAA2gcHABQABAAsABsAAgBJAQEggAMADgAAANoHBwAU AAQALwASAAIAQwEBCYABACEAAAAxNzYwQThGM0EyRThCNTRFOTU3MEJDQkUzMDY0MURERQBMBwED kAYAJAsAACgAAAADADYAAAAAAEAAOQCAj5sk8CfLAR4APQABAAAABQAAAFJlOiAAAAAAHgBwAAEA AAAdAAAAW1JvbGxdIFNlY3Rpb24gMy40IGluIFJQTC0xMAAAAAACAXEAAQAAABYAAAAByyfwLng4 HNf+h4ZFmZ0jPObzgLbkAAAeABoMAQAAABYAAAByb2xsLWJvdW5jZXNAaWV0Zi5vcmcAAAAeAB0O AQAAAB0AAABbUm9sbF0gU2VjdGlvbiAzLjQgaW4gUlBMLTEwAAAAAAIBCRABAAAAvAUAALgFAABD DAAATFpGdf+kqmMDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQey ESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFk MzYWUAumIEiwaSBQaAMRAHBkBdDgdWt1bCwKogqECoCqTwOgSh3gIAHQLB8xCjEfUWEFQDk6NTcN EMBNH2AdsyBHb3lZB0AgdwNgDrA6Hho+pxzmIiUiJiIuJBBJA6BAdGhlIGNhFBAgxG9mHWAgc3QF sAuAqmciJm4UIHcFsGsfYJBQMlAgCrBjaxQgQQQgdHJhdmUDIHVscHcLESdxbygkJTBE8E9EQUcH 8SGAJ/ACMLsDESRxeSImGCAA0GglId0FoG0EYAOgAHBjB5AlYf0hUGkkcCRjAQAlUAuAH+A2aQIg H8N3HTArIXBvbwuABUAqOieVZCiQJFFvKSy+LiIjHU4poXF1+SyAZS4GAAuALAAkYylAXk8nARgg LpEUESAEACDManUlUCUidWI0ciUBfykkNAUK4yJiFBEfYCRyZq5pFAAFQCt+KCUBcwhhpzNRHXIt CSkgAMB5JjD7KaE2x2s7QAfgAaAIYC6jvzCrBgADcCSRK44IYGwdkPU8E2I8kXckkDbHL/AukR88 Ey4EAiAy8B4aV2UnvmwDIADAJ0A0oDghbCsA/RggcjMAMnEzYh/hJHEYIP8dYEURA4E7ICGARPFD oQrAvwaQDeAtYwQgNsUwQWIs4R9B0TSgA6AHYCcyICM35jBCCyN3QWw5gDeEJxT/OvMnnUhBJTAD gSZABcBEk/9DgS/wB5E7Syr0N68r50STn03zPB8w2CMbHhRKUEkc40hgE+Bua3MiJh2zIxylIx0t WKIgTwUQZy1BxQMgTQeQc2FnJJBYo3UiJkYDYToj8B0iBSAgiExldgQAIiA8CrDgbEBjcy4lUABw AhCVCyAuCYB1I3dUb1shCyCpXBFtHcJAdXdt+V07Q2NbIQNgQwBcEWDi1kAIkAAwLgWwZyN3BmDr AjBbIE0CIGQ7EB9gHwEJOyAxOR9kIDc6NNA1OjE1HRBNYjc1YJZqBZBi4VIhoCBbCAAdQwBdBlFl 4C2BIDMuwjRIMlJQTC0foCMd5x7VY+YfwzExICBk0CBv/yF5I3YigUUCNLElMDKwRFKfA1JmyyUB Z8tseCJBRaH3WTAnwGejICRAXLIzUTSx3mUsgQSQb75vv1cugQSQjx9gNIEHQDMARXhwT8C1B5FE BZBlBtASgTMfVdlsh1tQWdJkwF1z3yRA83URJkEtRCegAYAs8Hoy+i1hoi1g4nsgC1Bn8R7x/wuQ bJZ3KniPNrAlVSTwBcD5O0BuLSVVMwAkQQbgLJHdJLJzJr8nxDAyYX35KSn/JHEDoC/6T7BZUi0J OTAp0P9DwAQRJHFshy0Jffk0sSuxzyRyKAQq4FIhZSlTViPh3X1/SUDEJHALgGtEhCUw/4EYJjEs AVnABRBjsQdAKCD+eSd2KGKGuykkA2ApoUhBv36mBGKAATSTLmAEEGkCYPtEdUOBdAhwBjEKwAhg HYH/H+BshytXf1KRAyvnJQEkcl85iVJvIywduiN3WQhgJ9NFEVkRaHSAAScdkDVQ/mdZ4DUBGCAE YFvgfvEkcv8LYDUBFBB1ATNCHXIYIAtR/mN+4iyAIiYscmwNI/AkT/9/WSY/gY+Cl4NfhG+Ff4aF /4d/InGI7wqwLJIwVCkoikD/gBIkfyWPo68nryi/Kc8q338r7yz/Lg8vHzAvMT8icVfZUSQgeQhg jHQ/Ix0i2fwgX75/v4/AWiImZnI68f9bcX7xW4CugMFqYZciJpwAgHRwczovL3fFQNouYaYvwjID gS/CsguA/QIQL2DiHhrAX8kvwJ8KgL/B78sYw73Ez8Xfxux90SAeADUQAQAAADEAAAA8RjFGQTND NzEtRTg1OC00ODY3LUE1Q0QtRjM2OTNCREU4MDY3QGNpc2NvLmNvbT4AAAAAHgA5EAEAAABKAAAA PDM4NTU2NDM5NC4xMjU3MTcuMTI3OTYxMjYzNzk5NC5KYXZhTWFpbC5yb290QG1haWwwMi5wYW50 aGVybGluay51d20uZWR1PgAAAB4AQhABAAAASgAAADwzODU1NjQzOTQuMTI1NzE3LjEyNzk2MTI2 Mzc5OTQuSmF2YU1haWwucm9vdEBtYWlsMDIucGFudGhlcmxpbmsudXdtLmVkdT4AAAAeAEMQAQAA ACwAAAA8bWFpbHRvOnJvbGwtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PWhlbHA+AB4ARBABAAAA XgAAADxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw+LDxtYWlsdG86 cm9sbC1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9c3Vic2NyaWJlPgAAAB4ARRABAAAAYAAAADxo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw+LDxtYWlsdG86cm9sbC1y ZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU+AAsA8hAAAEAAHwDzEAEAAABOAAAA UgBlACUAMwBBACAAWwBSAG8AbABsAF0AIABTAGUAYwB0AGkAbwBuACAAMwAuADQAIABpAG4AIABS AFAATAAtADEAMAAuAEUATQBMAAAAAABAAAcwBCp4LvAnywFAAAgwG7+7ivAnywEDAN4/r28AAAMA 3z//////AwDxPwAAAAAeAPg/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfk/AQAA AB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAB4A+j8BAAAAFQAAAFN5c3RlbSBB ZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAu AAAAAwD9P+QEAAADABlAAAABAAMAGkAAAAEAHgAwQAEAAAAWAAAAcm9sbC1ib3VuY2VzQGlldGYu b3JnAAAAHgAxQAEAAAAOAAAAanB2QGNpc2NvLmNvbQAAAB4AOEABAAAAAgAAAC4AAAAeADlAAQAA AAIAAAAuAAAACwApAAAAAAALACMAAAAAAAMABhBGzTfcAwAHEOUGAAADABAQAAAAAAMAERAAAAAA HgAIEAEAAABlAAAASElQSElMQU5ETVVLVUwsT05KVUwyMCwyMDEwLEFUOTo1N0FNLE1VS1VMR09Z QUxXUk9URTpISVBISUwiSU5USEVDQVNFT0ZBU1RPUklOR05FVFdPUkssUDJQUEFDS0VUU1RSQQAA AAACAX8AAQAAADEAAAA8RjFGQTNDNzEtRTg1OC00ODY3LUE1Q0QtRjM2OTNCREU4MDY3QGNpc2Nv LmNvbT4AAAAAyTE= ------_=_NextPart_001_01CB27F0.2E24F780-- ------------=_1279678968-2885-1-- From jpv@cisco.com Tue Jul 20 22:15:36 2010 Return-Path: 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 77FC33A6B33 for ; Tue, 20 Jul 2010 22:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 g7+f+xadbN7B for ; Tue, 20 Jul 2010 22:15:31 -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 F1FC93A6AFB for ; Tue, 20 Jul 2010 22:15:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOofRkxAZnwM/2dsb2JhbACfc3GkLJsOhTIEiFmCNocT Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2010 05:15:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6L5FbK8019846; Wed, 21 Jul 2010 05:15:38 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 07:15:38 +0200 Received: from [192.168.3.55] ([10.61.109.54]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 07:15:37 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Jul 2010 07:15:35 +0200 References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Jul 2010 05:15:37.0398 (UTC) FILETIME=[C1075D60:01CB2893] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 05:15:36 -0000 On Jul 20, 2010, at 6:38 PM, Philip Levis wrote: > > On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: > >> >> On Jul 20, 2010, at 9:13 AM, Jonathan Hui wrote: >> >>> Nicolas, >>> >>> On Jul 20, 2010, at 8:56 AM, Nicolas DEJEAN wrote: >>> >>>> Option A) >>>> * In section 5.2, specify an L bit ("Leaf node") in the DIS format. >>>> * In section 7.3, change the third item of the list to read "When a >>>> node receives a multicast DIS with a cleared L-bit and a Solicited >>>> Information option and when the node matches all of the >>>> predicates in >>>> the Solicited Information option." >>>> * In section 7.3, specify the algorithm to be run for responding >>>> with >>>> a unicast DIO to a multicast DIS with L-bit set. This text shall be >>>> described in a further email. This could advantageously be a >>>> temporary >>>> Trickle timer. >>>> >>>> Option B) >>>> * In section 7.3, change the third item of the list to read "When a >>>> node receives a multicast DIS with a Solicited Information option >>>> and >>>> the node matches all of the predicates in the Solicited Information >>>> option, unless a DIS flag restricts this behavior." >>>> * describe the L bit and RPL behavior in a separate I-D, together >>>> with >>>> the DIS option TLVs. >>>> >>>> Would the WG please voice their opinion on these options? >>> >>> Without a better understanding of the "response algorithm" and >>> additional information needed to drive how nodes respond, I would >>> lean to have this functionality described in a separate I-D and >>> not change the current RPL spec. For example, it's unclear to me >>> whether it should be a flag, an option, or a sub-option of an >>> updated solicited information option. Note that the rules in >>> Section 7.3 are SHOULDs, so it is OK to do something else if there >>> is a valid and well-understood reason. >> >> >> Oops. I remembered Section 7.3 wrong and it does read MUST, my >> mistake. My preference is still for Option B. I'm OK with >> including a flag to that disables the Trickle reset. But does it >> make sense to limit its use to the Solicited Information option, as >> you proposed? If you claim that the link-layer will guarantee >> collision-free unicast transmissions, then I guess it would be OK >> to allow neighbors to reply. But in either case, we might want to >> put some text in describing the dangers of the "disable Trickle >> reset" flag. > > My concern is that we're adding a specialized mechanism under the > assumptions of how the underlying link layer operates. I do not think that we do.We just define a simple mechanism that allows for reducing the number of messages when inserting a node (leaf node). This is true regardless of the link layer in use. JP. > Using this mechanism with link layers that do not have that property > could be disastrous (response implosion, hidden terminal collisions). > > That being said, it's clear we need to figure out if there's a safer > way for RPL to meet the application requirements. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Tue Jul 20 22:25:21 2010 Return-Path: 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 978CD3A6B2E for ; Tue, 20 Jul 2010 22:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 N8ceHscgskCv for ; Tue, 20 Jul 2010 22:25:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D4B4B3A68A3 for ; Tue, 20 Jul 2010 22:25:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ObRoF-0007zL-MQ; Tue, 20 Jul 2010 22:25:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Wed, 21 Jul 2010 05:25:35 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/65#comment:1 Message-ID: <064.9ed9f71d119770a7e48c17536ba94c26@tools.ietf.org> References: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <055.d2f39b0309f6a8e763a8c92f6533bbf2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #65: Move some references as normative X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 05:25:21 -0000 #65: Move some references as normative -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: References will be made normative in revision 11 or RPL -- Ticket URL: roll From jpv@cisco.com Tue Jul 20 22:57:00 2010 Return-Path: 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 4DD393A67B4 for ; Tue, 20 Jul 2010 22:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2Gsr1be5yJPI for ; Tue, 20 Jul 2010 22:56:59 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 47BA23A679F for ; Tue, 20 Jul 2010 22:56:59 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAopRkyrR7H+/2dsb2JhbACfc3GkJJsRhTIEiFmCNocT Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 05:57:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6L5vE1a026470; Wed, 21 Jul 2010 05:57:14 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 07:57:14 +0200 Received: from [192.168.3.55] ([10.61.109.54]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 07:57:13 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Jul 2010 07:57:11 +0200 References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Jul 2010 05:57:13.0701 (UTC) FILETIME=[90F0F950:01CB2899] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 05:57:00 -0000 On Jul 20, 2010, at 8:28 PM, Philip Levis wrote: > > On Jul 20, 2010, at 9:43 AM, Jonathan Hui wrote: > >> >> Phil, >> >> On Jul 20, 2010, at 9:38 AM, Philip Levis wrote: >> >>> On Jul 20, 2010, at 9:34 AM, Jonathan Hui wrote: >>> >>>> Oops. I remembered Section 7.3 wrong and it does read MUST, my >>>> mistake. My preference is still for Option B. I'm OK with >>>> including a flag to that disables the Trickle reset. But does it >>>> make sense to limit its use to the Solicited Information option, >>>> as you proposed? If you claim that the link-layer will guarantee >>>> collision-free unicast transmissions, then I guess it would be OK >>>> to allow neighbors to reply. But in either case, we might want >>>> to put some text in describing the dangers of the "disable >>>> Trickle reset" flag. >>> >>> My concern is that we're adding a specialized mechanism under the >>> assumptions of how the underlying link layer operates. Using this >>> mechanism with link layers that do not have that property could be >>> disastrous (response implosion, hidden terminal collisions). >>> >>> That being said, it's clear we need to figure out if there's a >>> safer way for RPL to meet the application requirements. >> >> I share your concerns. What I wanted to convey in my mail wasn't >> clear, but I meant to say that disabling a Trickle reset in >> response to a DIS is OK from my perspective - it's what other >> actions nodes do after that we need to think carefully about, and >> I'm arguing that those latter mechanisms go in a separate (possibly >> domain specific) draft. Or is it that you do not want any >> mechanism to avoid a Trickle reset? > > Let's be more precise: we're not really talking about disabling a > Trickle reset, we're talking about requesting an immediate response. > The transmission is independent of Trickle timers, although it could > affect suppression. > > This is fine as a mechanism: currently, unicast DIS transmissions > cause this behavior (e.g., to obtain the DODAG Configuration). My > concern is that the proposal is to allow this from a multicast > transmission. > > A protocol shouldn't allow a node to trigger immediate responses > from many nodes simultaneously, due to the MAC layer failures this > can introduce in wireless. The proposed solution is even a worst- > case scenario, where the responses are all unicast so cannot > suppress each other. The failure scenario is: I have a hundred nodes > in a box, one node sends a multicast DIS that requests immediate > unicast responses. If your link layer does not promise collision > free unicast transmissions (any CSMA scheme), you waste an enormous > amount of energy to create a lot of packet collisions. This seems to > be a mechanism that only works for certain link layers and could be > disastrous in others. Phil, I think that you go further than the proposal. The point is to allow for unicast reply of DIO and not general reset timer (could be according to a different algorithm to be determined by option B by the way ! It does not say that all nodes will immediately reply of course). JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mdurvy@cisco.com Wed Jul 21 02:22:09 2010 Return-Path: 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 D2D123A6907 for ; Wed, 21 Jul 2010 02:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 VxbuHcottACd for ; Wed, 21 Jul 2010 02:22:02 -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 E61193A67F0 for ; Wed, 21 Jul 2010 02:22:01 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2010 09:22:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6L9Lqqn012319; Wed, 21 Jul 2010 09:22:17 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 11:22:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jul 2010 11:22:14 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06A6_01CB28C6.F83ACD70" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE028C837B@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarifications on Section 16 "Manageability considerations" Thread-Index: AcsoG2OZzm7GmmwJS6603Ul9YfrdsAAmdS0A References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "JP Vasseur" X-OriginalArrivalTime: 21 Jul 2010 09:22:17.0244 (UTC) FILETIME=[366CA5C0:01CB28B6] Cc: roll WG Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Wed, 21 Jul 2010 09:22:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06A6_01CB28C6.F83ACD70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_06A7_01CB28C6.F83ACD70" ------=_NextPart_001_06A7_01CB28C6.F83ACD70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi JP, Perfect! Thanks. Just a couple of typos: - "Some of the RPL parameters are optional. The requirementS for configuration are only applicable IF the optionS are in use. - last sentence of 16.2.3 should probably be a bullet point. Also given the sentence above that you added at the beginning of the Section there is probably no need for the 'if' part of the sentence anymore. - 16.2.5 you might want to keep the DODAG preference (while removing the MOP of you already did) Best, Mathilde From: JP Vasseur [mailto:jpv@cisco.com] Sent: mardi, 20. juillet 2010 16:54 To: Mathilde Durvy (mdurvy) Cc: roll WG Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" Just had a quick discussion with Mathilde to clarify a few things. Mathilde, here is the new version. Let me know if we are in sync. Cheers. JP. ------=_NextPart_001_06A7_01CB28C6.F83ACD70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi JP,

 

Perfect! Thanks.

 

Just a couple of typos:

- “Some of the RPL parameters are optional. The = requirementS for configuration are only applicable IF the optionS are in = use.

- last sentence of 16.2.3 should probably be a bullet point. = Also given the sentence above that you added at the beginning of the Section = there is probably no need for the ‘if’ part of the sentence = anymore.

- 16.2.5 you might want to keep the DODAG preference (while removing the MOP of you already did)

 

Best,

Mathilde

 

From:= JP Vasseur [mailto:jpv@cisco.com]
Sent: mardi, 20. juillet 2010 16:54
To: Mathilde Durvy (mdurvy)
Cc: roll WG
Subject: Re: [Roll] Clarifications on Section 16 = "Manageability considerations"

 

Just had a quick discussion with Mathilde to = clarify a few things. Mathilde, here is the new version.

Let me know if we are in sync.

 

Cheers.

 

JP.

 

------=_NextPart_001_06A7_01CB28C6.F83ACD70-- ------=_NextPart_000_06A6_01CB28C6.F83ACD70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcyMTA5MjIxNFowIwYJKoZIhvcNAQkEMRYEFATs6yuXmebXVtZS PX4ryrePqsjTMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAj5IkCo1GgecY/80rgTCy6G6rFCb9kDea KLoLFRrOy9cdN2T8syGHDsLef7cvk+JGaFhthBdI/6rV29Bwu723La+juEt1i+Pg1rPiLgQtlMTS Iuq9HY8qF/ZgvPw+UgE1JCtifafqKioASu9MWi0MCjG50J7P1dTvkcpe8zic21IAAAAAAAA= ------=_NextPart_000_06A6_01CB28C6.F83ACD70-- From mdurvy@cisco.com Wed Jul 21 02:43:19 2010 Return-Path: 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 B4E713A6B83 for ; Wed, 21 Jul 2010 02:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.966 X-Spam-Level: X-Spam-Status: No, score=-9.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] 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 q8F9HWpHLEQW for ; Wed, 21 Jul 2010 02:43:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id DBA3D3A6B88 for ; Wed, 21 Jul 2010 02:43:15 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAANeRkxAaHte/2dsb2JhbACfcHGkH5sPhTIEiw8 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2010 09:43:31 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6L9hGb0010180; Wed, 21 Jul 2010 09:43:30 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 11:43:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jul 2010 11:43:23 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_06AE_01CB28C9.ECC1EA20" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE028C8396@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Soliciting WG comments on DIS for RPL Last Call Thread-Index: AcsoJDqyCpOJgy7UQjm/mPeBKdH9/gAlBd+w References: From: "Mathilde Durvy (mdurvy)" To: "Nicolas DEJEAN" , "roll WG" X-OriginalArrivalTime: 21 Jul 2010 09:43:26.0948 (UTC) FILETIME=[2B3A1A40:01CB28B9] Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 09:43:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06AE_01CB28C9.ECC1EA20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Nicolas, I think the scenario is interesting and should be addressed. I would favor Option B, to avoid modifying RPL too much at this stage. Note that you probably want to use the solicited option anyway to restrict the number of unicast DIOs that come back. Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Nicolas DEJEAN Sent: mardi, 20. juillet 2010 17:57 To: roll WG Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call Hello all, Based on our experience of having deployed many smart metering networks (totalling several million nodes), we have an issue with the way DIS and DIOs are currently handled by RPL. To solve this issue, we suggest minor modifications into the RPL core spec that only impacts the connection process of a leaf node to the LLN. As part of the everyday life of a smart metering network, every so often, a meter needs to be replaced or an extra one needs to be added. After physical installation, the technician stands by to witness the network hook-up. He/she will not leave the premises before the meter is satisfactorily connected. Every elapsed minute is an operation cost. We are talking real money. There's no way a meter will wait for a DIO to arrive by itself after some random number of hours. The meter has to solicit DIOs from yet unknown neighbor routers, and that's done by multicasting DIS'es. In our case of interest, the meter will be a leaf node, therefore its presence will not modify the network topology. Currently, RPL mandates that, in response to a multicast DIS, DIOs are multicasted and Trickle timers at the routers are reset. Firstly, resetting the Trickle timers generates much more control traffic than is needed. Neither the meter being installed nor neighbor nodes need the frequent repeats of the very same DIO (remember the topology is not changing). This is only a waste of energy at the routers and at the nodes that are the destination of the DIOs. Secondly, multicast makes the problem even worse by enlarging the audience for the DIO. Other than the meter being installed, nodes nearby do not need to receive the DIO, because they have long settled and the topology is not changing. In dense environments, the two effects combine to drastically reduce the network lifetime compared to our currently deployed, non-RPL, protocol. It is our industrial experience that this is a real and significant problem and we worked hard to solve it. Let's leverage that experience to the benefit of RPL users. Therefore, here are two possibilites for RPL. Option A) * In section 5.2, specify an L bit ("Leaf node") in the DIS format. * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a cleared L-bit and a Solicited Information option and when the node matches all of the predicates in the Solicited Information option." * In section 7.3, specify the algorithm to be run for responding with a unicast DIO to a multicast DIS with L-bit set. This text shall be described in a further email. This could advantageously be a temporary Trickle timer. Option B) * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior." * describe the L bit and RPL behavior in a separate I-D, together with the DIS option TLVs. Would the WG please voice their opinion on these options? Thanks _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_06AE_01CB28C9.ECC1EA20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDcyMTA5NDMyM1owIwYJKoZIhvcNAQkEMRYEFK7yV4zEKNeCsHlN 4DflmN4sYj0KMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAsLex6LImnfs7k+DWA9E4QrCepZY2SwwU +67k2q44fiIQQEroSN+lYFJVAellLV4xOfNHyRHC7Rn7ZD0PLhoohCrEE8bvo+v42BuOx67xq7m2 KnmwZdWxT0BWZ7yU458qtfpd4JE6s/y5Iwtvt6a+hyC21fU4mVxzqp2cb6Mk3f4AAAAAAAA= ------=_NextPart_000_06AE_01CB28C9.ECC1EA20-- From nicolas.dejean.ietf@googlemail.com Wed Jul 21 03:31:17 2010 Return-Path: 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 AEE0E3A6B9D for ; Wed, 21 Jul 2010 03:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_32=0.6] 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 QDvVrHiPapHv for ; Wed, 21 Jul 2010 03:31:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 17EF53A6845 for ; Wed, 21 Jul 2010 03:31:13 -0700 (PDT) Received: by ewy22 with SMTP id 22so2407546ewy.31 for ; Wed, 21 Jul 2010 03:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+Ojxju/GMM36J3lQ7VyvuwSjI3dEjAlZ5bfjPPFx2XU=; b=M/VSNuG5sFvJVgwXWfrXuJvDIcJxJcZ7Jlp6GrcQqmNG/cnTNDrV2IPDe1QQZYmsLa D9LB+BlymGb8i7Yl1UipnEJ5EKbM44ojD31tF3Ge/RENq/6OtwJeqd42/KeLhKfanWQ3 jcpfB2QBVY3ZbHCwFynpCbpBSJuYalMmw6ZwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uqmY8ofHWecGkIZriv7mRvkJ5wwrjAl79yjPAC3vO5OeofC8Y1FTqh2hjVDDzwSxC2 +46zjISGxv7vq4LJCMxTS5WLDG14xeiX30AH3Jmg1MZp819x6VlA5o4cnYHM6HYuD0uI iyy1srTj++LueuxASAYUNlWeM0JNR3NXlWd/4= MIME-Version: 1.0 Received: by 10.213.20.4 with SMTP id d4mr7518309ebb.94.1279708289393; Wed, 21 Jul 2010 03:31:29 -0700 (PDT) Received: by 10.213.28.80 with HTTP; Wed, 21 Jul 2010 03:31:29 -0700 (PDT) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE028C8396@XMB-AMS-103.cisco.com> References: <8A977BDC5A7B0E429B0F521E8D6F91EE028C8396@XMB-AMS-103.cisco.com> Date: Wed, 21 Jul 2010 12:31:29 +0200 Message-ID: From: Nicolas DEJEAN To: "Mathilde Durvy (mdurvy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 10:31:17 -0000 Hello Mathilde, 2010/7/21 Mathilde Durvy (mdurvy) : > Hi Nicolas, > > I think the scenario is interesting and should be addressed. > I would favor Option B, to avoid modifying RPL too much at this stage. Note > that you probably want to use the solicited option anyway to restrict the > number of unicast DIOs that come back. Yes clearly, this is the idea. Thanks for your feedback. Nicolas. > > Best, > Mathilde > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Nicolas DEJEAN > Sent: mardi, 20. juillet 2010 17:57 > To: roll WG > Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call > > Hello all, > > Based on our experience of having deployed many smart metering > networks (totalling several million nodes), we have an issue with the > way DIS and DIOs are currently handled by RPL. To solve this issue, we > suggest minor modifications into the RPL core spec that only impacts > the connection process of a leaf node to the LLN. > > As part of the everyday life of a smart metering network, every so > often, a meter needs to be replaced or an extra one needs to be added. > After physical installation, the technician stands by to witness the > network hook-up. He/she will not leave the premises before the meter > is satisfactorily connected. Every elapsed minute is an operation > cost. We are talking real money. There's no way a meter will wait for > a DIO to arrive by itself after some random number of hours. The meter > has to solicit DIOs from yet unknown neighbor routers, and that's done > by multicasting DIS'es. In our case of interest, the meter will be a > leaf node, therefore its presence will not modify the network > topology. Currently, RPL mandates that, in response to a multicast > DIS, DIOs are multicasted and Trickle timers at the routers are reset. > > Firstly, resetting the Trickle timers generates much more control > traffic than is needed. Neither the meter being installed nor neighbor > nodes need the frequent repeats of the very same DIO (remember the > topology is not changing). This is only a waste of energy at the > routers and at the nodes that are the destination of the DIOs. > > Secondly, multicast makes the problem even worse by enlarging the > audience for the DIO. Other than the meter being installed, nodes > nearby do not need to receive the DIO, because they have long settled > and the topology is not changing. > > In dense environments, the two effects combine to drastically reduce > the network lifetime compared to our currently deployed, non-RPL, > protocol. > > It is our industrial experience that this is a real and significant > problem and we worked hard to solve it. > Let's leverage that experience to the benefit of RPL users. > > Therefore, here are two possibilites for RPL. > > Option A) > * In section 5.2, specify an L bit ("Leaf node") in the DIS format. > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a cleared L-bit and a Solicited > Information option and when the node matches all of the predicates in > the Solicited Information option." > * In section 7.3, specify the algorithm to be run for responding with > a unicast DIO to a multicast DIS with L-bit set. This text shall be > described in a further email. This could advantageously be a temporary > Trickle timer. > > Option B) > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a Solicited Information option and > the node matches all of the predicates in the Solicited Information > option, unless a DIS flag restricts this behavior." > * describe the L bit and RPL behavior in a separate I-D, together with > the DIS option TLVs. > > Would the WG please voice their opinion on these options? > > Thanks > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From wintert@acm.org Wed Jul 21 06:21:26 2010 Return-Path: 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 33FEB3A68DD for ; Wed, 21 Jul 2010 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.332 X-Spam-Level: X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 kjAa4mSfBx7y for ; Wed, 21 Jul 2010 06:21:22 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id CEBA83A6784 for ; Wed, 21 Jul 2010 06:21:21 -0700 (PDT) Received: (qmail 22313 invoked from network); 21 Jul 2010 13:21:27 -0000 Received: from [10.56.17.106] (wintert@71.178.253.216 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 21 Jul 2010 06:21:27 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: a5rxazgVM1nRwaCnjEkgWXfOev28A2G8.Em0LThP_fCQzfe PL14Zlvcb4R.1eArHVMNJtuPOZxuDiuM8M2D9VF051OP9gRefPSKnIgVHaqn q.vAb7Al5ulLjHypKwOT.bdVopvcPajLDqR3v1V4FsmMd4_ntA5JeJP21G2C LNjEG86mG1y28P8KwVBHbhq2RDxVpt2Vn0QPKrT8meZoourjmAwEFSU65raE 15M_OiBD3zjQzWxf71ublkeXCjh3P40VoCL1E49trXzyXsVfzmD8HPGcKGez Z_FB9CVYHDYpHLYtwdRf9yVM9nEYH1pOoW8t5a2jqXZZiI4LEyhEA X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C46F456.2010908@acm.org> Date: Wed, 21 Jul 2010 09:21:26 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <8A977BDC5A7B0E429B0F521E8D6F91EE028C8396@XMB-AMS-103.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 13:21:26 -0000 I also support Option B. -Tim On 07/21/2010 06:31 AM, Nicolas DEJEAN wrote: > Hello Mathilde, > > 2010/7/21 Mathilde Durvy (mdurvy): >> Hi Nicolas, >> >> I think the scenario is interesting and should be addressed. >> I would favor Option B, to avoid modifying RPL too much at this stage. Note >> that you probably want to use the solicited option anyway to restrict the >> number of unicast DIOs that come back. > > Yes clearly, this is the idea. > > Thanks for your feedback. > > Nicolas. > >> >> Best, >> Mathilde >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >> Nicolas DEJEAN >> Sent: mardi, 20. juillet 2010 17:57 >> To: roll WG >> Subject: [Roll] Soliciting WG comments on DIS for RPL Last Call >> >> Hello all, >> >> Based on our experience of having deployed many smart metering >> networks (totalling several million nodes), we have an issue with the >> way DIS and DIOs are currently handled by RPL. To solve this issue, we >> suggest minor modifications into the RPL core spec that only impacts >> the connection process of a leaf node to the LLN. >> >> As part of the everyday life of a smart metering network, every so >> often, a meter needs to be replaced or an extra one needs to be added. >> After physical installation, the technician stands by to witness the >> network hook-up. He/she will not leave the premises before the meter >> is satisfactorily connected. Every elapsed minute is an operation >> cost. We are talking real money. There's no way a meter will wait for >> a DIO to arrive by itself after some random number of hours. The meter >> has to solicit DIOs from yet unknown neighbor routers, and that's done >> by multicasting DIS'es. In our case of interest, the meter will be a >> leaf node, therefore its presence will not modify the network >> topology. Currently, RPL mandates that, in response to a multicast >> DIS, DIOs are multicasted and Trickle timers at the routers are reset. >> >> Firstly, resetting the Trickle timers generates much more control >> traffic than is needed. Neither the meter being installed nor neighbor >> nodes need the frequent repeats of the very same DIO (remember the >> topology is not changing). This is only a waste of energy at the >> routers and at the nodes that are the destination of the DIOs. >> >> Secondly, multicast makes the problem even worse by enlarging the >> audience for the DIO. Other than the meter being installed, nodes >> nearby do not need to receive the DIO, because they have long settled >> and the topology is not changing. >> >> In dense environments, the two effects combine to drastically reduce >> the network lifetime compared to our currently deployed, non-RPL, >> protocol. >> >> It is our industrial experience that this is a real and significant >> problem and we worked hard to solve it. >> Let's leverage that experience to the benefit of RPL users. >> >> Therefore, here are two possibilites for RPL. >> >> Option A) >> * In section 5.2, specify an L bit ("Leaf node") in the DIS format. >> * In section 7.3, change the third item of the list to read "When a >> node receives a multicast DIS with a cleared L-bit and a Solicited >> Information option and when the node matches all of the predicates in >> the Solicited Information option." >> * In section 7.3, specify the algorithm to be run for responding with >> a unicast DIO to a multicast DIS with L-bit set. This text shall be >> described in a further email. This could advantageously be a temporary >> Trickle timer. >> >> Option B) >> * In section 7.3, change the third item of the list to read "When a >> node receives a multicast DIS with a Solicited Information option and >> the node matches all of the predicates in the Solicited Information >> option, unless a DIS flag restricts this behavior." >> * describe the L bit and RPL behavior in a separate I-D, together with >> the DIS option TLVs. >> >> Would the WG please voice their opinion on these options? >> >> Thanks >> _______________________________________________ >> 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 wintert@acm.org Wed Jul 21 06:22:47 2010 Return-Path: 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 A161F3A6846 for ; Wed, 21 Jul 2010 06:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LtCXtnvU95tw for ; Wed, 21 Jul 2010 06:22:46 -0700 (PDT) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id 9EBB93A6A09 for ; Wed, 21 Jul 2010 06:22:45 -0700 (PDT) Received: (qmail 27561 invoked from network); 21 Jul 2010 13:22:54 -0000 Received: from [10.56.17.106] (wintert@71.178.253.216 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 21 Jul 2010 06:22:54 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 1sw8nXQVM1mKDOM.I9bsFLN7.B4rYTybvhhuytgLDTuX_5. WdXSNGz6K7RG0MF6Raekt6gK_03tIJcB3tEt8QEGqYls6lGv0icGnl5UXMom dKY9IrZWnPJq1vsz96s8vE3CM1hohHg7QWDPB9waaFptuEqe1e1k0sShzPOE CSFUAJZdzIwhwWBIRV8jRWlaFKgx37weNGJsI15wxqzD_UcKqJO0KHVuVDIF SB61E0f8Y7c5NS6teiqZPJx.IjvfguJoh3QLutmhBS4kPgff0HtNifI1MJwH YXtcrz4NABjP7rBzbUuhvCrXhZmmhx38Cm1pCcuhODZW.Ejr78lpd X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C46F4AD.9010706@acm.org> Date: Wed, 21 Jul 2010 09:22:53 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <3a9969c91b0b37f5c4c64305397a14aa@mail.gmail.com> In-Reply-To: <3a9969c91b0b37f5c4c64305397a14aa@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] RPLInstanceID term clarification 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: , X-List-Received-Date: Wed, 21 Jul 2010 13:22:47 -0000 We will update this for -11: RPLInstanceID: A unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function. -Tim On 07/20/2010 07:46 AM, Yoav Ben-Yehezkel wrote: > Hi, > > Question on the following term: > > “RPLInstanceID: A unique identifier within a network. Two DODAGs with > the same RPLInstanceID share the same Objective Function.“ > > Is it really limited to two DODAGs? Suggest to remove the word “Two” if not. > > Regards, > > Yoav > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Wed Jul 21 07:21:45 2010 Return-Path: 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 EF0EE3A6826 for ; Wed, 21 Jul 2010 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qDYBp2FRtFj2 for ; Wed, 21 Jul 2010 07:21:43 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 34E3B3A6846 for ; Wed, 21 Jul 2010 07:21:43 -0700 (PDT) Received: from source ([209.85.216.180]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTEcChUQbEs/9qwwveap5QNCcoM15WzsT@postini.com; Wed, 21 Jul 2010 07:22:00 PDT Received: by qyk34 with SMTP id 34so3393595qyk.18 for ; Wed, 21 Jul 2010 07:21:57 -0700 (PDT) Received: by 10.224.34.230 with SMTP id m38mr141349qad.368.1279722117145; Wed, 21 Jul 2010 07:21:57 -0700 (PDT) From: Yoav Ben-Yehezkel References: <3a9969c91b0b37f5c4c64305397a14aa@mail.gmail.com> <4C46F4AD.9010706@acm.org> In-Reply-To: <4C46F4AD.9010706@acm.org> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acso19xXMeBEvLY+RrybDqTe8MQqugABsJXA Date: Wed, 21 Jul 2010 17:21:56 +0300 Message-ID: <3d6c4701816ef5a44eee80b7027880ab@mail.gmail.com> To: Tim Winter , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] RPLInstanceID term clarification 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: , X-List-Received-Date: Wed, 21 Jul 2010 14:21:45 -0000 Thanks Tim! I've another clarification on the scope RPL of nodes within a network with multiple RPL Instances. I was asked whether RPL supports a scenario where an RPL node "belongs" to different DODAGs in different RPL instances. The limitation I am aware of is that an RPL node cannot belong to different DODAGs in the same RPL Instance, but there was no text about what happens when there are multiple RPL instances. My implicit understanding is that no, but I'd like to make sure. Would you consider adding this clarification explicitly? Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: Wednesday, July 21, 2010 4:23 PM To: roll@ietf.org Subject: Re: [Roll] RPLInstanceID term clarification We will update this for -11: RPLInstanceID: A unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function. -Tim On 07/20/2010 07:46 AM, Yoav Ben-Yehezkel wrote: > Hi, > > Question on the following term: > > "RPLInstanceID: A unique identifier within a network. Two DODAGs with > the same RPLInstanceID share the same Objective Function." > > Is it really limited to two DODAGs? Suggest to remove the word "Two" if not. > > Regards, > > Yoav > > > > _______________________________________________ > 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 pal@cs.stanford.edu Wed Jul 21 08:56:18 2010 Return-Path: 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 19E193A6866 for ; Wed, 21 Jul 2010 08:56:18 -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 SYKSSP553rw7 for ; Wed, 21 Jul 2010 08:56:14 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 3DDC83A6856 for ; Wed, 21 Jul 2010 08:56:14 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Obbeo-0001Kb-1F; Wed, 21 Jul 2010 08:56:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 21 Jul 2010 08:56:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com> <12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com> <5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 15:56:18 -0000 On Jul 20, 2010, at 10:15 PM, JP Vasseur wrote: >=20 > On Jul 20, 2010, at 6:38 PM, Philip Levis wrote: >>>>>=20 >>>>>=20 >>=20 >> My concern is that we're adding a specialized mechanism under the = assumptions of how the underlying link layer operates. >=20 > I do not think that we do.We just define a simple mechanism that = allows for reducing the number of messages when inserting a node > (leaf node). This is true regardless of the link layer in use. >=20 > JP. JP -- the scheme assumes that unicast transmissions are collision-free. = Otherwise a set of correlated responses lead to a rash of collisions and = terrible network discovery: it doesn't work. This is a well known = problem in wireless[1,2], and one of the major motivations behind = Trickle. Phil [1] Ni et al. "The broadcast storm problem in a mobile ad hoc network" = http://portal.acm.org/citation.cfm?id=3D313525 [2] Ganesan et al. "Complex Behavior at Scale: An Experimental Study of = Low-Power Wireless Sensor Networks (2002)" = http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.19.770 From prvs=811ed6fc2=mukul@uwm.edu Wed Jul 21 11:35:31 2010 Return-Path: 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 CB7B63A68A3 for ; Wed, 21 Jul 2010 11:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=-0.973, 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 OStE+glzH2eM for ; Wed, 21 Jul 2010 11:35:26 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 21D1B3A6AFC for ; Wed, 21 Jul 2010 11:35:22 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 21 Jul 2010 13:35:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C47472B3F02; Wed, 21 Jul 2010 13:35:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YNJFIspg9dk; Wed, 21 Jul 2010 13:35:08 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 9E99A2B3EF6; Wed, 21 Jul 2010 13:35:08 -0500 (CDT) Date: Wed, 21 Jul 2010 13:35:22 -0500 (CDT) From: Mukul Goyal To: Emmanuel Baccelli Message-ID: <1541747918.183208.1279737322705.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <288483978.182831.1279736962596.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.6_GA_2330.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.6_GA_2330.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: charliep , roll Subject: [Roll] constraints for temporary dag formation and those for route discovery 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: , X-List-Received-Date: Wed, 21 Jul 2010 18:35:32 -0000 Hi all Here is the text from p2p draft regarding the max rank field of the route discovery option: Max Rank: A 7-bit unsigned integer that indicates the maximum rank allowed in the temporary DAG advertised by the DIO message. This upper limit on the DAG rank serves as the "distance" referred to in Section 4 and provides a control over how far the Route Discovery option contained in the DODAG Configuration option in the DIO message may travel. A router MUST NOT join the temporary DAG if its rank in the DAG will exceed this limit. Later versions of this draft will map the 128 value space available in this field to 16-bit long limits on the DAG rank. So, this is a 7 bit field imposing limits on 16-bit long rank value. There are two ways to use this field: 1) the 7 bit value is the actual limit on the rank in temporary DAG 2) as mentioned above, 7 bit field gives 128 values that can be used as limits on the rank. Now, we will have to specify what these limits are. In my view, a much cleaner design will be to eliminate this field altogether. Any limits on how much the temporary DAG can grow can be imposed as metric-specific "constraints" inside the metric container. For example, we can say that temporay DAG formation must satisfy the constraint "hop-count <= 5". Also, note that the discovered routes automatically satisfy the constraints for temporary DAG formation. So, we will have two sets of constraints: first set that both temporary DAG formation and route selection must satisfy and an additional set of constraints (in a second metric container immediately floowing the route discovery option) that the route selection must additionally satisfy. This change will also eliminate the problem JP pointed out that, in the current design, the criteria for temporary DAG formation and route discovery may be antagonistic to each other. Comments? Thanks Mukul From jpv@cisco.com Wed Jul 21 11:42:51 2010 Return-Path: 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 674913A6A15 for ; Wed, 21 Jul 2010 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 Yi7qhxGCl6Ua for ; Wed, 21 Jul 2010 11:42:50 -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 F0F533A67D4 for ; Wed, 21 Jul 2010 11:42:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAJPcRkxAZnwN/2dsb2JhbACBRJ4vcac9mxGFMgSIWYI2 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2010 18:43:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6LIh8Qo020482 for ; Wed, 21 Jul 2010 18:43:09 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 20:43:05 +0200 Received: from ams-jvasseur-8715.cisco.com ([10.55.201.134]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 20:43:04 +0200 Message-Id: <46A4F265-9D03-45FB-BCC8-A16B3A8277BE@cisco.com> From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE028C837B@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-134-782751731 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Jul 2010 20:41:02 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE0279CB07@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282F0A6@XMB-AMS-103.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE028C837B@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Jul 2010 18:43:04.0855 (UTC) FILETIME=[8DF6A270:01CB2904] Cc: roll WG Subject: Re: [Roll] Clarifications on Section 16 "Manageability considerations" 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: , X-List-Received-Date: Wed, 21 Jul 2010 18:42:51 -0000 --Apple-Mail-134-782751731 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Typos fixed. Great, I'll close the ticket then. Thanks for your comments. JP. On Jul 21, 2010, at 11:22 AM, Mathilde Durvy (mdurvy) wrote: > Hi JP, > > Perfect! Thanks. > > Just a couple of typos: > - =93Some of the RPL parameters are optional. The requirementS for =20 > configuration are only applicable IF the optionS are in use. > - last sentence of 16.2.3 should probably be a bullet point. Also =20 > given the sentence above that you added at the beginning of the =20 > Section there is probably no need for the =91if=92 part of the = sentence =20 > anymore. > - 16.2.5 you might want to keep the DODAG preference (while removing =20= > the MOP of you already did) > > Best, > Mathilde > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: mardi, 20. juillet 2010 16:54 > To: Mathilde Durvy (mdurvy) > Cc: roll WG > Subject: Re: [Roll] Clarifications on Section 16 "Manageability =20 > considerations" > > Just had a quick discussion with Mathilde to clarify a few things. =20 > Mathilde, here is the new version. > Let me know if we are in sync. > > Cheers. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-134-782751731 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Typos fixed. Great, I'll close = the ticket then.

Thanks for your = comments.

JP.

On Jul = 21, 2010, at 11:22 AM, Mathilde Durvy (mdurvy) wrote:

Hi JP,
 
Just a couple of = typos:
- =93Some of the = RPL parameters are optional. The requirementS for configuration are only = applicable IF the optionS are in use.
- last sentence of 16.2.3 should probably be a bullet = point. Also given the sentence above that you added at the beginning of = the Section there is probably no need for the =91if=92 part of the = sentence anymore.
- 16.2.5 you might = want to keep the DODAG preference (while removing the MOP of you already = did)
From: JP Vasseur [mailto:jpv@cisco.com] 
Sent: mardi, 20. juillet 2010 = 16:54
To: Mathilde Durvy = (mdurvy)
Cc: roll = WG
Subject: Re: [Roll] Clarifications = on Section 16 "Manageability = considerations"
 
Just had a quick = discussion with Mathilde to clarify a few things. Mathilde, here is the = new version.
Let me know if we are in = sync.
X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 21 Jul 2010 18:45:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/63#comment:1 Message-ID: <064.a2ae4363cbf327cb673818a00bc5fbec@tools.ietf.org> References: <055.2d8835ae40d7ed72be48f522fd248099@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <055.2d8835ae40d7ed72be48f522fd248099@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #63: Clarification and Modification in the Manageability Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 18:45:13 -0000 #63: Clarification and Modification in the Manageability Section -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed -- Ticket URL: roll From prvs=81145e6a8=Roger.Alexander@cooperindustries.com Wed Jul 21 15:10:18 2010 Return-Path: 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 DFEA73A68F0 for ; Wed, 21 Jul 2010 15:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 a-H-5l3Efy6O for ; Wed, 21 Jul 2010 15:10:15 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by core3.amsl.com (Postfix) with ESMTP id 59F613A6863 for ; Wed, 21 Jul 2010 15:10:14 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,240,1278302400"; d="scan'208";a="61963442" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 21 Jul 2010 18:10:30 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 18:10:29 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 18:09:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9BB070DB2D281946859EA89837931EEE19CABC@EVS4.nam.ci.root> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02575117@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Issue 59 on Transit information option Thread-Index: AcskPBx3Ans5PGoCSMOo8kG032G7jgAtQ4EQAJgDZsAAIhCZMABFO1Tw References: <6A2A459175DABE4BB11DE2026AA50A5D024CDC57@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE0282E94A@XMB-AMS-103.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02574665@XMB-AMS-107.cisco.com><4C3F395D.1050409@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D02574AC7@XMB-AMS-107.cisco.com> <9BB070DB2D281946859EA89837931EEE19C8B1@EVS4.nam.ci.root> <6A2A459175DABE4BB11DE2026AA50A5D02575117@XMB-AMS-107.cisco.com> From: "Alexander, Roger" To: "Pascal Thubert (pthubert)" , "Tim Winter" , X-OriginalArrivalTime: 21 Jul 2010 22:10:29.0594 (UTC) FILETIME=[879B1BA0:01CB2921] Subject: Re: [Roll] Issue 59 on Transit information option 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: , X-List-Received-Date: Wed, 21 Jul 2010 22:10:19 -0000 Hi Pascal, I agree that the association of paired path control bits with roughly equivalent parents will achieve the ability for load balancing even though there will be occasions where the lack of rough equivalence among DAO Parents will limit the use of diverse paths. In essence the source node (that is, the node owner of the given Prefix) will dictate the path choices by the initial determination of the relative equivalence of DAO Parents. If equivalent DAO Parents exist at the source node, the potential will be established to have equal path choices potentially through the network and at the root. If the source node does not have equivalent DAO Parents then different bits are set within the path control field (some bit(s) within the bit pairs not used) and load balancing is no longer an option across the network or at the DODAG root.=20 Yes, I agree, other than halving the preference to 4 levels, which should not be much of a concern, the overall fan out control is maintained together with an option for equal path routing when equivalent DAO Parent links exist at the source node. Works for me. Roger > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, July 20, 2010 3:08 AM > To: Alexander, Roger; Tim Winter; roll@ietf.org > Subject: RE: [Roll] Issue 59 on Transit information option >=20 > Hi Roger: >=20 > On board with the latter. We can't have much precision here. But I'd > like to be able to make a difference between a strict order an loose > equivalence. If parent A and parent B give me an approximately equal > metric set downwards, then I do not necessarily want to impose an > order. > Do you see an issue with the idea that says that the path control bits > are paired for roughly equivalent parents? The consequence is probably > that we'd have to skip (not use) some bits when there is not a second > equivalent parent, but I fail to see that as a problem. I do not expect > a real case to fan out more than 3 or 4 parents anyway. >=20 > Do I miss something? >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: Alexander, Roger [mailto:Roger.Alexander@cooperindustries.com] > > Sent: Tuesday, July 20, 2010 12:25 AM > > To: Pascal Thubert (pthubert); Tim Winter; roll@ietf.org > > Subject: RE: [Roll] Issue 59 on Transit information option > > > > I think equal cost multipath is a worthwhile objective. However, > there > is a > > question as to what extent must equal-cost be enforced? It may > require > at each > > hop that equal-cost be enforced by ensuring that DAOs of 'equal' > preference > > always be sent to DAO Parents that are of equal rank. > > As a result, to ensure that paths are indeed equal cost, a node may > be > forced to > > send two DAOs to the same DAO Parent, even where multiple DAO Parents > > exist, if none of alternative DAO Parents are of equal rank to the > selected DAO > > Parent. The net effect could be to reduce path diversity. > Alternatively, there > > can be less precision in the enforcement of equal-cost with the > corresponding > > softness in path preference extending also to the preferred path. > > > > Roger > > > > > -----Original Message----- > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf > > Of > > > Pascal Thubert (pthubert) > > > Sent: Friday, July 16, 2010 11:11 AM > > > To: Tim Winter; roll@ietf.org > > > Subject: Re: [Roll] Issue 59 on Transit information option > > > > > > > > > Apart from the clarification, I'd really like to enable Equal Cost > > > Multipath as Mathilde suggested. > > > Could we say that 2 consecutive bits 0-1, 2-3, 4-5, and 6-7 > represent > > > paths of equal preference? That leaves us 4 degrees of preference > > which > > > is probably enough. > > > Ideas? > > > > > > > > > Pascal > > > > > > > > > > -----Original Message----- > > > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf > > > Of Tim > > > > Winter > > > > Sent: Thursday, July 15, 2010 6:38 PM > > > > To: roll@ietf.org > > > > Subject: Re: [Roll] Issue 59 on Transit information option > > > > > > > > > > > > > > > > On 07/15/2010 11:06 AM, Pascal Thubert (pthubert) wrote: > > > > > Ho! I think the confusion is that not all the parents are > > > necessarily > > > > > DAO parents. The DAO parents are the subset of parents to which > > DAO > > > > > are sent (in storing) or about whom DAO are sent (in non > storing). > > > So > > > > > in your example there would be only one. But the sentence can > be > > > > > improved by saying that all DAOs sent at the same time are sent > > > with > > > > > the same sequence in order to build multiple paths. > > > > > > > > Yes, and it should also be clarified that if you have more DAO > > > Parents > > > than you > > > > can allocate Path Control bits for a given Target, then some of > > those > > > Parents > > > > will be left out of getting a DAO for that Target. > > > > > > > > -Tim > > > > > > > > > > > > > > > > > > > > > > Pascal > > > > > > > > > > *From:* Mathilde Durvy (mdurvy) > > > > > *Sent**:* Thursday, July 15, 2010 2:43 PM > > > > > *To:* Pascal Thubert (pthubert); 'JP Vasseur' > > > > > *Cc:* 'roll@ietf.org' > > > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > > > > > Hi Pascal, > > > > > > > > > > To answer your question: > > > > > > > > > > - It seems to me that the path control usage is incompatible > with > > > the > > > > > sentence "If a node sends a DAO to one DAO parent, it MUST send > a > > > DAO > > > > > with the same DAOSequence to all other DAO parents". No? > > > > > > > > > > */[Pascal] The sequence that we are talking about now is > probably > > > the > > > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > > > > > My point was not so much about the "sequence". What I meant is > > that > > > if > > > > > the path control has 1 bit set and you have 2 parents, you will > > > send > > > a > > > > > DAO to one parent without sending "to all other parents" no? > > > > > > > > > > Best, > > > > > > > > > > Mathilde > > > > > > > > > > */ /* > > > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > > *Sent:* mardi, 13. juillet 2010 14:10 > > > > > *To:* Mathilde Durvy (mdurvy); JP Vasseur > > > > > *Cc:* roll@ietf.org > > > > > *Subject:* RE: [Roll] Issue 59 on Transit information option > > > > > > > > > > Hi Mathilde > > > > > > > > > > Thanks for your great help; I hope more people will follow your > > > > > example so we can deeply clean up the spec during the round. > > please > > > find > > > > below: > > > > > > > > > > Thanks again for your reply. What you say makes sense although > I > > > still > > > > > think that the separation of the fields between the target and > > > transit > > > > > options is somewhat arbitrary J However this is not a major > issue > > > and > > > > > maybe at this point it's more important to clarify the specs > with > > > > > respect to the meaning / usage of the path sequence, control, > and > > > lifetime. > > > > > > > > > > */[Pascal] Yes; at the end of the day the path control really > had > > > to > > > > > be in the transit with the parent. Leaving the target without > any > > > bit > > > > > allows us to add more headers that would also qualify that > target > > > and > > > > > thus factorise./* > > > > > > > > > > - In storing mode, the path control is used to limit the DAO > > > fan-out. > > > > > It can also be used to set a preference between routes with the > > > > > limitation that it cannot specify two routes which are equally > > > > > preferred (since path control bits sent to different parents > have > > > to > > > be > > > > disjoint). > > > > > > > > > > */[Pascal] We have to see that. ecmp should be acceptable. We > have > > > an > > > > > active thread on path control, lets deal with that there./* > > > > > > > > > > - It seems to me that the path control usage is incompatible > with > > > the > > > > > sentence "If a node sends a DAO to one DAO parent, it MUST send > a > > > DAO > > > > > with the same DAOSequence to all other DAO parents". No? > > > > > > > > > > */[Pascal] The sequence that we are talking about now is > probably > > > the > > > > > path sequence, right? Can you please elaborate on the issue?/* > > > > > > > > > > - In the non storing mode, the path control is not used to > limit > > > the > > > > > DAO fan-out as nodes send DAOs to only one of their DAO > parents. > I > > > > > guess it can be used as a preference by the root when it > computes > > > the source > > > > routes. > > > > > > > > > > */[Pascal] Yes/* > > > > > > > > > > - How is the path sequence processed? Given that we have > already > a > > > DAO > > > > > sequence is it possible to receive a stale path sequence? Isn't > it > > > > > redundant? > > > > > > > > > > */[Pascal] I expect not. But the node may have a stale state > from > > > that > > > > > needs to be deprecated. By deprecated I mean that the router > > should > > > > > stop forwarding through a node child that has last presented > path > > > > > sequence 21 as soon as another child presents sequence 22 or > more > > > for a > > > > same target. > > > > > This indicates that in a DAG, a new path sequence should > rapidly > > > cause > > > > > a DAO. In a tree, that is less urgent./* > > > > > > > > > > - What does the lifetime represent concretely? Is it a measure > of > > > the > > > > > lifetime of the link between the target and the transit? > > > > > > > > > > */[Pascal] the lifetime is important for 2 things at least:/* > > > > > > > > > > - Flush. A lifetime of 0 is a route flush. That is how we do > > > no-path. > > > > > > > > > > - Seq number validation. The path lifetime covers the path > > sequence > > > so > > > > > that in normal operations, the path sequence should not be > > > incremented > > > > > by 16 during a lifetime, so we should never see path sequence > > > numbers > > > > > that are out of sync by more than 16. > > > > > > > > > > It's a lot of questions, but I hope it will help make the DAO > part > > > > > clearer to everybody! > > > > > > > > > > */[Pascal] including the editors since the doc belongs to the > > > group./* > > > > > > > > > > Best, > > > > > > > > > > Mathilde > > > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > > *Sent:* mercredi, 7. juillet 2010 09:22 > > > > > *To:* Mathilde Durvy (mdurvy); 'ROLL WG' > > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > > > Hi Mathilde, > > > > > > > > > > 1) In storing mode, the transit information "parent address" is > > not > > > > > used > > > > > > > > > > You're correct on that with the current spec. > > > > > > > > > > I'm pointing out that in some cases we are missing the info for > > the > > > > > tunnel endpoint and that it might become handy to indicate a > RPL > > > > > router to which a target host is attached. > > > > > > > > > > 2) Hence the pattern would be (Target+) for storing and > > > > > (Target+,Transit+)+ for non-storing. > > > > > > > > > > We want to factorise: in non-storing mode, the target can have > > > > > multiple parents each one with a different path control. > > > > > > > > > > In storing mode, a router with multiple interfaces can place > > > multiple > > > > > targets for all its addresses and then only one transit info > that > > > is > > > > > common to them all. > > > > > > > > > > Pascal > > > > > > > > > > *From:* Mathilde Durvy (mdurvy) > > > > > *Sent:* Tuesday, July 06, 2010 4:47 PM > > > > > *To:* Pascal Thubert (pthubert); 'ROLL WG' > > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > > > Hi Pascal, > > > > > > > > > > My point is a bit different. > > > > > > > > > > In storing mode, the transit information "parent address" is > not > > > used. > > > > > The only fields that are relevant in the transit information > are > > > the > > > > > path control, sequence, and lifetime, which actually relate to > the > > > > > target prefix. So why not put these fields in the target option > > and > > > > > use only the transit option when we are in non-storing mode and > > > hence > > > > > need to specify a parent address? > > > > > > > > > > Hence the pattern would be (Target+) for storing and > > > > > (Target+,Transit+)+ for non-storing. > > > > > > > > > > Does this make sense? > > > > > > > > > > Best, > > > > > > > > > > Mathilde > > > > > > > > > > *From:* Pascal Thubert (pthubert) > > > > > *Sent:* mardi, 6. juillet 2010 15:44 > > > > > *To:* Mathilde Durvy (mdurvy); ROLL WG > > > > > *Subject:* RE: [Roll] FW: Transit information option > > > > > > > > > > Hi Mathilde: > > > > > > > > > > Pls note that the target identifies the final destination and > the > > > > > transit tells you about how you get there. So you can factorize > > > > > optimally depending on what you are doing. > > > > > > > > > > We have issue 55 that should cover your proposed change. AS > Phil > > > > > pointed out, The pattern is really (Target+, Transit+)+. > > > > > > > > > > I tend to think that the parent is needed in storing mode to > > > indicate > > > > > the tunnel end point for targets outside the RPL network, like > the > > > > > proverbial dumb host attached to a RPL router. > > > > > > > > > > What do you think? > > > > > > > > > > Pascal > > > > > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] > *On > > > > > Behalf Of *Mathilde Durvy (mdurvy) > > > > > *Sent:* Tuesday, July 06, 2010 3:25 PM > > > > > *To:* ROLL WG > > > > > *Subject:* [Roll] FW: Transit information option > > > > > > > > > > Hi All, > > > > > > > > > > I didn't see these comments addressed in the new draft. Any > > reason? > > > > > > > > > > For point 2, I would go even further and propose to put the > path > > > > > sequence, control, and lifetime fields in the Target option and > > > keep > > > > > only the parent address field in the Transit option. > > > > > > > > > > Let me add that the sentence "In a DIO, the RPL Target Option > > > > > identifies a resource that the root is trying to reach" should > be > > > > > removed if I believe the list of options allowed for DIO. > > > > > > > > > > Best, > > > > > > > > > > Mathilde > > > > > > > > > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] > *On > > > > > Behalf Of *Mathilde Durvy (mdurvy) > > > > > *Sent:* vendredi, 18. juin 2010 11:09 > > > > > *To:* Philip Levis > > > > > *Cc:* roll@ietf.org > > > > > *Subject:* Re: [Roll] Transit information option > > > > > > > > > > Hi All, > > > > > > > > > > I just looked at the updated draft and most of the comments > below > > > have > > > > > been addresses / clarified. Just a few rather minor points: > > > > > > > > > > - Section 5.7.7. RPL Target. Based on the discussion below I > would > > > > > change "A set of one or more Transit Information options MAY > > > directly > > > > > follow the Target option in a DAO message" to "a RPL Target > Option > > > in > > > > > a unicast DAO MUST be followed by a set of one or more Transit > > > > > Information Option ". > > > > > > > > > > - If the Path-Sequence / Control fields are indeed used both in > > > > > storing (where I have doubts they are really needed) and non- > > > storing > > > > > mode, why not put them in the target option rather than in the > > > transit option. > > > > > This way we could maybe only use only the target option in > storing > > > > > mode and the target+transit option in non-storing mode. This > would > > > > > have the additional benefit of making the parent address > mandatory > > > in > > > > > the transit information option and thus avoid a variable length > > > option. > > > > > > > > > > Best, > > > > > > > > > > Mathilde > > > > > > > > > > *From:* Philip Levis [mailto:pal@cs.stanford.edu] > > > > > *Sent:* vendredi, 11. juin 2010 18:10 > > > > > *To:* Mathilde Durvy (mdurvy) > > > > > *Cc:* roll@ietf.org > > > > > *Subject:* Re: [Roll] Transit information option > > > > > > > > > > On Jun 11, 2010, at 7:26 AM, Mathilde Durvy (mdurvy) wrote: > > > > > > > > > > Hi Phil, > > > > > > > > > > Thanks a lot for your answer. Here are my comments: > > > > > > > > > > A few items that might be worth clarifying in version 09: > > > > > > > > > > - "Transit Information options MAY directly follow the Target > > > option" > > > > > Is it really a MAY? If not included it means the path sequence > / > > > > > control / lifetime are not specified (which seems to contradict > > > section > > > > 7.1.4.2). > > > > > > > > > > In non-storing mode, it is definitely a MUST. Storing mode > seems > > > like > > > > > it is a MUST as well... > > > > > > > > > > I think we all agree. > > > > > > > > > > - "A non-storing node that has more than one DAO parent MAY > > include > > > a > > > > > Transit Information option for each DAO parent as part of the > > > > > non-storing Destination Advertisement operation." Why would a > node > > > do > > > > > that? If a node is sending a DAO for a specific target to e.g. > 2 > > > DAO > > > > > parents (A and B) shouldn't he send one DAO with transit > > > information > > > A > > > > > (i.e. parent address =3D A) to DAO parent A and another DAO = with > > > transit > > > > > information B to DAO parent B? Otherwise how this would work > over > > > > > multiple hop? Maybe an example of DAO would help. > > > > > > > > > > - In section 7.1.5 point 2, I assume the node should add a > transit > > > > > information with its parent before passing the content of the > > > received > > > > > DAO. Also do the operation specified on the path control field > in > > > the > > > > > previous section for storing node also apply in the non-storing > > > case? > > > > > > > > > > These are good questions. Currently the draft is a bit unclear > on > > > > > whether > > > > > > > > > > 1) a DAO's transit option contains the full source route when > it > > > > > arrives at the DODAG Root, or > > > > > > > > > > 2) the DODAG Root receives just the last downward hops of each > > > node, > > > > > and stitches together source routes with this information. > > > > > > > > > > 1) seems like a much better idea to me. Note that if it's 2), > then > > > in > > > > > non-storing mode node needs to send a DAO to just one DAO > parent, > > > and > > > > > this DAO can contain the full set of last-hops. What are your > > > thoughts? > > > > > > > > > > Indeed, I think the current draft is a bit unclear. My > > > interpretation > > > > > when reading was 1 (probably due mostly to the history of the > > > draft). > > > > > Now from your comments I understand what the draft is > proposing, > > > > > namely 2. Thanks for explaining. > > > > > > > > > > What triggered this change? > > > > > > > > > > It seems to me that if proper aggregation of the routes is > > > performed > > > > > (in particular if in the record route case you can avoid > > > transmitting > > > > > routes which are sub-routes of others) the two schemes could > > > actually > > > > > be quite similar in terms of overhead. This would need to be > > > confirmed > > > > > by a careful study as it could depend quite on bit on the > > topology. > > > > > What is quite clear is that 2 requires more processing power > than > > 1 > > > as > > > > > it needs to reassemble routes from the received information. > > > > > > > > > > Also concerning your last comment, I agree. The DAO produced > will > > > be > > > > > slightly larger but we send only one DAO instead of one DAO per > > DAO > > > > > parent. I think if we do that we might not really need the path > > > > > control field, correct? > > > > > > > > > > -09 has a rewrite of the Downward Routes section that should > make > > > all > > > > > of this much clearer. The answer is 2), for reasons Richard > > brought > > > up > > > > > a few months ago. In particular, if you use 1), then when a > node > > > > > changes its parent set it entire sub-DODAG must resend DAOs. > This > > > is > > > a > > > > > significant cost. If you use 2), then only that node needs to > send > > > a > > > > > new DAO. > > > > > > > > > > - Has the advantage of having multiple DAO parents been > assessed > > > with > > > > > respect to the added complexity? One could argue that since we > > take > > > so > > > > > much care in selecting a preferred this should be a good enough > > > > > choice... Similar to Phil I'm getting worried about the > increased > > > complexity. > > > > > > > > > > But note that in upward routes, there's a parent set. The > concern > > > is > > > > > that the vagaries and unreliability of wireless links call for > > > > > supporting some degree of path diversity. Most protocols today > > > > > maintain multiple candidate next hops for this exact reason. > > > Because > > > > > downward routes start at the endpoints, there needs to be some > way > > > to > > > > > establish multiple routes. Otherwise, when one link breaks and > you > > > > > have to issue a trigger to the entire sub-DODAG. > > > > > > > > > > I understand how this would work in the storing case but in the > > > > > non-storing case how would you know at the root that the path > > > failed? > > > > > > > > > > ICMP error. > > > > > > > > > > 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 dominique.barthel@orange-ftgroup.com Wed Jul 21 16:19:46 2010 Return-Path: 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 9185E3A6809 for ; Wed, 21 Jul 2010 16:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_32=0.6, 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 jM-mDWNQ5CDr for ; Wed, 21 Jul 2010 16:19:45 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id B425C3A6824 for ; Wed, 21 Jul 2010 16:19:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A413F760002; Thu, 22 Jul 2010 01:22:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9CCD8760001; Thu, 22 Jul 2010 01:22:11 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 01:20:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 01:19:00 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF016FE43E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Soliciting WG comments on DIS for RPL Last Call Thread-Index: AcsoJCQ2LU4Q4y0oTpOc6LBx7bP9BwBBrleg References: From: To: , X-OriginalArrivalTime: 21 Jul 2010 23:20:00.0575 (UTC) FILETIME=[3DB44CF0:01CB292B] Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Wed, 21 Jul 2010 23:19:46 -0000 In order not to delay the RPL core spec and give more time to thoroughly = think through the proposed fixes, I'm in favor of Option B Best regards, Dominique=20 -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Nicolas DEJEAN Envoy=E9 : mardi 20 juillet 2010 17:57 =C0 : roll WG Objet : [Roll] Soliciting WG comments on DIS for RPL Last Call Hello all, Based on our experience of having deployed many smart metering networks = (totalling several million nodes), we have an issue with the way DIS and = DIOs are currently handled by RPL. To solve this issue, we suggest minor = modifications into the RPL core spec that only impacts the connection = process of a leaf node to the LLN. As part of the everyday life of a smart metering network, every so = often, a meter needs to be replaced or an extra one needs to be added. After physical installation, the technician stands by to witness the = network hook-up. He/she will not leave the premises before the meter is = satisfactorily connected. Every elapsed minute is an operation cost. We = are talking real money. There's no way a meter will wait for a DIO to = arrive by itself after some random number of hours. The meter has to = solicit DIOs from yet unknown neighbor routers, and that's done by = multicasting DIS'es. In our case of interest, the meter will be a leaf = node, therefore its presence will not modify the network topology. = Currently, RPL mandates that, in response to a multicast DIS, DIOs are = multicasted and Trickle timers at the routers are reset. Firstly, resetting the Trickle timers generates much more control = traffic than is needed. Neither the meter being installed nor neighbor = nodes need the frequent repeats of the very same DIO (remember the = topology is not changing). This is only a waste of energy at the routers = and at the nodes that are the destination of the DIOs. Secondly, multicast makes the problem even worse by enlarging the = audience for the DIO. Other than the meter being installed, nodes nearby = do not need to receive the DIO, because they have long settled and the = topology is not changing. In dense environments, the two effects combine to drastically reduce the = network lifetime compared to our currently deployed, non-RPL, protocol. It is our industrial experience that this is a real and significant = problem and we worked hard to solve it. Let's leverage that experience to the benefit of RPL users. Therefore, here are two possibilites for RPL. Option A) * In section 5.2, specify an L bit ("Leaf node") in the DIS format. * In section 7.3, change the third item of the list to read "When a node = receives a multicast DIS with a cleared L-bit and a Solicited = Information option and when the node matches all of the predicates in = the Solicited Information option." * In section 7.3, specify the algorithm to be run for responding with a = unicast DIO to a multicast DIS with L-bit set. This text shall be = described in a further email. This could advantageously be a temporary = Trickle timer. Option B) * In section 7.3, change the third item of the list to read "When a node = receives a multicast DIS with a Solicited Information option and the = node matches all of the predicates in the Solicited Information option, = unless a DIS flag restricts this behavior." * describe the L bit and RPL behavior in a separate I-D, together with = the DIS option TLVs. Would the WG please voice their opinion on these options? Thanks _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From navagar@cisco.com Wed Jul 21 21:27:18 2010 Return-Path: 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 3CC5D3A6838 for ; Wed, 21 Jul 2010 21:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.539 X-Spam-Level: X-Spam-Status: No, score=-9.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6CQgiwKMvaOX for ; Wed, 21 Jul 2010 21:27:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 92C4B3A6902 for ; Wed, 21 Jul 2010 21:27:16 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPpkR0xAaHte/2dsb2JhbACfdXGmMJsbhTIEg36HEQ Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 22 Jul 2010 04:27:32 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M4R2qJ011825 for ; Thu, 22 Jul 2010 04:27:32 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 09:56:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 09:56:49 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification for draft-ietf-roll-of0-02 Thread-Index: AcsCODQIBY+9hlmvT/2dcwiOliEeKQAABmnwCccccCA= References: <20100602094424.765143A6957@core3.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> From: "Navneet Agarwal (navagar)" To: "Pascal Thubert (pthubert)" , X-OriginalArrivalTime: 22 Jul 2010 04:26:50.0763 (UTC) FILETIME=[1B080DB0:01CB2956] Subject: Re: [Roll] New Version Notification for draft-ietf-roll-of0-02 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: , X-List-Received-Date: Thu, 22 Jul 2010 04:27:18 -0000 Hi Pascal: I have the following clarification on OF0-2: Section-3: The goal of stretching a rank is to allow a node to select siblings if there is only one parent. Since the sibling has been removed from the RPL spec, I am not sure the stretch logic of OF-0 is still applicable...can you pls clarify? Thx Regards, Navneet > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Wednesday, June 02, 2010 3:19 PM > To: roll@ietf.org > Subject: Re: [Roll] New Version Notification for=20 > draft-ietf-roll-of0-02 >=20 > Hi: >=20 > OF0-2 was just published. Limited changes include: >=20 > - make it very clear that only one octet of the rank is=20 > really used (from Zigbee's interop comments). > - provide an abstraction of the interaction with the core=20 > spec (requested some time ago on the list) though not at an API level. >=20 > Cheers, >=20 > Pascal >=20 >=20 > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Wednesday, June 02, 2010 11:44 AM > > To: Pascal Thubert (pthubert) > > Subject: New Version Notification for draft-ietf-roll-of0-02 > >=20 > >=20 > > A new version of I-D, draft-ietf-roll-of0-02.txt has been=20 > successfully=20 > > submitted by Pascal Thubert and posted to the IETF repository. > >=20 > > Filename: draft-ietf-roll-of0 > > Revision: 02 > > Title: RPL Objective Function 0 > > Creation_date: 2010-06-02 > > WG ID: roll > > Number_of_pages: 9 > >=20 > > Abstract: > > The Routing Protocol for Low Power and Lossy Networks (RPL)=20 > defines a=20 > > generic Distance Vector protocol for Low Power and Lossy=20 > Networks (LLNs). > > RPL is instantiated to honor a particular routing objective/=20 > > constraint by the adding a specific Objective Function (OF) that is=20 > > designed to solve that problem. This specification defines a basic=20 > > OF, OF0, that uses only the abstract properties exposed in=20 > RPL messages to maximize connectivity. > >=20 > >=20 > >=20 > > The IETF Secretariat. > >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From navagar@cisco.com Wed Jul 21 21:57:53 2010 Return-Path: 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 D2AB13A67AE for ; Wed, 21 Jul 2010 21:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.715 X-Spam-Level: X-Spam-Status: No, score=-9.715 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 8qjxPOEvCHGC for ; Wed, 21 Jul 2010 21:57:53 -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 094083A6869 for ; Wed, 21 Jul 2010 21:57:53 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEGAPNsR0xAaHte/2dsb2JhbACTN4w+caYcmxqCGIMaBIN+hxE Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 22 Jul 2010 04:58:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M4vVnq009225 for ; Thu, 22 Jul 2010 04:58:05 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 10:28:05 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB295A.7835F34A" Date: Thu, 22 Jul 2010 10:28:03 +0530 Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01A3230D@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MinHopRankIncr clarification Thread-Index: AcspWndrzT00xWCzQg6pR+pfL6Tg5Q== From: "Navneet Agarwal (navagar)" To: X-OriginalArrivalTime: 22 Jul 2010 04:58:05.0054 (UTC) FILETIME=[783229E0:01CB295A] Subject: [Roll] MinHopRankIncr clarification 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: , X-List-Received-Date: Thu, 22 Jul 2010 04:57:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB295A.7835F34A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG: I have the following query on MinHopRankIncr and its use in rank computation =20 Do we really see a need for MinHopRankIncr since the MRH-OF has tied the rank to link metrics and may be more of relevance for OF-0? IMO, for OF-0, it can be combined as part of step-of-rank which a node can choose (implementation specific) when doing rank computation. This can be used by other nodes in the DAG for of-0 for parent selection. Do we still need it to be specified in config option or removed? Comments? =20 Thanks =20 Regards, Navneet =20 ------_=_NextPart_001_01CB295A.7835F34A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 WG:
I have = the following=20 query on MinHopRankIncr and its use in rank = computation
 
Do we = really see a=20 need for MinHopRankIncr since the MRH-OF has tied the rank to link = metrics and=20 may be more of relevance for OF-0? IMO, for OF-0, it can be = combined as=20 part of step-of-rank which a node can choose (implementation = specific) when=20 doing rank computation. This can be used by other nodes in the = DAG for=20 of-0 for parent selection. Do we still need it to be specified = in=20 config option or removed? Comments?
 
Thanks
 
Regards,
Navneet
 
------_=_NextPart_001_01CB295A.7835F34A-- From pthubert@cisco.com Thu Jul 22 02:51:17 2010 Return-Path: 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 BCB0E3A69ED for ; Thu, 22 Jul 2010 02:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EVeVfaHlM4Zm for ; Thu, 22 Jul 2010 02:51:15 -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 8802A3A69DD for ; Thu, 22 Jul 2010 02:51:12 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 09:51:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M9pSXZ010818; Thu, 22 Jul 2010 09:51:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 11:51:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 11:51:25 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> In-Reply-To: <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Soliciting WG comments on DIS for RPL Last Call thread-index: Acso7VVT9R6yvlmST7OcFJiS9DptxQAlZs7Q References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com><12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com><5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "JP Vasseur" X-OriginalArrivalTime: 22 Jul 2010 09:51:28.0005 (UTC) FILETIME=[745F5350:01CB2983] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Thu, 22 Jul 2010 09:51:17 -0000 Phil: I understand the CA/CD aspect. The group also understands that we need to do something for this case. What we are being asked is really to allow the opportunity to do something specific as opposed to MUST a one fits it all. Would you propose an alternate text that would have the benefits of B) ? In my view, text that exposes a default behavior but allows adaptations would be appreciated. Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip > Levis > Sent: Wednesday, July 21, 2010 5:56 PM > To: JP Vasseur > Cc: roll WG > Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call >=20 >=20 > On Jul 20, 2010, at 10:15 PM, JP Vasseur wrote: >=20 > > > > On Jul 20, 2010, at 6:38 PM, Philip Levis wrote: > >>>>> > >>>>> > >> > >> My concern is that we're adding a specialized mechanism under the > assumptions of how the underlying link layer operates. > > > > I do not think that we do.We just define a simple mechanism that > > allows for reducing the number of messages when inserting a node (leaf > node). This is true regardless of the link layer in use. > > > > JP. >=20 > JP -- the scheme assumes that unicast transmissions are collision-free. > Otherwise a set of correlated responses lead to a rash of collisions and terrible > network discovery: it doesn't work. This is a well known problem in > wireless[1,2], and one of the major motivations behind Trickle. >=20 > Phil >=20 >=20 > [1] Ni et al. "The broadcast storm problem in a mobile ad hoc network" > http://portal.acm.org/citation.cfm?id=3D313525 > [2] Ganesan et al. "Complex Behavior at Scale: An Experimental Study of Low- > Power Wireless Sensor Networks (2002)" > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.19.770 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Thu Jul 22 04:51:56 2010 Return-Path: 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 3C4E23A685E for ; Thu, 22 Jul 2010 04:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gLuVtossYLVc for ; Thu, 22 Jul 2010 04:51:55 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id 016613A6407 for ; Thu, 22 Jul 2010 04:51:54 -0700 (PDT) Received: from source ([209.85.212.53]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTEgw6zCN7enuNF3oLIIlvc4NTmY5tu6a@postini.com; Thu, 22 Jul 2010 04:52:12 PDT Received: by mail-vw0-f53.google.com with SMTP id 15so37503vws.40 for ; Thu, 22 Jul 2010 04:52:11 -0700 (PDT) Received: by 10.224.59.195 with SMTP id m3mr1203703qah.34.1279799531342; Thu, 22 Jul 2010 04:52:11 -0700 (PDT) From: Yoav Ben-Yehezkel References: <3a9969c91b0b37f5c4c64305397a14aa@mail.gmail.com> <4C46F4AD.9010706@acm.org> 3d6c4701816ef5a44eee80b7027880ab@mail.gmail.com In-Reply-To: 3d6c4701816ef5a44eee80b7027880ab@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acso19xXMeBEvLY+RrybDqTe8MQqugABsJXAAC1jQpA= Date: Thu, 22 Jul 2010 14:52:08 +0300 Message-ID: <3083375edbdaae1883d2c12d3f710cbf@mail.gmail.com> To: Yoav Ben-Yehezkel , Tim Winter , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] RPLInstanceID term clarification 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: , X-List-Received-Date: Thu, 22 Jul 2010 11:51:56 -0000 Found it :) First para. in section 4. Thanks, Yoav -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Wednesday, July 21, 2010 5:22 PM To: 'Tim Winter'; 'roll@ietf.org' Subject: RE: [Roll] RPLInstanceID term clarification Thanks Tim! I've another clarification on the scope RPL of nodes within a network with multiple RPL Instances. I was asked whether RPL supports a scenario where an RPL node "belongs" to different DODAGs in different RPL instances. The limitation I am aware of is that an RPL node cannot belong to different DODAGs in the same RPL Instance, but there was no text about what happens when there are multiple RPL instances. My implicit understanding is that no, but I'd like to make sure. Would you consider adding this clarification explicitly? Regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: Wednesday, July 21, 2010 4:23 PM To: roll@ietf.org Subject: Re: [Roll] RPLInstanceID term clarification We will update this for -11: RPLInstanceID: A unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function. -Tim On 07/20/2010 07:46 AM, Yoav Ben-Yehezkel wrote: > Hi, > > Question on the following term: > > "RPLInstanceID: A unique identifier within a network. Two DODAGs with > the same RPLInstanceID share the same Objective Function." > > Is it really limited to two DODAGs? Suggest to remove the word "Two" if not. > > Regards, > > Yoav > > > > _______________________________________________ > 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 pthubert@cisco.com Thu Jul 22 09:42:10 2010 Return-Path: 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 9A11B3A69B9 for ; Thu, 22 Jul 2010 09:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EDfLNFEU60fa for ; Thu, 22 Jul 2010 09:42: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 C7C823A69F9 for ; Thu, 22 Jul 2010 09:42:08 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 16:42:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6MGgOQt004508; Thu, 22 Jul 2010 16:42:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 18:42:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 22 Jul 2010 18:42:21 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AB31@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue #58: Clarification on DAO thread-index: AcspvNqzXQ9cQRvASNCpmlAz2dLkew== From: "Pascal Thubert (pthubert)" To: "roll WG" X-OriginalArrivalTime: 22 Jul 2010 16:42:25.0086 (UTC) FILETIME=[DD234DE0:01CB29BC] Subject: [Roll] Closing issue #58: Clarification on DAO 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: , X-List-Received-Date: Thu, 22 Jul 2010 16:42:11 -0000 RGVhciBXRw0KDQpJIHRoaW5rIHdlIGNhbiBjbG9zZSA1OC4gMTEgd2lsbCBoYXZlIHRoZSBmb2xs b3dpbmcgY2hhbmdlczoNCg0KPiAgLSDigJxNdWx0aWNhc3QgREFPcyBNVVNUIE5PVCBpbmNsdWRl IFRyYW5zaXQgSW5mb3JtYXRpb24gb3B0aW9uc+KAnSAoU2VjdGlvbg0KPiA4LjYpLiBEbyB5b3Ug bWVhbiDigJxNVVNUIG5vdCBpbmNsdWRlIGEgcGFyZW50IGFkZHJlc3MgaW4gdGhlIHRyYW5zaXQN Cj4gaW5mb3JtYXRpb24gb3B0aW9u4oCdPw0KDQpDb3JyZWN0ZWQgYWxvbmcgdGhlIHByb3Bvc2Fs DQoNCg0KPiAgLSBTZWN0aW9uIDE2LjIuNiAod2hpY2ggZGVhbHMgd2l0aCBjb25maWd1cmF0aW9u KSBpbnRyb2R1Y2VzIHNvbWUgIHRlcm1pbm9sb2d5DQo+IG5vdCB1c2VkIGluIHRoZSBzcGVjIChl LmcgVU5SRUFDSEFCTEUgc3RhdGUpLiBJcyB0aGlzIHNvbWUgIGxlZ2FjeSB0ZXh0Pw0KDQpMZWdh Y3kgdGV4dCByZW1vdmVkLg0KDQo+ICAtIFdoYXQgYWN0aW9ucyBuZWVkIHRvIGJlIHRha2VuIGJ5 IGEgbm9kZSB0aGF0IGRpZG7igJl0IGdldCBhIERBTy1BQ0sgIHJlc3BvbnNlDQo+IHdoZW4gc2V0 dGluZyB0aGUgSyBiaXQ/DQoNClRoZSB0ZXh0IGxlYXZlcyB0aGF0IHRvIGltcGxlbWVudGF0aW9u LiBTaG91bGQgbm90IHJldHJ5IGluZGVmaW5pdGVseSB0aG91Z2ghDQoNCklmIGFueWJvZHkgb3Bw b3NlcyB0byBjbG9zZSBhbG9uZyB0aGUgYWJvdmUgbGluZSBwbGVhc2Ugc3BlYWsgdXAgOiApDQoN ClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcm9sbC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2Ygcm9sbA0KPiBpc3N1ZSB0cmFja2VyDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTMsIDIwMTAg MTE6MTQgQU0NCj4gVG86IGpwdkBjaXNjby5jb20NCj4gQ2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3Vi amVjdDogW1JvbGxdIFtyb2xsXSAjNTg6IENsYXJpZmljYXRpb24gb24gREFPDQo+IA0KPiAjNTg6 IENsYXJpZmljYXRpb24gb24gREFPDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tDQo+ICBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICB8 ICAgICAgIE93bmVyOg0KPiAgICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgIHwgICAgICBTdGF0 dXM6ICBuZXcNCj4gIFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0K PiBDb21wb25lbnQ6ICBycGwgICAgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+ICBTZXZlcml0 eTogIEluIFdHIExhc3QgQ2FsbCAgfCAgICBLZXl3b3JkczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0NCj4gIEhlbGxvIE1hdGhpbGRlDQo+ IA0KPiAgLSBXaGF0IGlzIHRoZSBEQU8gcGFyZW50IHNlbGVjdGlvbiBjcml0ZXJpYSBmb3IgT0NQ MD8gU2FtZSBhcyBmb3IgRElPICBwYXJlbnRzDQo+IEkgYXNzdW1lLg0KPiAgW1Bhc2NhbF0gT0Yw IG9ubHkgbWFuZGF0ZXMgb25lIHByZWZlcnJlZCBwYXJlbnQgd2l0aCBnb29kIGVub3VnaA0KPiBi aWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eSwgYW5kIGl0IGVuYWJsZXMgYSBiYWNrdXAgaWYgb25l IGlzIGF2YWlsYWJsZS4NCj4gIFNvIHllcywgdGhlcmXigJlzIGxpdHRsZSBjaG9pY2UgYnV0IHBp Y2sgaXQgYXMgREFPIHBhcmVudCBhcyB3ZWxsLiBUaGUgZHJhZnQgIGNvdWxkDQo+IGhhdmUgYW4g YWRkaXRpb25hbCBzZW50ZW5jZSB0byBzYXkgdGhhdCBJIGFkbWl0Lg0KPiANCj4gIC0gV2hhdCBh Y3Rpb25zIG5lZWQgdG8gYmUgdGFrZW4gYnkgYSBub2RlIHRoYXQgZGlkbuKAmXQgZ2V0IGEgREFP LUFDSyAgcmVzcG9uc2UNCj4gd2hlbiBzZXR0aW5nIHRoZSBLIGJpdD8NCj4gIFtQYXNjYWxdIFdl IGhhdmUgdG8gcmVmaW5lIHRoYXQgdGV4dCBpbiAxMSBmb3Igc3VyZS4gT25seSBuZXcgaW5mb3Jt YXRpb24gIGlzDQo+IHNlbnQgYXN5bmNocm9ub3VzbHkgdG8gdGhlIERBTyBwYXJlbnRzIHdoaWxl IHRoZSBmdWxsIGluZm9ybWF0aW9uIGlzICBzZW50IGluDQo+IGRlbWFuZCAodXBvbiBEVFNOIG9y IG5ldyB2ZXJzaW9uKS4gSW4gc2hvcnQsIHRoZSByaWNoICBpbXBsZW1lbnRhdGlvbiBjYW4NCj4g bWFpbnRhaW4gcGVyIHBhcmVudCB3aGF0IHdhcyBhY2tub3dsZWRnZWQgYW5kIGZsYWcgaXQgIGFz IG5vdCBuZXcuIFRoZQ0KPiBjb25zdHJhaW5lZCBpbXBsZW1lbnRhdGlvbiBzZW5kcyB0aGUgZGVs dGEgb25jZSBhbmQgZmxhZyAgaXQgYXMgbm90IG5ldw0KPiB3aXRob3V0IGFuIGFjaywgd2FpdGlu ZyBmb3IgdGhlIG5leHQgZnVsbCBpbmZvcm1hdGlvbiB0byAgZmlsbCB0aGUgZ2Fwcy4gU28NCj4g YmFzaWNhbGx5IHdoZW4gc29tZXRoaW5nIG5ldyBpcyBsZWFybnQsIHRoZSBzdG9yaW5nICByb3V0 ZXIgYXJtcyBhIHRpbWVyIHRvDQo+IHNjaGVkdWxlIGEgREFPLiBXaGVuIHRoZSB0aW1lciBlbGFw c2VzLCB0aGUgcm91dGVyICBzZW5kcyBhbGwgbmV3IGluZm9ybWF0aW9uDQo+IHRvIHRoZSBwYXJl bnRzLiBUaGUgdGltZXIga2VlcHMgZWxhcHNpbmcgZm9yIGEgIGdpdmVuIHBhcmVudCB0aWxsIHRo ZSBwYXJlbnQgYWNrcw0KPiB0aGUgbW9zdCByZWNlbnQgREFPIHNlcXVlbmNlIHNlbnQgdG8gaXQg IG9yIHRoZSByb3V0ZXIgZ2l2ZXMgdXAuIElmIHRoZSByb3V0ZXINCj4gZ2l2ZXMgdXAsIHRoZSBw YXJlbnQgaXMgb3V0IG9mIHN5bmMgIHRpbGwgdGhlIG5leHQgY2hhbmdlIG9yIGZ1bGwgaW5mb3Jt YXRpb24NCj4gdXBkYXRlcyBpdC4gVGhlIHBhdGggc2VxdWVuY2UgIHRoYXQgY2lyY3VsYXRlcyB2 aWEgb3RoZXIgcGFyZW50cyB0aGF0IGFyZSBub3Qgb3V0DQo+IG9mIHN5bmMgaXMgZnJlc2hlciBh bmQgIGVuYWJsZXMgdGhlIGFuY2VzdG9ycyB0byBzZWxlY3QgdGhlIHVzYWJsZSBwYXRoLg0KPiAN Cj4gIC0gU2VjdGlvbiAxNi4yLjYgKHdoaWNoIGRlYWxzIHdpdGggY29uZmlndXJhdGlvbikgaW50 cm9kdWNlcyBzb21lICB0ZXJtaW5vbG9neQ0KPiBub3QgdXNlZCBpbiB0aGUgc3BlYyAoZS5nIFVO UkVBQ0hBQkxFIHN0YXRlKS4gSXMgdGhpcyBzb21lICBsZWdhY3kgdGV4dD8NCj4gIFtQYXNjYWxd IEl0IGlzLiBUaGF0IHN0YXRlIHdhcyBpbiB0aGUgRlNNIHRoYXQgd2VudCBkb3duIHRoZSBzaW5r IGFyb3VuZA0KPiAgMDgNCj4gDQo+ICAtIFdoZW4gc2hvdWxkIGEgbm9kZSBpbml0aWF0ZSAoaS5l LiBub3QgcHJvcGFnYXRlKSBhbiBpbmNyZWFzZSBpbiBEVFNOPw0KPiAgW1Bhc2NhbF0gQ2FuIGJl IHVwb24gYW4gaW5jb25zaXN0ZW5jeSBkZXRlY3Rpb24sIG9yIHVwb24gYW4gaW50ZXJuYWwgdGlt ZXIgIHBlcg0KPiBwb2xpY3kgdGhvdWdoIHRoYXQgaXMgbm90IG1hbmRhdGVkLiBBbiBpbmNvbnNp c3RlbmN5IGNhbiBiZSBhbiBSUEYgIGNoZWNrLCBhDQo+IERBTyBlbnRyeSBub3QgcmV2YWxpZGF0 ZWQsIGEgZGF0YXBhdGggdmFsaWRhdGlvbiBmYWlsdXJlLiBOZXcgIERTVE4gc2hvdWxkIGJlDQo+ IGNhcGVkIGluIHRpbWUuDQo+IA0KPiAgLSDigJxNdWx0aWNhc3QgREFPcyBNVVNUIE5PVCBpbmNs dWRlIFRyYW5zaXQgSW5mb3JtYXRpb24gb3B0aW9uc+KAnSAoU2VjdGlvbg0KPiA4LjYpLiBEbyB5 b3UgbWVhbiDigJxNVVNUIG5vdCBpbmNsdWRlIGEgcGFyZW50IGFkZHJlc3MgaW4gdGhlIHRyYW5z aXQNCj4gaW5mb3JtYXRpb24gb3B0aW9u4oCdPw0KPiAgW1Bhc2NhbF0gT3VwcyEgQ29ycmVjdC4g V2Ugc29tZXRpbWUgbmVlZCB0aGUgbGlmZXRpbWUuDQo+IA0KPiAgQmVzdCwNCj4gDQo+ICBQYXNj YWwNCj4gDQo+IC0tDQo+IFRpY2tldCBVUkw6IDxodHRwczovL3N2bi50b29scy5pZXRmLm9yZy93 Zy9yb2xsL3RyYWMvdGlja2V0LzU4Pg0KPiByb2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv cm9sbC8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From pthubert@cisco.com Thu Jul 22 09:47:22 2010 Return-Path: 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 D26843A6887 for ; Thu, 22 Jul 2010 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8f-lvDuvyIZz for ; Thu, 22 Jul 2010 09:47:21 -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 A78343A6844 for ; Thu, 22 Jul 2010 09:47:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOISSExAZnwM/2dsb2JhbACfcnGmYJskhTYEixI Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 16:47:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6MGlbhf015417 for ; Thu, 22 Jul 2010 16:47:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 18:47:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 18:47:24 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com> In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification for draft-ietf-roll-of0-02 thread-index: AcsCODQIBY+9hlmvT/2dcwiOliEeKQAABmnwCccccCAAGiDzQA== References: <20100602094424.765143A6957@core3.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> From: "Pascal Thubert (pthubert)" To: "Navneet Agarwal (navagar)" , X-OriginalArrivalTime: 22 Jul 2010 16:47:37.0403 (UTC) FILETIME=[974B18B0:01CB29BD] Subject: Re: [Roll] New Version Notification for draft-ietf-roll-of0-02 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: , X-List-Received-Date: Thu, 22 Jul 2010 16:47:22 -0000 Hi Navneet: The concept of sibling still exists, and at the moment the RPL spec does not specify how they can be used; in other words they cannot safely be used. You can thus see the stretch as a filter that filters out neighbors of low interest because they yield no forward progress. Does that make sense? Pascal > -----Original Message----- > From: Navneet Agarwal (navagar) > Sent: Thursday, July 22, 2010 6:27 AM > To: Pascal Thubert (pthubert); roll@ietf.org > Subject: RE: [Roll] New Version Notification for draft-ietf-roll-of0-02 >=20 > Hi Pascal: > I have the following clarification on OF0-2: >=20 > Section-3: The goal of stretching a rank is to allow a node to select siblings if > there is only one parent. Since the sibling has been removed from the RPL spec, > I am not sure the stretch logic of OF-0 is still applicable...can you pls clarify? >=20 > Thx >=20 > Regards, > Navneet >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > > Behalf Of Pascal Thubert (pthubert) > > Sent: Wednesday, June 02, 2010 3:19 PM > > To: roll@ietf.org > > Subject: Re: [Roll] New Version Notification for > > draft-ietf-roll-of0-02 > > > > Hi: > > > > OF0-2 was just published. Limited changes include: > > > > - make it very clear that only one octet of the rank is > > really used (from Zigbee's interop comments). > > - provide an abstraction of the interaction with the core > > spec (requested some time ago on the list) though not at an API level. > > > > Cheers, > > > > Pascal > > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Wednesday, June 02, 2010 11:44 AM > > > To: Pascal Thubert (pthubert) > > > Subject: New Version Notification for draft-ietf-roll-of0-02 > > > > > > > > > A new version of I-D, draft-ietf-roll-of0-02.txt has been > > successfully > > > submitted by Pascal Thubert and posted to the IETF repository. > > > > > > Filename: draft-ietf-roll-of0 > > > Revision: 02 > > > Title: RPL Objective Function 0 > > > Creation_date: 2010-06-02 > > > WG ID: roll > > > Number_of_pages: 9 > > > > > > Abstract: > > > The Routing Protocol for Low Power and Lossy Networks (RPL) > > defines a > > > generic Distance Vector protocol for Low Power and Lossy > > Networks (LLNs). > > > RPL is instantiated to honor a particular routing objective/ > > > constraint by the adding a specific Objective Function (OF) that is > > > designed to solve that problem. This specification defines a basic > > > OF, OF0, that uses only the abstract properties exposed in > > RPL messages to maximize connectivity. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > From jpv@cisco.com Thu Jul 22 12:10:31 2010 Return-Path: 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 146FD3A67C2 for ; Thu, 22 Jul 2010 12:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9W2A0qxp9ebT for ; Thu, 22 Jul 2010 12:10:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 644BC3A6850 for ; Thu, 22 Jul 2010 12:10:29 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN40SEyrRN+J/2dsb2JhbACfdHGnVJsYhTYEiFmCOQ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2010 19:10:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6MJAiOx004019; Thu, 22 Jul 2010 19:10:46 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:10:44 +0200 Received: from [192.168.1.12] ([10.55.90.47]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:10:44 +0200 Message-Id: From: JP Vasseur To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 21:10:43 +0200 References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com><12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com><5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jul 2010 19:10:44.0062 (UTC) FILETIME=[955747E0:01CB29D1] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Thu, 22 Jul 2010 19:10:31 -0000 Hi Pascal, On Jul 22, 2010, at 11:51 AM, Pascal Thubert (pthubert) wrote: > Phil: > > I understand the CA/CD aspect. The group also understands that we need > to do something for this case. What we are being asked is really to > allow the opportunity to do something specific as opposed to MUST a > one > fits it all. Would you propose an alternate text that would have the > benefits of B) ? In my view, text that exposes a default behavior but > allows adaptations would be appreciated. > As discussed today i'll work with Phil on the modified text compliant with the option B for which we have a consensus on the mailing list. JP. > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of Philip >> Levis >> Sent: Wednesday, July 21, 2010 5:56 PM >> To: JP Vasseur >> Cc: roll WG >> Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call >> >> >> On Jul 20, 2010, at 10:15 PM, JP Vasseur wrote: >> >>> >>> On Jul 20, 2010, at 6:38 PM, Philip Levis wrote: >>>>>>> >>>>>>> >>>> >>>> My concern is that we're adding a specialized mechanism under the >> assumptions of how the underlying link layer operates. >>> >>> I do not think that we do.We just define a simple mechanism that >>> allows for reducing the number of messages when inserting a node > (leaf >> node). This is true regardless of the link layer in use. >>> >>> JP. >> >> JP -- the scheme assumes that unicast transmissions are > collision-free. >> Otherwise a set of correlated responses lead to a rash of collisions > and terrible >> network discovery: it doesn't work. This is a well known problem in >> wireless[1,2], and one of the major motivations behind Trickle. >> >> Phil >> >> >> [1] Ni et al. "The broadcast storm problem in a mobile ad hoc >> network" >> http://portal.acm.org/citation.cfm?id=313525 >> [2] Ganesan et al. "Complex Behavior at Scale: An Experimental Study > of Low- >> Power Wireless Sensor Networks (2002)" >> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.770 >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Thu Jul 22 12:18:08 2010 Return-Path: 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 21A753A6842 for ; Thu, 22 Jul 2010 12:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 ReUnxzPHxRPR for ; Thu, 22 Jul 2010 12:18:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D5CE63A67D4 for ; Thu, 22 Jul 2010 12:18:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oc1Hh-0004NJ-PE; Thu, 22 Jul 2010 12:18:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 22 Jul 2010 19:18:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/56#comment:1 Message-ID: <064.b8105a9d556a003964d4f024ebf5ff3a@tools.ietf.org> References: <055.1533bd03f4c151786a54d1047fc43e73@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <055.1533bd03f4c151786a54d1047fc43e73@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #56: Transit and Target address mismatch X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:18:08 -0000 #56: [Roll] Transit and Target address mismatch -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Here is the new text that will be incorporated to rev-11 of RPL, which allows us to close this ticket: -------------------------------------------- - The R bit in PIO is used as in RFC3775 to indicate a (global/ULA) address as opposed to a prefix. - The prefix is still valid for the purpose of autoconf when the R bit is set. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Option Length | Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: Format of the Prefix Information Option The Prefix Information option may be used to distribute the prefix in use inside the DODAG, e.g. for address autoconfiguration. .... R 1-bit Router address flag. When set, indicates that the Prefix field contains a complete IPv6 address assigned to the sending router that can be used as parent in a target option. The indicated prefix is the first Prefix Length bits of the Prefix field. The router IPv6 address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses only the leading bits. Interpretation of this flag bit is thus independent of the processing required for the On-Link (L) and Autonomous Address-Configuration (A) flag bits. - The address in the PIO can be used as transit parent by the children but is not necessarily on link for the children. - The router that advertises an address as parent in PIO must also advertise that address as target in a DAO for the route recursion to complete. - An address that is advertised as target in a DAO must be collocated or reachable onlink by the parent that is indicated in the associated transit information. - A new flag in the transit information qualifies a target address that is behind a router, either as an attached host or installed on another interface. The router is the tunnel endpoint for such address. Transit Information is updated as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Option Length |E| Reserved | Path Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Sequence | Path Lifetime | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + Parent Address* + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The '*' denotes that the Parent Address is not always present, as described below. Figure XX: Format of the Transit Information option .... External (E): 1-bit flag. The 'E' flag is set to indicate that the parent router redistributes external targets into the RPL network. An external target is a target that has been learned through an alternate protocol. The external targets are listed in the target options that immediately precede the Transit Information option. An external target is not expected to support RPL messages and options. .... DAO rules are updated as follows: In non-storing mode additional rules apply to ensure the continuity of end-to-end source route path: 1. The address used as transit parent by the children MUST be taken from a PIO with the 'R' flag set from that parent but is not necessarily on link for the children. 2. The router that advertises an address as parent in a PIO MUST also advertise that address as target in a DAO message. 3. An address that is advertised as target in a DAO MUST be collocated or reachable onlink by the parent that is indicated in the associated transit information. 4. A router might have targets that are not known to be onlink for a parent, either because they are addresses located on an alternate interface or because they belong to nodes that are external to RPL, for instance connected hosts. In order to inject such a target in the RPL network, the router MUST advertise itself as the Parent Address in the Transit Information option for that target, using an address that is onlink for that nodes DAO parent. If the target belongs to an external node then the router MUST set the External 'E' flag in the transit information. -- Ticket URL: roll From Matteo.Paris@ember.com Thu Jul 22 12:19:22 2010 Return-Path: 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 5A4253A67AF for ; Thu, 22 Jul 2010 12:19:22 -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 tW+LyXF10gzB for ; Thu, 22 Jul 2010 12:19:21 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2FF513A6765 for ; Thu, 22 Jul 2010 12:19:21 -0700 (PDT) Received: from [10.7.6.5] ([192.168.81.42]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 15:19:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com> References: <20100602094424.765143A6957@core3.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com> Date: Thu, 22 Jul 2010 15:19:36 -0400 To: From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 22 Jul 2010 19:19:37.0811 (UTC) FILETIME=[D37AEA30:01CB29D2] Subject: [Roll] DAO Inconsistency Loop Detection and Recovery 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: , X-List-Received-Date: Thu, 22 Jul 2010 19:19:22 -0000 I think section 10.2.2.3 of rpl-10, "DAO Inconsistency Loop Detection and Recovery" could use some clarification. The first sentence is ungrammatical: "A DAO inconsistency happens when router that has an down DAO route via a child that is a remnant from an obsolete state that is not matched in the child." This makes the rest of the section difficult to follow. I believe the intention is to say that a node receiving a downward-going packet should check to see if the previous sender is its DAO parent. If not, it notifies the sender by returning the packet with the Forwarding-Error 'F' bit set. If this is the correct interpretation, I believe the entire section only applies to the storing mode of operation. In non-storing mode, the packet is source-routed from the root, and no state is maintained on the previous upstream hop. This should be pointed out for clarity. The second paragraph begins: "In a general manner, a packet that goes down should never go up again." This sounds like a recap of the previous section 10.2.2.2, "DAG Inconsistency Loop Detection", which explains that the rank must increase when a packet is going downward and decrease when a packet is going upward. I find this sentence confusing here because I thought this section was describing a *different* kind of inconsistency than the previous section. Is a DAG inconsistency also considered a DAO inconsistency for downward-headed packets? If so, should the corrective actions described in 10.2.2.2 (setting the 'R' bit, resetting the Trickle timer) be taken in addition to the actions described in 10.2.2.3 (setting the 'F' bit, etc)? Thanks, Matteo From trac@tools.ietf.org Thu Jul 22 12:21:34 2010 Return-Path: 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 D033A3A68A9 for ; Thu, 22 Jul 2010 12:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 LAuZLiQmKISf for ; Thu, 22 Jul 2010 12:21:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 70BC53A68C0 for ; Thu, 22 Jul 2010 12:21:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oc1L5-000120-7z; Thu, 22 Jul 2010 12:21:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Thu, 22 Jul 2010 19:21:51 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/55#comment:2 Message-ID: <064.c5fd4cca77e4cc7a92b2119506ab003a@tools.ietf.org> References: <055.3f9964d7e3d9be963ea63ee01a78e115@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <055.3f9964d7e3d9be963ea63ee01a78e115@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #55: Downward routes in RPL rev -09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:21:35 -0000 #55: Downward routes in RPL rev -09 -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: The text below is incorporated in rev-11 of RPL, which closes that ticket: 1 and 4) DAO messages are consumed and regenerated by the unicast destination. (Note that in consideration of Ticket 57 that destination may the DODAG root) We updated the text to help clarify this in RPL-11 as follows: Generation of DAO Messages A node might send DAO messages when it receives DAO messages, as a result of changes in its DAO parent set, or in response to another event such as the expiry of a related prefix lifetime. In the case of receiving DAOs, it matters whether the DAO message is "new," or contains new information. In non-storing mode, every DAO message a node receives is "new." In storing mode, a DAO message is "new" if it satisfies any of these criteria for a contained Target: 1. it has a newer Path Sequence number, 2. it has additional Path Control bits, or 3. is a No-Path DAO message that removes the last downward route to a prefix. A node that receives a DAO message from its sub-DODAG MAY suppress scheduling a DAO message transmission if that DAO message is not new. ------ DAO Transmission Scheduling Because DAOs flow upwards, receiving a unicast DAO can trigger sending a unicast DAO to a DAO parent. 1. On receiving a unicast DAO message with updated information, such as containing a Transit Information option with a new Path Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO message immediately. It SHOULD delay sending the DAO message in order to aggregate DAO information from other nodes for which it is a DAO parent. 2. A node SHOULD delay sending a DAO message with a timer (DelayDAO). Receiving a DAO message starts the DelayDAO timer. DAO messages received while the DelayDAO timer is active do not reset the timer. When the DelayDAO timer expires, the node sends a DAO. 3. When a node adds a node to its DAO parent set, it SHOULD schedule a DAO message transmission. DelayDAO's value and calculation is implementation-dependent. 2) RPL-11 clarifies the DAO structure as follows: Structure of DAO Messages DAOs follow a common structure in both storing and non-storing networks. In the most general form, a DAO message may include several groups of options, where each group consists of one or more Target options followed by one or more Transit Information options. The entire group of Transit Information options applies to the entire group of Target options. Later sections describe further details for each mode of operation. 3) Text is updated as follows for RPL-11: o A node's DAO parent set MUST be a subset of its DODAG parent set. 4) See #1 above 5) The rule "Each time a node link-local multicasts a DAO, the DAOSequence field MUST increment by one since the last link local multicast DAO" is removed for RPL-11 -- Ticket URL: roll From jpv@cisco.com Thu Jul 22 12:34:18 2010 Return-Path: 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 560483A68DE for ; Thu, 22 Jul 2010 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.326 X-Spam-Level: X-Spam-Status: No, score=-9.326 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_HI=-8] 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 eIXIvW-Td30U for ; Thu, 22 Jul 2010 12:34:14 -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 9A93D3A68F1 for ; Thu, 22 Jul 2010 12:33:54 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAAY6SEyrR7Hu/2dsb2JhbACBRJ4wcadVinWQJoU2BIhZgjk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 22 Jul 2010 19:34:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6MJY4AJ014033 for ; Thu, 22 Jul 2010 19:34:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:34:04 +0200 Received: from [192.168.1.12] ([10.55.90.47]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 21:34:03 +0200 Message-Id: <65E84FF5-4109-4F53-B8E5-BC20AAB71C82@cisco.com> From: JP Vasseur To: roll WG Content-Type: multipart/alternative; boundary=Apple-Mail-2-872332837 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 21:34:03 +0200 References: <20100722111034.747793A6B2E@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 22 Jul 2010 19:34:03.0815 (UTC) FILETIME=[D7A8A370:01CB29D4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17522.001 X-TM-AS-Result: No--29.344700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: IETF 78 - Registration Cut-off 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: , X-List-Received-Date: Thu, 22 Jul 2010 19:34:19 -0000 --Apple-Mail-2-872332837 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: IETF Secretariat > Date: July 22, 2010 1:10:30 PM CEDT > To: IETF Announcement list > Cc: wgchairs@ietf.org > Subject: IETF 78 - Registration Cut-off > > 78th IETF Meeting > Maastricht, Netherlands > July 25-30, 2010 > > 1. Registration: Final Pre-Registration and Pre-Payment Cut-off is > TOMORROW Friday, 1 July > 2. Social Event > > Please note: Breakfast will -NOT- be provided at the MECC (IETF > meeting > venue). Internet access is not included in the IETF hotel guest room > rates. > =================================================== > 1) Registration: Final Pre-Registration and Pre-Payment cut-off is > Friday, > 23 July 2010 at 17:00 local Maastricht time (08:00 PDT, 15:00 UTC). > Registration and payment will resume on site on Sunday 25 July 2010 at > 11:00am; your registration fee will be $785 USD. You can register on > line > at: http://www.ietf.org/meeting/78/index.html > > On site registration will be located in the Trajectum Foyer at the > MECC. > > > 2) Social Event > Social event tickets purchased on line prior to 17:00 local Maastricht > time (08:00 PDT, 15:00 UTC) Friday, 23 July 2010 will be $25.00 USD > Starting at 11:00am Sunday 25 July 2010, social event tickets > purchased on > site will be $27.50 USD for credit card payment or 25.00 Euro cash. > > Ticket sales for the social event will end at 12:00 noon on Tuesday, > 27 > July 2010. > > General Information: http://www.ietf78.nl/social-event.html > Where: On the banks of the Meuse River > Date: Tuesday 27 July 2010 > Time: 19:30 - 22:30 > Host: Ministry of Economic Affairs, the Province of Limburg and the > Municipality of Maastricht > > Maastricht, one of the Netherlands oldest and most beautiful cities, > is > the backdrop to this spectacular social event, exclusively for > visitors to > the 78th IETF meeting. It is a lighthearted break in the IETF78 > Maastricht > program - an event you do not want to miss! > > You must register for the IETF meeting before you can purchase social > event tickets. > > Only 3 days until IETF 78! > http://www.ietf.org/meeting/78/index.html > > --Apple-Mail-2-872332837 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: July 22, 2010 1:10:30 PM = CEDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = IETF 78 - Registration Cut-off 

78th IETF = Meeting
Maastricht, Netherlands
July 25-30, 2010

1. = Registration: Final Pre-Registration and Pre-Payment Cut-off = is
TOMORROW Friday, 1 July
2. Social Event

Please note: = Breakfast will -NOT- be provided at the MECC (IETF meeting
venue). =  Internet access is not included in the IETF hotel guest = room
rates.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
1) Registration: Final Pre-Registration and = Pre-Payment cut-off is Friday,
23 July 2010 at 17:00 local Maastricht = time (08:00 PDT, 15:00 UTC).
Registration and payment will resume on = site on Sunday 25 July 2010 at
11:00am; your registration fee will be = $785 USD. You can register on line
at: http://www.ietf.org/mee= ting/78/index.html

On site registration will be located in = the Trajectum Foyer at the MECC.


2) Social Event
Social = event tickets purchased on line prior to 17:00 local Maastricht
time = (08:00 PDT, 15:00 UTC) Friday, 23 July 2010 will be $25.00 = USD
Starting at 11:00am Sunday 25 July 2010, social event tickets = purchased on
site will be $27.50 USD for credit card payment or 25.00 = Euro cash.

Ticket sales for the social event will end at 12:00 = noon on Tuesday, 27
July 2010.

General Information: http://www.ietf78.nl/socia= l-event.html
Where: On the banks of the Meuse River
Date: = Tuesday 27 July 2010
Time: 19:30 - 22:30
Host: Ministry of = Economic Affairs, the Province of Limburg and the
Municipality of = Maastricht

Maastricht, one of the Netherlands oldest and most = beautiful cities, is
the backdrop to this spectacular social event, = exclusively for visitors to
the 78th IETF meeting. It is a = lighthearted break in the IETF78 Maastricht
program - an event you do = not want to miss!

You must register for the IETF meeting before = you can purchase social
event tickets.

Only 3 days until IETF = 78!
http://www.ietf.org/mee= ting/78/index.html



= --Apple-Mail-2-872332837-- From trac@tools.ietf.org Thu Jul 22 14:29:15 2010 Return-Path: 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 580FD3A6893 for ; Thu, 22 Jul 2010 14:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 TUqFKqRFZjxm for ; Thu, 22 Jul 2010 14:29:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 609C83A6852 for ; Thu, 22 Jul 2010 14:29:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oc3Kd-0002n2-Ck; Thu, 22 Jul 2010 14:29:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 22 Jul 2010 21:29:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/68#comment:1 Message-ID: <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #68: RPL security comments received during LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 21:29:15 -0000 #68: RPL security comments received during LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Answer in line -- Ticket URL: roll From alexandru.petrescu@gmail.com Thu Jul 22 14:47:24 2010 Return-Path: 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 16FEF3A69C7 for ; Thu, 22 Jul 2010 14:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=0.568, 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 ZSQQsA6f1OcT for ; Thu, 22 Jul 2010 14:47:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E73F83A69A9 for ; Thu, 22 Jul 2010 14:47:21 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 40FA99400D0 for ; Thu, 22 Jul 2010 23:47:33 +0200 (CEST) Message-ID: <4C48BC74.4000906@gmail.com> Date: Thu, 22 Jul 2010 23:47:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> In-Reply-To: <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] [roll] #68: RPL security comments received during LC 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: , X-List-Received-Date: Thu, 22 Jul 2010 21:47:24 -0000 Le 22/07/2010 23:29, roll issue tracker a écrit : > #68: RPL security comments received during LC > -----------------------------+---------------------------------------------- > Reporter: jpv@… | Owner: pal@… > Type: defect | Status: closed > Priority: major | Milestone: > Component: rpl | Version: > Severity: In WG Last Call | Resolution: fixed > Keywords: | > -----------------------------+---------------------------------------------- > Changes (by jpv@…): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Answer in line SOrry - I don't see any answer... is it empty? Let me re-iterate my comments: Did the Security DT ask for WG approval of the security mechanism? Is this security mechanism output by the Security DT or by something-somebody else? Why not using IPsec AH? How was the security IPR disclosure agreed? I do not agree to the terms. I am surprised to see this closed, as if by magic. Alex > From pal@cs.stanford.edu Thu Jul 22 15:08:29 2010 Return-Path: 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 E41AA3A69E2 for ; Thu, 22 Jul 2010 15:08:29 -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=[AWL=0.000, 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 uIv4pUcYlNnm for ; Thu, 22 Jul 2010 15:08:29 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 10D7E3A6847 for ; Thu, 22 Jul 2010 15:08:29 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oc3wc-0007gt-Lh; Thu, 22 Jul 2010 15:08:46 -0700 In-Reply-To: <4C48BC74.4000906@gmail.com> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> <4C48BC74.4000906@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Levis Date: Thu, 22 Jul 2010 15:08:10 -0700 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: roll@ietf.org Subject: Re: [Roll] [roll] #68: RPL security comments received during LC 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: , X-List-Received-Date: Thu, 22 Jul 2010 22:08:30 -0000 On Jul 22, 2010, at 2:47 PM, Alexandru Petrescu wrote: > Le 22/07/2010 23:29, roll issue tracker a =E9crit : >> #68: RPL security comments received during LC >> -----------------------------=20 >> +---------------------------------------------- >> Reporter: jpv@=85 | Owner: pal@=85 >> Type: defect | Status: closed >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: In WG Last Call | Resolution: fixed >> Keywords: | >> -----------------------------=20 >> +---------------------------------------------- >> Changes (by jpv@=85): >> >> * status: new =3D> closed >> * resolution: =3D> fixed >> >> >> Comment: >> >> Answer in line > > SOrry - I don't see any answer... is it empty? > > Let me re-iterate my comments: > > Did the Security DT ask for WG approval of the security mechanism? > > Is this security mechanism output by the Security DT or by =20 > something-somebody else? > > Why not using IPsec AH? > > How was the security IPR disclosure agreed? I do not agree to the =20 > terms. > > I am surprised to see this closed, as if by magic. Alex -- sorry if this was unclear. #68 was supposed to refer to the =20 technical points on wording and ordering of cryptographic operations =20 from Michael Richardson and other WG members. The procedural =20 questions you raised on IPR are still open, and there should be a =20 message with answers to your questions later today, along with a =20 query for discussion among the WG on the best path forward. Phil= From pal@cs.stanford.edu Thu Jul 22 15:43:40 2010 Return-Path: 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 097093A6A6A for ; Thu, 22 Jul 2010 15:43:40 -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 SO2iHMVKgxJL for ; Thu, 22 Jul 2010 15:43:39 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 195B43A6A5C for ; Thu, 22 Jul 2010 15:43:39 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oc4Ue-00014L-Ki; Thu, 22 Jul 2010 15:43:56 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> Date: Thu, 22 Jul 2010 15:43:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com><12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com><5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Thu, 22 Jul 2010 22:43:40 -0000 On Jul 22, 2010, at 2:51 AM, Pascal Thubert (pthubert) wrote: > Phil: >=20 > I understand the CA/CD aspect. The group also understands that we need > to do something for this case. What we are being asked is really to > allow the opportunity to do something specific as opposed to MUST a = one > fits it all. Would you propose an alternate text that would have the > benefits of B) ? In my view, text that exposes a default behavior but > allows adaptations would be appreciated. It looks like there's consensus around option B: "Option B) * In section 7.3, change the third item of the list to read "When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior." * describe the L bit and RPL behavior in a separate I-D, together with the DIS option TLVs." With respect to updating the text, I think we can get away without = changing anything. Couldn't a future draft simply add a flag whose = predicate is always false? The way the current text is written, the = flags include the condition under which their predicate is true/false. = Does that make sense? Phil= From pal@cs.stanford.edu Thu Jul 22 16:40:55 2010 Return-Path: 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 2B3473A68FB for ; Thu, 22 Jul 2010 16:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 GUsKKpMKYsGM for ; Thu, 22 Jul 2010 16:40:54 -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 79F323A68B2 for ; Thu, 22 Jul 2010 16:40:52 -0700 (PDT) Received: from c-67-164-98-139.hsd1.ca.comcast.net ([67.164.98.139] helo=[192.168.1.105]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oc5Nu-00084X-Oo; Thu, 22 Jul 2010 16:41:05 -0700 From: Philip Levis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 16:41:00 -0700 Message-Id: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> To: roll WG Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Cc: seclln@external.cisco.com Subject: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Thu, 22 Jul 2010 23:40:55 -0000 Summary: This mail describes the current status of signature schemes in = RPL, presents three options for going forward, and asks the WG to = discuss and reach consensus on how to proceed. Background ------------- Currently RPL has a single security algorithm configuration: +-------+-------------------+--------------------------------------+ | ID | Encryption/MAC | Signature | +-------+-------------------+--------------------------------------+ | 0 | CCM* with AES-128 | ECPVS with K-283, Matyas-Meyer-Oseas | | 1-255 | Reserved | Reserved | +-------+-------------------+--------------------------------------+ The Signature scheme described is encumbered by IPR held by Certicom. = Rene, as a major contributor to the security parts of RPL, disclosed = this IPR through the standard IETF process. Rene does not currently work = for Certicom, although he did in the past. The particular scheme was = chosen because of its technical advantages in LLNs: short signatures = which are inexpensive to compute compared to many other signature = schemes. Going Forward -------------------------- The security DT sees three possible paths going forward: 1) Keep the Algorithm options as they are now: the only signature = scheme supported in the base RPL specification is encumbered by IPR. = Let's call this the "IPR" option. 2) Keep a single Algorithm (ID=3D0) in the base RPL specification, but = change Algorithm ID=3D0's signature scheme to one that we believe is = unencumbered by IPR. Let's call this the "No-IPR" option. 3) Keep the current Algorithm (ID=3D0), and add a second Algorithm = (ID=3D1) to have the same Encryption/MAC scheme as ID=3D0 (CCM* with = AES-128) but a signature scheme we believe is unencumbered by IPR. Let's = call this the "Both" option. We are currently investigating which signature scheme unencumbered by = IPR would best meet the requirements of LLNs. We expect to have reached = a conclusion on this by the end of this week. It's our opinion that = which exact algorithm is chosen should be considered independently of = the three options above (under the assumption that it is unencumbered by = IPR). Discussion ------------------- The security DT would like guidance from the WG on which of the three = options it should pursue. Given that we are in last call and are meeting = next week, let's try to keep the discussion focused and on-topic so we = can reach consensus quickly. Phil From pal@cs.stanford.edu Thu Jul 22 16:44:38 2010 Return-Path: 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 41A6A3A688C for ; Thu, 22 Jul 2010 16:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, 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 yIgCwnj4xKUC for ; Thu, 22 Jul 2010 16:44:36 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id A98203A6883 for ; Thu, 22 Jul 2010 16:44:36 -0700 (PDT) Received: from c-67-164-98-139.hsd1.ca.comcast.net ([67.164.98.139] helo=[192.168.1.105]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oc5RZ-0003dP-DI; Thu, 22 Jul 2010 16:44:54 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C48BC74.4000906@gmail.com> Date: Thu, 22 Jul 2010 16:44:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> <4C48BC74.4000906@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Cc: roll@ietf.org Subject: Re: [Roll] [roll] #68: RPL security comments received during LC 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: , X-List-Received-Date: Thu, 22 Jul 2010 23:44:38 -0000 On Jul 22, 2010, at 2:47 PM, Alexandru Petrescu wrote: >=20 > SOrry - I don't see any answer... is it empty? >=20 > Let me re-iterate my comments: >=20 > Did the Security DT ask for WG approval of the security mechanism? The security DT did not actively poll the WG: we considered -10 as a = draft to discuss (as we are doing now!). It is not set in stone: please = see my recent mail. >=20 > Is this security mechanism output by the Security DT or by = something-somebody else? Security DT. >=20 > Why not using IPsec AH? >=20 We've already had this discussion, which I thought we resolved. I can = replay a bunch of emails, but I'd rather keep this discussion on topic. > How was the security IPR disclosure agreed? I do not agree to the = terms. You don't know how the disclosure was made, or the terms of the IPR, but = don't agree to the terms? I don't understand. You seem to be objecting = blindly. Please keep your comments constructive. >=20 > I am surprised to see this closed, as if by magic. Again, please accept my apologies for the confusion on ticket #68 = closing. JP and I miscommunicated. The question of the signature schemes = in RPL is still open. Phil From mcr@sandelman.ca Thu Jul 22 16:57:10 2010 Return-Path: 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 602DD3A6981 for ; Thu, 22 Jul 2010 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6] 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 IG67NIzmJPOY for ; Thu, 22 Jul 2010 16:57:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3FA483A684F for ; Thu, 22 Jul 2010 16:57:09 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 473DC34698; Thu, 22 Jul 2010 19:57:26 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A51C098A06; Thu, 22 Jul 2010 19:55:07 -0400 (EDT) From: Michael Richardson To: roll WG , seclln@external.cisco.com In-Reply-To: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 22 Jul 2010 19:55:07 -0400 Message-ID: <7804.1279842907@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Thu, 22 Jul 2010 23:57:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Philip" == Philip Levis writes: Philip> The security DT sees three possible paths going forward: Philip> 1) Keep the Algorithm options as they are now: the only Philip> signature scheme supported in the base RPL specification is Philip> encumbered by IPR. Let's call this the "IPR" option. Philip> 2) Keep a single Algorithm (ID=0) in the base RPL Philip> specification, but change Algorithm ID=0's signature scheme Philip> to one that we believe is unencumbered by IPR. Let's call Philip> this the "No-IPR" option. Philip> 3) Keep the current Algorithm (ID=0), and add a second Philip> Algorithm (ID=1) to have the same Encryption/MAC scheme as Philip> ID=0 (CCM* with AES-128) but a signature scheme we believe Philip> is unencumbered by IPR. Let's call this the "Both" option. This is not a good explanation of the three options. a) we can always create another algorithm ID=1 as proposed by option (3). That's not what's important. What's important is whether or not ID=1 is MUST. You did not specify this, but I will assume that this is what you mean. Given that ID=1 will then become a MUST, you have not specified what will happen to ID=0 --- will it be a MUST or not? b) similarly, for option(2), we can always declare a new ID=n option with AES-CCM* + "IPR mode". The implicit assumption is that the No-IPR option will be a MUST, while some future ID=n option will be a MAY. So a better choice would be to present the working group with question: "Shall the only MUST signature algorithm be IPR-encumbered?" - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTEjaWoCLcPvd0N1lAQLISwf+Iyklzi3Q+uA5RBRgqdcdl4eUquc3mcb3 6oHpr/Xu/iOr2o3Sr8fpjAJs8zHF4XMheTaD+aRQt3oIkiEp5vcEOsDJsh7MayzP DDnPXVB7zODwxlLblASdQ/x4Ol/YsYWeWyQv7UHQyxgG2EMOzHzS3gz8MYqQlrfF hUg9y/makniiI1erU02DEn8jfEQwms7mnaev8E3sFHCsnRnlyXx/o3ha8HHSyMDR CQk9mY04AR9bBCCdXfgwub0SecmR1gK57vBo5riuGxoouqWzf0qzzo+aiMKkGAyE s07MfslXcqhZGSr47D/Y0pW6w7nAKPMfo1YAU0mJNzEVOog5MvyNHg== =6oWx -----END PGP SIGNATURE----- From mcr@sandelman.ca Thu Jul 22 16:59:35 2010 Return-Path: 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 914F13A6981 for ; Thu, 22 Jul 2010 16:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 nC3uZcvWICob for ; Thu, 22 Jul 2010 16:59:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id CCCB23A684F for ; Thu, 22 Jul 2010 16:59:34 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A9F533449E; Thu, 22 Jul 2010 19:59:52 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3417B98A06; Thu, 22 Jul 2010 19:57:34 -0400 (EDT) From: Michael Richardson To: roll WG , seclln@external.cisco.com In-Reply-To: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 22 Jul 2010 19:57:34 -0400 Message-ID: <7911.1279843054@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Thu, 22 Jul 2010 23:59:35 -0000 >>>>> "Philip" == Philip Levis writes: Philip> The security DT sees three possible paths going forward: Philip> 1) Keep the Algorithm options as they are now: the only Philip> signature scheme supported in the base RPL specification is Philip> encumbered by IPR. Let's call this the "IPR" option. Philip> 2) Keep a single Algorithm (ID=0) in the base RPL Philip> specification, but change Algorithm ID=0's signature scheme Philip> to one that we believe is unencumbered by IPR. Let's call Philip> this the "No-IPR" option. Philip> 3) Keep the current Algorithm (ID=0), and add a second Philip> Algorithm (ID=1) to have the same Encryption/MAC scheme as Philip> ID=0 (CCM* with AES-128) but a signature scheme we believe Philip> is unencumbered by IPR. Let's call this the "Both" option. I will answer on the assumption that: a) option 2 means marking ID=0, No-IPR option MUST, and any future IPR-option a MAY. 3b) option 3 means marking ID=1 MUST, and ID=0 MUST. 3c) option 3 means marking ID=1 MUST, and ID=0 MAY. My preferences are: (2) (3c) I consider (1) and (3c) to be completely un-acceptable. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pal@cs.stanford.edu Thu Jul 22 17:09:37 2010 Return-Path: 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 C1E703A695F for ; Thu, 22 Jul 2010 17:09:37 -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 ZwQdOkBlQDB2 for ; Thu, 22 Jul 2010 17:09:37 -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 F2F603A6883 for ; Thu, 22 Jul 2010 17:09:36 -0700 (PDT) Received: from c-67-164-98-139.hsd1.ca.comcast.net ([67.164.98.139] helo=[192.168.1.105]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oc5pq-0001i7-JB; Thu, 22 Jul 2010 17:09:54 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7804.1279842907@marajade.sandelman.ca> Date: Thu, 22 Jul 2010 17:09:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Fri, 23 Jul 2010 00:09:38 -0000 On Jul 22, 2010, at 4:55 PM, Michael Richardson wrote: >=20 >=20 > So a better choice would be to present the working group with = question: > "Shall the only MUST signature algorithm be IPR-encumbered?" >=20 > - -- Except, of course, that supporting signatures is not a MUST. It is = entirely acceptable, within the current specification, to have a RPL = implementation that supports only unsecured mode, just as it is = acceptable to have a RPL implementation that rejects all unsecured = messages.=20 This flexibility is because some LLNs have security mechanisms (e.g., = link layer) which can render the RPL ones superfluous, therefore = optional. One of the stated design goals from the beginning is that RPL = should not require security mechanisms when they are not needed. Phil= From jpv@cisco.com Thu Jul 22 23:57:37 2010 Return-Path: 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 D87C23A6AF9 for ; Thu, 22 Jul 2010 23:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BKsYU7aO-23b for ; Thu, 22 Jul 2010 23:57:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6FA103A6AF5 for ; Thu, 22 Jul 2010 23:57:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABraSEyrR7Hu/2dsb2JhbACfZnGlXpsNhTYEiGCCOocb Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 06:57:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6N6vq28019412; Fri, 23 Jul 2010 06:57:52 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 23:57:52 -0700 Received: from [192.168.1.12] ([10.66.255.138]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 23:57:50 -0700 Message-Id: <8987CC7C-C992-4E36-A5F5-F0811B01F848@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 08:57:46 +0200 References: <349A930D-DF59-45BD-A170-EE00D163B019@archrock.com><12509FBB-6C6B-4E8C-B776-FE1D6E977D82@archrock.com><5FACE3DF-48A6-43FD-8BB5-E3A193A30D69@cs.stanford.edu> <2F808880-7D4D-4C03-9D9E-02DD2DE889DB@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0260A881@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 06:57:51.0158 (UTC) FILETIME=[5DDC5D60:01CB2A34] Cc: roll WG Subject: Re: [Roll] Soliciting WG comments on DIS for RPL Last Call 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: , X-List-Received-Date: Fri, 23 Jul 2010 06:57:37 -0000 On Jul 23, 2010, at 12:43 AM, Philip Levis wrote: > > On Jul 22, 2010, at 2:51 AM, Pascal Thubert (pthubert) wrote: > >> Phil: >> >> I understand the CA/CD aspect. The group also understands that we >> need >> to do something for this case. What we are being asked is really to >> allow the opportunity to do something specific as opposed to MUST a >> one >> fits it all. Would you propose an alternate text that would have the >> benefits of B) ? In my view, text that exposes a default behavior but >> allows adaptations would be appreciated. > > It looks like there's consensus around option B: > > "Option B) > * In section 7.3, change the third item of the list to read "When a > node receives a multicast DIS with a Solicited Information option and > the node matches all of the predicates in the Solicited Information > option, unless a DIS flag restricts this behavior." > * describe the L bit and RPL behavior in a separate I-D, together with > the DIS option TLVs." > > With respect to updating the text, I think we can get away without > changing anything. Couldn't a future draft simply add a flag whose > predicate is always false? The way the current text is written, the > flags include the condition under which their predicate is true/ > false. Does that make sense? There may be room for mis-interpretation. I'd suggest to tweak the text a little bit though. Let me propose something in a few minutes in the ticket#71 and we will close. Thanks. JP. > > Phil From jpv@cisco.com Thu Jul 22 23:59:00 2010 Return-Path: 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 E8F4C3A6AA7 for ; Thu, 22 Jul 2010 23:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 b9y8Ek1wxnlg for ; Thu, 22 Jul 2010 23:58:59 -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 8C7153A699F for ; Thu, 22 Jul 2010 23:58:59 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABraSEytJV2a/2dsb2JhbACfZnGlXpsNhTYEiGCCOocb Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 06:59:17 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o6N6xGZX008566; Fri, 23 Jul 2010 06:59:16 GMT Received: from xfe-rcd-201.cisco.com ([72.163.62.204]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 01:59:16 -0500 Received: from [192.168.1.12] ([10.66.255.138]) by xfe-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 01:59:15 -0500 Message-Id: From: JP Vasseur To: Philip Levis , Alexandru Petrescu In-Reply-To: <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 08:59:10 +0200 References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> <4C48BC74.4000906@gmail.com> <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 06:59:15.0912 (UTC) FILETIME=[9060CC80:01CB2A34] Cc: roll WG Subject: Re: [Roll] [roll] #68: RPL security comments received during LC 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: , X-List-Received-Date: Fri, 23 Jul 2010 06:59:01 -0000 On Jul 23, 2010, at 1:44 AM, Philip Levis wrote: > > On Jul 22, 2010, at 2:47 PM, Alexandru Petrescu wrote: > >> >> SOrry - I don't see any answer... is it empty? >> >> Let me re-iterate my comments: >> >> Did the Security DT ask for WG approval of the security mechanism? > > The security DT did not actively poll the WG: we considered -10 as a > draft to discuss (as we are doing now!). It is not set in stone: > please see my recent mail. > > >> >> Is this security mechanism output by the Security DT or by >> something-somebody else? > > Security DT. > >> >> Why not using IPsec AH? >> > > We've already had this discussion, which I thought we resolved. I > can replay a bunch of emails, but I'd rather keep this discussion on > topic. > > >> How was the security IPR disclosure agreed? I do not agree to the >> terms. > > You don't know how the disclosure was made, or the terms of the IPR, > but don't agree to the terms? I don't understand. You seem to be > objecting blindly. Please keep your comments constructive. > > >> >> I am surprised to see this closed, as if by magic. > > Again, please accept my apologies for the confusion on ticket #68 > closing. JP and I miscommunicated. The question of the signature > schemes in RPL is still open. Yes, Ticket was re-opended. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Fri Jul 23 00:00:36 2010 Return-Path: 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 A5BEF3A6AF4 for ; Fri, 23 Jul 2010 00:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 7wN4JK-AgK5y for ; Fri, 23 Jul 2010 00:00:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 020763A6AA7 for ; Fri, 23 Jul 2010 00:00:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcCFZ-00051m-6M; Fri, 23 Jul 2010 00:00:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Fri, 23 Jul 2010 07:00:53 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/68#comment:2 Message-ID: <064.43b0aa33fb3627f1153a0981db5b8623@tools.ietf.org> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #68: RPL security comments received during LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 07:00:36 -0000 #68: RPL security comments received during LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: reopened Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: closed => reopened * resolution: fixed => -- Ticket URL: roll From jpv@cisco.com Fri Jul 23 00:17:32 2010 Return-Path: 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 C00D13A6AA8 for ; Fri, 23 Jul 2010 00:17:32 -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=[AWL=-4.001, 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 M9oqag8OVZRY for ; Fri, 23 Jul 2010 00:17:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 178E03A6AA6 for ; Fri, 23 Jul 2010 00:17:30 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngEAELfSExAaHtegWdsb2JhbACBRJ4iFQEBFiIipWObDoU2BIhggjo X-IronPort-AV: E=Sophos;i="4.55,246,1278288000"; d="scan'208,217";a="9259505" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 23 Jul 2010 06:34:20 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N7H63N000945 for ; Fri, 23 Jul 2010 07:17:46 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 12:47:13 +0530 Received: from [192.168.1.12] ([10.66.255.138]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 12:47:10 +0530 Message-Id: <4BF6F495-2184-4B64-9EF5-CEBA766D7F5F@cisco.com> From: JP Vasseur To: roll WG Content-Type: multipart/alternative; boundary=Apple-Mail-16-914516996 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 09:17:07 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 07:17:10.0930 (UTC) FILETIME=[11238720:01CB2A37] Subject: [Roll] Ticket#71 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: , X-List-Received-Date: Fri, 23 Jul 2010 07:17:32 -0000 --Apple-Mail-16-914516996 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Considering the wide consensus for option B, I have updated the text accordingly. This requires 3 changes. 1) New text in Section 7.3, third bullet: OLD: "o When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option." NEW: "o When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option (carried in the DIS option field) and/or (to be defined) fields of the Flag field are set." 2) DIS Packet Format OLD: "0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Winter, et al. Expires December 30, 2010 [Page 30] Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Figure 9: The DIS Base Object " NEW: "0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Winter, et al. Expires December 30, 2010 [Page 30] Internet-Draft draft-ietf-roll-rpl-10 Jun 2010 Figure 9: The DIS Base Object " 3) IANA Section to be added after 18.5. 18.6 New Registry for the DIS (DODAG Informational Solicitation) Flags IANA is requested to create a registry for the DIS (DODAG Informational Solicitation) Flag Field. New fields may be allocated only by an IETF Consensus action. Each field should be tracked with the following qualities: o Mode of Operation o Capability description o Defining RFC No flags are currently defined. Thanks. JP. --Apple-Mail-16-914516996 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Considering the wide consensus for option B, I = have updated the text accordingly.

This = requires 3 changes.

1) New text in Section 7.3, = third = bullet:

OLD:

"o When a node receives a multicast DIS with a Solicited = Information
      option and the node =
matches all of the predicates in the =
Solicited 
Information = option."

NEW:

"o When a node receives a multicast DIS with a Solicited = Information
   option and the node matches =
all of the predicates in the Solicited 
Information option (carried in the DIS option field) and/or = (to be
defined) fields of the Flag = field are set."

2) DIS Packet = Format

OLD:

"0 1 2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Reserved            |   Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Winter, et al.          =
Expires December 30, 2010              [Page 30]


NEW:

"0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Reserved      |     Flags     |   Option(s)...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Winter, et al.          =
Expires December 30, 2010              [Page 30]



3) =
IANA Section

to be added after =
18.5.

18.6 New Registry for the DIS =
(DODAG Informational Solicitation) Flags

IANA is requested =
to create a registry for the DIS (DODAG =
Informational 
Solicitation) 
New fields may be allocated only by an IETF Consensus action.  Each
field should be tracked with the following qualities:

   o  Mode of Operation

   o  Capability description

   o  Defining RFC

No flags are =
currently defined.

Thanks.

JP.

=

--Apple-Mail-16-914516996--

From trac@tools.ietf.org  Fri Jul 23 00:18:30 2010
Return-Path: 
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 E18833A6AA6 for ; Fri, 23 Jul 2010 00:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level: 
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 lG0EKJKNeZ46 for ; Fri, 23 Jul 2010 00:18:30 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0B8573A6AA7 for ; Fri, 23 Jul 2010 00:18:30 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcCWt-0003xN-BW; Fri, 23 Jul 2010 00:18:47 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "roll issue tracker" 
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: wintert@acm.org, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 23 Jul 2010 07:18:47 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/71#comment:1
Message-ID: <064.bcd6a4c05417b22aa7781dc3b01839fa@tools.ietf.org>
References: <055.50900f39e20babf74687f0e1e7779730@tools.ietf.org>
X-Trac-Ticket-ID: 71
In-Reply-To: <055.50900f39e20babf74687f0e1e7779730@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #71: DIS Behavior
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:18:31 -0000

#71: DIS Behavior
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  wintert@…      
     Type:  enhancement         |       Status:  closed         
 Priority:  major               |    Milestone:                 
Component:  rpl                 |      Version:                 
 Severity:  Active WG Document  |   Resolution:  fixed          
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Email from JP on July 23:


 Dear all,

 Considering the wide consensus for option B, I have updated the text
 accordingly.

 This requires 3 changes.

 1) New text in Section 7.3, third bullet:

 OLD:

 "o  When a node receives a multicast DIS with a Solicited Information
       option and the node matches all of the predicates in the Solicited
       Information option."

 NEW:

 "o  When a node receives a multicast DIS with a Solicited Information
    option and the node matches all of the predicates in the Solicited
    Information option (carried in the DIS option field) and/or (to be
    defined) fields of the Flag field are set."

 2) DIS Packet Format

 OLD:

 "0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           Reserved            |   Option(s)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Winter, et al.          Expires December 30, 2010              [Page 30]
 Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

                        Figure 9: The DIS Base Object
 "

 NEW:

 "0                   1                   2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Reserved      |     Flags     |   Option(s)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Winter, et al.          Expires December 30, 2010              [Page 30]
 Internet-Draft           draft-ietf-roll-rpl-10                 Jun 2010

                        Figure 9: The DIS Base Object
 "


 3) IANA Section

 to be added after 18.5.

 18.6 New Registry for the DIS (DODAG Informational Solicitation) Flags

 IANA is requested to create a registry for the DIS (DODAG Informational
 Solicitation) Flag Field.

 New fields may be allocated only by an IETF Consensus action.  Each
 field should be tracked with the following qualities:

    o  Mode of Operation

    o  Capability description

    o  Defining RFC

 No flags are currently defined.

 Thanks.

 JP.

-- 
Ticket URL: 
roll 


From alexandru.petrescu@gmail.com  Fri Jul 23 00:26:13 2010
Return-Path: 
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 822F23A6B01 for ; Fri, 23 Jul 2010 00:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level: 
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176,  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 9+UAKqyiUqmF for ; Fri, 23 Jul 2010 00:26:12 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF553A6B00 for ; Fri, 23 Jul 2010 00:26:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N7QNWA012821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 09:26:24 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N7QNY4024562; Fri, 23 Jul 2010 09:26:23 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N7QM3K011551; Fri, 23 Jul 2010 09:26:23 +0200
Message-ID: <4C49441F.6030608@gmail.com>
Date: Fri, 23 Jul 2010 09:26:23 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Philip Levis 
References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> <4C48BC74.4000906@gmail.com> <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu>
In-Reply-To: <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #68: RPL security  comments received during LC
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:26:13 -0000

Le 23/07/2010 01:44, Philip Levis a écrit :

>> Did the Security DT ask for WG approval of the security mechanism?
>
> The security DT did not actively poll the WG:

That is not good.  The WG should have been queried prior to inserting
Security DT output into a WG item.

> we considered -10 as a draft to discuss (as we are doing now!).

This is wrong.  One would have better ask the WG prior to inserting
Security DT output into a WG item.

I as part of the WG could very well disagree to insert that text as
such.  I actually do.

> It is not set in stone: please see my recent mail.

Ok, it would be good to know that the output of the Security DT is
subject to the WG approval.

>> Is this security mechanism output by the Security DT or by
>> something-somebody else?
>
> Security DT.

Ok.  It is strange because the Security DT had a document
http://tools.ietf.org/html/draft-ietf-roll-security-framework-00
and that does not mention CCM*.  Being so, one wonders how CCM* landed
into the RPL document... you say Security DT... ok, good to know.

>> Why not using IPsec AH?
>>
>
> We've already had this discussion, which I thought we resolved. I can
> replay a bunch of emails, but I'd rather keep this discussion on
> topic.

WEll some discussion happened but I didn't see agreement.  Private
discussion happened too and although there didn't seem to be large
agreement around IPsec AH - there was no strong agreement around the
current security method either.

>> How was the security IPR disclosure agreed?  I do not agree to the
>>  terms.
>
> You don't know how the disclosure was made,

I mean the disclosure made on this list, made according to IETF practice.

> or the terms of the IPR,

I do not know the terms used to license this IPR.  There are surely
licensing terms.  Not knowing them means to me I disagree with them.
They surely do exist.

> but don't agree to the terms? I don't understand. You seem to be
> objecting blindly.

You seem to  agree to them blindly - do you know them?

> Please keep your comments constructive.

YEs, I agree to keep them constructive - please make public the security
licensing terms and then ask whether we agree with them or not.  I think
this is constructive.

>> I am surprised to see this closed, as if by magic.
>
> Again, please accept my apologies for the confusion on ticket #68
> closing. JP and I miscommunicated. The question of the signature
> schemes in RPL is still open.

Ok, thanks, good to know.

Alex

>
> Phil
>



From alexandru.petrescu@gmail.com  Fri Jul 23 00:31:48 2010
Return-Path: 
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 A91FC3A6B0B for ; Fri, 23 Jul 2010 00:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.782
X-Spam-Level: 
X-Spam-Status: No, score=-1.782 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6]
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 FmDjHo7rYLeq for ; Fri, 23 Jul 2010 00:31:17 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 0F9543A67E3 for ; Fri, 23 Jul 2010 00:30:39 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N7UYdc015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Jul 2010 09:30:35 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N7UYOb025743 for ; Fri, 23 Jul 2010 09:30:34 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N7UYnU013100 for ; Fri, 23 Jul 2010 09:30:34 +0200
Message-ID: <4C49451A.1060007@gmail.com>
Date: Fri, 23 Jul 2010 09:30:34 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: roll@ietf.org
References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca>
In-Reply-To: <7804.1279842907@marajade.sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] Signature schemes consultation question
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:31:48 -0000

Le 23/07/2010 01:55, Michael Richardson a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>>>>>> "Philip" == Philip Levis  writes:
>      Philip>  The security DT sees three possible paths going forward:
>
>      Philip>    1) Keep the Algorithm options as they are now: the only
>      Philip>  signature scheme supported in the base RPL specification is
>      Philip>  encumbered by IPR. Let's call this the "IPR" option.
>
>      Philip>    2) Keep a single Algorithm (ID=0) in the base RPL
>      Philip>  specification, but change Algorithm ID=0's signature scheme
>      Philip>  to one that we believe is unencumbered by IPR. Let's call
>      Philip>  this the "No-IPR" option.
>
>      Philip>    3) Keep the current Algorithm (ID=0), and add a second
>      Philip>  Algorithm (ID=1) to have the same Encryption/MAC scheme as
>      Philip>  ID=0 (CCM* with AES-128) but a signature scheme we believe
>      Philip>  is unencumbered by IPR. Let's call this the "Both" option.
>
> This is not a good explanation of the three options.
>
> a) we can always create another algorithm ID=1 as proposed by option (3).
>     That's not what's important.
>     What's important is whether or not ID=1 is MUST.
>     You did not specify this, but I will assume that this is what you
>     mean.
>
>     Given that ID=1 will then become a MUST, you have not specified what
>     will happen to ID=0 --- will it be a MUST or not?
>
> b) similarly, for option(2), we can always declare a new ID=n
>     option with AES-CCM* + "IPR mode".
>     The implicit assumption is that the No-IPR option will be a MUST,
>     while some future ID=n option will be a MAY.
>
> So a better choice would be to present the working group with question:
>     "Shall the only MUST signature algorithm be IPR-encumbered?"

My answer to that question is - no, we should not MUST a signature 
algorithm IPR-encumbered.

Make the default IPR non-encumbered and add IPR'ed extensions.

And then we could also ask about the licensing terms - I guess they exist.

Alex


>
> - --
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
>     Kyoto Plus: watch the video
> 	then sign the petition.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBTEjaWoCLcPvd0N1lAQLISwf+Iyklzi3Q+uA5RBRgqdcdl4eUquc3mcb3
> 6oHpr/Xu/iOr2o3Sr8fpjAJs8zHF4XMheTaD+aRQt3oIkiEp5vcEOsDJsh7MayzP
> DDnPXVB7zODwxlLblASdQ/x4Ol/YsYWeWyQv7UHQyxgG2EMOzHzS3gz8MYqQlrfF
> hUg9y/makniiI1erU02DEn8jfEQwms7mnaev8E3sFHCsnRnlyXx/o3ha8HHSyMDR
> CQk9mY04AR9bBCCdXfgwub0SecmR1gK57vBo5riuGxoouqWzf0qzzo+aiMKkGAyE
> s07MfslXcqhZGSr47D/Y0pW6w7nAKPMfo1YAU0mJNzEVOog5MvyNHg==
> =6oWx
> -----END PGP SIGNATURE-----
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>



From alexandru.petrescu@gmail.com  Fri Jul 23 00:33:58 2010
Return-Path: 
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 8E64B3A67E3 for ; Fri, 23 Jul 2010 00:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level: 
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.174,  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 njWK5+5S0A0h for ; Fri, 23 Jul 2010 00:33:55 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 08DE13A679F for ; Fri, 23 Jul 2010 00:33:54 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N7YCoA026101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 23 Jul 2010 09:34:12 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N7YCNb027309 for ; Fri, 23 Jul 2010 09:34:12 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N7YBBt003460 for ; Fri, 23 Jul 2010 09:34:11 +0200
Message-ID: <4C4945F3.7060501@gmail.com>
Date: Fri, 23 Jul 2010 09:34:11 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: roll@ietf.org
References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu>	<7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu>
In-Reply-To: <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] Signature schemes consultation question
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:33:58 -0000

Le 23/07/2010 02:09, Philip Levis a écrit :
>
> On Jul 22, 2010, at 4:55 PM, Michael Richardson wrote:
>
>>
>>
>> So a better choice would be to present the working group with
>> question: "Shall the only MUST signature algorithm be
>> IPR-encumbered?"
>>
>> - --
>
>
> Except, of course, that supporting signatures is not a MUST. It is
> entirely acceptable, within the current specification, to have a RPL
> implementation that supports only unsecured mode, just as it is
> acceptable to have a RPL implementation that rejects all unsecured
> messages.

This may lead to a situation where the implementations of people who 
don't pay are unsecure... extrapolating, of course, but that sounds so.

It is not a good situation to be in.

And of course people who don't pay could design a default auth mechanism 
which could ensure enough security.

> This flexibility is because some LLNs have security mechanisms (e.g.,
> link layer) which can render the RPL ones superfluous, therefore
> optional.

I agree.  When link layer security is relied upon then we should state 
so, in the draft, with the names of the link layer security.

> One of the stated design goals from the beginning is that
> RPL should not require security mechanisms when they are not needed.

Is this reflected in the draft?

Alex

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



From navagar@cisco.com  Fri Jul 23 00:38:32 2010
Return-Path: 
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 93DC73A6B0B for ; Fri, 23 Jul 2010 00:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.841
X-Spam-Level: 
X-Spam-Status: No, score=-9.841 tagged_above=-999 required=5 tests=[AWL=0.758,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 au0zw5PQqewt for ; Fri, 23 Jul 2010 00:38:31 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 821493A67E3 for ; Fri, 23 Jul 2010 00:38:31 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGvkSExAaHte/2dsb2JhbACfZnGlbpsOhTYEhAOHFw
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 23 Jul 2010 07:38:49 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N7a5BQ015899 for ; Fri, 23 Jul 2010 07:38:48 GMT
Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 23 Jul 2010 13:08:45 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Jul 2010 13:08:45 +0530
Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01A32602@XMB-BGL-41C.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] New Version Notification for draft-ietf-roll-of0-02
Thread-Index: AcsCODQIBY+9hlmvT/2dcwiOliEeKQAABmnwCccccCAAGiDzQAAfH//g
References: <20100602094424.765143A6957@core3.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com>
From: "Navneet Agarwal (navagar)" 
To: "Pascal Thubert (pthubert)" , 
X-OriginalArrivalTime: 23 Jul 2010 07:38:45.0944 (UTC) FILETIME=[1506FB80:01CB2A3A]
Subject: Re: [Roll] New Version Notification for draft-ietf-roll-of0-02
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:38:32 -0000

Hi Pascal:
Ok

IIUC, the stretch allows you to select additional neighbors (as
siblings) and since they are not to be used at the moment, the stretch
is more of nop. Right?

Thx

Regards,
Navneet=20

> -----Original Message-----
> From: Pascal Thubert (pthubert)=20
> Sent: Thursday, July 22, 2010 10:17 PM
> To: Navneet Agarwal (navagar); 'roll@ietf.org'
> Subject: RE: [Roll] New Version Notification for=20
> draft-ietf-roll-of0-02
>=20
> Hi Navneet:
>=20
> The concept of sibling still exists, and at the moment the=20
> RPL spec does not specify how they can be used; in other=20
> words they cannot safely be used. You can thus see the=20
> stretch as a filter that filters out neighbors of low=20
> interest because they yield no forward progress. Does that make sense?
>=20
> Pascal
>=20
>=20
> > -----Original Message-----
> > From: Navneet Agarwal (navagar)
> > Sent: Thursday, July 22, 2010 6:27 AM
> > To: Pascal Thubert (pthubert); roll@ietf.org
> > Subject: RE: [Roll] New Version Notification for=20
> > draft-ietf-roll-of0-02
> >=20
> > Hi Pascal:
> > I have the following clarification on OF0-2:
> >=20
> > Section-3: The goal of stretching a rank is to allow a node=20
> to select=20
> > siblings if there is only one parent. Since the sibling has been=20
> > removed from the RPL spec, I am not sure the stretch logic=20
> of OF-0 is still applicable...can you pls clarify?
> >=20
> > Thx
> >=20
> > Regards,
> > Navneet
> >=20
> > > -----Original Message-----
> > > From: roll-bounces@ietf.org=20
> [mailto:roll-bounces@ietf.org] On Behalf=20
> > > Of Pascal Thubert (pthubert)
> > > Sent: Wednesday, June 02, 2010 3:19 PM
> > > To: roll@ietf.org
> > > Subject: Re: [Roll] New Version Notification for
> > > draft-ietf-roll-of0-02
> > >
> > > Hi:
> > >
> > > OF0-2 was just published. Limited changes include:
> > >
> > > -  make it very clear that only one octet of the rank is=20
> really used=20
> > > (from Zigbee's interop comments).
> > > - provide an abstraction of the interaction with the core spec=20
> > > (requested some time ago on the list) though not at an API level.
> > >
> > > Cheers,
> > >
> > > Pascal
> > >
> > >
> > > > -----Original Message-----
> > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> > > > Sent: Wednesday, June 02, 2010 11:44 AM
> > > > To: Pascal Thubert (pthubert)
> > > > Subject: New Version Notification for draft-ietf-roll-of0-02
> > > >
> > > >
> > > > A new version of I-D, draft-ietf-roll-of0-02.txt has been
> > > successfully
> > > > submitted by Pascal Thubert and posted to the IETF repository.
> > > >
> > > > Filename:	 draft-ietf-roll-of0
> > > > Revision:	 02
> > > > Title:		 RPL Objective Function 0
> > > > Creation_date:	 2010-06-02
> > > > WG ID:		 roll
> > > > Number_of_pages: 9
> > > >
> > > > Abstract:
> > > > The Routing Protocol for Low Power and Lossy Networks (RPL)
> > > defines a
> > > > generic Distance Vector protocol for Low Power and Lossy
> > > Networks (LLNs).
> > > > RPL is instantiated to honor a particular routing objective/=20
> > > > constraint by the adding a specific Objective Function=20
> (OF) that=20
> > > > is designed to solve that problem.  This specification=20
> defines a=20
> > > > basic OF, OF0, that uses only the abstract properties exposed in
> > > RPL messages to maximize connectivity.
> > > >
> > > >
> > > >
> > > > The IETF Secretariat.
> > > >
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > Roll@ietf.org
> > > https://www.ietf.org/mailman/listinfo/roll
> > >
>=20

From mdurvy@cisco.com  Fri Jul 23 00:49:05 2010
Return-Path: 
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 59C763A67E3 for ; Fri, 23 Jul 2010 00:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.268
X-Spam-Level: 
X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ofTvanC2iJZA for ; Fri, 23 Jul 2010 00:49:04 -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 5B6D13A69B3 for ; Fri, 23 Jul 2010 00:49:03 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: smime.p7s : 4100
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 07:49:21 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6N7nDbG005608; Fri, 23 Jul 2010 07:49:20 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 23 Jul 2010 09:49:20 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 23 Jul 2010 09:49:19 +0200
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008D_01CB2A4C.51CF91F0"
Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE02951562@XMB-AMS-103.cisco.com>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AB31@XMB-AMS-107.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Closing issue #58: Clarification on DAO
Thread-Index: AcspvNqzXQ9cQRvASNCpmlAz2dLkewAfXyRA
References: <6A2A459175DABE4BB11DE2026AA50A5D0260AB31@XMB-AMS-107.cisco.com>
From: "Mathilde Durvy (mdurvy)" 
To: "Pascal Thubert (pthubert)" , "roll WG" 
X-OriginalArrivalTime: 23 Jul 2010 07:49:20.0632 (UTC) FILETIME=[8F54AF80:01CB2A3B]
Subject: Re: [Roll] Closing issue #58: Clarification on DAO
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 07:49:05 -0000

This is a multipart message in MIME format.

------=_NextPart_000_008D_01CB2A4C.51CF91F0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Pascal,

So essentially we don't mandate anything in terms of processing =
DAO-ACKs. Correct?

Concerning the question "When should a node initiate (i.e. not =
propagate) an increase in DTSN?" are you going to add some text?
If nothing is mandated there as well, it means that nodes could decide =
never to increment their DTSN and hence send a DAO only when they change =
of DAO parent.=20

This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK are =
used but nothing is done when they are not received. What do you think?

Best,
Mathilde

-----Original Message-----
From: Pascal Thubert (pthubert)=20
Sent: jeudi, 22. juillet 2010 18:42
To: roll WG
Cc: JP Vasseur (jpv@cisco.com); Mathilde Durvy (mdurvy)
Subject: Closing issue #58: Clarification on DAO

Dear WG

I think we can close 58. 11 will have the following changes:

>  - =E2=80=9CMulticast DAOs MUST NOT include Transit Information =
options=E2=80=9D (Section
> 8.6). Do you mean =E2=80=9CMUST not include a parent address in the =
transit
> information option=E2=80=9D?

Corrected along the proposal


>  - Section 16.2.6 (which deals with configuration) introduces some  =
terminology
> not used in the spec (e.g UNREACHABLE state). Is this some  legacy =
text?

Legacy text removed.

>  - What actions need to be taken by a node that didn=E2=80=99t get a =
DAO-ACK  response
> when setting the K bit?

The text leaves that to implementation. Should not retry indefinitely =
though!

If anybody opposes to close along the above line please speak up : )

Pascal


> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =
Of roll
> issue tracker
> Sent: Tuesday, July 13, 2010 11:14 AM
> To: jpv@cisco.com
> Cc: roll@ietf.org
> Subject: [Roll] [roll] #58: Clarification on DAO
>=20
> #58: Clarification on DAO
> =
-----------------------------+------------------------------------------
> -----------------------------+----
>  Reporter:  jpv@=E2=80=A6            |       Owner:
>      Type:  enhancement      |      Status:  new
>  Priority:  major            |   Milestone:
> Component:  rpl              |     Version:
>  Severity:  In WG Last Call  |    Keywords:
> =
-----------------------------+------------------------------------------
> -----------------------------+----
>  Hello Mathilde
>=20
>  - What is the DAO parent selection criteria for OCP0? Same as for DIO =
 parents
> I assume.
>  [Pascal] OF0 only mandates one preferred parent with good enough
> bidirectional connectivity, and it enables a backup if one is =
available.
>  So yes, there=E2=80=99s little choice but pick it as DAO parent as =
well. The draft  could
> have an additional sentence to say that I admit.
>=20
>  - What actions need to be taken by a node that didn=E2=80=99t get a =
DAO-ACK  response
> when setting the K bit?
>  [Pascal] We have to refine that text in 11 for sure. Only new =
information  is
> sent asynchronously to the DAO parents while the full information is  =
sent in
> demand (upon DTSN or new version). In short, the rich  implementation =
can
> maintain per parent what was acknowledged and flag it  as not new. The
> constrained implementation sends the delta once and flag  it as not =
new
> without an ack, waiting for the next full information to  fill the =
gaps. So
> basically when something new is learnt, the storing  router arms a =
timer to
> schedule a DAO. When the timer elapses, the router  sends all new =
information
> to the parents. The timer keeps elapsing for a  given parent till the =
parent acks
> the most recent DAO sequence sent to it  or the router gives up. If =
the router
> gives up, the parent is out of sync  till the next change or full =
information
> updates it. The path sequence  that circulates via other parents that =
are not out
> of sync is fresher and  enables the ancestors to select the usable =
path.
>=20
>  - Section 16.2.6 (which deals with configuration) introduces some  =
terminology
> not used in the spec (e.g UNREACHABLE state). Is this some  legacy =
text?
>  [Pascal] It is. That state was in the FSM that went down the sink =
around
>  08
>=20
>  - When should a node initiate (i.e. not propagate) an increase in =
DTSN?
>  [Pascal] Can be upon an inconsistency detection, or upon an internal =
timer  per
> policy though that is not mandated. An inconsistency can be an RPF  =
check, a
> DAO entry not revalidated, a datapath validation failure. New  DSTN =
should be
> caped in time.
>=20
>  - =E2=80=9CMulticast DAOs MUST NOT include Transit Information =
options=E2=80=9D (Section
> 8.6). Do you mean =E2=80=9CMUST not include a parent address in the =
transit
> information option=E2=80=9D?
>  [Pascal] Oups! Correct. We sometime need the lifetime.
>=20
>  Best,
>=20
>  Pascal
>=20
> --
> Ticket URL: 
> roll 
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

------=_NextPart_000_008D_01CB2A4C.51CF91F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww
ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD
VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs
aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea
BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg
1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg
+u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs
PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8
WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz
NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl
ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL
wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi
8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3
otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ
iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f
ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4
RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E
BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl
TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo
MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB
gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT
i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV
67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN
AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl
ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH
MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp
c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc
BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx
IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq
hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2
hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M
PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU
pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB
BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD
AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw
Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ
KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq
jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo
xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa
4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH
6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB
8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB
GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTEwMDcyMzA3NDkxOFowIwYJKoZIhvcNAQkEMRYEFAXwaicUQ+Z2tVLo
JyB5e9wbA/cXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF
MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m
IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz
b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT
dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB
8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB
GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGAWFOWt/AsnkAEuHj7YxCu1ANkcPc/PNid
y6GuTRUmeexBONIW94B99LTqdK/xsXkrjjHW9H0UQ/EsFtMgKEzUBw/JvkMqojXvqcRdQiQGYETB
80LS0KfgMMDarBVMno+wqhCOdrx4CpWyi9rfKpc57WvQNcgbKPOGfVH/tFMlcA8AAAAAAAA=

------=_NextPart_000_008D_01CB2A4C.51CF91F0--

From jpv@cisco.com  Fri Jul 23 01:09:14 2010
Return-Path: 
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 900E23A698F for ; Fri, 23 Jul 2010 01:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.598
X-Spam-Level: 
X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 MMVRkcNOE5QF for ; Fri, 23 Jul 2010 01:09:13 -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 900493A6B08 for ; Fri, 23 Jul 2010 01:09:13 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPrqSExAaHte/2dsb2JhbACBRJ4icaVWmwiFNgSIYII6
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2010 08:09:31 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N89UwH008364 for ; Fri, 23 Jul 2010 08:09:30 GMT
Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 23 Jul 2010 13:39:30 +0530
Received: from [192.168.1.12] ([10.66.255.138]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:39:28 +0530
Message-Id: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com>
From: JP Vasseur 
To: roll WG 
Content-Type: multipart/alternative; boundary=Apple-Mail-24-917654304
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 23 Jul 2010 10:09:24 +0200
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 23 Jul 2010 08:09:28.0935 (UTC) FILETIME=[5F891770:01CB2A3E]
Subject: [Roll] Route-tags - Soliciting WG comments
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 08:09:14 -0000

--Apple-Mail-24-917654304
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Dear all,

This is one of the comments that I send last week (ticket 70). We had  
a discussion with the RPL authors yesterday (as pretty much every  
week) to continue our work on the remaining open tickets (making great  
progress). Let me simply explain why "route-tags" may be important to  
have in the core spec. First of all, I'd like to clarify that we are  
not discussing about using tags/labels for forwarding (we will at some  
point !) so I'll start using the terms prefix-color to avoid  
ambiguity. We had the concept of route-color (called route-tags) up to  
revision -7, at which point we revisited the whole DAO format and it  
went away.

Why is it used for ?

Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS),  
that is used to mark a route. For example, this could be used to flag  
important versus less-critical prefix. This has proven to be useful in  
a number of other routing protocols but to give two examples: this can  
be used to prioritize prefix installation during DODAG rebuilt to  
increase the "convergence" time and restore connectivity faster for  
critical prefixes, it could also be used in case of memory overflow to  
preferably keep the important prefix, ...

Complexity ?

Nothing more than an option carried in a DAO message that could look  
like this:

  0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |   Type = 8    |       2       |               
Flags            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

We just need to add one sentence in the Manageability Section.

We could either defer it to another ID or add it now. Personally I am  
leaning toward adding it back, considering how simple it is and the  
benefits this can bring.

Could you let us know whether you think that we should add it to the  
core spec:

1) Yes
2) No.

Thanks.

JP.
--Apple-Mail-24-917654304
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Dear =
all,

This is one of the comments that I send last =
week (ticket 70). We had a discussion with the RPL authors yesterday (as =
pretty much every week) to continue our work on the remaining open =
tickets (making great progress). Let me simply explain why "route-tags" =
may be important to have in the core spec. First of all, I'd like to =
clarify that we are not discussing about using tags/labels for =
forwarding (we will at some point !) so I'll start using the terms =
prefix-color to avoid ambiguity. We had the concept of route-color =
(called route-tags) up to revision -7, at which point we revisited the =
whole DAO format and it went away.

Why is =
it used for ?

Route-colors is just an x =
bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. =
For example, this could be used to flag important versus less-critical =
prefix. This has proven to be useful in a number of other routing =
protocols but to give two examples: this can be used to prioritize =
prefix installation during DODAG rebuilt to increase the "convergence" =
time and restore connectivity faster for critical prefixes, it could =
also be used in case of memory overflow to preferably keep the important =
prefix, ... 

Complexity =
?

Nothing more than an option carried =
in a DAO message that could look like =
this:

 0                   1           =
        2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 8    |       2       |              Flags            =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We just need to add one sentence in the =
Manageability Section.

We could either defer it =
to another ID or add it now. Personally I am leaning toward adding it =
back, considering how simple it is and the benefits this can =
bring.

Could you let us know whether you think =
that we should add it to the core spec:

1) =
Yes
2) =
No.

Thanks.

JP.
=

--Apple-Mail-24-917654304--

From navagar@cisco.com  Fri Jul 23 01:12:34 2010
Return-Path: 
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 3C2F03A699F for ; Fri, 23 Jul 2010 01:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.936
X-Spam-Level: 
X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.662,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 YGTdAO9HfVeK for ; Fri, 23 Jul 2010 01:12:33 -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 2F49C3A67F1 for ; Fri, 23 Jul 2010 01:12:33 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2010 08:12:50 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N8Cmhd010652; Fri, 23 Jul 2010 08:12:49 GMT
Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 23 Jul 2010 13:42:49 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2A3E.D7140DAA"
Date: Fri, 23 Jul 2010 13:42:49 +0530
Message-ID: <3EF472F4AD7D824EA24D3197C56B61DB01A3260E@XMB-BGL-41C.cisco.com>
In-Reply-To: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Roll] Route-tags - Soliciting WG comments
Thread-Index: AcsqPnIvfkCMgPa3R2CvIapIkg1uFQAAEjuw
References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com>
From: "Navneet Agarwal (navagar)" 
To: "JP Vasseur" , "roll WG" 
X-OriginalArrivalTime: 23 Jul 2010 08:12:49.0835 (UTC) FILETIME=[D747FFB0:01CB2A3E]
Subject: Re: [Roll] Route-tags - Soliciting WG comments
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: , 
X-List-Received-Date: Fri, 23 Jul 2010 08:12:34 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB2A3E.D7140DAA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi JP:
Yes for me
=20
Would be useful in future.
=20
Regards,
Navneet


________________________________

	From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On
Behalf Of JP Vasseur
	Sent: Friday, July 23, 2010 1:39 PM
	To: roll WG
	Subject: [Roll] Route-tags - Soliciting WG comments
=09
=09
	Dear all,=20

	This is one of the comments that I send last week (ticket 70).
We had a discussion with the RPL authors yesterday (as pretty much every
week) to continue our work on the remaining open tickets (making great
progress). Let me simply explain why "route-tags" may be important to
have in the core spec. First of all, I'd like to clarify that we are not
discussing about using tags/labels for forwarding (we will at some point
!) so I'll start using the terms prefix-color to avoid ambiguity. We had
the concept of route-color (called route-tags) up to revision -7, at
which point we revisited the whole DAO format and it went away.

	Why is it used for ?

	Route-colors is just an x bit flag field (e.g. RPC 5130 for
ISIS), that is used to mark a route. For example, this could be used to
flag important versus less-critical prefix. This has proven to be useful
in a number of other routing protocols but to give two examples: this
can be used to prioritize prefix installation during DODAG rebuilt to
increase the "convergence" time and restore connectivity faster for
critical prefixes, it could also be used in case of memory overflow to
preferably keep the important prefix, ...=20

	Complexity ?

	Nothing more than an option carried in a DAO message that could
look like this:

=09
	 0                   1                   2                   3
	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	       |   Type =3D 8    |       2       |              Flags
|
=09
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	We just need to add one sentence in the Manageability Section.

	We could either defer it to another ID or add it now. Personally
I am leaning toward adding it back, considering how simple it is and the
benefits this can bring.

	Could you let us know whether you think that we should add it to
the core spec:

	1) Yes
	2) No.

	Thanks.

	JP.


------_=_NextPart_001_01CB2A3E.D7140DAA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi JP:
Yes for me


 


Would be useful in future.


 


Regards,


Navneet



  

  

  From: roll-bounces@ietf.org=20
  [mailto:roll-bounces@ietf.org] On Behalf Of JP =
Vasseur
Sent:=20
  Friday, July 23, 2010 1:39 PM
To: roll WG
Subject: =
[Roll]=20
  Route-tags - Soliciting WG comments


  
Dear all,
  


  
This is one of the comments that I send last week (ticket 70). We =
had a=20
  discussion with the RPL authors yesterday (as pretty much every week) =
to=20
  continue our work on the remaining open tickets (making great =
progress). Let=20
  me simply explain why "route-tags" may be important to have in the =
core spec.=20
  First of all, I'd like to clarify that we are not discussing about =
using=20
  tags/labels for forwarding (we will at some point !) so I'll start =
using the=20
  terms prefix-color to avoid ambiguity. We had the concept of =
route-color=20
  (called route-tags) up to revision -7, at which point we revisited the =
whole=20
  DAO format and it went away.

  


  
Why is it used for ?

  


  
Route-colors is just an x bit flag field (e.g. RPC 5130 for =
ISIS), that=20
  is used to mark a route. For example, this could be used to flag =
important=20
  versus less-critical prefix. This has proven to be useful in a number =
of other=20
  routing protocols but to give two examples: this can be used to =
prioritize=20
  prefix installation during DODAG rebuilt to increase the "convergence" =
time=20
  and restore connectivity faster for critical prefixes, it could also =
be used=20
  in case of memory overflow to preferably keep the important prefix,=20
  ... 

  


  
Complexity ?

  


  
Nothing more than an option carried in a DAO message that could =
look like=20
  this:

  


  
 0                   1                   2  =
                 3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 8    |       2       |              Flags            =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  


  
We just need to add one sentence in the Manageability =
Section.

  


  
We could either defer it to another ID or add it now. Personally =
I am=20
  leaning toward adding it back, considering how simple it is and the =
benefits=20
  this can bring.

  


  
Could you let us know whether you think that we should add it to =
the core=20
  spec:

  


  
1) Yes

  
2) No.

  


  
Thanks.

  


  
JP.
------_=_NextPart_001_01CB2A3E.D7140DAA-- From jpv@cisco.com Fri Jul 23 01:17:12 2010 Return-Path: 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 258DC3A6B31 for ; Fri, 23 Jul 2010 01:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0sqaH1ay7mZR for ; Fri, 23 Jul 2010 01:16:48 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6DE4D3A6841 for ; Fri, 23 Jul 2010 01:16:43 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACHtSEyrR7Hu/2dsb2JhbACfZnGlV5sHhTYEiGCCOg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 08:17:01 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6N8H1f7027582 for ; Fri, 23 Jul 2010 08:17:01 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 01:17:01 -0700 Received: from [192.168.1.12] ([10.66.255.138]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jul 2010 01:16:59 -0700 Message-Id: From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE02951562@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 10:16:55 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D0260AB31@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE02951562@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 08:17:00.0245 (UTC) FILETIME=[6C898850:01CB2A3F] Cc: roll WG Subject: Re: [Roll] Closing issue #58: Clarification on DAO 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: , X-List-Received-Date: Fri, 23 Jul 2010 08:17:12 -0000 On Jul 23, 2010, at 9:49 AM, Mathilde Durvy (mdurvy) wrote: > Hi Pascal, > > So essentially we don't mandate anything in terms of processing DAO-=20= > ACKs. Correct? > Correct. > Concerning the question "When should a node initiate (i.e. not =20 > propagate) an increase in DTSN?" are you going to add some text? > If nothing is mandated there as well, it means that nodes could =20 > decide never to increment their DTSN and hence send a DAO only when =20= > they change of DAO parent. > Q for Pascal. > This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK =20 > are used but nothing is done when they are not received. What do you =20= > think? > I don't think that we need to specify an algorithm here. We provide =20 the mechanism, the rest is implementation specific (as in many other =20 protocols). Thanks. JP. > Best, > Mathilde > > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: jeudi, 22. juillet 2010 18:42 > To: roll WG > Cc: JP Vasseur (jpv@cisco.com); Mathilde Durvy (mdurvy) > Subject: Closing issue #58: Clarification on DAO > > Dear WG > > I think we can close 58. 11 will have the following changes: > >> - =93Multicast DAOs MUST NOT include Transit Information =20 >> options=94 (Section >> 8.6). Do you mean =93MUST not include a parent address in the transit >> information option=94? > > Corrected along the proposal > > >> - Section 16.2.6 (which deals with configuration) introduces some =20= >> terminology >> not used in the spec (e.g UNREACHABLE state). Is this some legacy =20= >> text? > > Legacy text removed. > >> - What actions need to be taken by a node that didn=92t get a DAO-=20 >> ACK response >> when setting the K bit? > > The text leaves that to implementation. Should not retry =20 > indefinitely though! > > If anybody opposes to close along the above line please speak up : ) > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Tuesday, July 13, 2010 11:14 AM >> To: jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #58: Clarification on DAO >> >> #58: Clarification on DAO >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Reporter: jpv@=85 | Owner: >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: In WG Last Call | Keywords: >> -----------------------------=20 >> +------------------------------------------ >> -----------------------------+---- >> Hello Mathilde >> >> - What is the DAO parent selection criteria for OCP0? Same as for =20 >> DIO parents >> I assume. >> [Pascal] OF0 only mandates one preferred parent with good enough >> bidirectional connectivity, and it enables a backup if one is =20 >> available. >> So yes, there=92s little choice but pick it as DAO parent as well. =20= >> The draft could >> have an additional sentence to say that I admit. >> >> - What actions need to be taken by a node that didn=92t get a DAO-=20 >> ACK response >> when setting the K bit? >> [Pascal] We have to refine that text in 11 for sure. Only new =20 >> information is >> sent asynchronously to the DAO parents while the full information =20 >> is sent in >> demand (upon DTSN or new version). In short, the rich =20 >> implementation can >> maintain per parent what was acknowledged and flag it as not new. =20= >> The >> constrained implementation sends the delta once and flag it as not =20= >> new >> without an ack, waiting for the next full information to fill the =20= >> gaps. So >> basically when something new is learnt, the storing router arms a =20= >> timer to >> schedule a DAO. When the timer elapses, the router sends all new =20 >> information >> to the parents. The timer keeps elapsing for a given parent till =20 >> the parent acks >> the most recent DAO sequence sent to it or the router gives up. If =20= >> the router >> gives up, the parent is out of sync till the next change or full =20 >> information >> updates it. The path sequence that circulates via other parents =20 >> that are not out >> of sync is fresher and enables the ancestors to select the usable =20= >> path. >> >> - Section 16.2.6 (which deals with configuration) introduces some =20= >> terminology >> not used in the spec (e.g UNREACHABLE state). Is this some legacy =20= >> text? >> [Pascal] It is. That state was in the FSM that went down the sink =20 >> around >> 08 >> >> - When should a node initiate (i.e. not propagate) an increase in =20 >> DTSN? >> [Pascal] Can be upon an inconsistency detection, or upon an =20 >> internal timer per >> policy though that is not mandated. An inconsistency can be an RPF =20= >> check, a >> DAO entry not revalidated, a datapath validation failure. New DSTN =20= >> should be >> caped in time. >> >> - =93Multicast DAOs MUST NOT include Transit Information =20 >> options=94 (Section >> 8.6). Do you mean =93MUST not include a parent address in the transit >> information option=94? >> [Pascal] Oups! Correct. We sometime need the lifetime. >> >> Best, >> >> Pascal >> >> -- >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Fri Jul 23 01:19:17 2010 Return-Path: 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 003D53A6841 for ; Fri, 23 Jul 2010 01:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 WxKlVt0lr82L for ; Fri, 23 Jul 2010 01:19:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 23BEC3A6B46 for ; Fri, 23 Jul 2010 01:19:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcDTi-0007xj-6v; Fri, 23 Jul 2010 01:19:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Fri, 23 Jul 2010 08:19:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/72 Message-ID: <055.4b3b3ff8ad95c59b535425683e961cf4@tools.ietf.org> X-Trac-Ticket-ID: 72 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #72: Prefix-color X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:19:17 -0000 #72: Prefix-color --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Dear all, This is one of the comments that I send last week (ticket 70). We had a discussion with the RPL authors yesterday (as pretty much every week) to continue our work on the remaining open tickets (making great progress). Let me simply explain why "route-tags" may be important to have in the core spec. First of all, I'd like to clarify that we are not discussing about using tags/labels for forwarding (we will at some point !) so I'll start using the terms prefix-color to avoid ambiguity. We had the concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away. Why is it used for ? Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. For example, this could be used to flag important versus less-critical prefix. This has proven to be useful in a number of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, it could also be used in case of memory overflow to preferably keep the important prefix, ... Complexity ? Nothing more than an option carried in a DAO message that could look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | 2 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We just need to add one sentence in the Manageability Section. We could either defer it to another ID or add it now. Personally I am leaning toward adding it back, considering how simple it is and the benefits this can bring. Could you let us know whether you think that we should add it to the core spec: 1) Yes 2) No. Thanks. JP. _____________ -- Ticket URL: roll From pthubert@cisco.com Fri Jul 23 02:16:02 2010 Return-Path: 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 1EBF13A68DD for ; Fri, 23 Jul 2010 02:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kHiLyt1tmAri for ; Fri, 23 Jul 2010 02:16:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D606E3A6B29 for ; Fri, 23 Jul 2010 02:15:59 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACb7SEyrRN+K/2dsb2JhbACDIJtlYXGldIk2kVGBJoMdcwSLGg Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 09:16:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6N9G9en011634 for ; Fri, 23 Jul 2010 09:16:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:16:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 23 Jul 2010 11:16:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AC8A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resolving #59: Request for clarification: Transit information option thread-index: Acspu4eBJyRjK1AGSf6sAuTEHIQ36QAiih/wAAB0RXA= From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 23 Jul 2010 09:16:13.0247 (UTC) FILETIME=[B24A9CF0:01CB2A47] Subject: [Roll] FW: Resolving #59: Request for clarification: Transit information option 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: , X-List-Received-Date: Fri, 23 Jul 2010 09:16:02 -0000 DQpEZWFyIFdHDQoNCg0KVGhlIGZvbGxvd2luZyB0ZXh0IGlzIHByb3Bvc2VkIHRvIGNsYXJpZnkg UlBMIGZvciBpc3N1ZSA1OToNCg0KLSBFQ01QIGlzIGFkZGVkIGZvciBpc3N1ZSAjNjAgYnkgcGFp cmluZyBwYXRoIGNvbnRyb2wgYml0cy4NCi0gU29tZSB0ZXh0IG9uIHBhdGggc2VxdWVuY2UgaXMg YWRkZWQgZm9yIGlzc3VlICM1NQ0KLSB0ZXh0IG9uIGxpZmV0aW1lIGlzIGFkZGVkIGZvciBpc3N1 ZSAjNTYNCg0KIklmIGEgbm9kZSBzZW5kcyBhIERBTyBtZXNzYWdlIHRvIG9uZSBEQU8gcGFyZW50 LCBpdCBNVVNUIHNlbmQgYQ0KICAgICAgICAgICAgREFPIHdpdGggdGhlIHNhbWUgU2VxdWVuY2Ug dG8gYWxsIG90aGVyIERBTyBwYXJlbnRzLiINCg0KV2FzIGF0IHRoZSB3cm9uZyBwbGFjZS4gSXQg Z29lcyBhd2F5IGJ1dCBpcyByZXBsYWNlZCBlbHNld2hlcmUgd2l0aCB0aGlzDQoNCiJQYXRoIFNl cXVlbmNlOiAgVGhpcyBzZXF1ZW5jZSBjb3VudGVyIGlzIHByZXNlbnQgaW4NCiAgICAgICAgICAg IHRoZSBUcmFuc2l0IEluZm9ybWF0aW9uIG9wdGlvbiBpbiBhIERBTyBtZXNzYWdlLiBUaGUgcHVy cG9zZSBvZg0KICAgICAgICAgICAgdGhpcyBjb3VudGVyIGlzIHRvIGRpZmZlcmVudGlhdGUgYSBt b3ZlbWVudCB3aGVyZSBhIG5ld2VyIHJvdXRlDQogICAgICAgICAgICBzdXBlcnNlZGVzIGEgc3Rh bGUgb25lIGZyb20gYSByb3V0ZSByZWR1bmRhbmN5IHNjZW5hcmlvIHdoZXJlDQogICAgICAgICAg ICBtdWx0aXBsZSByb3V0ZXMgZXhpc3QgaW4gcGFyYWxsZWwgZm9yIGEgc2FtZSB0YXJnZXQuIFRo ZSBQYXRoDQogICAgICAgICAgICBTZXF1ZW5jZSBpcyBnbG9iYWxseSBzaWduaWZpY2FudCBpbiBh IERPREFHIGFuZCBpbmRpY2F0ZXMgdGhlDQogICAgICAgICAgICBmcmVzaG5lc3Mgb2YgdGhlIHJv dXRlIHRvIHRoZSBhc3NvY2lhdGVkIHRhcmdldC4gQW4gb2xkZXIgKGxlc3NlcikNCiAgICAgICAg ICAgIHZhbHVlIHJlY2VpdmVkIGZyb20gYW4gb3JpZ2luYXRpbmcgcm91dGVyIGluZGljYXRlcyB0 aGF0IHRoZQ0KICAgICAgICAgICAgb3JpZ2luYXRpbmcgcm91dGVyIGhvbGRzIHN0YWxlIHJvdXRp bmcgc3RhdGVzIGFuZCB0aGUgb3JpZ2luYXRpbmcNCiAgICAgICAgICAgIHJvdXRlciBzaG91bGQg bm90IGJlIGNvbnNpZGVyZWQgYW55bW9yZSBhcyBhIHBvdGVudGlhbCBuZXh0LWhvcA0KICAgICAg ICAgICAgZm9yIHRoZSB0YXJnZXQuIFRoZSBQYXRoIFNlcXVlbmNlIGlzIGNvbXB1dGVkIGJ5IHRo ZSBub2RlIHRoYXQNCiAgICAgICAgICAgIGFkdmVydGlzZXMgdGhlIHRhcmdldCwgdGhhdCBpcyB0 aGUgdGFyZ2V0IGl0c2VsZiBvciBhIHJvdXRlciB0aGF0DQogICAgICAgICAgICBhZHZlcnRpc2Vz IGEgdGFyZ2V0IG9uIGJlaGFsZiBvZiBhIGhvc3QsIGFuZCBpcyB1bmNoYW5nZWQgYXMgdGhlDQog ICAgICAgICAgICBEQU8gY29udGVudCBpcyBwcm9wYWdhdGVkIHRvd2FyZHMgdGhlIHJvb3QgYnkg cGFyZW50IHJvdXRlcnMuIElmIGENCiAgICAgICAgICAgIGhvc3QgZG9lcyBub3QgcGFzcyBhIGNv dW50ZXIgdG8gaXRzIHJvdXRlciwgdGhlbiB0aGUgcm91dGVyIGlzIGluDQogICAgICAgICAgICBj aGFyZ2Ugb2YgY29tcHV0aW5nIHRoZSBQYXRoIFNlcXVlbmNlIG9uIGJlaGFsZiBvZiB0aGUgaG9z dCBhbmQNCiAgICAgICAgICAgIHRoZSBob3N0IGNhbiBvbmx5IHJlZ2lzdGVyIHRvIG9uZSByb3V0 ZXIgZm9yIHRoYXQgcHVycG9zZS4gSWYgYQ0KICAgICAgICAgICAgREFPIG1lc3NhZ2UgY29udGFp bmluZyBhIHNhbWUgdGFyZ2V0IGlzIGlzc3VlZCB0byBtdWx0aXBsZSBwYXJlbnRzDQogICAgICAg ICAgICBhdCBhIGdpdmVuIHBvaW50IG9mIHRpbWUgZm9yIHRoZSBwdXJwb3NlIG9mIHJvdXRlIHJl ZHVuZGFuY3ksIHRoZW4NCiAgICAgICAgICAgIHRoZSBQYXRoIFNlcXVlbmNlIGlzIHRoZSBzYW1l IGluIGFsbCB0aGUgREFPIG1lc3NhZ2VzIGZvciB0aGF0DQogICAgICAgICAgICBzYW1lIHRhcmdl dC4iDQoNCkFsc28NCg0KICAgICAgICAgICJGb3IgYSBUYXJnZXQgdGhhdCBpcyBhc3NvY2lhdGVk IHdpdGggKG93bmVkIGJ5KSBhIG5vZGUsIHRoYXQgbm9kZQ0KICAgICAgICAgIE1BWSBpbmNyZW1l bnQgdGhlIFBhdGggU2VxdWVuY2UgY291bnRlciwgYW5kIGdlbmVyYXRlIGEgbmV3IERBTw0KICAg ICAgICAgIG1lc3NhZ2UsIG9uIG9jY2FzaW9uIGluIG9yZGVyIHRvIHJlZnJlc2ggdGhlIGRvd253 YXJkIHJvdXRpbmcNCiAgICAgICAgICBpbmZvcm1hdGlvbi4gSW4gc3RvcmluZyBtb2RlLCB0aGUg bm9kZSBnZW5lcmF0ZXMgc3VjaCBEQU8gdG8gZWFjaCBvZiANCiAgICAgICAgICBpdHMgREFPIHBh cmVudHMgaW4gb3JkZXIgdG8gZW5hYmxlIG11bHRpcGF0aC4NCiAgICAgICAgICBBbGwgREFPcyBn ZW5lcmF0ZWQgYXQgdGhlIHNhbWUgdGltZSBmb3IgYSBzYW1lIHRhcmdldCBNVVNUIGJlIHNlbnQN CiAgICAgICAgICB3aXRoIHRoZSBzYW1lIHBhdGggc2VxdWVuY2UgaW4gdGhlIHRyYW5zaXQgaW5m b3JtYXRpb24uIg0KDQpUZXh0IG9uIHBhdGggc2VxdWVuY2UgYW5kIERBTyBzZXF1ZW5jZSBpcyBy ZXZpc2l0ZWQuDQoNClRoZSBwYXRoIGNvbnRyb2wgdGV4dCBpcyBzbGlnaHRseSBpbmNyZW1lbnRl ZDoNCg0KICAgICAgICIgV2hlbiBhIG5vZGUgc2VuZHMgYSBEQU8gdG8gb25lIG9mIGl0cyBEQU8g cGFyZW50cywgaXQgTVVTVCBzZWxlY3QNCiAgICAgICBvbmUgb3IgbW9yZSBvZiB0aGUgc2V0LCBh Y3RpdmUgYml0cyBpbiB0aGUgYWdncmVnYXRlZCBQYXRoDQogICAgICAgQ29udHJvbCBmaWVsZC4g IFRoZSBEQU8gaXQgdHJhbnNtaXRzIHRvIGl0cyBwYXJlbnQgTVVTVCBoYXZlDQogICAgICAgdGhl c2UgYWN0aXZlIGJpdHMgc2V0IGFuZCBhbGwgb3RoZXIgYWN0aXZlIGJpdHMgY2xlYXJlZC4iDQoN CkJlY29tZXMNCg0KICAgICAgICAgICAiV2hlbiBhIG5vZGUgc2VuZHMgYSBEQU8gbWVzc2FnZSB0 byBvbmUgb2YgaXRzIERBTyBwYXJlbnRzLCBpdA0KICAgICAgICAgICAgTVVTVCBzZWxlY3Qgb25l IG9yIG1vcmUgb2YgdGhlIGJpdHMgdGhhdCBhcmUgc2V0IGFjdGl2ZSBpbiB0aGUgYWdncmVnYXRl ZA0KICAgICAgICAgICAgUGF0aCBDb250cm9sIGZpZWxkIHRvIGFkdmVydGlzZSB0byBhIHRoYXQg cGFyZW50LiBBIGdpdmVuIGJpdCBjYW4NCiAgICAgICAgICAgIG9ubHkgYmUgcHJlc2VudGVkIGFz IGFjdGl2ZSB0byBvbmUgcGFyZW50LiBUaGUgREFPIG1lc3NhZ2UgaXQNCiAgICAgICAgICAgIHRy YW5zbWl0cyB0byBpdHMgcGFyZW50IE1VU1QgaGF2ZSB0aGVzZSBhY3RpdmUgYml0cyBzZXQgYW5k IGFsbA0KICAgICAgICAgICAgb3RoZXIgYWN0aXZlIGJpdHMgY2xlYXJlZC4iDQoNCklmIHlvdSBo YXZlIGFuIGlzc3VlIHdpdGggdGhpcyByZXNvbHV0aW9uIHBsZWFzZSBjaGltZSBpbiA6ICkNCg0K UGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiByb2xsIGlz c3VlIHRyYWNrZXIgW21haWx0bzp0cmFjQHRvb2xzLmlldGYub3JnXQ0KPiBTZW50OiBUdWVzZGF5 LCBKdWx5IDEzLCAyMDEwIDE6MjIgUE0NCj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7 IGpwdkBjaXNjby5jb20NCj4gQ2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3JvbGxdICM1 OTogUmVxdWVzdCBmb3IgY2xhcmlmaWNhdGlvbjogVHJhbnNpdCBpbmZvcm1hdGlvbiANCj4gb3B0 aW9uDQo+IA0KPiAjNTk6IFJlcXVlc3QgZm9yIGNsYXJpZmljYXRpb246IFRyYW5zaXQgaW5mb3Jt YXRpb24gb3B0aW9uDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLQ0KPiAgUmVwb3J0 ZXI6ICBqcHZA4oCmICAgICAgICAgICAgfCAgICAgICBPd25lcjogIHB0aHViZXJ0QOKApg0KPiAg ICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCj4gIFByaW9y aXR5OiAgbWFqb3IgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBycGwg ICAgICAgICAgICAgIHwgICAgIFZlcnNpb246DQo+ICBTZXZlcml0eTogIEluIFdHIExhc3QgQ2Fs bCAgfCAgICBLZXl3b3JkczoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSstLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tDQo+ICBF bWFpbCBmcm9tIE1hdGhpbGRlIE9uIEp1bHkgOToNCj4gDQo+ICBGcm9tOiByb2xsLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2Yg TWF0aGlsZGUgRHVydnkgKG1kdXJ2eSkNCj4gIFNlbnQ6IHZlbmRyZWRpLCA5LiBqdWlsbGV0IDIw MTAgMTU6MTcNCj4gIFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyBST0xMIFdHDQo+ICBT dWJqZWN0OiBSZTogW1JvbGxdIEZXOiBUcmFuc2l0IGluZm9ybWF0aW9uIG9wdGlvbg0KPiANCj4g IEhpIFBhc2NhbCwNCj4gDQo+ICBUaGFua3MgYWdhaW4gZm9yIHlvdXIgcmVwbHkuIFdoYXQgeW91 IHNheSBtYWtlcyBzZW5zZSBhbHRob3VnaCBJIA0KPiBzdGlsbCAgdGhpbmsgdGhhdCB0aGUgc2Vw YXJhdGlvbiBvZiB0aGUgZmllbGRzIGJldHdlZW4gdGhlIHRhcmdldCBhbmQgDQo+IHRyYW5zaXQg IG9wdGlvbnMgaXMgc29tZXdoYXQgYXJiaXRyYXJ5IEogSG93ZXZlciB0aGlzIGlzIG5vdCBhIG1h am9yIA0KPiBpc3N1ZSBhbmQgIG1heWJlIGF0IHRoaXMgcG9pbnQgaXTigJlzIG1vcmUgaW1wb3J0 YW50IHRvIGNsYXJpZnkgdGhlIA0KPiBzcGVjcyB3aXRoIHJlc3BlY3QgIHRvIHRoZSBtZWFuaW5n IC8gdXNhZ2Ugb2YgdGhlIHBhdGggc2VxdWVuY2UsIGNvbnRyb2wsIGFuZCBsaWZldGltZS4NCj4g IC0gSW4gc3RvcmluZyBtb2RlLCB0aGUgcGF0aCBjb250cm9sIGlzIHVzZWQgdG8gbGltaXQgdGhl IERBTyBmYW4tb3V0LiANCj4gSXQgIGNhbiBhbHNvIGJlIHVzZWQgdG8gc2V0IGEgcHJlZmVyZW5j ZSBiZXR3ZWVuIHJvdXRlcyB3aXRoIHRoZSANCj4gbGltaXRhdGlvbiAgdGhhdCBpdCBjYW5ub3Qg c3BlY2lmeSB0d28gcm91dGVzIHdoaWNoIGFyZSBlcXVhbGx5IA0KPiBwcmVmZXJyZWQgKHNpbmNl IHBhdGggIGNvbnRyb2wgYml0cyBzZW50IHRvIGRpZmZlcmVudCBwYXJlbnRzIGhhdmUgdG8gYmUg ZGlzam9pbnQpLg0KPiAgLSBJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBwYXRoIGNvbnRyb2wgdXNh Z2UgaXMgaW5jb21wYXRpYmxlIHdpdGggdGhlIA0KPiBzZW50ZW5jZSDigJxJZiBhIG5vZGUgc2Vu ZHMgYSBEQU8gdG8gb25lIERBTyBwYXJlbnQsIGl0IE1VU1Qgc2VuZCBhIERBTyANCj4gd2l0aCAg dGhlIHNhbWUgREFPU2VxdWVuY2UgdG8gYWxsIG90aGVyIERBTyBwYXJlbnRz4oCdLiBObz8NCj4g IC0gSW4gdGhlIG5vbiBzdG9yaW5nIG1vZGUsIHRoZSBwYXRoIGNvbnRyb2wgaXMgbm90IHVzZWQg dG8gbGltaXQgdGhlIA0KPiBEQU8gIGZhbi1vdXQgYXMgbm9kZXMgc2VuZCBEQU9zIHRvIG9ubHkg b25lIG9mIHRoZWlyIERBTyBwYXJlbnRzLiBJIA0KPiBndWVzcyBpdCAgY2FuIGJlIHVzZWQgYXMg YSBwcmVmZXJlbmNlIGJ5IHRoZSByb290IHdoZW4gaXQgY29tcHV0ZXMgdGhlIHNvdXJjZSAgcm91 dGVzLg0KPiAgLSBIb3cgaXMgdGhlIHBhdGggc2VxdWVuY2UgcHJvY2Vzc2VkPyBHaXZlbiB0aGF0 IHdlIGhhdmUgYWxyZWFkeSBhIA0KPiBEQU8gc2VxdWVuY2UgaXMgaXQgcG9zc2libGUgdG8gcmVj ZWl2ZSBhIHN0YWxlIHBhdGggc2VxdWVuY2U/IElzbuKAmXQgaXQgIHJlZHVuZGFudD8NCj4gIC0g V2hhdCBkb2VzIHRoZSBsaWZldGltZSByZXByZXNlbnQgY29uY3JldGVseT8gSXMgaXQgYSBtZWFz dXJlIG9mIHRoZSANCj4gbGlmZXRpbWUgb2YgdGhlIGxpbmsgYmV0d2VlbiB0aGUgdGFyZ2V0IGFu ZCB0aGUgdHJhbnNpdD8NCj4gDQo+ICBJdOKAmXMgYSBsb3Qgb2YgcXVlc3Rpb25zLCBidXQgSSBo b3BlIGl0IHdpbGwgaGVscCBtYWtlIHRoZSBEQU8gcGFydCANCj4gY2xlYXJlciAgdG8gZXZlcnli b2R5IQ0KPiANCj4gIEJlc3QsDQo+ICBNYXRoaWxkZQ0KPiANCj4gLS0NCj4gVGlja2V0IFVSTDog PGh0dHBzOi8vc3ZuLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvNTk+DQo+IHJv bGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCg0K From pthubert@cisco.com Fri Jul 23 02:19:16 2010 Return-Path: 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 41EAA3A69B5 for ; Fri, 23 Jul 2010 02:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Cs3TOemSUo0l for ; Fri, 23 Jul 2010 02:19:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F4D63A6816 for ; Fri, 23 Jul 2010 02:19:15 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANr7SEyrR7Ht/2dsb2JhbACDIJtlYXGldok2kVKBJoMdcwSLGg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 23 Jul 2010 09:19:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N9JDgu006883 for ; Fri, 23 Jul 2010 09:19:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:19:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 23 Jul 2010 11:19:17 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AC8D@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] FW: Resolving #59: Request for clarification: Transitinformation option thread-index: AcsqSB9+2qaT2rFwQ3SbCxkBPT+Zag== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 23 Jul 2010 09:19:21.0795 (UTC) FILETIME=[22ACC130:01CB2A48] Subject: Re: [Roll] FW: Resolving #59: Request for clarification: Transitinformation option 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: , X-List-Received-Date: Fri, 23 Jul 2010 09:19:16 -0000 RXJyYXR1bToNCg0KLSB0ZXh0IG9uIGxpZmV0aW1lIGlzIGFkZGVkIGZvciBpc3N1ZSAjNjcNCg0K U29ycnksDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YNCj4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiBTZW50OiBGcmlkYXks IEp1bHkgMjMsIDIwMTAgMTE6MTYgQU0NCj4gVG86IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDog W1JvbGxdIEZXOiBSZXNvbHZpbmcgIzU5OiBSZXF1ZXN0IGZvciBjbGFyaWZpY2F0aW9uOiBUcmFu c2l0aW5mb3JtYXRpb24NCj4gb3B0aW9uDQo+IA0KPiANCj4gRGVhciBXRw0KPiANCj4gDQo+IFRo ZSBmb2xsb3dpbmcgdGV4dCBpcyBwcm9wb3NlZCB0byBjbGFyaWZ5IFJQTCBmb3IgaXNzdWUgNTk6 DQo+IA0KPiAtIEVDTVAgaXMgYWRkZWQgZm9yIGlzc3VlICM2MCBieSBwYWlyaW5nIHBhdGggY29u dHJvbCBiaXRzLg0KPiAtIFNvbWUgdGV4dCBvbiBwYXRoIHNlcXVlbmNlIGlzIGFkZGVkIGZvciBp c3N1ZSAjNTUNCj4gLSB0ZXh0IG9uIGxpZmV0aW1lIGlzIGFkZGVkIGZvciBpc3N1ZSAjNTYNCj4g DQo+ICJJZiBhIG5vZGUgc2VuZHMgYSBEQU8gbWVzc2FnZSB0byBvbmUgREFPIHBhcmVudCwgaXQg TVVTVCBzZW5kIGENCj4gICAgICAgICAgICAgREFPIHdpdGggdGhlIHNhbWUgU2VxdWVuY2UgdG8g YWxsIG90aGVyIERBTyBwYXJlbnRzLiINCj4gDQo+IFdhcyBhdCB0aGUgd3JvbmcgcGxhY2UuIEl0 IGdvZXMgYXdheSBidXQgaXMgcmVwbGFjZWQgZWxzZXdoZXJlIHdpdGggdGhpcw0KPiANCj4gIlBh dGggU2VxdWVuY2U6ICBUaGlzIHNlcXVlbmNlIGNvdW50ZXIgaXMgcHJlc2VudCBpbg0KPiAgICAg ICAgICAgICB0aGUgVHJhbnNpdCBJbmZvcm1hdGlvbiBvcHRpb24gaW4gYSBEQU8gbWVzc2FnZS4g VGhlIHB1cnBvc2Ugb2YNCj4gICAgICAgICAgICAgdGhpcyBjb3VudGVyIGlzIHRvIGRpZmZlcmVu dGlhdGUgYSBtb3ZlbWVudCB3aGVyZSBhIG5ld2VyIHJvdXRlDQo+ICAgICAgICAgICAgIHN1cGVy c2VkZXMgYSBzdGFsZSBvbmUgZnJvbSBhIHJvdXRlIHJlZHVuZGFuY3kgc2NlbmFyaW8gd2hlcmUN Cj4gICAgICAgICAgICAgbXVsdGlwbGUgcm91dGVzIGV4aXN0IGluIHBhcmFsbGVsIGZvciBhIHNh bWUgdGFyZ2V0LiBUaGUgUGF0aA0KPiAgICAgICAgICAgICBTZXF1ZW5jZSBpcyBnbG9iYWxseSBz aWduaWZpY2FudCBpbiBhIERPREFHIGFuZCBpbmRpY2F0ZXMgdGhlDQo+ICAgICAgICAgICAgIGZy ZXNobmVzcyBvZiB0aGUgcm91dGUgdG8gdGhlIGFzc29jaWF0ZWQgdGFyZ2V0LiBBbiBvbGRlciAo bGVzc2VyKQ0KPiAgICAgICAgICAgICB2YWx1ZSByZWNlaXZlZCBmcm9tIGFuIG9yaWdpbmF0aW5n IHJvdXRlciBpbmRpY2F0ZXMgdGhhdCB0aGUNCj4gICAgICAgICAgICAgb3JpZ2luYXRpbmcgcm91 dGVyIGhvbGRzIHN0YWxlIHJvdXRpbmcgc3RhdGVzIGFuZCB0aGUgb3JpZ2luYXRpbmcNCj4gICAg ICAgICAgICAgcm91dGVyIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBhbnltb3JlIGFzIGEgcG90 ZW50aWFsIG5leHQtaG9wDQo+ICAgICAgICAgICAgIGZvciB0aGUgdGFyZ2V0LiBUaGUgUGF0aCBT ZXF1ZW5jZSBpcyBjb21wdXRlZCBieSB0aGUgbm9kZSB0aGF0DQo+ICAgICAgICAgICAgIGFkdmVy dGlzZXMgdGhlIHRhcmdldCwgdGhhdCBpcyB0aGUgdGFyZ2V0IGl0c2VsZiBvciBhIHJvdXRlciB0 aGF0DQo+ICAgICAgICAgICAgIGFkdmVydGlzZXMgYSB0YXJnZXQgb24gYmVoYWxmIG9mIGEgaG9z dCwgYW5kIGlzIHVuY2hhbmdlZCBhcyB0aGUNCj4gICAgICAgICAgICAgREFPIGNvbnRlbnQgaXMg cHJvcGFnYXRlZCB0b3dhcmRzIHRoZSByb290IGJ5IHBhcmVudCByb3V0ZXJzLiBJZiBhDQo+ICAg ICAgICAgICAgIGhvc3QgZG9lcyBub3QgcGFzcyBhIGNvdW50ZXIgdG8gaXRzIHJvdXRlciwgdGhl biB0aGUgcm91dGVyIGlzIGluDQo+ICAgICAgICAgICAgIGNoYXJnZSBvZiBjb21wdXRpbmcgdGhl IFBhdGggU2VxdWVuY2Ugb24gYmVoYWxmIG9mIHRoZSBob3N0IGFuZA0KPiAgICAgICAgICAgICB0 aGUgaG9zdCBjYW4gb25seSByZWdpc3RlciB0byBvbmUgcm91dGVyIGZvciB0aGF0IHB1cnBvc2Uu IElmIGENCj4gICAgICAgICAgICAgREFPIG1lc3NhZ2UgY29udGFpbmluZyBhIHNhbWUgdGFyZ2V0 IGlzIGlzc3VlZCB0byBtdWx0aXBsZSBwYXJlbnRzDQo+ICAgICAgICAgICAgIGF0IGEgZ2l2ZW4g cG9pbnQgb2YgdGltZSBmb3IgdGhlIHB1cnBvc2Ugb2Ygcm91dGUgcmVkdW5kYW5jeSwgdGhlbg0K PiAgICAgICAgICAgICB0aGUgUGF0aCBTZXF1ZW5jZSBpcyB0aGUgc2FtZSBpbiBhbGwgdGhlIERB TyBtZXNzYWdlcyBmb3IgdGhhdA0KPiAgICAgICAgICAgICBzYW1lIHRhcmdldC4iDQo+IA0KPiBB bHNvDQo+IA0KPiAgICAgICAgICAgIkZvciBhIFRhcmdldCB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0 aCAob3duZWQgYnkpIGEgbm9kZSwgdGhhdCBub2RlDQo+ICAgICAgICAgICBNQVkgaW5jcmVtZW50 IHRoZSBQYXRoIFNlcXVlbmNlIGNvdW50ZXIsIGFuZCBnZW5lcmF0ZSBhIG5ldyBEQU8NCj4gICAg ICAgICAgIG1lc3NhZ2UsIG9uIG9jY2FzaW9uIGluIG9yZGVyIHRvIHJlZnJlc2ggdGhlIGRvd253 YXJkIHJvdXRpbmcNCj4gICAgICAgICAgIGluZm9ybWF0aW9uLiBJbiBzdG9yaW5nIG1vZGUsIHRo ZSBub2RlIGdlbmVyYXRlcyBzdWNoIERBTyB0byBlYWNoIG9mDQo+ICAgICAgICAgICBpdHMgREFP IHBhcmVudHMgaW4gb3JkZXIgdG8gZW5hYmxlIG11bHRpcGF0aC4NCj4gICAgICAgICAgIEFsbCBE QU9zIGdlbmVyYXRlZCBhdCB0aGUgc2FtZSB0aW1lIGZvciBhIHNhbWUgdGFyZ2V0IE1VU1QgYmUg c2VudA0KPiAgICAgICAgICAgd2l0aCB0aGUgc2FtZSBwYXRoIHNlcXVlbmNlIGluIHRoZSB0cmFu c2l0IGluZm9ybWF0aW9uLiINCj4gDQo+IFRleHQgb24gcGF0aCBzZXF1ZW5jZSBhbmQgREFPIHNl cXVlbmNlIGlzIHJldmlzaXRlZC4NCj4gDQo+IFRoZSBwYXRoIGNvbnRyb2wgdGV4dCBpcyBzbGln aHRseSBpbmNyZW1lbnRlZDoNCj4gDQo+ICAgICAgICAiIFdoZW4gYSBub2RlIHNlbmRzIGEgREFP IHRvIG9uZSBvZiBpdHMgREFPIHBhcmVudHMsIGl0IE1VU1Qgc2VsZWN0DQo+ICAgICAgICBvbmUg b3IgbW9yZSBvZiB0aGUgc2V0LCBhY3RpdmUgYml0cyBpbiB0aGUgYWdncmVnYXRlZCBQYXRoDQo+ ICAgICAgICBDb250cm9sIGZpZWxkLiAgVGhlIERBTyBpdCB0cmFuc21pdHMgdG8gaXRzIHBhcmVu dCBNVVNUIGhhdmUNCj4gICAgICAgIHRoZXNlIGFjdGl2ZSBiaXRzIHNldCBhbmQgYWxsIG90aGVy IGFjdGl2ZSBiaXRzIGNsZWFyZWQuIg0KPiANCj4gQmVjb21lcw0KPiANCj4gICAgICAgICAgICAi V2hlbiBhIG5vZGUgc2VuZHMgYSBEQU8gbWVzc2FnZSB0byBvbmUgb2YgaXRzIERBTyBwYXJlbnRz LCBpdA0KPiAgICAgICAgICAgICBNVVNUIHNlbGVjdCBvbmUgb3IgbW9yZSBvZiB0aGUgYml0cyB0 aGF0IGFyZSBzZXQgYWN0aXZlIGluIHRoZQ0KPiBhZ2dyZWdhdGVkDQo+ICAgICAgICAgICAgIFBh dGggQ29udHJvbCBmaWVsZCB0byBhZHZlcnRpc2UgdG8gYSB0aGF0IHBhcmVudC4gQSBnaXZlbiBi aXQgY2FuDQo+ICAgICAgICAgICAgIG9ubHkgYmUgcHJlc2VudGVkIGFzIGFjdGl2ZSB0byBvbmUg cGFyZW50LiBUaGUgREFPIG1lc3NhZ2UgaXQNCj4gICAgICAgICAgICAgdHJhbnNtaXRzIHRvIGl0 cyBwYXJlbnQgTVVTVCBoYXZlIHRoZXNlIGFjdGl2ZSBiaXRzIHNldCBhbmQgYWxsDQo+ICAgICAg ICAgICAgIG90aGVyIGFjdGl2ZSBiaXRzIGNsZWFyZWQuIg0KPiANCj4gSWYgeW91IGhhdmUgYW4g aXNzdWUgd2l0aCB0aGlzIHJlc29sdXRpb24gcGxlYXNlIGNoaW1lIGluIDogKQ0KPiANCj4gUGFz Y2FsDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IHJv bGwgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWNAdG9vbHMuaWV0Zi5vcmddDQo+ID4gU2VudDog VHVlc2RheSwgSnVseSAxMywgMjAxMCAxOjIyIFBNDQo+ID4gVG86IFBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCk7IGpwdkBjaXNjby5jb20NCj4gPiBDYzogcm9sbEBpZXRmLm9yZw0KPiA+IFN1Ympl Y3Q6IFtyb2xsXSAjNTk6IFJlcXVlc3QgZm9yIGNsYXJpZmljYXRpb246IFRyYW5zaXQgaW5mb3Jt YXRpb24NCj4gPiBvcHRpb24NCj4gPg0KPiA+ICM1OTogUmVxdWVzdCBmb3IgY2xhcmlmaWNhdGlv bjogVHJhbnNpdCBpbmZvcm1hdGlvbiBvcHRpb24NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSstLS0tDQo+ID4gIFJlcG9ydGVyOiAganB2QOKApiAgICAgICAgICAgIHwgICAgICAg T3duZXI6ICBwdGh1YmVydEDigKYNCj4gPiAgICAgIFR5cGU6ICBlbmhhbmNlbWVudCAgICAgIHwg ICAgICBTdGF0dXM6ICBuZXcNCj4gPiAgUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgIHwgICBN aWxlc3RvbmU6DQo+ID4gQ29tcG9uZW50OiAgcnBsICAgICAgICAgICAgICB8ICAgICBWZXJzaW9u Og0KPiA+ICBTZXZlcml0eTogIEluIFdHIExhc3QgQ2FsbCAgfCAgICBLZXl3b3JkczoNCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0NCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tDQo+ID4gIEVtYWlsIGZyb20gTWF0aGls ZGUgT24gSnVseSA5Og0KPiA+DQo+ID4gIEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gT2YgTWF0aGlsZGUgRHVy dnkgKG1kdXJ2eSkNCj4gPiAgU2VudDogdmVuZHJlZGksIDkuIGp1aWxsZXQgMjAxMCAxNToxNw0K PiA+ICBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgUk9MTCBXRw0KPiA+ICBTdWJqZWN0 OiBSZTogW1JvbGxdIEZXOiBUcmFuc2l0IGluZm9ybWF0aW9uIG9wdGlvbg0KPiA+DQo+ID4gIEhp IFBhc2NhbCwNCj4gPg0KPiA+ICBUaGFua3MgYWdhaW4gZm9yIHlvdXIgcmVwbHkuIFdoYXQgeW91 IHNheSBtYWtlcyBzZW5zZSBhbHRob3VnaCBJDQo+ID4gc3RpbGwgIHRoaW5rIHRoYXQgdGhlIHNl cGFyYXRpb24gb2YgdGhlIGZpZWxkcyBiZXR3ZWVuIHRoZSB0YXJnZXQgYW5kDQo+ID4gdHJhbnNp dCAgb3B0aW9ucyBpcyBzb21ld2hhdCBhcmJpdHJhcnkgSiBIb3dldmVyIHRoaXMgaXMgbm90IGEg bWFqb3INCj4gPiBpc3N1ZSBhbmQgIG1heWJlIGF0IHRoaXMgcG9pbnQgaXTigJlzIG1vcmUgaW1w b3J0YW50IHRvIGNsYXJpZnkgdGhlDQo+ID4gc3BlY3Mgd2l0aCByZXNwZWN0ICB0byB0aGUgbWVh bmluZyAvIHVzYWdlIG9mIHRoZSBwYXRoIHNlcXVlbmNlLCBjb250cm9sLCBhbmQNCj4gbGlmZXRp bWUuDQo+ID4gIC0gSW4gc3RvcmluZyBtb2RlLCB0aGUgcGF0aCBjb250cm9sIGlzIHVzZWQgdG8g bGltaXQgdGhlIERBTyBmYW4tb3V0Lg0KPiA+IEl0ICBjYW4gYWxzbyBiZSB1c2VkIHRvIHNldCBh IHByZWZlcmVuY2UgYmV0d2VlbiByb3V0ZXMgd2l0aCB0aGUNCj4gPiBsaW1pdGF0aW9uICB0aGF0 IGl0IGNhbm5vdCBzcGVjaWZ5IHR3byByb3V0ZXMgd2hpY2ggYXJlIGVxdWFsbHkNCj4gPiBwcmVm ZXJyZWQgKHNpbmNlIHBhdGggIGNvbnRyb2wgYml0cyBzZW50IHRvIGRpZmZlcmVudCBwYXJlbnRz IGhhdmUgdG8gYmUNCj4gZGlzam9pbnQpLg0KPiA+ICAtIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl IHBhdGggY29udHJvbCB1c2FnZSBpcyBpbmNvbXBhdGlibGUgd2l0aCB0aGUNCj4gPiBzZW50ZW5j ZSDigJxJZiBhIG5vZGUgc2VuZHMgYSBEQU8gdG8gb25lIERBTyBwYXJlbnQsIGl0IE1VU1Qgc2Vu ZCBhIERBTw0KPiA+IHdpdGggIHRoZSBzYW1lIERBT1NlcXVlbmNlIHRvIGFsbCBvdGhlciBEQU8g cGFyZW50c+KAnS4gTm8/DQo+ID4gIC0gSW4gdGhlIG5vbiBzdG9yaW5nIG1vZGUsIHRoZSBwYXRo IGNvbnRyb2wgaXMgbm90IHVzZWQgdG8gbGltaXQgdGhlDQo+ID4gREFPICBmYW4tb3V0IGFzIG5v ZGVzIHNlbmQgREFPcyB0byBvbmx5IG9uZSBvZiB0aGVpciBEQU8gcGFyZW50cy4gSQ0KPiA+IGd1 ZXNzIGl0ICBjYW4gYmUgdXNlZCBhcyBhIHByZWZlcmVuY2UgYnkgdGhlIHJvb3Qgd2hlbiBpdCBj b21wdXRlcyB0aGUgc291cmNlDQo+IHJvdXRlcy4NCj4gPiAgLSBIb3cgaXMgdGhlIHBhdGggc2Vx dWVuY2UgcHJvY2Vzc2VkPyBHaXZlbiB0aGF0IHdlIGhhdmUgYWxyZWFkeSBhDQo+ID4gREFPIHNl cXVlbmNlIGlzIGl0IHBvc3NpYmxlIHRvIHJlY2VpdmUgYSBzdGFsZSBwYXRoIHNlcXVlbmNlPyBJ c27igJl0IGl0DQo+IHJlZHVuZGFudD8NCj4gPiAgLSBXaGF0IGRvZXMgdGhlIGxpZmV0aW1lIHJl cHJlc2VudCBjb25jcmV0ZWx5PyBJcyBpdCBhIG1lYXN1cmUgb2YgdGhlDQo+ID4gbGlmZXRpbWUg b2YgdGhlIGxpbmsgYmV0d2VlbiB0aGUgdGFyZ2V0IGFuZCB0aGUgdHJhbnNpdD8NCj4gPg0KPiA+ ICBJdOKAmXMgYSBsb3Qgb2YgcXVlc3Rpb25zLCBidXQgSSBob3BlIGl0IHdpbGwgaGVscCBtYWtl IHRoZSBEQU8gcGFydA0KPiA+IGNsZWFyZXIgIHRvIGV2ZXJ5Ym9keSENCj4gPg0KPiA+ICBCZXN0 LA0KPiA+ICBNYXRoaWxkZQ0KPiA+DQo+ID4gLS0NCj4gPiBUaWNrZXQgVVJMOiA8aHR0cHM6Ly9z dm4udG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC81OT4NCj4gPiByb2xsIDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nicolas.dejean.ietf@googlemail.com Fri Jul 23 02:25:20 2010 Return-Path: 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 0D25B3A67B7 for ; Fri, 23 Jul 2010 02:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.348, 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 pGXnTTuGd-S2 for ; Fri, 23 Jul 2010 02:25:19 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id B06203A69D0 for ; Fri, 23 Jul 2010 02:25:18 -0700 (PDT) Received: by eyb7 with SMTP id 7so2481926eyb.31 for ; Fri, 23 Jul 2010 02:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bt50ZTZ+Iejgl+UcBdjyhcsXix648QEyV+RHGPQLVUA=; b=nxh9jAgECv+3/Aemt6lSOWq0PifQ74g4vpsNa5zc344ofOc/t/1WaCYRWiN05VYOlp Jyml0NRPcBvENUdnPMAkYPxuohfYb84LMEpBiOKZY9HBUa9ER13CIqp2TVm4VMZ+CbXM TlLVhPstoSVFZ2J0GxmRX9VE8de1jxp3c6fGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ifcxZVS56GohT+gsObTxTFsUbwfDxPt7G4EQSSCFcWuzeClu2d8wQTNRxPt4ddnV6+ U9krBqRXMx9UrV9KYprWI9ordD4Iquqhr11RQw3yoc0UtX7lqFb0WZpz8rjttkOD32yT vTzf+J6P+Y82Qrs2oF3ZVwMSy1NnMpMjTY5Ww= MIME-Version: 1.0 Received: by 10.213.31.141 with SMTP id y13mr3116585ebc.37.1279877136036; Fri, 23 Jul 2010 02:25:36 -0700 (PDT) Received: by 10.213.28.80 with HTTP; Fri, 23 Jul 2010 02:25:35 -0700 (PDT) In-Reply-To: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> Date: Fri, 23 Jul 2010 11:25:35 +0200 Message-ID: From: Nicolas DEJEAN To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Fri, 23 Jul 2010 09:25:20 -0000 Hello JP, you can count one more Yes. Cheers, Nicolas. 2010/7/23 JP Vasseur : > Dear all, > This is one of the comments that I send last week (ticket 70). We had a > discussion with the RPL authors yesterday (as pretty much every week) to > continue our work on the remaining open tickets (making great progress). Let > me simply explain why "route-tags" may be important to have in the core > spec. First of all, I'd like to clarify that we are not discussing about > using tags/labels for forwarding (we will at some point !) so I'll start > using the terms prefix-color to avoid ambiguity. We had the concept of > route-color (called route-tags) up to revision -7, at which point we > revisited the whole DAO format and it went away. > Why is it used for ? > Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is > used to mark a route. For example, this could be used to flag important > versus less-critical prefix. This has proven to be useful in a number of > other routing protocols but to give two examples: this can be used to > prioritize prefix installation during DODAG rebuilt to increase the > "convergence" time and restore connectivity faster for critical prefixes, it > could also be used in case of memory overflow to preferably keep the > important prefix, ... > Complexity ? > Nothing more than an option carried in a DAO message that could look like > this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 8 | 2 | Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > We just need to add one sentence in the Manageability Section. > We could either defer it to another ID or add it now. Personally I am > leaning toward adding it back, considering how simple it is and the benefits > this can bring. > Could you let us know whether you think that we should add it to the core > spec: > 1) Yes > 2) No. > Thanks. > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From pthubert@cisco.com Fri Jul 23 02:27:58 2010 Return-Path: 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 B9CEA3A6A17 for ; Fri, 23 Jul 2010 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 KC7DkvIAUNVq for ; Fri, 23 Jul 2010 02:27:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A5C043A69D5 for ; Fri, 23 Jul 2010 02:27:57 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2010 09:28:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N9Rg49010619; Fri, 23 Jul 2010 09:28:15 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:28:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2A49.5ECDF3D1" Date: Fri, 23 Jul 2010 11:28:09 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260ACA1@XMB-AMS-107.cisco.com> In-Reply-To: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Route-tags - Soliciting WG comments thread-index: AcsqPm1oC+5Kiz/KQoaiqUe1ALf38wACrjSQ References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "roll WG" X-OriginalArrivalTime: 23 Jul 2010 09:28:12.0968 (UTC) FILETIME=[5F475280:01CB2A49] Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Fri, 23 Jul 2010 09:27:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2A49.5ECDF3D1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Yes. We can describe that as an opaque metadata. No way we can describe its application though. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Friday, July 23, 2010 10:09 AM To: roll WG Subject: [Roll] Route-tags - Soliciting WG comments =20 Dear all, =20 This is one of the comments that I send last week (ticket 70). We had a discussion with the RPL authors yesterday (as pretty much every week) to continue our work on the remaining open tickets (making great progress). Let me simply explain why "route-tags" may be important to have in the core spec. First of all, I'd like to clarify that we are not discussing about using tags/labels for forwarding (we will at some point !) so I'll start using the terms prefix-color to avoid ambiguity. We had the concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away. =20 Why is it used for ? =20 Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. For example, this could be used to flag important versus less-critical prefix. This has proven to be useful in a number of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, it could also be used in case of memory overflow to preferably keep the important prefix, ...=20 =20 Complexity ? =20 Nothing more than an option carried in a DAO message that could look like this: =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | 2 | Flags = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 We just need to add one sentence in the Manageability Section. =20 We could either defer it to another ID or add it now. Personally I am leaning toward adding it back, considering how simple it is and the benefits this can bring. =20 Could you let us know whether you think that we should add it to the core spec: =20 1) Yes 2) No. =20 Thanks. =20 JP. ------_=_NextPart_001_01CB2A49.5ECDF3D1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Yes. We can describe that as an opaque metadata. No way we can = describe its application though.

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Friday, July 23, 2010 10:09 = AM
To: roll WG
Subject: [Roll] Route-tags - = Soliciting WG comments

 

Dear = all,

 

This is one of the comments that I send last week = (ticket 70). We had a discussion with the RPL authors yesterday (as = pretty much every week) to continue our work on the remaining open = tickets (making great progress). Let me simply explain why = "route-tags" may be important to have in the core spec. First = of all, I'd like to clarify that we are not discussing about using = tags/labels for forwarding (we will at some point !) so I'll start using = the terms prefix-color to avoid ambiguity. We had the concept of = route-color (called route-tags) up to revision -7, at which point we = revisited the whole DAO format and it went = away.

 

Why is it used for = ?

 

Route-colors is just an x bit flag field (e.g. RPC = 5130 for ISIS), that is used to mark a route. For example, this could be = used to flag important versus less-critical prefix. This has proven to = be useful in a number of other routing protocols but to give two = examples: this can be used to prioritize prefix installation during = DODAG rebuilt to increase the "convergence" time and restore = connectivity faster for critical prefixes, it could also be used in case = of memory overflow to preferably keep the important prefix, = ... 

 

Complexity ?

 

Nothing more than an option carried in a DAO message = that could look like this:

 

 =
0            =
       =
1            =
       =
2            =
       3
        =
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       =
|   Type =3D 8    =
|       =
2       =
|            =
  =
Flags            =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

We just need to add one sentence in the Manageability = Section.

 

We could either defer it to another ID or add it now. = Personally I am leaning toward adding it back, considering how simple it = is and the benefits this can bring.

 

Could you let us know whether you think that we should = add it to the core spec:

 

1) Yes

2) No.

 

Thanks.

 

JP.

------_=_NextPart_001_01CB2A49.5ECDF3D1-- From pthubert@cisco.com Fri Jul 23 02:52:17 2010 Return-Path: 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 2FF113A6839 for ; Fri, 23 Jul 2010 02:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.428 X-Spam-Level: X-Spam-Status: No, score=-10.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BYq5W7yJ73Dh for ; Fri, 23 Jul 2010 02:52:14 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DCC423A6802 for ; Fri, 23 Jul 2010 02:52:13 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFsDSUyrR7Ht/2dsb2JhbACfZnGlZJsKhTYEixo Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 09:52:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N9qHib020335 for ; Fri, 23 Jul 2010 09:52:31 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:52:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jul 2010 11:52:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260ACC7@XMB-AMS-107.cisco.com> In-Reply-To: <3EF472F4AD7D824EA24D3197C56B61DB01A32602@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] New Version Notification for draft-ietf-roll-of0-02 thread-index: AcsCODQIBY+9hlmvT/2dcwiOliEeKQAABmnwCccccCAAGiDzQAAfH//gAASAbDA= References: <20100602094424.765143A6957@core3.amsl.com> <6A2A459175DABE4BB11DE2026AA50A5D02016412@XMB-AMS-107.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01A322F9@XMB-BGL-41C.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0260AB35@XMB-AMS-107.cisco.com> <3EF472F4AD7D824EA24D3197C56B61DB01A32602@XMB-BGL-41C.cisco.com> From: "Pascal Thubert (pthubert)" To: "Navneet Agarwal (navagar)" , X-OriginalArrivalTime: 23 Jul 2010 09:52:24.0646 (UTC) FILETIME=[C08BCE60:01CB2A4C] Subject: Re: [Roll] New Version Notification for draft-ietf-roll-of0-02 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: , X-List-Received-Date: Fri, 23 Jul 2010 09:52:17 -0000 Hi Navneet You're correct.=20 The stretch kindof forms clear circles that rationalize the topology; there's no use for that in the current spec but there are documented extensions that would benefit from those clear circles. See the concept of rings in http://www.ietf.org/mail-archive/web/roll/current/msg03306.html. Also the concept of beltlines that run an alternate routing within the rings to bypass the center. Since it is all mays, I do not see value in removing the stretch text. You certainly do not have to implement this right now though. Pascal > -----Original Message----- > From: Navneet Agarwal (navagar) > Sent: Friday, July 23, 2010 9:39 AM > To: Pascal Thubert (pthubert); 'roll@ietf.org' > Subject: RE: [Roll] New Version Notification for draft-ietf-roll-of0-02 >=20 > Hi Pascal: > Ok >=20 > IIUC, the stretch allows you to select additional neighbors (as siblings) and since > they are not to be used at the moment, the stretch is more of nop. Right? >=20 > Thx >=20 > Regards, > Navneet >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: Thursday, July 22, 2010 10:17 PM > > To: Navneet Agarwal (navagar); 'roll@ietf.org' > > Subject: RE: [Roll] New Version Notification for > > draft-ietf-roll-of0-02 > > > > Hi Navneet: > > > > The concept of sibling still exists, and at the moment the RPL spec > > does not specify how they can be used; in other words they cannot > > safely be used. You can thus see the stretch as a filter that filters > > out neighbors of low interest because they yield no forward progress. > > Does that make sense? > > > > Pascal > > > > > > > -----Original Message----- > > > From: Navneet Agarwal (navagar) > > > Sent: Thursday, July 22, 2010 6:27 AM > > > To: Pascal Thubert (pthubert); roll@ietf.org > > > Subject: RE: [Roll] New Version Notification for > > > draft-ietf-roll-of0-02 > > > > > > Hi Pascal: > > > I have the following clarification on OF0-2: > > > > > > Section-3: The goal of stretching a rank is to allow a node > > to select > > > siblings if there is only one parent. Since the sibling has been > > > removed from the RPL spec, I am not sure the stretch logic > > of OF-0 is still applicable...can you pls clarify? > > > > > > Thx > > > > > > Regards, > > > Navneet > > > > > > > -----Original Message----- > > > > From: roll-bounces@ietf.org > > [mailto:roll-bounces@ietf.org] On Behalf > > > > Of Pascal Thubert (pthubert) > > > > Sent: Wednesday, June 02, 2010 3:19 PM > > > > To: roll@ietf.org > > > > Subject: Re: [Roll] New Version Notification for > > > > draft-ietf-roll-of0-02 > > > > > > > > Hi: > > > > > > > > OF0-2 was just published. Limited changes include: > > > > > > > > - make it very clear that only one octet of the rank is > > really used > > > > (from Zigbee's interop comments). > > > > - provide an abstraction of the interaction with the core spec > > > > (requested some time ago on the list) though not at an API level. > > > > > > > > Cheers, > > > > > > > > Pascal > > > > > > > > > > > > > -----Original Message----- > > > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > > > Sent: Wednesday, June 02, 2010 11:44 AM > > > > > To: Pascal Thubert (pthubert) > > > > > Subject: New Version Notification for draft-ietf-roll-of0-02 > > > > > > > > > > > > > > > A new version of I-D, draft-ietf-roll-of0-02.txt has been > > > > successfully > > > > > submitted by Pascal Thubert and posted to the IETF repository. > > > > > > > > > > Filename: draft-ietf-roll-of0 > > > > > Revision: 02 > > > > > Title: RPL Objective Function 0 > > > > > Creation_date: 2010-06-02 > > > > > WG ID: roll > > > > > Number_of_pages: 9 > > > > > > > > > > Abstract: > > > > > The Routing Protocol for Low Power and Lossy Networks (RPL) > > > > defines a > > > > > generic Distance Vector protocol for Low Power and Lossy > > > > Networks (LLNs). > > > > > RPL is instantiated to honor a particular routing objective/ > > > > > constraint by the adding a specific Objective Function > > (OF) that > > > > > is designed to solve that problem. This specification > > defines a > > > > > basic OF, OF0, that uses only the abstract properties exposed in > > > > RPL messages to maximize connectivity. > > > > > > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > > > > > _______________________________________________ > > > > Roll mailing list > > > > Roll@ietf.org > > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > From pthubert@cisco.com Fri Jul 23 03:07:44 2010 Return-Path: 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 C9DCD3A6A56 for ; Fri, 23 Jul 2010 03:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Rj1ik1CfUsi2 for ; Fri, 23 Jul 2010 03:07:43 -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 8004D3A6A50 for ; Fri, 23 Jul 2010 03:07:43 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2010 10:08:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6NA7WxG024839; Fri, 23 Jul 2010 10:08:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 12:07:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jul 2010 12:07:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260ACD4@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing issue #58: Clarification on DAO thread-index: AcsqP3BY7ra3ZS7qRbug7Ma7HXV1EAADkHOw References: <6A2A459175DABE4BB11DE2026AA50A5D0260AB31@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE02951562@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Mathilde Durvy (mdurvy)" X-OriginalArrivalTime: 23 Jul 2010 10:07:49.0685 (UTC) FILETIME=[E7E98E50:01CB2A4E] Cc: roll WG Subject: Re: [Roll] Closing issue #58: Clarification on DAO 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: , X-List-Received-Date: Fri, 23 Jul 2010 10:07:44 -0000 Hi Mathilde & JP > > Concerning the question "When should a node initiate (i.e. not > > propagate) an increase in DTSN?" are you going to add some text? > > If nothing is mandated there as well, it means that nodes could decide > > never to increment their DTSN and hence send a DAO only when they > > change of DAO parent. > > >=20 > Q for Pascal. We leave that to implementation as well. Here's proposed text to be added in 'Configuration of RPL Parameters related to DAO-based mechanisms' " A RPL implementation MAY allow for configuring a set of rules specifying the triggers for DTSN increment (manual or event-based). " Do you think we should mandate more? It makes sense that an inconsistency detection sometimes triggers a cache refresh, but that certainly should be rate limited, and depend on the stability of the network. Pascal > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Friday, July 23, 2010 10:17 AM > To: Mathilde Durvy (mdurvy) > Cc: Pascal Thubert (pthubert); roll WG > Subject: Re: Closing issue #58: Clarification on DAO >=20 >=20 > On Jul 23, 2010, at 9:49 AM, Mathilde Durvy (mdurvy) wrote: >=20 > > Hi Pascal, > > > > So essentially we don't mandate anything in terms of processing DAO- > > ACKs. Correct? > > >=20 > Correct. >=20 > > Concerning the question "When should a node initiate (i.e. not > > propagate) an increase in DTSN?" are you going to add some text? > > If nothing is mandated there as well, it means that nodes could decide > > never to increment their DTSN and hence send a DAO only when they > > change of DAO parent. > > >=20 > Q for Pascal. >=20 > > This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK are > > used but nothing is done when they are not received. What do you > > think? > > >=20 > I don't think that we need to specify an algorithm here. We provide the > mechanism, the rest is implementation specific (as in many other protocols). >=20 > Thanks. >=20 > JP. >=20 > > Best, > > Mathilde > > > > -----Original Message----- > > From: Pascal Thubert (pthubert) > > Sent: jeudi, 22. juillet 2010 18:42 > > To: roll WG > > Cc: JP Vasseur (jpv@cisco.com); Mathilde Durvy (mdurvy) > > Subject: Closing issue #58: Clarification on DAO > > > > Dear WG > > > > I think we can close 58. 11 will have the following changes: > > > >> - "Multicast DAOs MUST NOT include Transit Information options" > >> (Section 8.6). Do you mean "MUST not include a parent address in the > >> transit information option"? > > > > Corrected along the proposal > > > > > >> - Section 16.2.6 (which deals with configuration) introduces some > >> terminology > >> not used in the spec (e.g UNREACHABLE state). Is this some legacy > >> text? > > > > Legacy text removed. > > > >> - What actions need to be taken by a node that didn't get a DAO- ACK > >> response when setting the K bit? > > > > The text leaves that to implementation. Should not retry indefinitely > > though! > > > > If anybody opposes to close along the above line please speak up : ) > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >> Of roll issue tracker > >> Sent: Tuesday, July 13, 2010 11:14 AM > >> To: jpv@cisco.com > >> Cc: roll@ietf.org > >> Subject: [Roll] [roll] #58: Clarification on DAO > >> > >> #58: Clarification on DAO > >> ----------------------------- > >> +------------------------------------------ > >> -----------------------------+---- > >> Reporter: jpv@... | Owner: > >> Type: enhancement | Status: new > >> Priority: major | Milestone: > >> Component: rpl | Version: > >> Severity: In WG Last Call | Keywords: > >> ----------------------------- > >> +------------------------------------------ > >> -----------------------------+---- > >> Hello Mathilde > >> > >> - What is the DAO parent selection criteria for OCP0? Same as for DIO > >> parents I assume. > >> [Pascal] OF0 only mandates one preferred parent with good enough > >> bidirectional connectivity, and it enables a backup if one is > >> available. > >> So yes, there's little choice but pick it as DAO parent as well. > >> The draft could > >> have an additional sentence to say that I admit. > >> > >> - What actions need to be taken by a node that didn't get a DAO- ACK > >> response when setting the K bit? > >> [Pascal] We have to refine that text in 11 for sure. Only new > >> information is sent asynchronously to the DAO parents while the full > >> information is sent in > >> demand (upon DTSN or new version). In short, the rich > >> implementation can > >> maintain per parent what was acknowledged and flag it as not new. > >> The > >> constrained implementation sends the delta once and flag it as not > >> new without an ack, waiting for the next full information to fill > >> the gaps. So basically when something new is learnt, the storing > >> router arms a timer to schedule a DAO. When the timer elapses, the > >> router sends all new information to the parents. The timer keeps > >> elapsing for a given parent till the parent acks the most recent DAO > >> sequence sent to it or the router gives up. If the router gives up, > >> the parent is out of sync till the next change or full information > >> updates it. The path sequence that circulates via other parents that > >> are not out of sync is fresher and enables the ancestors to select > >> the usable path. > >> > >> - Section 16.2.6 (which deals with configuration) introduces some > >> terminology > >> not used in the spec (e.g UNREACHABLE state). Is this some legacy > >> text? > >> [Pascal] It is. That state was in the FSM that went down the sink > >> around > >> 08 > >> > >> - When should a node initiate (i.e. not propagate) an increase in > >> DTSN? > >> [Pascal] Can be upon an inconsistency detection, or upon an internal > >> timer per > >> policy though that is not mandated. An inconsistency can be an RPF > >> check, a > >> DAO entry not revalidated, a datapath validation failure. New DSTN > >> should be caped in time. > >> > >> - "Multicast DAOs MUST NOT include Transit Information options" > >> (Section 8.6). Do you mean "MUST not include a parent address in the > >> transit information option"? > >> [Pascal] Oups! Correct. We sometime need the lifetime. > >> > >> Best, > >> > >> Pascal > >> > >> -- > >> Ticket URL: > >> roll > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri Jul 23 03:26:35 2010 Return-Path: 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 B4E753A6A17 for ; Fri, 23 Jul 2010 03:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 EF7+D7uqrGRu for ; Fri, 23 Jul 2010 03:26:34 -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 842C03A68BD for ; Fri, 23 Jul 2010 03:26:34 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMsLSUyrR7Hu/2dsb2JhbACBRJ4icaVomw2FNgSIYII6 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2010 10:26:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6NAQn9s022262 for ; Fri, 23 Jul 2010 10:26:52 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 12:26:47 +0200 Received: from [192.168.1.11] ([10.61.86.244]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 12:26:46 +0200 Message-Id: From: JP Vasseur To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260ACA1@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-40-925895494 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 12:26:46 +0200 References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0260ACA1@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 10:26:46.0803 (UTC) FILETIME=[8DAFFE30:01CB2A51] Cc: roll WG Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Fri, 23 Jul 2010 10:26:35 -0000 --Apple-Mail-40-925895494 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 23, 2010, at 11:28 AM, Pascal Thubert (pthubert) wrote: > > Yes. We can describe that as an opaque metadata. No way we can > describe its application though. Absolutely, so do we for link affinities, ... Thanks for the feed-back. JP. > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Friday, July 23, 2010 10:09 AM > To: roll WG > Subject: [Roll] Route-tags - Soliciting WG comments > > Dear all, > > This is one of the comments that I send last week (ticket 70). We > had a discussion with the RPL authors yesterday (as pretty much > every week) to continue our work on the remaining open tickets > (making great progress). Let me simply explain why "route-tags" may > be important to have in the core spec. First of all, I'd like to > clarify that we are not discussing about using tags/labels for > forwarding (we will at some point !) so I'll start using the terms > prefix-color to avoid ambiguity. We had the concept of route-color > (called route-tags) up to revision -7, at which point we revisited > the whole DAO format and it went away. > > Why is it used for ? > > Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), > that is used to mark a route. For example, this could be used to > flag important versus less-critical prefix. This has proven to be > useful in a number of other routing protocols but to give two > examples: this can be used to prioritize prefix installation during > DODAG rebuilt to increase the "convergence" time and restore > connectivity faster for critical prefixes, it could also be used in > case of memory overflow to preferably keep the important prefix, ... > > Complexity ? > > Nothing more than an option carried in a DAO message that could look > like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Type = 8 | 2 | > Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > We just need to add one sentence in the Manageability Section. > > We could either defer it to another ID or add it now. Personally I > am leaning toward adding it back, considering how simple it is and > the benefits this can bring. > > Could you let us know whether you think that we should add it to the > core spec: > > 1) Yes > 2) No. > > Thanks. > > JP. --Apple-Mail-40-925895494 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 23, 2010, = at 11:28 AM, Pascal Thubert (pthubert) wrote:

Yes. = We can describe that as an opaque metadata. No way we can describe its = application = though.

Ab= solutely, so do we for link affinities, = ...

Thanks for the = feed-back.

JP.


 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Friday, July 23, 2010 10:09 = AM
To: roll = WG
Subject: [Roll] Route-tags - = Soliciting WG comments
 
Dear = all,
This is one of the = comments that I send last week (ticket 70). We had a discussion with the = RPL authors yesterday (as pretty much every week) to continue our work = on the remaining open tickets (making great progress). Let me simply = explain why "route-tags" may be important to have in the core spec. = First of all, I'd like to clarify that we are not discussing about using = tags/labels for forwarding (we will at some point !) so I'll start using = the terms prefix-color to avoid ambiguity. We had the concept of = route-color (called route-tags) up to revision -7, at which point we = revisited the whole DAO format and it went = away.
Why is it used for = ?
Route-colors is just an x = bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. = For example, this could be used to flag important versus less-critical = prefix. This has proven to be useful in a number of other routing = protocols but to give two examples: this can be used to prioritize = prefix installation during DODAG rebuilt to increase the "convergence" = time and restore connectivity faster for critical prefixes, it could = also be used in case of memory overflow to preferably keep the important = prefix, ... 
Complexity = ?
Nothing more than an = option carried in a DAO message that could look like = this:
= 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3
        0 1 2 =
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
       =
|   Type =3D 8    =
|       =
2       =
|            &=
nbsp; =
Flags            =
|
 
We just need to add one sentence in the Manageability = Section.
We could either defer it = to another ID or add it now. Personally I am leaning toward adding it = back, considering how simple it is and the benefits this can = bring.
Could you let us know = whether you think that we should add it to the core = spec:
1) = Yes
2) = No.
>> propagate) an increase in DTSN?" are you going to add some text? >>> If nothing is mandated there as well, it means that nodes could > decide >>> never to increment their DTSN and hence send a DAO only when they >>> change of DAO parent. >>> >> >> Q for Pascal. > > We leave that to implementation as well. > > Here's proposed text to be added in 'Configuration of RPL Parameters > related to DAO-based mechanisms' > > " > A RPL implementation MAY allow for configuring a set of rules > specifying the triggers for DTSN increment (manual or > event-based). > " > > Do you think we should mandate more? Nope, let's add it to Section 16. > It makes sense that an > inconsistency detection sometimes triggers a cache refresh, but that > certainly should be rate limited, and depend on the stability of the > network. Which is a tuning issue. JP. > > Pascal > > >> -----Original Message----- >> From: JP Vasseur [mailto:jpv@cisco.com] >> Sent: Friday, July 23, 2010 10:17 AM >> To: Mathilde Durvy (mdurvy) >> Cc: Pascal Thubert (pthubert); roll WG >> Subject: Re: Closing issue #58: Clarification on DAO >> >> >> On Jul 23, 2010, at 9:49 AM, Mathilde Durvy (mdurvy) wrote: >> >>> Hi Pascal, >>> >>> So essentially we don't mandate anything in terms of processing DAO- >>> ACKs. Correct? >>> >> >> Correct. >> >>> Concerning the question "When should a node initiate (i.e. not >>> propagate) an increase in DTSN?" are you going to add some text? >>> If nothing is mandated there as well, it means that nodes could > decide >>> never to increment their DTSN and hence send a DAO only when they >>> change of DAO parent. >>> >> >> Q for Pascal. >> >>> This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK > are >>> used but nothing is done when they are not received. What do you >>> think? >>> >> >> I don't think that we need to specify an algorithm here. We provide > the >> mechanism, the rest is implementation specific (as in many other > protocols). >> >> Thanks. >> >> JP. >> >>> Best, >>> Mathilde >>> >>> -----Original Message----- >>> From: Pascal Thubert (pthubert) >>> Sent: jeudi, 22. juillet 2010 18:42 >>> To: roll WG >>> Cc: JP Vasseur (jpv@cisco.com); Mathilde Durvy (mdurvy) >>> Subject: Closing issue #58: Clarification on DAO >>> >>> Dear WG >>> >>> I think we can close 58. 11 will have the following changes: >>> >>>> - "Multicast DAOs MUST NOT include Transit Information options" >>>> (Section 8.6). Do you mean "MUST not include a parent address in > the >>>> transit information option"? >>> >>> Corrected along the proposal >>> >>> >>>> - Section 16.2.6 (which deals with configuration) introduces some >>>> terminology >>>> not used in the spec (e.g UNREACHABLE state). Is this some legacy >>>> text? >>> >>> Legacy text removed. >>> >>>> - What actions need to be taken by a node that didn't get a DAO- > ACK >>>> response when setting the K bit? >>> >>> The text leaves that to implementation. Should not retry > indefinitely >>> though! >>> >>> If anybody opposes to close along the above line please speak up : ) >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On > Behalf >>>> Of roll issue tracker >>>> Sent: Tuesday, July 13, 2010 11:14 AM >>>> To: jpv@cisco.com >>>> Cc: roll@ietf.org >>>> Subject: [Roll] [roll] #58: Clarification on DAO >>>> >>>> #58: Clarification on DAO >>>> ----------------------------- >>>> +------------------------------------------ >>>> -----------------------------+---- >>>> Reporter: jpv@... | Owner: >>>> Type: enhancement | Status: new >>>> Priority: major | Milestone: >>>> Component: rpl | Version: >>>> Severity: In WG Last Call | Keywords: >>>> ----------------------------- >>>> +------------------------------------------ >>>> -----------------------------+---- >>>> Hello Mathilde >>>> >>>> - What is the DAO parent selection criteria for OCP0? Same as for > DIO >>>> parents I assume. >>>> [Pascal] OF0 only mandates one preferred parent with good enough >>>> bidirectional connectivity, and it enables a backup if one is >>>> available. >>>> So yes, there's little choice but pick it as DAO parent as well. >>>> The draft could >>>> have an additional sentence to say that I admit. >>>> >>>> - What actions need to be taken by a node that didn't get a DAO- > ACK >>>> response when setting the K bit? >>>> [Pascal] We have to refine that text in 11 for sure. Only new >>>> information is sent asynchronously to the DAO parents while the > full >>>> information is sent in >>>> demand (upon DTSN or new version). In short, the rich >>>> implementation can >>>> maintain per parent what was acknowledged and flag it as not new. >>>> The >>>> constrained implementation sends the delta once and flag it as not >>>> new without an ack, waiting for the next full information to fill >>>> the gaps. So basically when something new is learnt, the storing >>>> router arms a timer to schedule a DAO. When the timer elapses, the >>>> router sends all new information to the parents. The timer keeps >>>> elapsing for a given parent till the parent acks the most recent > DAO >>>> sequence sent to it or the router gives up. If the router gives > up, >>>> the parent is out of sync till the next change or full information >>>> updates it. The path sequence that circulates via other parents > that >>>> are not out of sync is fresher and enables the ancestors to select >>>> the usable path. >>>> >>>> - Section 16.2.6 (which deals with configuration) introduces some >>>> terminology >>>> not used in the spec (e.g UNREACHABLE state). Is this some legacy >>>> text? >>>> [Pascal] It is. That state was in the FSM that went down the sink >>>> around >>>> 08 >>>> >>>> - When should a node initiate (i.e. not propagate) an increase in >>>> DTSN? >>>> [Pascal] Can be upon an inconsistency detection, or upon an > internal >>>> timer per >>>> policy though that is not mandated. An inconsistency can be an RPF >>>> check, a >>>> DAO entry not revalidated, a datapath validation failure. New DSTN >>>> should be caped in time. >>>> >>>> - "Multicast DAOs MUST NOT include Transit Information options" >>>> (Section 8.6). Do you mean "MUST not include a parent address in > the >>>> transit information option"? >>>> [Pascal] Oups! Correct. We sometime need the lifetime. >>>> >>>> Best, >>>> >>>> Pascal >>>> >>>> -- >>>> Ticket URL: >>>> roll >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll > From trac@tools.ietf.org Fri Jul 23 03:35:03 2010 Return-Path: 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 C1DFA3A6890 for ; Fri, 23 Jul 2010 03:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 M+6vZkEDk6KY for ; Fri, 23 Jul 2010 03:35:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A0F913A6853 for ; Fri, 23 Jul 2010 03:35:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcFb6-0004tb-S6; Fri, 23 Jul 2010 03:35:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Fri, 23 Jul 2010 10:35:20 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/59#comment:1 Message-ID: <064.ac7354eb02635b9913b9837166e3faca@tools.ietf.org> References: <055.798c48fa8ae12e4b6b01d186c855a8f7@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <055.798c48fa8ae12e4b6b01d186c855a8f7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #59: Request for clarification: Transit information option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 10:35:03 -0000 #59: Request for clarification: Transit information option -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Email from Pascal on July 23. Dear WG The following text is proposed to clarify RPL for issue 59: - ECMP is added for issue #60 by pairing path control bits. - Some text on path sequence is added for issue #55 - text on lifetime is added for issue #56 "If a node sends a DAO message to one DAO parent, it MUST send a DAO with the same Sequence to all other DAO parents." Was at the wrong place. It goes away but is replaced elsewhere with this "Path Sequence: This sequence counter is present in the Transit Information option in a DAO message. The purpose of this counter is to differentiate a movement where a newer route supersedes a stale one from a route redundancy scenario where multiple routes exist in parallel for a same target. The Path Sequence is globally significant in a DODAG and indicates the freshness of the route to the associated target. An older (lesser) value received from an originating router indicates that the originating router holds stale routing states and the originating router should not be considered anymore as a potential next-hop for the target. The Path Sequence is computed by the node that advertises the target, that is the target itself or a router that advertises a target on behalf of a host, and is unchanged as the DAO content is propagated towards the root by parent routers. If a host does not pass a counter to its router, then the router is in charge of computing the Path Sequence on behalf of the host and the host can only register to one router for that purpose. If a DAO message containing a same target is issued to multiple parents at a given point of time for the purpose of route redundancy, then the Path Sequence is the same in all the DAO messages for that same target." Also "For a Target that is associated with (owned by) a node, that node MAY increment the Path Sequence counter, and generate a new DAO message, on occasion in order to refresh the downward routing information. In storing mode, the node generates such DAO to each of its DAO parents in order to enable multipath. All DAOs generated at the same time for a same target MUST be sent with the same path sequence in the transit information." Text on path sequence and DAO sequence is revisited. The path control text is slightly incremented: " When a node sends a DAO to one of its DAO parents, it MUST select one or more of the set, active bits in the aggregated Path Control field. The DAO it transmits to its parent MUST have these active bits set and all other active bits cleared." Becomes "When a node sends a DAO message to one of its DAO parents, it MUST select one or more of the bits that are set active in the aggregated Path Control field to advertise to a that parent. A given bit can only be presented as active to one parent. The DAO message it transmits to its parent MUST have these active bits set and all other active bits cleared." If you have an issue with this resolution please chime in : ) Pascal -- Ticket URL: roll From trac@tools.ietf.org Fri Jul 23 03:41:00 2010 Return-Path: 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 1DC4E3A699C for ; Fri, 23 Jul 2010 03:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 B0VVWeWOHGqT for ; Fri, 23 Jul 2010 03:40:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2090C3A6853 for ; Fri, 23 Jul 2010 03:40:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcFgr-0005CA-9D; Fri, 23 Jul 2010 03:41:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Fri, 23 Jul 2010 10:41:17 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/58#comment:1 Message-ID: <064.b81b52f91e7e596963f458010a82a912@tools.ietf.org> References: <055.2b0240e94b11938c1f27781717c93f00@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <055.2b0240e94b11938c1f27781717c93f00@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #58: Clarification on DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 10:41:00 -0000 #58: Clarification on DAO -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: From: "Pascal Thubert (pthubert)" Date: July 22, 2010 6:42:21 PM CEDT To: "roll WG" Cc: , "Mathilde Durvy (mdurvy)" Subject: Closing issue #58: Clarification on DAO Dear WG I think we can close 58. 11 will have the following changes: - “Multicast DAOs MUST NOT include Transit Information options†(Section 8.6). Do you mean “MUST not include a parent address in the transit information option� Corrected along the proposal - Section 16.2.6 (which deals with configuration) introduces some terminology not used in the spec (e.g UNREACHABLE state). Is this some legacy text? Legacy text removed. - What actions need to be taken by a node that didn’t get a DAO-ACK response when setting the K bit? The text leaves that to implementation. Should not retry indefinitely though! If anybody opposes to close along the above line please speak up : ) Pascal -- Ticket URL: roll From pthubert@cisco.com Fri Jul 23 04:38:25 2010 Return-Path: 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 7899D3A695D for ; Fri, 23 Jul 2010 04:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.433 X-Spam-Level: X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 v+eebEekZNXb for ; Fri, 23 Jul 2010 04:38:24 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 055713A69DD for ; Fri, 23 Jul 2010 04:38:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Jul 2010 11:38:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6NBcZPZ019440; Fri, 23 Jul 2010 11:38:42 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:38:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2A5B.98D6BC73" Date: Fri, 23 Jul 2010 13:38:35 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AD34@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ticket #64 thread-index: AcskG29OIspSfJOlTQmUD9rjjr9mrwGP/A4Q References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 23 Jul 2010 11:38:40.0997 (UTC) FILETIME=[9925C150:01CB2A5B] Subject: Re: [Roll] Ticket #64 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: , X-List-Received-Date: Fri, 23 Jul 2010 11:38:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2A5B.98D6BC73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about this: =20 RPLInstanceIDs are used to avoid loops between DODAGs from different origins. DODAGs that are constructed for antagonistic constraints might contain paths that, if mixed together, would yield loops. Those loops are avoided by forwarding a packet along the DODAG that is associated to a given instance. =20 The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. =20 For a packet that is originated from outside the RPL network, the source of the packet might be aware of the RPL network, of the constraints imposed on OFs, and of associated RPLInstanceIDs. In that case, the source of the packet MAY tag the flow label with the RPLInstanceID. =20 A router that injects a data packet into the RPL network MUST tag the packet by inserting a RPL Hop-by-hop option as specified in I-D.hui-6man-rpl-option. The ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the RPL Hop-by-hop option. =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Thursday, July 15, 2010 2:44 PM To: ROLL WG Subject: [Roll] Ticket #64 =20 10.2.2. Router Operation =20 10.2.2.1. Instance Forwarding =20 Instance IDs are used to avoid loops between DODAGs from different origins. DODAGs that constructed for antagonistic constraints might contain paths that, if mixed together, would yield loops. Those loops are avoided by forwarding a packet along the DODAG that is associated to a given instance. =20 The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For traffic originating outside of the RPL domain there may be a mapping occurring at the gateway=20 JP> Do not use "gateway". It is called LBR in the terminology ID. into the RPL domain, possibly based on an encoding within the flow label. This aspect of RPL operation is to be clarified in a future version of this specification. =20 JP> in rev-11. Note that the LBR may use policy to compute itself the RPLInstanceID. We do not need to mandate the source outside of the RPL domain to carry it in the=20 flow label. ------_=_NextPart_001_01CB2A5B.98D6BC73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What about this:

 

            = RPLInstanceIDs are used to avoid loops between DODAGs = from

            = different origins. DODAGs that are constructed for = antagonistic

            = constraints might contain paths that, if mixed together, = would

            = yield loops. Those loops are avoided by forwarding a packet = along

            = the DODAG that is associated to a given = instance.

 

            = The RPLInstanceID is associated by the source with the = packet.

            = This RPLInstanceID MUST match the RPL Instance onto which = the

            = packet is placed by any node, be it a host or = router.

 

            = For a packet that is originated from outside the RPL = network,

            = the source of the packet might be aware of the RPL network, = of

            = the constraints imposed on OFs, and of associated = RPLInstanceIDs.

            In = that case, the source of the packet MAY tag the flow label = with

            = the RPLInstanceID.

 

            A = router that injects a data packet into the RPL network = MUST

            = tag the packet by inserting a RPL Hop-by-hop option as = specified

            in = I-D.hui-6man-rpl-option. The ingress router that injects = the

           =  packet into the RPL network MUST add a RPLInstanceID = field

            to = the RPL Hop-by-hop option.

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Thursday, July 15, 2010 2:44 = PM
To: ROLL WG
Subject: [Roll] Ticket = #64

 

10.2.2.  Router =
Operation
 
10.2.2.1. =
; Instance =
Forwarding
 
   =
Instance IDs are used to avoid loops between DODAGs from =
different
   origins.  DODAGs that =
constructed for antagonistic constraints =
might
   contain paths that, if mixed =
together, would yield loops.  =
Those
   loops are avoided by forwarding =
a packet along the DODAG that is
   =
associated to a given =
instance.
 
   =
The RPLInstanceID is associated by the source with the packet.  =
This
   RPLInstanceID MUST match the RPL =
Instance onto which the packet is
   =
placed by any node, be it a host or router.  For traffic =
originating
   outside of the RPL domain =
there may be a mapping occurring at =
the
   gateway 
JP> Do =
not use "gateway". It is called LBR in the terminology =
ID.
into the RPL domain, possibly based on =
an encoding within the
   flow =
label.  This aspect of RPL operation is to be clarified in =
a
   future version of this =
specification.
 
JP> in =
rev-11. Note that the LBR may use policy to compute itself the =
RPLInstanceID.
We do not =
need to mandate the source outside of the RPL domain to carry it in =
the 
flow =
label.
------_=_NextPart_001_01CB2A5B.98D6BC73-- From jpv@cisco.com Fri Jul 23 04:46:39 2010 Return-Path: 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 6C97A3A6784 for ; Fri, 23 Jul 2010 04:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 a36PMSLQz9Jq for ; Fri, 23 Jul 2010 04:46:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 698F43A6817 for ; Fri, 23 Jul 2010 04:46:37 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAE8eSUyrR7Ht/2dsb2JhbACBRJ4icaVjmwmFNgSIYII6 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 11:46:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6NBkm51016743 for ; Fri, 23 Jul 2010 11:46:55 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:46:52 +0200 Received: from [192.168.1.11] ([10.61.86.244]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:46:52 +0200 Message-Id: <39B538AE-1D84-45DE-BDD7-E2F019A43A05@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AD34@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-47-930701305 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 13:46:51 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D0260AD34@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 11:46:52.0165 (UTC) FILETIME=[BDE80B50:01CB2A5C] Cc: ROLL WG Subject: Re: [Roll] Ticket #64 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: , X-List-Received-Date: Fri, 23 Jul 2010 11:46:39 -0000 --Apple-Mail-47-930701305 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Pascal, Our emials collide ... look at the email that I sent to authors summarizing all proposed changes and we'll go back to the WG. On Jul 23, 2010, at 1:38 PM, Pascal Thubert (pthubert) wrote: > What about this: > > RPLInstanceIDs are used to avoid loops between DODAGs from > different origins. DODAGs that are constructed for > antagonistic > constraints might contain paths that, if mixed together, > would > yield loops. Those loops are avoided by forwarding a > packet along > the DODAG that is associated to a given instance. > > The RPLInstanceID is associated by the source with the > packet. > This RPLInstanceID MUST match the RPL Instance onto > which the > packet is placed by any node, be it a host or router. > > For a packet that is originated from outside the RPL > network, > the source of the packet might be aware of the RPL > network, of > the constraints imposed on OFs, and of associated > RPLInstanceIDs. > In that case, the source of the packet MAY tag the flow > label with > the RPLInstanceID. > > A router that injects a data packet into the RPL network > MUST > tag the packet by inserting a RPL Hop-by-hop option as > specified > in I-D.hui-6man-rpl-option. The ingress router that > injects the > packet into the RPL network MUST add a RPLInstanceID field > to the RPL Hop-by-hop option. > > Pascal > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of JP Vasseur > Sent: Thursday, July 15, 2010 2:44 PM > To: ROLL WG > Subject: [Roll] Ticket #64 > > 10.2.2. Router Operation > > 10.2.2.1. Instance Forwarding > > Instance IDs are used to avoid loops between DODAGs from different > origins. DODAGs that constructed for antagonistic constraints > might > contain paths that, if mixed together, would yield loops. Those > loops are avoided by forwarding a packet along the DODAG that is > associated to a given instance. > > The RPLInstanceID is associated by the source with the packet. > This > RPLInstanceID MUST match the RPL Instance onto which the packet is > placed by any node, be it a host or router. For traffic > originating > outside of the RPL domain there may be a mapping occurring at the > gateway > JP> Do not use "gateway". It is called LBR in the terminology ID. > into the RPL domain, possibly based on an encoding within the > flow label. This aspect of RPL operation is to be clarified in a > future version of this specification. > > JP> in rev-11. Note that the LBR may use policy to compute itself > the RPLInstanceID. > We do not need to mandate the source outside of the RPL domain to > carry it in the > flow label. --Apple-Mail-47-930701305 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
What = about this:
 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent: Thursday, July 15, 2010 = 2:44 PM
To: ROLL = WG
Subject: [Roll] Ticket = #64
10.2.2.  Router = Operation
 
   Instance IDs are used to =
avoid loops between DODAGs from different
   =
origins.  DODAGs that constructed for antagonistic constraints =
might
   contain paths that, if mixed together, =
would yield loops.  Those
   loops are =
avoided by forwarding a packet along the DODAG that =
is
   associated to a given =
instance.
 
   RPLInstanceID MUST =
match the RPL Instance onto which the packet is
   outside of the RPL =
domain there may be a mapping occurring at the
into the RPL domain, possibly based on an encoding within =
the
   flow label.  This aspect of RPL =
operation is to be clarified in a
 
JP> in rev-11. Note that the =
LBR may use policy to compute itself the =
RPLInstanceID.
flow =
label.

= --Apple-Mail-47-930701305-- From jpv@cisco.com Fri Jul 23 04:51:40 2010 Return-Path: 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 1BC9D3A68FA for ; Fri, 23 Jul 2010 04:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vpJFJP5Tolkn for ; Fri, 23 Jul 2010 04:51:39 -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 2D1423A6845 for ; Fri, 23 Jul 2010 04:51:39 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE8fSUxAZnwN/2dsb2JhbACfZ3Gla5sJhTYEiGCCOocb Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2010 11:51:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NBpuQP001889; Fri, 23 Jul 2010 11:51:56 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:51:56 +0200 Received: from [192.168.1.11] ([10.61.86.244]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:51:55 +0200 Message-Id: <8E8E23EB-A1AA-447E-935F-EEC3EC553A49@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 13:51:55 +0200 References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 11:51:55.0933 (UTC) FILETIME=[72F75CD0:01CB2A5D] Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Fri, 23 Jul 2010 11:51:40 -0000 On Jul 23, 2010, at 2:09 AM, Philip Levis wrote: > > On Jul 22, 2010, at 4:55 PM, Michael Richardson wrote: > >> >> >> So a better choice would be to present the working group with >> question: >> "Shall the only MUST signature algorithm be IPR-encumbered?" >> >> - -- > > > Except, of course, that supporting signatures is not a MUST. It is > entirely acceptable, within the current specification, to have a RPL > implementation that supports only unsecured mode, just as it is > acceptable to have a RPL implementation that rejects all unsecured > messages. > > This flexibility is because some LLNs have security mechanisms > (e.g., link layer) which can render the RPL ones superfluous, > therefore optional. One of the stated design goals from the > beginning is that RPL should not require security mechanisms when > they are not needed. > Thanks for stressing this important fact. > Phil From jpv@cisco.com Fri Jul 23 04:52:10 2010 Return-Path: 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 E1DB63A696C for ; Fri, 23 Jul 2010 04:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 l8oxwlYlm1md for ; Fri, 23 Jul 2010 04:52: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 4C67E3A6828 for ; Fri, 23 Jul 2010 04:52:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAE8fSUxAZnwN/2dsb2JhbACBRIRQkx6GNXGla4xljiSFNgSIYII6 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2010 11:52:27 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NBqQ2t002034 for ; Fri, 23 Jul 2010 11:52:27 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:52:26 +0200 Received: from [192.168.1.11] ([10.61.86.244]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 13:52:26 +0200 Message-Id: <07FC6D5B-C9C9-44C8-B600-0C3430DD8063@cisco.com> From: JP Vasseur To: roll WG Content-Type: multipart/alternative; boundary=Apple-Mail-48-931035394 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 13:52:25 +0200 References: <7911.1279843054@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 11:52:26.0214 (UTC) FILETIME=[8503E060:01CB2A5D] Subject: [Roll] ** Please chime in if you have an opinion ** Fwd: Signature schemes and IPR in RPL 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: , X-List-Received-Date: Fri, 23 Jul 2010 11:52:11 -0000 --Apple-Mail-48-931035394 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Michael Richardson > Date: July 23, 2010 1:57:34 AM CEDT > To: roll WG , seclln@external.cisco.com > Subject: Re: [Roll] Signature schemes and IPR in RPL > > >>>>>> "Philip" == Philip Levis writes: > Philip> The security DT sees three possible paths going forward: > > Philip> 1) Keep the Algorithm options as they are now: the only > Philip> signature scheme supported in the base RPL specification is > Philip> encumbered by IPR. Let's call this the "IPR" option. > > Philip> 2) Keep a single Algorithm (ID=0) in the base RPL > Philip> specification, but change Algorithm ID=0's signature scheme > Philip> to one that we believe is unencumbered by IPR. Let's call > Philip> this the "No-IPR" option. > > Philip> 3) Keep the current Algorithm (ID=0), and add a second > Philip> Algorithm (ID=1) to have the same Encryption/MAC scheme as > Philip> ID=0 (CCM* with AES-128) but a signature scheme we believe > Philip> is unencumbered by IPR. Let's call this the "Both" option. > > I will answer on the assumption that: > a) option 2 means marking ID=0, No-IPR option MUST, and any > future IPR-option a MAY. > > 3b) option 3 means marking ID=1 MUST, and ID=0 MUST. > > 3c) option 3 means marking ID=1 MUST, and ID=0 MAY. > > > My preferences are: > (2) > (3c) > > I consider (1) and (3c) to be completely un-acceptable. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-48-931035394 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = Michael Richardson <mcr@sandelman.ca>
Date: = July 23, 2010 1:57:34 AM CEDT
Subject: Re: [Roll] Signature schemes and IPR = in RPL

=

"Philip" =3D=3D Philip Levis = <pal@cs.stanford.edu> = writes:
   Philip> The security DT sees three possible = paths going forward:

   Philip>   1) = Keep the Algorithm options as they are now: the only
=    Philip> signature scheme supported in the base RPL = specification is
   Philip> encumbered by IPR. = Let's call this the "IPR" option.

   Philip> =   2) Keep a single Algorithm (ID=3D0) in the base RPL
=    Philip> specification, but change Algorithm ID=3D0's = signature scheme
   Philip> to one that we believe = is unencumbered by IPR. Let's call
   Philip> this = the "No-IPR" option.

   Philip>   3) = Keep the current Algorithm (ID=3D0), and add a second
=    Philip> Algorithm (ID=3D1) to have the same = Encryption/MAC scheme as
   Philip> ID=3D0 (CCM* = with AES-128) but a signature scheme we believe
=    Philip> is unencumbered by IPR. Let's call this the = "Both" option.

I will answer on the assumption that:
 a) = option 2 means marking ID=3D0, No-IPR option MUST, and any
=     future IPR-option a MAY.

 3b) = option 3 means marking ID=3D1 MUST, and ID=3D0 MUST.

 3c) = option 3 means marking ID=3D1 MUST, and ID=3D0 MAY.


My = preferences are:
  (2)
  (3c)

I = consider (1) and (3c) to be completely un-acceptable.

--
] =       He who is tired of Weird Al is tired = of life!           | =  firewalls  [
]   Michael Richardson, Sandelman = Software Works, Ottawa, ON    |net architect[
] = mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on= .ca/ |device driver[
  Kyoto Plus: watch the video = <http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE>
=             &n= bsp; then sign the petition. =




_______________________________________________
Rol= l mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-48-931035394-- From mjohn.info@googlemail.com Fri Jul 23 05:51:40 2010 Return-Path: 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 0C6D13A6823 for ; Fri, 23 Jul 2010 05:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.448, 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 AkHB+D+qGG9Q for ; Fri, 23 Jul 2010 05:51:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id AAB633A68AB for ; Fri, 23 Jul 2010 05:51:38 -0700 (PDT) Received: by wyb40 with SMTP id 40so165137wyb.31 for ; Fri, 23 Jul 2010 05:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xEkdvdm9ic3PqDPVEyQSAisP+qlbopmxPE4Xmtr/Ejc=; b=W+9kOQ2zgH735VphblH7Ks7ye4zBVpxeLtaTF/jcEu7J4xuTpEUk3cwkcmOg1fZlUK G33LkNQLzez185BxhDzJOZvD7KmzwKqwbMQdJE+In7445IxhRa68Sg1JberxtkWEIeYV OZjwgN4p1MeQP8DlgrkbOfu63+nMXPd6XykSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j5ZOded+iny5QNU/s5UfA+ChgEv74/OWw/mlLKARcgKz1HQWLvjhTU7BpV+tb3Zztk 3l5vmEiVG40gA/OCP044UGpNrOXLaw36GKsWsUqnKLWRuth9BxnCRGxKWQDBDtFqpdeW pCKrZjAbFgssVAA19mTNtvMBYl6xw053WONLY= MIME-Version: 1.0 Received: by 10.216.185.132 with SMTP id u4mr3386661wem.27.1279889516210; Fri, 23 Jul 2010 05:51:56 -0700 (PDT) Received: by 10.216.230.3 with HTTP; Fri, 23 Jul 2010 05:51:56 -0700 (PDT) In-Reply-To: <07FC6D5B-C9C9-44C8-B600-0C3430DD8063@cisco.com> References: <7911.1279843054@marajade.sandelman.ca> <07FC6D5B-C9C9-44C8-B600-0C3430DD8063@cisco.com> Date: Fri, 23 Jul 2010 14:51:56 +0200 Message-ID: From: Michael John To: JP Vasseur Content-Type: multipart/alternative; boundary=0016e65b5c50f72b11048c0d7f48 X-Mailman-Approved-At: Fri, 23 Jul 2010 05:55:11 -0700 Cc: roll WG Subject: Re: [Roll] ** Please chime in if you have an opinion ** Fwd: Signature schemes and IPR in RPL 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: , X-List-Received-Date: Fri, 23 Jul 2010 12:51:40 -0000 --0016e65b5c50f72b11048c0d7f48 Content-Type: text/plain; charset=ISO-8859-1 JP, all, Philip> 2) Keep a single Algorithm (ID=0) in the base RPL > Philip> specification, but change Algorithm ID=0's signature scheme > Philip> to one that we believe is unencumbered by IPR. Let's call > Philip> this the "No-IPR" option. > > I would prefer this. > Philip> 3) Keep the current Algorithm (ID=0), and add a second > Philip> Algorithm (ID=1) to have the same Encryption/MAC scheme as > Philip> ID=0 (CCM* with AES-128) but a signature scheme we believe > Philip> is unencumbered by IPR. Let's call this the "Both" option. > > This is also feasible, but I that case I would suggest to make the second algorithm the default (use ID=0). --0016e65b5c50f72b11048c0d7f48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JP, all,

=A0=A0 Philip> =A0=A02) Keep a single Algorithm (ID=3D0) in the ba= se RPL
=A0=A0=A0Philip> specification, but change Algorithm ID=3D0&#= 39;s signature scheme
=A0=A0=A0Philip> to one that we believe is une= ncumbered by IPR. Let's call
=A0=A0=A0Philip> this the "No-IPR" option.
I would prefer this.
=A0
= =A0=A0=A0Philip> =A0=A03) Keep the current Algorithm (ID=3D0), and add a= second
=A0=A0=A0Philip> Algorithm (ID=3D1) to have the same Encrypt= ion/MAC scheme as
=A0=A0=A0Philip> ID=3D0 (CCM* with AES-128) but a signature scheme we b= elieve
=A0=A0=A0Philip> is unencumbered by IPR. Let's call this = the "Both" option.

This is also feasible, but I that case I would suggest to make the second a= lgorithm the default (use ID=3D0).
--0016e65b5c50f72b11048c0d7f48-- From mcr@sandelman.ca Fri Jul 23 06:13:53 2010 Return-Path: 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 CC8443A681A for ; Fri, 23 Jul 2010 06:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 DBtScWy74rUA for ; Fri, 23 Jul 2010 06:13:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 1E7693A6867 for ; Fri, 23 Jul 2010 06:13:52 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 0A30C34724 for ; Fri, 23 Jul 2010 09:14:11 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3DBFE98A06 for ; Fri, 23 Jul 2010 09:11:54 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <07FC6D5B-C9C9-44C8-B600-0C3430DD8063@cisco.com> References: <7911.1279843054@marajade.sandelman.ca> <07FC6D5B-C9C9-44C8-B600-0C3430DD8063@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 23 Jul 2010 09:11:54 -0400 Message-ID: <4612.1279890714@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] ** Please chime in if you have an opinion ** Fwd: Signature schemes and IPR in RPL 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: , X-List-Received-Date: Fri, 23 Jul 2010 13:13:53 -0000 My preferences had a typo: > I will answer on the assumption that: > a) option 2 means marking ID=0, No-IPR option MUST, and any > future IPR-option a MAY. > > 3b) option 3 means marking ID=1 MUST, and ID=0 MUST. > > 3c) option 3 means marking ID=1 MUST, and ID=0 MAY. > > > My preferences are: > (2) > (3c) > > I consider (1) and (3b) to be completely un-acceptable. **** From mcr@sandelman.ca Fri Jul 23 06:17:12 2010 Return-Path: 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 947EF3A6940 for ; Fri, 23 Jul 2010 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 iQqhJPoeGLDX for ; Fri, 23 Jul 2010 06:17:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 73CF23A688E for ; Fri, 23 Jul 2010 06:17:11 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id AC22534724; Fri, 23 Jul 2010 09:17:29 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id CBD1698A06; Fri, 23 Jul 2010 09:15:12 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 23 Jul 2010 09:15:12 -0400 Message-ID: <4676.1279890912@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Fri, 23 Jul 2010 13:17:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Philip" == Philip Levis writes: >> So a better choice would be to present the working group with >> question: "Shall the only MUST signature algorithm be >> IPR-encumbered?" Philip> Except, of course, that supporting signatures is not a Philip> MUST. It is entirely acceptable, within the current Philip> specification, to have a RPL implementation that supports Philip> only unsecured mode, just as it is acceptable to have a RPL Philip> implementation that rejects all unsecured messages. This does not change things at all. You speak about how a specific network (LLN) is configured. I speak about what features a device MUST implement in order to be compliant to the specification. In fact, this observation makes the problem more acute. In the absense of a MUST to implement IPR-unencumbered signature mechanism, then many devices will be created which do not support any such mechanism, and nearly all RPL networks that do not have security at the layer-2, will be insecure. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTEmV34CLcPvd0N1lAQLZ5QgAh0ud8ASJVkBj9vhgMieRDNOboy/ke5mE M7XXZH5bmBYPJkuQW0HuHwGP5xZEYPhRgpx+piAjsi9WZttTNXXipdr7g9vCXqB0 duj4OuY/wLONHZJpw/PBVtWbZ5laq56+VieH09D/5lxUGhkd/iRNsoiKNSDvXkSq FkU5Wr/D8D6GAbc4efOrbNqYfuxehKB83PcxuchVWPfm1sShkQxfZOxrw+uMKctJ 1Qzws4E8auX9J+ja49xn4kxeproz5UzdjgHI/5RHSMlup2qmOtMJ/H1VbkQYrcDW GeD1ie5Us0QqC84259gLAzCklwcEqA0QpmQvo6CV0mZbjk0jgdhk1A== =DZY4 -----END PGP SIGNATURE----- From ulrich@herberg.name Fri Jul 23 07:54:16 2010 Return-Path: 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 9AB663A6861 for ; Fri, 23 Jul 2010 07:54:16 -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=[AWL=0.000, 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 fqU9TSUtGi6D for ; Fri, 23 Jul 2010 07:54:15 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D66A73A68B6 for ; Fri, 23 Jul 2010 07:54:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so1890496bwz.31 for ; Fri, 23 Jul 2010 07:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.46.23 with SMTP id h23mr2718735bkf.75.1279896871492; Fri, 23 Jul 2010 07:54:31 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Fri, 23 Jul 2010 07:54:31 -0700 (PDT) In-Reply-To: <4676.1279890912@marajade.sandelman.ca> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4676.1279890912@marajade.sandelman.ca> Date: Fri, 23 Jul 2010 16:54:31 +0200 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Fri, 23 Jul 2010 14:54:16 -0000 Hi, I was wondering whether the DT has any specific alternate unencumbered signature algorithms in mind. It may be easier to decide when having a concrete alternative, in order to compare performance / length of signatures. Also, are there any such similar "reasonable non-discriminatory IPR terms" with Certicom, as with Cisco? (https://datatracker.ietf.org/ipr/720/) Ulrich On Fri, Jul 23, 2010 at 3:15 PM, Michael Richardson wrot= e: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Philip" =3D=3D Philip Levis writes: > =A0 =A0>> So a better choice would be to present the working group with > =A0 =A0>> question: "Shall the only MUST signature algorithm be > =A0 =A0>> IPR-encumbered?" > > =A0 =A0Philip> Except, of course, that supporting signatures is not a > =A0 =A0Philip> MUST. It is entirely acceptable, within the current > =A0 =A0Philip> specification, to have a RPL implementation that supports > =A0 =A0Philip> only unsecured mode, just as it is acceptable to have a RP= L > =A0 =A0Philip> implementation that rejects all unsecured messages. > > This does not change things at all. =A0You speak about how a specific > network (LLN) is configured. =A0I speak about what features a device MUST > implement in order to be compliant to the specification. > > In fact, this observation makes the problem more acute. > > In the absense of a MUST to implement IPR-unencumbered signature > mechanism, then many devices will be created which do not support any > such mechanism, and nearly all RPL networks that do not have security at > the layer-2, will be insecure. > > - -- > ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 = =A0 =A0 | =A0firewalls =A0[ > ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|ne= t architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > =A0 Kyoto Plus: watch the video > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBTEmV34CLcPvd0N1lAQLZ5QgAh0ud8ASJVkBj9vhgMieRDNOboy/ke5mE > M7XXZH5bmBYPJkuQW0HuHwGP5xZEYPhRgpx+piAjsi9WZttTNXXipdr7g9vCXqB0 > duj4OuY/wLONHZJpw/PBVtWbZ5laq56+VieH09D/5lxUGhkd/iRNsoiKNSDvXkSq > FkU5Wr/D8D6GAbc4efOrbNqYfuxehKB83PcxuchVWPfm1sShkQxfZOxrw+uMKctJ > 1Qzws4E8auX9J+ja49xn4kxeproz5UzdjgHI/5RHSMlup2qmOtMJ/H1VbkQYrcDW > GeD1ie5Us0QqC84259gLAzCklwcEqA0QpmQvo6CV0mZbjk0jgdhk1A=3D=3D > =3DDZY4 > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Fri Jul 23 09:45:45 2010 Return-Path: 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 3D89C3A69E7 for ; Fri, 23 Jul 2010 09:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, 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 4eu5yOSKbvpC for ; Fri, 23 Jul 2010 09:45:44 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 46FA73A685E for ; Fri, 23 Jul 2010 09:45:44 -0700 (PDT) Received: from [172.27.75.101] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OcLNq-0007ev-8M; Fri, 23 Jul 2010 09:46:02 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4BF6F495-2184-4B64-9EF5-CEBA766D7F5F@cisco.com> Date: Fri, 23 Jul 2010 09:07:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BF6F495-2184-4B64-9EF5-CEBA766D7F5F@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: e1c7b331cb521454e7d22df558880a52 Cc: roll WG Subject: Re: [Roll] Ticket#71 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: , X-List-Received-Date: Fri, 23 Jul 2010 16:45:45 -0000 On Jul 23, 2010, at 12:17 AM, JP Vasseur wrote: > Dear all, >=20 > Considering the wide consensus for option B, I have updated the text = accordingly. >=20 > This requires 3 changes. >=20 > 1) New text in Section 7.3, third bullet: >=20 > OLD: >=20 > "o When a node receives a multicast DIS with a Solicited Information > option and the node matches all of the predicates in the = Solicited=20 > Information option." >=20 > NEW: >=20 > "o When a node receives a multicast DIS with a Solicited Information > option and the node matches all of the predicates in the Solicited=20= > Information option (carried in the DIS option field) and/or (to be > defined) fields of the Flag field are set." >=20 > 2) DIS Packet Format >=20 > OLD: >=20 > "0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Option(s)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Winter, et al. Expires December 30, 2010 [Page = 30] > Internet-Draft draft-ietf-roll-rpl-10 Jun = 2010 >=20 >=20 > Figure 9: The DIS Base Object >=20 > " >=20 > NEW: >=20 > "0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Flags | Option(s)... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > Winter, et al. Expires December 30, 2010 [Page = 30] > Internet-Draft draft-ietf-roll-rpl-10 Jun = 2010 >=20 >=20 > Figure 9: The DIS Base Object >=20 > " I think this makes the whole thing more complicated. We now have flags = that indicate whether you should check a predicate within the solicited = information option, as well as flags in the DIS itself. Suddenly we're = doing the same thing in two places: that seems like a mistake. I thought = the agreement was to just add something to the solicited information = option? Let me try another approach: we just need text that makes it = clear one could just add a bit whose predicate is always false. Phil From pal@cs.stanford.edu Fri Jul 23 09:45:46 2010 Return-Path: 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 2D35C3A685E for ; Fri, 23 Jul 2010 09:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 i4nhph+g0ywZ for ; Fri, 23 Jul 2010 09:45:45 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 452A83A69EB for ; Fri, 23 Jul 2010 09:45:45 -0700 (PDT) Received: from [172.27.75.101] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OcLNr-0007ev-Mz; Fri, 23 Jul 2010 09:46:03 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4C4945F3.7060501@gmail.com> Date: Fri, 23 Jul 2010 09:22:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: roll@ietf.org Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Fri, 23 Jul 2010 16:45:46 -0000 On Jul 23, 2010, at 12:34 AM, Alexandru Petrescu wrote: > Le 23/07/2010 02:09, Philip Levis a =E9crit : >=20 >> This flexibility is because some LLNs have security mechanisms (e.g., >> link layer) which can render the RPL ones superfluous, therefore >> optional. >=20 > I agree. When link layer security is relied upon then we should state = so, in the draft, with the names of the link layer security. >=20 >> One of the stated design goals from the beginning is that >> RPL should not require security mechanisms when they are not needed. >=20 > Is this reflected in the draft? Alex, I think these discussions might be more productive if you read the = RPL draft, as well as the motivating application drafts, before making = forceful comments about how RPL should work. 3.3.3. Security RPL supports message confidentiality and integrity. It is designed such that link-layer mechanisms can be used when available and appropriate, yet in their absence RPL can use its own mechanisms. RPL has three basic security modes. Phil= From jpv@cisco.com Fri Jul 23 11:19:25 2010 Return-Path: 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 ED8273A6A07 for ; Fri, 23 Jul 2010 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3eL0kLPeMxOe for ; Fri, 23 Jul 2010 11:19:25 -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 9E04F3A6A59 for ; Fri, 23 Jul 2010 11:19:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALd5SUxAZnwM/2dsb2JhbACfaXGnLJsChTYEiGCCOocb Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 18:19:42 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6NIJfZC022123; Fri, 23 Jul 2010 18:19:42 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 20:19:41 +0200 Received: from [192.168.1.11] ([10.61.111.197]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 20:19:41 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 20:19:39 +0200 References: <4BF6F495-2184-4B64-9EF5-CEBA766D7F5F@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 18:19:41.0097 (UTC) FILETIME=[9E15A990:01CB2A93] Cc: roll WG Subject: Re: [Roll] Ticket#71 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: , X-List-Received-Date: Fri, 23 Jul 2010 18:19:26 -0000 Phil, I have to disagree. We have a 16 bits reserved bits field. Take 8 bits for flags, add the registry to IANA, and then we have usable 8 bits. No need to insert an option if a flag is sufficient. This is I think a much better design. JP. On Jul 23, 2010, at 6:07 PM, Philip Levis wrote: > > On Jul 23, 2010, at 12:17 AM, JP Vasseur wrote: > >> Dear all, >> >> Considering the wide consensus for option B, I have updated the >> text accordingly. >> >> This requires 3 changes. >> >> 1) New text in Section 7.3, third bullet: >> >> OLD: >> >> "o When a node receives a multicast DIS with a Solicited Information >> option and the node matches all of the predicates in the >> Solicited >> Information option." >> >> NEW: >> >> "o When a node receives a multicast DIS with a Solicited Information >> option and the node matches all of the predicates in the Solicited >> Information option (carried in the DIS option field) and/or (to be >> defined) fields of the Flag field are set." >> >> 2) DIS Packet Format >> >> OLD: >> >> "0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved | Option(s)... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Winter, et al. Expires December 30, 2010 >> [Page 30] >> Internet-Draft draft-ietf-roll-rpl-10 Jun >> 2010 >> >> >> Figure 9: The DIS Base Object >> >> " >> >> NEW: >> >> "0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Reserved | Flags | Option(s)... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Winter, et al. Expires December 30, 2010 >> [Page 30] >> Internet-Draft draft-ietf-roll-rpl-10 Jun >> 2010 >> >> >> Figure 9: The DIS Base Object >> >> " > > > I think this makes the whole thing more complicated. We now have > flags that indicate whether you should check a predicate within the > solicited information option, as well as flags in the DIS itself. > Suddenly we're doing the same thing in two places: that seems like a > mistake. I thought the agreement was to just add something to the > solicited information option? Let me try another approach: we just > need text that makes it clear one could just add a bit whose > predicate is always false. > > Phil From mcr@sandelman.ca Fri Jul 23 12:04:31 2010 Return-Path: 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 6B3833A67E2 for ; Fri, 23 Jul 2010 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 9fi5RDB+0vHl for ; Fri, 23 Jul 2010 12:04:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B687E3A68DC for ; Fri, 23 Jul 2010 12:04:29 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 8D4653477A for ; Fri, 23 Jul 2010 15:04:47 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E482B98A06 for ; Fri, 23 Jul 2010 15:02:29 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4C49441F.6030608@gmail.com> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> <064.acba84cbe6064a57b7445959a71cd421@tools.ietf.org> <4C48BC74.4000906@gmail.com> <658F47B7-7118-4469-928E-BF494FF215FF@cs.stanford.edu> <4C49441F.6030608@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 23 Jul 2010 15:02:29 -0400 Message-ID: <12935.1279911749@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #68: RPL security comments received during LC 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: , X-List-Received-Date: Fri, 23 Jul 2010 19:04:31 -0000 >>>>> "Alexandru" == Alexandru Petrescu writes: Alexandru> Ok. It is strange because the Security DT had a document Alexandru> Alexandru> http://tools.ietf.org/html/draft-ietf-roll-security-framework-00 This document was never even close to being complete. It just talked about abstracts. It never (nor has rpl-10) clearly explained what the threats are that we need to defend against. We have a LOT of text to write for the Security Considerations. We need to basically be saying: 1) if a message of type FOO, claiming BAR arrives, and it is accepted at face value (i.e. we ignore the security), then this results in an attacker being able to do 2) thus, messages of type FOO must always be secured. 3) if a message of type FRED, claiming BAZ arrives, and it is accepted at face value (i.e. we ignore the security), it has no effect, because we won't change state anyway without confirmation, so it's okay for messages of type FRED to be insecure. We will need to explain how the bootstrap process occurs, and what messages we have to take at face value from new leaf nodes in order that those leaf nodes can join the network sufficiently so that they can upgrade themselves to secured leaf, or router. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Fri Jul 23 12:06:49 2010 Return-Path: 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 F19473A683A for ; Fri, 23 Jul 2010 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 w2pvVEkm7ehi for ; Fri, 23 Jul 2010 12:06:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2B0713A67E2 for ; Fri, 23 Jul 2010 12:06:45 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 80848346EB for ; Fri, 23 Jul 2010 15:07:03 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C399098A06 for ; Fri, 23 Jul 2010 15:04:45 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 23 Jul 2010 15:04:45 -0400 Message-ID: <12982.1279911885@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Fri, 23 Jul 2010 19:06:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "JP" == JP Vasseur writes: JP> This is one of the comments that I send last week (ticket JP> 70). We had a discussion with the RPL authors yesterday (as JP> pretty much every week) to continue our work on the remaining I believe that this feature may be very useful to some, but not to all. As such, I think it is a very good example of what should be the first extension draft. It can be 3-4 pages long (80% boilerplate), and serve an example of how to do an extension. There are some clear advantages to doing this now: for instance it may motivate clarification of text on what one does with an option that one does not understand. (I haven't read that part of rpl-10 yet) Options might be: ignore the option copy the unknown option downstream drop the entire packet - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTEnnyYCLcPvd0N1lAQLj6wf+LkEjgWdXeO00oZmixbbsloLsALUh1KbI 3MPa4yc/Llm26dSZiti3Pt9fmaYAkYYd/NlarfQzAC1o9fe6CiCdIycv/PIMjG9l RPm1gYb5VT6WCoEyktXZMzegTNNW+usrnFUxbODAOqssf2RIPaTMaz8Ry6lfwzOd hIrzIakmvVBcL8ifXv0nGYuWf1Wr7DGzLmFVZqi78h+ExL3mxeTqQO6TS/aS7g83 AfiGn+qSANHxuINnv68MhLi/sb9Xv1JsP87rs1XuUcFMpNc9HyYc4L8DfysBP/+5 0/e3R+9QxS9T/gyq1nuH6Rq9u9Wec2Ducn8qwVkS77M1ezyX/i7MBw== =WqnL -----END PGP SIGNATURE----- From culler@cs.berkeley.edu Fri Jul 23 12:09:30 2010 Return-Path: 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 A7AB53A6952 for ; Fri, 23 Jul 2010 12:09:30 -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 4ncMRKWQ0xIw for ; Fri, 23 Jul 2010 12:09:29 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 8C2963A68D6 for ; Fri, 23 Jul 2010 12:09:29 -0700 (PDT) Received: from dhcp-45-99.eecs.berkeley.edu (dhcp-45-99.EECS.Berkeley.EDU [128.32.45.99]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6NIlFYH026251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 23 Jul 2010 11:47:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> Date: Fri, 23 Jul 2010 11:47:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1081) Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Fri, 23 Jul 2010 19:09:30 -0000 While the various companies that have disclosed IPR relative to RPL have = been generous in enabling the standard to move forward, it behooves us = to do everything we can to create standards that do not require = proprietary IP to achieve interoperable implementations. It seems clear = that we should pursue a variant of 2. We should complete the core spec = utilizing a security scheme that is unencumbered. We should make sure = that there is enough room in the encoding that we may consider more = highly optimized schemes later. In that time, we can sort out IPR = issues. With so many signature schemes already well established it = would be very surprising that we simply cannot use any of them. The = disclosed IPR may provide substantial improvements, but that is = certainly a secondary concern. Can the security DT suggest one or more such openly available options. On Jul 22, 2010, at 4:41 PM, Philip Levis wrote: > Summary: This mail describes the current status of signature schemes = in RPL, presents three options for going forward, and asks the WG to = discuss and reach consensus on how to proceed. >=20 > Background > ------------- >=20 > Currently RPL has a single security algorithm configuration: >=20 > = +-------+-------------------+--------------------------------------+ > | ID | Encryption/MAC | Signature = | > = +-------+-------------------+--------------------------------------+ > | 0 | CCM* with AES-128 | ECPVS with K-283, Matyas-Meyer-Oseas = | > | 1-255 | Reserved | Reserved = | > = +-------+-------------------+--------------------------------------+ >=20 > The Signature scheme described is encumbered by IPR held by Certicom. = Rene, as a major contributor to the security parts of RPL, disclosed = this IPR through the standard IETF process. Rene does not currently work = for Certicom, although he did in the past. The particular scheme was = chosen because of its technical advantages in LLNs: short signatures = which are inexpensive to compute compared to many other signature = schemes. >=20 > Going Forward > -------------------------- >=20 > The security DT sees three possible paths going forward: >=20 > 1) Keep the Algorithm options as they are now: the only signature = scheme supported in the base RPL specification is encumbered by IPR. = Let's call this the "IPR" option. >=20 > 2) Keep a single Algorithm (ID=3D0) in the base RPL specification, = but change Algorithm ID=3D0's signature scheme to one that we believe is = unencumbered by IPR. Let's call this the "No-IPR" option. >=20 > 3) Keep the current Algorithm (ID=3D0), and add a second Algorithm = (ID=3D1) to have the same Encryption/MAC scheme as ID=3D0 (CCM* with = AES-128) but a signature scheme we believe is unencumbered by IPR. Let's = call this the "Both" option. >=20 > We are currently investigating which signature scheme unencumbered by = IPR would best meet the requirements of LLNs. We expect to have reached = a conclusion on this by the end of this week. It's our opinion that = which exact algorithm is chosen should be considered independently of = the three options above (under the assumption that it is unencumbered by = IPR). >=20 > Discussion > ------------------- >=20 > The security DT would like guidance from the WG on which of the three = options it should pursue. Given that we are in last call and are meeting = next week, let's try to keep the discussion focused and on-topic so we = can reach consensus quickly. >=20 > Phil >=20 From jpv@cisco.com Fri Jul 23 12:48:53 2010 Return-Path: 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 771FC3A6878 for ; Fri, 23 Jul 2010 12:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ISczJwYw8u2M for ; Fri, 23 Jul 2010 12:48:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 25E103A6876 for ; Fri, 23 Jul 2010 12:48:52 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsGAM6OSUyrRN+J/2dsb2JhbACBRIRQmVVxp0OMZY4fhTYEiGCCOg Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 19:49:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6NJn9Nq011008; Fri, 23 Jul 2010 19:49:10 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 21:49:09 +0200 Received: from [192.168.1.11] ([10.61.111.197]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 21:49:08 +0200 Message-Id: <967807F6-FB7F-403B-A39B-F99579ACB1F7@cisco.com> From: JP Vasseur To: Michael Richardson In-Reply-To: <12982.1279911885@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary=Apple-Mail-73-959637007 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 21:49:07 +0200 References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> <12982.1279911885@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Jul 2010 19:49:08.0469 (UTC) FILETIME=[1D49A250:01CB2AA0] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17524.001 X-TM-AS-Result: No--41.659000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll WG Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Fri, 23 Jul 2010 19:48:53 -0000 --Apple-Mail-73-959637007 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Michael, On Jul 23, 2010, at 9:04 PM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "JP" == JP Vasseur writes: > JP> This is one of the comments that I send last week (ticket > JP> 70). We had a discussion with the RPL authors yesterday (as > JP> pretty much every week) to continue our work on the remaining > > I believe that this feature may be very useful to some, but not to > all. > As such, I think it is a very good example of what should be the first > extension draft. It can be 3-4 pages long (80% boilerplate), and > serve > an example of how to do an extension. The point is also that having a number of short RFCs makes the overall picture hard to get. Again we are talking about a field flag, that's all. > > There are some clear advantages to doing this now: for instance it may > motivate clarification of text on what one does with an option that > one > does not understand. (I haven't read that part of rpl-10 yet) This is actually clearly stated (since you're right saying that such text is required): When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in the message. Thanks for your feed-back. JP. > > Options might be: > ignore the option > copy the unknown option downstream > drop the entire packet > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBTEnnyYCLcPvd0N1lAQLj6wf+LkEjgWdXeO00oZmixbbsloLsALUh1KbI > 3MPa4yc/Llm26dSZiti3Pt9fmaYAkYYd/NlarfQzAC1o9fe6CiCdIycv/PIMjG9l > RPm1gYb5VT6WCoEyktXZMzegTNNW+usrnFUxbODAOqssf2RIPaTMaz8Ry6lfwzOd > hIrzIakmvVBcL8ifXv0nGYuWf1Wr7DGzLmFVZqi78h+ExL3mxeTqQO6TS/aS7g83 > AfiGn+qSANHxuINnv68MhLi/sb9Xv1JsP87rs1XuUcFMpNc9HyYc4L8DfysBP/+5 > 0/e3R+9QxS9T/gyq1nuH6Rq9u9Wec2Ducn8qwVkS77M1ezyX/i7MBw== > =WqnL > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-73-959637007 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Michael,

On Jul 23, 2010, at 9:04 PM, Michael = Richardson wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1


"JP" =3D=3D JP Vasseur <jpv@cisco.com> = writes:
   JP> This is one of the comments that I send last = week (ticket
   JP> 70). We had a discussion with = the RPL authors yesterday (as
   JP> pretty much = every week) to continue our work on the remaining

I believe that = this feature may be very useful to some, but not to all.
As such, I = think it is a very good example of what should be the first
extension = draft.  It can be 3-4 pages long (80% boilerplate), and serve
an = example of how to do an = extension.

The point is also = that having a number of short RFCs makes the = overall 
picture hard to get. Again we are talking about = a field flag, that's all. 


There are some clear advantages to doing this = now: for instance it may
motivate clarification of text on what one = does with an option that one
does not understand. (I haven't read = that part of rpl-10 yet)

This = is actually clearly stated (since you're right saying that such text is = required):

   When processing a RPL message =
containing an option for which the
   Option Type value is not recognized by the receiver, the receiver
   MUST silently ignore the unrecognized option and continue to process
   the following option, correctly handling any remaining options in the
   message.


Thanks for your = feed-back.

JP.


Options might be:
 ignore the option =     
 copy the unknown option = downstream
 drop the entire packet

- --
] =       He who is tired of Weird Al is tired = of life!           | =  firewalls  [
]   Michael Richardson, Sandelman = Software Works, Ottawa, ON    |net architect[
] = mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on= .ca/ |device driver[
  Kyoto Plus: watch the video = <http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE>
=             &n= bsp; then sign the petition.
-----BEGIN PGP = SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Finger = me for = keys

iQEVAwUBTEnnyYCLcPvd0N1lAQLj6wf+LkEjgWdXeO00oZmixbbsloLsALUh1K= bI
3MPa4yc/Llm26dSZiti3Pt9fmaYAkYYd/NlarfQzAC1o9fe6CiCdIycv/PIMjG9l
= RPm1gYb5VT6WCoEyktXZMzegTNNW+usrnFUxbODAOqssf2RIPaTMaz8Ry6lfwzOd
hIrzIa= kmvVBcL8ifXv0nGYuWf1Wr7DGzLmFVZqi78h+ExL3mxeTqQO6TS/aS7g83
AfiGn+qSANHx= uINnv68MhLi/sb9Xv1JsP87rs1XuUcFMpNc9HyYc4L8DfysBP/+5
0/e3R+9QxS9T/gyq1n= uH6Rq9u9Wec2Ducn8qwVkS77M1ezyX/i7MBw=3D=3D
=3DWqnL
-----END PGP = SIGNATURE-----
_______________________________________________
Roll = mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-73-959637007-- From pthubert@cisco.com Sat Jul 24 01:46:50 2010 Return-Path: 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 25CE03A6993 for ; Sat, 24 Jul 2010 01:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ArY8JtxErEGe for ; Sat, 24 Jul 2010 01:46:37 -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 94AD63A679F for ; Sat, 24 Jul 2010 01:46:37 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,252,1278288000"; d="scan'208,217";a="563140913" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2010 08:46:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6O8kth2018800; Sat, 24 Jul 2010 08:46:55 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 10:46:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2B0C.C40501A5" Date: Sat, 24 Jul 2010 10:46:50 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AEF2@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: closing Ticket #64 thread-index: AcsrDMA70hq9c2ByRA60I66AOPvSSg== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 24 Jul 2010 08:46:54.0643 (UTC) FILETIME=[C47EB030:01CB2B0C] Subject: [Roll] closing Ticket #64 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: , X-List-Received-Date: Sat, 24 Jul 2010 08:46:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2B0C.C40501A5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: =20 Long discussions lead to specify only the location of the RPLinstanceID = inside the RPL network, leaving it to policies the way the ingress = router figures it out. The RPLinstanceID will be placed in the RPL = option which is probably the cleanest and most generic thing we can do. = Other drafts are allowed to come later and provide alternate forwarding = rules eventually placing the content of the RPL option validation = somewhere else, for instance in order to avoid IPinIP. A forwarding mode = will probably indicate what the network does. =20 Proposed changes: =20 RPL uses a hop-by-hop IPv6 header to detect possible loops within a DODAG.=20 -> RPL carries routing information in a RPL Option contained = in an IPv6 =20 Hop-by-Hop Option as specified in = [I-D.hui-6man-rpl-option]. Such = routing information are used for example for loop = detection within a =20 DODAG as discussed in Section 11.2 and may be extended = in future =20 documents for additional features. = =20 =20 =20 For data packets, the RPLInstanceID may be indicated in the flow label by the source of the packet. If it is not, then it is inferred and added by the RPL network ingress router in the RPL Hop-by-hop option ([I-D.hui-6man-rpl-option]) as further described in Section 10.2 =20 =E8 =20 =20 Data packet that flow within the RP network expose the = RPLInstanceID =20 in the RPL option that is specified in = [I-D.hui-6man-rpl-option], and =20 further described in Section 11.2. For data packets = coming from =20 outside the RPL network, the RPLInstanceID is determined = by the RPL =20 network ingress router and placed in the RPL option that = is added to =20 the packet. =20 =20 RPL loop detection uses information that is placed into the packet. = =20 A future version of this specification will detail how this information is carried with the packet (e.g. a hop-by-hop option ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow label). For the purpose of RPL operations, the information carried with a packet is constructed follows: =20 =E8 =20 RPL loop detection uses information that contained within = the data =20 packet using the RPL Option [I-D.hui-6man-rpl-option]) in an = IPv6 =20 Hop-by-Hop Option header. The RPL Option is a generic = container for =20 a list of TLVs. This specification defines a new RPL = Option type, =20 called the RPL Loop Detection. The RPL Loop Detection = TLV is placed =20 in the RPL Option with Option Type =3D 1 (to be = confirmed by IANA), =20 Option Data Length =3D 4 octets, and the Value has the = following =20 format: =20 =20 =20 =20 The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For traffic originating = =20 outside of the RPL domain there may be a mapping occurring at the = gateway into the RPL domain, possibly based on an encoding within the flow label. This aspect of RPL operation is to be clarified in a future version of this specification. =20 The source of the packet might be aware of the RPL network, of the constraints imposed on OFs, and of associated Instance IDs. In that case, the source of the packet MAY tag the flow label with the RPLInstanceID, in which case it is used in that form within the RPL network. =20 A router that injects a data packet into the RPL network MUST tag the packet by inserting a RPL Hop-by-hop option as specified in [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the = =20 packet into the RPL network MUST add a RPLInstanceID field to the RPL = =20 Hop-by-hop option. =20 =20 =E8 =20 The RPLInstanceID is associated by the source with the = packet. This =20 RPLInstanceID MUST match the RPL Instance onto which the = packet is =20 placed by any node, be it a host or router. =20 =20 For a packet that is originated from outside the RPL = network, the =20 source of the packet might be aware of the RPL network, = of the =20 constraints imposed on OFs, and of associated = RPLInstanceIDs. In =20 that case, the source of the packet MAY tag the flow = label with the =20 RPLInstanceID. =20 =20 A RPL router that forwards a packet in the RPL network = MUST check if =20 the packet includes the RPL Loop Detection TLV in a RPL = Option within =20 the IPv6 Hop-by-Hop Option header. If one does not = exist, the RPL =20 router MUST insert a RPL Loop Detection type as = specified in =20 =20 =20 [I-D.hui-6man-rpl-option]. If the router is an ingress = router that =20 injects the packet into the RPL network, the router MUST = set the =20 RPLInstanceID field in the RPL Loop Detection TLV. = =20 =20 =20 As usual, please speak up if there's an issue with the proposed = resolution! =20 Pascal =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Saturday, July 24, 2010 12:02 AM To: Pascal Thubert (pthubert) Subject: Re: Ticket #64 and Summary of our discussion today =20 could you please provide the final text then ? =20 Thanks Pascal. =20 On Jul 23, 2010, at 4:13 PM, Pascal Thubert (pthubert) wrote: Hi JP; =20 I did the same in parallel; I changed very little as below. Please = review; I'm resending the ready to forward mail to this list... =20 Pascal =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Friday, July 23, 2010 1:46 PM To: Tim Winter; Pascal Thubert (pthubert); Jonathan Hui; = rpl-authors@external.cisco.com Subject: Re: Ticket #64 and Summary of our discussion today =20 OK here is the new text to close Ticket #64 -=20 =20 I combined the text from Pascal, Jonathan + my suggestions. =20 All please let us know today is you agree, then I will close that = ticket. =20 Text to include in ticket #64 for closing ############################### =20 Please find below the various changes to close ticket #64 =20 The definition and provisioning of RPL instances are beyond the scope of this specification. Those operations are expected to be such that data packets coming from the outside of the RPL network can unambiguously be associated to at least one RPL instance, and be safely routed over any instance that would match the packet. Information used to match a packet to a RPL instance can typically be taken from fields in the IPv6 header, like the flow label, differentiated services (DS) field, or destination address. =20 Control and data packets within RPL network are tagged to unambiguously identify what RPL Instance they are part of. =20 Every RPL control message has a RPLInstanceID field. Some RPL control messages, when referring to a local RPLInstanceID as defined below, may also include a DODAGID. =20 Data packets that flow within the RPL domain expose the RPLInstanceID in the RPL Hop-by-hop option that is specified in [I-D.ietf-6man-rpl-option],and further described in Section 11.2. For data packets coming from outside the RPL network, the RPLInstanceID is determined by the RPL network ingress router and placed in a RPL Hop-by-hop option that is added to the packet." [Pascal] removed hop-by-hop per Jonathan's point Data packet that flow within the RP network expose the RPLInstanceID in the RPL option that is specified in , and further described in . For data packets coming from outside the RPL network, the = RPLInstanceID is determined by the RPL network ingress router and placed = in the RPL option that is added to the packet. " Data packet that flow within the RP network expose the RPLInstanceID in the RPL option that is specified in [I-D.hui-6man-rpl-option], and further described in Section 11.2. For data packets coming from outside the RPL network, the RPLInstanceID is determined by the RPL network ingress router and placed in the RPL option that is added to the packet. =20 " Then ... =20 3.3.7. Datapath Validation and Loop Detection =20 RPL uses a hop-by-hop IPv6 header to detect possible loops within a = DODAG. --> =20 RPL carried routing information in a RPL Option contained in an IPv6 Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-routing-header]. Such routing information are used for example for loop detection within a DODAG as discussed in Section 10.2 and subject to additional = information defined in future document. =20 [Pascal] carried -> carries [Pascal] and subject to additional information defined in future = document. -> and may be extended in future documents for additional features. =20 =20 5. RPL Instance =20 and added by the RPL network ingress router in the RPL Hop-by-hop = option =20 --> and added by the RPL network ingress router in the RPL Option =20 [Pascal] This is actually the first change in the mail above. Do I miss = something like a dup? =20 8.2.2.5. Poisoning =20 whose hop-by-hop option ([I-D.hui-6man-rpl-option]) includes a Rank --> whose RPL Option ([I-D.hui-6man-rpl-option]) includes a Rank =20 [Pascal] done =20 11.2. Loop Avoidance and Detection =20 RPL loop detection uses information that is placed into the packet. A future version of this specification will detail how this information is carried with the packet (e.g. a hop-by-hop option ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow label). For the purpose of RPL operations, the information carried with a packet is constructed follows: --> RPL loop detection uses information that contained within the data packet using the RPL Option [I-D.hui-6man-rpl-option] in an IPv6 Hop-by-Hop Option header. The RPL Option is a generic container for a list of TLVs. This specification defines a new RPL Option type, called the RPL Loop Detection. The RPL loop Detection TLV has the=20 following format, with type=3D1 (to be confirmed by IANA). =20 HERE INSET THE FORMAT [Pascal] as is =20 =20 11.2.2.1. Instance Forwarding =20 A router that injects a data packet into the RPL network MUST insert a = RPL Hop-by-hop option as specified in [I-D.ietf-6man-rpl-option]. =20 If the RPLInstanceID is not present in flow label of the data packet, = the ingress=20 router that injects the packet into the RPL network MUST add a = RPLInstanceID=20 field to the RPL Hop-by-hop option. =20 --> =20 A RPL router that forwards a packet in the RPL domain MUST check if the packet includes the RPL Loop Detection TLV in a RPL Option with the IPv6 Hop-by-Hop Option header. If one does not exist, the RPL = router MUST insert a RPL Loop Detection type as specified in = [I-D.ietf-6man-rpl-option]. =20 A router that forwards a packet to outside the RPL network MUST remove the RPL Hop-by-hop option. --> =20 A router that forwards a packet to outside the RPL domain MUST remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. [Pascal] as is. =20 =20 ------_=_NextPart_001_01CB2B0C.C40501A5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

Long discussions lead to specify only the location of the = RPLinstanceID inside the RPL network, leaving it to policies the way the = ingress router figures it out. The RPLinstanceID will be placed in the = RPL option which is probably the cleanest and most generic thing we can = do. Other drafts are allowed to come later and provide alternate = forwarding rules eventually placing the content of the RPL option = validation somewhere else, for instance in order to avoid IPinIP. A = forwarding mode will probably indicate what the network = does.

 

Proposed changes:

 

RPL uses=A0 a hop-by-hop IPv6 header to detect possible loops within = a

DODAG.

->

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RPL carries routing information = in a RPL Option contained in an=A0 IPv6=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hop-by-Hop Option as = specified in [I-D.hui-6man-rpl-option]. = Such=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 routing information are = used for example for loop detection within = a=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DODAG as discussed in = Section 11.2 and may be extended in = future=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 documents for = additional = features.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

 

 

For data packets, the RPLInstanceID may be indicated in the = flow

label by the source of the packet. If it is not, then it is = inferred

and added by the RPL network ingress router in the RPL = Hop-by-hop

option ([I-D.hui-6man-rpl-option]) as further described = in

Section 10.2

 

=E8  

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Data packet that flow within the = RP network expose the RPLInstanceID=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in the RPL option that = is specified in [I-D.hui-6man-rpl-option], = and=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 further described in = Section 11.2. For data packets coming = from=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 outside the RPL = network, the RPLInstanceID is determined by the = RPL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 network ingress router = and placed in the RPL option that is added = to=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the = packet.

 

 

RPL loop detection uses information that is placed into the = packet.=A0=A0=A0=A0=A0=A0=A0=A0=A0

A future version of this specification will detail how = this

information is carried with the packet (e.g. a hop-by-hop = option

([I-D.hui-6man-rpl-option]) or summarized somehow into the = flow

label). For the purpose of RPL operations, the information = carried

with a packet is constructed follows:

 

=E8  

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RPL loop detection uses information = that contained within the data=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0packet using the RPL Option = [I-D.hui-6man-rpl-option]) in an = IPv6=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hop-by-Hop Option = header. The RPL Option is a generic container = for=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a list of TLVs. This = specification defines a new RPL Option = type,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 called the RPL Loop = Detection. The RPL Loop Detection TLV is = placed=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in the RPL Option with = Option Type =3D 1 (to be confirmed by = IANA),=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Option Data Length =3D = 4 octets, and the Value has the = following=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = format:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0

 

 

The RPLInstanceID is associated by the source with the packet. = This

RPLInstanceID MUST match the RPL Instance onto which the packet = is

placed by any node, be it a host or router. For traffic = originating=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

outside of the RPL domain there may be a mapping occurring at = the=A0=A0=A0=A0=A0=A0=A0

gateway into the RPL domain, possibly based on an encoding within = the

flow label. This aspect of RPL operation is to be clarified in = a

future version of this specification.

 

The source of the packet might be aware of the RPL network, of = the

constraints imposed on OFs, and of associated Instance IDs. In = that

case, the source of the packet MAY tag the flow label with = the

RPLInstanceID, in which case it is used in that form within the = RPL

network.

 

A router that injects a data packet into the RPL network MUST tag = the

packet by inserting a RPL Hop-by-hop option as specified = in

[I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present = in

flow label of the data packet, the ingress router that injects = the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

packet into the RPL network MUST add a RPLInstanceID field to the = RPL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

Hop-by-hop option.=A0=A0=A0=A0=A0=A0=A0

 

=E8  

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The RPLInstanceID is associated = by the source with the packet. This=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RPLInstanceID MUST = match the RPL Instance onto which the packet = is=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 placed by any node, be = it a host or router.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 For a packet that is = originated from outside the RPL network, = the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 source of the packet = might be aware of the RPL network, of = the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 constraints imposed on = OFs, and of associated RPLInstanceIDs. = In=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that case, the source = of the packet MAY tag the flow label with = the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = RPLInstanceID.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A RPL router that = forwards a packet in the RPL network MUST check = if=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the packet includes the = RPL Loop Detection TLV in a RPL Option = within=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the IPv6 Hop-by-Hop = Option header. If one does not exist, the = RPL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 router MUST insert a = RPL Loop Detection type as specified = in=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = [I-D.hui-6man-rpl-option]. If the router is an ingress router = that=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 injects the packet into = the RPL network, the router MUST set = the=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RPLInstanceID field in = the RPL Loop Detection = TLV.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0

As usual, please speak up if there’s an issue with the proposed = resolution!

 

Pascal

 

From:= JP Vasseur = [mailto:jpv@cisco.com]
Sent: Saturday, July 24, 2010 12:02 = AM
To: Pascal Thubert (pthubert)
Subject: Re: Ticket = #64 and Summary of our discussion = today

 

could you = please provide the final text then ?

 

Thanks Pascal.

 

On = Jul 23, 2010, at 4:13 PM, Pascal Thubert (pthubert) = wrote:



Hi JP;

 

I did the same in parallel; I changed very little as below. Please = review; I’m resending the ready to forward mail to this = list…

 

Pascal

 

= From:=  = JP Vasseur [mailto:jpv@cisco.com] 
Sent: Friday, July 23, 2010 1:46 = PM
To: Tim = Winte= r; Pascal Thubert (pthubert); Jonathan Hui; rpl-authors@external.cisco= .com
Subject: Re: Ticket #64 and Summary of = our discussion today

 

OK here is the new text to = close Ticket #64 - 

 

<= p class=3DMsoNormal>I combined the text from = Pascal, Jonathan + my = suggestions.

 

<= p class=3DMsoNormal>All please let us know = today is you agree, then I will close that ticket.

 

<= p class=3DMsoNormal>Text to include in = ticket #64 for closing

###############################

 

<= p class=3DMsoNormal>Please find below the = various changes to close ticket = #64

 

<= p class=3DMsoNormal> The definition and = provisioning of RPL instances are beyond the = scope

 of this = specification.  Those operations are expected to be such = that

 data packets coming = from the outside of the RPL network = can

 unambiguously be = associated to at least one RPL instance, and = be

 safely routed over any instance that would = match the packet.

 Information used to = match a packet to a RPL instance can typically = be

 taken from fields in the IPv6 header, like = the flow label,

 differentiated = services (DS) field, or destination = address.

 

<= p class=3DMsoNormal> Control and data = packets within RPL network are tagged = to

 unambiguously identify what RPL Instance = they are part of.

 

<= p class=3DMsoNormal> Every RPL control = message has a RPLInstanceID field.  Some = RPL

 control messages, = when referring to a local RPLInstanceID as = defined

 below, may also = include a DODAGID.

 

<= p class=3DMsoNormal> Data packets that = flow within the RPL domain expose = the

 RPLInstanceID in the = RPL Hop-by-hop option that is specified = in

 [I-D.ietf-6man-rpl-option],and further = described in Section 11.2.

 For data packets = coming from outside the RPL network, = the

 RPLInstanceID is = determined by the RPL network ingress = router

 and placed in a RPL = Hop-by-hop option that is added to = the

 packet."

[Pascal] removed hop-by-hop per Jonathan’s = point

      <t>Data packet that flow within = the RP network expose the

            =   RPLInstanceID in the RPL option that is specified = in

            =   <xref = target=3D"I-D.hui-6man-rpl-option"></xref>,

            =   and further described in <xref = target=3D"loopdetect"></xref>.

            =   For data packets coming from outside the RPL network, the = RPLInstanceID

            =   is determined by the RPL network ingress router and placed in the = RPL

           &nbs= p;    option that is added to the packet.

“

   Data packet that flow within the RP network expose the = RPLInstanceID

   in the RPL option that is specified in = [I-D.hui-6man-rpl-option], and

   further described in Section 11.2.  For data packets = coming from

   outside the RPL network, the RPLInstanceID is determined = by the RPL

   network ingress router and placed in the RPL option that = is added to

   the packet.

 

“

Then = ...

 

<= p class=3DMsoNormal>3.3.7.  Datapath = Validation and Loop = Detection

 

<= p class=3DMsoNormal> RPL uses a = hop-by-hop IPv6 header to detect possible loops within = a DODAG.

-->

<= p class=3DMsoNormal> 

<= p class=3DMsoNormal>RPL carried routing = information in a RPL Option contained in an = IPv6

Hop-by-Hop Option as = specified in [I-D.ietf-6man-rpl-routing-header].
Such routing = information are used for example for loop detection within
a DODAG as = discussed in Section 10.2 and subject to additional = information
defined in future = document.

 

[Pascal] carried -> carries

[Pascal] and subject to additional information defined in future = document.

->

and may be extended in future  documents for additional = features.

 

 

5.  RPL = Instance

 

<= p class=3DMsoNormal> and added by the = RPL network ingress router in the RPL = Hop-by-hop option

 

<= p class=3DMsoNormal>--> and added by = the RPL network ingress router in the RPL = Option

 

[Pascal] This is actually the first change in the mail above. Do I = miss something like a dup?

 

8.2.2.5. =  Poisoning

 

<= p class=3DMsoNormal> whose hop-by-hop = option ([I-D.hui-6man-rpl-option]) includes a = Rank

-->

<= p class=3DMsoNormal> whose RPL Option = ([I-D.hui-6man-rpl-option]) includes a = Rank

 

[Pascal] done

 

11.2.  Loop Avoidance = and Detection

 

<= p class=3DMsoNormal> RPL loop detection = uses information that is placed into the = packet.

 A future version of = this specification will detail how = this

 information is = carried with the packet (e.g. a hop-by-hop = option

 ([I-D.hui-6man-rpl-option]) or summarized = somehow into the flow

 label).  For = the purpose of RPL operations, the information = carried

 with a packet is = constructed follows:

-->

<= p class=3DMsoNormal> RPL loop detection = uses information that contained within the = data

 packet using the RPL = Option [I-D.hui-6man-rpl-option] in an = IPv6

 Hop-by-Hop Option = header.  The RPL Option is a generic container = for

 a list of TLVs. =  This specification defines a new RPL Option = type,

 called the RPL Loop = Detection.  The RPL loop Detection TLV has = the 

following = format, with type=3D1 (to be confirmed by = IANA).

 

<= p class=3DMsoNormal>HERE INSET THE = FORMAT

[Pascal] as is

 

 

<= p class=3DMsoNormal>11.2.2.1.  Instance = Forwarding

 

<= p class=3DMsoNormal>A router that injects a = data packet into the RPL network MUST insert a = RPL

Hop-by-hop option as = specified in = [I-D.ietf-6man-rpl-option].

 

<= p class=3DMsoNormal>If the RPLInstanceID is = not present in flow label of the data packet, the = ingress 

router that injects = the packet into the RPL network MUST add a = RPLInstanceID 

field to the = RPL Hop-by-hop = option.

 

<= p class=3DMsoNormal>-->

<= p class=3DMsoNormal> 

<= p class=3DMsoNormal>A RPL router that = forwards a packet in the RPL domain MUST check = if

 the packet includes the RPL Loop Detection = TLV in a RPL Option = with

 the IPv6 = Hop-by-Hop Option header.  If one does not exist, the RPL = router

 MUST insert a RPL Loop Detection = type as specified in = [I-D.ietf-6man-rpl-option].

 

<= p class=3DMsoNormal> A router that = forwards a packet to outside the RPL network = MUST

 remove the RPL = Hop-by-hop option.

-->

<= p class=3DMsoNormal> 

<= p class=3DMsoNormal> A router that = forwards a packet to outside the RPL domain = MUST

 remove the RPL = Option as specified in = [I-D.ietf-6man-rpl-option].

[Pascal] as is.

 

 

------_=_NextPart_001_01CB2B0C.C40501A5-- From trac@tools.ietf.org Sat Jul 24 01:59:37 2010 Return-Path: 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 18A863A699A for ; Sat, 24 Jul 2010 01:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 6VH1H5qhrD5l for ; Sat, 24 Jul 2010 01:59:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C509E3A689E for ; Sat, 24 Jul 2010 01:59:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcaaI-0005Tf-PY; Sat, 24 Jul 2010 01:59:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: richard.kelsey@ember.com, jpv@cisco.com X-Trac-Project: roll Date: Sat, 24 Jul 2010 08:59:54 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/57#comment:1 Message-ID: <064.bea1c933076c2e62a2697abd0278e1b6@tools.ietf.org> References: <055.3e4b6aebd2ab17460a59e9c452c3da42@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <055.3e4b6aebd2ab17460a59e9c452c3da42@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: richard.kelsey@ember.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #57: Proposed change: Routing DAOs in non-storing DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 08:59:37 -0000 #57: Proposed change: Routing DAOs in non-storing DODAGs -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: richard.kelsey@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: RPL-11 has been updated to allow a DAO to be sent to a DODAG root in non-storing mode as follows: Terminology: DODAGID: The identifier of a DODAG root. The DODAGID is unique within the scope of a RPL Instance in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. ----- DAO Message: Destination Advertisement Object (DAO) The Destination Advertisement Object (DAO) is used to propagate destination information upwards along the DODAG. In storing mode the DAO message is unicast by the child to the selected parent(s). In non-storing mode the DAO message is unicast to the DODAG root. The DAO message may optionally, upon explicit request or error, be acknowledged by its destination with a Destination Advertisement Acknowledgement (DAO-ACK) message back to the sender of the DAO. ..... K: The 'K' flag indicates that the recipient is expected to send a DAO-ACK back. (See Section 9.3 D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. DAOSequence: Incremented at each unique DAO message from a node and echoed in the DAO-ACK message. ..... A special case of the DAO message, termed a No-Path, is used in storing mode to clear downward routing state that has been provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target. ----- DAO-ACK message: The DAO-ACK message is sent as a unicast packet by a DAO recipient (a DAO parent or DODAG root) in response to a unicast DAO message. ..... DAOSequence: Incremented at each DAO message from a node, and echoed in the DAO-ACK by the recipient. The DAOSequence is used to correlate a DAO message and a DAO ACK message and is not to be confused with the Transit Information option Path Sequence that is associated to a given target down the DODAG. ----- Transit Information option: A typical non-storing node will use multiple Transit Information options, and it will send the DAO message thus formed directly to the root. A typical storing node will use one Transit Information option with no parent field, and will send the DAO message thus formed, with additional adjustments to Path Control as detailed later, to one or multiple parents. ----- DIO Base Rules: 3. The DODAGID field each root sets MUST be unique within the RPL Instance and MUST be a routable IPv6 address belonging to the root. ----- Destination Advertisement Parents: To establish downward routes, RPL nodes send DAO messages upwards. The next hop destinations of these DAO messages are called DAO parents. The collection of a node's DAO parents is called the DAO parent set. 1. A node's DAO parent set MUST be a subset of its DODAG parent set. 2. In storing mode operation, a node MUST NOT send unicast DAO messages to nodes that are not DAO parents. 3. In non-storing mode operation, a node MUST NOT send unicast DAO messages to nodes that are not DODAG roots. 4. A node MUST NOT forward unicast DAO messages to nodes that are not DAO parents. 5. A node MAY send DAO messages using the all-RPL-nodes multicast address, which is an optimization to provision one-hop routing. The 'K' bit SHOULD be cleared on transmission of the multicast DAO. 6. The IPv6 Source Address of a DAO message MUST be the link local address of the sending node. -- Ticket URL: roll From alexandru.petrescu@gmail.com Sat Jul 24 02:20:21 2010 Return-Path: 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 491383A69A4 for ; Sat, 24 Jul 2010 02:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.972 X-Spam-Level: X-Spam-Status: No, score=-0.972 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_05=-1.11, 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 Csa0aogn58Ct for ; Sat, 24 Jul 2010 02:20:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 83C233A69A0 for ; Sat, 24 Jul 2010 02:20:17 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id ECA8D940128; Sat, 24 Jul 2010 11:20:28 +0200 (CEST) Message-ID: <4C4AB059.3080107@gmail.com> Date: Sat, 24 Jul 2010 11:20:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> In-Reply-To: <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100724-0, 24/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Sat, 24 Jul 2010 09:20:21 -0000 Le 23/07/2010 18:22, Philip Levis a écrit : > > On Jul 23, 2010, at 12:34 AM, Alexandru Petrescu wrote: > >> Le 23/07/2010 02:09, Philip Levis a écrit : > > >> >>> This flexibility is because some LLNs have security mechanisms >>> (e.g., link layer) which can render the RPL ones superfluous, >>> therefore optional. >> >> I agree. When link layer security is relied upon then we should >> state so, in the draft, with the names of the link layer security. >> >>> One of the stated design goals from the beginning is that RPL >>> should not require security mechanisms when they are not needed. >> >> Is this reflected in the draft? > > Alex, I think these discussions might be more productive if you read > the RPL draft, as well as the motivating application drafts, before > making forceful comments about how RPL should work. > > 3.3.3. Security > > RPL supports message confidentiality and integrity. It is designed > such that link-layer mechanisms can be used when available and > appropriate, yet in their absence RPL can use its own mechanisms. RPL > has three basic security modes. Thanks Phil for pointing to this text specifically. I will also follow private indications to read the document. Link layer security being reflected in the draft would mean to name that link layer security, the protocol and algorithm names specific to that link layer security. I think currently it doesn't... For example it never says the name of that particular link layer, or at least I can not find it. I may need to search more. Alex > > > Phil From alexandru.petrescu@gmail.com Sat Jul 24 02:32:03 2010 Return-Path: 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 36B8E3A686C for ; Sat, 24 Jul 2010 02:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-0.755, 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 oq4t+F1SGOga for ; Sat, 24 Jul 2010 02:31:59 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 37A2F3A69B1 for ; Sat, 24 Jul 2010 02:31:51 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3F0BF9400AA for ; Sat, 24 Jul 2010 11:32:04 +0200 (CEST) Message-ID: <4C4AB311.2000907@gmail.com> Date: Sat, 24 Jul 2010 11:32:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <6427.1278635611@marajade.sandelman.ca> <39D6B8E1-CD63-489E-97E3-A43407ED92C8@cs.stanford.edu> <4C37690B.50608@gmail.com> In-Reply-To: <4C37690B.50608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100724-0, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] unsigned integer MUST be at least 6 octets long? 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: , X-List-Received-Date: Sat, 24 Jul 2010 09:32:03 -0000 Has this nit been solved somehow? Are there any opinions or reasons to ignore this nit? The nit is the draft to wrongly consider an unsigned integer at least 6 octet long, because this makes impossible to use unsigned integers 4 octet longs (which are a default on many platforms). Alex Le 09/07/2010 20:23, Alexandru Petrescu a écrit : > A nit: > >> In the simplest case, the Counter value is an unsigned integer >> that a node increments by one or more on each secured RPL >> transmission. The Counter MAY represent a timestamp that has the >> following properties: >> >> 1. The timestamp MUST be at least six octets long. > > One would expect to read here 'four' instead of 'six'. > > On many platforms simply saying "int i;" defaults to 4-octet. With > that "MUST" this default is ruled out, making it a contradiction: > implementer reads 'unsigned integer' and thinks 'C int' - yet it is > forbidden to be a 'C int'. > > C unsigned integers are very often 2, 4, 8, 16 octets long and very > rarely 6 (I have never seen a 6-octet unsigned int actually). > > Alex > > > Le 09/07/2010 19:25, Philip Levis a écrit : >> Comments inline. Rene, there are 3-4 questions for you to answer. >> Please take a look. >> >> On Jul 8, 2010, at 5:33 PM, Michael Richardson wrote: >> >>> >>> {I have a lot of comments here on rpl-10, mostly about the >>> security stuff present since rpl-09} >>> >>> Exec summary: *** I am not happy with the lack of algorithm >>> agility implied by RPL-10. CCM*-AES-128 and the ECPVS signature >>> scheme[X9.92] appear to be hard coded. While there are some bits >>> to permit up to 3 additional algorithms to be used, I can see no >>> bits to permit a different signature algorithm. >>> >>> *** I am *not* of the opinion that AH would be a better choice >>> here. AH can be made to work, but we will essentially be creating >>> a new mode of AH, which is replay-enabled while still being >>> multicast and multi-sender capable. What I am saying is that >>> there is no code savings: restricted code size system won't care >>> AH vs RPL10, because they won't have any AH code to reuse. >>> Systems with AH will have to implement new code anyway, and it >>> will be harder to implement RPL on any system that already has >>> IPsec because the code may be hard to modify. >>> >>> I am of the STRONG opinion that the text, and essential packet >>> format of the AH specification should be extensively used. >>> >>> >>> === my detailed comments. >>> >>> In section 5.1, RPL Security Fields, the Key Identifier may be >>> present depending upon the value of the KIM field. >>> >>> When KIM is 00, 01, and 10, the presence, absence of the Key >>> Identifier is clear. (But, if Group key is used, then Key Source >>> is not used, because, I guess, the Key Index is no longer a local >>> key, but a global key, so that's why the Key Source is not >>> present?) >>> >>> When KIM is 11, a signature is present. Where is the signature >>> defined? What is the format of the signature? When KIM is 11, a >>> key source *MAY* be present and a key index *MAY* be present. How >>> is this determined? I think it may come out of the security >>> level, but I don't quite see how. >> >> Rene and Kris, can you answer this? >> >>> >>> It appears that the RPL security fields are not a multiple of >>> 64-bits, and block-mode AES requires 16-byte blocks, while CCM >>> mode is happy with any increment of bits. Assuming that someone >>> will define a second cipher at some point, we need to know how to >>> padd properly. But, I don't see any statement about how padding >>> is to be used. >>> >>> I am not happy with the text of 9.2. I suggest it should say: >>> >>> Authenticated mode requires a would-be router to dynamically >>> install new keys once they have joined a network as a host. >>> Having joined as a host, the node would then use standard IP >>> messaging to communicate with an authorization server, and new >>> keys would be provided. >>> >>> A protocol to obtain such keys is the subject of a future >>> standard. >> >> OK. >> >>> >>> === >>> >>> I also see no way for a node to tell if it is joining an >>> authenticated network or a pre-installed network. How does a >>> node which is authenticated know which set of keys (pre-installed >>> or authenticated) to use to authenticate a message from a new >>> prospective node? Is this an inate property of the keys >>> themselves indicated by the Key Source and Key Index? >>> >>> The 'A' bit of the Configuration Option tells a node what it may >>> do. >>> >>> section 9.3: 2. When a node resets its Trickle timer in response >>> to a secure DIS (Section 7.3), the next DIO it transmits MUST be >>> a secure DIO with the same security configuration as the secure >>> DIS. If a node receives multiple secure DIS messages before it >>> transmits a DIO, the secure DIO MUST have the same security >>> configuration as the last DIS it is responding to. >>> >>> The fact that the DIO transmitted is always the same as the last >>> DIS it received means that any DIS received before may never get >>> replied to using an acceptable (to that transmitter) level of >>> security. Isn't this an opening for a bid-down attack? >> >> What's a better way to do it? It MUST respond with the same >> security configuration as the first DIS? This opens a network up to >> a denial of service attack: as soon as a node sends a DIO, the >> adversary sends a DIS. The assumption here is that it's much harder >> to ensure you send the last DIS than the first one, because the DIO >> transmission time is randomized. Security policies can always >> discard DIOs whose security configuration is below what is >> acceptable. >> >> >> >> >>> The rules for the 'A' bit of the configuration option are >>> written wrong. They give rules for what a node MAY NOT do, but >>> nodes will do what they like. What we need are rules to determine >>> what a message being processed with a non-Authenticated keyset >>> may express. >>> >>> Text like this: >>> >>> When processing DIO messages secured with Key Index 0x00 in a >>> DODAG that is marked as authenticated, a processing node MUST >>> consider the advertised rank to be INFINITE_RANK. Any other >>> value results in the message being discarded. >>> >>> When processing DAO messages secured with Key index 0x00 in a >>> DODAG that is marked as authenticated, a processing node MUST >>> ensure that any RPL Target Option containing the same address as >>> the message's source address. >> >> Right -- this reverses the requirement. Seems reasonable. >> >> >>> >>> ...continuing with >>> >>> The above rules mean that in RPL Instances where the 'A' bit is >>> set, using Key Index 0x00 a node can join the RPL Instance as a >>> host but not a router. A node must communicate with a key >>> authority to obtain a key that will enable it to act as a >>> router. >>> >>> >>> {Why not just ignore any Target Option prefixes, and take the >>> value from the source address? That way, you can avoid sending >>> unnecessary bytes} >> >> OK. >> >>> >>> >>> 9.4: >>> >>> - the 'C' bit is set, this Counter field can be 1 or 4 bits. RPL >>> nodes + the 'C' bit is set, this Counter field can be 1 or 4 >>> bytes. RPL nodes >>> >>> >>>> 2. If a node receives a secure RPL message with the C bit set >>>> and is uncertain of the 32-bit counter value, it MAY send a CC >>>> message with the R bit cleared to obtain an uncompressed >>>> counter value. The Nonce field of the CC message SHOULD be a >>>> random or pseudorandom number. >>> >>> It says, "MAY". What other choices does the node have? What does >>> the node do with the message it received? Discard? Are there >>> parts of the message that may still be trustworthy? Is there any >>> point in asking for an update on the CC if the message does not >>> change any state? >> >> The point of the MAY here is to state that it's the >> implementation's decision of when to do so. >> >> >>> >>>> 3. If a node receives a unicast CC message with the R bit >>>> cleared, and it is a member of or is in the process of joining >>>> the associated DODAG, it SHOULD respond with a unicast CC >>>> message to the sender. This response MUST have the C bit of >>>> the security section cleared, MUST have the R bit set, and MUST >>>> have the same Nonce, RPLInstanceID and DODAGID fields as the >>>> message it received. >>> >>> It seems like this should have been discussed more in the >>> section 3? >>> >>> Why is the nonce only 16-bits? Seems small to me. There needs to >>> be advice that the nonce is not an incrementing integer! (cf. >>> DNS queries with 16-bit ids). >> >> I don't think the problem follows; in DNS the need for random IDs >> stems from the lack of integrity (an adversary can generate a >> response). In this case, the ID is intended to avoid attacks where >> an adversary replays a response. >> >> >>> Why is the destination counter included? Of what use is that? Is >>> it valid to send CC messages to peers which are not onlink (one >>> hop)? I.e. can CC messages be meaningfully routed across the >>> DAG? I'm asking, not because I think they should be forbidden, >>> but because if they are not forbidden, then we might need to say >>> so lest someone makes a different decision. >> >> The destination counter is for when a node reboots (a common issue >> in LLNs, e.g. due to low power). If it can't store its counter >> value, then nodes will ignore its messages until it counts to where >> it was before it rebooted. The destination counter provides a >> mechanism where it can sync with the last counter it set before >> rebooting. >> >> >> >>> >>>> 2. The timestamp MUST be in 1kHz (millisecond) granularity. >>> >>> Is it 1/1000 that one wants, or 1/1024? >> >> Good question -- Rene? >> >>> >>>> 3. The timestamp start time MUST be January 1, 2010, >>>> 12:00:00AM UTC. >>> >>> Making it Unix epoch (Jan. 1, 1970) would be simpler. As the >>> specification says we are supposed to keep 6 bytes (48 bits) of >>> resolution, this is 274877906944s, or 8700 years. If we go to >>> Jan. 1970, then this changes the lifetime of RPL from 8716 years >>> to 8675 years. >>> >>> As I understand it, we are only transmitting the lower 32-bits >>> of the value, in units of 1/1000s. So the timestamp for my email >>> would be: Unix time(1278331381) * 1000 mod (2^32) = 2726094088. >>> >>>> 7. If a node does not have a local timestamp that satisfies >>>> the above requirements, it MUST ignore the 'T' flag. >>> >>> I think this is confusing. I think it means that if a node does >>> not have a timestamp that meets the requirements, it must set >>> the 'T' flag to zero. The question of what a node does with a >>> message with the 'T' flag set, where the node has no concept of >>> time is not dealt with, I think. >>> >>> Also, I guess that if keys have Start Times and End Times, then >>> in principle, one can have multiple keys with index 0x00, which >>> are non-overlapping in time. In principle, that is, if every node >>> has a clock! >>> >>> If a node hasn't a clock, while I can see ways to pick the key >>> by either trying all of them, or using the Counter value as a >>> clue, it seems that this introduces windows for replay attacks >>> that the counters had just closed. >>> >>>> node's security policy database. The configuration of this >>>> security policy database for outgoing packet processing is TBD >>>> (it may, for >>> >>> the term "security policy database", while generically used >>> here, may well be confused with IPsec's SPD. >>> >>>> to the particular destination address. Where a Counter for the >>>> intended destination address has not been established, the >>>> Counter value MUST be initialized to zero and sent as a Full >>>> Counter for the initial RPL message transmission. >>> >>> To aid in implementation, can we please start the Counter at 1, >>> and even better, forbid 32-bit Counter values of 0 (matters when >>> the counter rolls). >>> >>> The entire Compressed Counter mechanism seems like a waste of >>> code space. I see no savings by doing this in the resulting >>> packets due to required padding. The ensuing CC process that is >>> needed to deal with this seems like a further waste. I'd rather >>> define a standard compression algorithm that we can apply before >>> encryption instead. >>> >>> I was excited by section 9.5.1, because it was going to tell me >>> which bits to apply the AES-CCM encryption bits to, and which >>> bits to authenticate. It failed to do that. >>> >>> Do I understand that the security bits themselves are *NOT* >>> integrity protected? >>> >>> page 74, re: zero-value Full Counter receipt. Is the message >>> itself discarded then? Assume that it otherwise passes all >>> processing. >>> >>>> protection for a received RPL message. The replay check MUST >>>> be performed following the authentication of the received >>>> packet. The >>> >>> well, no. The replay check SHOULD be preformed before >>> authentication of the packet. If the replay counter says "old", >>> then you discard without further processing (do not waste your >>> time/energy verifying old packets!). If the replay says "new", >>> then you can authenticate first, and update the counters if it >>> checks out. >>> >>> I can't tell from the specification if the contents of the >>> "Security Section" are protected in any way by the integrity >>> check. Section 9.6 was not helpful, as it says "entire IPv6 >>> packet". I guess this means the layer-3, but someone will get it >>> wrong, and include layer-2 too. When the integrity check is >>> calculated, what is the value in the security section for the MAC >>> code? >>> >>> (I would assume zeroes..) >>> >>> Should any fields in the layer-3 (IPv6 base header) be skipped, >>> the way that AH skips them? What about any extension headers >>> present? >>> >>> As the recommended MUST is AES-CCM mode, which performs both >>> integrity and encryption at the same time, I don't know how one >>> can have the bytes under integrity check different from those >>> that are encrypted. >>> >>> Please see RFC4302, appendix B, and RFC4303 section 3.4.3 for >>> some text to steal. Note that this might >>> >>> section 9.5.3.1: I have no idea where in the packet the nonce >>> goes. Is it simply created as input into the CCM* star? Or does >>> it have to be transmitted somewhere? (I don't think so) >>> >>> *** I am not happy with the lack of algorithm agility implied by >>> RPL-10 *** >>> >>> 9.5.3.2: I am not happy with specification of a possibly >>> encumbered elliptic curve here. Has then been a proper IPR >>> disclosure? There is no algorithm agility available here either. >> >> Rene, can you respond to this? >> >> 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 jpv@cisco.com Sat Jul 24 03:19:03 2010 Return-Path: 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 BD6723A6816 for ; Sat, 24 Jul 2010 03:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 nAIEBT16S2cp for ; Sat, 24 Jul 2010 03:19:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 196813A67B7 for ; Sat, 24 Jul 2010 03:19:01 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFALdaSkyrR7Hu/2dsb2JhbACBRJ4hcaR2mk2CboJIBIhkgjo X-IronPort-AV: E=Sophos;i="4.55,252,1278288000"; d="scan'208,217";a="230250472" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2010 10:19:19 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6OAJBVG018578 for ; Sat, 24 Jul 2010 10:19:19 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 12:19:18 +0200 Received: from [192.168.1.11] ([10.61.111.197]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 12:19:18 +0200 Message-Id: <5E1E30BE-BCE5-4DE1-980D-A0C91266E957@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AEF2@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-92-1011846990 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Jul 2010 12:19:17 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D0260AEF2@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Jul 2010 10:19:18.0266 (UTC) FILETIME=[ACC06DA0:01CB2B19] Cc: roll@ietf.org Subject: Re: [Roll] closing Ticket #64 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: , X-List-Received-Date: Sat, 24 Jul 2010 10:19:03 -0000 --Apple-Mail-92-1011846990 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Great text, which I think address the ticket - minor comments below. On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote: > Dear WG: > > Long discussions lead to specify only the location of the =20 > RPLinstanceID inside the RPL network, leaving it to policies the way =20= > the ingress router figures it out. The RPLinstanceID will be placed =20= > in the RPL option which is probably the cleanest and most generic =20 > thing we can do. Other drafts are allowed to come later and provide =20= > alternate forwarding rules eventually placing the content of the RPL =20= > option validation somewhere else, for instance in order to avoid =20 > IPinIP. A forwarding mode will probably indicate what the network =20 > does. > > Proposed changes: > > RPL uses a hop-by-hop IPv6 header to detect possible loops within a > DODAG. > -> > RPL carries routing information in a RPL Option =20 > contained in an IPv6 > Hop-by-Hop Option as specified in [I-D.hui-6man-rpl-=20= > option]. Such > routing information are used for example for loop =20 > detection within a > DODAG as discussed in Section 11.2 and may be =20 > extended in future > documents for additional features. > > > For data packets, the RPLInstanceID may be indicated in the flow > label by the source of the packet. If it is not, then it is inferred > and added by the RPL network ingress router in the RPL Hop-by-hop > option ([I-D.hui-6man-rpl-option]) as further described in > Section 10.2 > > =E8 > > Data packet that flow within the RP network expose the =20= > RPLInstanceID > in the RPL option that is specified in [I-D.hui-6man-=20= > rpl-option], and > further described in Section 11.2. For data packets =20= > coming from > outside the RPL network, the RPLInstanceID is =20 > determined by the RPL > network ingress router and placed in the RPL option =20= > that is added to > the packet. > > > RPL loop detection uses information that is placed into the packet. > A future version of this specification will detail how this > information is carried with the packet (e.g. a hop-by-hop option > ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow > label). For the purpose of RPL operations, the information carried > with a packet is constructed follows: > > =E8 > RPL loop detection uses information that contained =20 > within the data > packet using the RPL Option [I-D.hui-6man-rpl-option]) =20 > in an IPv6 > Hop-by-Hop Option header. The RPL Option is a =20 > generic container for > a list of TLVs. This specification defines a new RPL =20= > Option type, > called the RPL Loop Detection. The RPL Loop =20 > Detection TLV is placed > in the RPL Option with Option Type =3D 1 (to be =20 > confirmed by IANA), > Option Data Length =3D 4 octets, and the Value has the = =20 > following > format: > > > > The RPLInstanceID is associated by the source with the packet. This > RPLInstanceID MUST match the RPL Instance onto which the packet is > placed by any node, be it a host or router. For traffic originating > outside of the RPL domain there may be a mapping occurring at the > gateway into the RPL domain, possibly based on an encoding within the > flow label. This aspect of RPL operation is to be clarified in a > future version of this specification. > > The source of the packet might be aware of the RPL network, of the > constraints imposed on OFs, and of associated Instance IDs. In that > case, the source of the packet MAY tag the flow label with the > RPLInstanceID, in which case it is used in that form within the RPL > network. > > A router that injects a data packet into the RPL network MUST tag the > packet by inserting a RPL Hop-by-hop option as specified in > [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in > flow label of the data packet, the ingress router that injects the > packet into the RPL network MUST add a RPLInstanceID field to the RPL > Hop-by-hop option. > > =E8 > The RPLInstanceID is associated by the source with the =20= > packet. This > RPLInstanceID MUST match the RPL Instance onto which =20= > the packet is > placed by any node, be it a host or router. > > For a packet that is originated from outside the RPL =20= > network, the > source of the packet might be aware of the RPL =20 > network, of the > constraints imposed on OFs, and of associated =20 > RPLInstanceIDs. In > that case, the source of the packet MAY tag the flow =20= > label with the > RPLInstanceID. > > A RPL router that forwards a packet in the RPL =20 > network MUST check if > the packet includes the RPL Loop Detection TLV in a =20= > RPL Option within > the IPv6 Hop-by-Hop Option header. If one does not =20 > exist, the RPL > router MUST insert a RPL Loop Detection type as =20 > specified in > > > [I-D.hui-6man-rpl-option]. If the router is an =20 > ingress router that > injects the packet into the RPL network, the router =20= > MUST set the > RPLInstanceID field in the RPL Loop Detection TLV. > > + add: A router that forwards a packet to outside the RPL domain MUST remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. > As usual, please speak up if there=92s an issue with the proposed =20 > resolution! > > Pascal > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Saturday, July 24, 2010 12:02 AM > To: Pascal Thubert (pthubert) > Subject: Re: Ticket #64 and Summary of our discussion today > > could you please provide the final text then ? > > Thanks Pascal. > > On Jul 23, 2010, at 4:13 PM, Pascal Thubert (pthubert) wrote: > > > Hi JP; > > I did the same in parallel; I changed very little as below. Please =20 > review; I=92m resending the ready to forward mail to this list=85 > > Pascal > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Friday, July 23, 2010 1:46 PM > To: Tim Winter; Pascal Thubert (pthubert); Jonathan Hui; = rpl-authors@external.cisco.com > Subject: Re: Ticket #64 and Summary of our discussion today > > OK here is the new text to close Ticket #64 - > > I combined the text from Pascal, Jonathan + my suggestions. > > All please let us know today is you agree, then I will close that =20 > ticket. > > Text to include in ticket #64 for closing > ############################### > > Please find below the various changes to close ticket #64 > > The definition and provisioning of RPL instances are beyond the scope > of this specification. Those operations are expected to be such that > data packets coming from the outside of the RPL network can > unambiguously be associated to at least one RPL instance, and be > safely routed over any instance that would match the packet. > Information used to match a packet to a RPL instance can typically be > taken from fields in the IPv6 header, like the flow label, > differentiated services (DS) field, or destination address. > > Control and data packets within RPL network are tagged to > unambiguously identify what RPL Instance they are part of. > > Every RPL control message has a RPLInstanceID field. Some RPL > control messages, when referring to a local RPLInstanceID as defined > below, may also include a DODAGID. > > Data packets that flow within the RPL domain expose the > RPLInstanceID in the RPL Hop-by-hop option that is specified in > [I-D.ietf-6man-rpl-option],and further described in Section 11.2. > For data packets coming from outside the RPL network, the > RPLInstanceID is determined by the RPL network ingress router > and placed in a RPL Hop-by-hop option that is added to the > packet." > [Pascal] removed hop-by-hop per Jonathan=92s point > Data packet that flow within the RP network expose the > RPLInstanceID in the RPL option that is specified in > , > and further described in xref>. > For data packets coming from outside the RPL network, =20= > the RPLInstanceID > is determined by the RPL network ingress router and =20 > placed in the RPL > option that is added to the packet. > =93 > Data packet that flow within the RP network expose the =20 > RPLInstanceID > in the RPL option that is specified in [I-D.hui-6man-rpl-option], =20= > and > further described in Section 11.2. For data packets coming from > outside the RPL network, the RPLInstanceID is determined by the RPL > network ingress router and placed in the RPL option that is added =20= > to > the packet. > > =93 > Then ... > > 3.3.7. Datapath Validation and Loop Detection > > RPL uses a hop-by-hop IPv6 header to detect possible loops within a =20= > DODAG. > --> > > RPL carried routing information in a RPL Option contained in an IPv6 > Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-routing-header]. > Such routing information are used for example for loop detection =20 > within > a DODAG as discussed in Section 10.2 and subject to additional =20 > information > defined in future document. > > [Pascal] carried -> carries > [Pascal] and subject to additional information defined in future =20 > document. > -> > and may be extended in future documents for additional features. > > > 5. RPL Instance > > and added by the RPL network ingress router in the RPL Hop-by-hop =20 > option > > --> and added by the RPL network ingress router in the RPL Option > > [Pascal] This is actually the first change in the mail above. Do I =20 > miss something like a dup? > > 8.2.2.5. Poisoning > > whose hop-by-hop option ([I-D.hui-6man-rpl-option]) includes a Rank > --> > whose RPL Option ([I-D.hui-6man-rpl-option]) includes a Rank > > [Pascal] done > > 11.2. Loop Avoidance and Detection > > RPL loop detection uses information that is placed into the packet. > A future version of this specification will detail how this > information is carried with the packet (e.g. a hop-by-hop option > ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow > label). For the purpose of RPL operations, the information carried > with a packet is constructed follows: > --> > RPL loop detection uses information that contained within the data > packet using the RPL Option [I-D.hui-6man-rpl-option] in an IPv6 > Hop-by-Hop Option header. The RPL Option is a generic container for > a list of TLVs. This specification defines a new RPL Option type, > called the RPL Loop Detection. The RPL loop Detection TLV has the > following format, with type=3D1 (to be confirmed by IANA). > > HERE INSET THE FORMAT > [Pascal] as is > > > 11.2.2.1. Instance Forwarding > > A router that injects a data packet into the RPL network MUST insert =20= > a RPL > Hop-by-hop option as specified in [I-D.ietf-6man-rpl-option]. > > If the RPLInstanceID is not present in flow label of the data =20 > packet, the ingress > router that injects the packet into the RPL network MUST add a =20 > RPLInstanceID > field to the RPL Hop-by-hop option. > > --> > > A RPL router that forwards a packet in the RPL domain MUST check if > the packet includes the RPL Loop Detection TLV in a RPL Option with > the IPv6 Hop-by-Hop Option header. If one does not exist, the RPL =20= > router > MUST insert a RPL Loop Detection type as specified in [I-=20 > D.ietf-6man-rpl-option]. > > A router that forwards a packet to outside the RPL network MUST > remove the RPL Hop-by-hop option. > --> > > A router that forwards a packet to outside the RPL domain MUST > remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. > [Pascal] as is. > > --Apple-Mail-92-1011846990 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Great text, which I think = address the ticket - minor comments below.

On Jul 24, = 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote:

Dear = WG:
Long = discussions lead to specify only the location of the RPLinstanceID = inside the RPL network, leaving it to policies the way the ingress = router figures it out. The RPLinstanceID will be placed in the RPL = option which is probably the cleanest and most generic thing we can do. = Other drafts are allowed to come later and provide alternate forwarding = rules eventually placing the content of the RPL option validation = somewhere else, for instance in order to avoid IPinIP. A forwarding mode = will probably indicate what the network = does.
 
RPL uses  a hop-by-hop IPv6 = header to detect possible loops within a
For = data packets, the RPLInstanceID may be indicated in the = flow
label by = the source of the packet. If it is not, then it is = inferred
and = added by the RPL network ingress router in the RPL = Hop-by-hop
Section = 10.2
=E8  
RPL = loop detection uses information that is placed into the = packet.         
A future version of this = specification will detail how this
information is carried with the = packet (e.g. a hop-by-hop option
([I-D.hui-6man-rpl-option]) or = summarized somehow into the flow
label). For the purpose of RPL = operations, the information carried
with a packet is constructed = follows:
=E8  
The = RPLInstanceID is associated by the source with the packet. = This
placed by = any node, be it a host or router. For traffic = originating          &nb= sp;    
outside of the RPL domain there = may be a mapping occurring at = the       
gateway into the RPL domain, = possibly based on an encoding within the
flow label. This aspect of RPL = operation is to be clarified in a
future version of this = specification.
The = source of the packet might be aware of the RPL network, of = the
constraints = imposed on OFs, and of associated Instance IDs. In = that
case, the = source of the packet MAY tag the flow label with = the
A = router that injects a data packet into the RPL network MUST tag = the
packet by = inserting a RPL Hop-by-hop option as specified = in
flow label = of the data packet, the ingress router that injects = the            = ;   
packet into the RPL network MUST add a RPLInstanceID = field to the = RPL            = ;   
Hop-by-hop = option.       
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-bottom: = 0.0001pt; margin-left: 0cm; font-size: 12pt; font-family: 'Times New = Roman', serif; ">=E8  
As usual, = please speak up if there=92s an issue with the proposed = resolution!
 JP Vasseur [mailto:jpv@cisco.com] 
Sent: Saturday, July 24, 2010 = 12:02 AM
To: Pascal Thubert = (pthubert)
Subject: Re: Ticket #64 and Summary = of our discussion today
 
could you please provide = the final text then ?
Thanks = Pascal.
On Jul 23, 2010, at 4:13 = PM, Pascal Thubert (pthubert) wrote:


Hi JP;I did = the same in parallel; I changed very little as below. Please review; I=92m= resending the ready to forward mail to this list=85
 
Pascal 
JP Vasseur [mailto:jpv@cisco.com] 
Sent: Friday, July 23, 2010 1:46 = PM
To: Tim = Winter; Pascal Thubert (pthubert); = Jonathan Hui;  Re: Ticket #64 and Summary = of our discussion today 

= --Apple-Mail-92-1011846990-- From jpv@cisco.com Sat Jul 24 03:23:34 2010 Return-Path: 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 660C83A69B4 for ; Sat, 24 Jul 2010 03:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 7U-GD6kKsp3j for ; Sat, 24 Jul 2010 03:23:33 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 690A53A6816 for ; Sat, 24 Jul 2010 03:23:33 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKZbSkyrR7Hu/2dsb2JhbACfZXGke5pKhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,252,1278288000"; d="scan'208";a="162449206" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 24 Jul 2010 10:23:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6OANo9v019756; Sat, 24 Jul 2010 10:23:52 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 12:23:51 +0200 Received: from [192.168.1.11] ([10.61.111.197]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 12:23:51 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4AB059.3080107@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Jul 2010 12:23:50 +0200 References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> <4C4AB059.3080107@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Jul 2010 10:23:51.0260 (UTC) FILETIME=[4F7801C0:01CB2B1A] Cc: roll@ietf.org Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Sat, 24 Jul 2010 10:23:34 -0000 [snip] >> >> 3.3.3. Security >> >> RPL supports message confidentiality and integrity. It is designed >> such that link-layer mechanisms can be used when available and >> appropriate, yet in their absence RPL can use its own mechanisms. RPL >> has three basic security modes. > > Thanks Phil for pointing to this text specifically. I will also > follow > private indications to read the document. > > Link layer security being reflected in the draft would mean to name > that > link layer security, the protocol and algorithm names specific to that > link layer security. I think currently it doesn't... > > For example it never says the name of that particular link layer, or > at > least I can not find it. I may need to search more. > We do not name the link layer and should not. RPL is L3, link layer "agnostic". As pointed out, one may choose to implement the routing security mechanisms specified in the draft, depending on what is available at the link layer. This should go in some "deployment" guide, not here. Thanks. JP. > Alex > > >> >> >> Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Sat Jul 24 05:57:19 2010 Return-Path: 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 BBEDB3A69D8 for ; Sat, 24 Jul 2010 05:57:19 -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=[AWL=0.000, 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 NnU5CtiAvO5S for ; Sat, 24 Jul 2010 05:57:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 874923A690D for ; Sat, 24 Jul 2010 05:57:18 -0700 (PDT) Received: by bwz7 with SMTP id 7so2450110bwz.31 for ; Sat, 24 Jul 2010 05:57:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.7.219 with SMTP id e27mr3291739bke.191.1279976256301; Sat, 24 Jul 2010 05:57:36 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Sat, 24 Jul 2010 05:57:36 -0700 (PDT) In-Reply-To: <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> Date: Sat, 24 Jul 2010 14:57:36 +0200 Message-ID: From: Ulrich Herberg To: David Culler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Sat, 24 Jul 2010 12:57:19 -0000 On Fri, Jul 23, 2010 at 8:47 PM, David Culler wrot= e: > While the various companies that have disclosed IPR relative to RPL have = been generous in enabling the standard to move forward, it behooves us to d= o everything we can to create =A0standards that do not require proprietary = IP to achieve interoperable implementations. =A0It seems clear that we shou= ld pursue a variant of 2. =A0We should complete the core spec utilizing a s= ecurity scheme that is unencumbered. =A0We should make sure that there is e= nough room in the encoding that we may consider more highly optimized schem= es later. =A0In that time, we can sort out IPR issues. =A0 =A0With so many = signature schemes already well established it would be very surprising that= we simply cannot use any of them. =A0The disclosed IPR may provide substan= tial improvements, but that is certainly a secondary concern. > > Can the security DT suggest one or more such openly available options. I fully agree. There should be other, unencumbered algorithms, which provide similar levels of performance and signature lengths. It would be good to investigate these. Ulrich > > > On Jul 22, 2010, at 4:41 PM, Philip Levis wrote: > >> Summary: This mail describes the current status of signature schemes in = RPL, presents three options for going forward, and asks the WG to discuss a= nd reach consensus on how to proceed. >> >> Background >> ------------- >> >> Currently RPL has a single security algorithm configuration: >> >> =A0 =A0+-------+-------------------+------------------------------------= --+ >> =A0 =A0| =A0ID =A0 | =A0Encryption/MAC =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0= Signature =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 =A0+-------+-------------------+------------------------------------= --+ >> =A0 =A0| =A0 0 =A0 | CCM* with AES-128 | ECPVS with K-283, Matyas-Meyer-= Oseas | >> =A0 =A0| 1-255 | =A0 =A0 =A0Reserved =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Reserved =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 =A0+-------+-------------------+------------------------------------= --+ >> >> The Signature scheme described is encumbered by IPR held by Certicom. Re= ne, as a major contributor to the security parts of RPL, disclosed this IPR= through the standard IETF process. Rene does not currently work for Certic= om, although he did in the past. The particular scheme was chosen because o= f its technical advantages in LLNs: short signatures which are inexpensive = to compute compared to many other signature schemes. >> >> Going Forward >> -------------------------- >> >> The security DT sees three possible paths going forward: >> >> =A01) Keep the Algorithm options as they are now: the only signature sch= eme supported in the base RPL specification is encumbered by IPR. Let's cal= l this the "IPR" option. >> >> =A02) Keep a single Algorithm (ID=3D0) in the base RPL specification, bu= t change Algorithm ID=3D0's signature scheme to one that we believe is unen= cumbered by IPR. Let's call this the "No-IPR" option. >> >> =A03) Keep the current Algorithm (ID=3D0), and add a second Algorithm (I= D=3D1) to have the same Encryption/MAC scheme as ID=3D0 (CCM* with AES-128)= but a signature scheme we believe is unencumbered by IPR. Let's call this = the "Both" option. >> >> We are currently investigating which signature scheme unencumbered by IP= R would best meet the requirements of LLNs. We expect to have reached a con= clusion on this by the end of this week. It's our opinion that which exact = algorithm is chosen should be considered independently of the three options= above (under the assumption that it is unencumbered by IPR). >> >> Discussion >> ------------------- >> >> The security DT would like guidance from the WG on which of the three op= tions it should pursue. Given that we are in last call and are meeting next= week, let's try to keep the discussion focused and on-topic so we can reac= h consensus quickly. >> >> Phil >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Sat Jul 24 06:06:42 2010 Return-Path: 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 658713A690D for ; Sat, 24 Jul 2010 06:06:42 -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 JaUt8o7uVg9f for ; Sat, 24 Jul 2010 06:06:41 -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 5C1F73A6905 for ; Sat, 24 Jul 2010 06:06:41 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OceRQ-0005Wy-Di; Sat, 24 Jul 2010 06:07:00 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Sat, 24 Jul 2010 06:06:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80AF40A5-E114-4F27-882A-8BD91EFEF0D0@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> To: Ulrich Herberg X-Mailer: Apple Mail (2.1081) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Sat, 24 Jul 2010 13:06:42 -0000 On Jul 24, 2010, at 5:57 AM, Ulrich Herberg wrote: > On Fri, Jul 23, 2010 at 8:47 PM, David Culler = wrote: >> While the various companies that have disclosed IPR relative to RPL = have been generous in enabling the standard to move forward, it behooves = us to do everything we can to create standards that do not require = proprietary IP to achieve interoperable implementations. It seems clear = that we should pursue a variant of 2. We should complete the core spec = utilizing a security scheme that is unencumbered. We should make sure = that there is enough room in the encoding that we may consider more = highly optimized schemes later. In that time, we can sort out IPR = issues. With so many signature schemes already well established it = would be very surprising that we simply cannot use any of them. The = disclosed IPR may provide substantial improvements, but that is = certainly a secondary concern. >>=20 >> Can the security DT suggest one or more such openly available = options. >=20 > I fully agree. There should be other, unencumbered algorithms, which > provide similar levels of performance and signature lengths. It would > be good to investigate these. Ulrich, I fully agree as well. It turns out that such algorithms which are = unencumbered by IPR are not *that* easy to find, however. I consulted = with my resident cryptographic expert, Dan Boneh[1]. He suggested an = algorithm which he developed in 2001 or so, based on the Weil = pairing[2], which is completely open and has no encumbering IPR. At = first glance, it seems to possibly be technically superior than the = Certicom-encumbered one in terms of factors we care about (e.g., = signature length), which was already very attractive. There are = reference implementations[3], and the FAA is beginning to incorporate it = into some of their systems. The security DT is currently examining the = algorithm. I hope to give an update soon. Phil [1] http://crypto.stanford.edu/ [2] http://crypto.stanford.edu/~dabo/pubs/abstracts/weilsigs.html [3] http://crypto.stanford.edu/pbc/ From ajakuma2@cisco.com Sat Jul 24 07:21:25 2010 Return-Path: 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 B33863A694C for ; Sat, 24 Jul 2010 07:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ZFbG7c8VfP54 for ; Sat, 24 Jul 2010 07:21:24 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4D6393A67FC for ; Sat, 24 Jul 2010 07:21:24 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8FACOUSkxAaHte/2dsb2JhbACBRJFZjEhxpQKaNIU2BIQGhxgMAQ X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208,217";a="230289526" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 24 Jul 2010 14:21:42 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6OELf3e007778 for ; Sat, 24 Jul 2010 14:21:42 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 19:51:42 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2B3B.8966F29A" Date: Sat, 24 Jul 2010 19:51:38 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01802115B18@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrong option Length specified in 5.7.6 Thread-Index: AcsrO4eS5sw/zCWFTMe6hqJ4O5Se5w== From: "Ajay Kumar (ajakuma2)" To: X-OriginalArrivalTime: 24 Jul 2010 14:21:42.0176 (UTC) FILETIME=[8998FA00:01CB2B3B] Subject: [Roll] Wrong option Length specified in 5.7.6 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: , X-List-Received-Date: Sat, 24 Jul 2010 14:21:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2B3B.8966F29A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roll Group, =20 I was going through Rev10 and found following text in 5.7.6(Dodag Config Option) =20 Option Type: 0x04 (to be confirmed by IANA) Option Length: 8 bytes =20 =20 Total length of the option is 12 bytes including Type & Length fields. So, Option Length must be 10(may be a typo). =20 Please ignore if it has already been pointed out. =20 Regards, Ajay=20 =20 ------_=_NextPart_001_01CB2B3B.8966F29A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roll Group,

 

I was going through Rev10 and found following text = in 5.7.6(Dodag Config Option)

 

Option Type: 0x04 (to be confirmed by = IANA)

Option Length: 8 bytes

 

 

Total length of the option is 12 bytes including = Type & Length fields. So, Option Length must be 10(may be a = typo).

 

Please ignore if it has already been pointed = out.

 

Regards,

Ajay =

 

------_=_NextPart_001_01CB2B3B.8966F29A-- From wintert@acm.org Sat Jul 24 07:28:07 2010 Return-Path: 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 D0A793A689C for ; Sat, 24 Jul 2010 07:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 59ntyE8E81hb for ; Sat, 24 Jul 2010 07:28:07 -0700 (PDT) Received: from smtp103.prem.mail.ac4.yahoo.com (smtp103.prem.mail.ac4.yahoo.com [76.13.13.42]) by core3.amsl.com (Postfix) with SMTP id D30FD3A67FC for ; Sat, 24 Jul 2010 07:28:06 -0700 (PDT) Received: (qmail 10279 invoked from network); 24 Jul 2010 14:28:20 -0000 Received: from [10.56.17.103] (wintert@71.178.253.216 with plain) by smtp103.prem.mail.ac4.yahoo.com with SMTP; 24 Jul 2010 07:28:20 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 69pZrzMVM1n0CIcpRA3Zk08RjZtzzJdMO0ndkUyxGCohNIY 30wLq9l1cOHv7VaFeM46hDsLOmu3Gu3in9K8Ezjuu5ZNP96Qq9nPAthxR9wr wYZpixMdSl9KQp0fiReQWXpP4GY1yWdpxM.c8UEMvFpWg_3PbrUyxbOClyva 1n1r0jPGLQ34T1_s1xA16JJRgI3DRz07dkDBE3cPu7hsf9iK4djYq6TKxSOm Tp7k0262l36nCo3muJukCMZhqh1dyVOzZA.E_StV6x8F4JrJSe3mlGc7wdR8 POA9DcHM94mdHln5bIUvn.Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4AF879.2070007@acm.org> Date: Sat, 24 Jul 2010 10:28:09 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100528 Thunderbird/3.0.5 MIME-Version: 1.0 To: roll@ietf.org References: <454A16E4DA86094EB66BB2C1DBBBC01802115B18@XMB-BGL-41B.cisco.com> In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC01802115B18@XMB-BGL-41B.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Wrong option Length specified in 5.7.6 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: , X-List-Received-Date: Sat, 24 Jul 2010 14:28:08 -0000 On 07/24/2010 10:21 AM, Ajay Kumar (ajakuma2) wrote: > Hi Roll Group, > > I was going through Rev10 and found following text in 5.7.6(Dodag Config > Option) > > Option Type: 0x04 (to be confirmed by IANA) > > Option Length: 8 bytes > > Total length of the option is 12 bytes including Type & Length fields. > So, Option Length must be 10(may be a typo). > Good catch! That is now fixed ... > Please ignore if it has already been pointed out. > > Regards, > > Ajay > Thanks, -Tim From pthubert@cisco.com Sat Jul 24 07:36:04 2010 Return-Path: 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 BD4E83A68D9 for ; Sat, 24 Jul 2010 07:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 8ErW7GLZFibF for ; Sat, 24 Jul 2010 07:36:01 -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 3D0563A6A09 for ; Sat, 24 Jul 2010 07:36:01 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAMCWSkyrR7Hu/2dsb2JhbACBRJ4hcaUBmjKFNgSLHg X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208,217";a="563207843" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2010 14:36:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6OEaI1G015775 for ; Sat, 24 Jul 2010 14:36:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 16:36:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2B3D.935E0EA9" Date: Sat, 24 Jul 2010 16:36:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AF0A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: solving issue 71 thread-index: AcsrPZA7NYuMzhVtTsa/GOyOskBXMQ== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 24 Jul 2010 14:36:18.0337 (UTC) FILETIME=[93D48910:01CB2B3D] Subject: [Roll] solving issue 71 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: , X-List-Received-Date: Sat, 24 Jul 2010 14:36:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2B3D.935E0EA9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG =20 Please find the proposed solution for issue 71 to add an opaque tag with the RPL route advertisements: =20 =20 Changed 6.4.3. DAO Options to add the Descriptor =20 The DAO message MAY carry valid options. =20 This specification allows for the DAO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor =20 =20 =20 Changed 6.7.7. RPL Target =20 =20 A RPL Target Option May optionally be paired with a RPL Target Descriptor Option (Section 6.8) that qualifies the target. =20 A set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target option in a DAO message, where each Target Option MAY be paired with a RPL Target Descritor Option. The structure of the DAO message, detailing how Target options are used in conjunction with Transit Information options, is further described in Section 9.6. =20 =20 =20 Added RPL Target descriptor =20 The RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target. =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Option Length | Descriptor = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Descriptor (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 29: Format of the RPL Target Descriptor Option =20 The RPL Target Descriptor Option is used to qualify a target, something that is sometimes called tagging. =20 There can be at most one descriptor per target. The descriptor is set by the node that injects the target in the RPL network. It MUST be copied but not modified by routers that propagate the target up the DODAG in DAO messages. =20 Option Type: 0x09 (to be confirmed by IANA) =20 Option Length: 6 =20 Descriptor: 32-bit unsigned integer. Opaque. =20 If you have an issue with this resolution please speak up! =20 Pascal ------_=_NextPart_001_01CB2B3D.935E0EA9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Dear =
WG
 
Please find the =
proposed solution for issue 71 to add an opaque tag with the RPL route =
advertisements:
 
&nb=
sp;
Changed 6.4.3.  DAO Options to add the =
Descriptor
 
   =
The DAO message MAY carry valid =
options.
 
   =
This specification allows for the DAO message to carry the =
following
   =
options:
      0x00 =
Pad1
      0x01 =
PadN
      0x05 RPL =
Target
      0x06 Transit =
Information
      0x09 RPL =
Target =
Descriptor
 
 
 
Changed  6.7.7.  =
RPL Target

 

 

   A RPL = Target Option May optionally be paired with a RPL = Target

   = Descriptor Option (Section 6.8) that qualifies the = target.

 

   A set = of one or more Transit Information options (Section 6.7.8) = MAY

   = directly follow a set of one or more Target option in a DAO = message,

   where = each Target Option MAY be paired with a RPL Target = Descritor

   = Option.  The structure of the DAO message, detailing how = Target

   = options are used in conjunction with Transit Information options, = is

   = further described in Section 9.6.

 

 

 

Added

RPL Target =
descriptor
 
   =
The RPL Target option MAY be immediately followed by one =
opaque
   descriptor that qualifies that =
specific =
target.
 
 
        =
0            =
       =
1            =
       =
2            =
       =
3
        0 1 2 =
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =
=3D 9    | Option Length |   =
Descriptor          &nb=
sp;       =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   =
Descriptor (cont.)          =
|
        &n=
bsp;  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 <=
/pre>
           =
Figure 29: Format of the RPL Target Descriptor =
Option
 
   The =
RPL Target Descriptor Option is used to qualify a =
target,
   something that is sometimes =
called =
tagging.
 
   =
There can be at most one descriptor per target.  The descriptor =
is
   set by the node that injects the =
target in the RPL network.  It =
MUST
   be copied but not modified by =
routers that propagate the target up
   =
the DODAG in DAO =
messages.
 
   =
Option Type:  0x09 (to be confirmed by =
IANA)
 
   =
Option Length:  =
6
 
   =
Descriptor:  32-bit unsigned integer.  =
Opaque.
 
If you have an issue with this resolution please speak =
up!
 
Pascal
------_=_NextPart_001_01CB2B3D.935E0EA9-- From pthubert@cisco.com Sat Jul 24 07:41:47 2010 Return-Path: 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 D9B413A69A8 for ; Sat, 24 Jul 2010 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 SZ-lWzNhmYdg for ; Sat, 24 Jul 2010 07:41:46 -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 4ACE43A6851 for ; Sat, 24 Jul 2010 07:41:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAA6ZSkxAZnwM/2dsb2JhbACBRJ4hcaUFmjGFNgSLHg X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208,217";a="138634527" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2010 14:42:05 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6OEg4Fn025314 for ; Sat, 24 Jul 2010 14:42:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 16:42:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2B3E.61F2B29A" Date: Sat, 24 Jul 2010 16:42:02 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AF0C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: solving issue 72 thread-index: AcsrPl/wE1/7aX8SRVmkfYMuWfmsNg== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 24 Jul 2010 14:42:04.0713 (UTC) FILETIME=[62495190:01CB2B3E] Subject: [Roll] solving issue 72 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: , X-List-Received-Date: Sat, 24 Jul 2010 14:41:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2B3E.61F2B29A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oups! This text is for issue 72 =20 Pascal =20 From: Pascal Thubert (pthubert)=20 Sent: Saturday, July 24, 2010 4:36 PM To: roll@ietf.org Subject: solving issue 71 =20 Dear WG =20 Please find the proposed solution for issue 71 to add an opaque tag with the RPL route advertisements: =20 =20 Changed 6.4.3. DAO Options to add the Descriptor =20 The DAO message MAY carry valid options. =20 This specification allows for the DAO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor =20 =20 =20 Changed 6.7.7. RPL Target =20 =20 A RPL Target Option May optionally be paired with a RPL Target Descriptor Option (Section 6.8) that qualifies the target. =20 A set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target option in a DAO message, where each Target Option MAY be paired with a RPL Target Descritor Option. The structure of the DAO message, detailing how Target options are used in conjunction with Transit Information options, is further described in Section 9.6. =20 =20 =20 Added RPL Target descriptor =20 The RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target. =20 =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Option Length | Descriptor = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Descriptor (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 29: Format of the RPL Target Descriptor Option =20 The RPL Target Descriptor Option is used to qualify a target, something that is sometimes called tagging. =20 There can be at most one descriptor per target. The descriptor is set by the node that injects the target in the RPL network. It MUST be copied but not modified by routers that propagate the target up the DODAG in DAO messages. =20 Option Type: 0x09 (to be confirmed by IANA) =20 Option Length: 6 =20 Descriptor: 32-bit unsigned integer. Opaque. =20 If you have an issue with this resolution please speak up! =20 Pascal ------_=_NextPart_001_01CB2B3E.61F2B29A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Oups! This text is for issue = 72

 

Pascal

 

From:= Pascal = Thubert (pthubert)
Sent: Saturday, July 24, 2010 4:36 = PM
To: roll@ietf.org
Subject: solving issue = 71

 

Dear =
WG
 
Please find the =
proposed solution for issue 71 to add an opaque tag with the RPL route =
advertisements:
 
&nb=
sp;
Changed 6.4.3.  DAO Options to add the =
Descriptor
 
   =
The DAO message MAY carry valid =
options.
 
   =
This specification allows for the DAO message to carry the =
following
   =
options:
      0x00 =
Pad1
      0x01 =
PadN
      0x05 RPL =
Target
      0x06 Transit =
Information
      0x09 RPL =
Target =
Descriptor
 
 
 
Changed  6.7.7.  =
RPL Target

 

 

   A RPL = Target Option May optionally be paired with a RPL = Target

   = Descriptor Option (Section 6.8) that qualifies the = target.

 

   A set = of one or more Transit Information options (Section 6.7.8) = MAY

   = directly follow a set of one or more Target option in a DAO = message,

   where = each Target Option MAY be paired with a RPL Target = Descritor

   = Option.  The structure of the DAO message, detailing how = Target

   = options are used in conjunction with Transit Information options, = is

   = further described in Section 9.6.

 

 

 

Added

RPL Target =
descriptor
 
   =
The RPL Target option MAY be immediately followed by one =
opaque
   descriptor that qualifies that =
specific =
target.
 
 
        =
0            =
       =
1            =
       =
2            =
       =
3
        0 1 2 =
3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =
=3D 9    | Option Length |   =
Descriptor          &nb=
sp;       =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   =
Descriptor (cont.)          =
|
        &n=
bsp;  =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 <=
/pre>
           =
Figure 29: Format of the RPL Target Descriptor =
Option
 
   The =
RPL Target Descriptor Option is used to qualify a =
target,
   something that is sometimes =
called =
tagging.
 
   =
There can be at most one descriptor per target.  The descriptor =
is
   set by the node that injects the =
target in the RPL network.  It =
MUST
   be copied but not modified by =
routers that propagate the target up
   =
the DODAG in DAO =
messages.
 
   =
Option Type:  0x09 (to be confirmed by =
IANA)
 
   =
Option Length:  =
6
 
   =
Descriptor:  32-bit unsigned integer.  =
Opaque.
 
If you have an issue with this resolution please speak =
up!
 
Pascal
------_=_NextPart_001_01CB2B3E.61F2B29A-- From trac@tools.ietf.org Sat Jul 24 08:09:23 2010 Return-Path: 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 7FF7B3A689C for ; Sat, 24 Jul 2010 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 3gzVLDAAkfqc for ; Sat, 24 Jul 2010 08:09:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 755EF3A6A10 for ; Sat, 24 Jul 2010 08:09:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcgM9-0005A4-Jm; Sat, 24 Jul 2010 08:09:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pthubert@cisco.com, jpv@cisco.com X-Trac-Project: roll Date: Sat, 24 Jul 2010 15:09:41 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/64#comment:1 Message-ID: <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pthubert@cisco.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 15:09:23 -0000 #64: RPL Instance ID in flow label or RPL option -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pthubert@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Email from JP July 24 Following an email from Pascal. Great text, which I think address the ticket - minor comments below. On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote: Dear WG: Long discussions lead to specify only the location of the RPLinstanceID inside the RPL network, leaving it to policies the way the ingress router figures it out. The RPLinstanceID will be placed in the RPL option which is probably the cleanest and most generic thing we can do. Other drafts are allowed to come later and provide alternate forwarding rules eventually placing the content of the RPL option validation somewhere else, for instance in order to avoid IPinIP. A forwarding mode will probably indicate what the network does. Proposed changes: RPL uses a hop-by-hop IPv6 header to detect possible loops within a DODAG. -> RPL carries routing information in a RPL Option contained in an IPv6 Hop-by-Hop Option as specified in [I-D.hui-6man-rpl- option]. Such routing information are used for example for loop detection within a DODAG as discussed in Section 11.2 and may be extended in future documents for additional features. For data packets, the RPLInstanceID may be indicated in the flow label by the source of the packet. If it is not, then it is inferred and added by the RPL network ingress router in the RPL Hop-by-hop option ([I-D.hui-6man-rpl-option]) as further described in Section 10.2 è Data packet that flow within the RP network expose the RPLInstanceID in the RPL option that is specified in [I-D.hui-6man-rpl- option], and further described in Section 11.2. For data packets coming from outside the RPL network, the RPLInstanceID is determined by the RPL network ingress router and placed in the RPL option that is added to the packet. RPL loop detection uses information that is placed into the packet. A future version of this specification will detail how this information is carried with the packet (e.g. a hop-by-hop option ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow label). For the purpose of RPL operations, the information carried with a packet is constructed follows: è RPL loop detection uses information that contained within the data packet using the RPL Option [I-D.hui-6man-rpl-option]) in an IPv6 Hop-by-Hop Option header. The RPL Option is a generic container for a list of TLVs. This specification defines a new RPL Option type, called the RPL Loop Detection. The RPL Loop Detection TLV is placed in the RPL Option with Option Type = 1 (to be confirmed by IANA), Option Data Length = 4 octets, and the Value has the following format: The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For traffic originating outside of the RPL domain there may be a mapping occurring at the gateway into the RPL domain, possibly based on an encoding within the flow label. This aspect of RPL operation is to be clarified in a future version of this specification. The source of the packet might be aware of the RPL network, of the constraints imposed on OFs, and of associated Instance IDs. In that case, the source of the packet MAY tag the flow label with the RPLInstanceID, in which case it is used in that form within the RPL network. A router that injects a data packet into the RPL network MUST tag the packet by inserting a RPL Hop-by-hop option as specified in [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in flow label of the data packet, the ingress router that injects the packet into the RPL network MUST add a RPLInstanceID field to the RPL Hop-by-hop option. è The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. For a packet that is originated from outside the RPL network, the source of the packet might be aware of the RPL network, of the constraints imposed on OFs, and of associated RPLInstanceIDs. In that case, the source of the packet MAY tag the flow label with the RPLInstanceID. A RPL router that forwards a packet in the RPL network MUST check if the packet includes the RPL Loop Detection TLV in a RPL Option within the IPv6 Hop-by-Hop Option header. If one does not exist, the RPL router MUST insert a RPL Loop Detection type as specified in [I-D.hui-6man-rpl-option]. If the router is an ingress router that injects the packet into the RPL network, the router MUST set the RPLInstanceID field in the RPL Loop Detection TLV. JP> + add: A router that forwards a packet to outside the RPL domain MUST remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. As usual, please speak up if thereÂ’s an issue with the proposed resolution! Pascal -- Ticket URL: roll From trac@tools.ietf.org Sat Jul 24 08:13:51 2010 Return-Path: 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 DBB073A682F for ; Sat, 24 Jul 2010 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 eJ+fkY+e--XQ for ; Sat, 24 Jul 2010 08:13:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 078F83A657C for ; Sat, 24 Jul 2010 08:13:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcgQU-0000AI-Hf; Sat, 24 Jul 2010 08:14:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Sat, 24 Jul 2010 15:14:10 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/72#comment:1 Message-ID: <064.d37d18a3d01545aa3be5ee9ef89283c2@tools.ietf.org> References: <055.4b3b3ff8ad95c59b535425683e961cf4@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <055.4b3b3ff8ad95c59b535425683e961cf4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #72: Prefix-color X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 15:13:52 -0000 #72: Prefix-color --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Several expressed positive support, one neutral. Here is the proposing text: Please find the proposed solution for issue 71 to add an opaque tag with the RPL route advertisements: Changed 6.4.3. DAO Options to add the Descriptor The DAO message MAY carry valid options. This specification allows for the DAO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor Changed 6.7.7. RPL Target A RPL Target Option May optionally be paired with a RPL Target Descriptor Option (Section 6.8) that qualifies the target. A set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target option in a DAO message, where each Target Option MAY be paired with a RPL Target Descritor Option. The structure of the DAO message, detailing how Target options are used in conjunction with Transit Information options, is further described in Section 9.6. Added RPL Target descriptor The RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Option Length | Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Descriptor (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: Format of the RPL Target Descriptor Option The RPL Target Descriptor Option is used to qualify a target, something that is sometimes called tagging. There can be at most one descriptor per target. The descriptor is set by the node that injects the target in the RPL network. It MUST be copied but not modified by routers that propagate the target up the DODAG in DAO messages. Option Type: 0x09 (to be confirmed by IANA) Option Length: 6 Descriptor: 32-bit unsigned integer. Opaque. -- Ticket URL: roll From trac@tools.ietf.org Sat Jul 24 09:56:46 2010 Return-Path: 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 D80B93A67B8 for ; Sat, 24 Jul 2010 09:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 cZQAatEmIblp for ; Sat, 24 Jul 2010 09:56:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DE4D03A6359 for ; Sat, 24 Jul 2010 09:56:45 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Oci24-0006du-AT; Sat, 24 Jul 2010 09:57:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sat, 24 Jul 2010 16:57:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/73 Message-ID: <055.04fd304a30dd5f51fce91e0bac6ddf94@tools.ietf.org> X-Trac-Ticket-ID: 73 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #73: determining downward routes at the root X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 16:56:46 -0000 #73: [Roll] determining downward routes at the root --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- ----- Original Message ----- From: "Mukul Goyal" To: "Pascal Thubert (pthubert)" Cc: "roll" Sent: Tuesday, July 20, 2010 11:40:13 AM Subject: Re: [Roll] determining downward routes at the root Hi Pascal I think, in the absence of any explanation in the text, there is a risk of misinterpretation. So, this is my interpretation of how it will work: Root needs to determine the source route to node N. Root starts with node N's DAO, finds its highest preference parent, adds it to the route and then repeats the procedure with this parent. This continues until the route is complete. So, this is a greedy approach to route discovery. The underlying assumption seems to be that a more preferred parent is infinitely better for downwards routing than a less preferred parent. Another possibility is to let the DAG root reverse the path control field and use it as link cost to determine shortest paths to a destination using dijkstra. It seems to me that there needs to be some guidance, perhaps in the objective function, regarding how path control is to be used (for non-storing operation) and how would the root calculate the downwards routes. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "roll" Sent: Tuesday, July 20, 2010 6:26:00 AM Subject: RE: [Roll] determining downward routes at the root Hi Mukul: This is a pretty classical recursive route lookup. Only the highest preference 1hop route should show up so recursively the root will quite naturally build the source route header. Routing protocols usually do not describe such operation. Do you think there is a risk of misinterpretation? Would someone else please shime in? Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Tuesday, July 20, 2010 11:25 AM To: roll Subject: [Roll] determining downward routes at the root I was wondering if it makes sense to add some text to the RPL draft regarding how does a root, in non-storing LLN, determine the _shortest_ downward routes to different destinations using the "path control" values as the (inverse) link costs. Thanks Mukul _______________________________________________ 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 -- Ticket URL: roll From pthubert@cisco.com Sat Jul 24 10:12:11 2010 Return-Path: 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 22CD43A680E for ; Sat, 24 Jul 2010 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 NjvGGsfoBx28 for ; Sat, 24 Jul 2010 10:12: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 95F6C3A67B8 for ; Sat, 24 Jul 2010 10:12:06 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208";a="563240895" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2010 17:12:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6OHCPvU009838; Sat, 24 Jul 2010 17:12:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 19:12:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 24 Jul 2010 19:12:21 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0260AF1C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing] #73: determining downward routes at the root thread-index: AcsrU18hKVbb4p8wSa6OuWApj2bMhg== From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 24 Jul 2010 17:12:24.0579 (UTC) FILETIME=[628BA530:01CB2B53] Subject: [Roll] Closing] #73: determining downward routes at the root 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: , X-List-Received-Date: Sat, 24 Jul 2010 17:12:12 -0000 VGhlIGVkaXRvcnMgaGFkIGEgY2hhdCB3aXRoIGplcnJ5IGFuZCBNdWt1bC4gSW4gdGhlIGNvbnRl eHQgb2YgaXNzdWUgNjAsIFRpbSB3aWxsIGJlIGFkZGluZyB0ZXh0IG9uIHRoZSBwYXRoIGNvbnRy b2wgb3BlcmF0aW9uLiANCkZvciB0aGUgc3BlY2lmaWMgaXNzdWUsIHRoZSBwcm9wb3NlZCBmaXgg aXMgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCBiYXNlZCBvbiBNdWt1bCdzIHN1Z2dlc3Rpb246 DQoNCiJ0aGUgY29udHJvbCBmaWVsZCBwcmVmZXJlbmNlIChvZiB0aGUgREFPIHBhcmVudHMpIGlz IGRldGVybWluZWQgb24gdGhlIGJhc2lzIG9mIHRoaXMgbm9kZSdzIGJlc3Qga25vd2xlZGdlIG9m IHRoZSAiZW5kLXRvLWVuZCIgYWdncmVnYXRlZCBtZXRyaWNzIGluIHRoZSAiZG93bndhcmQiIGRp cmVjdGlvbiBhcyBwZXIgdGhlIG9iamVjdGl2ZSBmdW5jdGlvbiwgc28gdGhlIHJvb3QgY2FuIGRl dGVybWluZSB0aGUgZG93bndhcmQgcm91dGUgYnkgcmVjdXJzaXZlbHkgc2VsZWN0aW5nIHRoZSBi ZXN0IHByZWZlcmVuY2UgMSBob3Atcm91dGUuIg0KDQpBcyB1c3VhbCwgaWYgeW91IGhhdmUgb2Jq ZWN0aW9ucyBwbGVhc2Ugc3BlYWsgbm93IDogKQ0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJv bGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJvbGwNCj4gaXNzdWUgdHJhY2tlcg0K PiBTZW50OiBTYXR1cmRheSwgSnVseSAyNCwgMjAxMCA2OjU3IFBNDQo+IFRvOiB3aW50ZXJ0QGFj bS5vcmc7IGpwdkBjaXNjby5jb20NCj4gQ2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1Jv bGxdIFtyb2xsXSAjNzM6IGRldGVybWluaW5nIGRvd253YXJkIHJvdXRlcyBhdCB0aGUgcm9vdA0K PiANCj4gIzczOiBbUm9sbF0gZGV0ZXJtaW5pbmcgZG93bndhcmQgcm91dGVzIGF0IHRoZSByb290 DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tDQo+ICBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAg d2ludGVydEDigKYNCj4gICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICB8ICAgICAgU3Rh dHVzOiAgbmV3DQo+ICBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgfCAgIE1pbGVzdG9u ZToNCj4gQ29tcG9uZW50OiAgcnBsICAgICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiAg U2V2ZXJpdHk6ICBBY3RpdmUgV0cgRG9jdW1lbnQgIHwgICAgS2V5d29yZHM6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tDQo+ICAtLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ICBGcm9tOiAiTXVrdWwgR295YWwiIDxtdWt1bEB1 d20uZWR1Pg0KPiAgVG86ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lz Y28uY29tPg0KPiAgQ2M6ICJyb2xsIiA8cm9sbEBpZXRmLm9yZz4NCj4gIFNlbnQ6IFR1ZXNkYXks IEp1bHkgMjAsIDIwMTAgMTE6NDA6MTMgQU0NCj4gIFN1YmplY3Q6IFJlOiBbUm9sbF0gZGV0ZXJt aW5pbmcgZG93bndhcmQgcm91dGVzIGF0IHRoZSByb290DQo+IA0KPiAgSGkgUGFzY2FsDQo+IA0K PiAgSSB0aGluaywgaW4gdGhlIGFic2VuY2Ugb2YgYW55IGV4cGxhbmF0aW9uIGluIHRoZSB0ZXh0 LCB0aGVyZSBpcyBhIHJpc2sgIG9mDQo+IG1pc2ludGVycHJldGF0aW9uLg0KPiANCj4gIFNvLCB0 aGlzIGlzIG15IGludGVycHJldGF0aW9uIG9mIGhvdyBpdCB3aWxsIHdvcms6DQo+IA0KPiAgUm9v dCBuZWVkcyB0byBkZXRlcm1pbmUgdGhlIHNvdXJjZSByb3V0ZSB0byBub2RlIE4uIFJvb3Qgc3Rh cnRzIHdpdGggIG5vZGUgTidzDQo+IERBTywgZmluZHMgaXRzIGhpZ2hlc3QgcHJlZmVyZW5jZSBw YXJlbnQsIGFkZHMgaXQgdG8gdGhlIHJvdXRlICBhbmQgdGhlbiByZXBlYXRzDQo+IHRoZSBwcm9j ZWR1cmUgd2l0aCB0aGlzIHBhcmVudC4gVGhpcyBjb250aW51ZXMgdW50aWwgIHRoZSByb3V0ZSBp cyBjb21wbGV0ZS4NCj4gDQo+ICBTbywgdGhpcyBpcyBhIGdyZWVkeSBhcHByb2FjaCB0byByb3V0 ZSBkaXNjb3ZlcnkuIFRoZSB1bmRlcmx5aW5nICBhc3N1bXB0aW9uDQo+IHNlZW1zIHRvIGJlIHRo YXQgYSBtb3JlIHByZWZlcnJlZCBwYXJlbnQgaXMgaW5maW5pdGVseSBiZXR0ZXIgIGZvciBkb3du d2FyZHMNCj4gcm91dGluZyB0aGFuIGEgbGVzcyBwcmVmZXJyZWQgcGFyZW50Lg0KPiANCj4gIEFu b3RoZXIgcG9zc2liaWxpdHkgaXMgdG8gbGV0IHRoZSBEQUcgcm9vdCByZXZlcnNlIHRoZSBwYXRo IGNvbnRyb2wgIGZpZWxkIGFuZCB1c2UNCj4gaXQgYXMgbGluayBjb3N0IHRvIGRldGVybWluZSBz aG9ydGVzdCBwYXRocyB0byBhICBkZXN0aW5hdGlvbiB1c2luZyBkaWprc3RyYS4NCj4gDQo+ICBJ dCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgZ3VpZGFuY2UsIHBlcmhh cHMgaW4gdGhlICBvYmplY3RpdmUNCj4gZnVuY3Rpb24sIHJlZ2FyZGluZyBob3cgcGF0aCBjb250 cm9sIGlzIHRvIGJlIHVzZWQgKGZvciAgbm9uLXN0b3Jpbmcgb3BlcmF0aW9uKQ0KPiBhbmQgaG93 IHdvdWxkIHRoZSByb290IGNhbGN1bGF0ZSB0aGUgZG93bndhcmRzICByb3V0ZXMuDQo+IA0KPiAg VGhhbmtzDQo+ICBNdWt1bA0KPiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiAgRnJv bTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQo+ICBU bzogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4sICJyb2xsIiA8cm9sbEBpZXRmLm9yZz4N Cj4gIFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjAsIDIwMTAgNjoyNjowMCBBTQ0KPiAgU3ViamVjdDog UkU6IFtSb2xsXSBkZXRlcm1pbmluZyBkb3dud2FyZCByb3V0ZXMgYXQgdGhlIHJvb3QNCj4gDQo+ ICBIaSBNdWt1bDoNCj4gDQo+ICBUaGlzIGlzIGEgcHJldHR5IGNsYXNzaWNhbCByZWN1cnNpdmUg cm91dGUgbG9va3VwLiBPbmx5IHRoZSBoaWdoZXN0ICBwcmVmZXJlbmNlDQo+IDFob3Agcm91dGUg c2hvdWxkIHNob3cgdXAgc28gcmVjdXJzaXZlbHkgdGhlIHJvb3Qgd2lsbCBxdWl0ZSAgbmF0dXJh bGx5IGJ1aWxkIHRoZQ0KPiBzb3VyY2Ugcm91dGUgaGVhZGVyLiBSb3V0aW5nIHByb3RvY29scyB1 c3VhbGx5IGRvICBub3QgZGVzY3JpYmUgc3VjaCBvcGVyYXRpb24uDQo+IA0KPiAgRG8geW91IHRo aW5rIHRoZXJlIGlzIGEgcmlzayBvZiBtaXNpbnRlcnByZXRhdGlvbj8NCj4gIFdvdWxkIHNvbWVv bmUgZWxzZSBwbGVhc2Ugc2hpbWUgaW4/DQo+IA0KPiAgUGFzY2FsDQo+IA0KPiANCj4gIC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICBGcm9tOiByb2xsLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiAgT2YNCj4gTXVrdWwgR295YWwN Cj4gIFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjAsIDIwMTAgMTE6MjUgQU0NCj4gIFRvOiByb2xsDQo+ ICBTdWJqZWN0OiBbUm9sbF0gZGV0ZXJtaW5pbmcgZG93bndhcmQgcm91dGVzIGF0IHRoZSByb290 DQo+IA0KPiAgSSB3YXMgd29uZGVyaW5nIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFkZCBzb21lIHRl eHQgdG8gdGhlIFJQTCBkcmFmdCAgcmVnYXJkaW5nDQo+IGhvdyBkb2VzIGEgcm9vdCwgaW4gbm9u LXN0b3JpbmcgTExOLCBkZXRlcm1pbmUgdGhlIF9zaG9ydGVzdF8gZG93bndhcmQNCj4gcm91dGVz IHRvIGRpZmZlcmVudCBkZXN0aW5hdGlvbnMgdXNpbmcgdGhlICJwYXRoIGNvbnRyb2wiIHZhbHVl cyBhcyAgdGhlIChpbnZlcnNlKQ0KPiBsaW5rIGNvc3RzLg0KPiANCj4gIFRoYW5rcw0KPiAgTXVr dWwgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gUm9sbCBt YWlsaW5nDQo+IGxpc3QgUm9sbEBpZXRmLm9yZyAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsDQo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gDQo+IC0tDQo+IFRpY2tldCBVUkw6 IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9yb2xsL3RyYWMvdGlja2V0LzczPg0KPiBy b2xsIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0K PiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbA0K From jpv@cisco.com Sat Jul 24 10:15:55 2010 Return-Path: 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 EAFB53A69F7 for ; Sat, 24 Jul 2010 10:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 zoc7YNQIbIOh for ; Sat, 24 Jul 2010 10:15:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EC10D3A68BF for ; Sat, 24 Jul 2010 10:15:54 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALy8SkyrR7Hu/2dsb2JhbACfZnGlH5omhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208";a="346157067" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2010 17:16:14 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6OHGDTd007827; Sat, 24 Jul 2010 17:16:14 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 19:16:12 +0200 Received: from [192.168.1.11] ([10.61.85.221]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Jul 2010 19:16:12 +0200 Message-Id: <5F8A522F-3966-4EBE-99CB-599E735385E4@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0260AF1C@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Jul 2010 19:16:11 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D0260AF1C@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Jul 2010 17:16:12.0240 (UTC) FILETIME=[EA3DF500:01CB2B53] Cc: roll@ietf.org Subject: Re: [Roll] Closing] #73: determining downward routes at the root 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: , X-List-Received-Date: Sat, 24 Jul 2010 17:15:56 -0000 On Jul 24, 2010, at 7:12 PM, Pascal Thubert (pthubert) wrote: > The editors had a chat with jerry and Mukul. In the context of issue =20= > 60, Tim will be adding text on the path control operation. > For the specific issue, the proposed fix is to add the following =20 > text based on Mukul's suggestion: > > "the control field preference (of the DAO parents) is determined on =20= > the basis of this node's best knowledge of the "end-to-end" =20 > aggregated metrics in the "downward" direction as per the objective =20= > function, so the root can determine the downward route by =20 > recursively selecting the best preference 1 hop-route." > Thanks Pascal, in the discussion thread, additional text was also =20 suggested to address Mukul's concerns. We'll add it to the ticket =20 resolution. > As usual, if you have objections please speak now : ) > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of roll >> issue tracker >> Sent: Saturday, July 24, 2010 6:57 PM >> To: wintert@acm.org; jpv@cisco.com >> Cc: roll@ietf.org >> Subject: [Roll] [roll] #73: determining downward routes at the root >> >> #73: [Roll] determining downward routes at the root >> --------------------------------=20 >> +--------------------------------------- >> --------------------------------+---- >> Reporter: jpv@=85 | Owner: wintert@=85 >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: rpl | Version: >> Severity: Active WG Document | Keywords: >> --------------------------------=20 >> +--------------------------------------- >> --------------------------------+---- >> ----- Original Message ----- >> From: "Mukul Goyal" >> To: "Pascal Thubert (pthubert)" >> Cc: "roll" >> Sent: Tuesday, July 20, 2010 11:40:13 AM >> Subject: Re: [Roll] determining downward routes at the root >> >> Hi Pascal >> >> I think, in the absence of any explanation in the text, there is a =20= >> risk of >> misinterpretation. >> >> So, this is my interpretation of how it will work: >> >> Root needs to determine the source route to node N. Root starts =20 >> with node N's >> DAO, finds its highest preference parent, adds it to the route and =20= >> then repeats >> the procedure with this parent. This continues until the route is =20= >> complete. >> >> So, this is a greedy approach to route discovery. The underlying =20 >> assumption >> seems to be that a more preferred parent is infinitely better for =20= >> downwards >> routing than a less preferred parent. >> >> Another possibility is to let the DAG root reverse the path =20 >> control field and use >> it as link cost to determine shortest paths to a destination using =20= >> dijkstra. >> >> It seems to me that there needs to be some guidance, perhaps in =20 >> the objective >> function, regarding how path control is to be used (for non-=20 >> storing operation) >> and how would the root calculate the downwards routes. >> >> Thanks >> Mukul >> ----- Original Message ----- >> From: "Pascal Thubert (pthubert)" >> To: "Mukul Goyal" , "roll" >> Sent: Tuesday, July 20, 2010 6:26:00 AM >> Subject: RE: [Roll] determining downward routes at the root >> >> Hi Mukul: >> >> This is a pretty classical recursive route lookup. Only the =20 >> highest preference >> 1hop route should show up so recursively the root will quite =20 >> naturally build the >> source route header. Routing protocols usually do not describe =20 >> such operation. >> >> Do you think there is a risk of misinterpretation? >> Would someone else please shime in? >> >> Pascal >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =20 >> Behalf Of >> Mukul Goyal >> Sent: Tuesday, July 20, 2010 11:25 AM >> To: roll >> Subject: [Roll] determining downward routes at the root >> >> I was wondering if it makes sense to add some text to the RPL =20 >> draft regarding >> how does a root, in non-storing LLN, determine the _shortest_ =20 >> downward >> routes to different destinations using the "path control" values =20 >> as the (inverse) >> link costs. >> >> Thanks >> Mukul _______________________________________________ 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 >> >> -- >> Ticket URL: >> roll >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sat Jul 24 14:06:27 2010 Return-Path: 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 7D3913A6768 for ; Sat, 24 Jul 2010 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=0.587, 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 ezNKAT8ZZXwD for ; Sat, 24 Jul 2010 14:06:22 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6BE3A67B5 for ; Sat, 24 Jul 2010 14:06:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 0FD3A9400AD for ; Sat, 24 Jul 2010 23:06:34 +0200 (CEST) Message-ID: <4C4B55D7.4060407@gmail.com> Date: Sat, 24 Jul 2010 23:06:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <9BB070DB2D281946859EA89837931EEE0F5896@EVS4.nam.ci.root> <4C17F94C.5090005@gmail.com> <19516.1276795896@marajade.sandelman.ca> In-Reply-To: <19516.1276795896@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Using IPsec with RPL 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: , X-List-Received-Date: Sat, 24 Jul 2010 21:06:27 -0000 Le 17/06/2010 19:31, Michael Richardson a écrit : > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > There is a thread about IPsec with RPL. I read it all. > > Most of the thread misses the point about IPsec. > > Let me just prefix this by stating that I've worked on IPsec related > standards for 15 years, implemented it several times in several > different operating systems, and managed the technical aspects of the > Linux Freeswan and Xelerance Openswan projects. I mention this > because many of you in this group are experts in your fields (of > which I am often ignorant), and the reverse is the case. > > For quite a number of years, non-security WGs of the IETF tried to > say just say, "Use IPsec" in their protocols. This was a total > FAIL. > > Starting around 2000, mostly with the iSCSI specifications, using > IPsec means actually specifying a number of things. Not just Tunnel > vs Transport, and not just AES vs 3DES. In fact, those things are > irrelevant. > > The question is: where does the trust and authorization come from? > > This is the question I keep asking about the security in RPL. > > We can use AH format or not. Let's use it. > It doesn't matter much. I think there are some differences, because AH may protect more fields of RPL (ICMP), but I have to check in detail. > There are essentially no interesting hardware accelerators that can > do AH calculations, that can't also do just do HMAC-SHA1-96. (The > HMAC construct has proved to be very resiliant to all the hash > attacks involving preimages. You might think that MD5 is be broken, > but HMAC-MD5 is still very strong) WEll yes, I believe the strength required depends on the nature of attacks. A computational attack coming from a supercomputer (or distributed.net?) would require more strength to resist. In this sense, I believe MD5 or even MD4 could be enough (yes, HMAC-MD5) for RPL. Who are the attackers? What's their computing power? (and yes, I still have to read the RPL doc in detail, soon). Alex > > > > ***** The question is: how do we create and distribute keys? ***** > > > > IKE? IKEv2? How many keys are required? A naive use of IPsec *OR > ANY NETWORK INTEGRITY* system would require a set of available keys > for each pair of nodes that wishes to communicate. THIS WON'T WORK. > > As such we must look to the gkmp WG and consider whether statically > distributing keys is useful. > > We must also very carefully consider bootstrapping, and asking the > questions: which parts of an RPL (DIO,DOA,+various P2P pieces) > message can a receiving node trust and/or act upon *EVEN* if the > integrity check can not be verified? > > IPsec has been specified for multicast from the beginning, but in > general you have to: a) manually key the SAs b) this implies turning > off replay protection > > I believe that we could document a standard way of using AH with our > hop-by-hop multicast and unicast packets (treating the unicast > packets as if they were multicast for security), and it might be > useful. But, what's the point if we aren't using IKE? There is > little code reuse that I can see. Specification reuse, great. > Particularly in the "FOO-bar algorithm for use with ESP/AH". > > - -- ] He who is tired of Weird Al is tired of life! | > firewalls [ ] Michael Richardson, Sandelman Software Works, > Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch > the video then sign the > petition. > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBTBpb7oCLcPvd0N1lAQLBnwf/T4J3iq6A2oFmchHCJfxMC1gy3SvNodQI > zxoeiIJn035yy08dTWbCBSdpfDqQR9d7oxLw75eb02PFLjUCd44/SS8AGuy2vBMw > LJo0tmEmmGJWdZiqzZKWRA5J+2EloTGWqFhRjfwtHD03QCtQMPN5RhygW5PLz4Of > Pp3iOZqt9Sbce5aDX2PnOcy2hnQPK0zWczXqpjcBxf3bipEK9PkY5uiPggzMAWJ5 > wmdbcI4EK9eAkP1Hrs8/RzcjWzAva6V6xp1r0qlrqK2LuXValTRFIRy5xP6CTHbA > xW3++uiigS9kk0rGvHT6IsTAon0H7buwxSyHpuUImLLLtij+saXeTQ== =m0Vn > -----END PGP SIGNATURE----- > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sat Jul 24 14:14:53 2010 Return-Path: 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 C981B3A683A for ; Sat, 24 Jul 2010 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.556, 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 qG2k03VoZnF9 for ; Sat, 24 Jul 2010 14:14:51 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 909993A67F9 for ; Sat, 24 Jul 2010 14:14:49 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C95499400B2 for ; Sat, 24 Jul 2010 23:15:04 +0200 (CEST) Message-ID: <4C4B57D5.5060306@gmail.com> Date: Sat, 24 Jul 2010 23:15:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> <80AF40A5-E114-4F27-882A-8BD91EFEF0D0@cs.stanford.edu> In-Reply-To: <80AF40A5-E114-4F27-882A-8BD91EFEF0D0@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Sat, 24 Jul 2010 21:14:53 -0000 Le 24/07/2010 15:06, Philip Levis a écrit : > > On Jul 24, 2010, at 5:57 AM, Ulrich Herberg wrote: > >> On Fri, Jul 23, 2010 at 8:47 PM, David >> Culler wrote: >>> While the various companies that have disclosed IPR relative to >>> RPL have been generous in enabling the standard to move forward, >>> it behooves us to do everything we can to create standards that >>> do not require proprietary IP to achieve interoperable >>> implementations. It seems clear that we should pursue a variant >>> of 2. We should complete the core spec utilizing a security >>> scheme that is unencumbered. We should make sure that there is >>> enough room in the encoding that we may consider more highly >>> optimized schemes later. In that time, we can sort out IPR >>> issues. With so many signature schemes already well >>> established it would be very surprising that we simply cannot use >>> any of them. The disclosed IPR may provide substantial >>> improvements, but that is certainly a secondary concern. >>> >>> Can the security DT suggest one or more such openly available >>> options. >> >> I fully agree. There should be other, unencumbered algorithms, >> which provide similar levels of performance and signature lengths. >> It would be good to investigate these. > > Ulrich, > > I fully agree as well. It turns out that such algorithms which are > unencumbered by IPR are not *that* easy to find, however. WEll, I wonder about MD4 and MD5: are they free of IPR and easier to export control? ("export control" is the US or other country law making it difficult to export to other countries, thus hard to use Internet-wide). This question may be off the current security thinking in RPL, and it may show I have no experience at all, but I felt I would just ask - sorry for disturbing. > I consulted with my resident cryptographic expert, Dan Boneh[1]. He > suggested an algorithm which he developed in 2001 or so, based on > the Weil pairing[2], which is completely open and has no encumbering > IPR. At first glance, it seems to possibly be technically superior > than the Certicom-encumbered one in terms of factors we care about > (e.g., signature length), which was already very attractive. There > are reference implementations[3], and the FAA is beginning to > incorporate it into some of their systems. The security DT is > currently examining the algorithm. I hope to give an update soon. WEll the first questions I'd ask is - is it a published or a secret algorithm? Is it implemented? Is the implementation available under some good license? Have many eye-balls read and tried to attack? Etc. (not to ask whether it's been already documented in a draft, that could come later). Alex > > Phil > > [1] http://crypto.stanford.edu/ [2] > http://crypto.stanford.edu/~dabo/pubs/abstracts/weilsigs.html [3] > http://crypto.stanford.edu/pbc/ > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sat Jul 24 14:47:17 2010 Return-Path: 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 837723A683A for ; Sat, 24 Jul 2010 14:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[AWL=-0.772, 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 suHrsVrIUZmC for ; Sat, 24 Jul 2010 14:47:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 823463A6768 for ; Sat, 24 Jul 2010 14:47:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 24543940089 for ; Sat, 24 Jul 2010 23:47:29 +0200 (CEST) Message-ID: <4C4B5F6F.3020108@gmail.com> Date: Sat, 24 Jul 2010 23:47:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Could all paths terminate at two nodes? 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: , X-List-Received-Date: Sat, 24 Jul 2010 21:47:17 -0000 Could all paths terminate at two nodes? > DAG: Directed Acyclic Graph. A directed graph having the property > that all edges are oriented in such a way that no cycles exist. > All edges are contained in paths oriented toward and > terminating at one or more root nodes. For some reason I have a hard time understanding: "all [...] paths terminating at [...] more root nodes". Is it possible to have _all_ unicast paths to _terminate_ at _two_ root nodes? If they _all_ _terminate_ at one node then not even one could go any further to the second node. Or is it that edges and paths are not the same thing? Or is it that _some_ paths may terminate at a node whereas _other_ paths could terminate at other node? If so then it should say so. For example: "All edges are contained in paths and all paths contain edges (define "contain"). Paths are oriented towards terminating nodes; some paths may terminate at some nodes whereas other paths at other nodes". (this definition has strong influence on understanding the subsequent definitions DAG root, DODAG root, and the rest of the draft and discussion). Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:03:37 2010 Return-Path: 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 DAA633A6829 for ; Sat, 24 Jul 2010 15:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_20=-0.74, 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 NBODdDOhu9s1 for ; Sat, 24 Jul 2010 15:03:37 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B80B43A6821 for ; Sat, 24 Jul 2010 15:03:35 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 580A3940063 for ; Sun, 25 Jul 2010 00:03:50 +0200 (CEST) Message-ID: <4C4B6343.5030505@gmail.com> Date: Sun, 25 Jul 2010 00:03:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Is the term 'destination prefix' appropriate in RPL and LLN 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:03:38 -0000 For some reason I do not like the term 'destination prefix': > A RPL Instance may provide routes to certain destination prefixes [...] > The Route Information option is used to indicate that connectivity > to the specified destination prefix is available from the DODAG > root. [...] > A DAO Routing Table Entry conceptually contains the following > elements (for storing nodes only): [...] > * DAO Lifetime > > * DAO Path Control > > o Destination Prefix (or Address or Mcast Group) I couldn't understand a Destination Prefix being a Mcast Group ("Mcast Group" is probably a "multicast address" and that has no prefix length or if it had it were 128 like an address). Additionally, it makes little sense to talk prefixes instead of addresses when the deployment seems to be nodes without subnets covering them, i.e. without a prefix covering several nodes (like in an Ethernet subnet); and which are mobile, i.e. the addresses hardly aggregatable into a prefix, usually done according to an initial plan. Not sure how to explain this but it is hard to me to grasp the term "destination prefix" in the context of RPL and LLN. I may be wrong... Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:08:49 2010 Return-Path: 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 C35CB3A6829 for ; Sat, 24 Jul 2010 15:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_05=-1.11, 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 iZxiGNRBvvHU for ; Sat, 24 Jul 2010 15:08:49 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B5EF93A66B4 for ; Sat, 24 Jul 2010 15:08:47 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 779139400BA; Sun, 25 Jul 2010 00:09:01 +0200 (CEST) Message-ID: <4C4B647A.1080408@gmail.com> Date: Sun, 25 Jul 2010 00:08:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> In-Reply-To: <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:08:49 -0000 Le 23/07/2010 18:22, Philip Levis a écrit : > > On Jul 23, 2010, at 12:34 AM, Alexandru Petrescu wrote: > >> Le 23/07/2010 02:09, Philip Levis a écrit : > > >> >>> This flexibility is because some LLNs have security mechanisms >>> (e.g., link layer) which can render the RPL ones superfluous, >>> therefore optional. >> >> I agree. When link layer security is relied upon then we should >> state so, in the draft, with the names of the link layer security. >> >>> One of the stated design goals from the beginning is that RPL >>> should not require security mechanisms when they are not needed. >> >> Is this reflected in the draft? > > Alex, I think these discussions might be more productive if you read > the RPL draft, as well as the motivating application drafts, before > making forceful comments about how RPL should work. > > 3.3.3. Security > > RPL supports message confidentiality and integrity. It is designed > such that link-layer mechanisms can be used when available and > appropriate, yet in their absence RPL can use its own mechanisms. > RPL has three basic security modes. But earlier the draft says: > In compliance with the layered architecture of IP, RPL does not rely > on any particular features of a specific link layer technology. which I interpret as saying RPL does not use any feature from the link layer (e.g. security). I think these two paragraphs sound contradictory(?) Alex > > > Phil From alexandru.petrescu@gmail.com Sat Jul 24 15:11:28 2010 Return-Path: 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 B8DC23A67E2 for ; Sat, 24 Jul 2010 15:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=-0.711, 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 VlbgvyW+Yp88 for ; Sat, 24 Jul 2010 15:11:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 83A6E3A66B4 for ; Sat, 24 Jul 2010 15:11:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 218889400CB for ; Sun, 25 Jul 2010 00:11:40 +0200 (CEST) Message-ID: <4C4B651A.4030402@gmail.com> Date: Sun, 25 Jul 2010 00:11:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Mentioning link layer names in RPL doc 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:11:28 -0000 I think the draft should mention more about the link layers it uses. For example here: > RPL is designed to be able to operate over a variety of different > link layers, including but not limited to, low power wireless or PLC > (Power Line Communication) technologies. It is the only name of a link layer appearing in the draft (if I read it correctly). I think more names should appear, to not give the impression that PLC were paramount. And for "PLC" the name of that particular PLC technology (IEEE something?) is worth to write. Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:15:11 2010 Return-Path: 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 CE7623A6829 for ; Sat, 24 Jul 2010 15:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=-0.682, 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 y0ZpyUuZ8wWZ for ; Sat, 24 Jul 2010 15:15:09 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 13CC53A683A for ; Sat, 24 Jul 2010 15:15:06 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5DEA5940024 for ; Sun, 25 Jul 2010 00:15:21 +0200 (CEST) Message-ID: <4C4B65F6.2060705@gmail.com> Date: Sun, 25 Jul 2010 00:15:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:15:11 -0000 I have difficulty understanding the term "meta-data": > Each RPL packet has meta-data that associates it with a particular > RPLInstanceID and therefore RPL Instance.(Section 4). [...] > For example, a node may continue to send data packets whose meta-data > include a Rank that is not INFINITE_RANK yet still advertise > INFINITE_RANK in its DIOs. These are the only two occurences of the term "meta" and it is new to me. What is the structure of the meta data? Is it a conceptual data structure? (I agree, it may be only me, I had a same issue with "out-of-band" data and it turned out everybody understood it except me). Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:18:10 2010 Return-Path: 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 D202D3A6829 for ; Sat, 24 Jul 2010 15:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.303 X-Spam-Level: X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[AWL=-0.654, 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 Hn2DFppSJjZh for ; Sat, 24 Jul 2010 15:18:06 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C2EB13A680D for ; Sat, 24 Jul 2010 15:18:05 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8A21D940011 for ; Sun, 25 Jul 2010 00:18:20 +0200 (CEST) Message-ID: <4C4B66A9.4060409@gmail.com> Date: Sun, 25 Jul 2010 00:18:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] What is "non-LLN backchannel" and "non-LLN backbone"? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:18:10 -0000 What is "non-LLN backchannel" and "non-LLN backbone"? Is it the same thing? If yes then what is it? (new to me, sorry). > These roots may operate independently, or may coordinate over > a non-LLN backchannel. [...] > o a single DODAG with a single virtual root coordinating LLN sinks > (with the same DODAGID) over some non-LLN backbone Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:24:22 2010 Return-Path: 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 594F43A682A for ; Sat, 24 Jul 2010 15:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=-0.629, 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 Z7DlTDPsDkDO for ; Sat, 24 Jul 2010 15:24:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 78A353A6829 for ; Sat, 24 Jul 2010 15:24:19 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3FDF1940067 for ; Sun, 25 Jul 2010 00:24:35 +0200 (CEST) Message-ID: <4C4B6820.8000807@gmail.com> Date: Sun, 25 Jul 2010 00:24:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: how a DODAG version number increment leads to a new DODAG Version 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:24:22 -0000 Nit: > Figure 2 depicts how a DODAG version number increment leads to a new > DODAG Version. How? By incrementing, no need to look at the figure, it's right there in the text. Worried of my misunderstanding I start thinking whether "version" is the same as "Version". I think worry is not motivated, but rather that this is a nit. Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:30:18 2010 Return-Path: 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 8CC8D3A6876 for ; Sat, 24 Jul 2010 15:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=-0.606, 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 r5d5xvQFsaBP for ; Sat, 24 Jul 2010 15:30:17 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1A53A683A for ; Sat, 24 Jul 2010 15:30:15 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3EABB940067 for ; Sun, 25 Jul 2010 00:30:30 +0200 (CEST) Message-ID: <4C4B6984.8020509@gmail.com> Date: Sun, 25 Jul 2010 00:30:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Up or up? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:30:18 -0000 > Up: Up refers to the direction from leaf nodes towards DODAG > roots, [...] > RPL provisions routes up towards DODAG roots, Usually when terms are defined in the Terminology we subsequently use these terms capitalized to distinguish from the more mundane uses, avoid confusion. HEre, it is difficult to understand. Did the Author mean "up" the mundane? Or "Up" the term in Terminology section. "Up" in the sense of Terminology would mean that RPL provided routes to DODAG roots, and my remark would be to provide them in the other way around as well. "up" in the mundane sense would be ok, because it would mean "up they go", somebody "up" there takes care of routes, etc. and I would not have any remark. Did the Author mean "up" or "Up"? Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:36:06 2010 Return-Path: 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 D3CFE3A680D for ; Sat, 24 Jul 2010 15:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.233 X-Spam-Level: X-Spam-Status: No, score=-0.233 tagged_above=-999 required=5 tests=[AWL=-0.584, 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 YAa+OOGE2LwK for ; Sat, 24 Jul 2010 15:36:06 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id EF5B93A67D3 for ; Sat, 24 Jul 2010 15:36:04 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id B6E7694007A for ; Sun, 25 Jul 2010 00:36:19 +0200 (CEST) Message-ID: <4C4B6AE0.9060602@gmail.com> Date: Sun, 25 Jul 2010 00:36:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: hosts or DODAGs required to satisfy app goals? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:36:06 -0000 > A grounded DODAG offers connectivity to hosts that are required for > satisfying the application-defined goal. Comma missing? Who is required? The hosts or the connectivity? Required for satisfying or required to satisfy? > A floating DODAG is not expected to satisfy the goal Ah, it seems it is the DODAG who is expected. So it should say "that is" required, not "that are" required. What did the Author mean? Alex > and in most cases only provides routes to nodes within the DODAG. > Floating DODAGs may be used, for example, to preserve inner > connectivity during repair. From alexandru.petrescu@gmail.com Sat Jul 24 15:43:15 2010 Return-Path: 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 3E5573A6876 for ; Sat, 24 Jul 2010 15:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.584 X-Spam-Level: X-Spam-Status: No, score=-0.584 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_20=-0.74, 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 0skaa-5Ywh-f for ; Sat, 24 Jul 2010 15:43:14 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 4DFCF3A687E for ; Sat, 24 Jul 2010 15:43:12 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1671F940041 for ; Sun, 25 Jul 2010 00:43:27 +0200 (CEST) Message-ID: <4C4B6C8D.50100@gmail.com> Date: Sun, 25 Jul 2010 00:43:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:43:15 -0000 Nit: what is a datapath? The term appears in the title of a section > 3.3.7. Datapath Validation and Loop Detection and it is not explained further. I understand path and data but the combination is not clear to me. Because of this, this text reads strange: > RPL uses a hop-by-hop IPv6 header to detect possible loops within a > DODAG. Each data packet includes the Rank of the transmitter. What is a 'data packet'? Do you mean I have to modify every application to include that IPv6 header to insert new options? E.g. if I run http and TCP - do I have to modify the TCP stack to include this Rank on each data packet? (Is it "Each" or "Some"?) Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:53:33 2010 Return-Path: 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 EF5923A6861 for ; Sat, 24 Jul 2010 15:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=-0.558, 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 KF52wgP4ePu2 for ; Sat, 24 Jul 2010 15:53:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id F169B3A67C2 for ; Sat, 24 Jul 2010 15:53:30 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id B05A6940014 for ; Sun, 25 Jul 2010 00:53:45 +0200 (CEST) Message-ID: <4C4B6EF6.602@gmail.com> Date: Sun, 25 Jul 2010 00:53:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: apps modified? longer-match term? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:53:33 -0000 > o Nodes provision routing table entries, for the destinations > specified by the DIO, via their DODAG parents in the DODAG version. > Nodes MUST provision a DODAG parent as a default route for the > associated instance. It is up to the end-to-end application to > select the RPL instance to be associated to its traffic (should > there be more than one instance) 1 - so end-to-end applications must be modified ro tun in an RPL network? 2 - so if there is only one instance then the applications must not be modified? > and thus the default route upwards So the default route upwards is associated to a traffic. > when no longer-match exists. No better route exists, maybe? I don't understand "no longer-match exists": is it "shorter match exists"? is it "longer-match does not exist"? I do understand longest prefix match algorightms. But many people understand different things by this "longest prefix match" term, and it deservers clarification, it precludes understanding the negative "no longer-match exists". If needed, I can discuss this term further, I am all ears. In all cases, that last phrase is way too long. Alex From alexandru.petrescu@gmail.com Sat Jul 24 15:57:25 2010 Return-Path: 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 4AE9F3A6858 for ; Sat, 24 Jul 2010 15:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 JLEEtiPbRWIT for ; Sat, 24 Jul 2010 15:57:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7622E3A67C2 for ; Sat, 24 Jul 2010 15:57:22 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 408E9940031 for ; Sun, 25 Jul 2010 00:57:38 +0200 (CEST) Message-ID: <4C4B6FDF.8000008@gmail.com> Date: Sun, 25 Jul 2010 00:57:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: Candidate list or candidate neighbor set? 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: , X-List-Received-Date: Sat, 24 Jul 2010 22:57:25 -0000 "Candidate list" appears only once whereas "candidate neighbor set" appears multiple times, they seem to mean the same thing - is this a nit? Should "candidate list" be "candidate neighbor set" actually? > If a link or a node does not satisfy a required constraint, it is > 'pruned' from the candidate list, thus leading to a constrained > shortest path. [...] > First, the candidate neighbor set is a subset of the nodes that can > be reached via link- local multicast. Alex From alexandru.petrescu@gmail.com Sat Jul 24 16:12:16 2010 Return-Path: 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 E19FA3A67C2 for ; Sat, 24 Jul 2010 16:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=-0.523, 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 dD-sUoDFMrfE for ; Sat, 24 Jul 2010 16:12:14 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6DE3A67B8 for ; Sat, 24 Jul 2010 16:12:12 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 42A6E94006D for ; Sun, 25 Jul 2010 01:12:28 +0200 (CEST) Message-ID: <4C4B7359.6010109@gmail.com> Date: Sun, 25 Jul 2010 01:12:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sat, 24 Jul 2010 23:12:16 -0000 > Once a node has joined a DODAG version, RPL disallows certain > behaviors, including greediness, in order to prevent resulting > instabilities in the DODAG version. How? I searched for greed further down the text and it does not appear. This phrase sounds as if there is a bit set on/off called 'greed', or similar. I may be wrong. > It is for this reason that RPL limits the cases where a node may > process DIO messages from deeper nodes to some forms of local > repair. Which forms? 'local repair' procedure is mentioned several times in the draft: > On receiving such a packet, a node institutes a local repair > operation. [...] > Strict use of the DODAG Version Number can eliminate this type of > loop, but this type of loop may possibly be encountered when using > some local repair mechanisms. > [...] > MaxRankIncrease: 16-bit unsigned integer used to configure > DAGMaxRankIncrease, the allowable increase in rank in support of > local repair. [...] > o Trigger a local repair [...] > o Number of times a local repair procedure was triggered These are all the occurences of "local repair". It reads as an operation, mechanism, procedure. It is some form, some. But what is a local repair? Probably it is another term explained elsewhere that I can't find while searching in this draft, sorry if so. Alex From alexandru.petrescu@gmail.com Sat Jul 24 16:26:45 2010 Return-Path: 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 8A89B3A67C2 for ; Sat, 24 Jul 2010 16:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-0.507, 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 5XMShTdRUz39 for ; Sat, 24 Jul 2010 16:26:44 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DAC043A681C for ; Sat, 24 Jul 2010 16:26:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9B442940053 for ; Sun, 25 Jul 2010 01:26:57 +0200 (CEST) Message-ID: <4C4B76BE.9080602@gmail.com> Date: Sun, 25 Jul 2010 01:26:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: Rank a value or a function ('monotonic')? Options 'restricted to'? 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: , X-List-Received-Date: Sat, 24 Jul 2010 23:26:45 -0000 > The rank of a node is a scalar representation of the location of that > node within a DODAG version. Ok a scalar, not a vectorial. > The rank is used to avoid and detect > loops, and as such must demonstrate certain properties. The exact > calculation of the rank is left to the Objective Function, and may > depend on parents, link metrics, and the node configuration and > policies. > > The rank is not a cost metric, although its value can be derived from > and influenced by metrics. The rank has properties of its own that > are not necessarily those of all metrics: > > Type: The rank is an abstract numeric value. Ok, a numeric value, not alphabetical. > Function: The rank is the expression of a relative position within a > DODAG version with regard to neighbors and is not necessarily > a good indication or a proper expression of a distance or a > cost to the root. > > Stability: The stability of the rank determines the stability of the > routing topology. Some dampening or filtering might be > applied to keep the topology stable, and thus the rank does > not necessarily change as fast as some physical metrics > would. A new DODAG version would be a good opportunity to > reconcile the discrepancies that might form over time between > metrics and ranks within a DODAG version. > > Properties: The rank is strictly monotonic, But we said rank were a 'scalar', 'numeric' (like '1' or '0.5'). These can't be monotonic, functions could. Is the rank a function? Or is it 'the range of values of a rank could only be output by a monotonic function'? (or similar). > and can be used to > validate a progression from or towards the root. A metric, > like bandwidth or jitter, does not necessarily exhibit this > property. I think these can't be 'monotonic' because they aren't functions either. > Abstract: The rank does not have a physical unit, but rather a range > of increment per hop, where the assignment of each increment > is to be determined by the Objective Function. Ok, I get Abstract. Could the rank also be 'decrement' per hop? Or is it restricted to being always incremented? > The rank value feeds into DODAG parent selection, according to the > RPL loop-avoidance strategy. Once a parent has been added, and a > rank value for the node within the DODAG has been advertised, the ^^^ you mean 'this' node? (not 'the' node)? > nodes further options with regard to DODAG parent selection and ^^^^^ node's? nodes'? > movement within the DODAG are restricted in favor of loop avoidance. ^^^^^^^^^^^^^^^^^^^^^^ restricted to? refused in favor of? limited to? 'reduced, favoring loop avoidance' would mean it still has some options other than loop avoidance. Alex From alexandru.petrescu@gmail.com Sat Jul 24 16:33:18 2010 Return-Path: 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 311663A67D4 for ; Sat, 24 Jul 2010 16:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.492, 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 8GdvQGAuuH0Y for ; Sat, 24 Jul 2010 16:33:17 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 0302B3A67C2 for ; Sat, 24 Jul 2010 16:33:15 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C84C9940067 for ; Sun, 25 Jul 2010 01:33:30 +0200 (CEST) Message-ID: <4C4B7847.9050605@gmail.com> Date: Sun, 25 Jul 2010 01:33:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: Rank a fixed point number or variable point (floating?)? 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: , X-List-Received-Date: Sat, 24 Jul 2010 23:33:18 -0000 > Rank may be thought of as a fixed point number, where the position > of the radix point between the integer part and the fractional part > is determined by MinHopRankIncrease. IT is strange to read "a fixed point number, where the position of the radix point is determined by MinHopRankIncrease" this latter reading as a variable... is that point fixed? (it may be only me mathematically absent sometimes) Alex From alexandru.petrescu@gmail.com Sat Jul 24 16:54:12 2010 Return-Path: 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 E82113A67F3 for ; Sat, 24 Jul 2010 16:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=-0.478, 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 MTPyKe3DeKu2 for ; Sat, 24 Jul 2010 16:54:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E7FC53A67C2 for ; Sat, 24 Jul 2010 16:54:10 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id B13B5940058 for ; Sun, 25 Jul 2010 01:54:25 +0200 (CEST) Message-ID: <4C4B7D2E.6030300@gmail.com> Date: Sun, 25 Jul 2010 01:54:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: C '/ ' and floor; 8bit and 256 value; rank computation example? 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: , X-List-Received-Date: Sat, 24 Jul 2010 23:54:13 -0000 > The integer portion of the Rank is computed by the DAGRank() macro > as follows, where floor(x) is the function that evaluates to the > greatest integer less than or equal to x: > > > DAGRank(rank) = floor(rank/MinHopRankIncrease) > > > MinHopRankIncrease is provisioned at the DODAG Root and propagated in > the DIO message. What is '/' in rank/MinHopRankIncrease - is it integer division? Real (fixed or float)? Were '/' the one in C then I suppose we wouldn't need floor(?) If an example were written in the text then I'd be interested to read, to clarify, sorry if I misunderstand. STill about this, earlier it says: > DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of > MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value of > 256. This configuration results in an 8-bit wide integer part of > Rank. So the Rank can't have an integer part '0'? (besides I don't understand why we need only 8bits to represent a minimum value 256 when we don't know the max value of this integer part - do we?) (also: if we needed only the values power of 2 between 1 and 256 then 4bits would be sufficient, not 8) (this is why I don't understand the logic here... examples helpful). Alex From alexandru.petrescu@gmail.com Sat Jul 24 17:04:06 2010 Return-Path: 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 0CB403A67AC for ; Sat, 24 Jul 2010 17:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.465, 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 rh+SZYRVzzdF for ; Sat, 24 Jul 2010 17:04:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D0E403A6818 for ; Sat, 24 Jul 2010 17:04:01 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 88406940041 for ; Sun, 25 Jul 2010 02:04:16 +0200 (CEST) Message-ID: <4C4B7F7D.60503@gmail.com> Date: Sun, 25 Jul 2010 02:04:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: message diagrams, addresses missing 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: , X-List-Received-Date: Sun, 25 Jul 2010 00:04:06 -0000 > The aim of this section is to describe RPL in the spirit of > [RFC4101]. I do like that RFC4101 "Writing Protocol Models" and I like it is mentioned here. However, I feel that its spirit is a bit different. It gives 4 example protocol descriptions: each contains a message exchange diagram like this: > Client Server > ------ ------ > DCCP-Request -> > [Ports, Service, > Features] > <- DCCP-Response > [Features, > Cookie] > DCCP-Ack -> > [Features, > Cookie] It's but an example but the arrows show the messages being exchanged in certain direction, they have names (DCCP-Request). This is very useful for understanding the protocol; it's also useful for the designer! I miss such diagram from RPL, I would like to see. I could even try to sketch some if you accepted. Also, most examples have addresses painted on them - I miss this too in RPL - real addresses (be them the 2001:db8 documentation prefix). Alex From alexandru.petrescu@gmail.com Sat Jul 24 17:10:44 2010 Return-Path: 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 0E2F43A6818 for ; Sat, 24 Jul 2010 17:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[AWL=-0.452, 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 clDA4nfQucVg for ; Sat, 24 Jul 2010 17:10:43 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id A148F3A680C for ; Sat, 24 Jul 2010 17:10:41 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4CB57940014 for ; Sun, 25 Jul 2010 02:10:56 +0200 (CEST) Message-ID: <4C4B810D.7030101@gmail.com> Date: Sun, 25 Jul 2010 02:10:53 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: to be confirmed or to be defined or to be assigned... by IANA? 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: , X-List-Received-Date: Sun, 25 Jul 2010 00:10:45 -0000 > The RPL Control message is an ICMPv6 information message with a > requested Type of 155 (to be confirmed by IANA). I would be more attentive here. I see IANA as somebody one has to ask gently to obtain, not somebody to confirm a personal decision (be that a WG decision). 155 may be the value you see now available but how about next next Monday? Maybe someone at IETF has already got that 155 for their ICMP extension... and knowing 6lowpan, autoconf and IPv6 wg are all active in this area... I wouldn't be so sure. Thus I'd just say Type TBA by IANA In this way when IANA needs to assign it scans the document for the 'IANA' document, if they have time enough. I think they'd rather prefer all concentrated in the IANA section, but that changes with time. I think it's good to _not_ say 155, but TBA, and have all these TBAs in one place. I think there are more particular IANA preferences... or you may already know them all and have written "to be confirmed by IANA" knowing already their preferences - sorry if so. Alex From alexandru.petrescu@gmail.com Sat Jul 24 17:22:56 2010 Return-Path: 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 5EFC43A67AC for ; Sat, 24 Jul 2010 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_20=-0.74, 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 BCvk7FQ0syqC for ; Sat, 24 Jul 2010 17:22:55 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 132603A680C for ; Sat, 24 Jul 2010 17:22:52 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DF3D4940002 for ; Sun, 25 Jul 2010 02:23:07 +0200 (CEST) Message-ID: <4C4B83E9.8050607@gmail.com> Date: Sun, 25 Jul 2010 02:23:05 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Questions about RPL Security 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: , X-List-Received-Date: Sun, 25 Jul 2010 00:22:56 -0000 Questions about Message Authentication Code > The message authentication code is calculated over the entire IPv6 > packet. Before or after the application has modified the packet to include Rank? ("RPL uses a hop-by-hop IPv6 header to detect possible loops within a DODAG. Each data packet includes the Rank of the transmitter.") > The IPv6 and ICMPv6 headers are never encrypted. Which "IPv6 header"? I suppose you mean the "base header" - if so then say so. HbH is an IPv6 header too. ICMPv6 headers _are_ encrypted if preceded by ESP transport mode, or tunnel mode. Or are you going to forbid the use of ESP on RPL? > The body of the RPL ICMPv6 message MAY be encrypted, > starting from the first byte after the security section Ah? So RPL Security does not cover (confidentiality) the ICMP Type and Code fields? I agree - let ESP do it. Alex From alexandru.petrescu@gmail.com Sat Jul 24 17:30:59 2010 Return-Path: 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 42E0C3A67C2 for ; Sat, 24 Jul 2010 17:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_20=-0.74, 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 g4wPJhYlbSlT for ; Sat, 24 Jul 2010 17:30:57 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 922113A67AC for ; Sat, 24 Jul 2010 17:30:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2A277940051 for ; Sun, 25 Jul 2010 02:31:10 +0200 (CEST) Message-ID: <4C4B85CC.6080706@gmail.com> Date: Sun, 25 Jul 2010 02:31:08 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] How is the Message Authentication Code field computed? 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: , X-List-Received-Date: Sun, 25 Jul 2010 00:30:59 -0000 > 9.6. Coverage of Integrity and Confidentiality > > > For a RPL ICMPv6 message, the entire packet is within the scope of > RPL security. Well yes and no, because draft says "The body of the RPL ICMPv6 message MAY be encrypted, starting from the first byte after the security section" - that is not the entire packet. > The message authentication code is calculated over the entire IPv6 > packet. I need to understand this in more detail, and I don't find in draft (or I don't understand): How is the MAC computed? Which fields are covered? Which are mutable? What's the initialization? How is the ICMP Checksum field covered by the MAC? First compute the Checksum or first the MAC? Please give an example. (I could give similar with AH HMAC-MD5 and SHA1) (I may not be aware of a ton of security RFCs and terminology - sorry Michael about HMAC-MD5 vs MD5). Alex From alexandru.petrescu@gmail.com Sat Jul 24 17:31:29 2010 Return-Path: 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 574D13A67C2 for ; Sat, 24 Jul 2010 17:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.086 X-Spam-Level: X-Spam-Status: No, score=-0.086 tagged_above=-999 required=5 tests=[AWL=-0.437, 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 95G4LrxcVux3 for ; Sat, 24 Jul 2010 17:31:28 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 8B5243A67AC for ; Sat, 24 Jul 2010 17:31:26 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6848194004B for ; Sun, 25 Jul 2010 02:31:42 +0200 (CEST) Message-ID: <4C4B85EB.2080007@gmail.com> Date: Sun, 25 Jul 2010 02:31:39 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Sorry if too many messages 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: , X-List-Received-Date: Sun, 25 Jul 2010 00:31:29 -0000 Sorry if too many messages. Alex From alexandru.petrescu@gmail.com Sat Jul 24 18:01:31 2010 Return-Path: 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 3E70D3A683A for ; Sat, 24 Jul 2010 18:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=-0.426, 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 MSJaDebQsV7F for ; Sat, 24 Jul 2010 18:01:30 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 2C38E3A6831 for ; Sat, 24 Jul 2010 18:01:28 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 08795940048 for ; Sun, 25 Jul 2010 03:01:43 +0200 (CEST) Message-ID: <4C4B8CF5.3000401@gmail.com> Date: Sun, 25 Jul 2010 03:01:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100724-1, 24/07/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Nit: the term Mode of Operation 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: , X-List-Received-Date: Sun, 25 Jul 2010 01:01:31 -0000 Nit: the term Mode of Operation The term "mode of operation" is used several times throughout, with various semantics (sometimes unrelated) ranging from generic "RPL mode of operation" to very specific "MoP" field with 4 reserved values, storing mode of operation, inverse cryptographic mode of operation, DIS mode of operation, [fault mgmt] correct mode of operation, DODAG mode of operation, seq counters mode of operation transitioning linear to circular region, more. One could not say, for example, that the MoP field values cover the seq counters mode of operation, I believe(?) They only cover the storing modes. Thus, one would not expect there to be a _single_ mode of operation. Yet the draft states upfront: > This document describes the mode of operation of RPL. Maybe the plural 'modes' of operation of RPL would be better adapted? That phrase would be thus less confusing with respect to the specific uses appearing later. Depending on this modification, I could try to clarify further the different usages of this term. Alex From L.Wood@surrey.ac.uk Sat Jul 24 23:51:25 2010 Return-Path: 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 A9E7B3A6849 for ; Sat, 24 Jul 2010 23:51:25 -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=[AWL=0.000, 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 pEIB4XajOAsv for ; Sat, 24 Jul 2010 23:51:24 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 418233A6833 for ; Sat, 24 Jul 2010 23:51:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-10.tower-82.messagelabs.com!1280040703!15416193!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 12814 invoked from network); 25 Jul 2010 06:51:43 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-10.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2010 06:51:43 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 25 Jul 2010 07:51:42 +0100 From: To: Date: Sun, 25 Jul 2010 07:51:41 +0100 Thread-Topic: [Roll] What is "meta-data"? Thread-Index: Acsrxdb8tFNVDuCISzGxPwBfC7YcJw== Message-ID: References: <4C4B65F6.2060705@gmail.com> In-Reply-To: <4C4B65F6.2060705@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 06:51:25 -0000 On 24 Jul 2010, at 23:15, Alexandru Petrescu wrote: > I have difficulty understanding the term "meta-data": http://en.wikipedia.org/wiki/Metadata >=20 >> Each RPL packet has meta-data that associates it with a particular >> RPLInstanceID and therefore RPL Instance.(Section 4). > [...] >> For example, a node may continue to send data packets whose meta-data >> include a Rank that is not INFINITE_RANK yet still advertise >> INFINITE_RANK in its DIOs. >=20 > These are the only two occurences of the term "meta" and it is new to > me. What is the structure of the meta data? Is it a conceptual data > structure? >=20 > (I agree, it may be only me, I had a same issue with "out-of-band" data > and it turned out everybody understood it except me). >=20 > Alex >=20 From L.Wood@surrey.ac.uk Sun Jul 25 00:09:19 2010 Return-Path: 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 6E4503A680B for ; Sun, 25 Jul 2010 00:09:19 -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=[AWL=0.000, 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 iJIcs7ty9JMy for ; Sun, 25 Jul 2010 00:09:18 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 106853A63CB for ; Sun, 25 Jul 2010 00:09:17 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1280041777!10715678!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 20516 invoked from network); 25 Jul 2010 07:09:37 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2010 07:09:37 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sun, 25 Jul 2010 08:09:37 +0100 From: To: Date: Sun, 25 Jul 2010 08:09:35 +0100 Thread-Topic: [Roll] What is "meta-data"? Thread-Index: AcsryFcDtX5JquscQfOx+7JWUee3/A== Message-ID: <3055B487-2D36-4829-8811-3434DC347267@surrey.ac.uk> References: <4C4B65F6.2060705@gmail.com> In-Reply-To: <4C4B65F6.2060705@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 07:09:19 -0000 http://en.wikipedia.org/wiki/Out-of-band On 24 Jul 2010, at 23:15, Alexandru Petrescu wrote: > (I agree, it may be only me, I had a same issue with "out-of-band" data > and it turned out everybody understood it except me). Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From trac@tools.ietf.org Sun Jul 25 00:55:40 2010 Return-Path: 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 980B43A6838 for ; Sun, 25 Jul 2010 00:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 DfTcv9towISX for ; Sun, 25 Jul 2010 00:55:37 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C93D63A67E5 for ; Sun, 25 Jul 2010 00:55:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Ocw3w-00047j-Ca; Sun, 25 Jul 2010 00:55:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sun, 25 Jul 2010 07:55:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/73#comment:1 Message-ID: <064.cd3e229810f4ee7fd9517e5d9d5fe5ad@tools.ietf.org> References: <055.04fd304a30dd5f51fce91e0bac6ddf94@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <055.04fd304a30dd5f51fce91e0bac6ddf94@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #73: determining downward routes at the root X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 07:55:40 -0000 #73: [Roll] determining downward routes at the root --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Text solving the issue (agreed by Mukul) to be incorporated in revision 11: A node that provisions a DAO route for a Target that has an associated Path Control field SHOULD use the content of that Path Control field in order to determine an order of preference among multiple alternative DAO routes for that Target. The Path Control field assignment is derived from preference (of the DAO parents), as determined on the basis of this node's best knowledge of the "end-to- end" aggregated metrics in the "downward" direction as per the objective function. In non storing mode the root can determine the downward route by aggregating the information from each received DAO, which includes the Path Control indications of preferred DAO parents. -- Ticket URL: roll From alexandru.petrescu@gmail.com Sun Jul 25 00:57:18 2010 Return-Path: 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 891653A659B for ; Sun, 25 Jul 2010 00:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=0.884, 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 7g0sKnnXUBiw for ; Sun, 25 Jul 2010 00:57:17 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 73E9B3A63CB for ; Sun, 25 Jul 2010 00:57:15 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 655699400FD; Sun, 25 Jul 2010 09:57:30 +0200 (CEST) Message-ID: <4C4BEE65.4020302@gmail.com> Date: Sun, 25 Jul 2010 09:57:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4C4B65F6.2060705@gmail.com> <3055B487-2D36-4829-8811-3434DC347267@surrey.ac.uk> In-Reply-To: <3055B487-2D36-4829-8811-3434DC347267@surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 07:57:18 -0000 Le 25/07/2010 09:09, L.Wood@surrey.ac.uk a écrit : > http://en.wikipedia.org/wiki/Out-of-band Please don't point me to wikipedia. I don't understand meta-data in the RPL document, not in wikipedia, (wikipedia is a good thing btw.) Alex > > On 24 Jul 2010, at 23:15, Alexandru Petrescu wrote: > >> (I agree, it may be only me, I had a same issue with "out-of-band" data >> and it turned out everybody understood it except me). > > Lloyd Wood > L.Wood@surrey.ac.uk > http://sat-net.com/L.Wood > > > > From trac@tools.ietf.org Sun Jul 25 01:13:14 2010 Return-Path: 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 ED8A33A67E5 for ; Sun, 25 Jul 2010 01:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.424 X-Spam-Level: X-Spam-Status: No, score=-101.424 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, MANGLED_PAIN=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 GU9dw-xeJFWx for ; Sun, 25 Jul 2010 01:13:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6C3153A659B for ; Sun, 25 Jul 2010 01:13:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OcwKy-0000Ro-Nd; Sun, 25 Jul 2010 01:13:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Sun, 25 Jul 2010 08:13:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/60#comment:1 Message-ID: <064.cdb9b9300153aa3f335a3ac6ae5785c3@tools.ietf.org> References: <055.52290677ea9b9f72bf1ce609efdca1de@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <055.52290677ea9b9f72bf1ce609efdca1de@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #60: More text to be added to no-path DAO and fan out X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 08:13:15 -0000 #60: More text to be added to no-path DAO and fan out -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Text solving the issue to be incorporated in revision -11: RPL-11 will be updated as follows: Path Control: 8-bit bitfield. The Path Control field limits the number of DAO-Parents to which a DAO message advertising connectivity to a specific destination may be sent, as well as providing some indication of relative preference. The limit provides some bound on overall DAO message fan-out in the LLN. The assignment and ordering of the bits in the path control also serves to communicate preference. Not all of these bits may be enabled as according the the PCS in the DODAG Configuration. The Path Control field is divided into four subfields which contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in Figure 27. The subfields are ordered by preference, with PC1 being the most preferred and PC4 being the least preferred. Within a subfield there is no order of preference. By grouping the parents (as in ECMP) and ordering them, the parents may be associated with specific bits in the Path Control field in a way that communicates preference. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PC1|PC2|PC3|PC4| +-+-+-+-+-+-+-+-+ Figure 27: Path Control Preference Sub-field Encoding ----- Generation of DAO Messages A node might send DAO messages when it receives DAO messages, as a result of changes in its DAO parent set, or in response to another event such as the expiry of a related prefix lifetime. In the case of receiving DAOs, it matters whether the DAO message is "new," or contains new information. In non-storing mode, every DAO message a node receives is "new." In storing mode, a DAO message is "new" if it satisfies any of these criteria for a contained Target: 1. it has a newer Path Sequence number, 2. it has additional Path Control bits, or 3. is a No-Path DAO message that removes the last downward route to a prefix. A node that receives a DAO message from its sub-DODAG MAY suppress scheduling a DAO message transmission if that DAO message is not new. ----- 9.X Path Control A DAO message from a node contains one or more Target Options. Each Target Option specifies either the node's prefix, a prefix of addresses reachable outside the LLN, or a destination in the node's sub-DODAG. The Path Control field of the Transit Information option allows nodes to request or allow for multiple downward routes. A node constructs the Path Control field of a Transit Information option as follows: 1. The bit width of the path control field MUST be equal to the value (PCS + 1), where PCS is specified in the control field of the DODAG Configuration Option. Bits greater than or equal to the value (PCS + 1) MUST be cleared on transmission and MUST be ignored on reception. Bits below that value are considered "active" bits. 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (See Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the patch control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. 3. For a RPL Target option describing a node's own address or a prefix outside the LLN, at least one active bit of the Path Control field MUST be set. More active bits of the Path Control field MAY be set. 4. If a node receives multiple DAOs with the same RPL Target option, it MUST bitwise-OR the Path Control fields it receives. This aggregated bitwise-OR represents the number of downward routes the prefix requests. 5. When a node sends a DAO message to one of its DAO parents, it MUST select one or more of the bits that are set active in the subfield that is mapped to the group containing that DAO parent from the aggregated Path Control field. A given bit can only be presented as active to one parent. The DAO message it transmits to its parent MUST have these active bits set and all other active bits cleared. 6. For the RPL Target option and DAOSequence number, the DAOs a node sends to different DAO parents MUST have disjoint sets of active Path Control bits. A node MUST NOT set the same active bit on DAOs to two different DAO parents. 7. Path control bits SHOULD be allocated according to the preference mapping of DAO parents onto Path Control subfields, such that the active Path Control bits, or groupings of bits, that belong to a particular Path Control subfield are allocated to DAO parents within the group that was mapped to that subfield. 8. In a non-storing mode of operation, a node MAY pass DAOs through without performing any further processing on the Path Control field. 9. A node MUST NOT unicast a DAO message that has no active bits in the Path Control field set. It is possible that, for a given Target option, that a node does not have enough aggregate Path Control bits to send a DAO message containing that Target to each of its DAO Parents, in which case those least preferred DAO Parents may not get a DAO message for that Target. The Path Control field allows a node to bound how many downward routes will be generated to it. It sets a number of bits in the Path Control field equal to the maximum number of downward routes it prefers. Each bit is sent to at most one DAO parent; clusters of bits can be sent to a single DAO parent for it to divide among its own DAO parents. A node that provisions a DAO route for a Target that has an associate Path Control field SHOULD use content of that Path Control field in order to determine an order of preference among multiple alternative DAO routes for that Target. The Path Control field assignment is derived from preference (of the DAO parents), as determined on the basis of this node's best knowledge of the "end-to-end" aggregated metrics in the "downward" direction as per the objective function. In non-storing mode the root can determine the downward route by recursively selecting the best preference 1 hop-route. 9.X.1. Path Control Example Suppose that there is an LLN operating in storing mode that contains a Node N with four parents, P1, P2, P3, and P4. Let N have three children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such that there will be 8 active bits in the Path Control field: 11111111b. Consider the following example: The Path Control field is split into 4 subfields, PC1 (11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b), such that those 4 subfields represent 4 different levels of preference as per Figure 27. The implementation at Node N, in this example, groups {P1, P2} to be of equal preference to each other, and the most preferred group overall. {P3} is less preferred to {P1, P2}, and more preferred to {P4}. Let Node N then perform its path control mapping such that: {P1, P2} -> PC1 (11000000b) in the Path Control field {P3} -> PC2 (00110000b) in the Path Control field {P4} -> PC3 (00001100b) in the Path Control field {P4} -> PC4 (00000011b) in the Path Control field Note that the implementation repeated {P4} in order to get complete coverage of the Path Control field. 1. Let C1 send a DAO containing a Target T with a Path Control 10000000b. Node N stores an entry associating 10000000b with the Path Control field for C1 and Target T. 2. Let C2 send a DAO containing a Target T with a Path Control 00010000b. Node N stores an entry associating 00010000b with the Path Control field for C1 and Target T. 3. Let C3 send a DAO containing a Target T with a Path Control 00001100b. Node N stores an entry associating 00001100b with the Path Control field for C1 and Target T. 4. At some later time, Node N generates a DAO for Target T. Node N will construct an aggregate Path Control field by ORing together the contribution from each of its children that have given a DAO for Target T. The aggregate Path Control field thus has the active bits set as: 10011100b. 5. Node N then distributes the aggregate Path Control bits among its parents P1, P2, P3, and P4 in order to prepare the DAO messages. 6. P1 and P2 are eligible to receive active bits from the most preferred subfield (11000000b). Those bits are 10000000b in the aggregate Path Control field. Node N must the bit to one of the two parents only. In this case, Node P1 is allocated the bit, and gets the Path Control field 10000000b for its DAO. There are no bits left to allocate to Node P2, thus Node P2 would have a Path Control field of 00000000b and a DAO cannot be generated to Node P2 since there are no active bits. 7. The second-most preferred subfield (00110000b) has the active bits 00010000b. Node N has mapped P3 to this subfield. Node N may allocates the active bit to P3, constructing a DAO for P3 containing Target T with a Path Control of 00010000b. 8. The third-most preferred subfield (00001100b) has the active bits 00001100b. Node N has mapped P4 to this subfield. Node N may allocate both bits to P4, constructing a DAO for P4 containing Target T with a Path Control of 00001100b. 9. The least preferred subfield (00000011b) has no active bits. Had there been active bits, those bits would have been added to the Path Control field of the DAO constructed for P4. 10. The process of populating the DAO messages destined for P1, P2, P3, P4 with other targets (other than T) proceeds as according the aggregate path control fields collected for those targets. -- Ticket URL: roll From jpv@cisco.com Sun Jul 25 01:15:35 2010 Return-Path: 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 A15223A659B for ; Sun, 25 Jul 2010 01:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 58zScG1zij-W for ; Sun, 25 Jul 2010 01:15:34 -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 A8B233A67E5 for ; Sun, 25 Jul 2010 01:15:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABaQS0xAZnwN/2dsb2JhbACfXHGkJplLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138851249" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 08:15:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8FrRM019313; Sun, 25 Jul 2010 08:15:54 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:15:53 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:15:53 +0200 Message-Id: <48F84E47-1C47-4517-BEC9-3EA5FAE5D2DB@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6FDF.8000008@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:15:51 +0200 References: <4C4B6FDF.8000008@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:15:53.0686 (UTC) FILETIME=[99B0EF60:01CB2BD1] Cc: ROLL WG Subject: Re: [Roll] Nit: Candidate list or candidate neighbor set? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:15:35 -0000 On Jul 25, 2010, at 12:57 AM, Alexandru Petrescu wrote: > "Candidate list" appears only once whereas "candidate neighbor set" > appears multiple times, they seem to mean the same thing - is this a > nit? Should "candidate list" be "candidate neighbor set" actually? Yes. This will be fixed. Thanks. > >> If a link or a node does not satisfy a required constraint, it is >> 'pruned' from the candidate list, thus leading to a constrained >> shortest path. > > [...] > >> First, the candidate neighbor set is a subset of the nodes that can >> be reached via link- local multicast. > > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 01:15:49 2010 Return-Path: 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 B93253A67E5 for ; Sun, 25 Jul 2010 01:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CrEq4UXsAQTL for ; Sun, 25 Jul 2010 01:15:48 -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 A39A43A659B for ; Sun, 25 Jul 2010 01:15:48 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACaPS0xAZnwN/2dsb2JhbACfXHGkLZlKhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138806335" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:16:08 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8G7le019402; Sun, 25 Jul 2010 08:16:08 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:07 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:07 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6984.8020509@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:16:05 +0200 References: <4C4B6984.8020509@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:16:07.0593 (UTC) FILETIME=[A1FAF990:01CB2BD1] Cc: ROLL WG Subject: Re: [Roll] Up or up? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:15:49 -0000 On Jul 25, 2010, at 12:30 AM, Alexandru Petrescu wrote: >> Up: Up refers to the direction from leaf nodes towards DODAG >> roots, > [...] >> RPL provisions routes up towards DODAG roots, > > Usually when terms are defined in the Terminology we subsequently use > these terms capitalized to distinguish from the more mundane uses, > avoid > confusion. > > HEre, it is difficult to understand. > > Did the Author mean "up" the mundane? Or "Up" the term in Terminology > section. > > "Up" in the sense of Terminology would mean that RPL provided routes > to > DODAG roots, and my remark would be to provide them in the other way > around as well. > > "up" in the mundane sense would be ok, because it would mean "up they > go", somebody "up" there takes care of routes, etc. and I would not > have > any remark. > > Did the Author mean "up" or "Up"? Always the same meaning .... "up" or "Up" refers to the direction, as you said, toward the DODAG root. JP. > > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 01:15:59 2010 Return-Path: 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 3BDA73A680B for ; Sun, 25 Jul 2010 01:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2VFoZeZSBtXL for ; Sun, 25 Jul 2010 01:15:57 -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 9290D3A68A9 for ; Sun, 25 Jul 2010 01:15:53 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABaQS0xAZnwM/2dsb2JhbACfXHGkJplLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138851295" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 08:16:13 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8GCum002704; Sun, 25 Jul 2010 08:16:13 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:12 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:12 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B651A.4030402@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:16:11 +0200 References: <4C4B651A.4030402@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:16:12.0843 (UTC) FILETIME=[A51C0FB0:01CB2BD1] Cc: ROLL WG Subject: Re: [Roll] Mentioning link layer names in RPL doc 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:15:59 -0000 Hi Alex, On Jul 25, 2010, at 12:11 AM, Alexandru Petrescu wrote: > I think the draft should mention more about the link layers it uses. > > For example here: >> RPL is designed to be able to operate over a variety of different >> link layers, including but not limited to, low power wireless or PLC >> (Power Line Communication) technologies. > > It is the only name of a link layer appearing in the draft (if I > read it > correctly). I think more names should appear, to not give the > impression that PLC were paramount. > > And for "PLC" the name of that particular PLC technology (IEEE > something?) is worth to write. > The reasons for not mentioning explicitly link layers is precisely because we must stay agnostic to the link layer, operating at the layer 3. Step back 3-4 years ago: pretty much the link layer for low power operation was IEEE 802.15.4. While still an important one, many others ones are in the works or have been defined. What we need to do is to explain the design choices of RPL in light of their characteristics, which is what it is done in the document. Thanks. JP. > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 01:16:02 2010 Return-Path: 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 390573A68B2 for ; Sun, 25 Jul 2010 01:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EIoLgWwTzI9O for ; Sun, 25 Jul 2010 01:16:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DBBA13A6889 for ; Sun, 25 Jul 2010 01:15:59 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKPS0yrR7Ht/2dsb2JhbACfXHGkLZlKhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="346217209" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:16:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8GIXJ015130; Sun, 25 Jul 2010 08:16:19 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:18 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:18 +0200 Message-Id: <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B65F6.2060705@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:16:16 +0200 References: <4C4B65F6.2060705@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:16:18.0578 (UTC) FILETIME=[A8872720:01CB2BD1] Cc: ROLL WG Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:16:02 -0000 On Jul 25, 2010, at 12:15 AM, Alexandru Petrescu wrote: > I have difficulty understanding the term "meta-data": > >> Each RPL packet has meta-data that associates it with a particular >> RPLInstanceID and therefore RPL Instance.(Section 4). > [...] >> For example, a node may continue to send data packets whose meta-data >> include a Rank that is not INFINITE_RANK yet still advertise >> INFINITE_RANK in its DIOs. > > These are the only two occurences of the term "meta" and it is new to > me. What is the structure of the meta data? Is it a conceptual data > structure? > > (I agree, it may be only me, I had a same issue with "out-of-band" > data > and it turned out everybody understood it except me). This is to refer to information (here in this case the RPLInstanceID) used to route the packet on the appropriate topology. Here is a pretty good discussion about this term: http://en.wikipedia.org/wiki/Metadata JP. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 01:16:06 2010 Return-Path: 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 9BC023A68B7 for ; Sun, 25 Jul 2010 01:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uCsuyErUTeXm for ; Sun, 25 Jul 2010 01:16:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 110933A680B for ; Sun, 25 Jul 2010 01:16:04 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGKPS0yrR7Ht/2dsb2JhbACfXHGkLZlKhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="346217226" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:16:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8GNdP015154; Sun, 25 Jul 2010 08:16:23 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:23 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:16:22 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6343.5030505@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:16:21 +0200 References: <4C4B6343.5030505@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:16:22.0890 (UTC) FILETIME=[AB191CA0:01CB2BD1] Cc: ROLL WG Subject: Re: [Roll] Is the term 'destination prefix' appropriate in RPL and LLN 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:16:07 -0000 On Jul 25, 2010, at 12:03 AM, Alexandru Petrescu wrote: > For some reason I do not like the term 'destination prefix': > >> A RPL Instance may provide routes to certain destination prefixes > [...] >> The Route Information option is used to indicate that connectivity >> to the specified destination prefix is available from the DODAG >> root. > [...] >> A DAO Routing Table Entry conceptually contains the following >> elements (for storing nodes only): > [...] >> * DAO Lifetime >> >> * DAO Path Control >> >> o Destination Prefix (or Address or Mcast Group) > > I couldn't understand a Destination Prefix being a Mcast Group ("Mcast > Group" is probably a "multicast address" and that has no prefix length > or if it had it were 128 like an address). > > Additionally, it makes little sense to talk prefixes instead of > addresses when the deployment seems to be nodes without subnets > covering > them, i.e. without a prefix covering several nodes (like in an > Ethernet > subnet); and which are mobile, i.e. the addresses hardly aggregatable > into a prefix, usually done according to an initial plan. > > Not sure how to explain this but it is hard to me to grasp the term > "destination prefix" in the context of RPL and LLN. I may be wrong... Sorry but I cannot see why you don't like it. JP. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 01:20:33 2010 Return-Path: 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 DEACA3A6838 for ; Sun, 25 Jul 2010 01:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 BT0fkZC8l3G0 for ; Sun, 25 Jul 2010 01:20:30 -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 EF5D63A659B for ; Sun, 25 Jul 2010 01:20:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFOQS0xAZnwM/2dsb2JhbACfXHGkKZlLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138807207" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:20:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8Kn3c003481; Sun, 25 Jul 2010 08:20:49 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:20:48 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:20:48 +0200 Message-Id: <614DA9BF-7B73-4AD5-972A-42A83B1E0973@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B8CF5.3000401@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-115--1056346214 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:20:48 +0200 References: <4C4B8CF5.3000401@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:20:48.0803 (UTC) FILETIME=[49983730:01CB2BD2] Cc: ROLL WG Subject: Re: [Roll] Nit: the term Mode of Operation 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:20:33 -0000 --Apple-Mail-115--1056346214 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit "Mode of operation" is a very common terms used in RFC. On Jul 25, 2010, at 3:01 AM, Alexandru Petrescu wrote: > Nit: the term Mode of Operation > > The term "mode of operation" is used several times throughout, with > various semantics (sometimes unrelated) ranging from generic "RPL mode > of operation" to very specific "MoP" field with 4 reserved values, > storing mode of operation, inverse cryptographic mode of operation, > DIS > mode of operation, [fault mgmt] correct mode of operation, DODAG mode > of operation, seq counters mode of operation transitioning linear to > circular region, more. > > One could not say, for example, that the MoP field values cover the > seq > counters mode of operation, I believe(?) They only cover the > storing modes. > > Thus, one would not expect there to be a _single_ mode of operation. > Yet the draft states upfront: >> This document describes the mode of operation of RPL. > > Maybe the plural 'modes' of operation of RPL would be better adapted? The one place where we could slighly reword is in Section 1.1 replacing "This document describes the mode of operation of RPL." by "This document specifies RPL". Thanks. JP. > > That phrase would be thus less confusing with respect to the specific > uses appearing later. > > Depending on this modification, I could try to clarify further the > different usages of this term. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-115--1056346214 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Mode of operation" is a very = common terms used in RFC.

On Jul 25, 2010, at 3:01 AM, = Alexandru Petrescu wrote:

Nit: = the term Mode of Operation

The term "mode of operation" is used = several times throughout, with
various semantics (sometimes = unrelated) ranging from generic "RPL mode
of operation" to very = specific "MoP" field with 4 reserved values,
storing mode of = operation, inverse cryptographic mode of operation, DIS
mode of = operation,  [fault mgmt] correct mode of operation, DODAG = mode
of operation, seq counters mode of operation transitioning = linear to
circular region, more.

One could not say, for = example, that the MoP field values cover the seq
counters mode of = operation, I believe(?)  They only cover the storing = modes.

Thus, one would not expect there to be a _single_ mode of = operation.
Yet the draft states upfront:
This document describes the mode of operation of = RPL.

Maybe the plural 'modes' of operation of RPL = would be better adapted?

The = one place where we could slighly reword is in Section = 1.1
replacing "This document = describes the mode of operation of RPL." by
"This = document specifies = RPL".

Thanks.

JP.
<= br>

= --Apple-Mail-115--1056346214-- From alexandru.petrescu@gmail.com Sun Jul 25 01:22:06 2010 Return-Path: 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 C6B933A6783 for ; Sun, 25 Jul 2010 01:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=0.863, 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 aOiwvHkfp1fZ for ; Sun, 25 Jul 2010 01:22:04 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id EFE4B3A659B for ; Sun, 25 Jul 2010 01:22:02 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3B0A09400CC; Sun, 25 Jul 2010 10:22:16 +0200 (CEST) Message-ID: <4C4BF434.8000808@gmail.com> Date: Sun, 25 Jul 2010 10:22:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B651A.4030402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Mentioning link layer names in RPL doc 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:22:07 -0000 Le 25/07/2010 10:16, JP Vasseur a écrit : > Hi Alex, > > On Jul 25, 2010, at 12:11 AM, Alexandru Petrescu wrote: > >> I think the draft should mention more about the link layers it >> uses. >> >> For example here: >>> RPL is designed to be able to operate over a variety of >>> different link layers, including but not limited to, low power >>> wireless or PLC (Power Line Communication) technologies. >> >> It is the only name of a link layer appearing in the draft (if I >> read it correctly). I think more names should appear, to not give >> the impression that PLC were paramount. >> >> And for "PLC" the name of that particular PLC technology (IEEE >> something?) is worth to write. >> > > The reasons for not mentioning explicitly link layers is precisely > because we must stay agnostic to the link layer, operating at the > layer 3. Step back 3-4 years ago: pretty much the link layer for low > power operation was IEEE 802.15.4. While still an important one, > many others ones are in the works or have been defined. What we need > to do is to explain the design choices of RPL in light of their > characteristics, which is what it is done in the document. Ok... but mentioning "PLC" and not any other tech (like Ethernet) seems to intentionally give more weight to PLC than others. Is this the intention? PLC reads half-way from completely independent of link layer and some specific IEEE xxx protocol. Why not Ethernet too? (which reads similary). Alex > > Thanks. > > JP. > >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Sun Jul 25 01:23:49 2010 Return-Path: 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 9D4FA3A68C8 for ; Sun, 25 Jul 2010 01:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.844, 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 Zm+ck70JChOp for ; Sun, 25 Jul 2010 01:23:48 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 17E5E3A68C0 for ; Sun, 25 Jul 2010 01:23:46 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 58000940122; Sun, 25 Jul 2010 10:24:01 +0200 (CEST) Message-ID: <4C4BF49C.9080708@gmail.com> Date: Sun, 25 Jul 2010 10:23:56 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B65F6.2060705@gmail.com> <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> In-Reply-To: <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:23:49 -0000 Le 25/07/2010 10:16, JP Vasseur a écrit : > > On Jul 25, 2010, at 12:15 AM, Alexandru Petrescu wrote: > >> I have difficulty understanding the term "meta-data": >> >>> Each RPL packet has meta-data that associates it with a >>> particular RPLInstanceID and therefore RPL Instance.(Section 4). >> [...] >>> For example, a node may continue to send data packets whose >>> meta-data include a Rank that is not INFINITE_RANK yet still >>> advertise INFINITE_RANK in its DIOs. >> >> These are the only two occurences of the term "meta" and it is new >> to me. What is the structure of the meta data? Is it a conceptual >> data structure? >> >> (I agree, it may be only me, I had a same issue with "out-of-band" >> data and it turned out everybody understood it except me). > > This is to refer to information (here in this case the RPLInstanceID) Calling it RPLInstanceID would read better (Rather than meta-data). > used to route the packet on the appropriate topology. Here is a > pretty good discussion about this term: > http://en.wikipedia.org/wiki/Metadata No. For example you have "conceptual structures" which is ok - has fields, entries, leads to implementation. MEta-data is just that: meta talk. Thanks, Alex > > JP. > >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Sun Jul 25 01:27:28 2010 Return-Path: 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 89F4B3A68C0 for ; Sun, 25 Jul 2010 01:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.825, 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 OXrwzM7IUDkv for ; Sun, 25 Jul 2010 01:27:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 57AA33A659B for ; Sun, 25 Jul 2010 01:27:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8B15094011B; Sun, 25 Jul 2010 10:27:40 +0200 (CEST) Message-ID: <4C4BF577.1070606@gmail.com> Date: Sun, 25 Jul 2010 10:27:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B6343.5030505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Is the term 'destination prefix' appropriate in RPL and LLN 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:27:28 -0000 Le 25/07/2010 10:16, JP Vasseur a écrit : > > On Jul 25, 2010, at 12:03 AM, Alexandru Petrescu wrote: > >> For some reason I do not like the term 'destination prefix': >> >>> A RPL Instance may provide routes to certain destination >>> prefixes >> [...] >>> The Route Information option is used to indicate that >>> connectivity to the specified destination prefix is available >>> from the DODAG root. >> [...] >>> A DAO Routing Table Entry conceptually contains the following >>> elements (for storing nodes only): >> [...] >>> * DAO Lifetime >>> >>> * DAO Path Control >>> >>> o Destination Prefix (or Address or Mcast Group) >> >> I couldn't understand a Destination Prefix being a Mcast Group >> ("Mcast Group" is probably a "multicast address" and that has no >> prefix length or if it had it were 128 like an address). >> >> Additionally, it makes little sense to talk prefixes instead of >> addresses when the deployment seems to be nodes without subnets >> covering them, i.e. without a prefix covering several nodes (like >> in an Ethernet subnet); and which are mobile, i.e. the addresses >> hardly aggregatable into a prefix, usually done according to an >> initial plan. >> >> Not sure how to explain this but it is hard to me to grasp the >> term "destination prefix" in the context of RPL and LLN. I may be >> wrong... > > Sorry but I cannot see why you don't like it. If we had pictures with actual addresses put on devices then we'd understand better each other, I believe. I could draw pictures if you wish. A destination prefix (length shorter than 128) would mean a set of nodes in that prefix. To do that, one needs to be able to aggregate several addresses into a prefix. It doesn't seem the case here: we have no subnets, nodes move, one can't have several addresses aggregated into a prefix. Besides, what is "MCast Group" - do you mean a multicast address. If so then that "destination prefix (address or multicast address)" is wrongly written, I believe, the multicast addresses not having prefix lengths I believe. I could explain further, and read more. Alex > > JP. > >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From jpv@cisco.com Sun Jul 25 01:28:18 2010 Return-Path: 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 102223A68CC for ; Sun, 25 Jul 2010 01:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 prr4yk6lYo2A for ; Sun, 25 Jul 2010 01:28:17 -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 48DE83A68CD for ; Sun, 25 Jul 2010 01:28:16 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAKuSS0xAZnwM/2dsb2JhbACBRJ4YcaQtmUuFNgSELoQ2gjo X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138808858" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:28:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8SZ8U005450; Sun, 25 Jul 2010 08:28:35 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:28:35 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:28:35 +0200 Message-Id: <7DDB9D5E-84A3-4B1C-9EAD-49F97565BE91@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B7F7D.60503@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-116--1055879848 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:28:34 +0200 References: <4C4B7F7D.60503@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:28:35.0237 (UTC) FILETIME=[5F9C6550:01CB2BD3] Cc: ROLL WG Subject: Re: [Roll] Nit: message diagrams, addresses missing 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:28:18 -0000 --Apple-Mail-116--1055879848 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, On Jul 25, 2010, at 2:04 AM, Alexandru Petrescu wrote: >> The aim of this section is to describe RPL in the spirit of >> [RFC4101]. > > I do like that RFC4101 "Writing Protocol Models" and I like it is > mentioned here. However, I feel that its spirit is a bit > different. It gives 4 example protocol descriptions: each contains > a message exchange diagram like this: > >> Client Server >> ------ ------ >> DCCP-Request -> >> [Ports, Service, >> Features] >> <- DCCP-Response >> [Features, >> Cookie] >> DCCP-Ack -> >> [Features, >> Cookie] > > It's but an example but the arrows show the messages being exchanged > in certain direction, they have names (DCCP-Request). This is very > useful for understanding the protocol; it's also useful for the > designer! > > I miss such diagram from RPL, I would like to see. > > I could even try to sketch some if you accepted. > > Also, most examples have addresses painted on them - I miss this too > in RPL - real addresses (be them the 2001:db8 documentation prefix). > There are many ways to provide an overview of the protocol. You could either use arrows where there are lots of messages exchanges (3 way hand-check, ...). Here is another example from RFC5440: +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | | Open msg | |-------- | | \ Open msg | | \ ---------| | \/ | | /\ | | / -------->| | / | |<------ Keepalive| | --------| |Keepalive / | |-------- / | | \/ | | /\ | |<------ ---------->| | | But in the RPL case, these are pretty straightforward and we preferred to describe it with words and can you can see there is a lot of text there already. Thanks. JP. > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-116--1055879848 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi,

On Jul = 25, 2010, at 2:04 AM, Alexandru Petrescu wrote:

The aim of this section is = to describe RPL in the spirit of
[RFC4101].

I do like that RFC4101 = "Writing Protocol Models" and I like it is mentioned here. =  However, I feel that its spirit is a bit different.  It gives = 4 example protocol descriptions: each contains a message exchange = diagram like this:

Client =             &n= bsp;           &nbs= p;            = Server
  ------ =             &n= bsp;           &nbs= p;            = ------
=   DCCP-Request =            ->
  [Ports, = Service,
=   Features]
=             &n= bsp;           &nbs= p; <- =           DCCP-Response<= br>
=             &n= bsp;           &nbs= p;            =      [Features,
=             &n= bsp;           &nbs= p;            =         Cookie]
  DCCP-Ack =             &n= bsp;  ->
=   [Features,
=   Cookie]

It's but an example but the = arrows show the messages being exchanged in certain direction, they have = names (DCCP-Request).  This is very useful for understanding the = protocol; it's also useful for the designer!

I miss such diagram = from RPL, I would like to see.

I could even try to sketch some if = you accepted.

Also, most examples have addresses painted on them = - I miss this too in RPL - real addresses (be them the 2001:db8 = documentation = prefix).


There are many = ways to provide an overview of the protocol. You could either use arrows = where there are lots of messages exchanges (3 way hand-check, = ...).
Here is another example from RFC5440:
               +-+-+                 +-+-+
               |PCC|                 |PCE|
               +-+-+                 +-+-+
                 |                     |
                 | Open msg            |
                 |--------             |
                 |        \   Open msg |
                 |         \  ---------|
                 |          \/         |
                 |          /\         |
                 |         /  -------->|
                 |        /            |
                 |<------     Keepalive|
                 |             --------|
                 |Keepalive   /        |
                 |--------   /         |
                 |        \/           |
                 |        /\           |
                 |<------   ---------->|
                 |                     |

But in the RPL case, these are pretty = straightforward and we preferred to describe it with words and can you = can see there is a lot of text there = already.

Thanks.

JP.

Alex


_______________________________________= ________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-116--1055879848-- From alexandru.petrescu@gmail.com Sun Jul 25 01:28:18 2010 Return-Path: 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 B4E063A68CC for ; Sun, 25 Jul 2010 01:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.442 X-Spam-Level: X-Spam-Status: No, score=-1.442 tagged_above=-999 required=5 tests=[AWL=0.807, 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 FA54S49lF-4C for ; Sun, 25 Jul 2010 01:28:17 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C24753A68B2 for ; Sun, 25 Jul 2010 01:28:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1010594012F; Sun, 25 Jul 2010 10:28:27 +0200 (CEST) Message-ID: <4C4BF5A7.4040608@gmail.com> Date: Sun, 25 Jul 2010 10:28:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B8CF5.3000401@gmail.com> <614DA9BF-7B73-4AD5-972A-42A83B1E0973@cisco.com> In-Reply-To: <614DA9BF-7B73-4AD5-972A-42A83B1E0973@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: the term Mode of Operation 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:28:18 -0000 Le 25/07/2010 10:20, JP Vasseur a écrit : > "Mode of operation" is a very common terms used in RFC. NEw to me... > > On Jul 25, 2010, at 3:01 AM, Alexandru Petrescu wrote: > >> Nit: the term Mode of Operation >> >> The term "mode of operation" is used several times throughout, with >> various semantics (sometimes unrelated) ranging from generic "RPL mode >> of operation" to very specific "MoP" field with 4 reserved values, >> storing mode of operation, inverse cryptographic mode of operation, DIS >> mode of operation, [fault mgmt] correct mode of operation, DODAG mode >> of operation, seq counters mode of operation transitioning linear to >> circular region, more. >> >> One could not say, for example, that the MoP field values cover the seq >> counters mode of operation, I believe(?) They only cover the storing >> modes. >> >> Thus, one would not expect there to be a _single_ mode of operation. >> Yet the draft states upfront: >>> This document describes the mode of operation of RPL. >> >> Maybe the plural 'modes' of operation of RPL would be better adapted? > > The one place where we could slighly reword is in Section 1.1 > replacing "This document describes the mode of operation of RPL." by > "This document specifies RPL". Sounds good. Alex > > Thanks. > > JP. > >> >> That phrase would be thus less confusing with respect to the specific >> uses appearing later. >> >> Depending on this modification, I could try to clarify further the >> different usages of this term. >> >> Alex >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Sun Jul 25 01:33:40 2010 Return-Path: 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 A87D63A67E5 for ; Sun, 25 Jul 2010 01:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DGGHo9kjp8MH for ; Sun, 25 Jul 2010 01:33:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B358F3A68CE for ; Sun, 25 Jul 2010 01:33:23 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKyTS0yrR7Hu/2dsb2JhbACfXHGkLJlNhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="230416452" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 25 Jul 2010 08:33:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8Xe8x011238; Sun, 25 Jul 2010 08:33:41 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:33:40 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:33:39 +0200 Message-Id: <1206B2EC-18AE-4C95-80C3-CFB29DCA9030@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B810D.7030101@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:33:38 +0200 References: <4C4B810D.7030101@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:33:39.0493 (UTC) FILETIME=[14F62D50:01CB2BD4] Cc: ROLL WG Subject: Re: [Roll] Nit: to be confirmed or to be defined or to be assigned... by IANA? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:33:41 -0000 Hi Alex, You are correct that IANA is the only one having the authority to assign protocol number. Still it is a common practice to propose a value so that implementers can start implementing and interoperate. In the example of RPL, this allowed two interoperability tests in the past. This numbers are subject to change (this is why you have always the mention "to be confirmed by IANA"). JP. On Jul 25, 2010, at 2:10 AM, Alexandru Petrescu wrote: >> The RPL Control message is an ICMPv6 information message with a >> requested Type of 155 (to be confirmed by IANA). > > I would be more attentive here. I see IANA as somebody one has to ask > gently to obtain, not somebody to confirm a personal decision (be > that a > WG decision). > > 155 may be the value you see now available but how about next next > Monday? Maybe someone at IETF has already got that 155 for their ICMP > extension... and knowing 6lowpan, autoconf and IPv6 wg are all > active in > this area... I wouldn't be so sure. > > Thus I'd just say > > Type > TBA by IANA > > In this way when IANA needs to assign it scans the document for the > 'IANA' document, if they have time enough. I think they'd rather > prefer all concentrated in the IANA section, but that changes with > time. > > I think it's good to _not_ say 155, but TBA, and have all these TBAs > in > one place. > > I think there are more particular IANA preferences... or you may > already > know them all and have written "to be confirmed by IANA" knowing > already > their preferences - sorry if so. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sun Jul 25 01:37:07 2010 Return-Path: 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 569A43A6843 for ; Sun, 25 Jul 2010 01:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=0.790, 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 4P5SFEcOpTnk for ; Sun, 25 Jul 2010 01:37:06 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 1D40B3A67E5 for ; Sun, 25 Jul 2010 01:37:04 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 56F63940137; Sun, 25 Jul 2010 10:37:19 +0200 (CEST) Message-ID: <4C4BF7BA.8030404@gmail.com> Date: Sun, 25 Jul 2010 10:37:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B7F7D.60503@gmail.com> <7DDB9D5E-84A3-4B1C-9EAD-49F97565BE91@cisco.com> In-Reply-To: <7DDB9D5E-84A3-4B1C-9EAD-49F97565BE91@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: message diagrams, addresses missing 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:37:07 -0000 Le 25/07/2010 10:28, JP Vasseur a écrit : > Hi, > > On Jul 25, 2010, at 2:04 AM, Alexandru Petrescu wrote: > >>> The aim of this section is to describe RPL in the spirit of >>> [RFC4101]. >> >> I do like that RFC4101 "Writing Protocol Models" and I like it is >> mentioned here. However, I feel that its spirit is a bit different. It >> gives 4 example protocol descriptions: each contains a message >> exchange diagram like this: >> >>> Client Server >>> ------ ------ >>> DCCP-Request -> >>> [Ports, Service, >>> Features] >>> <- DCCP-Response >>> [Features, >>> Cookie] >>> DCCP-Ack -> >>> [Features, >>> Cookie] >> >> It's but an example but the arrows show the messages being exchanged >> in certain direction, they have names (DCCP-Request). This is very >> useful for understanding the protocol; it's also useful for the designer! >> >> I miss such diagram from RPL, I would like to see. >> >> I could even try to sketch some if you accepted. >> >> Also, most examples have addresses painted on them - I miss this too >> in RPL - real addresses (be them the 2001:db8 documentation prefix). >> > > There are many ways to provide an overview of the protocol. You could > either use arrows where there are lots of messages exchanges (3 way > hand-check, ...). > Here is another example from RFC5440: > > +-+-+ +-+-+ > |PCC| |PCE| > +-+-+ +-+-+ > | | > | Open msg | > |-------- | > | \ Open msg | > | \ ---------| > | \/ | > | /\ | > | / -------->| > | / | > |<------ Keepalive| > | --------| > |Keepalive / | > |-------- / | > | \/ | > | /\ | > |<------ ---------->| > | | That is good! IT shows a notion of time. > But in the RPL case, these are pretty straightforward and we preferred > to describe it with words and can you can see there is a lot of text > there already. I prefer to think a picture is worth thousand words... I think this is missing from many otherwise good drafts and RFCs which could have made them better. It's up to you. Alex > > Thanks. > > JP. > >> Alex >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sun Jul 25 01:40:21 2010 Return-Path: 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 0B1C33A68D4 for ; Sun, 25 Jul 2010 01:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6] 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 KTWbFrsLNvd8 for ; Sun, 25 Jul 2010 01:40:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE1A3A67E5 for ; Sun, 25 Jul 2010 01:40:16 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DF273940069; Sun, 25 Jul 2010 10:40:30 +0200 (CEST) Message-ID: <4C4BF87A.2010907@gmail.com> Date: Sun, 25 Jul 2010 10:40:26 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B810D.7030101@gmail.com> <1206B2EC-18AE-4C95-80C3-CFB29DCA9030@cisco.com> In-Reply-To: <1206B2EC-18AE-4C95-80C3-CFB29DCA9030@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: to be confirmed or to be defined or to be assigned... by IANA? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:40:21 -0000 Le 25/07/2010 10:33, JP Vasseur a écrit : > Hi Alex, > > You are correct that IANA is the only one having the authority to > assign protocol number. Still it is a common practice to propose a > value so that implementers can start implementing and interoperate. > In the example of RPL, this allowed two interoperability tests in the > past. This numbers are subject to change (this is why you have always > the mention "to be confirmed by IANA"). I disagree - it is not a good practice. IT makes change very difficult later: one has to search throughout the document for 155, for the old 155, for the new 155, etc. and often this search has to be performed by IANA which has not written the document i'ts more work for them This kind of glitches gets into documents very easily and stays in RFC... Alex > > JP. > > On Jul 25, 2010, at 2:10 AM, Alexandru Petrescu wrote: > >>> The RPL Control message is an ICMPv6 information message with a >>> requested Type of 155 (to be confirmed by IANA). >> >> I would be more attentive here. I see IANA as somebody one has to >> ask gently to obtain, not somebody to confirm a personal decision >> (be that a WG decision). >> >> 155 may be the value you see now available but how about next next >> Monday? Maybe someone at IETF has already got that 155 for their >> ICMP extension... and knowing 6lowpan, autoconf and IPv6 wg are all >> active in this area... I wouldn't be so sure. >> >> Thus I'd just say >> >> Type TBA by IANA >> >> In this way when IANA needs to assign it scans the document for >> the 'IANA' document, if they have time enough. I think they'd >> rather prefer all concentrated in the IANA section, but that >> changes with time. >> >> I think it's good to _not_ say 155, but TBA, and have all these >> TBAs in one place. >> >> I think there are more particular IANA preferences... or you may >> already know them all and have written "to be confirmed by IANA" >> knowing already their preferences - sorry if so. >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From jpv@cisco.com Sun Jul 25 01:44:00 2010 Return-Path: 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 8991D3A6897 for ; Sun, 25 Jul 2010 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gJz4RwSef5yD for ; Sun, 25 Jul 2010 01:43:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8FA813A67E5 for ; Sun, 25 Jul 2010 01:43:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALeVS0yrR7Hu/2dsb2JhbACBRJ4YcaQymUuFNgSIZII6 X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="162616334" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 25 Jul 2010 08:44:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8iI9Y014607; Sun, 25 Jul 2010 08:44:19 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:44:18 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:44:17 +0200 Message-Id: <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6C8D.50100@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-117--1054937159 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:44:17 +0200 References: <4C4B6C8D.50100@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:44:17.0849 (UTC) FILETIME=[91739290:01CB2BD5] Cc: ROLL WG Subject: Re: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:44:00 -0000 --Apple-Mail-117--1054937159 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 25, 2010, at 12:43 AM, Alexandru Petrescu wrote: > Nit: what is a datapath? The term appears in the title of a section > >> 3.3.7. Datapath Validation and Loop Detection > > and it is not explained further. > > I understand path and data but the combination is not clear to me. > > Because of this, this text reads strange: >> RPL uses a hop-by-hop IPv6 header to detect possible loops within a >> DODAG. Each data packet includes the Rank of the transmitter. > > What is a 'data packet'? An IPv6 packet carrying user data as opposed to a routing control message such as a DIS. > Do you mean I have to modify every application > to include that IPv6 header to insert new options? > Your application builds the IP packet and allows setting IPv6 header field (DS, ...), but also extended headers, ... In RPL, datapath validation and loop detection is performed by adding the RPL option defined in (draft-hui-6man-rpl-option-01) carried in the hop by hop header. This part will be more detailed in the next revision (see for example ticket 64) JP. > E.g. if I run http and TCP - do I have to modify the TCP stack to > include this Rank on each data packet? > > (Is it "Each" or "Some"?) > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-117--1054937159 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 25, 2010, = at 12:43 AM, Alexandru Petrescu wrote:

Nit: =  what is a datapath?  The term appears in the title of a = section

3.3.7. Datapath Validation and = Loop Detection

and it is not explained = further.

I understand path and data but the combination is not = clear to me.

Because of this, this text reads = strange:
RPL uses a hop-by-hop IPv6 header = to detect possible loops within a
DODAG.  Each data packet includes the Rank of the = transmitter.

What is a 'data packet'? =  

An IPv6 packet carrying = user data as opposed to a routing control message 
such = as a DIS.

Do you mean I have to = modify every application
to include that IPv6 header to insert new = options?


Your application = builds the IP packet and allows setting IPv6 header field (DS, = ...),
but also extended headers, = ... 

In RPL, datapath validation and loop = detection is performed by adding the RPL option
defined in = (
E.g. if I run http and TCP - do I have to modify the = TCP stack to
include this Rank on each data packet?

(Is it = "Each" or = "Some"?)

Alex

______________________________________________= _
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-117--1054937159-- From jpv@cisco.com Sun Jul 25 01:46:59 2010 Return-Path: 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 4C4BD3A68D8 for ; Sun, 25 Jul 2010 01:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] 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 QXHCOKPTKBU1 for ; Sun, 25 Jul 2010 01:46:58 -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 A6DBC3A68D0 for ; Sun, 25 Jul 2010 01:46:57 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOOWS0xAZnwN/2dsb2JhbACfXHGkJplLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138856545" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 08:47:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8l8k1026773; Sun, 25 Jul 2010 08:47:17 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:47:10 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:47:10 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B7D2E.6030300@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-118--1054764510 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:47:09 +0200 References: <4C4B7D2E.6030300@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:47:10.0375 (UTC) FILETIME=[F848F370:01CB2BD5] Cc: ROLL WG Subject: Re: [Roll] Nit: C '/ ' and floor; 8bit and 256 value; rank computation example? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:46:59 -0000 --Apple-Mail-118--1054764510 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 25, 2010, at 1:54 AM, Alexandru Petrescu wrote: >> The integer portion of the Rank is computed by the DAGRank() macro >> as follows, where floor(x) is the function that evaluates to the >> greatest integer less than or equal to x: >> >> >> DAGRank(rank) = floor(rank/MinHopRankIncrease) >> >> >> MinHopRankIncrease is provisioned at the DODAG Root and propagated in >> the DIO message. > > What is '/' in rank/MinHopRankIncrease - is it integer division? > Real (fixed or float)? > > Were '/' the one in C then I suppose we wouldn't need floor(?) > > If an example were written in the text then I'd be interested to > read, to clarify, sorry if I misunderstand. Yes indeed we will add an example in the next revision. Here it is (hope that clarifies): 3.6.1. Rank Comparison (DAGRank()) Rank may be thought of as a fixed point number, where the position of the radix point between the integer part and the fractional part is determined by MinHopRankIncrease. MinHopRankIncrease is the minimum increase in rank between a node and any of its DODAG parents. A DODAG Root provisions MinHopRankIncrease. MinHopRankIncrease creates a tradeoff between hop cost precision and the maximum number of hops a network can support. A very large MinHopRankIncrease, for example, allows precise characterization of a given hop's affect on Rank but cannot support many hops. When an objective function computes rank, the objective function operates on the entire (i.e. 16-bit) rank quantity. When rank is compared, e.g. for determination of parent relationships or loop detection, the integer portion of the rank is to be used. The integer portion of the Rank is computed by the DAGRank() macro as follows, where floor(x) is the function that evaluates to the greatest integer less than or equal to x: DAGRank(rank) = floor(rank/MinHopRankIncrease) For example, if a 16-bit rank quantity is decimal 27, and the MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 1. The integer part of the rank is 1 and the fractional part is 11/16. By convention in this document, using the macro DAGRank(node) may be interpreted as DAGRank(node.rank), where node.rank is the rank value as maintained by the node. A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B). A node A has a rank equal to the rank of a node B if DAGRank(A) is equal to DAGRank(B). A node A has a rank greater than the rank of a node B if DAGRank(A) is greater than DAGRank(B). > > STill about this, earlier it says: >> DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of >> MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value of >> 256. This configuration results in an 8-bit wide integer part of >> Rank. > > So the Rank can't have an integer part '0'? > > (besides I don't understand why we need only 8bits to represent a > minimum value 256 when we don't know the max value of this integer > part - do we?) > > (also: if we needed only the values power of 2 between 1 and 256 > then 4bits would be sufficient, not 8) > > (this is why I don't understand the logic here... examples helpful). > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-118--1054764510 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 25, 2010, = at 1:54 AM, Alexandru Petrescu wrote:

The integer portion of the = Rank is computed by the DAGRank() macro
as follows, where floor(x) is the function that evaluates = to the
greatest integer less = than or equal to x:


DAGRank(rank) =3D= floor(rank/MinHopRankIncrease)


MinHopRankIncrease is provisioned at the DODAG Root and = propagated in
the DIO = message.

What is '/' in rank/MinHopRankIncrease - is = it integer division?
Real (fixed or float)?

Were '/' the one = in C then I suppose we wouldn't need floor(?)

If an example were = written in the text then I'd be interested to read, to clarify, sorry if = I misunderstand.

Yes indeed we = will add an example in the next revision. Here it is (hope that = clarifies):

3.6.1.  Rank Comparison (DAGRank())

   Rank may be thought of as a fixed point number, where the position of
   the radix point between the integer part and the fractional part is
   determined by MinHopRankIncrease.  MinHopRankIncrease is the minimum
   increase in rank between a node and any of its DODAG parents.  A
   DODAG Root provisions MinHopRankIncrease.  MinHopRankIncrease creates
   a tradeoff between hop cost precision and the maximum number of hops
   a network can support.  A very large MinHopRankIncrease, for example,
   allows precise characterization of a given hop's affect on Rank but
   cannot support many hops.

   When an objective function computes rank, the objective function
   operates on the entire (i.e. 16-bit) rank quantity.  When rank is
   compared, e.g. for determination of parent relationships or loop
   detection, the integer portion of the rank is to be used.  The
   integer portion of the Rank is computed by the DAGRank() macro as
   follows, where floor(x) is the function that evaluates to the
   greatest integer less than or equal to x:


              DAGRank(rank) =3D floor(rank/MinHopRankIncrease)


   For example, if a 16-bit rank quantity is decimal 27, and the
   MinHopRankIncrease is decimal 16, then DAGRank(27) =3D floor(1.6875) =
=3D
   1.  The integer part of the rank is 1 and the fractional part is
   11/16.

   By convention in this document, using the macro DAGRank(node) may be
   interpreted as DAGRank(node.rank), where node.rank is the rank value
   as maintained by the node.

   A node A has a rank less than the rank of a node B if DAGRank(A) is
   less than DAGRank(B).

   A node A has a rank equal to the rank of a node B if DAGRank(A) is
   equal to DAGRank(B).

   A node A has a rank greater than the rank of a node B if DAGRank(A)
   is greater than DAGRank(B).


STill about this, earlier it says:
DEFAULT_MIN_HOP_RANK_INCREASE  This is the default = value of
MinHopRankIncrease. =  DEFAULT_MIN_HOP_RANK_INCREASE has a value = of
256.  This = configuration results in an 8-bit wide integer part = of
Rank.

So = the Rank can't have an integer part '0'?

(besides I don't = understand why we need only 8bits to represent a minimum value 256 when = we don't know the max value of this integer part - do we?)

(also: = if we needed only the values power of 2 between 1 and 256 then 4bits = would be sufficient, not 8)

(this is why I don't understand the = logic here... examples = helpful).

Alex
_______________________________________________Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-118--1054764510-- From L.Wood@surrey.ac.uk Sun Jul 25 01:47:39 2010 Return-Path: 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 990CE3A68D9 for ; Sun, 25 Jul 2010 01:47:39 -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=[AWL=0.000, 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 np6+qmwD7d61 for ; Sun, 25 Jul 2010 01:47:36 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id C97C33A67E5 for ; Sun, 25 Jul 2010 01:47:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-82.messagelabs.com!1280047674!8294685!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 909 invoked from network); 25 Jul 2010 08:47:55 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-5.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2010 08:47:55 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 25 Jul 2010 09:47:54 +0100 From: To: Date: Sun, 25 Jul 2010 09:47:53 +0100 Thread-Topic: [Roll] What is "meta-data"? Thread-Index: Acsr1hKoRNq0sClMRZKCOdKnCxk8Kw== Message-ID: <2499913B-4A57-4452-9736-A930B963B4AD@surrey.ac.uk> References: <4C4B65F6.2060705@gmail.com> <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> <4C4BF49C.9080708@gmail.com> In-Reply-To: <4C4BF49C.9080708@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:47:39 -0000 On 25 Jul 2010, at 09:23, Alexandru Petrescu wrote: >> used to route the packet on the appropriate topology. Here is a >> pretty good discussion about this term: >> http://en.wikipedia.org/wiki/Metadata >=20 > No. >=20 > For example you have "conceptual structures" which is ok - has fields,=20 > entries, leads to implementation. MEta-data is just that: meta talk. Metadata is generally structured and machine readable. The wikipedia page gives examples. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From jpv@cisco.com Sun Jul 25 01:53:36 2010 Return-Path: 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 C8DD23A67E5 for ; Sun, 25 Jul 2010 01:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.477 X-Spam-Level: X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 qdVNSilWAimD for ; Sun, 25 Jul 2010 01:53:36 -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 CF6813A67F1 for ; Sun, 25 Jul 2010 01:53:35 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIaYS0xAZnwM/2dsb2JhbACfXHGkIJlLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138812616" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 08:53:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8rtIv011339; Sun, 25 Jul 2010 08:53:55 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:53:55 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:53:54 +0200 Message-Id: <892F8DF5-DF4A-42CF-83FE-9C1D2C69ADFD@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6820.8000807@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-120--1054360626 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:53:53 +0200 References: <4C4B6820.8000807@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:53:54.0653 (UTC) FILETIME=[E940E0D0:01CB2BD6] Cc: ROLL WG Subject: Re: [Roll] Nit: how a DODAG version number increment leads to a new DODAG Version 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:53:36 -0000 --Apple-Mail-120--1054360626 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jul 25, 2010, at 12:24 AM, Alexandru Petrescu wrote: > Nit: > >> Figure 2 depicts how a DODAG version number increment leads to a new >> DODAG Version. > > How? By incrementing, no need to look at the figure, it's right there > in the text. This is to show that when the version is incremented by the root (also referred to as global repair, and this can be seen as a global reoptimization too), this may lead to a new DODAG shape. By the way we added that the DODAG shape may be unchanged too. New text: Figure 2 depicts how a DODAG version number increment leads to a new DODAG Version. Note that a new DODAG Version does not always imply a different DODAG topology. > > Worried of my misunderstanding I start thinking whether "version" is > the > same as "Version". I think worry is not motivated, but rather that > this > is a nit. version and Version: same thing. JP. > > Alex > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-120--1054360626 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 25, 2010, = at 12:24 AM, Alexandru Petrescu wrote:

Nit:

Figure 2 = depicts how a DODAG version number increment leads to a = new
DODAG = Version.

How?  By incrementing, no need to look = at the figure, it's right there
in the = text.

This is to show that = when the version is incremented by the root (also referred to = as
global repair, and this can be seen as a global = reoptimization too), this may lead to
a new DODAG shape. By = the way we added that the DODAG shape may be = unchanged
too.

New = text:

Figure 2 depicts how a DODAG
   version number increment leads to a new DODAG Version.  Note that a
   new DODAG Version does not always imply a different DODAG =
topology.


Worried= of my misunderstanding I start thinking whether "version" is = the
same as "Version".  I think worry is not motivated, but = rather that this
is a = nit.

version and Version: same = thing.

JP.


Alex

_______________________________________= ________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-120--1054360626-- From jpv@cisco.com Sun Jul 25 01:59:19 2010 Return-Path: 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 E4EE13A684C for ; Sun, 25 Jul 2010 01:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HSxRNfGQNMii for ; Sun, 25 Jul 2010 01:59:19 -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 DC2FB3A67F1 for ; Sun, 25 Jul 2010 01:59:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuZS0xAZnwM/2dsb2JhbACfXHGkIplLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138857946" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 08:59:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P8xbIf012464; Sun, 25 Jul 2010 08:59:38 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:59:38 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 10:59:37 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B66A9.4060409@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 10:59:37 +0200 References: <4C4B66A9.4060409@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 08:59:37.0808 (UTC) FILETIME=[B5CA2D00:01CB2BD7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17526.005 X-TM-AS-Result: No--6.561100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] What is "non-LLN backchannel" and "non-LLN backbone"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 08:59:20 -0000 On Jul 25, 2010, at 12:18 AM, Alexandru Petrescu wrote: > What is "non-LLN backchannel" and "non-LLN backbone"? > > Is it the same thing? If yes then what is it? (new to me, sorry). Same thing. This is for example when DODAG root are connected via an Ethernet link (IPv6 enabled of course but where RPL is not running). We will make sure to use one term here in next revision. > >> These roots may operate independently, or may coordinate over >> a non-LLN backchannel. > [...] >> o a single DODAG with a single virtual root coordinating LLN sinks >> (with the same DODAGID) over some non-LLN backbone > Formal definition of virtual root will be added too: Virtual DODAG root: A Virtual DODAG root is the result of two or more RPL routers, most typically LBRs, coordinating to synchronize DODAG state and act in concert as if they are a single DODAG root, with multiple interfaces, with respect to the LLN. The coordination most likely occurs over a non-LLN channel, and the details of that scheme are beyond the scope of this specification. > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sun Jul 25 02:05:22 2010 Return-Path: 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 9AE5A3A68D7 for ; Sun, 25 Jul 2010 02:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pk+yTjvjIWrJ for ; Sun, 25 Jul 2010 02:05:21 -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 72EC03A684C for ; Sun, 25 Jul 2010 02:05:21 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+aS0yrR7H+/2dsb2JhbACfXHGkIJlLhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="563434589" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2010 09:05:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P95eM4004645; Sun, 25 Jul 2010 09:05:41 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:05:40 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:05:39 +0200 Message-Id: <7E244E54-F666-47A1-803F-E1BFA5F3FCE3@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4BF434.8000808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:05:39 +0200 References: <4C4B651A.4030402@gmail.com> <4C4BF434.8000808@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:05:39.0848 (UTC) FILETIME=[8D951880:01CB2BD8] Cc: ROLL WG Subject: Re: [Roll] Mentioning link layer names in RPL doc 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:05:22 -0000 On Jul 25, 2010, at 10:22 AM, Alexandru Petrescu wrote: > Le 25/07/2010 10:16, JP Vasseur a =E9crit : >> Hi Alex, >> >> On Jul 25, 2010, at 12:11 AM, Alexandru Petrescu wrote: >> >>> I think the draft should mention more about the link layers it >>> uses. >>> >>> For example here: >>>> RPL is designed to be able to operate over a variety of >>>> different link layers, including but not limited to, low power >>>> wireless or PLC (Power Line Communication) technologies. >>> >>> It is the only name of a link layer appearing in the draft (if I >>> read it correctly). I think more names should appear, to not give >>> the impression that PLC were paramount. >>> >>> And for "PLC" the name of that particular PLC technology (IEEE >>> something?) is worth to write. >>> >> >> The reasons for not mentioning explicitly link layers is precisely >> because we must stay agnostic to the link layer, operating at the >> layer 3. Step back 3-4 years ago: pretty much the link layer for low >> power operation was IEEE 802.15.4. While still an important one, >> many others ones are in the works or have been defined. What we need >> to do is to explain the design choices of RPL in light of their >> characteristics, which is what it is done in the document. > > Ok... but mentioning "PLC" and not any other tech (like Ethernet) =20 > seems > to intentionally give more weight to PLC than others. Is this the > intention? I think that the text says what it needs to say: >>>> RPL is designed to be able to operate over a variety of >>>> different link layers, including but not limited to, low power >>>> wireless or PLC (Power Line Communication) technologies. To answer your question, PLC is explicitly mentioned since lots of =20 work has been done in this area on WSN, the intention was (according to our =20 charter) to be explicit about the fact that RPL has been also designed for low =20= power and lossy PLC link. Note also the "not limited to", which includes =20 Ethernet and many others. > > PLC reads half-way from completely independent of link layer and some > specific IEEE xxx protocol. Why not Ethernet too? (which reads =20 > similary). > > Alex > >> >> Thanks. >> >> JP. >> >>> Alex _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > From jpv@cisco.com Sun Jul 25 02:15:06 2010 Return-Path: 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 251923A67E3 for ; Sun, 25 Jul 2010 02:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.182 X-Spam-Level: X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] 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 FE-kb1+HKvjG for ; Sun, 25 Jul 2010 02:15:04 -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 7887B3A684C for ; Sun, 25 Jul 2010 02:15:04 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADadS0xAZnwM/2dsb2JhbACfXHGkFZlKhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138815968" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 09:15:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9FNPB016828; Sun, 25 Jul 2010 09:15:24 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:15:23 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:15:23 +0200 Message-Id: <8F6D1CE3-DBA8-4598-B8CA-67E50CE6C340@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4BF87A.2010907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:15:22 +0200 References: <4C4B810D.7030101@gmail.com> <1206B2EC-18AE-4C95-80C3-CFB29DCA9030@cisco.com> <4C4BF87A.2010907@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:15:23.0015 (UTC) FILETIME=[E92D5170:01CB2BD9] Cc: ROLL WG Subject: Re: [Roll] Nit: to be confirmed or to be defined or to be assigned... by IANA? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:15:06 -0000 On Jul 25, 2010, at 10:40 AM, Alexandru Petrescu wrote: > Le 25/07/2010 10:33, JP Vasseur a =E9crit : >> Hi Alex, >> >> You are correct that IANA is the only one having the authority to >> assign protocol number. Still it is a common practice to propose a >> value so that implementers can start implementing and interoperate. >> In the example of RPL, this allowed two interoperability tests in the >> past. This numbers are subject to change (this is why you have always >> the mention "to be confirmed by IANA"). > > I disagree - it is not a good practice. Look at the NUMBER of drafts where such a practice is in use. If you do not specify any number, you cannot test until we are in the =20= final stage of the protocol, WHICH is NOT a good practice. In our case, we managed to perform interop as we were designing the =20 protocol, which was very useful. > IT makes change very difficult later: one has to search throughout =20 > the document for 155, for the old 155, for the new 155, etc. and =20 > often this search has to be performed by IANA which has not written =20= > the document i'ts more work for them > > This kind of glitches gets into documents very easily and stays in =20 > RFC... > > Alex > >> >> JP. >> >> On Jul 25, 2010, at 2:10 AM, Alexandru Petrescu wrote: >> >>>> The RPL Control message is an ICMPv6 information message with a >>>> requested Type of 155 (to be confirmed by IANA). >>> >>> I would be more attentive here. I see IANA as somebody one has to >>> ask gently to obtain, not somebody to confirm a personal decision >>> (be that a WG decision). >>> >>> 155 may be the value you see now available but how about next next >>> Monday? Maybe someone at IETF has already got that 155 for their >>> ICMP extension... and knowing 6lowpan, autoconf and IPv6 wg are all >>> active in this area... I wouldn't be so sure. >>> >>> Thus I'd just say >>> >>> Type TBA by IANA >>> >>> In this way when IANA needs to assign it scans the document for >>> the 'IANA' document, if they have time enough. I think they'd >>> rather prefer all concentrated in the IANA section, but that >>> changes with time. >>> >>> I think it's good to _not_ say 155, but TBA, and have all these >>> TBAs in one place. >>> >>> I think there are more particular IANA preferences... or you may >>> already know them all and have written "to be confirmed by IANA" >>> knowing already their preferences - sorry if so. >>> >>> Alex >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> > From jpv@cisco.com Sun Jul 25 02:22:31 2010 Return-Path: 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 B375A3A6897 for ; Sun, 25 Jul 2010 02:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vzg5ehTPXAbP for ; Sun, 25 Jul 2010 02:22: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 0D3C93A67B4 for ; Sun, 25 Jul 2010 02:22:28 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI+fS0xAZnwM/2dsb2JhbACfXHGkHplKgm6CSASIZII6 X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138816928" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 09:22:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9Mmf2018922; Sun, 25 Jul 2010 09:22:48 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:22:47 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:22:47 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B6EF6.602@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-124--1052627342 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:22:46 +0200 References: <4C4B6EF6.602@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:22:47.0227 (UTC) FILETIME=[F1F2B0B0:01CB2BDA] Cc: ROLL WG Subject: Re: [Roll] Nit: apps modified? longer-match term? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:22:31 -0000 --Apple-Mail-124--1052627342 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 25, 2010, at 12:53 AM, Alexandru Petrescu wrote: >> o Nodes provision routing table entries, for the destinations >> specified by the DIO, via their DODAG parents in the DODAG version. >> Nodes MUST provision a DODAG parent as a default route for the >> associated instance. It is up to the end-to-end application to >> select the RPL instance to be associated to its traffic (should >> there be more than one instance) > > 1 - so end-to-end applications must be modified ro tun in an RPL > network? > 2 - so if there is only one instance then the applications must not be > modified? You could deploy a network with one RPLIntance equal to 0. This text will be clarified in the next revision: 5. RPL Instance Within a given LLN, there may be multiple, logically independent RPL instances. A RPL node may belong to multiple RPL instances, and may act as a router in some and as a leaf in others. This document describes how a single instance behaves. There are two types of RPL Instances: local and global. RPL divides the RPLInstanceID space between Global and Local instances to allow for both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL Instances are coordinated, have one or more DODAGs, and are typically long-lived. Local RPL Instances are always a single DODAG whose singular root owns the corresponding DODAGID and allocates the Local RPLInstanceID in a unilateral manner. Local RPL Instances can be used, for example, for constructing DODAGs in support of a future on-demand routing solution. The mode of operation of Local RPL Instances is outside of the scope of this document and may be described in other companion specifications. The definition and provisioning of RPL instances are beyond the =20 scope of this specification. Those operations are expected to be such =20 that data packets coming from the outside of the RPL network can unambiguously be associated to at least one RPL instance, and be safely routed over any instance that would match the packet. Information used to match a packet to a RPL instance can typically =20= be taken from fields in the IPv6 header, like the flow label, differentiated services (DS) field, or destination address. Control and data packets within RPL network are tagged to unambiguously identify what RPL Instance they are part of. Every RPL control message has a RPLInstanceID field. Some RPL control messages, when referring to a local RPLInstanceID as defined below, may also include a DODAGID. Data packet that flow within the RP network expose the RPLInstanceID in the RPL option that is specified in [I-D.hui-6man-rpl-option], =20= and further described in Section 11.2. For data packets coming from outside the RPL network, the RPLInstanceID is determined by the RPL network ingress router and placed in the RPL option that is added to the packet. 5.1. RPL Instance ID A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms for allocating and provisioning global RPLInstanceID are out of =20 scope for this document. There can be up to 128 global instance in the whole network. Local instances are always used in conjunction =20 with a Winter, et al. Expires January 16, 2011 [Page 26] =0C Internet-Draft draft-ietf-roll-rpl-11 July 2010 DODAGID (which is either given explicitly or implicitly in some cases), and up 64 local instances per DODAGID can be supported. Local instances are allocated and managed by the node that owns the DODAGID, without any explicit coordination with other nodes, as further detailed below. A global RPLinstanceID is encoded in a RPLinstanceID field as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLinstanceID in 0..127 +-+-+-+-+-+-+-+-+ Figure 4: RPL Instance ID field format for global instances A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it MUST be unique for that DODAGID. The DODAGID used to configure the local RPLInstanceID MUST be a reachable IPv6 address =20= of the node, and MUST be used as an endpoint of all communications within that local instance. A local RPLinstanceID is encoded in a RPLinstanceID field as =20 follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|D| ID | Local RPLInstanceID in 0..63 +-+-+-+-+-+-+-+-+ Figure 5: RPL Instance ID field format for local instances The D flag in a Local RPLInstanceID is always set to 0 in RPL =20 control messages. It is used in data packets to indicate whether the =20 DODAGID is the source or the destination of the packet. If the D flag is =20= set to 1 then the destination address of the IPv6 packet MUST be the DODAGID. If the D flag is cleared then the source address of the IPv6 packet MUST be the DODAGID. For example, consider a node A that is the DODAG Root of a local RPL Instance, and has allocated a local RPLInstanceID. By definition, all traffic traversing that local RPL Instance will either originate or terminate at node A. The DODAGID in this case will be the reachable IPv6 address of node A, and all traffic will contain the address of node A, thus the DODAGID, in either the source or destination address. Thus the Local RPLInstanceID may indicate that the DODAGID is equivalent to either the source address or the destination address by setting the D flag appropriately. Winter, et al. Expires January 16, 2011 [Page 27] =0C Internet-Draft draft-ietf-roll-rpl-11 July 2010 > >> and thus the default route upwards > > So the default route upwards is associated to a traffic. > If your have multiple RPL instance, you have multiple default routes. When steering your data packer to a RPL instance, it follows the routes of the corresponding DODAG. >> when no longer-match exists. > Because you can advertise specific routes in DIO, more specific than the default route. > No better route exists, maybe? > > I don't understand "no longer-match exists": is it "shorter match > exists"? is it "longer-match does not exist"? > > I do understand longest prefix match algorightms. But many people > understand different things by this "longest prefix match" term, and =20= > it > deservers clarification, it precludes understanding the negative "no > longer-match exists". > > If needed, I can discuss this term further, I am all ears. > > In all cases, that last phrase is way too long. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-124--1052627342 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Jul 25, 2010, = at 12:53 AM, Alexandru Petrescu wrote:

o  Nodes provision = routing table entries, for the destinations
specified by the DIO, via their DODAG parents in the DODAG = version.
Nodes MUST provision = a DODAG parent as a default route for the
associated instance.  It is up to the end-to-end = application to
select the RPL = instance to be associated to its traffic = (should
there be more than one = instance)

1 - so end-to-end applications must be = modified ro tun in an RPL
   network?
2 - so if = there is only one instance then the applications must not be
=    modified?

You = could deploy a network with one RPLIntance equal to = 0.

This text will be clarified in the next = revision:

5.  RPL Instance

   Within a given LLN, there may be multiple, logically independent RPL
   instances.  A RPL node may belong to multiple RPL instances, and may
   act as a router in some and as a leaf in others.  This document
   describes how a single instance behaves.

   There are two types of RPL Instances: local and global.  RPL divides
   the RPLInstanceID space between Global and Local instances to allow
   for both coordinated and unilateral allocation of RPLInstanceIDs.
   Global RPL Instances are coordinated, have one or more DODAGs, and
   are typically long-lived.  Local RPL Instances are always a single
   DODAG whose singular root owns the corresponding DODAGID and
   allocates the Local RPLInstanceID in a unilateral manner.  Local RPL
   Instances can be used, for example, for constructing DODAGs in
   support of a future on-demand routing solution.  The mode of
   operation of Local RPL Instances is outside of the scope of this
   document and may be described in other companion specifications.

   The definition and provisioning of RPL instances are beyond the scope
   of this specification.  Those operations are expected to be such that
   data packets coming from the outside of the RPL network can
   unambiguously be associated to at least one RPL instance, and be
   safely routed over any instance that would match the packet.
   Information used to match a packet to a RPL instance can typically be
   taken from fields in the IPv6 header, like the flow label,
   differentiated services (DS) field, or destination address.

   Control and data packets within RPL network are tagged to
   unambiguously identify what RPL Instance they are part of.

   Every RPL control message has a RPLInstanceID field.  Some RPL
   control messages, when referring to a local RPLInstanceID as defined
   below, may also include a DODAGID.

   Data packet that flow within the RP network expose the RPLInstanceID
   in the RPL option that is specified in [I-D.hui-6man-rpl-option], and
   further described in Section 11.2.  For data packets coming from
   outside the RPL network, the RPLInstanceID is determined by the RPL
   network ingress router and placed in the RPL option that is added to
   the packet.

5.1.  RPL Instance ID

   A global RPLInstanceID MUST be unique to the whole LLN.  Mechanisms
   for allocating and provisioning global RPLInstanceID are out of scope
   for this document.  There can be up to 128 global instance in the
   whole network.  Local instances are always used in conjunction with a



Winter, et al.          Expires January 16, 2011               [Page 26]
=0C
Internet-Draft           draft-ietf-roll-rpl-11                July 2010


   DODAGID (which is either given explicitly or implicitly in some
   cases), and up 64 local instances per DODAGID can be supported.
   Local instances are allocated and managed by the node that owns the
   DODAGID, without any explicit coordination with other nodes, as
   further detailed below.

   A global RPLinstanceID is encoded in a RPLinstanceID field as
   follows:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |0|     ID      |  Global RPLinstanceID in 0..127
       +-+-+-+-+-+-+-+-+


        Figure 4: RPL Instance ID field format for global instances

   A local RPLInstanceID is autoconfigured by the node that owns the
   DODAGID and it MUST be unique for that DODAGID.  The DODAGID used to
   configure the local RPLInstanceID MUST be a reachable IPv6 address of
   the node, and MUST be used as an endpoint of all communications
   within that local instance.

   A local RPLinstanceID is encoded in a RPLinstanceID field as follows:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |1|D|   ID      |  Local RPLInstanceID in 0..63
       +-+-+-+-+-+-+-+-+

        Figure 5: RPL Instance ID field format for local instances

   The D flag in a Local RPLInstanceID is always set to 0 in RPL control
   messages.  It is used in data packets to indicate whether the DODAGID
   is the source or the destination of the packet.  If the D flag is set
   to 1 then the destination address of the IPv6 packet MUST be the
   DODAGID.  If the D flag is cleared then the source address of the
   IPv6 packet MUST be the DODAGID.

   For example, consider a node A that is the DODAG Root of a local RPL
   Instance, and has allocated a local RPLInstanceID.  By definition,
   all traffic traversing that local RPL Instance will either originate
   or terminate at node A. The DODAGID in this case will be the
   reachable IPv6 address of node A, and all traffic will contain the
   address of node A, thus the DODAGID, in either the source or
   destination address.  Thus the Local RPLInstanceID may indicate that
   the DODAGID is equivalent to either the source address or the
   destination address by setting the D flag appropriately.



Winter, et al.          Expires January 16, 2011               [Page 27]
=0C
Internet-Draft           draft-ietf-roll-rpl-11                July 2010
 


and thus the default = route upwards

So the default route upwards is = associated to a = traffic.


If your have = multiple RPL instance, you have multiple default routes.
When = steering your data packer to a RPL instance, it follows the = routes
of the corresponding DODAG.

when no longer-match = exists.


Because= you can advertise specific routes in DIO, more specific than = the
default route.

No = better route exists, maybe?

I don't understand "no longer-match = exists": is it "shorter match
exists"? is it "longer-match does not = exist"?

I do understand longest prefix match algorightms. =  But many people
understand different things by this "longest = prefix match" term, and it
deservers clarification, it precludes = understanding the negative "no
longer-match exists".

If = needed, I can discuss this term further, I am all ears.

In all = cases, that last phrase is way too = long.

Alex
_______________________________________________
Ro= ll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-124--1052627342-- From alexandru.petrescu@gmail.com Sun Jul 25 02:23:19 2010 Return-Path: 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 695D33A684C for ; Sun, 25 Jul 2010 02:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=0.764, 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 DYFZMiQBp8j5 for ; Sun, 25 Jul 2010 02:23:18 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5A73A67B4 for ; Sun, 25 Jul 2010 02:23:08 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 517169400E5; Sun, 25 Jul 2010 11:23:23 +0200 (CEST) Message-ID: <4C4C0286.8060709@gmail.com> Date: Sun, 25 Jul 2010 11:23:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B6C8D.50100@gmail.com> <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> In-Reply-To: <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:23:19 -0000 Le 25/07/2010 10:44, JP Vasseur a écrit : > > On Jul 25, 2010, at 12:43 AM, Alexandru Petrescu wrote: > >> Nit: what is a datapath? The term appears in the title of a >> section >> >>> 3.3.7. Datapath Validation and Loop Detection >> >> and it is not explained further. >> >> I understand path and data but the combination is not clear to me. >> >> Because of this, this text reads strange: >>> RPL uses a hop-by-hop IPv6 header to detect possible loops within >>> a DODAG. Each data packet includes the Rank of the transmitter. >> >> What is a 'data packet'? > > An IPv6 packet carrying user data as opposed to a routing control > message such as a DIS. > >> Do you mean I have to modify every application to include that IPv6 >> header to insert new options? >> > > Your application builds the IP packet and allows setting IPv6 header > field (DS, ...), but also extended headers, ... > > In RPL, datapath validation and loop detection is performed by adding > the RPL option defined in (draft-hui-6man-rpl-option-01) carried in > the hop by hop header. This part will be more detailed in the next > revision (see for example ticket 64) Who adds that option field? ("Each data packet includes the Rank of the transmitter.") - the application or RPL? Alex > > JP. > >> E.g. if I run http and TCP - do I have to modify the TCP stack to >> include this Rank on each data packet? >> >> (Is it "Each" or "Some"?) >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sun Jul 25 02:24:45 2010 Return-Path: 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 609C33A67B4 for ; Sun, 25 Jul 2010 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=0.749, 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 xNCJymadXmj2 for ; Sun, 25 Jul 2010 02:24:44 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 755A03A684C for ; Sun, 25 Jul 2010 02:24:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 83B7B94006D; Sun, 25 Jul 2010 11:24:57 +0200 (CEST) Message-ID: <4C4C02E4.5060700@gmail.com> Date: Sun, 25 Jul 2010 11:24:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4C4B65F6.2060705@gmail.com> <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> <4C4BF49C.9080708@gmail.com> <2499913B-4A57-4452-9736-A930B963B4AD@surrey.ac.uk> In-Reply-To: <2499913B-4A57-4452-9736-A930B963B4AD@surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:24:45 -0000 Le 25/07/2010 10:47, L.Wood@surrey.ac.uk a écrit : > > On 25 Jul 2010, at 09:23, Alexandru Petrescu wrote: > >>> used to route the packet on the appropriate topology. Here is a >>> pretty good discussion about this term: >>> http://en.wikipedia.org/wiki/Metadata >> >> No. >> >> For example you have "conceptual structures" which is ok - has fields, >> entries, leads to implementation. MEta-data is just that: meta talk. > > Metadata is generally structured and machine readable. Metadata or meta-data? Yes structured - and the spec would say how is it structured - it doesn't. (it does for the conceptual data structures which are not the same thing as 'meta-data') Alex > > The wikipedia page gives examples. > > Lloyd Wood > L.Wood@surrey.ac.uk > http://sat-net.com/L.Wood > > > > From jpv@cisco.com Sun Jul 25 02:27:29 2010 Return-Path: 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 704A23A68ED for ; Sun, 25 Jul 2010 02:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 8ivYqeWimImn for ; Sun, 25 Jul 2010 02:27:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 317783A6836 for ; Sun, 25 Jul 2010 02:27:27 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAImgS0yrR7Ht/2dsb2JhbACfXHGkIJlJhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="230423241" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 25 Jul 2010 09:27:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9RjVS009013; Sun, 25 Jul 2010 09:27:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:27:45 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:27:44 +0200 Message-Id: <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4B7359.6010109@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-125--1052330069 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:27:44 +0200 References: <4C4B7359.6010109@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:27:44.0835 (UTC) FILETIME=[A3561130:01CB2BDB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17526.006 X-TM-AS-Result: No--38.274600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:27:29 -0000 --Apple-Mail-125--1052330069 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable To explain "geediness" we have added an example (see below). Local repair is by contrast with global repair where the DODAG =20 increments the DODAG version and the DODAG is being "Rebuit", which may or may not lead to a different DODAG shape. With local repair, the DODAG is repaired "locally" to restore connectivity without rebuilding the =20 entire DODAG. Example that will be added about "greediness" 3.8.1.1. Example: Greedy Parent Selection and Instability (A) (A) (A) |\ |\ |\ | `-----. | `-----. | `-----. | \ | \ | \ (B) (C) (B) \ | (C) \ | | / `-----. | | .-----' \| |/ (C) (B) -1- -2- -3- Figure 3: Greedy DODAG Parent Selection Figure 3 depicts a DODAG in 3 different configurations. A usable link between (B) and (C) exists in all 3 configurations. In Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a DODAG parent for Node (B). If a RPL node is too greedy, in that it attempts to optimize for an additional number of parents beyond its most preferred parents, then an instability can result. Consider the DODAG illustrated in Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but we will consider the case when they are operating under the greedy condition that will try to optimize for 2 Winter, et al. Expires January 16, 2011 [Page 22] =0C Internet-Draft draft-ietf-roll-rpl-11 July 2010 parents. o Let Figure 3-1 be the initial condition. o Suppose Node (C) first is able to leave the DODAG and rejoin at a lower rank, taking both Nodes (A) and (B) as DODAG parents as depicted in Figure 3-2. Now Node (C) is deeper than both Nodes (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. o Suppose Node (B), in its greediness, is willing to receive and process a DIO message from Node (C) (against the rules of RPL), and then Node (B) leaves the DODAG and rejoins at a lower rank, taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is deeper than both Nodes (A) and (C) and is satisfied with 2 DAG parents. o Then Node (C), because it is also greedy, will leave and rejoin deeper, to again get 2 parents and have a lower rank then both of them. o Next Node (B) will again leave and rejoin deeper, to again get 2 parents o And again Node (C) leaves and rejoins deeper... o The process will repeat, and the DODAG will oscillate between Figure 3-2 and Figure 3-3 until the nodes count to infinity and restart the cycle again. o This cycle can be averted through mechanisms in RPL: * Nodes (B) and (C) stay at a rank sufficient to attach to their most preferred parent (A) and don't go for any deeper (worse) alternate parents (Nodes are not greedy) * Nodes (B) and (C) do not process DIO messages from nodes =20 deeper than themselves (because such nodes are possibly in their own sub-DODAGs) On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: >> Once a node has joined a DODAG version, RPL disallows certain >> behaviors, including greediness, in order to prevent resulting >> instabilities in the DODAG version. > > How? I searched for greed further down the text and it does not =20 > appear. > > This phrase sounds as if there is a bit set on/off called 'greed', or > similar. > > I may be wrong. > >> It is for this reason that RPL limits the cases where a node may >> process DIO messages from deeper nodes to some forms of local >> repair. > > Which forms? > > 'local repair' procedure is mentioned several times in the draft: > >> On receiving such a packet, a node institutes a local repair >> operation. > [...] >> Strict use of the DODAG Version Number can eliminate this type of >> loop, but this type of loop may possibly be encountered when using >> some local repair mechanisms. >> > [...] >> MaxRankIncrease: 16-bit unsigned integer used to configure >> DAGMaxRankIncrease, the allowable increase in rank in support of >> local repair. > [...] >> o Trigger a local repair > [...] >> o Number of times a local repair procedure was triggered > > These are all the occurences of "local repair". It reads as an > operation, mechanism, procedure. It is some form, some. > > But what is a local repair? > > Probably it is another term explained elsewhere that I can't find =20 > while > searching in this draft, sorry if so. > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-125--1052330069 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable To explain "geediness" we have = added an example (see below).
Local repair is by contrast with = global repair where the DODAG increments
the DODAG version and = the DODAG is being "Rebuit", which may or may 
not lead = to a different DODAG shape. With local repair, the DODAG = is 
repaired "locally" to restore connectivity without = rebuilding the entire DODAG.

Example that will = be added about "greediness"

3.8.1.1.  =
Example: Greedy Parent Selection and Instability


         (A)                    (A)                    (A)
          |\                     |\                     |\
          | `-----.              | `-----.              | `-----.
          |        \             |        \             |        \
         (B)       (C)          (B)        \            |        (C)
                                  \        |            |        /
                                   `-----. |            | .-----'
                                          \|            |/
                                          (C)          (B)

              -1-                    -2-                    -3-


                  Figure 3: Greedy DODAG Parent Selection

   Figure 3 depicts a DODAG in 3 different configurations.  A usable
   link between (B) and (C) exists in all 3 configurations.  In
   Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C).  In
   Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and
   Node (B) is also a DODAG parent for Node (C).  In Figure 3-3, Node
   (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a
   DODAG parent for Node (B).

   If a RPL node is too greedy, in that it attempts to optimize for an
   additional number of parents beyond its most preferred parents, then
   an instability can result.  Consider the DODAG illustrated in
   Figure 3-1.  In this example, Nodes (B) and (C) may most prefer Node
   (A) as a DODAG parent, but we will consider the case when they are
   operating under the greedy condition that will try to optimize for 2



Winter, et al.          Expires January 16, 2011               [Page 22]
=0C
Internet-Draft           draft-ietf-roll-rpl-11                July 2010


   parents.

   o  Let Figure 3-1 be the initial condition.

   o  Suppose Node (C) first is able to leave the DODAG and rejoin at a
      lower rank, taking both Nodes (A) and (B) as DODAG parents as
      depicted in Figure 3-2.  Now Node (C) is deeper than both Nodes
      (A) and (B), and Node (C) is satisfied to have 2 DODAG parents.

   o  Suppose Node (B), in its greediness, is willing to receive and
      process a DIO message from Node (C) (against the rules of RPL),
      and then Node (B) leaves the DODAG and rejoins at a lower rank,
      taking both Nodes (A) and (C) as DODAG parents.  Now Node (B) is
      deeper than both Nodes (A) and (C) and is satisfied with 2 DAG
      parents.

   o  Then Node (C), because it is also greedy, will leave and rejoin
      deeper, to again get 2 parents and have a lower rank then both of
      them.

   o  Next Node (B) will again leave and rejoin deeper, to again get 2
      parents

   o  And again Node (C) leaves and rejoins deeper...

   o  The process will repeat, and the DODAG will oscillate between
      Figure 3-2 and Figure 3-3 until the nodes count to infinity and
      restart the cycle again.

   o  This cycle can be averted through mechanisms in RPL:

      *  Nodes (B) and (C) stay at a rank sufficient to attach to their
         most preferred parent (A) and don't go for any deeper (worse)
         alternate parents (Nodes are not greedy)

      *  Nodes (B) and (C) do not process DIO messages from nodes deeper
         than themselves (because such nodes are possibly in their own
         sub-DODAGs)
=




<= div>
On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote:

Once a node has joined a = DODAG version, RPL disallows certain
behaviors, including greediness, in order to prevent = resulting
instabilities in the = DODAG version.

How?  I searched for greed = further down the text and it does not appear.

This phrase sounds = as if there is a bit set on/off called 'greed', or
similar.

I = may be wrong.

It is for this reason = that RPL limits the cases where a node may
process DIO messages from deeper nodes to some forms of = local
repair.

Which forms?

'local = repair' procedure is mentioned several times in the = draft:

On receiving such a packet, a = node institutes a local repair
operation.
[...]
Strict use of the DODAG Version Number can eliminate this = type of
loop, but this type of = loop may possibly be encountered when using
some local repair mechanisms.

[...]
MaxRankIncrease:  16-bit unsigned integer used to = configure
DAGMaxRankIncrease, = the allowable increase in rank in support of
local repair.
[...]
o  Trigger a local = repair
[...]
o  Number = of times a local repair procedure was = triggered

These are all the occurences of "local = repair".  It reads as an
operation, mechanism, procedure. =  It is some form, some.

But what is a local = repair?

Probably it is another term explained elsewhere that I = can't find while
searching in this draft, sorry if = so.

Alex
_______________________________________________
Roll= mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-125--1052330069-- From jpv@cisco.com Sun Jul 25 02:28:38 2010 Return-Path: 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 49B843A68C0 for ; Sun, 25 Jul 2010 02:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OjIWKMsJg5q5 for ; Sun, 25 Jul 2010 02:28:37 -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 301603A6901 for ; Sun, 25 Jul 2010 02:28:30 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL6gS0yrR7H+/2dsb2JhbACfXHGkHZlJhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="563439172" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2010 09:28:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9Snv2011970; Sun, 25 Jul 2010 09:28:49 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:28:48 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:28:48 +0200 Message-Id: <8532B297-6296-437C-AB84-F30637256091@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4C0286.8060709@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:28:47 +0200 References: <4C4B6C8D.50100@gmail.com> <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> <4C4C0286.8060709@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:28:48.0205 (UTC) FILETIME=[C91B8FD0:01CB2BDB] Cc: ROLL WG Subject: Re: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:28:38 -0000 On Jul 25, 2010, at 11:23 AM, Alexandru Petrescu wrote: > Le 25/07/2010 10:44, JP Vasseur a =E9crit : >> >> On Jul 25, 2010, at 12:43 AM, Alexandru Petrescu wrote: >> >>> Nit: what is a datapath? The term appears in the title of a >>> section >>> >>>> 3.3.7. Datapath Validation and Loop Detection >>> >>> and it is not explained further. >>> >>> I understand path and data but the combination is not clear to me. >>> >>> Because of this, this text reads strange: >>>> RPL uses a hop-by-hop IPv6 header to detect possible loops within >>>> a DODAG. Each data packet includes the Rank of the transmitter. >>> >>> What is a 'data packet'? >> >> An IPv6 packet carrying user data as opposed to a routing control >> message such as a DIS. >> >>> Do you mean I have to modify every application to include that IPv6 >>> header to insert new options? >>> >> >> Your application builds the IP packet and allows setting IPv6 header >> field (DS, ...), but also extended headers, ... >> >> In RPL, datapath validation and loop detection is performed by adding >> the RPL option defined in (draft-hui-6man-rpl-option-01) carried in >> the hop by hop header. This part will be more detailed in the next >> revision (see for example ticket 64) > > Who adds that option field? ("Each data packet includes the Rank of =20= > the transmitter.") - the application or RPL? RPL ! The application does not know about the rank of course. JP. > > Alex > >> >> JP. >> >>> E.g. if I run http and TCP - do I have to modify the TCP stack to >>> include this Rank on each data packet? >>> >>> (Is it "Each" or "Some"?) >>> >>> Alex >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > From alexandru.petrescu@gmail.com Sun Jul 25 02:30:23 2010 Return-Path: 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 13CEB3A684C for ; Sun, 25 Jul 2010 02:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6] 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 1YPJawIDIxPO for ; Sun, 25 Jul 2010 02:30:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 87C573A68F0 for ; Sun, 25 Jul 2010 02:30:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C32B79400CC; Sun, 25 Jul 2010 11:30:28 +0200 (CEST) Message-ID: <4C4C0430.6020002@gmail.com> Date: Sun, 25 Jul 2010 11:30:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B810D.7030101@gmail.com> <1206B2EC-18AE-4C95-80C3-CFB29DCA9030@cisco.com> <4C4BF87A.2010907@gmail.com> <8F6D1CE3-DBA8-4598-B8CA-67E50CE6C340@cisco.com> In-Reply-To: <8F6D1CE3-DBA8-4598-B8CA-67E50CE6C340@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: to be confirmed or to be defined or to be assigned... by IANA? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:30:23 -0000 Le 25/07/2010 11:15, JP Vasseur a écrit : > > On Jul 25, 2010, at 10:40 AM, Alexandru Petrescu wrote: > >> Le 25/07/2010 10:33, JP Vasseur a écrit : >>> Hi Alex, >>> >>> You are correct that IANA is the only one having the authority to >>> assign protocol number. Still it is a common practice to propose >>> a value so that implementers can start implementing and >>> interoperate. In the example of RPL, this allowed two >>> interoperability tests in the past. This numbers are subject to >>> change (this is why you have always the mention "to be confirmed >>> by IANA"). >> >> I disagree - it is not a good practice. > > Look at the NUMBER of drafts where such a practice is in use. If you > do not specify any number, you cannot test until we are in the final > stage of the protocol, YEs you can - use a locally defined number in lab, not even need to inform IETF. Or write an EXPERIMENTAL draft about that number, without informing IANA. When you ask me to look at the number of drafts where such a practice is in use - maybe I already looked. I am speaking from my own experience of implementing such drafts. This experience may or may not be useful here. Did you ask somebody else whether it's good to have that '155' there? Or whether it is good to say in doc anything else than TBA prior to IANA assignment? Maybe we should ask somebody from IANA to advice. My experience has been reported. > WHICH is NOT a good practice. In our case, we managed to perform > interop as we were designing the protocol, which was very useful. WEll you did, which is good. But I'd refrain from the tendency of telling IANA "we interoped with 155 so please confirm it" - I'd rather say "IANA, we used some magic number - what would you assign for me? TBA". Alex > > >> IT makes change very difficult later: one has to search throughout >> the document for 155, for the old 155, for the new 155, etc. and >> often this search has to be performed by IANA which has not >> written the document i'ts more work for them >> >> This kind of glitches gets into documents very easily and stays in >> RFC... >> >> Alex >> >>> >>> JP. >>> >>> On Jul 25, 2010, at 2:10 AM, Alexandru Petrescu wrote: >>> >>>>> The RPL Control message is an ICMPv6 information message >>>>> with a requested Type of 155 (to be confirmed by IANA). >>>> >>>> I would be more attentive here. I see IANA as somebody one has >>>> to ask gently to obtain, not somebody to confirm a personal >>>> decision (be that a WG decision). >>>> >>>> 155 may be the value you see now available but how about next >>>> next Monday? Maybe someone at IETF has already got that 155 >>>> for their ICMP extension... and knowing 6lowpan, autoconf and >>>> IPv6 wg are all active in this area... I wouldn't be so sure. >>>> >>>> Thus I'd just say >>>> >>>> Type TBA by IANA >>>> >>>> In this way when IANA needs to assign it scans the document for >>>> the 'IANA' document, if they have time enough. I think they'd >>>> rather prefer all concentrated in the IANA section, but that >>>> changes with time. >>>> >>>> I think it's good to _not_ say 155, but TBA, and have all these >>>> TBAs in one place. >>>> >>>> I think there are more particular IANA preferences... or you >>>> may already know them all and have written "to be confirmed by >>>> IANA" knowing already their preferences - sorry if so. >>>> >>>> Alex >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >>> >> > > From alexandru.petrescu@gmail.com Sun Jul 25 02:33:30 2010 Return-Path: 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 F3BEC3A684C for ; Sun, 25 Jul 2010 02:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=0.726, 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 4FxotQjfD9A6 for ; Sun, 25 Jul 2010 02:33:29 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C1FBC3A6841 for ; Sun, 25 Jul 2010 02:33:27 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D9182940063; Sun, 25 Jul 2010 11:33:41 +0200 (CEST) Message-ID: <4C4C04F1.2080407@gmail.com> Date: Sun, 25 Jul 2010 11:33:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B7359.6010109@gmail.com> <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> In-Reply-To: <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:33:30 -0000 Le 25/07/2010 11:27, JP Vasseur a écrit : > To explain "geediness" we have added an example (see below). [...] > Internet-Draft draft-ietf-roll-rpl-11 July 2010 11? I thought it was 10? Am I looking at the right document? This is a moving target - I do not like to work that way, sorry. Please post drafts publicly and only then ask for review. Can't work this way: private documents, fuzzy authorship. It's a waste of time from my part. Yes, procedure is important. Alex > > > parents. > > o Let Figure 3-1 be the initial condition. > > o Suppose Node (C) first is able to leave the DODAG and rejoin at a > lower rank, taking both Nodes (A) and (B) as DODAG parents as > depicted in Figure 3-2. Now Node (C) is deeper than both Nodes > (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. > > o Suppose Node (B), in its greediness, is willing to receive and > process a DIO message from Node (C) (against the rules of RPL), > and then Node (B) leaves the DODAG and rejoins at a lower rank, > taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is > deeper than both Nodes (A) and (C) and is satisfied with 2 DAG > parents. > > o Then Node (C), because it is also greedy, will leave and rejoin > deeper, to again get 2 parents and have a lower rank then both of > them. > > o Next Node (B) will again leave and rejoin deeper, to again get 2 > parents > > o And again Node (C) leaves and rejoins deeper... > > o The process will repeat, and the DODAG will oscillate between > Figure 3-2 and Figure 3-3 until the nodes count to infinity and > restart the cycle again. > > o This cycle can be averted through mechanisms in RPL: > > * Nodes (B) and (C) stay at a rank sufficient to attach to their > most preferred parent (A) and don't go for any deeper (worse) > alternate parents (Nodes are not greedy) > > * Nodes (B) and (C) do not process DIO messages from nodes deeper > than themselves (because such nodes are possibly in their own > sub-DODAGs) > > > > > > On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: > >>> Once a node has joined a DODAG version, RPL disallows certain >>> behaviors, including greediness, in order to prevent resulting >>> instabilities in the DODAG version. >> >> How? I searched for greed further down the text and it does not appear. >> >> This phrase sounds as if there is a bit set on/off called 'greed', or >> similar. >> >> I may be wrong. >> >>> It is for this reason that RPL limits the cases where a node may >>> process DIO messages from deeper nodes to some forms of local >>> repair. >> >> Which forms? >> >> 'local repair' procedure is mentioned several times in the draft: >> >>> On receiving such a packet, a node institutes a local repair >>> operation. >> [...] >>> Strict use of the DODAG Version Number can eliminate this type of >>> loop, but this type of loop may possibly be encountered when using >>> some local repair mechanisms. >>> >> [...] >>> MaxRankIncrease: 16-bit unsigned integer used to configure >>> DAGMaxRankIncrease, the allowable increase in rank in support of >>> local repair. >> [...] >>> o Trigger a local repair >> [...] >>> o Number of times a local repair procedure was triggered >> >> These are all the occurences of "local repair". It reads as an >> operation, mechanism, procedure. It is some form, some. >> >> But what is a local repair? >> >> Probably it is another term explained elsewhere that I can't find while >> searching in this draft, sorry if so. >> >> Alex >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Sun Jul 25 02:37:28 2010 Return-Path: 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 141C93A67B4 for ; Sun, 25 Jul 2010 02:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.712, 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 ORonuYTocFLX for ; Sun, 25 Jul 2010 02:37:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E8A073A677C for ; Sun, 25 Jul 2010 02:37:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1CCA19400AC; Sun, 25 Jul 2010 11:37:39 +0200 (CEST) Message-ID: <4C4C05DF.4020705@gmail.com> Date: Sun, 25 Jul 2010 11:37:35 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B6C8D.50100@gmail.com> <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> <4C4C0286.8060709@gmail.com> <8532B297-6296-437C-AB84-F30637256091@cisco.com> In-Reply-To: <8532B297-6296-437C-AB84-F30637256091@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:37:28 -0000 Le 25/07/2010 11:28, JP Vasseur a écrit : > > On Jul 25, 2010, at 11:23 AM, Alexandru Petrescu wrote: > >> Le 25/07/2010 10:44, JP Vasseur a écrit : >>> >>> On Jul 25, 2010, at 12:43 AM, Alexandru Petrescu wrote: >>> >>>> Nit: what is a datapath? The term appears in the title of a >>>> section >>>> >>>>> 3.3.7. Datapath Validation and Loop Detection >>>> >>>> and it is not explained further. >>>> >>>> I understand path and data but the combination is not clear to >>>> me. >>>> >>>> Because of this, this text reads strange: >>>>> RPL uses a hop-by-hop IPv6 header to detect possible loops >>>>> within a DODAG. Each data packet includes the Rank of the >>>>> transmitter. >>>> >>>> What is a 'data packet'? >>> >>> An IPv6 packet carrying user data as opposed to a routing >>> control message such as a DIS. >>> >>>> Do you mean I have to modify every application to include that >>>> IPv6 header to insert new options? >>>> >>> >>> Your application builds the IP packet and allows setting IPv6 >>> header field (DS, ...), but also extended headers, ... >>> >>> In RPL, datapath validation and loop detection is performed by >>> adding the RPL option defined in (draft-hui-6man-rpl-option-01) >>> carried in the hop by hop header. This part will be more detailed >>> in the next revision (see for example ticket 64) >> >> Who adds that option field? ("Each data packet includes the Rank of >> the transmitter.") - the application or RPL? > > RPL ! The application does not know about the rank of course. RPL touches every data packet? I would oppose that. In some exceptional cases - maybe, but not always. Let the app be end-to-end, in most cases at least. You're mentioning a draft-hui about hbh - would RPL advance without that document adopted as WG item, progressed, etc. Would the MEssage Authentication Code cover that HbH header? How? Which fields are initialized and which are computed first? Or would AH cover it? Alex > > JP. > >> >> Alex >> >>> >>> JP. >>> >>>> E.g. if I run http and TCP - do I have to modify the TCP stack >>>> to include this Rank on each data packet? >>>> >>>> (Is it "Each" or "Some"?) >>>> >>>> Alex >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >> > > From jpv@cisco.com Sun Jul 25 02:39:43 2010 Return-Path: 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 7B7EC3A684C for ; Sun, 25 Jul 2010 02:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 yWZM78100g1L for ; Sun, 25 Jul 2010 02:39:42 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 316213A677C for ; Sun, 25 Jul 2010 02:39:42 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIqjS0yrR7Ht/2dsb2JhbACfXHGkHJlJhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="162623241" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 25 Jul 2010 09:40:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9e1JC012719; Sun, 25 Jul 2010 09:40:01 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:40:00 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:40:00 +0200 Message-Id: <2DA850CF-D601-4966-946D-DC4D85E779C9@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4C04F1.2080407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:39:59 +0200 References: <4C4B7359.6010109@gmail.com> <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> <4C4C04F1.2080407@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:40:00.0695 (UTC) FILETIME=[59F16470:01CB2BDD] Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:39:43 -0000 On Jul 25, 2010, at 11:33 AM, Alexandru Petrescu wrote: > Le 25/07/2010 11:27, JP Vasseur a =E9crit : >> To explain "geediness" we have added an example (see below). > [...] >> Internet-Draft draft-ietf-roll-rpl-11 July =20= >> 2010 > > 11? I thought it was 10? It is 10 right now. The author team has been working hard to =20 incorporate all the comments, ticket resolutions in the (to be posted) revision 11. I gave you some =20= new text that will be incorporated to answer your question. > > Am I looking at the right document? > > This is a moving target - I do not like to work that way, sorry. =20 > Please post drafts publicly and only then ask for review. > > Can't work this way: private documents, fuzzy authorship. > > It's a waste of time from my part. > > Yes, procedure is important. > Alex, we are in WG LC. We have received a number of comments, open a =20 number of tickets, proposed solutions, ... this cannot be more transparent. Resolution text are =20 being worked out and I gave you extracts. That's it. JP. > Alex > >> >> >> parents. >> >> o Let Figure 3-1 be the initial condition. >> >> o Suppose Node (C) first is able to leave the DODAG and rejoin =20= >> at a >> lower rank, taking both Nodes (A) and (B) as DODAG parents as >> depicted in Figure 3-2. Now Node (C) is deeper than both Nodes >> (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. >> >> o Suppose Node (B), in its greediness, is willing to receive and >> process a DIO message from Node (C) (against the rules of RPL), >> and then Node (B) leaves the DODAG and rejoins at a lower rank, >> taking both Nodes (A) and (C) as DODAG parents. Now Node (B) =20= >> is >> deeper than both Nodes (A) and (C) and is satisfied with 2 DAG >> parents. >> >> o Then Node (C), because it is also greedy, will leave and rejoin >> deeper, to again get 2 parents and have a lower rank then =20 >> both of >> them. >> >> o Next Node (B) will again leave and rejoin deeper, to again =20 >> get 2 >> parents >> >> o And again Node (C) leaves and rejoins deeper... >> >> o The process will repeat, and the DODAG will oscillate between >> Figure 3-2 and Figure 3-3 until the nodes count to infinity and >> restart the cycle again. >> >> o This cycle can be averted through mechanisms in RPL: >> >> * Nodes (B) and (C) stay at a rank sufficient to attach to =20 >> their >> most preferred parent (A) and don't go for any deeper =20 >> (worse) >> alternate parents (Nodes are not greedy) >> >> * Nodes (B) and (C) do not process DIO messages from nodes =20 >> deeper >> than themselves (because such nodes are possibly in their =20= >> own >> sub-DODAGs) >> >> >> >> >> >> On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: >> >>>> Once a node has joined a DODAG version, RPL disallows certain >>>> behaviors, including greediness, in order to prevent resulting >>>> instabilities in the DODAG version. >>> >>> How? I searched for greed further down the text and it does not =20 >>> appear. >>> >>> This phrase sounds as if there is a bit set on/off called 'greed', =20= >>> or >>> similar. >>> >>> I may be wrong. >>> >>>> It is for this reason that RPL limits the cases where a node may >>>> process DIO messages from deeper nodes to some forms of local >>>> repair. >>> >>> Which forms? >>> >>> 'local repair' procedure is mentioned several times in the draft: >>> >>>> On receiving such a packet, a node institutes a local repair >>>> operation. >>> [...] >>>> Strict use of the DODAG Version Number can eliminate this type of >>>> loop, but this type of loop may possibly be encountered when using >>>> some local repair mechanisms. >>>> >>> [...] >>>> MaxRankIncrease: 16-bit unsigned integer used to configure >>>> DAGMaxRankIncrease, the allowable increase in rank in support of >>>> local repair. >>> [...] >>>> o Trigger a local repair >>> [...] >>>> o Number of times a local repair procedure was triggered >>> >>> These are all the occurences of "local repair". It reads as an >>> operation, mechanism, procedure. It is some form, some. >>> >>> But what is a local repair? >>> >>> Probably it is another term explained elsewhere that I can't find =20= >>> while >>> searching in this draft, sorry if so. >>> >>> Alex >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> > From jpv@cisco.com Sun Jul 25 02:41:32 2010 Return-Path: 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 B2E1F3A689E for ; Sun, 25 Jul 2010 02:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 qq+MRv8H3F2P for ; Sun, 25 Jul 2010 02:41: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 975713A67D7 for ; Sun, 25 Jul 2010 02:41:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAOkS0xAZnwM/2dsb2JhbACfXHGkHJlIhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138863476" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 09:41:50 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6P9fojF022862; Sun, 25 Jul 2010 09:41:50 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:41:49 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 11:41:49 +0200 Message-Id: <716C47EB-337F-49E6-8A73-71314499B72B@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4C05DF.4020705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 11:41:48 +0200 References: <4C4B6C8D.50100@gmail.com> <2D0F6F11-0188-4E45-A596-91A5E8F8EDAB@cisco.com> <4C4C0286.8060709@gmail.com> <8532B297-6296-437C-AB84-F30637256091@cisco.com> <4C4C05DF.4020705@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 09:41:49.0792 (UTC) FILETIME=[9AF84600:01CB2BDD] Cc: ROLL WG Subject: Re: [Roll] Nit: what is a 'datapath', 'data packet' - must all apps be modified to include Rank in HbH 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:41:32 -0000 On Jul 25, 2010, at 11:37 AM, Alexandru Petrescu wrote: > Le 25/07/2010 11:28, JP Vasseur a =E9crit : >> >> On Jul 25, 2010, at 11:23 AM, Alexandru Petrescu wrote: >> >>> Le 25/07/2010 10:44, JP Vasseur a =E9crit : >>>> >>>> On Jul 25, 2010, at 12:43 AM, Alexandru Petrescu wrote: >>>> >>>>> Nit: what is a datapath? The term appears in the title of a >>>>> section >>>>> >>>>>> 3.3.7. Datapath Validation and Loop Detection >>>>> >>>>> and it is not explained further. >>>>> >>>>> I understand path and data but the combination is not clear to >>>>> me. >>>>> >>>>> Because of this, this text reads strange: >>>>>> RPL uses a hop-by-hop IPv6 header to detect possible loops >>>>>> within a DODAG. Each data packet includes the Rank of the >>>>>> transmitter. >>>>> >>>>> What is a 'data packet'? >>>> >>>> An IPv6 packet carrying user data as opposed to a routing >>>> control message such as a DIS. >>>> >>>>> Do you mean I have to modify every application to include that >>>>> IPv6 header to insert new options? >>>>> >>>> >>>> Your application builds the IP packet and allows setting IPv6 >>>> header field (DS, ...), but also extended headers, ... >>>> >>>> In RPL, datapath validation and loop detection is performed by >>>> adding the RPL option defined in (draft-hui-6man-rpl-option-01) >>>> carried in the hop by hop header. This part will be more detailed >>>> in the next revision (see for example ticket 64) >>> >>> Who adds that option field? ("Each data packet includes the Rank of >>> the transmitter.") - the application or RPL? >> >> RPL ! The application does not know about the rank of course. > > RPL touches every data packet? I would oppose that. In some > exceptional cases - maybe, but not always. Let the app be end-to-end, > in most cases at least. > > You're mentioning a draft-hui about hbh - would RPL advance without =20= > that document adopted as WG item, progressed, etc. > The document has been approved as WG document in 6man. As you know the =20= publishing window will reopen very soon now. So you will see it as a WG ID soon. > Would the MEssage Authentication Code cover that HbH header? How? =20 > Which fields are initialized and which are computed first? Or would =20= > AH cover it? > Leave it for all your questions about security. JP. > Alex > >> >> JP. >> >>> >>> Alex >>> >>>> >>>> JP. >>>> >>>>> E.g. if I run http and TCP - do I have to modify the TCP stack >>>>> to include this Rank on each data packet? >>>>> >>>>> (Is it "Each" or "Some"?) >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> >> >> > From alexandru.petrescu@gmail.com Sun Jul 25 02:44:14 2010 Return-Path: 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 479FD3A6834 for ; Sun, 25 Jul 2010 02:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=-0.601, 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 aOmIUm6o5hK6 for ; Sun, 25 Jul 2010 02:44:13 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2AE3A67B2 for ; Sun, 25 Jul 2010 02:44:11 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 95B909400F9; Sun, 25 Jul 2010 11:44:26 +0200 (CEST) Message-ID: <4C4C0775.3040204@gmail.com> Date: Sun, 25 Jul 2010 11:44:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "David E. Culler" , JP Vasseur Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: [Roll] WG is a first class reviewer, not second 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:44:14 -0000 Chairs, With all due respect - I would like to express disappointment. I consider the WG as a first class reviewer, not second. I thought the DT was closed and discussion happened on the WG list exclusively. Spinning a private 11 version draft and asking for reviewing the public 10 draft is not kind to reviewer - it makes her/him waste a good amount of time. I copy the list to show that list is important. Alex From alexandru.petrescu@gmail.com Sun Jul 25 02:46:47 2010 Return-Path: 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 444EE3A67D7 for ; Sun, 25 Jul 2010 02:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=0.710, 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 JKe1fMo3JeDK for ; Sun, 25 Jul 2010 02:46:46 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 01A343A682E for ; Sun, 25 Jul 2010 02:46:44 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2785F940051; Sun, 25 Jul 2010 11:46:58 +0200 (CEST) Message-ID: <4C4C080E.6010307@gmail.com> Date: Sun, 25 Jul 2010 11:46:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <4C4B7359.6010109@gmail.com> <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> <4C4C04F1.2080407@gmail.com> <2DA850CF-D601-4966-946D-DC4D85E779C9@cisco.com> In-Reply-To: <2DA850CF-D601-4966-946D-DC4D85E779C9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:46:47 -0000 Le 25/07/2010 11:39, JP Vasseur a écrit : > > On Jul 25, 2010, at 11:33 AM, Alexandru Petrescu wrote: > >> Le 25/07/2010 11:27, JP Vasseur a écrit : >>> To explain "geediness" we have added an example (see below). >> [...] >>> Internet-Draft draft-ietf-roll-rpl-11 July 2010 >> >> 11? I thought it was 10? > > It is 10 right now. The author team has been working hard to > incorporate all the comments, ticket resolutions in the (to be > posted) revision 11. I gave you some new text that will be > incorporated to answer your question. > >> >> Am I looking at the right document? >> >> This is a moving target - I do not like to work that way, sorry. >> Please post drafts publicly and only then ask for review. >> >> Can't work this way: private documents, fuzzy authorship. >> >> It's a waste of time from my part. >> >> Yes, procedure is important. >> > > Alex, we are in WG LC. We have received a number of comments, open a > number of tickets, proposed solutions, ... this cannot be more > transparent. Resolution text are being worked out and I gave you > extracts. That's it. JP - thanks for explanation. This is a management problem. YOu have a 100 page document, 100wise tickets and a WG LC which you seem to want to solve in one IETF meeting. I think it is too much work... Yes, this is procedure, not technical, but without good procedure I can't talk technical. Alex > > JP. > >> Alex >> >>> >>> >>> parents. >>> >>> o Let Figure 3-1 be the initial condition. >>> >>> o Suppose Node (C) first is able to leave the DODAG and rejoin at >>> a lower rank, taking both Nodes (A) and (B) as DODAG parents as >>> depicted in Figure 3-2. Now Node (C) is deeper than both Nodes >>> (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. >>> >>> o Suppose Node (B), in its greediness, is willing to receive and >>> process a DIO message from Node (C) (against the rules of RPL), >>> and then Node (B) leaves the DODAG and rejoins at a lower rank, >>> taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is >>> deeper than both Nodes (A) and (C) and is satisfied with 2 DAG >>> parents. >>> >>> o Then Node (C), because it is also greedy, will leave and >>> rejoin deeper, to again get 2 parents and have a lower rank then >>> both of them. >>> >>> o Next Node (B) will again leave and rejoin deeper, to again get >>> 2 parents >>> >>> o And again Node (C) leaves and rejoins deeper... >>> >>> o The process will repeat, and the DODAG will oscillate between >>> Figure 3-2 and Figure 3-3 until the nodes count to infinity and >>> restart the cycle again. >>> >>> o This cycle can be averted through mechanisms in RPL: >>> >>> * Nodes (B) and (C) stay at a rank sufficient to attach to their >>> most preferred parent (A) and don't go for any deeper (worse) >>> alternate parents (Nodes are not greedy) >>> >>> * Nodes (B) and (C) do not process DIO messages from nodes >>> deeper than themselves (because such nodes are possibly in their >>> own sub-DODAGs) >>> >>> >>> >>> >>> >>> On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: >>> >>>>> Once a node has joined a DODAG version, RPL disallows >>>>> certain behaviors, including greediness, in order to prevent >>>>> resulting instabilities in the DODAG version. >>>> >>>> How? I searched for greed further down the text and it does not >>>> appear. >>>> >>>> This phrase sounds as if there is a bit set on/off called >>>> 'greed', or similar. >>>> >>>> I may be wrong. >>>> >>>>> It is for this reason that RPL limits the cases where a node >>>>> may process DIO messages from deeper nodes to some forms of >>>>> local repair. >>>> >>>> Which forms? >>>> >>>> 'local repair' procedure is mentioned several times in the >>>> draft: >>>> >>>>> On receiving such a packet, a node institutes a local repair >>>>> operation. >>>> [...] >>>>> Strict use of the DODAG Version Number can eliminate this >>>>> type of loop, but this type of loop may possibly be >>>>> encountered when using some local repair mechanisms. >>>>> >>>> [...] >>>>> MaxRankIncrease: 16-bit unsigned integer used to configure >>>>> DAGMaxRankIncrease, the allowable increase in rank in support >>>>> of local repair. >>>> [...] >>>>> o Trigger a local repair >>>> [...] >>>>> o Number of times a local repair procedure was triggered >>>> >>>> These are all the occurences of "local repair". It reads as an >>>> operation, mechanism, procedure. It is some form, some. >>>> >>>> But what is a local repair? >>>> >>>> Probably it is another term explained elsewhere that I can't >>>> find while searching in this draft, sorry if so. >>>> >>>> Alex _______________________________________________ Roll >>>> mailing list Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >> > > From L.Wood@surrey.ac.uk Sun Jul 25 02:50:23 2010 Return-Path: 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 A214C3A689E for ; Sun, 25 Jul 2010 02:50:23 -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=[AWL=0.000, 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 wtIi7aIjXFr2 for ; Sun, 25 Jul 2010 02:50:23 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 8FDCD3A6834 for ; Sun, 25 Jul 2010 02:50:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-3.tower-72.messagelabs.com!1280051442!9404324!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 18260 invoked from network); 25 Jul 2010 09:50:42 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-3.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2010 09:50:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sun, 25 Jul 2010 10:50:41 +0100 From: To: Date: Sun, 25 Jul 2010 10:50:41 +0100 Thread-Topic: [Roll] What is "meta-data"? Thread-Index: Acsr3tg6qJuWbeqgSsKWP2nxV0/xGw== Message-ID: References: <4C4B65F6.2060705@gmail.com> <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> <4C4BF49C.9080708@gmail.com> <2499913B-4A57-4452-9736-A930B963B4AD@surrey.ac.uk> <4C4C02E4.5060700@gmail.com> In-Reply-To: <4C4C02E4.5060700@gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:50:23 -0000 On 25 Jul 2010, at 10:24, Alexandru Petrescu wrote: >=20 > Metadata or meta-data? pe-dant or pedant? From alexandru.petrescu@gmail.com Sun Jul 25 02:51:45 2010 Return-Path: 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 311273A68F0 for ; Sun, 25 Jul 2010 02:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.697, 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 vbHnY9zdZ1yB for ; Sun, 25 Jul 2010 02:51:44 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 255B73A6783 for ; Sun, 25 Jul 2010 02:51:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 37C6394007F; Sun, 25 Jul 2010 11:51:56 +0200 (CEST) Message-ID: <4C4C0938.9080905@gmail.com> Date: Sun, 25 Jul 2010 11:51:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: L.Wood@surrey.ac.uk References: <4C4B65F6.2060705@gmail.com> <3BA36E6B-4A9B-4E39-808B-4A88641159A3@cisco.com> <4C4BF49C.9080708@gmail.com> <2499913B-4A57-4452-9736-A930B963B4AD@surrey.ac.uk> <4C4C02E4.5060700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100725-0, 25/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] What is "meta-data"? 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: , X-List-Received-Date: Sun, 25 Jul 2010 09:51:45 -0000 Le 25/07/2010 11:50, L.Wood@surrey.ac.uk a écrit : > > On 25 Jul 2010, at 10:24, Alexandru Petrescu wrote: >> >> Metadata or meta-data? > > pe-dant or pedant? Pedant. Alex > > > > From jpv@cisco.com Sun Jul 25 03:10:39 2010 Return-Path: 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 BDA553A6834 for ; Sun, 25 Jul 2010 03:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 U5v8np-RWU3o for ; Sun, 25 Jul 2010 03:10:37 -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 43A453A63D3 for ; Sun, 25 Jul 2010 03:10:36 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAurS0xAZnwN/2dsb2JhbACfXHGkDplJhTYEiGSCOg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208,217";a="138869294" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 10:10:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6PAAt7v017669; Sun, 25 Jul 2010 10:10:55 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 12:10:55 +0200 Received: from [192.168.1.11] ([10.55.91.19]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Jul 2010 12:10:54 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C4C080E.6010307@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-129--1049739975 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 12:10:54 +0200 References: <4C4B7359.6010109@gmail.com> <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> <4C4C04F1.2080407@gmail.com> <2DA850CF-D601-4966-946D-DC4D85E779C9@cisco.com> <4C4C080E.6010307@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 25 Jul 2010 10:10:54.0926 (UTC) FILETIME=[AB2696E0:01CB2BE1] Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Sun, 25 Jul 2010 10:10:40 -0000 --Apple-Mail-129--1049739975 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 25, 2010, at 11:46 AM, Alexandru Petrescu wrote: > Le 25/07/2010 11:39, JP Vasseur a =E9crit : >> >> On Jul 25, 2010, at 11:33 AM, Alexandru Petrescu wrote: >> >>> Le 25/07/2010 11:27, JP Vasseur a =E9crit : >>>> To explain "geediness" we have added an example (see below). >>> [...] >>>> Internet-Draft draft-ietf-roll-rpl-11 July 2010 >>> >>> 11? I thought it was 10? >> >> It is 10 right now. The author team has been working hard to >> incorporate all the comments, ticket resolutions in the (to be >> posted) revision 11. I gave you some new text that will be >> incorporated to answer your question. >> >>> >>> Am I looking at the right document? >>> >>> This is a moving target - I do not like to work that way, sorry. >>> Please post drafts publicly and only then ask for review. >>> >>> Can't work this way: private documents, fuzzy authorship. >>> >>> It's a waste of time from my part. >>> >>> Yes, procedure is important. >>> >> >> Alex, we are in WG LC. We have received a number of comments, open a >> number of tickets, proposed solutions, ... this cannot be more >> transparent. Resolution text are being worked out and I gave you >> extracts. That's it. > > JP - thanks for explanation. This is a management problem. YOu =20 > have a 100 page document, 100wise tickets and a WG LC which you seem =20= > to want to solve in one IETF meeting. I think it is too much work... Last email on the subject matter from my side. David may want to chime =20= in as document shepherd. If you carefully look at the mailing list, you will find out that a =20 number of people provided comments that helped to collectively build RPL. You are referring to the 100wise tickets =20 (actually 73), that were opened and a 100 page document to solve in one IETF. I have no idea of why you are =20 referring to "Solving in one IETF meeting". The first ticket was opened 1 year ago, we have 3 IETF meetings and =20 two interim meetings. Tickets have been discussed, solved and closed on the mailing in total transparency. I'll stop there. David may want to say a few words too. JP. > > Yes, this is procedure, not technical, but without good procedure I =20= > can't talk technical. > > Alex > >> >> JP. >> >>> Alex >>> >>>> >>>> >>>> parents. >>>> >>>> o Let Figure 3-1 be the initial condition. >>>> >>>> o Suppose Node (C) first is able to leave the DODAG and rejoin at >>>> a lower rank, taking both Nodes (A) and (B) as DODAG parents as >>>> depicted in Figure 3-2. Now Node (C) is deeper than both Nodes >>>> (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. >>>> >>>> o Suppose Node (B), in its greediness, is willing to receive and >>>> process a DIO message from Node (C) (against the rules of RPL), >>>> and then Node (B) leaves the DODAG and rejoins at a lower rank, >>>> taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is >>>> deeper than both Nodes (A) and (C) and is satisfied with 2 DAG >>>> parents. >>>> >>>> o Then Node (C), because it is also greedy, will leave and >>>> rejoin deeper, to again get 2 parents and have a lower rank then >>>> both of them. >>>> >>>> o Next Node (B) will again leave and rejoin deeper, to again get >>>> 2 parents >>>> >>>> o And again Node (C) leaves and rejoins deeper... >>>> >>>> o The process will repeat, and the DODAG will oscillate between >>>> Figure 3-2 and Figure 3-3 until the nodes count to infinity and >>>> restart the cycle again. >>>> >>>> o This cycle can be averted through mechanisms in RPL: >>>> >>>> * Nodes (B) and (C) stay at a rank sufficient to attach to their >>>> most preferred parent (A) and don't go for any deeper (worse) >>>> alternate parents (Nodes are not greedy) >>>> >>>> * Nodes (B) and (C) do not process DIO messages from nodes >>>> deeper than themselves (because such nodes are possibly in their >>>> own sub-DODAGs) >>>> >>>> >>>> >>>> >>>> >>>> On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: >>>> >>>>>> Once a node has joined a DODAG version, RPL disallows >>>>>> certain behaviors, including greediness, in order to prevent >>>>>> resulting instabilities in the DODAG version. >>>>> >>>>> How? I searched for greed further down the text and it does not >>>>> appear. >>>>> >>>>> This phrase sounds as if there is a bit set on/off called >>>>> 'greed', or similar. >>>>> >>>>> I may be wrong. >>>>> >>>>>> It is for this reason that RPL limits the cases where a node >>>>>> may process DIO messages from deeper nodes to some forms of >>>>>> local repair. >>>>> >>>>> Which forms? >>>>> >>>>> 'local repair' procedure is mentioned several times in the >>>>> draft: >>>>> >>>>>> On receiving such a packet, a node institutes a local repair >>>>>> operation. >>>>> [...] >>>>>> Strict use of the DODAG Version Number can eliminate this >>>>>> type of loop, but this type of loop may possibly be >>>>>> encountered when using some local repair mechanisms. >>>>>> >>>>> [...] >>>>>> MaxRankIncrease: 16-bit unsigned integer used to configure >>>>>> DAGMaxRankIncrease, the allowable increase in rank in support >>>>>> of local repair. >>>>> [...] >>>>>> o Trigger a local repair >>>>> [...] >>>>>> o Number of times a local repair procedure was triggered >>>>> >>>>> These are all the occurences of "local repair". It reads as an >>>>> operation, mechanism, procedure. It is some form, some. >>>>> >>>>> But what is a local repair? >>>>> >>>>> Probably it is another term explained elsewhere that I can't >>>>> find while searching in this draft, sorry if so. >>>>> >>>>> Alex _______________________________________________ Roll >>>>> mailing list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> >> >> > --Apple-Mail-129--1049739975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Jul 25, 2010, = at 11:46 AM, Alexandru Petrescu wrote:

Le = 25/07/2010 11:39, JP Vasseur a =E9crit :

On Jul 25, = 2010, at 11:33 AM, Alexandru Petrescu wrote:

Le 25/07/2010 11:27, JP Vasseur a =E9crit = :
To explain "geediness" we have = added an example (see = below).
[...]
Internet-Draft draft-ietf-roll-rpl-11 July = 2010

11? I thought it was = 10?

It is 10 right = now. The author team has been working hard = to
incorporate all the = comments, ticket resolutions in the (to be
posted) revision 11. I gave you some new text that will = be
incorporated to answer your = question.


Am I looking at the right = document?

This is a moving target - I do = not like to work that way, = sorry.
Please post drafts publicly and only then ask for = review.

Can't work this way: private = documents, fuzzy authorship.

It's a waste of time from my = part.

Yes, procedure is = important.


Alex, we are in = WG LC. We have received a number of comments, open = a
number of tickets, proposed = solutions, ... this cannot be more
transparent. Resolution text are being worked out and I = gave you
extracts. That's = it.

JP - thanks for explanation.  This is a = management problem.  YOu have a 100 page document, 100wise tickets = and a WG LC which you seem to want to  solve in one IETF meeting. =  I think it is too much = work...

Last email on the = subject matter from my side. David may want to chime in as document = shepherd. 
If you carefully look at the mailing list, you = will find out that a number of people provided comments that = helped
to collectively build RPL. You are referring to = the 100wise tickets (actually 73), that were opened and a = 100
page document to solve in one IETF. I have no idea = of why you are referring to "Solving in one IETF meeting".
The = first ticket was opened 1 year ago, we have 3 IETF meetings and two = interim meetings. Tickets have been
discussed, solved and = closed on the mailing in total = transparency. 

I'll stop there. David may = want to say a few words = too.

JP.


Yes, this is procedure, not technical, but = without good procedure I can't talk = technical.

Alex


JP.

Alex



parents.

o Let = Figure 3-1 be the initial = condition.

o = Suppose Node (C) first is able to leave the DODAG and rejoin = at
a = lower rank, taking both Nodes (A) and (B) as DODAG parents = as
depicted= in Figure 3-2. Now Node (C) is deeper than both = Nodes
(A) = and (B), and Node (C) is satisfied to have 2 DODAG = parents.

o = Suppose Node (B), in its greediness, is willing to receive = and
process = a DIO message from Node (C) (against the rules of = RPL),
and = then Node (B) leaves the DODAG and rejoins at a lower = rank,
taking = both Nodes (A) and (C) as DODAG parents. Now Node (B) = is
deeper = than both Nodes (A) and (C) and is satisfied with 2 = DAG
parents.

o Then = Node (C), because it is also greedy, will leave = and
rejoin = deeper, to again get 2 parents and have a lower rank = then
both = of them.

o Next = Node (B) will again leave and rejoin deeper, to again = get
2 = parents

o And = again Node (C) leaves and rejoins = deeper...

o The = process will repeat, and the DODAG will oscillate = between
Figure = 3-2 and Figure 3-3 until the nodes count to infinity = and
restart = the cycle again.

o This = cycle can be averted through mechanisms in = RPL:

* = Nodes (B) and (C) stay at a rank sufficient to attach to = their
most = preferred parent (A) and don't go for any deeper = (worse)
alternate parents (Nodes are not = greedy)

* = Nodes (B) and (C) do not process DIO messages from = nodes
deeper = than themselves (because such nodes are possibly in = their
own = sub-DODAGs)





On Jul = 25, 2010, at 1:12 AM, Alexandru Petrescu = wrote:

Once a = node has joined a DODAG version, RPL = disallows
certain = behaviors, including greediness, in order to = prevent
resulting instabilities in the DODAG = version.

How? I searched for greed = further down the text and it does = not
appear.

This phrase sounds as if there = is a bit set on/off = called
'greed', or = similar.

I may be = wrong.

It is = for this reason that RPL limits the cases where a = node
<= blockquote type=3D"cite">
may = process DIO messages from deeper nodes to some forms = of
local = repair.

Which = forms?

'local repair' procedure is = mentioned several times in = the
draft:

On = receiving such a packet, a node institutes a local = repair
operation.
[...]
Strict = use of the DODAG Version Number can eliminate = this
<= blockquote type=3D"cite">
type = of loop, but this type of loop may possibly = be
encountered when using some local repair = mechanisms.

[...]
MaxRankIncrease: 16-bit unsigned integer used to = configure
DAGMaxRankIncrease, the allowable increase in rank in = support
of = local = repair.
[...]
o = Trigger a local = repair
[...]
o = Number of times a local repair procedure was = triggered

These are all the occurences of = "local repair". It reads as = an
operation, mechanism, procedure. = It is some form, = some.

But what is a local = repair?

Probably it is another term = explained elsewhere that I = can't
find while searching in this = draft, sorry if = so.

Alex = _______________________________________________ = Roll
mailing list Roll@ietf.org = <mailto:Roll@ietf.org>
https://www.ietf.org/m= ailman/listinfo/roll






= --Apple-Mail-129--1049739975-- From pal@cs.stanford.edu Sun Jul 25 12:38:30 2010 Return-Path: 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 5DE1C3A68B7 for ; Sun, 25 Jul 2010 12:38:30 -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 lUzGrGo6XaLa for ; Sun, 25 Jul 2010 12:38:29 -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 7FA6D3A6937 for ; Sun, 25 Jul 2010 12:38:29 -0700 (PDT) Received: from [87.213.214.66] (helo=[192.168.1.77]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Od729-0001Nw-8Y; Sun, 25 Jul 2010 12:38:49 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C4AB311.2000907@gmail.com> Date: Sun, 25 Jul 2010 12:37:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DD46A9A-FA39-46BA-BC28-391893EE97F8@cs.stanford.edu> References: <6427.1278635611@marajade.sandelman.ca> <39D6B8E1-CD63-489E-97E3-A43407ED92C8@cs.stanford.edu> <4C37690B.50608@gmail.com> <4C4AB311.2000907@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: roll@ietf.org Subject: Re: [Roll] unsigned integer MUST be at least 6 octets long? 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: , X-List-Received-Date: Sun, 25 Jul 2010 19:38:30 -0000 On Jul 24, 2010, at 2:32 AM, Alexandru Petrescu wrote: > Has this nit been solved somehow? Are there any opinions or reasons = to > ignore this nit? >=20 > The nit is the draft to wrongly consider an unsigned integer at least = 6 > octet long, because this makes impossible to use unsigned integers 4 > octet longs (which are a default on many platforms). >=20 The assumption is that you use an unsigned long long (uint64_t). If for = very tight RAM reasons you don't want to allocate 8 bytes, 6 is = sufficient. I would assume that most simple implementations just use = ULL. Making protocol decisions for "int" seems like a poor idea, given = its non-portable nature. It's worthwhile noting that many LLN platforms = (e.g., microcontrollers) have 2 octet, not 4 octet, "int" values. A = common mistake novice programmers make in this domain. :) Using 4 bytes is not technically feasible due to the timescales = required. A 32-bit counter with millsecond granularity wraps around = after approximately 50 days. We would like networks to last longer than = 50 days and be protected from replay as well as delay attacks. Again, I = feel that your concerns are ignoring the actual technical problem which = the protocol is trying to solve.=20 Phil=20 From pal@cs.stanford.edu Sun Jul 25 12:52:42 2010 Return-Path: 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 86DB63A6839 for ; Sun, 25 Jul 2010 12:52:42 -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 jGxFwnb+IqYi for ; Sun, 25 Jul 2010 12:52:41 -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 8732D3A6835 for ; Sun, 25 Jul 2010 12:52:41 -0700 (PDT) Received: from [87.213.214.66] (helo=[192.168.1.77]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Od7Ft-000278-7v; Sun, 25 Jul 2010 12:53:02 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Philip Levis In-Reply-To: <4C4B647A.1080408@gmail.com> Date: Sun, 25 Jul 2010 12:53:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9EDFAAAA-7F19-488A-8574-B5E6A722858F@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> <4C4B647A.1080408@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: f824399eb00b5943f8bdbe5dd24fccda Cc: roll@ietf.org Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Sun, 25 Jul 2010 19:52:42 -0000 On Jul 24, 2010, at 3:08 PM, Alexandru Petrescu wrote: >>=20 >> 3.3.3. Security >>=20 >> RPL supports message confidentiality and integrity. It is designed >> such that link-layer mechanisms can be used when available and >> appropriate, yet in their absence RPL can use its own mechanisms. >> RPL has three basic security modes. >=20 > But earlier the draft says: >=20 >> In compliance with the layered architecture of IP, RPL does not rely >> on any particular features of a specific link layer technology. >=20 > which I interpret as saying RPL does not use any feature from the link > layer (e.g. security). Rely and use have distinct meanings. =46rom the OED: rely verb ( -lies, -lied) [ intrans. ] ( rely on/upon) depend on with full trust or confidence : I know I can rely on your = discretion. =E2=80=A2 be dependent on : the charity has to rely entirely on public = donations. use verb=20 1 |yo=C5=8Dz| [ trans. ] take, hold, or deploy (something) as a means = of accomplishing a purpose or achieving a result; employ : she used her = key to open the front door | the poem uses simple language. =E2=80=A2 take or consume (an amount) from a limited supply of something = : we have used all the available funds. =E2=80=A2 exploit (a person or situation) for one's own advantage : I = couldn't help feeling that she was using me. RPL does not *rely* on particular link layer technologies: it does not = depend on them, and can, in this context, meet its security requirements = without link layer security mechanisms.=20 However, a given RPL application can *use* security capabilities of the = link layer (or other layers), if they are available, instead of RPL's = security mechanisms, if doing so is advantageous to meeting application = requirements.=20 As a trivial example, let's suppose there is a RPL application that = needs message integrity, and the link layer provides sufficient = integrity guarantees to meet the application requirements. RPL allows = the application developer to use the link layer mechanisms, rather than = force the RPL Instance to employ RPL-level integrity. Does that make = sense? Recall, many RPL applications are closed networks under a single = administrative domain. >=20 > I think these two paragraphs sound contradictory(?) >=20 >=20 Does this clear it up? Phil From ulrich@herberg.name Sun Jul 25 13:34:20 2010 Return-Path: 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 65E713A67C3 for ; Sun, 25 Jul 2010 13:32:06 -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=[AWL=0.000, 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 FKVX-0Rr6eJu for ; Sun, 25 Jul 2010 13:31:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5803E3A69BF for ; Sun, 25 Jul 2010 13:30:22 -0700 (PDT) Received: by bwz7 with SMTP id 7so2962574bwz.31 for ; Sun, 25 Jul 2010 13:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.80.162 with SMTP id t34mr4936064bkk.81.1280089841757; Sun, 25 Jul 2010 13:30:41 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Sun, 25 Jul 2010 13:30:41 -0700 (PDT) In-Reply-To: <80AF40A5-E114-4F27-882A-8BD91EFEF0D0@cs.stanford.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <88EE7D24-3E84-46D6-9684-6D2A1E4F32FE@cs.berkeley.edu> <80AF40A5-E114-4F27-882A-8BD91EFEF0D0@cs.stanford.edu> Date: Sun, 25 Jul 2010 22:30:41 +0200 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG , seclln@external.cisco.com Subject: Re: [Roll] Signature schemes and IPR in RPL 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: , X-List-Received-Date: Sun, 25 Jul 2010 20:34:25 -0000 On Sat, Jul 24, 2010 at 3:06 PM, Philip Levis wrote: >[...] > > Ulrich, > > I fully agree as well. It turns out that such algorithms which are unencu= mbered by IPR are not *that* easy to find, however. I consulted with my res= ident cryptographic expert, Dan Boneh[1]. He suggested an algorithm which h= e developed in 2001 or so, based on the Weil pairing[2], which is completel= y open and has no encumbering IPR. At first glance, it seems to possibly be= technically superior than the Certicom-encumbered one in terms of factors = we care about (e.g., signature length), which was already very attractive. = There are reference implementations[3], and the FAA is beginning to incorpo= rate it into some of their systems. The security DT is currently examining = the algorithm. I hope to give an update soon. > > Phil > > [1] http://crypto.stanford.edu/ > [2] http://crypto.stanford.edu/~dabo/pubs/abstracts/weilsigs.html > [3] http://crypto.stanford.edu/pbc/ Phil, thanks for these references. That sounds like an interesting alternative to the Certicom-encumbered algorithm. Are you aware how this algorithm would perform on typical devices which are intended to run RPL? Ulrich From yoav@yitran.com Sun Jul 25 13:37:47 2010 Return-Path: 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 419943A6842 for ; Sun, 25 Jul 2010 13:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=-1.777, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, 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 y+5Orzz0EHMq for ; Sun, 25 Jul 2010 13:37:46 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id DF5293A69B1 for ; Sun, 25 Jul 2010 13:37:01 -0700 (PDT) Received: from source ([209.85.216.182]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTEygeYaow8uilxovlL1KnqyNsy09Z/jz@postini.com; Sun, 25 Jul 2010 13:37:24 PDT Received: by mail-qy0-f182.google.com with SMTP id 32so1716198qyk.6 for ; Sun, 25 Jul 2010 13:37:13 -0700 (PDT) Received: by 10.224.115.163 with SMTP id i35mr626750qaq.80.1280090232976; Sun, 25 Jul 2010 13:37:12 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcssOShi5e95NyCARWaTJ6qf6Oje9g== Date: Sun, 25 Jul 2010 23:37:11 +0300 Message-ID: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> To: roll@ietf.org Content-Type: multipart/alternative; boundary=000feaeba9249df924048c3c3b39 Subject: [Roll] question on gain control 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: , X-List-Received-Date: Sun, 25 Jul 2010 20:37:47 -0000 --000feaeba9249df924048c3c3b39 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I would like to probe the WG=92s opinion on the issue of transmission at different transmission gains to obtain more reliability on the link quality= . For example, somehow indicating the transmission power level on DIS/DIO/DAO (maybe by percent of or db less than maximum transmission level) to make sure that metrics are calculated/parents are selected, etc. only based on transmissions received with low transmission gains. We=92ve used this to make our topologies more stable in proprietary solutio= ns. The motivation is to have sufficient level of margin for noise before messages at high gain will not be received properly (i.e. if messages are received at 6dB less than the maximum transmission gain, there=92s room for= at least 6 dB more noise before the messages will not be received =96 6 dB is = a lot of margin, so topologies remain very stable with this kind of margin). I believe that such an option used by the RPL would bring benefit, and mayb= e belong to one of the RPL drafts (i.e. metric, OF, other?). Would this something the RPL WG would consider to add? Your inputs would be greatly appreciated. Regards, Yoav --000feaeba9249df924048c3c3b39 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

I would like to probe the WG=92s opinion on the issu= e of transmission at different transmission gains to obtain more reliability on the link qual= ity.

=A0

For example, somehow indicating the transmission pow= er level on DIS/DIO/DAO (maybe by percent of or db less than maximum transmission le= vel) to make sure that metrics are calculated/parents are selected, etc. only ba= sed on transmissions received with low transmission gains.

=A0

We=92ve used this to make our topologies more stable= in proprietary solutions. The motivation is to have sufficient level of margin= for noise before messages at high gain will not be received properly (i.e. if m= essages are received at 6dB less than the maximum transmission gain, there=92s room= for at least 6 dB more noise before the messages will not be received =96 6 dB = is a lot of margin, so topologies remain very stable with this kind of margin).<= /p>

=A0

I believe that such an option used by the RPL would = bring benefit, and maybe belong to one of the RPL drafts (i.e. metric, OF, other?= ).

=A0

Would this something the RPL WG would consider to ad= d?

=A0

Your inputs would be greatly appreciated.

=A0

Regards,

Yoav

=A0

=A0

=A0

--000feaeba9249df924048c3c3b39-- From yoav@yitran.com Sun Jul 25 13:40:33 2010 Return-Path: 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 389F33A684E for ; Sun, 25 Jul 2010 13:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 v1DhwaTyhuKb for ; Sun, 25 Jul 2010 13:40:32 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 369C93A67C0 for ; Sun, 25 Jul 2010 13:40:29 -0700 (PDT) Received: from source ([209.85.216.176]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTEyhUdYFyIe1XO9AvBvCu/tEmR/mDSmK@postini.com; Sun, 25 Jul 2010 13:40:52 PDT Received: by mail-qy0-f176.google.com with SMTP id 34so2000783qyk.14 for ; Sun, 25 Jul 2010 13:40:49 -0700 (PDT) Received: by 10.224.93.130 with SMTP id v2mr5222802qam.253.1280090448986; Sun, 25 Jul 2010 13:40:48 -0700 (PDT) From: Yoav Ben-Yehezkel References: 2c24b2655735dd40afffafac5a0db04d@mail.gmail.com In-Reply-To: 2c24b2655735dd40afffafac5a0db04d@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcssOShi5e95NyCARWaTJ6qf6Oje9gAAD2LQ Date: Sun, 25 Jul 2010 23:40:47 +0300 Message-ID: To: Yoav Ben-Yehezkel , roll@ietf.org Content-Type: multipart/alternative; boundary=000feaf148617e0723048c3c4870 Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Sun, 25 Jul 2010 20:40:33 -0000 --000feaf148617e0723048c3c4870 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One clarification =96 Selection processes are with the transmission gain margin (lower transmission power). Maintenance processes are without the margin (higher and possibly maximal transmission power). So, after selection there=92s margin reliability on the link for the maintenance processes. Thanks, Yoav *From:* Yoav Ben-Yehezkel [mailto:yoav@yitran.com] *Sent:* Sunday, July 25, 2010 11:37 PM *To:* 'roll@ietf.org' *Subject:* question on gain control Hi, I would like to probe the WG=92s opinion on the issue of transmission at different transmission gains to obtain more reliability on the link quality= . For example, somehow indicating the transmission power level on DIS/DIO/DAO (maybe by percent of or db less than maximum transmission level) to make sure that metrics are calculated/parents are selected, etc. only based on transmissions received with low transmission gains. We=92ve used this to make our topologies more stable in proprietary solutio= ns. The motivation is to have sufficient level of margin for noise before messages at high gain will not be received properly (i.e. if messages are received at 6dB less than the maximum transmission gain, there=92s room for= at least 6 dB more noise before the messages will not be received =96 6 dB is = a lot of margin, so topologies remain very stable with this kind of margin). I believe that such an option used by the RPL would bring benefit, and mayb= e belong to one of the RPL drafts (i.e. metric, OF, other?). Would this something the RPL WG would consider to add? Your inputs would be greatly appreciated. Regards, Yoav --000feaf148617e0723048c3c4870 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

One clarification =96 =

Selection processes ar= e with the transmission gain margin (lower transmission power).

Maintenance processes = are without the margin (higher and possibly maximal transmission power).

So, after selection th= ere=92s margin reliability on the link for the maintenance processes.

=A0

Thanks,

Yoav

=A0

=A0

=A0

From: Yoav Ben= -Yehezkel [mailto:yoav@yitran.com]
Sent: Sunday, July 25, 2010 11:37 PM
To: 'roll@ietf.org'
Subject: question on gain control

=A0

Hi,

=A0

I would like to probe the WG=92s opinion on the issu= e of transmission at different transmission gains to obtain more reliability on = the link quality.

=A0

For example, somehow indicating the transmission pow= er level on DIS/DIO/DAO (maybe by percent of or db less than maximum transmission le= vel) to make sure that metrics are calculated/parents are selected, etc. only ba= sed on transmissions received with low transmission gains.

=A0

We=92ve used this to make our topologies more stable= in proprietary solutions. The motivation is to have sufficient level of margin= for noise before messages at high gain will not be received properly (i.e. if messages are received at 6dB less than the maximum transmission gain, there= =92s room for at least 6 dB more noise before the messages will not be received = =96 6 dB is a lot of margin, so topologies remain very stable with this kind of margin).

=A0

I believe that such an option used by the RPL would = bring benefit, and maybe belong to one of the RPL drafts (i.e. metric, OF, other?).

=A0

Would this something the RPL WG would consider to ad= d?

=A0

Your inputs would be greatly appreciated.

=A0

Regards,

Yoav

=A0

=A0

=A0

--000feaf148617e0723048c3c4870-- From dominique.barthel@orange-ftgroup.com Mon Jul 26 00:47:19 2010 Return-Path: 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 E935F3A6A51 for ; Mon, 26 Jul 2010 00:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 0wIuyLZBtfgQ for ; Mon, 26 Jul 2010 00:47:18 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id A71BC3A6A4F for ; Mon, 26 Jul 2010 00:47:11 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B2C73760005 for ; Mon, 26 Jul 2010 09:49:47 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 08B91760008 for ; Mon, 26 Jul 2010 09:49:43 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:47:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2C96.CA75DC50" Date: Mon, 26 Jul 2010 09:46:21 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF017516DB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Route-tags - Soliciting WG comments Thread-Index: AcsqPmW81aCCBHFeS1+quKsbC0N58gCV+QMg References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> From: To: X-OriginalArrivalTime: 26 Jul 2010 07:47:27.0247 (UTC) FILETIME=[CAFCC1F0:01CB2C96] Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Mon, 26 Jul 2010 07:47:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2C96.CA75DC50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support 1). This doesn't add complexity now and I trust it will prove useful later. Dominique ________________________________ De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = JP Vasseur Envoy=E9 : vendredi 23 juillet 2010 10:09 =C0 : roll WG Objet : [Roll] Route-tags - Soliciting WG comments Dear all,=20 This is one of the comments that I send last week (ticket 70). We had a = discussion with the RPL authors yesterday (as pretty much every week) to = continue our work on the remaining open tickets (making great progress). = Let me simply explain why "route-tags" may be important to have in the = core spec. First of all, I'd like to clarify that we are not discussing = about using tags/labels for forwarding (we will at some point !) so I'll = start using the terms prefix-color to avoid ambiguity. We had the = concept of route-color (called route-tags) up to revision -7, at which = point we revisited the whole DAO format and it went away. Why is it used for ? Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that = is used to mark a route. For example, this could be used to flag = important versus less-critical prefix. This has proven to be useful in a = number of other routing protocols but to give two examples: this can be = used to prioritize prefix installation during DODAG rebuilt to increase = the "convergence" time and restore connectivity faster for critical = prefixes, it could also be used in case of memory overflow to preferably = keep the important prefix, ...=20 Complexity ? Nothing more than an option carried in a DAO message that could look = like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | 2 | Flags = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We just need to add one sentence in the Manageability Section. We could either defer it to another ID or add it now. Personally I am = leaning toward adding it back, considering how simple it is and the = benefits this can bring. Could you let us know whether you think that we should add it to the = core spec: 1) Yes 2) No. Thanks. JP. ------_=_NextPart_001_01CB2C96.CA75DC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I support 1).
This doesn't add complexity now and I trust = it will prove=20 useful later.
Dominique

De : roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] De la part de JP=20 Vasseur
Envoy=E9 : vendredi 23 juillet 2010=20 10:09
=C0 : roll WG
Objet : [Roll] = Route-tags -=20 Soliciting WG comments

Dear all,

This is one of the comments that I send last week (ticket 70). We = had a=20 discussion with the RPL authors yesterday (as pretty much every week) to = continue our work on the remaining open tickets (making great progress). = Let me=20 simply explain why "route-tags" may be important to have in the core = spec. First=20 of all, I'd like to clarify that we are not discussing about using = tags/labels=20 for forwarding (we will at some point !) so I'll start using the terms=20 prefix-color to avoid ambiguity. We had the concept of route-color = (called=20 route-tags) up to revision -7, at which point we revisited the whole DAO = format=20 and it went away.

Why is it used for ?

Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), = that is=20 used to mark a route. For example, this could be used to flag important = versus=20 less-critical prefix. This has proven to be useful in a number of other = routing=20 protocols but to give two examples: this can be used to prioritize = prefix=20 installation during DODAG rebuilt to increase the "convergence" time and = restore=20 connectivity faster for critical prefixes, it could also be used in case = of=20 memory overflow to preferably keep the important prefix, ... 

Complexity ?

Nothing more than an option carried in a DAO message that could = look like=20 this:

 0                   1                   2       =
            3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type =3D 8    |       2       |              Flags            =
|
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We just need to add one sentence in the Manageability = Section.

We could either defer it to another ID or add it now. Personally I = am=20 leaning toward adding it back, considering how simple it is and the = benefits=20 this can bring.

Could you let us know whether you think that we should add it to = the core=20 spec:

1) Yes
2) No.

Thanks.

JP.
------_=_NextPart_001_01CB2C96.CA75DC50-- From jpv@cisco.com Mon Jul 26 00:49:34 2010 Return-Path: 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 0BED63A683A for ; Mon, 26 Jul 2010 00:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 vRkWSxp9r81v for ; Mon, 26 Jul 2010 00:49:33 -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 9C07A3A67AE for ; Mon, 26 Jul 2010 00:49:32 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAI/aTExAZnwN/2dsb2JhbACBRJ4ccaR2mgKFNgSIZII6 X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208,217";a="139118805" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 07:49:42 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q7nf1L003937; Mon, 26 Jul 2010 07:49:42 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 09:49:29 +0200 Received: from dhcp-60f4.meeting.ietf.org ([10.61.87.222]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 09:49:29 +0200 Message-Id: <33197130-0CAC-4FAE-9A6B-3509E5FEDA5E@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-19--971825440 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 09:49:28 +0200 References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jul 2010 07:49:29.0543 (UTC) FILETIME=[13E1A570:01CB2C97] Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Mon, 26 Jul 2010 07:49:34 -0000 --Apple-Mail-19--971825440 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Yoav, I would fully support this. It would go in the metric-ID (or separate =20= ID, but this is a metric discussion item for sure) but let's wait for =20= the WG feed-back to see what they think. Cheers. JP. On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel wrote: > Hi, > > I would like to probe the WG=92s opinion on the issue of transmission =20= > at different transmission gains to obtain more reliability on the =20 > link quality. > > For example, somehow indicating the transmission power level on DIS/=20= > DIO/DAO (maybe by percent of or db less than maximum transmission =20 > level) to make sure that metrics are calculated/parents are =20 > selected, etc. only based on transmissions received with low =20 > transmission gains. > > We=92ve used this to make our topologies more stable in proprietary =20= > solutions. The motivation is to have sufficient level of margin for =20= > noise before messages at high gain will not be received properly =20 > (i.e. if messages are received at 6dB less than the maximum =20 > transmission gain, there=92s room for at least 6 dB more noise before =20= > the messages will not be received =96 6 dB is a lot of margin, so =20 > topologies remain very stable with this kind of margin). > > I believe that such an option used by the RPL would bring benefit, =20 > and maybe belong to one of the RPL drafts (i.e. metric, OF, other?). > > Would this something the RPL WG would consider to add? > > Your inputs would be greatly appreciated. > > Regards, > Yoav > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-19--971825440 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Yoav,

I = would fully support this. It would go in the metric-ID (or separate ID, = but this is a metric discussion item for sure) but let's wait for the WG = feed-back to see what they = think.

Cheers.

JP.
=

On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel = wrote:

Hi,

I would like to probe the WG=92s opinion on the = issue of transmission at different transmission gains to obtain more = reliability on the link quality.

For example, somehow indicating the transmission = power level on DIS/DIO/DAO (maybe by percent of or db less than maximum = transmission level) to make sure that metrics are calculated/parents are = selected, etc. only based on transmissions received with low = transmission gains.

 

I believe that such an option used by the RPL = would bring benefit, and maybe belong to one of the RPL drafts (i.e. = metric, OF, other?).

 

 

Your inputs would be greatly = appreciated.

 

Yoav

 

Roll@ietf.org

Hi,

=A0

I found a small editorial fix in the description of = =93Option Length=94 field in the SIO description.

=A0

Right now the description says Option Length 19 byte= s, which I think little misleading. If I understand correctly, it should be saying t= hat the length of the field is 1 byte and its value shall be set to 19, right?<= /p>

=A0

Regards,

Yoav

=A0

=A0

5.7.9.=A0 Solicited Information

=A0

...

=A0

=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A03

=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0 Type =3D 7=A0=A0=A0 | Option Length | RPLInstanceID |V|I|D|=A0 Rsvd= =A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0|

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 DODAGID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 Version=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 22: Format of the Solicited Information Option

...

=A0

=A0=A0 Option Length:=A0 19 bytes

=A0

--000feaf07cef0b70e9048c460a23-- From yoav@yitran.com Mon Jul 26 01:30:32 2010 Return-Path: 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 A52613A6AA8 for ; Mon, 26 Jul 2010 01:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 VFmmgPtmbk05 for ; Mon, 26 Jul 2010 01:30:16 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id EC9713A687D for ; Mon, 26 Jul 2010 01:30:12 -0700 (PDT) Received: from source ([209.85.216.49]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTE1HqQFILv8tgBcO5OZaHm4DVHGCIXho@postini.com; Mon, 26 Jul 2010 01:30:36 PDT Received: by mail-qw0-f49.google.com with SMTP id 4so5133670qwe.8 for ; Mon, 26 Jul 2010 01:30:32 -0700 (PDT) Received: by 10.224.88.70 with SMTP id z6mr5898355qal.23.1280133032503; Mon, 26 Jul 2010 01:30:32 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF017516DB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF017516DB@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsqPmW81aCCBHFeS1+quKsbC0N58gCV+QMgAAFNyoA= Date: Mon, 26 Jul 2010 11:30:25 +0300 Message-ID: To: dominique.barthel@orange-ftgroup.com, roll@ietf.org Content-Type: multipart/alternative; boundary=00c09f97243aab1d07048c463202 Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Mon, 26 Jul 2010 08:30:33 -0000 --00c09f97243aab1d07048c463202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My only concern with this approach is that other =93prf=94 fields were no m= ore than 2/3 bits long, and defined a preference value (with upper and lower limits for comparison), the below approach is based on flags and much more than 2/3 bits. >From my understanding of the below explanation, it seems to me as if the purpose of the below text and the =93prf=94 fields are the same (prioritization). Flags is more flexible than value, but also require more processing. My questions/concerns: 1. Can we use the same approach in all places (prf) =96 due to the fa= ct that this can lead to simpler (common) coding for processing of the prioritization fields? 2. Is the proposed length acceptable and commonly used (seems much more than in other places)? I=92m not familiar with this concept =96 so I apologize in advance in case = I am missing the point completely and the purpose of this option is different than the =93Prf=94 fields in other places. Regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = * dominique.barthel@orange-ftgroup.com *Sent:* Monday, July 26, 2010 10:46 AM *To:* roll@ietf.org *Subject:* Re: [Roll] Route-tags - Soliciting WG comments I support 1). This doesn't add complexity now and I trust it will prove useful later. Dominique ------------------------------ *De :* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *De la part de*JP Vasseur *Envoy=E9 :* vendredi 23 juillet 2010 10:09 *=C0 :* roll WG *Objet :* [Roll] Route-tags - Soliciting WG comments Dear all, This is one of the comments that I send last week (ticket 70). We had a discussion with the RPL authors yesterday (as pretty much every week) to continue our work on the remaining open tickets (making great progress). Le= t me simply explain why "route-tags" may be important to have in the core spec. First of all, I'd like to clarify that we are not discussing about using tags/labels for forwarding (we will at some point !) so I'll start using the terms prefix-color to avoid ambiguity. We had the concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away. *Why is it used for ?* Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. For example, this could be used to flag important versus less-critical prefix. This has proven to be useful in a number of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, i= t could also be used in case of memory overflow to preferably keep the important prefix, ... *Complexity ?* Nothing more than an option carried in a DAO message that could look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | 2 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We just need to add one sentence in the Manageability Section. We could either defer it to another ID or add it now. Personally I am leaning toward adding it back, considering how simple it is and the benefit= s this can bring. Could you let us know whether you think that we should add it to the core spec: 1) Yes 2) No. Thanks. JP. --00c09f97243aab1d07048c463202 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

My only concern with this approach is that other =93prf=94 f= ields were no more than 2/3 bits long, and defined a preference value (with upper= and lower limits for comparison), the below approach is based on flags and much more than 2/3 bits.

=A0

From my understanding of the below explanation, it seems to = me as if the purpose of the below text and the =93prf=94 fields are the same (prioritization). Flags is more flexible than value, but also require more processing.

=A0

My questions/concerns:

1.=A0=A0=A0=A0=A0=A0 2.=A0=A0=A0=A0=A0=A0 =A0

I=92m not familiar with this concept =96 so I apologize in a= dvance in case I am missing the point completely and the purpose of this option is= different than the =93Prf=94 fields in other places.

=A0

Regards,

Yoav

=A0

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of domini= que.barthel@orange-ftgroup.com
Sent: Monday, July 26, 2010 10:46 AM
To: roll@ietf.org
Subject: Re: [Roll] Route-tags - Soliciting WG comments

=A0

I support 1).

This doesn't add complexity now and=A0I trust it will prove useful later.

Dominique

=A0

De=A0: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] De l= a part de JP Vasseur
Envoy=E9=A0: vendredi 23 juillet 2010 10:09
=C0=A0: roll WG
Objet=A0: [Roll] Route-tags - Soliciting WG comments

Dear all,

=A0

This is one of the comments that I send last week (t= icket 70). We had a discussion with the RPL authors yesterday (as pretty much eve= ry week) to continue our work on the remaining open tickets (making great progress). Let me simply explain why "route-tags" may be importan= t to have in the core spec. First of all, I'd like to clarify that we are no= t discussing about using tags/labels for forwarding (we will at some point !)= so I'll start using the terms prefix-color to avoid ambiguity. We had the = concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away.

=A0

Why is it used for ?

=A0

Route-colors is just an x bit flag field (e.g. RPC 5= 130 for ISIS), that is used to mark a route. For example, this could be used to fla= g important versus less-critical prefix. This has proven to be useful in a nu= mber of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, it could also be used in case of memory overflow to preferably ke= ep the important prefix, ...=A0

=A0

Complexity ?

=A0

Nothing more than an option carried in a DAO message= that could look like this:

=A0

=A00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A02=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2=
 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
=A0=A0=A0=A0=A0=A0 |=A0=A0=
 Type =3D 8=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Flags=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
<= pre style=3D"line-height:14.4pt">=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0

We just need to add one sentence in the Manageabilit= y Section.

=A0

We could either defer it to another ID or add it now= . Personally I am leaning toward adding it back, considering how simple it is= and the benefits this can bring.

=A0

Could you let us know whether you think that we shou= ld add it to the core spec:

=A0

1) Yes

2) No.

=A0

Thanks.

=A0

JP.

--00c09f97243aab1d07048c463202-- From jpv@cisco.com Mon Jul 26 01:37:39 2010 Return-Path: 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 E61AD3A6A1A for ; Mon, 26 Jul 2010 01:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 2HjuL8ArMcVt for ; Mon, 26 Jul 2010 01:37:37 -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 E187B3A6A50 for ; Mon, 26 Jul 2010 01:37:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAILmTEyrR7Ht/2dsb2JhbACBRJ4ccaRTmgmFNgSIZII6 X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208,217";a="563742907" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2010 08:37:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q8bhTJ001342; Mon, 26 Jul 2010 08:37:57 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 10:37:55 +0200 Received: from dhcp-60f4.meeting.ietf.org ([10.61.87.222]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 10:37:54 +0200 Message-Id: <25FD9F47-29B6-4D26-B9AC-30C28E05AD40@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <2b03c7a90ea1f72e963044180adc8d98@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-35--968919634 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 10:37:54 +0200 References: <2b03c7a90ea1f72e963044180adc8d98@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jul 2010 08:37:54.0819 (UTC) FILETIME=[D78F9530:01CB2C9D] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17528.005 X-TM-AS-Result: No--35.864300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format 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: , X-List-Received-Date: Mon, 26 Jul 2010 08:37:39 -0000 --Apple-Mail-35--968919634 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Yoav, On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: > Hi, > > I found a small editorial fix in the description of =93Option Length=94 = =20 > field in the SIO description. > > Right now the description says Option Length 19 bytes, which I think =20= > little misleading. If I understand correctly, it should be saying =20 > that the length of the field is 1 byte and its value shall be set to =20= > 19, right? > Well, in Section 5.7.1, this is actually clarified: 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. But I see your point, what we should be doing is to put the number 19 =20= in the figure. In other words, for each figure: Option Lenght (1 byte): 19 + shows the number (when we have a fixed number) on the figure. Would that clarify ? Thanks. JP. > Regards, > Yoav > > > 5.7.9. Solicited Information > > ... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =20= > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Type =3D 7 | Option Length | RPLInstanceID |V|I|D| =20 > Rsvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > =20 > | | > =20 > + + > =20 > | | > + =20 > DODAGID + > =20 > | | > =20 > + + > =20 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Version | > +-+-+-+-+-+-+-+-+ > > Figure 22: Format of the Solicited Information Option > ... > > Option Length: 19 bytes > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-35--968919634 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Yoav,

On = Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote:

Hi,

I found a small editorial fix in the description = of =93Option Length=94 field in the SIO description.

 

Right now the description says = Option Length 19 bytes, which I think little misleading. If I understand = correctly, it should be saying that the length of the field is 1 byte = and its value shall be set to 19, right?

5.7.1.  RPL =
Control Message Option Generic Format


   RPL Control Message Options all follow this format:

        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       |  Option Type  | Option Length | Option Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -

                   Figure 14: RPL Option Generic Format

   Option Type:  8-bit identifier of the type of option.  The Option
         Type values are to be confirmed by the IANA Se=
ction 18.4.

   Option Length:  8-bit unsigned integer, representing the length in
         octets of the option, not including the Option Type and Length
         fields.

   Option Data:  A variable length field that contains data specific to
         the option.

But I see your = point, what we should be doing is to put the number 19 in the = figure.

In other words, for each = figure:
Option Lenght (1 byte): 19
+
shows the number (when we = have a fixed number) on the = figure.

Would that clarify = ?

Thanks.

JP.
=
Regards,
 

5.7.9.  Solicited Information

 

...

        = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3

       |   Type =3D = 7    | Option Length | RPLInstanceID |V|I|D|  = Rsvd   |
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; |
       = +            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; +
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;            =  |
       = +            &= nbsp;           &nb= sp;   = DODAGID           &= nbsp;           &nb= sp;    +
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; |
       = +            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; +
       = |            &= nbsp;           &nb= sp; =             &n= bsp;           &nbs= p;            = |
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    = Version    |
       = +-+-+-+-+-+-+-+-+

 

Roll@ietf.org
X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 26 Jul 2010 08:45:14 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/74 Message-ID: <055.074d18fbfa50419d38970c4b532eaf39@tools.ietf.org> X-Trac-Ticket-ID: 74 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #74: Edits X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:45:06 -0000 #74: Edits -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: trivial | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- From: JP Vasseur Date: July 26, 2010 10:37:54 AM CEDT To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format Hi Yoav, On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: Hi, I found a small editorial fix in the description of “Option Length†field in the SIO description. Right now the description says Option Length 19 bytes, which I think little misleading. If I understand correctly, it should be saying that the length of the field is 1 byte and its value shall be set to 19, right? Well, in Section 5.7.1, this is actually clarified: 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. But I see your point, what we should be doing is to put the number 19 in the figure. In other words, for each figure: Option Lenght (1 byte): 19 + shows the number (when we have a fixed number) on the figure. Would that clarify ? Thanks. JP. Regards, Yoav 5.7.9. Solicited Information ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+ Figure 22: Format of the Solicited Information Option ... Option Length: 19 bytes _______________________________________________ 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 -- Ticket URL: roll From trac@tools.ietf.org Mon Jul 26 01:47:42 2010 Return-Path: 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 893BA3A6A84 for ; Mon, 26 Jul 2010 01:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 AZPvj4CgxP36 for ; Mon, 26 Jul 2010 01:47:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6F9673A6ADE for ; Mon, 26 Jul 2010 01:47:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdJLP-0002FK-K6; Mon, 26 Jul 2010 01:47:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 26 Jul 2010 08:47:31 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/74#comment:1 Message-ID: <064.eb53cf6da62e1a7efd42da99aacf8c75@tools.ietf.org> References: <055.074d18fbfa50419d38970c4b532eaf39@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <055.074d18fbfa50419d38970c4b532eaf39@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #74: Edits on Option Length on Figures (was: Edits) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:47:42 -0000 #74: Edits on Option Length on Figures -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: trivial | Milestone: Component: rpl | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Description changed by jpv@…: Old description: > From: JP Vasseur > Date: July 26, 2010 10:37:54 AM CEDT > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] small comment on DIS format > > Hi Yoav, > > On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: > > Hi, > > I found a small editorial fix in the description of “Option Length†field > in the SIO description. > > Right now the description says Option Length 19 bytes, which I think > little misleading. If I understand correctly, it should be saying that > the length of the field is 1 byte and its value shall be set to 19, > right? > > Well, in Section 5.7.1, this is actually clarified: > > 5.7.1. RPL Control Message Option Generic Format > > RPL Control Message Options all follow this format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > | Option Type | Option Length | Option Data > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > > Figure 14: RPL Option Generic Format > > Option Type: 8-bit identifier of the type of option. The Option > Type values are to be confirmed by the IANA Section 18.4. > > Option Length: 8-bit unsigned integer, representing the length in > octets of the option, not including the Option Type and Length > fields. > > Option Data: A variable length field that contains data specific to > the option. > > But I see your point, what we should be doing is to put the number 19 in > the figure. > > In other words, for each figure: > Option Lenght (1 byte): 19 > + > shows the number (when we have a fixed number) on the figure. > > Would that clarify ? > > Thanks. > > JP. > > Regards, > Yoav > > 5.7.9. Solicited Information > > ... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + DODAGID + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+ > > Figure 22: Format of the Solicited Information Option > ... > > Option Length: 19 bytes > > _______________________________________________ > 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 New description: From: JP Vasseur Date: July 26, 2010 10:37:54 AM CEDT To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format Hi Yoav, On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: Hi, I found a small editorial fix in the description of “Option Length†field in the SIO description. Right now the description says Option Length 19 bytes, which I think little misleading. If I understand correctly, it should be saying that the length of the field is 1 byte and its value shall be set to 19, right? Well, in Section 5.7.1, this is actually clarified: 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. But I see your point, what we should be doing is to put the number 19 in the figure. In other words, for each figure: Option Lenght (1 byte): 19 + shows the number (when we have a fixed number) on the figure. Would that clarify ? Thanks. JP. Regards, Yoav 5.7.9. Solicited Information ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+ Figure 22: Format of the Solicited Information Option ... Option Length: 19 bytes _______________________________________________ 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 -- -- Ticket URL: roll From yoav@yitran.com Mon Jul 26 01:47:46 2010 Return-Path: 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 DE2F63A6ABC for ; Mon, 26 Jul 2010 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 i3Fpo3wLt2li for ; Mon, 26 Jul 2010 01:47:43 -0700 (PDT) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by core3.amsl.com (Postfix) with SMTP id 260373A6A65 for ; Mon, 26 Jul 2010 01:47:35 -0700 (PDT) Received: from source ([209.85.216.182]) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTE1LsYZi0fuFclWECXD+P7jlVs8qrhio@postini.com; Mon, 26 Jul 2010 01:47:57 PDT Received: by qyk32 with SMTP id 32so2144164qyk.20 for ; Mon, 26 Jul 2010 01:47:44 -0700 (PDT) Received: by 10.224.19.144 with SMTP id a16mr5989870qab.346.1280134064652; Mon, 26 Jul 2010 01:47:44 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2b03c7a90ea1f72e963044180adc8d98@mail.gmail.com> <25FD9F47-29B6-4D26-B9AC-30C28E05AD40@cisco.com> In-Reply-To: <25FD9F47-29B6-4D26-B9AC-30C28E05AD40@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acssnds+Ruy9MyCNQ3Ggn8nvUSvzWgAAG7bw Date: Mon, 26 Jul 2010 11:47:35 +0300 Message-ID: To: JP Vasseur Content-Type: multipart/alternative; boundary=0015175cda323043fd048c467094 Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format 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: , X-List-Received-Date: Mon, 26 Jul 2010 08:47:47 -0000 --0015175cda323043fd048c467094 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable See below the places where fixes value is assigned to this field. 5.7.6. DODAG Configuration ... Option Length: 8 bytes 5.7.9. Solicited Information ... Option Length: 19 bytes 5.7.10. Prefix Information ... Option Length: 30. Note that this length is expressed in units of single-octets, unlike in IPv6 ND. I thought there was inconsistency because of 5.7.10. Maybe the correct thin= g to do is fix it to be consistent with the rest of the sections. My personal preference is to remove the word bytes in the field description= , or specify the number inside the field, but the main point was really abou= t consistency. Any way you choose to fix this that makes this field description consistent is OK by me. Hope this clears things up. Thanks, Yoav *From:* JP Vasseur [mailto:jpv@cisco.com] *Sent:* Monday, July 26, 2010 11:38 AM *To:* Yoav Ben-Yehezkel *Cc:* roll@ietf.org *Subject:* Re: [Roll] small comment on DIS format Hi Yoav, On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: Hi, I found a small editorial fix in the description of =93Option Length=94 fie= ld in the SIO description. Right now the description says Option Length 19 bytes, which I think little misleading. If I understand correctly, it should be saying that the length of the field is 1 byte and its value shall be set to 19, right? Well, in Section 5.7.1, this is actually clarified: 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4 . Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. But I see your point, what we should be doing is to put the number 19 in th= e figure. In other words, for each figure: Option Lenght (1 byte): 19 + shows the number (when we have a fixed number) on the figure. Would that clarify ? Thanks. JP. Regards, Yoav 5.7.9. Solicited Information ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+ Figure 22: Format of the Solicited Information Option ... Option Length: 19 bytes _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --0015175cda323043fd048c467094 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

See below the places where fixes value is assigned to this field.

=A0

5.7.6.=A0 DODAG Configuration

...

Option Length:=A0 8 bytes

=A0

5.7.9.=A0 Solicited Information

...

Option Length:=A0 19 bytes

=A0

5.7.10.=A0 Prefix Information

...

Option Length:=A0 30.=A0 Note that this length is expressed in units o=
f

=A0=A0=A0=A0=A0=A0=A0=A0 single-octets, unlike in IPv6 ND.

=A0

=A0

I thought there was inconsistency because of 5.7.10. Maybe t= he correct thing to do is fix it to be consistent with the rest of the sections.

=A0

My personal preference is to remove the word bytes in the fi= eld description, or specify the number inside the field,=A0 but the main point = was really about consistency. Any way you choose to fix this that makes this field description consistent is OK by me.

=A0

Hope this clears things up.

=A0

Thanks,

Yoav

=A0

=A0

=A0

From: JP Vasse= ur [mailto:jpv@cisco.com]
Sent: Monday, July 26, 2010 11:38 AM
To: Yoav Ben-Yehezkel
Cc: roll@ietf.org
Subject: Re: [Roll] small comment on DIS format

=A0

Hi Yoav,

=A0

On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrot= e:



Hi,

=A0

I found a small editorial fix in the description of =93Option Length=94 field in the SIO description.

=A0

Right now the description says Option Length 19 bytes, which I think little misleading. If I understand correctly, it should be saying tha= t the length of the field is 1 byte and its value shall be set to 19, right?<= /span>

=A0

=A0

Well, in Section 5.7.1, this is actually clarified:<= /p>

=A0

5.7.1.=A0 RPL Control= Message Option Generic Format

=
=A0
=A0
=A0=A0 RPL Control Message Options all follow t=
his format:
=
=A0
=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
2
=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 =
0 1 2 3 4 5 6 7 8 9 0 1 2 3
=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+- - - - - - - -
=
=A0=A0=A0=A0=A0=A0 |=A0 Option Type=A0 | Option Length | Option Data=

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure=
 14: RPL Option Generic Format
=A0
=A0=A0 Option Type:=A0 8-bit=
 identifier of the type of option.=A0 The Option
=A0=A0=A0=A0=A0=A0=A0=A0 Type values are t=
o be confirmed by the IANA Section 18.4.
=A0
=A0=A0 Option Length:=A0 8-b=
it unsigned integer, representing the length in
=A0=A0=A0=A0=A0=A0=A0=A0 octets of the opt=
ion, not including the Option Type and Length
=A0=A0=A0=A0=A0=A0=
=A0=A0 fields.
=A0
=A0=A0 Option Data:=A0 A var=
iable length field that contains data specific to
=A0=A0=A0=A0=A0=A0=A0=A0 the option.

=A0

But I see your point, what we should be doing is to = put the number 19 in the figure.

=A0

In other words, for each f= igure:

Option Lenght (1 byte): 19=

+

shows the number (when we = have a fixed number) on the figure.

=A0

Would that clarify ?

=A0

Thanks.

=A0

JP.



Regards,

Yoav

=A0

=A0

5.7.9.=A0 Solicited Information=

=A0

...

=A0

=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A03

=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0 Type =3D 7=A0=A0=A0 | Option Length | RPLInstanceID |V|I|D|=A0 Rsvd=A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0|

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 DODAGID=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 Version=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 22: Format of the Solicited Information Option

...

=A0

=A0=A0 Option Length:=A0 19 bytes

=A0

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

=A0

--0015175cda323043fd048c467094-- From jpv@cisco.com Mon Jul 26 01:49:31 2010 Return-Path: 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 C81783A6A1A for ; Mon, 26 Jul 2010 01:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6laKPK-Mbt10 for ; Mon, 26 Jul 2010 01:49:30 -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 4BB0B3A6A8F for ; Mon, 26 Jul 2010 01:49:27 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAJ/oTExAZnwM/2dsb2JhbACBRJ4ccaQ+mguFNgSIZII6 X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208,217";a="139134973" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 08:49:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q8nlT8029134; Mon, 26 Jul 2010 08:49:47 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 10:49:47 +0200 Received: from dhcp-60f4.meeting.ietf.org ([10.61.87.222]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 10:49:46 +0200 Message-Id: From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-39--968208141 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 10:49:46 +0200 References: <2b03c7a90ea1f72e963044180adc8d98@mail.gmail.com> <25FD9F47-29B6-4D26-B9AC-30C28E05AD40@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jul 2010 08:49:46.0355 (UTC) FILETIME=[7FAB5C30:01CB2C9F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17528.005 X-TM-AS-Result: No--30.662100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format 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: , X-List-Received-Date: Mon, 26 Jul 2010 08:49:31 -0000 --Apple-Mail-39--968208141 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 26, 2010, at 10:47 AM, Yoav Ben-Yehezkel wrote: > See below the places where fixes value is assigned to this field. > > 5.7.6. DODAG Configuration > ... > Option Length: 8 bytes > > 5.7.9. Solicited Information > ... > Option Length: 19 bytes > > 5.7.10. Prefix Information > ... > Option Length: 30. Note that this length is expressed in units of > single-octets, unlike in IPv6 ND. > > > I thought there was inconsistency because of 5.7.10. Maybe the =20 > correct thing to do is fix it to be consistent with the rest of the =20= > sections. > > My personal preference is to remove the word bytes in the field =20 > description, or specify the number inside the field, but the main =20 > point was really about consistency. Any way you choose to fix this =20 > that makes this field description consistent is OK by me. > > Hope this clears things up. It does, thanks for the feed-back. Will clarify in the next revision. JP. > > Thanks, > Yoav > > > > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Monday, July 26, 2010 11:38 AM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] small comment on DIS format > > Hi Yoav, > > On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: > > > Hi, > > I found a small editorial fix in the description of =93Option Length=94 = =20 > field in the SIO description. > > Right now the description says Option Length 19 bytes, which I think =20= > little misleading. If I understand correctly, it should be saying =20 > that the length of the field is 1 byte and its value shall be set to =20= > 19, right? > > > Well, in Section 5.7.1, this is actually clarified: > > 5.7.1. RPL Control Message Option Generic Format > > > > RPL Control Message Options all follow this format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > | Option Type | Option Length | Option Data > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > > Figure 14: RPL Option Generic Format > > Option Type: 8-bit identifier of the type of option. The Option > Type values are to be confirmed by the IANA Section 18.4. > > Option Length: 8-bit unsigned integer, representing the length in > octets of the option, not including the Option Type and =20 > Length > fields. > > Option Data: A variable length field that contains data specific =20= > to > the option. > > But I see your point, what we should be doing is to put the number =20 > 19 in the figure. > > In other words, for each figure: > Option Lenght (1 byte): 19 > + > shows the number (when we have a fixed number) on the figure. > > Would that clarify ? > > Thanks. > > JP. > > > Regards, > Yoav > > > 5.7.9. Solicited Information > > ... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =20= > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Type =3D 7 | Option Length | RPLInstanceID |V|I|D| =20 > Rsvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > =20 > | | > =20 > + + > =20 > | | > + =20 > DODAGID + > =20 > | | > =20 > + + > =20 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Version | > +-+-+-+-+-+-+-+-+ > > Figure 22: Format of the Solicited Information Option > ... > > Option Length: 19 bytes > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-39--968208141 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 26, 2010, = at 10:47 AM, Yoav Ben-Yehezkel wrote:

See below the places where fixes = value is assigned to this field.

 

Option Length:  8 bytes

 

5.7.9.  Solicited = Information
...
Option = Length:  19 bytes

5.7.10.  Prefix Information

Option Length:  30.  Note that this length is = expressed in units of
 

 

I thought there was inconsistency = because of 5.7.10. Maybe the correct thing to do is fix it to be = consistent with the rest of the sections.

 

My personal preference is to = remove the word bytes in the field description, or specify the number = inside the field,  but the main point was really about consistency. = Any way you choose to fix this that makes this field description = consistent is OK by me.

 

Hope this clears things = up.

It = does, thanks for the feed-back. Will clarify in the next = revision.

JP.

 

Thanks,
Yoav

 

 

 

 JP = Vasseur [mailto:jpv@cisco.com] 
Sent: Monday, July 26, 2010 11:38 = AM
To: Yoav = Ben-Yehezkel
Cc: roll@ietf.org
Subject: Re: [Roll] small comment on = DIS format

 

Hi Yoav,

 

On Jul 26, 2010, at 10:19 = AM, Yoav Ben-Yehezkel wrote:
I found a small = editorial fix in the description of =93Option Length=94 field in the SIO = description.

 

Right now the = description says Option Length 19 bytes, which I think little = misleading. If I understand correctly, it should be saying that the = length of the field is 1 byte and its value shall be set to 19, = right?

 

 

Well, in Section 5.7.1, = this is actually clarified:

 

5.7.1.  RPL Control Message = Option Generic Format

 
 
 
        =
0            &=
nbsp;      =
1            &=
nbsp;      2
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
 
   Option Type:  8-bit =
identifier of the type of option.  The Option
Section =
18.4.
 
   Option Length:  8-bit =
unsigned integer, representing the length in
 
   Option Data:  A variable =
length field that contains data specific to
But I see your point, what we should be =
doing is to put the number 19 in the figure.

 

In other words, for each = figure:
Option Lenght (1 byte): 19
+
shows the number (when we have a = fixed number) on the figure.

 

Would that clarify = ?

 

Thanks.

 

JP.


 

 

...

       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       = +            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; +
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;            =  |
       = +            &= nbsp;           &nb= sp;   = DODAGID           &= nbsp;           &nb= sp;    +
       = +            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; +
       = |            &= nbsp;           &nb= sp; =             &n= bsp;           &nbs= p;            = |
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...

Roll@ietf.org
writes: JP> This is one of the comments that I send last week (ticket JP> 70). We had a discussion with the RPL authors yesterday (as JP> pretty much every week) to continue our work on the remaining >> I believe that this feature may be very useful to some, but not >> to all. As such, I think it is a very good example of what >> should be the first extension draft. It can be 3-4 pages long >> (80% boilerplate), and serve an example of how to do an >> extension. JP> The point is also that having a number of short RFCs makes the JP> overall picture hard to get. Again we are talking about a field JP> flag, that's all. I agree, it's really simple. If it not relevant to everyone, then it belongs in another draft. If you go through with this in the main draft, it is going to be very hard to turn down other things which are also "field flags". -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From culler@cs.berkeley.edu Mon Jul 26 03:03:15 2010 Return-Path: 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 7CFC53A6833 for ; Mon, 26 Jul 2010 03:03:15 -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 5G1xXHB4Khrj for ; Mon, 26 Jul 2010 03:03:14 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 62FDA3A69E8 for ; Mon, 26 Jul 2010 03:03:14 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QA3TdE017297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 03:03:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: David Culler In-Reply-To: <9EDFAAAA-7F19-488A-8574-B5E6A722858F@cs.stanford.edu> Date: Mon, 26 Jul 2010 03:03:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78EA3D4B-9D3A-43E4-AC03-F897B27124B4@cs.berkeley.edu> References: <99649B3D-6ED2-4A83-B0C1-C69182BFD87E@cs.stanford.edu> <7804.1279842907@marajade.sandelman.ca> <3D6EC9B2-9EC9-4893-97CD-E93DC8BB97A8@cs.stanford.edu> <4C4945F3.7060501@gmail.com> <273C3856-B7DB-4AAD-9846-83C7BE2E4274@cs.stanford.edu> <4C4B647A.1080408@gmail.com> <9EDFAAAA-7F19-488A-8574-B5E6A722858F@cs.stanford.edu> To: Philip Levis , Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: roll WG Subject: Re: [Roll] Signature schemes consultation question 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:03:15 -0000 Indeed. We run IP over ieee 802.11 links. Layer 3 does not depend on = particular properties of the links, but that does not mean the we cannot = use WiFi encryption. The same would apply to IEEE 802.15.4. = Furthermore, the IETF did not have to specify WPA in order to utilize = it. On Jul 25, 2010, at 12:53 PM, Philip Levis wrote: >=20 > On Jul 24, 2010, at 3:08 PM, Alexandru Petrescu wrote: >>>=20 >>> 3.3.3. Security >>>=20 >>> RPL supports message confidentiality and integrity. It is designed >>> such that link-layer mechanisms can be used when available and >>> appropriate, yet in their absence RPL can use its own mechanisms. >>> RPL has three basic security modes. >>=20 >> But earlier the draft says: >>=20 >>> In compliance with the layered architecture of IP, RPL does not rely >>> on any particular features of a specific link layer technology. >>=20 >> which I interpret as saying RPL does not use any feature from the = link >> layer (e.g. security). >=20 > Rely and use have distinct meanings. =46rom the OED: >=20 > rely verb ( -lies, -lied) [ intrans. ] ( rely on/upon) > depend on with full trust or confidence : I know I can rely on your = discretion. > =E2=80=A2 be dependent on : the charity has to rely entirely on public = donations. >=20 > use verb=20 > 1 |yo=C5=8Dz| [ trans. ] take, hold, or deploy (something) as a means = of accomplishing a purpose or achieving a result; employ : she used her = key to open the front door | the poem uses simple language. > =E2=80=A2 take or consume (an amount) from a limited supply of = something : we have used all the available funds. > =E2=80=A2 exploit (a person or situation) for one's own advantage : I = couldn't help feeling that she was using me. >=20 > RPL does not *rely* on particular link layer technologies: it does not = depend on them, and can, in this context, meet its security requirements = without link layer security mechanisms.=20 >=20 > However, a given RPL application can *use* security capabilities of = the link layer (or other layers), if they are available, instead of = RPL's security mechanisms, if doing so is advantageous to meeting = application requirements.=20 >=20 > As a trivial example, let's suppose there is a RPL application that = needs message integrity, and the link layer provides sufficient = integrity guarantees to meet the application requirements. RPL allows = the application developer to use the link layer mechanisms, rather than = force the RPL Instance to employ RPL-level integrity. Does that make = sense? Recall, many RPL applications are closed networks under a single = administrative domain. >=20 >=20 >>=20 >> I think these two paragraphs sound contradictory(?) >>=20 >>=20 >=20 > Does this clear it up? >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From culler@cs.berkeley.edu Mon Jul 26 03:20:13 2010 Return-Path: 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 DAD003A6A42 for ; Mon, 26 Jul 2010 03:20:12 -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 Dh1wcDWODEfi for ; Mon, 26 Jul 2010 03:20:11 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 88E9E3A6833 for ; Mon, 26 Jul 2010 03:20:10 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QAKTRk017471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 03:20:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Mon, 26 Jul 2010 03:20:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76A0F25B-AD62-4C37-829F-EEE4CDE6DB7F@cs.berkeley.edu> References: To: David Culler X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] LC RPL-10 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:20:13 -0000 Thank you all for your comments. We are on track to close LC as = scheduled. Please send any last minute technical issues to the mailing = list. On Jul 6, 2010, at 9:41 AM, David Culler wrote: > This email starts a WG Last Call on RPL-10 that will end on July 27 at = noon ET. Please send your comments to the authors and copy the chairs = and the mailing list. Thanks all. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Mon Jul 26 03:32:18 2010 Return-Path: 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 ADEB43A6BB7 for ; Mon, 26 Jul 2010 03:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 XoDZ94m--9LV for ; Mon, 26 Jul 2010 03:32:16 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id 867F03A6BB6 for ; Mon, 26 Jul 2010 03:28:17 -0700 (PDT) Received: from source ([209.85.216.180]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTE1jVH5qGvDblWFoQLN4DnvhOMRWt6sg@postini.com; Mon, 26 Jul 2010 03:28:38 PDT Received: by mail-qy0-f180.google.com with SMTP id 8so1770703qyk.4 for ; Mon, 26 Jul 2010 03:28:36 -0700 (PDT) Received: by 10.224.54.134 with SMTP id q6mr5894270qag.377.1280140116780; Mon, 26 Jul 2010 03:28:36 -0700 (PDT) From: Yoav Ben-Yehezkel References: <1E00C3D0-DAE6-47EC-9608-A74E57202E5D@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF017516DB@ftrdmel0.rd.francetelecom.fr> b4d678a7f075c423c070fce59bf81c54@mail.gmail.com In-Reply-To: b4d678a7f075c423c070fce59bf81c54@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsqPmW81aCCBHFeS1+quKsbC0N58gCV+QMgAAFNyoAABF36wA== Date: Mon, 26 Jul 2010 13:28:29 +0300 Message-ID: <5e24fef6c5ecca6053b78d009ceef3a7@mail.gmail.com> To: Yoav Ben-Yehezkel , dominique.barthel@orange-ftgroup.com, roll@ietf.org Content-Type: multipart/alternative; boundary=0015175cdfb6ec6ddc048c47d868 Subject: Re: [Roll] Route-tags - Soliciting WG comments 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:32:18 -0000 --0015175cdfb6ec6ddc048c47d868 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable After some clarifications from JP (thanks for that), I also agree with option 1. Best regards, Yoav *From:* Yoav Ben-Yehezkel [mailto:yoav@yitran.com] *Sent:* Monday, July 26, 2010 11:30 AM *To:* 'dominique.barthel@orange-ftgroup.com'; 'roll@ietf.org' *Subject:* RE: [Roll] Route-tags - Soliciting WG comments My only concern with this approach is that other =93prf=94 fields were no m= ore than 2/3 bits long, and defined a preference value (with upper and lower limits for comparison), the below approach is based on flags and much more than 2/3 bits. >From my understanding of the below explanation, it seems to me as if the purpose of the below text and the =93prf=94 fields are the same (prioritization). Flags is more flexible than value, but also require more processing. My questions/concerns: 1. Can we use the same approach in all places (prf) =96 due to the fa= ct that this can lead to simpler (common) coding for processing of the prioritization fields? 2. Is the proposed length acceptable and commonly used (seems much more than in other places)? I=92m not familiar with this concept =96 so I apologize in advance in case = I am missing the point completely and the purpose of this option is different than the =93Prf=94 fields in other places. Regards, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = * dominique.barthel@orange-ftgroup.com *Sent:* Monday, July 26, 2010 10:46 AM *To:* roll@ietf.org *Subject:* Re: [Roll] Route-tags - Soliciting WG comments I support 1). This doesn't add complexity now and I trust it will prove useful later. Dominique ------------------------------ *De :* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *De la part de*JP Vasseur *Envoy=E9 :* vendredi 23 juillet 2010 10:09 *=C0 :* roll WG *Objet :* [Roll] Route-tags - Soliciting WG comments Dear all, This is one of the comments that I send last week (ticket 70). We had a discussion with the RPL authors yesterday (as pretty much every week) to continue our work on the remaining open tickets (making great progress). Le= t me simply explain why "route-tags" may be important to have in the core spec. First of all, I'd like to clarify that we are not discussing about using tags/labels for forwarding (we will at some point !) so I'll start using the terms prefix-color to avoid ambiguity. We had the concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away. *Why is it used for ?* Route-colors is just an x bit flag field (e.g. RPC 5130 for ISIS), that is used to mark a route. For example, this could be used to flag important versus less-critical prefix. This has proven to be useful in a number of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, i= t could also be used in case of memory overflow to preferably keep the important prefix, ... *Complexity ?* Nothing more than an option carried in a DAO message that could look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | 2 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We just need to add one sentence in the Manageability Section. We could either defer it to another ID or add it now. Personally I am leaning toward adding it back, considering how simple it is and the benefit= s this can bring. Could you let us know whether you think that we should add it to the core spec: 1) Yes 2) No. Thanks. JP. --0015175cdfb6ec6ddc048c47d868 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

After some clarifications from JP (thanks for that), I also = agree with option 1.

=A0

Best regards,

Yoav

=A0

=A0

From: Yoav Ben= -Yehezkel [mailto:yoav@yitran.com]
Sent: Monday, July 26, 2010 11:30 AM
To: 'dom= inique.barthel@orange-ftgroup.com'; 'roll@ietf.org'
Subject: RE: [Roll] Route-tags - Soliciting WG comments

=A0

My only concern with this approach is that other =93prf=94 f= ields were no more than 2/3 bits long, and defined a preference value (with upper= and lower limits for comparison), the below approach is based on flags and much more than 2/3 bits.

=A0

From my understanding of the below explanation, it seems to = me as if the purpose of the below text and the =93prf=94 fields are the same (prioritization). Flags is more flexible than value, but also require more processing.

=A0

My questions/concerns:

1.=A0=A0=A0=A0=A0=A0 2.=A0=A0=A0=A0=A0=A0 =A0

I=92m not familiar with this concept =96 so I apologize in a= dvance in case I am missing the point completely and the purpose of this option is different than the =93Prf=94 fields in other places.

=A0

Regards,

Yoav

=A0

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of domini= que.barthel@orange-ftgroup.com
Sent: Monday, July 26, 2010 10:46 AM
To: roll@ietf.org
Subject: Re: [Roll] Route-tags - Soliciting WG comments

=A0

I support 1).

This doesn't add complexity now and=A0I trust it will prove useful later.

Dominique

=A0

De=A0: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] De l= a part de JP Vasseur
Envoy=E9=A0: vendredi 23 juillet 2010 10:09
=C0=A0: roll WG
Objet=A0: [Roll] Route-tags - Soliciting WG comments

Dear all,

=A0

This is one of the comments that I send last week (t= icket 70). We had a discussion with the RPL authors yesterday (as pretty much eve= ry week) to continue our work on the remaining open tickets (making great progress). Let me simply explain why "route-tags" may be importan= t to have in the core spec. First of all, I'd like to clarify that we are no= t discussing about using tags/labels for forwarding (we will at some point !)= so I'll start using the terms prefix-color to avoid ambiguity. We had the = concept of route-color (called route-tags) up to revision -7, at which point we revisited the whole DAO format and it went away.

=A0

Why is it used for ?

=A0

Route-colors is just an x bit flag field (e.g. RPC 5= 130 for ISIS), that is used to mark a route. For example, this could be used to fla= g important versus less-critical prefix. This has proven to be useful in a nu= mber of other routing protocols but to give two examples: this can be used to prioritize prefix installation during DODAG rebuilt to increase the "convergence" time and restore connectivity faster for critical prefixes, it could also be used in case of memory overflow to preferably ke= ep the important prefix, ...=A0

=A0

Complexity ?

=A0

Nothing more than an option carried in a DAO message= that could look like this:

=A0

=A00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A02=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 3
=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2=
 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+
=A0=A0=A0=A0=A0=A0 |=A0=A0=
 Type =3D 8=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Flags=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
<= pre style=3D"line-height:14.4pt">=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0

We just need to add one sentence in the Manageabilit= y Section.

=A0

We could either defer it to another ID or add it now= . Personally I am leaning toward adding it back, considering how simple it is= and the benefits this can bring.

=A0

Could you let us know whether you think that we shou= ld add it to the core spec:

=A0

1) Yes

2) No.

=A0

Thanks.

=A0

JP.

--0015175cdfb6ec6ddc048c47d868-- From culler@cs.berkeley.edu Mon Jul 26 03:36:44 2010 Return-Path: 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 96C7F3A69F3 for ; Mon, 26 Jul 2010 03:36:44 -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=[AWL=-0.001, 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 0+xVzS51cqS9 for ; Mon, 26 Jul 2010 03:36:42 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 7B93D3A6AD0 for ; Mon, 26 Jul 2010 03:35:35 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QAZqOS017581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 03:35:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-8--961842749 From: David Culler In-Reply-To: Date: Mon, 26 Jul 2010 03:35:51 -0700 Message-Id: <4B8384AA-F622-46BE-985B-EEB442CFA54A@cs.berkeley.edu> References: <4C4B7359.6010109@gmail.com> <3CB63F47-065A-4C80-A618-28F65D7D78C4@cisco.com> <4C4C04F1.2080407@gmail.com> <2DA850CF-D601-4966-946D-DC4D85E779C9@cisco.com> <4C4C080E.6010307@gmail.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] How does RPL disallow greediness? What is local repair? 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:36:44 -0000 --Apple-Mail-8--961842749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alex, We are not solving 100 tickets in one IETF. We have been steadily = resolving issues. In the early stage, you address a small number of = large issues. It does not make sense to polish all the little ones = until the large ones have settled. In the final stages you end up with = numerous small issues to polish. That process is going along very = nicely. The WG include numerous people who have implemented variants of = the these protocols and have extensive experience. They have brought = that to bear on the problem. Where we encountered issues that do not = have a huge body of established evidence to guide, we have simplified = the approach to where it remained extremely well grounded. The proposed = protocol rests on a substantial body of knowledge and fact. The issues = at this stage are cleaning up details and improving consistency. This = allows the WG to complete the core spec and serious implementation to = proceed. =46rom that experience over time there is likely to be = addition small improvements. In particular, we have set aside major = optimizations that did not yet have sufficient body of evidence to = support introduction of additional complexity. At this point you seem to be tossing our long scattered messages on = everything that comes to your mind. That is permitted under IETF rules, = but it is not very useful. It will be much more useful if you will read = the draft, try to think through the concern that you have, and then if = it remains significant pose a focused question to the mailing list. On Jul 25, 2010, at 3:10 AM, JP Vasseur wrote: >=20 > On Jul 25, 2010, at 11:46 AM, Alexandru Petrescu wrote: >=20 >> Le 25/07/2010 11:39, JP Vasseur a =E9crit : >>>=20 >>> On Jul 25, 2010, at 11:33 AM, Alexandru Petrescu wrote: >>>=20 >>>> Le 25/07/2010 11:27, JP Vasseur a =E9crit : >>>>> To explain "geediness" we have added an example (see below). >>>> [...] >>>>> Internet-Draft draft-ietf-roll-rpl-11 July 2010 >>>>=20 >>>> 11? I thought it was 10? >>>=20 >>> It is 10 right now. The author team has been working hard to >>> incorporate all the comments, ticket resolutions in the (to be >>> posted) revision 11. I gave you some new text that will be >>> incorporated to answer your question. >>>=20 >>>>=20 >>>> Am I looking at the right document? >>>>=20 >>>> This is a moving target - I do not like to work that way, sorry. >>>> Please post drafts publicly and only then ask for review. >>>>=20 >>>> Can't work this way: private documents, fuzzy authorship. >>>>=20 >>>> It's a waste of time from my part. >>>>=20 >>>> Yes, procedure is important. >>>>=20 >>>=20 >>> Alex, we are in WG LC. We have received a number of comments, open a >>> number of tickets, proposed solutions, ... this cannot be more >>> transparent. Resolution text are being worked out and I gave you >>> extracts. That's it. >>=20 >> JP - thanks for explanation. This is a management problem. YOu have = a 100 page document, 100wise tickets and a WG LC which you seem to want = to solve in one IETF meeting. I think it is too much work... >=20 > Last email on the subject matter from my side. David may want to chime = in as document shepherd.=20 > If you carefully look at the mailing list, you will find out that a = number of people provided comments that helped > to collectively build RPL. You are referring to the 100wise tickets = (actually 73), that were opened and a 100 > page document to solve in one IETF. I have no idea of why you are = referring to "Solving in one IETF meeting". > The first ticket was opened 1 year ago, we have 3 IETF meetings and = two interim meetings. Tickets have been > discussed, solved and closed on the mailing in total transparency.=20 >=20 > I'll stop there. David may want to say a few words too. >=20 > JP. >=20 >>=20 >> Yes, this is procedure, not technical, but without good procedure I = can't talk technical. >>=20 >> Alex >>=20 >>>=20 >>> JP. >>>=20 >>>> Alex >>>>=20 >>>>>=20 >>>>>=20 >>>>> parents. >>>>>=20 >>>>> o Let Figure 3-1 be the initial condition. >>>>>=20 >>>>> o Suppose Node (C) first is able to leave the DODAG and rejoin at >>>>> a lower rank, taking both Nodes (A) and (B) as DODAG parents as >>>>> depicted in Figure 3-2. Now Node (C) is deeper than both Nodes >>>>> (A) and (B), and Node (C) is satisfied to have 2 DODAG parents. >>>>>=20 >>>>> o Suppose Node (B), in its greediness, is willing to receive and >>>>> process a DIO message from Node (C) (against the rules of RPL), >>>>> and then Node (B) leaves the DODAG and rejoins at a lower rank, >>>>> taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is >>>>> deeper than both Nodes (A) and (C) and is satisfied with 2 DAG >>>>> parents. >>>>>=20 >>>>> o Then Node (C), because it is also greedy, will leave and >>>>> rejoin deeper, to again get 2 parents and have a lower rank then >>>>> both of them. >>>>>=20 >>>>> o Next Node (B) will again leave and rejoin deeper, to again get >>>>> 2 parents >>>>>=20 >>>>> o And again Node (C) leaves and rejoins deeper... >>>>>=20 >>>>> o The process will repeat, and the DODAG will oscillate between >>>>> Figure 3-2 and Figure 3-3 until the nodes count to infinity and >>>>> restart the cycle again. >>>>>=20 >>>>> o This cycle can be averted through mechanisms in RPL: >>>>>=20 >>>>> * Nodes (B) and (C) stay at a rank sufficient to attach to their >>>>> most preferred parent (A) and don't go for any deeper (worse) >>>>> alternate parents (Nodes are not greedy) >>>>>=20 >>>>> * Nodes (B) and (C) do not process DIO messages from nodes >>>>> deeper than themselves (because such nodes are possibly in their >>>>> own sub-DODAGs) >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jul 25, 2010, at 1:12 AM, Alexandru Petrescu wrote: >>>>>=20 >>>>>>> Once a node has joined a DODAG version, RPL disallows >>>>>>> certain behaviors, including greediness, in order to prevent >>>>>>> resulting instabilities in the DODAG version. >>>>>>=20 >>>>>> How? I searched for greed further down the text and it does not >>>>>> appear. >>>>>>=20 >>>>>> This phrase sounds as if there is a bit set on/off called >>>>>> 'greed', or similar. >>>>>>=20 >>>>>> I may be wrong. >>>>>>=20 >>>>>>> It is for this reason that RPL limits the cases where a node >>>>>>> may process DIO messages from deeper nodes to some forms of >>>>>>> local repair. >>>>>>=20 >>>>>> Which forms? >>>>>>=20 >>>>>> 'local repair' procedure is mentioned several times in the >>>>>> draft: >>>>>>=20 >>>>>>> On receiving such a packet, a node institutes a local repair >>>>>>> operation. >>>>>> [...] >>>>>>> Strict use of the DODAG Version Number can eliminate this >>>>>>> type of loop, but this type of loop may possibly be >>>>>>> encountered when using some local repair mechanisms. >>>>>>>=20 >>>>>> [...] >>>>>>> MaxRankIncrease: 16-bit unsigned integer used to configure >>>>>>> DAGMaxRankIncrease, the allowable increase in rank in support >>>>>>> of local repair. >>>>>> [...] >>>>>>> o Trigger a local repair >>>>>> [...] >>>>>>> o Number of times a local repair procedure was triggered >>>>>>=20 >>>>>> These are all the occurences of "local repair". It reads as an >>>>>> operation, mechanism, procedure. It is some form, some. >>>>>>=20 >>>>>> But what is a local repair? >>>>>>=20 >>>>>> Probably it is another term explained elsewhere that I can't >>>>>> find while searching in this draft, sorry if so. >>>>>>=20 >>>>>> Alex _______________________________________________ Roll >>>>>> mailing list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-8--961842749 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Jul 25, = 2010, at 11:46 AM, Alexandru Petrescu wrote:

Le = 25/07/2010 11:39, JP Vasseur a =E9crit :

On Jul 25, = 2010, at 11:33 AM, Alexandru Petrescu wrote:

Le 25/07/2010 11:27, JP Vasseur a =E9crit = :
To explain "geediness" we have = added an example (see = below).
[...]
Internet-Draft draft-ietf-roll-rpl-11 July = 2010

11? I thought it was = 10?

It is 10 right = now. The author team has been working hard = to
incorporate all the = comments, ticket resolutions in the (to be
posted) revision 11. I gave you some new text that will = be
incorporated to answer your = question.


Am I looking at the right = document?

This is a moving target - I do = not like to work that way, = sorry.
Please post drafts publicly and only then ask for = review.

Can't work this way: private = documents, fuzzy authorship.

It's a waste of time from my = part.

Yes, procedure is = important.


Alex, we are in = WG LC. We have received a number of comments, open = a
number of tickets, proposed = solutions, ... this cannot be more
transparent. Resolution text are being worked out and I = gave you
extracts. That's = it.

JP - thanks for explanation.  This is a = management problem.  YOu have a 100 page document, 100wise tickets = and a WG LC which you seem to want to  solve in one IETF meeting. =  I think it is too much = work...

Last email on the = subject matter from my side. David may want to chime in as document = shepherd. 
If you carefully look at the mailing list, you = will find out that a number of people provided comments that = helped
to collectively build RPL. You are referring to = the 100wise tickets (actually 73), that were opened and a = 100
page document to solve in one IETF. I have no idea = of why you are referring to "Solving in one IETF meeting".
The = first ticket was opened 1 year ago, we have 3 IETF meetings and two = interim meetings. Tickets have been
discussed, solved and = closed on the mailing in total = transparency. 

I'll stop there. David may = want to say a few words = too.

JP.


Yes, this is procedure, not technical, but = without good procedure I can't talk = technical.

Alex


JP.

Alex



parents.

o Let = Figure 3-1 be the initial = condition.

o = Suppose Node (C) first is able to leave the DODAG and rejoin = at
a = lower rank, taking both Nodes (A) and (B) as DODAG parents = as
depicted= in Figure 3-2. Now Node (C) is deeper than both = Nodes
(A) = and (B), and Node (C) is satisfied to have 2 DODAG = parents.

o = Suppose Node (B), in its greediness, is willing to receive = and
process = a DIO message from Node (C) (against the rules of = RPL),
and = then Node (B) leaves the DODAG and rejoins at a lower = rank,
taking = both Nodes (A) and (C) as DODAG parents. Now Node (B) = is
deeper = than both Nodes (A) and (C) and is satisfied with 2 = DAG
parents.

o Then = Node (C), because it is also greedy, will leave = and
rejoin = deeper, to again get 2 parents and have a lower rank = then
both = of them.

o Next = Node (B) will again leave and rejoin deeper, to again = get
2 = parents

o And = again Node (C) leaves and rejoins = deeper...

o The = process will repeat, and the DODAG will oscillate = between
Figure = 3-2 and Figure 3-3 until the nodes count to infinity = and
restart = the cycle again.

o This = cycle can be averted through mechanisms in = RPL:

* = Nodes (B) and (C) stay at a rank sufficient to attach to = their
most = preferred parent (A) and don't go for any deeper = (worse)
alternate parents (Nodes are not = greedy)

* = Nodes (B) and (C) do not process DIO messages from = nodes
deeper = than themselves (because such nodes are possibly in = their
own = sub-DODAGs)





On Jul = 25, 2010, at 1:12 AM, Alexandru Petrescu = wrote:

Once a = node has joined a DODAG version, RPL = disallows
certain = behaviors, including greediness, in order to = prevent
resulting instabilities in the DODAG = version.

How? I searched for greed = further down the text and it does = not
appear.

This phrase sounds as if there = is a bit set on/off = called
'greed', or = similar.

I may be = wrong.

It is = for this reason that RPL limits the cases where a = node
<= blockquote type=3D"cite">
may = process DIO messages from deeper nodes to some forms = of
local = repair.

Which = forms?

'local repair' procedure is = mentioned several times in = the
draft:

On = receiving such a packet, a node institutes a local = repair
operation.
[...]
Strict = use of the DODAG Version Number can eliminate = this
<= blockquote type=3D"cite">
type = of loop, but this type of loop may possibly = be
encountered when using some local repair = mechanisms.

[...]
MaxRankIncrease: 16-bit unsigned integer used to = configure
DAGMaxRankIncrease, the allowable increase in rank in = support
of = local = repair.
[...]
o = Trigger a local = repair
[...]
o = Number of times a local repair procedure was = triggered

These are all the occurences of = "local repair". It reads as = an
operation, mechanism, procedure. = It is some form, = some.

But what is a local = repair?

Probably it is another term = explained elsewhere that I = can't
find while searching in this = draft, sorry if = so.

Alex = _______________________________________________ = Roll
mailing list Roll@ietf.org <mailto:Roll@ietf.org>
https://www.ietf.org/m= ailman/listinfo/roll






____= ___________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-8--961842749-- From mcr@sandelman.ca Mon Jul 26 03:38:22 2010 Return-Path: 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 2138C3A69F3 for ; Mon, 26 Jul 2010 03:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 2ga4+fU3az6J for ; Mon, 26 Jul 2010 03:38:21 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 2AEE23A69E8 for ; Mon, 26 Jul 2010 03:38:21 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 2E7A2345BB; Mon, 26 Jul 2010 06:38:42 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D8EF698A08; Mon, 26 Jul 2010 06:36:20 -0400 (EDT) From: Michael Richardson To: roll WG X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 26 Jul 2010 06:36:20 -0400 Message-ID: <6876.1280140580@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] RPL over "secured" lower-layers 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:38:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is has been much discussion in the 'Signature Consultation' over what it means to use vs rely on a lower layer security protocol. I ignore that discussion to ask a technical question. The RPL specification provides for three modes of operation (section 9.1): o Insecure. In this security mode, RPL uses insecure DIS, DIO, DAO, and DAO-Ack messages. o Pre-installed. In this security mode, RPL uses secure messages.... o Authenticated. In this security mode, RPL uses secure messages. ... To join the network as a router, a node must obtain a second key from a key authority. I'd just like to know how does one use and implement these multiple keys when running on top of a "secure" link-layer? Is there an implicit requirement for the secure radio layer to indicate to upper layers which key is being used? Do all radios support use of multiple simultaneous keys, and permit the upper layers to specify which key to use to send a particular message? Seems like there is a series of drafts (RPL-over-FOO) missing here. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTE1lI4CLcPvd0N1lAQIpUAf/dUNVgt0YrRtQusuDwnmTzzB4aFTzIRRc XD5pYQN8IrqTiCzVh5akkDzt20zcu7nj9mddbeugJ8/Q3yFGSiS5FhE5+FJ+0xdZ BK/KYZ0uUHXtaewTYqFgEZuteGwYD8QaE0O/gcGkUiAY/OYu7my+L/sfdsaff6em koHzc/b7zVDn0OQ3anx6LOAlNej/0JXwbVyYYPJ0/6D1N1tCYSx+T/7c6oGi+9q9 Md740CRLC9CviIdjcIqtopLBzFXyo9g3Q0lH7lx64xdwHIEpKzPfIRF52YYOhQpW c4fRMBE1Z31Ksk9CYIet5Q4aVVy+YEccB0G7D9GHb3ogZg/E5K/xEg== =oOw5 -----END PGP SIGNATURE----- From culler@cs.berkeley.edu Mon Jul 26 03:54:01 2010 Return-Path: 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 F1F253A68C3 for ; Mon, 26 Jul 2010 03:54:01 -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=[AWL=0.000, 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 bwqqWJKIAeXW for ; Mon, 26 Jul 2010 03:54:01 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id F02843A69F0 for ; Mon, 26 Jul 2010 03:54:00 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QAs84I017660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 03:54:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <4C4C0775.3040204@gmail.com> Date: Mon, 26 Jul 2010 03:54:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C4C0775.3040204@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: ROLL WG , "David E. Culler" Subject: Re: [Roll] WG is a first class reviewer, not second 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: , X-List-Received-Date: Mon, 26 Jul 2010 10:54:02 -0000 Alex, I do not understand what is your current disappointment, but let me = clarify. In the IETF, decisions are made through rough consensus AND = running code. That process is conducted through the WG email. (That is = why it is important to exercise care and though in posting to the list.) = The RPL DT was formed after several ID's presented alternative protocol = approaches. It include broad representation from the WG. It was = dissolved when the initial RPL draft was accepted as a WG document. As = the refine process proceeded, certain other members of the WG who = contributed very substantially joined in as authors and some less = involved dropped out. All 10 versions of the RPL spec have been = extensively reviewed by the working group. We are currently in LC on = 10. While the comments have been coming in, the authors have been = addressing them. All of those fixes will appear in 11. Of course you = need to freeze a version of the document to obtain comments. This is = precisely to avoid it being a moving target. Of course, those changes = will be reflected in the next version. Of course, you can start working = on that before the very last ticket appears. =20 So is your concern that the authors are doing their job and preparing = the response to LC on 10 in order to produce the resolution in 11 in a = timely fashion? I'm glad to hear that you are concerned about wasting time. To avoid = wasting the time of all the members of the WG, each individual must = think carefully through the questions he/she posts to the list. We = encourage all questions and clarifications, but the more well formed the = post, to more useful the response. On Jul 25, 2010, at 2:44 AM, Alexandru Petrescu wrote: > Chairs, >=20 > With all due respect - I would like to express disappointment. >=20 > I consider the WG as a first class reviewer, not second. I thought = the > DT was closed and discussion happened on the WG list exclusively. > Spinning a private 11 version draft and asking for reviewing the = public > 10 draft is not kind to reviewer - it makes her/him waste a good = amount > of time. >=20 > I copy the list to show that list is important. >=20 > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jul 26 06:43:55 2010 Return-Path: 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 9D5763A6C04 for ; Mon, 26 Jul 2010 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 w9jt4tiLBgGJ for ; Mon, 26 Jul 2010 06:43:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D3F7F3A6BFE for ; Mon, 26 Jul 2010 06:43:53 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,261,1278288000"; d="scan'208";a="230731064" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2010 13:44:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6QDhmbP027703; Mon, 26 Jul 2010 13:44:10 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 15:44:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 26 Jul 2010 15:44:03 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D026AC79A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing #74: Edits on Option Length on Figures (was:Edits) thread-index: AcssyJuHX5VQ9kWAQUGQRJJJPVgewA== From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 26 Jul 2010 13:44:06.0947 (UTC) FILETIME=[9E33D730:01CB2CC8] Subject: [Roll] Closing #74: Edits on Option Length on Figures (was:Edits) 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: , X-List-Received-Date: Mon, 26 Jul 2010 13:43:55 -0000 SGkNCg0KV2UnbGwgbm90IHRoYXQgdGhlIGdlbmVyYWwgZm9ybSBvZiB0aGUgb3B0aW9uIGxlbmd0 aCBpcyBhbHJlYWR5IHNwZWxsZWQgb3V0IA0KIg0KICAgUlBMIENvbnRyb2wgTWVzc2FnZSBPcHRp b25zIGFsbCBmb2xsb3cgdGhpcyBmb3JtYXQ6DQoNCiAgICAgICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDINCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstIC0gLSAtIC0gLSAtIC0NCiAgICAgICB8ICBPcHRpb24gVHlwZSAgfCBPcHRpb24g TGVuZ3RoIHwgT3B0aW9uIERhdGENCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstIC0gLSAtIC0gLSAtIC0NCg0KICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOTogUlBM IE9wdGlvbiBHZW5lcmljIEZvcm1hdA0KDQogICBPcHRpb24gVHlwZTogIDgtYml0IGlkZW50aWZp ZXIgb2YgdGhlIHR5cGUgb2Ygb3B0aW9uLiAgVGhlIE9wdGlvbg0KICAgICAgICAgVHlwZSB2YWx1 ZXMgYXJlIHRvIGJlIGNvbmZpcm1lZCBieSBJQU5BIFNlY3Rpb24gMTkuNC4NCg0KICAgT3B0aW9u IExlbmd0aDogIDgtYml0IHVuc2lnbmVkIGludGVnZXIsIHJlcHJlc2VudGluZyB0aGUgbGVuZ3Ro IGluDQogICAgICAgICBvY3RldHMgb2YgdGhlIG9wdGlvbiwgbm90IGluY2x1ZGluZyB0aGUgT3B0 aW9uIFR5cGUgYW5kIExlbmd0aA0KICAgICAgICAgZmllbGRzLg0KDQoiDQoNClNvIHdlIHNob3Vs ZCBub3QgcmVwZWF0IHRoYXQuIA0KT1RPSCwgdGhlIHdheSB0aGUgbGVuZ3RoIHdhcyBleHByZXNz ZWQgd2FzIG5vdCBjb25zaXN0ZW50Lg0KU28gdGhlIHByb3Bvc2FsIGlzIGZvciBhbGwgb3B0aW9u cyB0aGF0IGhhdmUgYSBjb25zdGFudCB2YWx1ZSwgdG8gdXNlIGEgc2FtZSBmb3JtLg0KDQpXZSBj b3VsZCB1c2Ugc29tZXRoaW5nIGxpa2U6DQoNCiINCiAgIE9wdGlvbiBUeXBlOiAgMHgwNCAodG8g YmUgY29uZmlybWVkIGJ5IElBTkEpDQoNCiAgIE9wdGlvbiBMZW5ndGg6ICAxNA0KIg0KDQpPciBz b21ldGhpbmcgbGlrZToNCg0KIg0KICAgT3B0aW9uIFR5cGU6ICAweDA0ICh0byBiZSBjb25maXJt ZWQgYnkgSUFOQSkNCg0KICAgT3B0aW9uIExlbmd0aDogIFRoaXMgZmllbGQgIE1VU1QgYmUgc2V0 IHRvIDE2Lg0KIg0KDQpJIHRlbmQgdG8gZmF2b3IgdGhlIGZvcm1lciwgYXMgcHJvcG9zZWQgaW4g SlAncyBtYWlsLiANCg0KQXMgdXN1YWwsIHlvdSBkaXNhZ3JlZSB3aXRoIHRoaXMgcmVzb2x1dGlv biBwbGVhc2Ugc3BlYWsgdXAgOiApDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygcm9sbA0KPiBpc3N1ZSB0cmFja2VyDQo+IFNlbnQ6 IE1vbmRheSwgSnVseSAyNiwgMjAxMCAxMDo0OCBBTQ0KPiBUbzogd2ludGVydEBhY20ub3JnOyBq cHZAY2lzY28uY29tDQo+IENjOiByb2xsQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0g W3JvbGxdICM3NDogRWRpdHMgb24gT3B0aW9uIExlbmd0aCBvbiBGaWd1cmVzICh3YXM6RWRpdHMp DQo+IA0KPiAjNzQ6IEVkaXRzIG9uIE9wdGlvbiBMZW5ndGggb24gRmlndXJlcw0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ICBSZXBvcnRlcjogIGpwdkDigKYgICAgICAgICAgICB8ICAgICAgIE93 bmVyOiAgd2ludGVydEDigKYNCj4gICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICB8ICAgICAg U3RhdHVzOiAgbmV3DQo+ICBQcmlvcml0eTogIHRyaXZpYWwgICAgICAgICAgfCAgIE1pbGVzdG9u ZToNCj4gQ29tcG9uZW50OiAgcnBsICAgICAgICAgICAgICB8ICAgICBWZXJzaW9uOg0KPiAgU2V2 ZXJpdHk6ICBJbiBXRyBMYXN0IENhbGwgIHwgICAgS2V5d29yZHM6DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gRGVzY3JpcHRpb24gY2hhbmdlZCBieSBqcHZA4oCmOg0KPiANCj4gT2xkIGRlc2Ny aXB0aW9uOg0KPiANCj4gPiBGcm9tOiBKUCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPg0KPiA+IERh dGU6IEp1bHkgMjYsIDIwMTAgMTA6Mzc6NTQgQU0gQ0VEVA0KPiA+IFRvOiBZb2F2IEJlbi1ZZWhl emtlbCA8eW9hdkB5aXRyYW4uY29tPg0KPiA+IENjOiByb2xsQGlldGYub3JnDQo+ID4gU3ViamVj dDogUmU6IFtSb2xsXSBzbWFsbCBjb21tZW50IG9uIERJUyBmb3JtYXQNCj4gPg0KPiA+IEhpIFlv YXYsDQo+ID4NCj4gPiBPbiBKdWwgMjYsIDIwMTAsIGF0IDEwOjE5IEFNLCBZb2F2IEJlbi1ZZWhl emtlbCB3cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gSSBmb3VuZCBhIHNtYWxsIGVkaXRv cmlhbCBmaXggaW4gdGhlIGRlc2NyaXB0aW9uIG9mIOKAnE9wdGlvbiBMZW5ndGjigJ0gZmllbGQN Cj4gPiBpbiB0aGUgU0lPIGRlc2NyaXB0aW9uLg0KPiA+DQo+ID4gUmlnaHQgbm93IHRoZSBkZXNj cmlwdGlvbiBzYXlzIE9wdGlvbiBMZW5ndGggMTkgYnl0ZXMsIHdoaWNoIEkgdGhpbmsNCj4gPiBs aXR0bGUgbWlzbGVhZGluZy4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgaXQgc2hvdWxkIGJl IHNheWluZyB0aGF0DQo+ID4gdGhlIGxlbmd0aCBvZiB0aGUgZmllbGQgaXMgMSBieXRlIGFuZCBp dHMgdmFsdWUgc2hhbGwgYmUgc2V0IHRvIDE5LA0KPiA+IHJpZ2h0Pw0KPiA+DQo+IA0KPiA+IFdl bGwsIGluIFNlY3Rpb24gNS43LjEsIHRoaXMgaXMgYWN0dWFsbHkgY2xhcmlmaWVkOg0KPiA+DQo+ ID4gNS43LjEuICBSUEwgQ29udHJvbCBNZXNzYWdlIE9wdGlvbiBHZW5lcmljIEZvcm1hdA0KPiA+ DQo+ID4gICAgUlBMIENvbnRyb2wgTWVzc2FnZSBPcHRpb25zIGFsbCBmb2xsb3cgdGhpcyBmb3Jt YXQ6DQo+ID4NCj4gPiAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAg ICAgICAyDQo+ID4gICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMw0KPiA+ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst IC0gLSAtIC0gLSAtIC0NCj4gPiAgICAgICAgfCAgT3B0aW9uIFR5cGUgIHwgT3B0aW9uIExlbmd0 aCB8IE9wdGlvbiBEYXRhDQo+ID4gICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0gLSAtIC0gLSAtIC0gLQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAx NDogUlBMIE9wdGlvbiBHZW5lcmljIEZvcm1hdA0KPiA+DQo+ID4gICAgT3B0aW9uIFR5cGU6ICA4 LWJpdCBpZGVudGlmaWVyIG9mIHRoZSB0eXBlIG9mIG9wdGlvbi4gIFRoZSBPcHRpb24NCj4gPiAg ICAgICAgICBUeXBlIHZhbHVlcyBhcmUgdG8gYmUgY29uZmlybWVkIGJ5IHRoZSBJQU5BIFNlY3Rp b24gMTguNC4NCj4gPg0KPiA+ICAgIE9wdGlvbiBMZW5ndGg6ICA4LWJpdCB1bnNpZ25lZCBpbnRl Z2VyLCByZXByZXNlbnRpbmcgdGhlIGxlbmd0aCBpbg0KPiA+ICAgICAgICAgIG9jdGV0cyBvZiB0 aGUgb3B0aW9uLCBub3QgaW5jbHVkaW5nIHRoZSBPcHRpb24gVHlwZSBhbmQgTGVuZ3RoDQo+ID4g ICAgICAgICAgZmllbGRzLg0KPiA+DQo+ID4gICAgT3B0aW9uIERhdGE6ICBBIHZhcmlhYmxlIGxl bmd0aCBmaWVsZCB0aGF0IGNvbnRhaW5zIGRhdGEgc3BlY2lmaWMgdG8NCj4gPiAgICAgICAgICB0 aGUgb3B0aW9uLg0KPiA+DQo+ID4gQnV0IEkgc2VlIHlvdXIgcG9pbnQsIHdoYXQgd2Ugc2hvdWxk IGJlIGRvaW5nIGlzIHRvIHB1dCB0aGUgbnVtYmVyIDE5IGluDQo+ID4gdGhlIGZpZ3VyZS4NCj4g Pg0KPiA+IEluIG90aGVyIHdvcmRzLCBmb3IgZWFjaCBmaWd1cmU6DQo+ID4gT3B0aW9uIExlbmdo dCAoMSBieXRlKTogMTkNCj4gPiArDQo+ID4gc2hvd3MgdGhlIG51bWJlciAod2hlbiB3ZSBoYXZl IGEgZml4ZWQgbnVtYmVyKSBvbiB0aGUgZmlndXJlLg0KPiA+DQo+ID4gV291bGQgdGhhdCBjbGFy aWZ5ID8NCj4gPg0KPiA+IFRoYW5rcy4NCj4gPg0KPiA+IEpQLg0KPiA+DQo+ID4gUmVnYXJkcywN Cj4gPiBZb2F2DQo+ID4NCj4gDQo+ID4gNS43LjkuICBTb2xpY2l0ZWQgSW5mb3JtYXRpb24NCj4g Pg0KPiA+IC4uLg0KPiA+DQo+ID4gICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+ID4gICAgICAgICAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4g PiAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICAgfCAgIFR5cGUgPSA3ICAgIHwgT3B0aW9uIExl bmd0aCB8IFJQTEluc3RhbmNlSUQgfFZ8SXxEfCAgUnN2ZCAgIHwNCj4gPiAgICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gPiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCj4gPiAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCj4gPiAgICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICBET0RBR0lE ICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCj4gPiAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAg ICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICsNCj4gPiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gPiAgICAgICAgfCAgICBWZXJzaW9uICAgIHwNCj4gPiAgICAgICAgKy0rLSstKy0rLSstKy0r LSsNCj4gPg0KPiA+ICAgICAgICAgICAgRmlndXJlIDIyOiBGb3JtYXQgb2YgdGhlIFNvbGljaXRl ZCBJbmZvcm1hdGlvbiBPcHRpb24NCj4gPiAuLi4NCj4gPg0KPiA+ICAgIE9wdGlvbiBMZW5ndGg6 ICAxOSBieXRlcw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+IFJvbGxAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gUm9sbCBt YWlsaW5nIGxpc3QNCj4gPiBSb2xsQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQo+IA0KPiBOZXcgZGVzY3JpcHRpb246DQo+IA0KPiAgRnJv bTogSlAgVmFzc2V1ciA8anB2QGNpc2NvLmNvbT4NCj4gIERhdGU6IEp1bHkgMjYsIDIwMTAgMTA6 Mzc6NTQgQU0gQ0VEVA0KPiAgVG86IFlvYXYgQmVuLVllaGV6a2VsIDx5b2F2QHlpdHJhbi5jb20+ DQo+ICBDYzogcm9sbEBpZXRmLm9yZw0KPiAgU3ViamVjdDogUmU6IFtSb2xsXSBzbWFsbCBjb21t ZW50IG9uIERJUyBmb3JtYXQNCj4gDQo+ICBIaSBZb2F2LA0KPiANCj4gIE9uIEp1bCAyNiwgMjAx MCwgYXQgMTA6MTkgQU0sIFlvYXYgQmVuLVllaGV6a2VsIHdyb3RlOg0KPiANCj4gIEhpLA0KPiAN Cj4gIEkgZm91bmQgYSBzbWFsbCBlZGl0b3JpYWwgZml4IGluIHRoZSBkZXNjcmlwdGlvbiBvZiDi gJxPcHRpb24gTGVuZ3Ro4oCdIGZpZWxkDQo+ICBpbiB0aGUgU0lPIGRlc2NyaXB0aW9uLg0KPiAN Cj4gIFJpZ2h0IG5vdyB0aGUgZGVzY3JpcHRpb24gc2F5cyBPcHRpb24gTGVuZ3RoIDE5IGJ5dGVz LCB3aGljaCBJIHRoaW5rDQo+ICBsaXR0bGUgbWlzbGVhZGluZy4gSWYgSSB1bmRlcnN0YW5kIGNv cnJlY3RseSwgaXQgc2hvdWxkIGJlIHNheWluZyB0aGF0IHRoZQ0KPiAgbGVuZ3RoIG9mIHRoZSBm aWVsZCBpcyAxIGJ5dGUgYW5kIGl0cyB2YWx1ZSBzaGFsbCBiZSBzZXQgdG8gMTksIHJpZ2h0Pw0K PiANCj4gDQo+ICBXZWxsLCBpbiBTZWN0aW9uIDUuNy4xLCB0aGlzIGlzIGFjdHVhbGx5IGNsYXJp ZmllZDoNCj4gDQo+ICA1LjcuMS4gIFJQTCBDb250cm9sIE1lc3NhZ2UgT3B0aW9uIEdlbmVyaWMg Rm9ybWF0DQo+IA0KPiAgICAgUlBMIENvbnRyb2wgTWVzc2FnZSBPcHRpb25zIGFsbCBmb2xsb3cg dGhpcyBmb3JtYXQ6DQo+IA0KPiAgICAgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMg0KPiAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMw0KPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0gLSAtIC0gLSAtIC0gLQ0KPiAgICAgICAgIHwgIE9wdGlvbiBUeXBlICB8IE9wdGlvbiBM ZW5ndGggfCBPcHRpb24gRGF0YQ0KPiAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0gLSAtIC0gLSAtIC0gLQ0KPiANCj4gICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MTQ6IFJQTCBPcHRpb24gR2VuZXJpYyBGb3JtYXQNCj4gDQo+ICAgICBPcHRpb24gVHlwZTogIDgt Yml0IGlkZW50aWZpZXIgb2YgdGhlIHR5cGUgb2Ygb3B0aW9uLiAgVGhlIE9wdGlvbg0KPiAgICAg ICAgICAgVHlwZSB2YWx1ZXMgYXJlIHRvIGJlIGNvbmZpcm1lZCBieSB0aGUgSUFOQSBTZWN0aW9u IDE4LjQuDQo+IA0KPiAgICAgT3B0aW9uIExlbmd0aDogIDgtYml0IHVuc2lnbmVkIGludGVnZXIs IHJlcHJlc2VudGluZyB0aGUgbGVuZ3RoIGluDQo+ICAgICAgICAgICBvY3RldHMgb2YgdGhlIG9w dGlvbiwgbm90IGluY2x1ZGluZyB0aGUgT3B0aW9uIFR5cGUgYW5kIExlbmd0aA0KPiAgICAgICAg ICAgZmllbGRzLg0KPiANCj4gICAgIE9wdGlvbiBEYXRhOiAgQSB2YXJpYWJsZSBsZW5ndGggZmll bGQgdGhhdCBjb250YWlucyBkYXRhIHNwZWNpZmljIHRvDQo+ICAgICAgICAgICB0aGUgb3B0aW9u Lg0KPiANCj4gIEJ1dCBJIHNlZSB5b3VyIHBvaW50LCB3aGF0IHdlIHNob3VsZCBiZSBkb2luZyBp cyB0byBwdXQgdGhlIG51bWJlciAxOSBpbg0KPiAgdGhlIGZpZ3VyZS4NCj4gDQo+ICBJbiBvdGhl ciB3b3JkcywgZm9yIGVhY2ggZmlndXJlOg0KPiAgT3B0aW9uIExlbmdodCAoMSBieXRlKTogMTkN Cj4gICsNCj4gIHNob3dzIHRoZSBudW1iZXIgKHdoZW4gd2UgaGF2ZSBhIGZpeGVkIG51bWJlcikg b24gdGhlIGZpZ3VyZS4NCj4gDQo+ICBXb3VsZCB0aGF0IGNsYXJpZnkgPw0KPiANCj4gIFRoYW5r cy4NCj4gDQo+ICBKUC4NCj4gDQo+ICBSZWdhcmRzLA0KPiAgWW9hdg0KPiANCj4gDQo+ICA1Ljcu OS4gIFNvbGljaXRlZCBJbmZvcm1hdGlvbg0KPiANCj4gIC4uLg0KPiANCj4gICAgICAgICAgMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg Mw0KPiAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCj4gICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgICAgIHwgICBU eXBlID0gNyAgICB8IE9wdGlvbiBMZW5ndGggfCBSUExJbnN0YW5jZUlEIHxWfEl8RHwgIFJzdmQg ICB8DQo+ICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArDQo+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICArICAgICAgICAgICAgICAgICAg ICAgICAgICAgIERPREFHSUQgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KPiAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQo+ICAgICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCj4gICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQo+ICAgICAgICAgfCAgICBWZXJzaW9uICAgIHwNCj4gICAgICAgICArLSst Ky0rLSstKy0rLSstKw0KPiANCj4gICAgICAgICAgICAgRmlndXJlIDIyOiBGb3JtYXQgb2YgdGhl IFNvbGljaXRlZCBJbmZvcm1hdGlvbiBPcHRpb24NCj4gIC4uLg0KPiANCj4gICAgIE9wdGlvbiBM ZW5ndGg6ICAxOSBieXRlcw0KPiANCj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ICBSb2xsIG1haWxpbmcgbGlzdA0KPiAgUm9sbEBpZXRmLm9yZw0K PiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+IA0KPiAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gIFJvbGwgbWFp bGluZyBsaXN0DQo+ICBSb2xsQGlldGYub3JnDQo+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGwNCj4gDQo+IC0tDQo+IA0KPiAtLQ0KPiBUaWNrZXQgVVJMOiA8aHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC90cmFjL3RpY2tldC83NCNjb21tZW50OjE+ DQo+IHJvbGwgPGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9yb2xsLz4NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBs aXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yb2xsDQo= From alexandru.petrescu@gmail.com Mon Jul 26 06:48:13 2010 Return-Path: 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 6C7463A6BB7 for ; Mon, 26 Jul 2010 06:48:13 -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 5yFEITe7ZocR for ; Mon, 26 Jul 2010 06:48:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6CBD13A69F8 for ; Mon, 26 Jul 2010 06:48:11 -0700 (PDT) Received: by bwz7 with SMTP id 7so3319192bwz.31 for ; Mon, 26 Jul 2010 06:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Bp/lGyNbte8h4VSl5J9WiUbTvWpNJCe13xmRJYnym4I=; b=afFfzLAlxNGodgWhgrrPKTTiBAr6Zf4loWut5eU/F/6M0bwAh8E6Wfh02SRN1roxdc UHMLykSckxsnZSTObLXziVVBoe76Pxlqy5MXAv8boLP80IVM35KpHUG6L4FajdBEdWGP 7l9RN+aIMSnc+NhhLwnoEg61YHS5qf4bm6K9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lf6IVF0n7nEZrxByL+BE3kD2t3NF6FvS5YO4IvIzGPso4QOAl1j/DUxZF3QDYiRPBz zLa7ZYVeN6ZzdCtR2sphUH5owmNtvUJPIcvLsLQqJvkxu1LzM0rBWlPCTUeSt7XbOyIF TPRpEvs3tI45F/uS0mtTsr27rGUtVqsM1fgdk= MIME-Version: 1.0 Received: by 10.204.82.80 with SMTP id a16mr5659938bkl.39.1280152111906; Mon, 26 Jul 2010 06:48:31 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Mon, 26 Jul 2010 06:48:31 -0700 (PDT) Date: Mon, 26 Jul 2010 15:48:31 +0200 Message-ID: From: Alexandru Petrescu To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] misunderstanding (was: WG is a first class reviewer, not second) 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: , X-List-Received-Date: Mon, 26 Jul 2010 13:48:13 -0000 David - there may have been a misundertsanding, sorry on my side.=A0 I will try to better understand who are the authours and the respective technical aspects. Let's see further, Alex Le 26/07/2010 12:54, David Culler a =E9crit : > Alex, I do not understand what is your current disappointment, but > let me clarify.=A0 In the IETF, decisions are made through rough > consensus AND running code.=A0 That process is conducted through the > WG email.=A0 (That is why it is important to exercise care and though > in posting to the list.)=A0 The RPL DT was formed after several ID's > presented alternative protocol approaches.=A0 It include broad > representation from the WG.=A0 It was dissolved when the initial RPL > draft was accepted as a WG document.=A0 As the refine process > proceeded, certain other members of the WG who contributed very > substantially joined in as authors and some less involved dropped > out.=A0 All 10 versions of the RPL spec have been extensively reviewed > by the working group.=A0 We are currently in LC on 10.=A0 While the > comments have been coming in, the authors have been addressing them. > All of those fixes will appear in 11.=A0 Of course you need to freeze > a version of the document to obtain comments.=A0 This is precisely to > avoid it being a moving target.=A0 Of course, those changes will be > reflected in the next version.=A0 Of course, you can start working on > that before the very last ticket appears. > > So is your concern that the authors are doing their job and > preparing the response to LC on 10 in order to produce the resolution > in 11 in a timely fashion? > > I'm glad to hear that you are concerned about wasting time.=A0 To > avoid wasting the time of all the members of the WG, each individual > must think carefully through the questions he/she posts to the list. > We encourage all questions and clarifications, but the more well > formed the post, to more useful the response. > > > On Jul 25, 2010, at 2:44 AM, Alexandru Petrescu wrote: > >> Chairs, >> >> With all due respect - I would like to express disappointment. >> >> I consider the WG as a first class reviewer, not second.=A0 I >> thought the DT was closed and discussion happened on the WG list >> exclusively. Spinning a private 11 version draft and asking for >> reviewing the public 10 draft is not kind to reviewer - it makes >> her/him waste a good amount of time. >> >> I copy the list to show that list is important. >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From ajakuma2@cisco.com Mon Jul 26 07:18:07 2010 Return-Path: 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 59C153A687C for ; Mon, 26 Jul 2010 07:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 TPV6i77z7aAR for ; Mon, 26 Jul 2010 07:18:04 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0287A3A68F3 for ; Mon, 26 Jul 2010 07:18:04 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEHALo1TUxAaHte/2dsb2JhbACBRJFZjEdxp22aO4U2BIQGhxgMAQ X-IronPort-AV: E=Sophos;i="4.55,261,1278288000"; d="scan'208,217";a="162958013" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 26 Jul 2010 14:18:24 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6QEINTc005487 for ; Mon, 26 Jul 2010 14:18:23 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 19:48:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2CCD.67DA3F64" Date: Mon, 26 Jul 2010 19:48:20 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01802115CC4@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Option Len Field mismatch in metric doc. Thread-Index: AcsszWZiDXaPTSLWSq+BH43H5WYZZg== From: "Ajay Kumar (ajakuma2)" To: X-OriginalArrivalTime: 26 Jul 2010 14:18:23.0908 (UTC) FILETIME=[683F2E40:01CB2CCD] Subject: [Roll] Option Len Field mismatch in metric doc. 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: , X-List-Received-Date: Mon, 26 Jul 2010 14:18:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CCD.67DA3F64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, =20 I see following text in roll-metric draft. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Type=3D2 | Option Len | Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 1: DAG Metric Container format =20 This is from core RPL spec. =20 The Routing Metric/Contraints objects have a common format consisting of one or more 8-bit words with a common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 How can the Length field in Metric Container Format accommodate Length specified in Common header that follows? =20 I believe the value in second field cannot be greater than 253 leaving out(Routin-MC-Type & Flags).=20 =20 Please ignore of it has already been pointed out. =20 Regards, Ajay =20 =20 =20 ------_=_NextPart_001_01CB2CCD.67DA3F64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I see following text in roll-metric draft.

 

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+ ...

| Type=3D2 | Option Len | Routing Metric/Constraint = objects

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+ ...

Figure 1: DAG Metric Container = format

 

This is from core RPL spec.

 

The Routing Metric/Contraints objects have a common = format consisting

of one or more 8-bit words with a common = header:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

|Routing-MC-Type|Res|R|G| A |O|C| Object Length = (bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+

| |

// (object body) //

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

How can the Length field in Metric Container Format = accommodate Length specified in Common header that follows?

 

I believe the value in second field cannot be = greater than 253 leaving out(Routin-MC-Type & Flags).

 

Please ignore of it has already been pointed = out.

 

Regards,

Ajay

=

 

 

 

------_=_NextPart_001_01CB2CCD.67DA3F64-- From mcr@sandelman.ca Mon Jul 26 08:53:21 2010 Return-Path: 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 F1CB83A6908 for ; Mon, 26 Jul 2010 08:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 N0HuX-twkxYZ for ; Mon, 26 Jul 2010 08:53:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DF4623A6880 for ; Mon, 26 Jul 2010 08:53:16 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 9CBE83450D for ; Mon, 26 Jul 2010 11:53:37 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D086598A08 for ; Mon, 26 Jul 2010 11:51:15 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 26 Jul 2010 11:51:15 -0400 Message-ID: <14763.1280159475@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] ECDH IPR issues 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: , X-List-Received-Date: Mon, 26 Jul 2010 15:53:21 -0000 At the 6lowpan meeting this morning Bob Moskowitz talked about HIP, and the ECDH mode. I asked him about any IPR issues with this mode. His answer was to see: http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-03.txt He suggests that: > But generally, we ARE expecting this to come through as IPR free. > Of course there are ECC parameters that themselves have IPR claims. > This does NOT include the NIST or RFC 5639 parameters. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jpv@cisco.com Mon Jul 26 09:11:42 2010 Return-Path: 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 46DE13A6C47 for ; Mon, 26 Jul 2010 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.265 X-Spam-Level: X-Spam-Status: No, score=-9.265 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 3mvXVG3pK0y2 for ; Mon, 26 Jul 2010 09:11:36 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7F7833A6C45 for ; Mon, 26 Jul 2010 09:11:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOtQTUxAaHte/2dsb2JhbACBRJ4ccahlmmaFNgSIZII6DAE X-IronPort-AV: E=Sophos;i="4.55,262,1278288000"; d="scan'208,217";a="230805703" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2010 16:11:48 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6QGAijG025104 for ; Mon, 26 Jul 2010 16:11:47 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 21:41:33 +0530 Received: from dhcp-60f4.meeting.ietf.org ([10.61.96.235]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 21:41:32 +0530 Message-Id: <86579FC7-E74B-4C66-B753-82AE16DDDB9F@cisco.com> From: JP Vasseur To: Ajay Kumar (ajakuma2) In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC01802115CC4@XMB-BGL-41B.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4--942586899 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 17:56:47 +0200 References: <454A16E4DA86094EB66BB2C1DBBBC01802115CC4@XMB-BGL-41B.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Jul 2010 16:11:32.0588 (UTC) FILETIME=[369D8AC0:01CB2CDD] Cc: roll@ietf.org Subject: Re: [Roll] Option Len Field mismatch in metric doc. 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: , X-List-Received-Date: Mon, 26 Jul 2010 16:11:42 -0000 --Apple-Mail-4--942586899 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Ajay, On Jul 26, 2010, at 4:18 PM, Ajay Kumar (ajakuma2) wrote: > Hi WG, > > I see following text in roll-metric draft. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + ... > | Type=2 | Option Len | Routing Metric/Constraint objects > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > + ... > Figure 1: DAG Metric Container format > > This is from core RPL spec. > > The Routing Metric/Contraints objects have a common format consisting > of one or more 8-bit words with a common header: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > // (object body) // > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > How can the Length field in Metric Container Format accommodate > Length specified in Common header that follows? > > I believe the value in second field cannot be greater than 253 > leaving out(Routin-MC-Type & Flags). > > Please ignore of it has already been pointed out. Good catch, thanks. The change in the RPL ID has not been reflected in the metric-ID. We changed it in the RPL spec (this is why we can have more than one container) but not yet in the metric-ID. It will be fixed in metric-ID version 9. Thanks for the comments. > > Regards, > Ajay > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-4--942586899 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Ajay,

On = Jul 26, 2010, at 4:18 PM, Ajay Kumar (ajakuma2) wrote:

Hi WG,
I = see following text in roll-metric draft.
0 1 2 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4
| Type=3D2 | Option Len | Routing = Metric/Constraint objects
Figure 1: DAG Metric Container = format
 
This is from core RPL = spec. 
The Routing = Metric/Contraints objects have a common format = consisting
of one or more 8-bit words with a common = header:
0 1 2 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
|Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) = |
| |
// (object body) = //
| |
 
How can the Length = field in Metric Container Format accommodate Length specified in Common = header that follows?
 
I = believe the value in second field cannot be greater than 253 leaving = out(Routin-MC-Type & Flags).
Please ignore of it has already been = pointed = out.

Good = catch, thanks. The change in the RPL ID has not been reflected in the = metric-ID. We changed it in the RPL
spec (this is why we can = have more than one container) but not yet in the metric-ID. It will be = fixed in metric-ID
version 9. Thanks for the = comments.

Regards,
 
In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC01802115CC4@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Option Len Field mismatch in metric doc. Thread-Index: AcsszWZiDXaPTSLWSq+BH43H5WYZZgAEbWHg References: <454A16E4DA86094EB66BB2C1DBBBC01802115CC4@XMB-BGL-41B.cisco.com> From: To: , X-OriginalArrivalTime: 26 Jul 2010 16:30:09.0421 (UTC) FILETIME=[D04CBBD0:01CB2CDF] Subject: Re: [Roll] Option Len Field mismatch in metric doc. 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: , X-List-Received-Date: Mon, 26 Jul 2010 16:29:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2CDF.CFB1CC48 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Ajay, =20 Good catch! The RPL option length was recently adjusted to express length in bytes = (as opposed to in 8 bytes chunks) so, definitely, the DAG Metric = Container length field (expressing length in bytes) does not need to be = more than 8 bits long. We'll take this into account for -09. Thanks =20 Dominique ________________________________ De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Ajay Kumar (ajakuma2) Envoy=E9 : lundi 26 juillet 2010 16:18 =C0 : roll@ietf.org Objet : [Roll] Option Len Field mismatch in metric doc. Hi WG, =20 I see following text in roll-metric draft. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ... | Type=3D2 | Option Len | Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ... Figure 1: DAG Metric Container format =20 This is from core RPL spec. =20 The Routing Metric/Contraints objects have a common format consisting of one or more 8-bit words with a common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 How can the Length field in Metric Container Format accommodate Length = specified in Common header that follows? =20 I believe the value in second field cannot be greater than 253 leaving = out(Routin-MC-Type & Flags).=20 =20 Please ignore of it has already been pointed out. =20 Regards, Ajay =20 =20 =20 ------_=_NextPart_001_01CB2CDF.CFB1CC48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Ajay,
 
Good catch!
The RPL option length was recently adjusted to = express length=20 in bytes (as opposed to in 8 bytes chunks) so, definitely, the DAG = Metric=20 Container length field (expressing length in bytes) does not need = to be=20 more than 8 bits long.
We'll take this into account for = -09.
Thanks
 
Dominique

De : roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] De la part de Ajay Kumar=20 (ajakuma2)
Envoy=E9 : lundi 26 juillet 2010=20 16:18
=C0 : roll@ietf.org
Objet : [Roll] = Option Len=20 Field mismatch in metric doc.

Hi WG,

 

I see following = text in=20 roll-metric draft.

 

0 1 2=20 3

0 1 2 3 4=20 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3=20 4

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+=20 ...

| Type=3D2=20 | Option Len | Routing Metric/Constraint objects

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+=20 ...

Figure 1:=20 DAG Metric Container format

 

This is from core = RPL=20 spec.

 

The=20 Routing Metric/Contraints objects have a common format=20 consisting

of one or=20 more 8-bit words with a common header:

0 1 2=20 3

0 1 2 3 4=20 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Routing-MC-Type|Res|R|G| A |O|C|=20 Object Length (bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|=20 |

//=20 (object body) //

|=20 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

How can the Length field in Metric Container Format = accommodate Length specified in Common header that = follows?

 

I believe the value in second field cannot be = greater than=20 253 leaving out(Routin-MC-Type & Flags).

 

Please ignore of it has already been pointed=20 out.

 

Regards,

Ajay

 

 

 

------_=_NextPart_001_01CB2CDF.CFB1CC48-- From alexandru.petrescu@gmail.com Mon Jul 26 09:42:25 2010 Return-Path: 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 57A733A657C for ; Mon, 26 Jul 2010 09:42:25 -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 47z8O6MdltWk for ; Mon, 26 Jul 2010 09:42:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id E805B3A6CCC for ; Mon, 26 Jul 2010 09:39:27 -0700 (PDT) Received: by bwz7 with SMTP id 7so3424586bwz.31 for ; Mon, 26 Jul 2010 09:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=AkOmSMLpTsm7gGM3vLFjaRtMR8ClvTtbqnMZCgTg3D8=; b=Etbc9sQKGYnwWgnkDmI0o7oWxM/rQ/WzYTkQgZW/0X5nA0xcw4hzteTktal7NLU6bA UZvxK7hBuMGHfgVQ10EFVTzBlefIxNkBXZ3ienq6MUnVQBOIY7sKQxXs739FQ7qq3m4K 6j0uAyoScxFBbsl08yLYURD+504GeVHyz4IqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TZ+zQHQtomutecvSXiIR5gZUXsETJIxNNq6vH2BZ3dl3WfcZxoqn7w2nn2+4QwEm0O +JIlmtIISgJPhkq28Wks7yRCm+GfKPOuAMbpXUhtKB1fKuiHnRW4cegZ1PazQDP2D2f1 Vk+FGnXlqPHeB1+zfFarN/O/SDD8ArN7TDYck= MIME-Version: 1.0 Received: by 10.204.6.75 with SMTP id 11mr5699222bky.95.1280162291569; Mon, 26 Jul 2010 09:38:11 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Mon, 26 Jul 2010 09:38:11 -0700 (PDT) Date: Mon, 26 Jul 2010 18:38:11 +0200 Message-ID: From: Alexandru Petrescu To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Side note: looking for reviewers of draft-petrescu-autoconf-ra-based-routing-00.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: , X-List-Received-Date: Mon, 26 Jul 2010 16:42:25 -0000 Hello RoLLers, Within RoLL WG discussion some times people mentioned the use of RPL in vehicular environments - this draft too. I am looking for reviewers of draft-petrescu-autoconf-ra-based-routing-00.txt. http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 "Router Advertisements for Routing between Moving Networks" This draft is mainly intended as INFORMATIONAL or EXPERIMENTAL. It describes the use of extended Routing Advertisements to exchange Mobile Network Prefixes between Mobile Routers, on their egress interfaces, for vehicular settings. It sets paths between LFNs accordingly. The draft was discussed shortly in MEXT WG (it's about NEMO moving networks) but also a little bit in AUTOCONF. Interested to reviez? I listen (privately or on the list). Thanks, Alex From culler@cs.berkeley.edu Mon Jul 26 09:49:33 2010 Return-Path: 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 17FF53A68A0 for ; Mon, 26 Jul 2010 09:49:33 -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 LDHajTrdYVhe for ; Mon, 26 Jul 2010 09:49:32 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 50CA23A6816 for ; Mon, 26 Jul 2010 09:49:32 -0700 (PDT) Received: from dhcp-45-99.eecs.berkeley.edu (dhcp-45-99.EECS.Berkeley.EDU [128.32.45.99]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QGnqt8020870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Jul 2010 09:49:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: David Culler In-Reply-To: Date: Mon, 26 Jul 2010 09:49:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ROLL WG X-Mailer: Apple Mail (2.1081) Subject: Re: [Roll] LC RPL-10 : Completed 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: , X-List-Received-Date: Mon, 26 Jul 2010 16:49:33 -0000 The WG last call on draft-ietf-roll-rpl-10.txt is now closed. RPL = authors, please prepare a rpl-11 draft that addresses the issues, = comments, and suggestions raised during the WG Last Call.=20 WG, thank you all for your diligent work to identify issues and weak = points in the draft. A number of relatively minor issues were = identified and addressed, and a number of useful observations and = comments and suggestions were provided. The authors have been tracking = those closely with the ticket mechanism and developing the resolution, = so I think we will be able to move very quickly to a resolution draft. = The one issue that may take a little time to completely resolve is the = specific signature algorithm (or algorithms) specified in Section 6.1. = We prefer to have an signature scheme that is unencumbered and yet = compact. This is an important work item, but it's resolution will have = a very localized effect on the draft. On Jul 6, 2010, at 9:41 AM, David Culler wrote: > This email starts a WG Last Call on RPL-10 that will end on July 27 at = noon ET. Please send your comments to the authors and copy the chairs = and the mailing list. Thanks all. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mjohn.info@googlemail.com Mon Jul 26 12:25:32 2010 Return-Path: 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 E2EE43A68CF for ; Mon, 26 Jul 2010 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.299, 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 wnDeJEG6dyxT for ; Mon, 26 Jul 2010 12:25:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 896473A689D for ; Mon, 26 Jul 2010 12:25:31 -0700 (PDT) Received: by wyb40 with SMTP id 40so2604093wyb.31 for ; Mon, 26 Jul 2010 12:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=17FgX+tiB6TtXscNcE9DQePRpSYWGyq0hoi6hUECtTM=; b=qf15iLlPvNopUa+9gsxsOmAVR5lnJF4F8jIvPWcnu8v6CtbFYSZAQS2G1r73g+3/3x nF24Ivz4xgwcSEEzBrkaUZaIj02zxcWUq/EVnDtMzZaQ27KnvP9dx8wko782iPL6J5LG zpQQPT29i90Vqjz71tFXlqAdoLzdHnssTQWX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pDDi1ifuKyvg2DRnqn/3XM9NlwQtdWY4YcOojVNstnbwJ36GxM9qYjRGvF77Rv9ISh dh/qkxxYnxWGAHVgMf3YEQREKTKSlFOJhsacJQQ6rzoBqMvSd0CQWIX4pPKw6oONf09l UrznyrrXIZjVjwR/ggCtfSCOaFuk3S+2ThzOo= MIME-Version: 1.0 Received: by 10.227.20.85 with SMTP id e21mr7702248wbb.175.1280172351838; Mon, 26 Jul 2010 12:25:51 -0700 (PDT) Received: by 10.216.188.69 with HTTP; Mon, 26 Jul 2010 12:25:51 -0700 (PDT) In-Reply-To: <6876.1280140580@marajade.sandelman.ca> References: <6876.1280140580@marajade.sandelman.ca> Date: Mon, 26 Jul 2010 21:25:51 +0200 Message-ID: From: Michael John To: Michael Richardson Content-Type: multipart/alternative; boundary=002215976372485bc0048c4f5a54 Cc: roll WG Subject: Re: [Roll] RPL over "secured" lower-layers 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: , X-List-Received-Date: Mon, 26 Jul 2010 19:25:33 -0000 --002215976372485bc0048c4f5a54 Content-Type: text/plain; charset=ISO-8859-1 Michael I'd just like to know how does one use and implement these multiple keys > when running on top of a "secure" link-layer? I would expect the pre-installed keys to be provisioned out of band or to be factory installed. A in-band provisioning seems feasible for the secured lower layer case. In this scenario an Application Layer protocol could to be used to provision the keys. > Is there an implicit requirement for the secure radio layer to indicate > to upper layers which key is being used? Do all radios support use of > multiple simultaneous keys, and permit the upper layers to specify which > key to use to send a particular message? > I do not see the requirement for the keying material used by the lower layer to be shared with the rpl instance (not sure if I got your question right). I would expect rpl security modes to operate independently from lower layer security. > Seems like there is a series of drafts (RPL-over-FOO) missing here. > I agree that a general guideline how to operate rpl would be useful. For example, to provide use case for each security mode. In certain scenarios with a fully secured lower layer "insecure" operation mode of rpl might be sufficient. Cheers, Michael --002215976372485bc0048c4f5a54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michael

I'd just like to know how does one use and implement these multiple key= s
when running on top of a "secure" link-layer?=A0

I would expect the pre-installed keys to be provisioned out of band or= to be factory installed. A in-band provisioning seems feasible for the sec= ured lower layer case. In this scenario an Application Layer protocol could= to be used to provision the keys.=A0
=A0
Is there an implicit requirement for the secure radio layer to indicate
to upper layers which key is being used? =A0 Do all radios support use of multiple simultaneous keys, and permit the upper layers to specify which key to use to send a particular message?

I do not = see the requirement for the keying material used by the lower layer to be s= hared with the rpl instance (not sure if I got your question right). I woul= d expect rpl security modes to operate independently from lower layer secur= ity.
=A0
Seems like there is a series of drafts (RPL-over-FOO) missing here.

I agree that a general guideline how to operate rpl would be u= seful. For example, to provide use case for each security mode. In certain = scenarios with a fully secured lower layer "insecure" operation m= ode of rpl might be sufficient.


Cheers,
Michael

--002215976372485bc0048c4f5a54-- From trac@tools.ietf.org Mon Jul 26 13:18:06 2010 Return-Path: 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 6CF193A6991 for ; Mon, 26 Jul 2010 13:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 px+yDbgJNBin for ; Mon, 26 Jul 2010 13:18:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 90AFE3A6937 for ; Mon, 26 Jul 2010 13:18:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdU7x-0001vd-Nq; Mon, 26 Jul 2010 13:18:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 26 Jul 2010 20:18:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/75 Message-ID: <055.5ecdc999e878316f774932679577d0fb@tools.ietf.org> X-Trac-Ticket-ID: 75 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #75: Option Len Field mismatch in metric doc. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 20:18:06 -0000 #75: Option Len Field mismatch in metric doc. --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: dominique.barthel@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Hi Ajay, On Jul 26, 2010, at 4:18 PM, Ajay Kumar (ajakuma2) wrote: Hi WG, I see following text in roll-metric draft. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Type=2 | Option Len | Routing Metric/Constraint objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 1: DAG Metric Container format This is from core RPL spec. The Routing Metric/Contraints objects have a common format consisting of one or more 8-bit words with a common header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing-MC-Type|Res|R|G| A |O|C| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (object body) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ How can the Length field in Metric Container Format accommodate Length specified in Common header that follows? I believe the value in second field cannot be greater than 253 leaving out (Routin-MC-Type & Flags). Please ignore of it has already been pointed out. JP> Good catch, thanks. The change in the RPL ID has not been reflected in the metric-ID. We changed it in the RPL spec (this is why we can have more than one container) but not yet in the metric-ID. It will be fixed in metric-ID version 9. Thanks for the comments. Regards, Ajay -- Ticket URL: roll From trac@tools.ietf.org Mon Jul 26 13:21:30 2010 Return-Path: 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 575C83A697F for ; Mon, 26 Jul 2010 13:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 r28HwjizY4Br for ; Mon, 26 Jul 2010 13:21:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A88FE3A696E for ; Mon, 26 Jul 2010 13:21:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdUBE-00065D-J8; Mon, 26 Jul 2010 13:21:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com X-Trac-Project: roll Date: Mon, 26 Jul 2010 20:21:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/75#comment:1 Message-ID: <064.f69c6b98b0373f6027899fa007b2499e@tools.ietf.org> References: <055.5ecdc999e878316f774932679577d0fb@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <055.5ecdc999e878316f774932679577d0fb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dominique.barthel@orange-ftgroup.com, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #75: Option Len Field mismatch in metric doc. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 20:21:30 -0000 #75: Option Len Field mismatch in metric doc. --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: dominique.barthel@… Type: defect | Status: new Priority: major | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * component: rpl => routing-metrics -- Ticket URL: roll From trac@tools.ietf.org Mon Jul 26 13:27:54 2010 Return-Path: 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 3FB9D3A697F for ; Mon, 26 Jul 2010 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 O1b7Z2AWEezL for ; Mon, 26 Jul 2010 13:27:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D63E43A684D for ; Mon, 26 Jul 2010 13:27:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OdUHU-0003rC-CB; Mon, 26 Jul 2010 13:28:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Mon, 26 Jul 2010 20:28:12 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/roll/trac/ticket/74#comment:2 Message-ID: <064.9548fde03ef1c55da386e74d01e316ae@tools.ietf.org> References: <055.074d18fbfa50419d38970c4b532eaf39@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <055.074d18fbfa50419d38970c4b532eaf39@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #74: Edits on Option Length on Figures X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 20:27:54 -0000 #74: Edits on Option Length on Figures -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: closed Priority: trivial | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Old description: > From: JP Vasseur > Date: July 26, 2010 10:37:54 AM CEDT > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] small comment on DIS format > > Hi Yoav, > > On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: > > Hi, > > I found a small editorial fix in the description of “Option Length†field > in the SIO description. > > Right now the description says Option Length 19 bytes, which I think > little misleading. If I understand correctly, it should be saying that > the length of the field is 1 byte and its value shall be set to 19, > right? > > Well, in Section 5.7.1, this is actually clarified: > > 5.7.1. RPL Control Message Option Generic Format > > RPL Control Message Options all follow this format: > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > | Option Type | Option Length | Option Data > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - > > Figure 14: RPL Option Generic Format > > Option Type: 8-bit identifier of the type of option. The Option > Type values are to be confirmed by the IANA Section 18.4. > > Option Length: 8-bit unsigned integer, representing the length in > octets of the option, not including the Option Type and Length > fields. > > Option Data: A variable length field that contains data specific to > the option. > > But I see your point, what we should be doing is to put the number 19 in > the figure. > > In other words, for each figure: > Option Lenght (1 byte): 19 > + > shows the number (when we have a fixed number) on the figure. > > Would that clarify ? > > Thanks. > > JP. > > Regards, > Yoav > > 5.7.9. Solicited Information > > ... > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + DODAGID + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+ > > Figure 22: Format of the Solicited Information Option > ... > > Option Length: 19 bytes > > _______________________________________________ > 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 New description: From: JP Vasseur Date: July 26, 2010 10:37:54 AM CEDT To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] small comment on DIS format Hi Yoav, On Jul 26, 2010, at 10:19 AM, Yoav Ben-Yehezkel wrote: Hi, I found a small editorial fix in the description of “Option Length†field in the SIO description. Right now the description says Option Length 19 bytes, which I think little misleading. If I understand correctly, it should be saying that the length of the field is 1 byte and its value shall be set to 19, right? Well, in Section 5.7.1, this is actually clarified: 5.7.1. RPL Control Message Option Generic Format RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 14: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by the IANA Section 18.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option. But I see your point, what we should be doing is to put the number 19 in the figure. In other words, for each figure: Option Lenght (1 byte): 19 + shows the number (when we have a fixed number) on the figure. Would that clarify ? Thanks. JP. Regards, Yoav 5.7.9. Solicited Information ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Option Length | RPLInstanceID |V|I|D| Rsvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+ Figure 22: Format of the Solicited Information Option ... Option Length: 19 bytes _______________________________________________ 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 -- Comment: Resolution to appear in revision -11: " RPL Control Message Options all follow this format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 19: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are to be confirmed by IANA Section 19.4. Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. " So we should not repeat that. OTOH, the way the length was expressed was not consistent. So the proposal is for all options that have a constant value, to use a same form. We could use something like: " Option Type: 0x04 (to be confirmed by IANA) Option Length: 14 -- Ticket URL: roll From gnawali@cs.stanford.edu Mon Jul 26 13:32:32 2010 Return-Path: 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 854453A6979 for ; Mon, 26 Jul 2010 13:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aGzTx0eYHH1G for ; Mon, 26 Jul 2010 13:32:30 -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 7D2AA3A6901 for ; Mon, 26 Jul 2010 13:32:30 -0700 (PDT) Received: from mail-gy0-f174.google.com ([209.85.160.174]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OdULy-0004rJ-VF for roll@ietf.org; Mon, 26 Jul 2010 13:32:52 -0700 Received: by gyg10 with SMTP id 10so989150gyg.19 for ; Mon, 26 Jul 2010 13:32:50 -0700 (PDT) Received: by 10.150.7.13 with SMTP id 13mr4407956ybg.411.1280176369658; Mon, 26 Jul 2010 13:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.144.199 with HTTP; Mon, 26 Jul 2010 13:32:29 -0700 (PDT) In-Reply-To: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> From: Omprakash Gnawali Date: Mon, 26 Jul 2010 13:32:29 -0700 Message-ID: To: Yoav Ben-Yehezkel Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Mon, 26 Jul 2010 20:32:32 -0000 On Sun, Jul 25, 2010 at 1:37 PM, Yoav Ben-Yehezkel wrote: > Hi, > > > > I would like to probe the WG=92s opinion on the issue of transmission at > different transmission gains to obtain more reliability on the link quali= ty. > > > > For example, somehow indicating the transmission power level on DIS/DIO/D= AO > (maybe by percent of or db less than maximum transmission level) to make > sure that metrics are calculated/parents are selected, etc. only based on > transmissions received with low transmission gains. > > > > We=92ve used this to make our topologies more stable in proprietary solut= ions. > The motivation is to have sufficient level of margin for noise before > messages at high gain will not be received properly (i.e. if messages are > received at 6dB less than the maximum transmission gain, there=92s room f= or at > least 6 dB more noise before the messages will not be received =96 6 dB i= s a > lot of margin, so topologies remain very stable with this kind of margin)= . How low a gain would you consider for topology discovery if you were to use this approach and the chip allows you to go to extremely low values? How does this work on networks with different density? - om_p From mcr@sandelman.ca Mon Jul 26 14:17:44 2010 Return-Path: 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 108073A69DD for ; Mon, 26 Jul 2010 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 Pf+yyL0VqmXL for ; Mon, 26 Jul 2010 14:17:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C94373A69D5 for ; Mon, 26 Jul 2010 14:17:42 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id ECA8434487; Mon, 26 Jul 2010 17:18:03 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6E57098A08; Mon, 26 Jul 2010 17:15:41 -0400 (EDT) From: Michael Richardson To: Michael John In-Reply-To: References: <6876.1280140580@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 26 Jul 2010 17:15:41 -0400 Message-ID: <21353.1280178941@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] RPL over "secured" lower-layers 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: , X-List-Received-Date: Mon, 26 Jul 2010 21:17:44 -0000 >>>>> "Michael" == Michael John writes: mcr> I'd just like to know how does one use and implement these mcr> multiple keys when running on top of a "secure" link-layer? Michael> I would expect the pre-installed keys to be provisioned out Michael> of band or to be factory installed. A in-band provisioning Michael> seems feasible for the secured lower layer case. In this Michael> scenario an Application Layer protocol could to be Michael> used to provision the keys. I don't think you understood the question. I didn't ask how the keys were provisioned --- that's the question you answered. I asked, once they are provisioned, how does the layer-3 RPL layer tell what key was used to secure a packet? This matters. In RPL, we have three levels of security. In level 0, there is no security. In level one, a node can join as a leaf. In level two, a node cna join as a router. If the security is provide by a secure link-layer (i.e. buried in an attached secure radio chip), how can one tell if a node is a level 1 or level 2 node? Do those devices even tell you? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From culler@cs.berkeley.edu Mon Jul 26 15:30:44 2010 Return-Path: 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 496603A6A99 for ; Mon, 26 Jul 2010 15:30:44 -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 bZeoYzeVRQg1 for ; Mon, 26 Jul 2010 15:30:40 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id DC42D3A6A64 for ; Mon, 26 Jul 2010 15:30:38 -0700 (PDT) Received: from dhcp-45-99.eecs.berkeley.edu (dhcp-45-99.EECS.Berkeley.EDU [128.32.45.99]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6QMUxMF001625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Jul 2010 15:31:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Mon, 26 Jul 2010 15:30:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2B103395-EA6F-4C12-8D5D-A745213800FC@cs.berkeley.edu> References: To: David Culler X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] LC RPL-10 : Completed - Correction 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: , X-List-Received-Date: Mon, 26 Jul 2010 22:30:44 -0000 Please forgive me, last call remains open until TOMORROW, July 27. I = don't expect anything sufficiently major to arise that would forestall = closure, but we should stick with the original duration. Please direct = any additional issues, concerns or suggestions to the list. On Jul 26, 2010, at 9:49 AM, David Culler wrote: > The WG last call on draft-ietf-roll-rpl-10.txt is now closed. RPL = authors, please prepare a rpl-11 draft that addresses the issues, = comments, and suggestions raised during the WG Last Call.=20 >=20 > WG, thank you all for your diligent work to identify issues and weak = points in the draft. A number of relatively minor issues were = identified and addressed, and a number of useful observations and = comments and suggestions were provided. The authors have been tracking = those closely with the ticket mechanism and developing the resolution, = so I think we will be able to move very quickly to a resolution draft. = The one issue that may take a little time to completely resolve is the = specific signature algorithm (or algorithms) specified in Section 6.1. = We prefer to have an signature scheme that is unencumbered and yet = compact. This is an important work item, but it's resolution will have = a very localized effect on the draft. >=20 >=20 > On Jul 6, 2010, at 9:41 AM, David Culler wrote: >=20 >> This email starts a WG Last Call on RPL-10 that will end on July 27 = at noon ET. Please send your comments to the authors and copy the = chairs and the mailing list. Thanks all. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Mon Jul 26 21:17:05 2010 Return-Path: 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 6AC4F3A6845 for ; Mon, 26 Jul 2010 21:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HjoPBhFuH0Dl for ; Mon, 26 Jul 2010 21:17:04 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 4FF213A6964 for ; Mon, 26 Jul 2010 21:17:03 -0700 (PDT) Received: from source ([209.85.216.174]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTE5d1Cu2sZ2SY2xll5w8ZGz0VV/FoYYw@postini.com; Mon, 26 Jul 2010 21:17:26 PDT Received: by mail-qy0-f174.google.com with SMTP id 7so3153862qyk.12 for ; Mon, 26 Jul 2010 21:17:24 -0700 (PDT) Received: by 10.224.73.73 with SMTP id p9mr7044877qaj.320.1280204244586; Mon, 26 Jul 2010 21:17:24 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcstAbtAI7Juv46pTP+BU3yBVc/pYQAP1iVQ Date: Tue, 27 Jul 2010 07:17:19 +0300 Message-ID: To: Omprakash Gnawali Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Tue, 27 Jul 2010 04:17:05 -0000 It is up to the application which gains to use and how to use it with DIS messages. We've used it in PLC networks in topologies with up to a few thousands of nodes, where each node on average has direct connectivity with about 200 nodes when using maximum gain and about 80% of the nodes using lower transmission gain. Our technology allows for 8 levels of gain, other technologies allows for some other values, Jennic's 802.15.4 modules allow for 4 levels of gain for example. This is completely application dependant. Does this make sense? Thanks, Yoav -----Original Message----- From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] Sent: Monday, July 26, 2010 11:32 PM To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] question on gain control On Sun, Jul 25, 2010 at 1:37 PM, Yoav Ben-Yehezkel wrote: > Hi, > > > > I would like to probe the WG's opinion on the issue of transmission at > different transmission gains to obtain more reliability on the link quality. > > > > For example, somehow indicating the transmission power level on DIS/DIO/DAO > (maybe by percent of or db less than maximum transmission level) to make > sure that metrics are calculated/parents are selected, etc. only based on > transmissions received with low transmission gains. > > > > We've used this to make our topologies more stable in proprietary solutions. > The motivation is to have sufficient level of margin for noise before > messages at high gain will not be received properly (i.e. if messages are > received at 6dB less than the maximum transmission gain, there's room for at > least 6 dB more noise before the messages will not be received - 6 dB is a > lot of margin, so topologies remain very stable with this kind of margin). How low a gain would you consider for topology discovery if you were to use this approach and the chip allows you to go to extremely low values? How does this work on networks with different density? - om_p From alexandru.petrescu@gmail.com Tue Jul 27 06:11:01 2010 Return-Path: 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 592923A69E8 for ; Tue, 27 Jul 2010 06:11:01 -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 Q-J2S3zR5kS2 for ; Tue, 27 Jul 2010 06:10:57 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 46C753A6802 for ; Tue, 27 Jul 2010 06:10:56 -0700 (PDT) Received: by bwz7 with SMTP id 7so3932339bwz.31 for ; Tue, 27 Jul 2010 06:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=QEWiWjBzwSH/7lSSHzuk8kWv0SWZeeVQzZ/HfqAkXcs=; b=aeJhTxgPrJAfUmHpdAnYLwQou6mj8IVjzIkj6PIvcE4wcXh/xbCUpghSMB6t6ECQPG pu2HHUy4vptRy0N/OeWNVrDru56UNNoNUMawl5RyATUtG8oJP2Wxb+mas1Dje8lZiVCZ 925/DDXJGHxK9xW4hyZflMzO29Q1OoeSvz+b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=uy9/vSrxOVxYnjb+OD1AJmDgJFjyDtCTJ4HDC1779NwPVSeJ/gziUx9VX8PRxLuAI/ vX6suDItTmFaxCHF4SLkqUMtBbpimSpCvJ3UV5UlCH1piFbQgyqHxQTVbbJ2nMp9zG9R CJHpdmiiwUCw79JWViVXKa/GKT+dgd8Zvmfwc= MIME-Version: 1.0 Received: by 10.204.1.139 with SMTP id 11mr6521918bkf.174.1280236275692; Tue, 27 Jul 2010 06:11:15 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Tue, 27 Jul 2010 06:11:15 -0700 (PDT) Date: Tue, 27 Jul 2010 15:11:15 +0200 Message-ID: From: Alexandru Petrescu To: pal@cs.stanford.edu, roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] unsigned integer MUST be at least 6 octets long? 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: , X-List-Received-Date: Tue, 27 Jul 2010 13:11:01 -0000 [posting from gmail gui, no Message-ID, unformatted] A quick note on this non blocking aspect. Le 25/07/2010 21:37, Philip Levis a =E9crit : > > On Jul 24, 2010, at 2:32 AM, Alexandru Petrescu wrote: > >> Has this nit been solved somehow? Are there any opinions or >> reasons to ignore this nit? >> >> The nit is the draft to wrongly consider an unsigned integer at >> least 6 octet long, because this makes impossible to use unsigned >> integers 4 octet longs (which are a default on many platforms). >> > > The assumption is that you use an unsigned long long (uint64_t). As stack implementer I rarely work with uint64_t as they are hardly portable across plaforms. > If for very tight RAM reasons you don't want to allocate 8 bytes, 6 > is sufficient. Hmmm... > I would assume that most simple implementations just use ULL. Probably(?) > Making protocol decisions for "int" seems like a poor idea, given its > non-portable nature. Hmmm... in my experience int could be widely assumed as 4byte - not everywhere, but mostly. On another hand I think there exists no C 6byte int structure (I think). > It's worthwhile noting that many LLN platforms (e.g., > microcontrollers) have 2 octet, not 4 octet, "int" values. A common > mistake novice programmers make in this domain. :) I agree, I find this to be a good note. A wise specifier would help a novice implementer by setting most if not all RPL message formats as 2byte or 1byte fields. > Using 4 bytes is not technically feasible due to the timescales > required. A 32-bit counter with millsecond granularity wraps around > after approximately 50 days. We would like networks to last longer > than 50 days and be protected from replay as well as delay attacks. > Again, I feel that your concerns are ignoring the actual technical > problem which the protocol is trying to solve. Sorry, not ignoring. I agree with the timescale required 50days. There may be however a way to specify it easier to read by implementer. E.g: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ |C|T| Rsrvd |Sec|KIM|Rsrvd| LVL | 1st2CounterBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2nd2CounterBytes | 3rd2CounterBytes | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Counter value is a timestamp at least 6bytes long. When the timestamp is 6bytes long, implementation should concatenate the fields 1st2CounterBytes, 2nd2CounterBytes and 3rd2CounterBytes into a single 6-byte value. Each CounterBytes field is in network byte order. The concatenation should be in host byte order. Symbolic example code for concatenation is the following: [...] (also one considers that hton functions don't exist for 6byte integers, making it hard to display and understand a 6byte value) Alex > Phil > From culler@cs.berkeley.edu Tue Jul 27 08:13:39 2010 Return-Path: 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 9DB9E3A68DD for ; Tue, 27 Jul 2010 08:13:39 -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=[AWL=0.000, 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 Ds6CGa0T1oUk for ; Tue, 27 Jul 2010 08:13:38 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 4A4843A687C for ; Tue, 27 Jul 2010 08:13:38 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6RFDM5m008770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Jul 2010 08:13:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <2B103395-EA6F-4C12-8D5D-A745213800FC@cs.berkeley.edu> Date: Tue, 27 Jul 2010 08:13:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92107C8B-C683-41BD-9290-3D298A370DE2@cs.berkeley.edu> References: <2B103395-EA6F-4C12-8D5D-A745213800FC@cs.berkeley.edu> To: David Culler X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] LC RPL-10 : Completed Noon ET July 27 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: , X-List-Received-Date: Tue, 27 Jul 2010 15:13:39 -0000 >> The WG last call on draft-ietf-roll-rpl-10.txt is closed effective = noon ET July 27. RPL authors, please prepare a rpl-11 draft that = addresses the issues, comments, and suggestions raised during the WG = Last Call.=20 >>=20 >> WG, thank you all for your diligent work to identify issues and weak = points in the draft. A number of relatively minor issues were = identified and addressed, and a number of useful observations and = comments and suggestions were provided. The authors have been tracking = those closely with the ticket mechanism and developing the resolution, = so I think we will be able to move very quickly to a resolution draft. = The one issue that may take a little time to completely resolve is the = specific signature algorithm (or algorithms) specified in Section 6.1. = We prefer to have an signature scheme that is unencumbered and yet = compact. This is an important work item, but it's resolution will have = a very localized effect on the draft. From jpv@cisco.com Tue Jul 27 09:21:36 2010 Return-Path: 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 9B28B28B797 for ; Tue, 27 Jul 2010 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3hTe5GWGwosf for ; Tue, 27 Jul 2010 09:21:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E3BA53A6A40 for ; Tue, 27 Jul 2010 09:21:35 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEukTkxAaMHG/2dsb2JhbACfY3GmaptGhTYEiGqCOg X-IronPort-AV: E=Sophos;i="4.55,269,1278288000"; d="scan'208";a="346867175" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2010 16:21:57 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6RGLPkV008721 for ; Tue, 27 Jul 2010 16:21:56 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 18:21:53 +0200 Received: from dhcp-706b.meeting.ietf.org ([10.61.88.96]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 18:21:53 +0200 Message-Id: <6F4C5CF8-D525-43A3-81FF-5FE794029670@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 18:21:53 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Jul 2010 16:21:53.0420 (UTC) FILETIME=[D312BCC0:01CB2DA7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17534.000 X-TM-AS-Result: No--3.678900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] ROLL Meeting Slides 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: , X-List-Received-Date: Tue, 27 Jul 2010 16:21:36 -0000 Dear all, If you have a (conditional) presentation slot and haven't done so yet, please send your slides so that we can upload them before the meeting. Thanks. JP. From gnawali@cs.stanford.edu Tue Jul 27 14:25:47 2010 Return-Path: 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 1BE393A68BF for ; Tue, 27 Jul 2010 14:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ja7Iw6A69226 for ; Tue, 27 Jul 2010 14:25:45 -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 AF9A83A67C3 for ; Tue, 27 Jul 2010 14:25:45 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1Odrf4-0004ha-2Z for roll@ietf.org; Tue, 27 Jul 2010 14:26:08 -0700 Received: by iwn7 with SMTP id 7so4040790iwn.19 for ; Tue, 27 Jul 2010 14:26:05 -0700 (PDT) Received: by 10.231.30.131 with SMTP id u3mr3398445ibc.189.1280265965334; Tue, 27 Jul 2010 14:26:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.144.199 with HTTP; Tue, 27 Jul 2010 14:25:45 -0700 (PDT) In-Reply-To: References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> From: Omprakash Gnawali Date: Tue, 27 Jul 2010 14:25:45 -0700 Message-ID: To: Yoav Ben-Yehezkel Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Tue, 27 Jul 2010 21:25:47 -0000 On Mon, Jul 26, 2010 at 9:17 PM, Yoav Ben-Yehezkel wrote: > It is up to the application which gains to use and how to use it with DIS > messages. > > We've used it in PLC networks in topologies with up to a few thousands of > nodes, where each node on average has direct connectivity with about 200 > nodes when using maximum gain and about 80% of the nodes using lower > transmission gain. > > Our technology allows for 8 levels of gain, other technologies allows for > some other values, Jennic's 802.15.4 modules allow for 4 levels of gain > for example. This is completely application dependant. > > Does this make sense? Yes, it does. Two more questions: - How does this mechanism work in a network that has different density at different places? - How does this mechanism work when new nodes are introduced to the network? Thanks. - om_p From yoav@yitran.com Tue Jul 27 15:34:24 2010 Return-Path: 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 6BAF028C0F3 for ; Tue, 27 Jul 2010 15:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 l0RDJ1KbmhnI for ; Tue, 27 Jul 2010 15:34:10 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id 3B6C43A6979 for ; Tue, 27 Jul 2010 15:34:08 -0700 (PDT) Received: from source ([74.125.82.46]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTE9e9pxOdbCic2ran9ot4fx9mfwgQzB2@postini.com; Tue, 27 Jul 2010 15:34:32 PDT Received: by mail-ww0-f46.google.com with SMTP id 39so305495wwb.27 for ; Tue, 27 Jul 2010 15:34:30 -0700 (PDT) Received: by 10.227.156.66 with SMTP id v2mr9545381wbw.136.1280270070505; Tue, 27 Jul 2010 15:34:30 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acst0lTXoJ7EzNXxTbCAuasFZqEoHAABeDiw Date: Wed, 28 Jul 2010 01:34:25 +0300 Message-ID: <16c63dda00d17f15296da3c8bc6ac128@mail.gmail.com> To: Omprakash Gnawali Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Tue, 27 Jul 2010 22:34:24 -0000 Hi, An example for an implementation utilizing this mechanism by new nodes or by disconnected nodes that are looking for reliable parents is as follows: 1. the node sends out a DIS (at low transmission gain, and with low rank filter for parents). The idea is that it is better to connect to the lowest possible parent (DODAG root for example), with sufficient margin. 2. if DODAG roots hear the DIS, only they respond with DIO. If one wants to maintain a bi-directional link with the margin, then the DIO response to the DIS should also be using low power (if the gain is indicated on the DIS). 3. If no response arrives after sending the DIS, the node can slightly increase the filter on the rank, and/or increase the transmission gain and/or both and resend the DIS. 4. This time, all nodes that satisfy the rank filter (can be nodes that are not DODAG roots) can respond, again with the capability to do so using low power. 5. repeat steps 3 and 4, until DIO response to DIS is received from a parent node (the last attempt can be without any rank filter and at highest transmission gain). The above method serves a few purposes: It allows the incoming responses to be using lower transmission power, hence, most likely after this connection is established, DIO/DAO reception will remain stable (since there was still margin for noise when the connection was established). Side effects: 1. Filter out DIO responses to DIS at the potential parent to avoid congestion. 2. Note that nodes attempting to connect can wait very little time after each DIS for responses before retrying to connect by sending out another DIS (because of 1.) 3. Agnostic to density. The above example is just one heuristic method that can be used to quickly obtain a highly reliable link with low congestion using gain control. The above doesn't preclude additional ways that can be thought of to use the info on transmission gain. My point was having the option of using the transmission gain as a metric/constraint. The idea probably needs to be better formulated to fit into RPL metrics/constraints spec. I'd appreciate the WG/editors'/chairs' assistance with that you find this method relevant/useful. Best regards, Yoav -----Original Message----- From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] Sent: Wednesday, July 28, 2010 12:26 AM To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] question on gain control On Mon, Jul 26, 2010 at 9:17 PM, Yoav Ben-Yehezkel wrote: > It is up to the application which gains to use and how to use it with DIS > messages. > > We've used it in PLC networks in topologies with up to a few thousands of > nodes, where each node on average has direct connectivity with about 200 > nodes when using maximum gain and about 80% of the nodes using lower > transmission gain. > > Our technology allows for 8 levels of gain, other technologies allows for > some other values, Jennic's 802.15.4 modules allow for 4 levels of gain > for example. This is completely application dependant. > > Does this make sense? Yes, it does. Two more questions: - How does this mechanism work in a network that has different density at different places? - How does this mechanism work when new nodes are introduced to the network? Thanks. - om_p From pal@cs.stanford.edu Tue Jul 27 15:47:30 2010 Return-Path: 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 8B9263A68B3 for ; Tue, 27 Jul 2010 15:47:30 -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 N8CWcVlvFcgH for ; Tue, 27 Jul 2010 15:47:29 -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 B797F3A6803 for ; Tue, 27 Jul 2010 15:47:29 -0700 (PDT) Received: from [87.213.214.66] (helo=[192.168.1.77]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OdswB-0008So-Li; Tue, 27 Jul 2010 15:47:52 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> Date: Wed, 28 Jul 2010 00:47:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Tue, 27 Jul 2010 22:47:30 -0000 On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel wrote: > Hi, > =20 > I would like to probe the WG=92s opinion on the issue of transmission = at different transmission gains to obtain more reliability on the link = quality. > =20 > For example, somehow indicating the transmission power level on = DIS/DIO/DAO (maybe by percent of or db less than maximum transmission = level) to make sure that metrics are calculated/parents are selected, = etc. only based on transmissions received with low transmission gains. > =20 > We=92ve used this to make o cur topologies more stable in proprietary = solutions. The motivation is to have sufficient level of margin for = noise before messages at high gain will not be received properly (i.e. = if messages are received at 6dB less than the maximum transmission gain, = there=92s room for at least 6 dB more noise before the messages will not = be received =96 6 dB is a lot of margin, so topologies remain very = stable with this kind of margin). > =20 > I believe that such an option used by the RPL would bring benefit, and = maybe belong to one of the RPL drafts (i.e. metric, OF, other?). > =20 > Would this something the RPL WG would consider to add? > =20 > Your inputs would be greatly appreciated. Why not just use a good link estimator? Any reasonable implementation = isn't going to assume receiving a DIS or DIO implies good connectivity. = Another mechanism would simply be to only consider nodes whose DIOs have = had an SNR above X to be candidate neighbors. Actually using variable = transmission power to infer link quality and stability is problematic: = it can be a link has high SNR but low PRR (e.g., due to external = interference). Phil From dat@exegin.com Tue Jul 27 17:05:48 2010 Return-Path: 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 B5BD23A63C9 for ; Tue, 27 Jul 2010 17:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.823, 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 R+i23-smt9TL for ; Tue, 27 Jul 2010 17:05:47 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B8F9028C0E0 for ; Tue, 27 Jul 2010 17:05:46 -0700 (PDT) Received: by vws10 with SMTP id 10so4179121vws.31 for ; Tue, 27 Jul 2010 17:06:08 -0700 (PDT) Received: by 10.220.61.6 with SMTP id r6mr5675868vch.6.1280275568233; Tue, 27 Jul 2010 17:06:08 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id y25sm3417371vbw.16.2010.07.27.17.06.06 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 17:06:07 -0700 (PDT) Message-ID: <4C4F7466.80905@exegin.com> Date: Tue, 27 Jul 2010 17:05:58 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: roll@ietf.org References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> In-Reply-To: <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 00:05:48 -0000 If the flow label is used by a source to identify a RPL Instance how would the same source use the flow label for other flows not related to RPL. Put another way, if an application (or a transport like TCP) wanted to identify a new data flow, how would the ingress router know that the label was identifying the new flow and not the RPL Instance. Reading RFC 3697, it would appear that the flow label is used in identifying the end-to-end flow, not for identify a route. From Section 2 in RFC 3697: The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes. Router performance SHOULD NOT be dependent on the distribution of the Flow Label values. Regards Dario roll issue tracker wrote: > #64: RPL Instance ID in flow label or RPL option > -----------------------------+---------------------------------------------- > Reporter: jpv@… | Owner: pthubert@… > Type: enhancement | Status: closed > Priority: major | Milestone: > Component: rpl | Version: > Severity: In WG Last Call | Resolution: fixed > Keywords: | > -----------------------------+---------------------------------------------- > Changes (by jpv@…): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Email from JP July 24 Following an email from Pascal. > > Great text, which I think address the ticket - minor comments below. > > On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote: > > Dear WG: > > Long discussions lead to specify only the location of the RPLinstanceID > inside the RPL network, leaving it to policies the way the ingress router > figures it out. The RPLinstanceID will be placed in the RPL option which > is probably the cleanest and most generic thing we can do. Other drafts > are allowed to come later and provide alternate forwarding rules > eventually placing the content of the RPL option validation somewhere > else, for instance in order to avoid IPinIP. A forwarding mode will > probably indicate what the network does. > > Proposed changes: > > RPL uses a hop-by-hop IPv6 header to detect possible loops within a > DODAG. > -> > RPL carries routing information in a RPL Option contained in > an IPv6 > Hop-by-Hop Option as specified in [I-D.hui-6man-rpl- > option]. Such > routing information are used for example for loop > detection within a > DODAG as discussed in Section 11.2 and may be extended in > future > documents for additional features. > > > For data packets, the RPLInstanceID may be indicated in the flow > label by the source of the packet. If it is not, then it is inferred > and added by the RPL network ingress router in the RPL Hop-by-hop > option ([I-D.hui-6man-rpl-option]) as further described in > Section 10.2 > > è > > Data packet that flow within the RP network expose the > RPLInstanceID > in the RPL option that is specified in [I-D.hui-6man-rpl- > option], and > further described in Section 11.2. For data packets coming > from > outside the RPL network, the RPLInstanceID is determined > by the RPL > network ingress router and placed in the RPL option that > is added to > the packet. > > > RPL loop detection uses information that is placed into the packet. > A future version of this specification will detail how this > information is carried with the packet (e.g. a hop-by-hop option > ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow > label). For the purpose of RPL operations, the information carried > with a packet is constructed follows: > > è > RPL loop detection uses information that contained within the > data > packet using the RPL Option [I-D.hui-6man-rpl-option]) in an > IPv6 > Hop-by-Hop Option header. The RPL Option is a generic > container for > a list of TLVs. This specification defines a new RPL > Option type, > called the RPL Loop Detection. The RPL Loop Detection TLV > is placed > in the RPL Option with Option Type = 1 (to be confirmed by > IANA), > Option Data Length = 4 octets, and the Value has the > following > format: > > > > The RPLInstanceID is associated by the source with the packet. This > RPLInstanceID MUST match the RPL Instance onto which the packet is > placed by any node, be it a host or router. For traffic originating > outside of the RPL domain there may be a mapping occurring at the > gateway into the RPL domain, possibly based on an encoding within the > flow label. This aspect of RPL operation is to be clarified in a > future version of this specification. > > The source of the packet might be aware of the RPL network, of the > constraints imposed on OFs, and of associated Instance IDs. In that > case, the source of the packet MAY tag the flow label with the > RPLInstanceID, in which case it is used in that form within the RPL > network. > > A router that injects a data packet into the RPL network MUST tag the > packet by inserting a RPL Hop-by-hop option as specified in > [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in > flow label of the data packet, the ingress router that injects the > packet into the RPL network MUST add a RPLInstanceID field to the RPL > Hop-by-hop option. > > è > The RPLInstanceID is associated by the source with the > packet. This > RPLInstanceID MUST match the RPL Instance onto which the > packet is > placed by any node, be it a host or router. > > For a packet that is originated from outside the RPL > network, the > source of the packet might be aware of the RPL network, of > the > constraints imposed on OFs, and of associated > RPLInstanceIDs. In > that case, the source of the packet MAY tag the flow label > with the > RPLInstanceID. > > A RPL router that forwards a packet in the RPL network > MUST check if > the packet includes the RPL Loop Detection TLV in a RPL > Option within > the IPv6 Hop-by-Hop Option header. If one does not exist, > the RPL > router MUST insert a RPL Loop Detection type as specified > in > > > [I-D.hui-6man-rpl-option]. If the router is an ingress > router that > injects the packet into the RPL network, the router MUST > set the > RPLInstanceID field in the RPL Loop Detection TLV. > > > > JP> + add: > > A router that forwards a packet to outside the RPL domain MUST > remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. > > As usual, please speak up if there’s an issue with the proposed > resolution! > > Pascal > > From mcr@sandelman.ca Tue Jul 27 17:33:57 2010 Return-Path: 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 87C1C3A6781 for ; Tue, 27 Jul 2010 17:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 4VLma+Jd0cgC for ; Tue, 27 Jul 2010 17:33:56 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4EE153A65A6 for ; Tue, 27 Jul 2010 17:33:56 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 77F4334521; Tue, 27 Jul 2010 20:34:17 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E0C2398A0E; Tue, 27 Jul 2010 20:31:52 -0400 (EDT) From: Michael Richardson To: Dario Tedeschi In-Reply-To: <4C4F7466.80905@exegin.com> References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> <4C4F7466.80905@exegin.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 27 Jul 2010 20:31:52 -0400 Message-ID: <7964.1280277112@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 00:33:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Dario" == Dario Tedeschi writes: Dario> If the flow label is used by a source to identify a RPL Dario> Instance how would the same source use the flow label for Dario> other flows not related to RPL. Put another way, if an Dario> application (or a transport like TCP) wanted to identify a Dario> new data flow, how would the ingress router know that the Dario> label was identifying the new flow and not the RPL Instance. Dario> Reading RFC 3697, it would appear that the flow label is used Dario> in identifying the end-to-end flow, not for identify a route. Because, in most cases, at least one end point of the flow, is a control or sensor in the LLN, and therefore it's got a right to participate in the end-to-end settings. If the collector machine is not a part of the LLN, then it is going to have be provisioned with the right flow labels. If the LLN is connected to the machines outside it's Autonomous System, then the gateway system at the end is going to have to validate flow labels anyway, and essentially either permit some through, or "reset" them all. Since the labels need to be delivered according to 3697, this may mean that a gateway machine will need to classify all untrusted flow labels into some kind of layer-2 tag which indicates "not-trusted" so that downstream routers will not act on the flow labels. What I write about may not be "stock" for IPv6, but few things are yet. It's really our job (in this WG) to establish a typical use for them. Nobody really knows what the flow labels will get used for, but many think they will get mapped to things like MPLS labels at border routers. Dario> From Section 2 in RFC 3697: Dario> The Flow Label value set by the source MUST be delivered Dario> unchanged to the destination node(s). IPv6 nodes MUST NOT Dario> assume any mathematical or other properties of the Flow Label Dario> values assigned by source nodes. Router performance SHOULD Dario> NOT be dependent on the distribution of the Flow Label Dario> values. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTE96d4CLcPvd0N1lAQIgZQf/TudbbIZ4sUUgOhEe5hKPxJuWpZEDuj3t jk8d2rM3HuYS1BBn284HP1giURPv5WrH5llfBT/laWWJq73ML22V4oF0+iSI/01d byeNvzZtkmiaVdFmWF/A3boNQjI2ggbqP/B6VEYgnnzN+t9y+4jRR+duKRsYN3np 6zwRzejPz+fsN6g6IJUy+JkIiIUeSogfjTZlrvIEzCTKqA/VSg718ehvEUl0XJnD yIKZCymEN43IhvkH1sP6mNAGQ2nLHHInnCeVv91LX2GaySboTn4Kiohl5Az4Ci2y 90wwITYok8BOeD6lvQYFancqZqPkj0qOCPNQMCB32fsO/PnEKePASg== =JqL8 -----END PGP SIGNATURE----- From yoav@yitran.com Tue Jul 27 22:27:22 2010 Return-Path: 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 8784A3A69B5 for ; Tue, 27 Jul 2010 22:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 j+hNFfJwMTF9 for ; Tue, 27 Jul 2010 22:27:21 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 49A9B3A6824 for ; Tue, 27 Jul 2010 22:27:19 -0700 (PDT) Received: from source ([74.125.82.182]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTE+/zGOkcButKdiMXowqavTk0UWLqHMa@postini.com; Tue, 27 Jul 2010 22:27:43 PDT Received: by mail-wy0-f182.google.com with SMTP id 26so4780181wyj.41 for ; Tue, 27 Jul 2010 22:27:40 -0700 (PDT) Received: by 10.227.153.3 with SMTP id i3mr9932370wbw.171.1280294860635; Tue, 27 Jul 2010 22:27:40 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acst3cBzE8GQQE0eSfqWlrlngOwJTwAN0dMw Date: Wed, 28 Jul 2010 08:27:35 +0300 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Wed, 28 Jul 2010 05:27:23 -0000 Indeed, in wireless networks SNR can be used as a good estimator. Unlike wireless networks, in low speed PLC technologies, because the operation is very close to the negative SNR bounds, there's only about 3dB difference between no reception and perfect reception. This is the main motivation for this method. 3dB is not a good enough margin. Thanks, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Wednesday, July 28, 2010 1:48 AM To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] question on gain control On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel wrote: > Hi, > > I would like to probe the WG's opinion on the issue of transmission at different transmission gains to obtain more reliability on the link quality. > > For example, somehow indicating the transmission power level on DIS/DIO/DAO (maybe by percent of or db less than maximum transmission level) to make sure that metrics are calculated/parents are selected, etc. only based on transmissions received with low transmission gains. > > We've used this to make o cur topologies more stable in proprietary solutions. The motivation is to have sufficient level of margin for noise before messages at high gain will not be received properly (i.e. if messages are received at 6dB less than the maximum transmission gain, there's room for at least 6 dB more noise before the messages will not be received - 6 dB is a lot of margin, so topologies remain very stable with this kind of margin). > > I believe that such an option used by the RPL would bring benefit, and maybe belong to one of the RPL drafts (i.e. metric, OF, other?). > > Would this something the RPL WG would consider to add? > > Your inputs would be greatly appreciated. Why not just use a good link estimator? Any reasonable implementation isn't going to assume receiving a DIS or DIO implies good connectivity. Another mechanism would simply be to only consider nodes whose DIOs have had an SNR above X to be candidate neighbors. Actually using variable transmission power to infer link quality and stability is problematic: it can be a link has high SNR but low PRR (e.g., due to external interference). Phil From jpv@cisco.com Wed Jul 28 00:40:51 2010 Return-Path: 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 063D73A68D7 for ; Wed, 28 Jul 2010 00:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TYu6K6RYkQgS for ; Wed, 28 Jul 2010 00:40:45 -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 2A8583A6986 for ; Wed, 28 Jul 2010 00:40:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACd8T0xAZnwM/2dsb2JhbACDFJxXcaRtiT2RUIEmgUiBVXMEiG6COg X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208";a="140146467" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2010 07:41:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6S7f51X013983; Wed, 28 Jul 2010 07:41:06 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 09:41:05 +0200 Received: from dhcp-60f4.meeting.ietf.org ([10.61.97.90]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 09:41:05 +0200 Message-Id: <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> From: JP Vasseur To: Dario Tedeschi In-Reply-To: <4C4F7466.80905@exegin.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Jul 2010 09:41:06 +0200 References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> <4C4F7466.80905@exegin.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Jul 2010 07:41:05.0602 (UTC) FILETIME=[3C55DA20:01CB2E28] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 07:40:51 -0000 Thanks for your email. As discussed, it will go in the RPL option. On Jul 28, 2010, at 2:05 AM, Dario Tedeschi wrote: > > If the flow label is used by a source to identify a RPL Instance how =20= > would the same source use the flow label for other flows not related =20= > to RPL. Put another way, if an application (or a transport like TCP) =20= > wanted to identify a new data flow, how would the ingress router =20 > know that the label was identifying the new flow and not the RPL =20 > Instance. > > Reading RFC 3697, it would appear that the flow label is used in =20 > identifying the end-to-end flow, not for identify a route. > > =46rom Section 2 in RFC 3697: > > The Flow Label value set by the source MUST be delivered unchanged to > the destination node(s). > IPv6 nodes MUST NOT assume any mathematical or other properties of > the Flow Label values assigned by source nodes. Router performance > SHOULD NOT be dependent on the distribution of the Flow Label values. > > > Regards > Dario > > roll issue tracker wrote: >> #64: RPL Instance ID in flow label or RPL option >> -----------------------------=20 >> +---------------------------------------------- >> Reporter: jpv@=E2=80=A6 | Owner: =20 >> pthubert@=E2=80=A6 Type: enhancement | = Status: =20 >> closed Priority: major | =20 >> Milestone: Component: rpl | =20 >> Version: Severity: In WG Last Call | =20 >> Resolution: fixed Keywords: | =20 >> -----------------------------=20 >> +---------------------------------------------- >> Changes (by jpv@=E2=80=A6): >> >> * status: new =3D> closed >> * resolution: =3D> fixed >> >> >> Comment: >> >> Email from JP July 24 Following an email from Pascal. >> >> Great text, which I think address the ticket - minor comments below. >> >> On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote: >> >> Dear WG: >> >> Long discussions lead to specify only the location of the =20 >> RPLinstanceID >> inside the RPL network, leaving it to policies the way the ingress =20= >> router >> figures it out. The RPLinstanceID will be placed in the RPL option =20= >> which >> is probably the cleanest and most generic thing we can do. Other =20 >> drafts >> are allowed to come later and provide alternate forwarding rules >> eventually placing the content of the RPL option validation somewhere >> else, for instance in order to avoid IPinIP. A forwarding mode will >> probably indicate what the network does. >> >> Proposed changes: >> >> RPL uses a hop-by-hop IPv6 header to detect possible loops within a >> DODAG. >> -> >> RPL carries routing information in a RPL Option =20 >> contained in >> an IPv6 >> Hop-by-Hop Option as specified in [I-D.hui-6man-rpl- >> option]. Such >> routing information are used for example for loop >> detection within a >> DODAG as discussed in Section 11.2 and may be =20 >> extended in >> future >> documents for additional features. >> >> >> For data packets, the RPLInstanceID may be indicated in the flow >> label by the source of the packet. If it is not, then it is inferred >> and added by the RPL network ingress router in the RPL Hop-by-hop >> option ([I-D.hui-6man-rpl-option]) as further described in >> Section 10.2 >> >> =C3=A8 >> >> Data packet that flow within the RP network expose the >> RPLInstanceID >> in the RPL option that is specified in [I-=20 >> D.hui-6man-rpl- >> option], and >> further described in Section 11.2. For data packets =20= >> coming >> from >> outside the RPL network, the RPLInstanceID is =20 >> determined >> by the RPL >> network ingress router and placed in the RPL option =20= >> that >> is added to >> the packet. >> >> >> RPL loop detection uses information that is placed into the packet. >> A future version of this specification will detail how this >> information is carried with the packet (e.g. a hop-by-hop option >> ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow >> label). For the purpose of RPL operations, the information carried >> with a packet is constructed follows: >> >> =C3=A8 >> RPL loop detection uses information that contained =20 >> within the >> data >> packet using the RPL Option [I-D.hui-6man-rpl-option]) =20= >> in an >> IPv6 >> Hop-by-Hop Option header. The RPL Option is a generic >> container for >> a list of TLVs. This specification defines a new RPL >> Option type, >> called the RPL Loop Detection. The RPL Loop =20 >> Detection TLV >> is placed >> in the RPL Option with Option Type =3D 1 (to be =20 >> confirmed by >> IANA), >> Option Data Length =3D 4 octets, and the Value has = the >> following >> format: >> >> >> >> The RPLInstanceID is associated by the source with the packet. This >> RPLInstanceID MUST match the RPL Instance onto which the packet is >> placed by any node, be it a host or router. For traffic originating >> outside of the RPL domain there may be a mapping occurring at the >> gateway into the RPL domain, possibly based on an encoding within the >> flow label. This aspect of RPL operation is to be clarified in a >> future version of this specification. >> >> The source of the packet might be aware of the RPL network, of the >> constraints imposed on OFs, and of associated Instance IDs. In that >> case, the source of the packet MAY tag the flow label with the >> RPLInstanceID, in which case it is used in that form within the RPL >> network. >> >> A router that injects a data packet into the RPL network MUST tag the >> packet by inserting a RPL Hop-by-hop option as specified in >> [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in >> flow label of the data packet, the ingress router that injects the >> packet into the RPL network MUST add a RPLInstanceID field to the RPL >> Hop-by-hop option. >> >> =C3=A8 >> The RPLInstanceID is associated by the source with the >> packet. This >> RPLInstanceID MUST match the RPL Instance onto =20 >> which the >> packet is >> placed by any node, be it a host or router. >> >> For a packet that is originated from outside the RPL >> network, the >> source of the packet might be aware of the RPL =20 >> network, of >> the >> constraints imposed on OFs, and of associated >> RPLInstanceIDs. In >> that case, the source of the packet MAY tag the =20 >> flow label >> with the >> RPLInstanceID. >> >> A RPL router that forwards a packet in the RPL =20 >> network >> MUST check if >> the packet includes the RPL Loop Detection TLV in a =20= >> RPL >> Option within >> the IPv6 Hop-by-Hop Option header. If one does not =20= >> exist, >> the RPL >> router MUST insert a RPL Loop Detection type as =20 >> specified >> in >> >> >> [I-D.hui-6man-rpl-option]. If the router is an =20 >> ingress >> router that >> injects the packet into the RPL network, the router =20= >> MUST >> set the >> RPLInstanceID field in the RPL Loop Detection TLV. >> >> >> >> JP> + add: >> >> A router that forwards a packet to outside the RPL domain MUST >> remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. >> >> As usual, please speak up if there=C2=92s an issue with the proposed >> resolution! >> >> Pascal >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed Jul 28 01:01:49 2010 Return-Path: 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 C7E8C28C12A for ; Wed, 28 Jul 2010 01:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RS6lpq38TQVs for ; Wed, 28 Jul 2010 01:01:48 -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 7EC3128C127 for ; Wed, 28 Jul 2010 01:01:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208";a="140107636" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2010 08:02:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6S8272j001352; Wed, 28 Jul 2010 08:02:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 10:02:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 28 Jul 2010 10:02:05 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D026ACE8B@XMB-AMS-107.cisco.com> In-Reply-To: <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option thread-index: AcsuKFNGC8NU9h6lR6W3Wsj8SPwErAAAP0vQ References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org><064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org><4C4F7466.80905@exegin.com> <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Dario Tedeschi" X-OriginalArrivalTime: 28 Jul 2010 08:02:08.0395 (UTC) FILETIME=[2D04C5B0:01CB2E2B] Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 08:01:49 -0000 RXhhY3RseS4NCg0KQXMgeW91IGtub3csIEkgZG8gc3VwcG9ydCB0aGUgaWRlYSBvZiB1c2luZyB0 aGUgZmxvdyBsYWJlbCBpbiBhIG51bWJlciBvZiBjaXJjdW1zdGFuY2VzLiBJJ20gaW4gZmFjdCB2 ZXJ5IG11Y2ggYWxvbmcgTWljaGFlbCdzIGxpbmVzLg0KDQpCdXQgcmVhbGx5LCB0aGlzIGhhcyBu b3RoaW5nIHRvIGRvIHdpdGggdGhlIG1haW4gc3BlYyB0aGF0IHdlIG5lZWQgdG8gZm9jdXMgb24g cmlnaHQgbm93LiBSUEwgaXMgY29tcGxldGVseSBhZ25vc3RpYyB0byB0aGUgd2F5IHRoZSBpbmdy ZXNzIHJvdXRlciAoIHRoZSBMMy01IGluZ3Jlc3MgR1cgaW4gZ2VuZXJhbCkgd2lsbCBmaWd1cmUg dGhlIFJQTEluc3RhbmNlSUQuIE9UT0gsIFJQTCBkZXNjcmliZXMgYW5kIG93bnMgdGhlIFJQTElu c3RhbmNlSUQgaXRzZWxmIGFuZCBwcm92aWRlcyBpbnN0cnVjdGlvbnMgb24gaG93IGl0IGlzIHVz ZWQgdG8gbGVhcm4vZGlzdHJpYnV0ZSByb3V0ZXMsIGFuZCBsb29rIHVwIHJvdXRlcyB3aGlsZSBm b3J3YXJkaW5nLg0KDQpXaGVyZSBleGFjdGx5IHRoZSBSUExJbnN0YW5jZUlEIGlzIHBsYWNlZCBJ IHRoZSBkYXRhIHBhY2tldCBtdXN0IGJlIGNvbnNpc3RlbnQgd2l0aGluIGEgbmV0d29yaywgYnV0 IG1pZ2h0IGRpZmZlciBmcm9tIGEgbmV0d29yayB0byBhbm90aGVyLiBXZSBoYWQgdG8gcHJvdmlk ZSBhdCBsZWFzdCBvbmUgcmVmZXJlbmNlIG9wZXJhdGlvbiBhcyBhIGNvbXBhbmlvbiBkcmFmdC4g VGhpcyB3YXMgZG9uZSBpcyBhIHNlcGFyYXRlIGRyYWZ0LCBhbmQgdGhlIGNvbnNlbnN1cyB3YXMg dG8gdXNlIGFuIG9wdGlvbiBpbiB0aGUgaG9wLWJ5LWhvcCBoZWFkZXIuDQoNCklmIHRoZXJlJ3Mg aW50ZXJlc3QsIGFuZCBJIGhvcGUgdGhlcmUgaXMsIHRoZW4gd2UgY2FuIHN0YXJ0IGEgZHJhZnQg b24gYSBmbG93LWxhYmVsLWJhc2VkIGFsdGVybmF0aXZlIGFuZCBoYXZlIFdHIGRpc2N1c3Npb25z IGFyb3VuZCBpdCBpbiBkdWUgdGltZS4gSSdsbCBiZSBnbGFkIHRvIHBhcnRpY2lwYXRlLiBJbiB0 aGUgaW50ZXJlc3Qgb2YgcHJvZ3Jlc3MgYW5kIHN0YWJpbGl0eSBvZiB0aGUgbWFpbiB3b3JrLCBs ZXQgdXMgdHJ1c3QgdGhlIGNoYWlycyB0byBndWlkZSB1cyBvbiB3aGVuIHRoaXMgYW5kIG90aGVy IGRpc2N1c3Npb25zIGNhbiBiZXN0IGhhcHBlbi4NCg0KUGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9s bC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSlANCj4gVmFzc2V1cg0KPiBTZW50OiBX ZWRuZXNkYXksIEp1bHkgMjgsIDIwMTAgOTo0MSBBTQ0KPiBUbzogRGFyaW8gVGVkZXNjaGkNCj4g Q2M6IHJvbGxAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtSb2xsXSBbcm9sbF0gIzY0OiBSUEwg SW5zdGFuY2UgSUQgaW4gZmxvdyBsYWJlbCBvciBSUEwgb3B0aW9uDQo+IA0KPiBUaGFua3MgZm9y IHlvdXIgZW1haWwuIEFzIGRpc2N1c3NlZCwgaXQgd2lsbCBnbyBpbiB0aGUgUlBMIG9wdGlvbi4N Cj4gDQo+IE9uIEp1bCAyOCwgMjAxMCwgYXQgMjowNSBBTSwgRGFyaW8gVGVkZXNjaGkgd3JvdGU6 DQo+IA0KPiA+DQo+ID4gSWYgdGhlIGZsb3cgbGFiZWwgaXMgdXNlZCBieSBhIHNvdXJjZSB0byBp ZGVudGlmeSBhIFJQTCBJbnN0YW5jZSBob3cNCj4gPiB3b3VsZCB0aGUgc2FtZSBzb3VyY2UgdXNl IHRoZSBmbG93IGxhYmVsIGZvciBvdGhlciBmbG93cyBub3QgcmVsYXRlZA0KPiA+IHRvIFJQTC4g UHV0IGFub3RoZXIgd2F5LCBpZiBhbiBhcHBsaWNhdGlvbiAob3IgYSB0cmFuc3BvcnQgbGlrZSBU Q1ApDQo+ID4gd2FudGVkIHRvIGlkZW50aWZ5IGEgbmV3IGRhdGEgZmxvdywgaG93IHdvdWxkIHRo ZSBpbmdyZXNzIHJvdXRlciBrbm93DQo+ID4gdGhhdCB0aGUgbGFiZWwgd2FzIGlkZW50aWZ5aW5n IHRoZSBuZXcgZmxvdyBhbmQgbm90IHRoZSBSUEwgSW5zdGFuY2UuDQo+ID4NCj4gPiBSZWFkaW5n IFJGQyAzNjk3LCBpdCB3b3VsZCBhcHBlYXIgdGhhdCB0aGUgZmxvdyBsYWJlbCBpcyB1c2VkIGlu DQo+ID4gaWRlbnRpZnlpbmcgdGhlIGVuZC10by1lbmQgZmxvdywgbm90IGZvciBpZGVudGlmeSBh IHJvdXRlLg0KPiA+DQo+ID4gRnJvbSBTZWN0aW9uIDIgaW4gUkZDIDM2OTc6DQo+ID4NCj4gPiAg VGhlIEZsb3cgTGFiZWwgdmFsdWUgc2V0IGJ5IHRoZSBzb3VyY2UgTVVTVCBiZSBkZWxpdmVyZWQg dW5jaGFuZ2VkIHRvDQo+ID4gdGhlIGRlc3RpbmF0aW9uIG5vZGUocykuDQo+ID4gICAgSVB2NiBu b2RlcyBNVVNUIE5PVCBhc3N1bWUgYW55IG1hdGhlbWF0aWNhbCBvciBvdGhlciBwcm9wZXJ0aWVz IG9mDQo+ID4gdGhlIEZsb3cgTGFiZWwgdmFsdWVzIGFzc2lnbmVkIGJ5IHNvdXJjZSBub2Rlcy4g IFJvdXRlciBwZXJmb3JtYW5jZQ0KPiA+IFNIT1VMRCBOT1QgYmUgZGVwZW5kZW50IG9uIHRoZSBk aXN0cmlidXRpb24gb2YgdGhlIEZsb3cgTGFiZWwgdmFsdWVzLg0KPiA+DQo+ID4NCj4gPiBSZWdh cmRzDQo+ID4gRGFyaW8NCj4gPg0KPiA+IHJvbGwgaXNzdWUgdHJhY2tlciB3cm90ZToNCj4gPj4g IzY0OiBSUEwgSW5zdGFuY2UgSUQgaW4gZmxvdyBsYWJlbCBvciBSUEwgb3B0aW9uDQo+ID4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IFJlcG9ydGVyOiAganB2QOKApiAgICAgICAg ICAgIHwgICAgICAgIE93bmVyOg0KPiA+PiBwdGh1YmVydEDigKYgICAgICAgICAgICAgVHlwZTog IGVuaGFuY2VtZW50ICAgICAgfCAgICAgICBTdGF0dXM6DQo+ID4+IGNsb3NlZCAgICAgICAgICAg ICBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgfA0KPiA+PiBNaWxlc3RvbmU6ICAgICAgICAg ICAgICAgICAgICBDb21wb25lbnQ6ICBycGwgICAgICAgICAgICAgIHwNCj4gPj4gVmVyc2lvbjog ICAgICAgICAgICAgICAgICAgICBTZXZlcml0eTogIEluIFdHIExhc3QgQ2FsbCAgfA0KPiA+PiBS ZXNvbHV0aW9uOiAgZml4ZWQgICAgICAgICAgICAgIEtleXdvcmRzOiAgICAgICAgICAgICAgICAg ICB8DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IENoYW5nZXMgKGJ5IGpw dkDigKYpOg0KPiA+Pg0KPiA+PiAgKiBzdGF0dXM6ICBuZXcgPT4gY2xvc2VkDQo+ID4+ICAqIHJl c29sdXRpb246ICA9PiBmaXhlZA0KPiA+Pg0KPiA+Pg0KPiA+PiBDb21tZW50Og0KPiA+Pg0KPiA+ PiBFbWFpbCBmcm9tIEpQIEp1bHkgMjQgRm9sbG93aW5nIGFuIGVtYWlsIGZyb20gUGFzY2FsLg0K PiA+Pg0KPiA+PiBHcmVhdCB0ZXh0LCB3aGljaCBJIHRoaW5rIGFkZHJlc3MgdGhlIHRpY2tldCAt IG1pbm9yIGNvbW1lbnRzIGJlbG93Lg0KPiA+Pg0KPiA+PiBPbiBKdWwgMjQsIDIwMTAsIGF0IDEw OjQ2IEFNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+Pg0KPiA+PiBEZWFy IFdHOg0KPiA+Pg0KPiA+PiBMb25nIGRpc2N1c3Npb25zIGxlYWQgdG8gc3BlY2lmeSBvbmx5IHRo ZSBsb2NhdGlvbiBvZiB0aGUNCj4gPj4gUlBMaW5zdGFuY2VJRCBpbnNpZGUgdGhlIFJQTCBuZXR3 b3JrLCBsZWF2aW5nIGl0IHRvIHBvbGljaWVzIHRoZSB3YXkNCj4gPj4gdGhlIGluZ3Jlc3Mgcm91 dGVyIGZpZ3VyZXMgaXQgb3V0LiBUaGUgUlBMaW5zdGFuY2VJRCB3aWxsIGJlIHBsYWNlZA0KPiA+ PiBpbiB0aGUgUlBMIG9wdGlvbiB3aGljaCBpcyBwcm9iYWJseSB0aGUgY2xlYW5lc3QgYW5kIG1v c3QgZ2VuZXJpYw0KPiA+PiB0aGluZyB3ZSBjYW4gZG8uIE90aGVyIGRyYWZ0cyBhcmUgYWxsb3dl ZCB0byBjb21lIGxhdGVyIGFuZCBwcm92aWRlDQo+ID4+IGFsdGVybmF0ZSBmb3J3YXJkaW5nIHJ1 bGVzIGV2ZW50dWFsbHkgcGxhY2luZyB0aGUgY29udGVudCBvZiB0aGUgUlBMDQo+ID4+IG9wdGlv biB2YWxpZGF0aW9uIHNvbWV3aGVyZSBlbHNlLCBmb3IgaW5zdGFuY2UgaW4gb3JkZXIgdG8gYXZv aWQNCj4gPj4gSVBpbklQLiBBIGZvcndhcmRpbmcgbW9kZSB3aWxsIHByb2JhYmx5IGluZGljYXRl IHdoYXQgdGhlIG5ldHdvcmsNCj4gPj4gZG9lcy4NCj4gPj4NCj4gPj4gUHJvcG9zZWQgY2hhbmdl czoNCj4gPj4NCj4gPj4gUlBMIHVzZXMgIGEgaG9wLWJ5LWhvcCBJUHY2IGhlYWRlciB0byBkZXRl Y3QgcG9zc2libGUgbG9vcHMgd2l0aGluIGENCj4gPj4gRE9EQUcuDQo+ID4+IC0+DQo+ID4+ICAg ICAgICAgICAgICBSUEwgY2FycmllcyByb3V0aW5nIGluZm9ybWF0aW9uIGluIGEgUlBMIE9wdGlv bg0KPiA+PiBjb250YWluZWQgaW4gYW4gIElQdjYNCj4gPj4gICAgICAgICAgICAgICAgIEhvcC1i eS1Ib3AgT3B0aW9uIGFzIHNwZWNpZmllZCBpbiBbSS1ELmh1aS02bWFuLXJwbC0NCj4gPj4gb3B0 aW9uXS4gU3VjaA0KPiA+PiAgICAgICAgICAgICAgICAgcm91dGluZyBpbmZvcm1hdGlvbiBhcmUg dXNlZCBmb3IgZXhhbXBsZSBmb3IgbG9vcA0KPiA+PiBkZXRlY3Rpb24gd2l0aGluIGENCj4gPj4g ICAgICAgICAgICAgICAgIERPREFHIGFzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDExLjIgYW5kIG1h eSBiZQ0KPiA+PiBleHRlbmRlZCBpbiBmdXR1cmUNCj4gPj4gICAgICAgICAgICAgICAgIGRvY3Vt ZW50cyBmb3IgYWRkaXRpb25hbCBmZWF0dXJlcy4NCj4gPj4NCj4gPj4NCj4gPj4gRm9yIGRhdGEg cGFja2V0cywgdGhlIFJQTEluc3RhbmNlSUQgbWF5IGJlIGluZGljYXRlZCBpbiB0aGUgZmxvdw0K PiA+PiBsYWJlbCBieSB0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQuIElmIGl0IGlzIG5vdCwgdGhl biBpdCBpcyBpbmZlcnJlZA0KPiA+PiBhbmQgYWRkZWQgYnkgdGhlIFJQTCBuZXR3b3JrIGluZ3Jl c3Mgcm91dGVyIGluIHRoZSBSUEwgSG9wLWJ5LWhvcA0KPiA+PiBvcHRpb24gKFtJLUQuaHVpLTZt YW4tcnBsLW9wdGlvbl0pIGFzIGZ1cnRoZXIgZGVzY3JpYmVkIGluIFNlY3Rpb24NCj4gPj4gMTAu Mg0KPiA+Pg0KPiA+PiDDqA0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgRGF0YSBwYWNrZXQgdGhh dCBmbG93IHdpdGhpbiB0aGUgUlAgbmV0d29yayBleHBvc2UgdGhlDQo+ID4+IFJQTEluc3RhbmNl SUQNCj4gPj4gICAgICAgICAgICAgICAgIGluIHRoZSBSUEwgb3B0aW9uIHRoYXQgaXMgc3BlY2lm aWVkIGluIFtJLQ0KPiA+PiBELmh1aS02bWFuLXJwbC0NCj4gPj4gb3B0aW9uXSwgYW5kDQo+ID4+ ICAgICAgICAgICAgICAgICBmdXJ0aGVyIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDExLjIuIEZvciBk YXRhIHBhY2tldHMNCj4gPj4gY29taW5nIGZyb20NCj4gPj4gICAgICAgICAgICAgICAgIG91dHNp ZGUgdGhlIFJQTCBuZXR3b3JrLCB0aGUgUlBMSW5zdGFuY2VJRCBpcw0KPiA+PiBkZXRlcm1pbmVk IGJ5IHRoZSBSUEwNCj4gPj4gICAgICAgICAgICAgICAgIG5ldHdvcmsgaW5ncmVzcyByb3V0ZXIg YW5kIHBsYWNlZCBpbiB0aGUgUlBMIG9wdGlvbg0KPiA+PiB0aGF0IGlzIGFkZGVkIHRvDQo+ID4+ ICAgICAgICAgICAgICAgICB0aGUgcGFja2V0Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBSUEwgbG9vcCBk ZXRlY3Rpb24gdXNlcyBpbmZvcm1hdGlvbiB0aGF0IGlzIHBsYWNlZCBpbnRvIHRoZSBwYWNrZXQu DQo+ID4+IEEgZnV0dXJlIHZlcnNpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHdpbGwgZGV0YWls IGhvdyB0aGlzDQo+ID4+IGluZm9ybWF0aW9uIGlzIGNhcnJpZWQgd2l0aCB0aGUgcGFja2V0IChl LmcuIGEgaG9wLWJ5LWhvcCBvcHRpb24NCj4gPj4gKFtJLUQuaHVpLTZtYW4tcnBsLW9wdGlvbl0p IG9yIHN1bW1hcml6ZWQgc29tZWhvdyBpbnRvIHRoZSBmbG93DQo+ID4+IGxhYmVsKS4gRm9yIHRo ZSBwdXJwb3NlIG9mIFJQTCBvcGVyYXRpb25zLCB0aGUgaW5mb3JtYXRpb24gY2FycmllZA0KPiA+ PiB3aXRoIGEgcGFja2V0IGlzIGNvbnN0cnVjdGVkIGZvbGxvd3M6DQo+ID4+DQo+ID4+IMOoDQo+ ID4+ICAgICAgICAgICAgIFJQTCBsb29wIGRldGVjdGlvbiB1c2VzIGluZm9ybWF0aW9uIHRoYXQg Y29udGFpbmVkIHdpdGhpbg0KPiA+PiB0aGUgZGF0YQ0KPiA+PiAgICAgICAgICAgICBwYWNrZXQg dXNpbmcgdGhlIFJQTCBPcHRpb24gW0ktRC5odWktNm1hbi1ycGwtb3B0aW9uXSkgaW4NCj4gPj4g YW4NCj4gPj4gSVB2Ng0KPiA+PiAgICAgICAgICAgICAgICAgSG9wLWJ5LUhvcCBPcHRpb24gaGVh ZGVyLiBUaGUgUlBMIE9wdGlvbiBpcyBhIGdlbmVyaWMNCj4gPj4gY29udGFpbmVyIGZvcg0KPiA+ PiAgICAgICAgICAgICAgICAgYSBsaXN0IG9mIFRMVnMuIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZp bmVzIGEgbmV3IFJQTA0KPiA+PiBPcHRpb24gdHlwZSwNCj4gPj4gICAgICAgICAgICAgICAgIGNh bGxlZCB0aGUgUlBMIExvb3AgRGV0ZWN0aW9uLiBUaGUgUlBMIExvb3AgRGV0ZWN0aW9uDQo+ID4+ IFRMViBpcyBwbGFjZWQNCj4gPj4gICAgICAgICAgICAgICAgIGluIHRoZSBSUEwgT3B0aW9uIHdp dGggT3B0aW9uIFR5cGUgPSAxICh0byBiZQ0KPiA+PiBjb25maXJtZWQgYnkgSUFOQSksDQo+ID4+ ICAgICAgICAgICAgICAgICBPcHRpb24gRGF0YSBMZW5ndGggPSA0IG9jdGV0cywgYW5kIHRoZSBW YWx1ZSBoYXMgdGhlDQo+ID4+IGZvbGxvd2luZw0KPiA+PiAgICAgICAgICAgICAgICAgZm9ybWF0 Og0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgUlBMSW5zdGFuY2VJRCBpcyBhc3NvY2lhdGVk IGJ5IHRoZSBzb3VyY2Ugd2l0aCB0aGUgcGFja2V0LiBUaGlzDQo+ID4+IFJQTEluc3RhbmNlSUQg TVVTVCBtYXRjaCB0aGUgUlBMIEluc3RhbmNlIG9udG8gd2hpY2ggdGhlIHBhY2tldCBpcw0KPiA+ PiBwbGFjZWQgYnkgYW55IG5vZGUsIGJlIGl0IGEgaG9zdCBvciByb3V0ZXIuIEZvciB0cmFmZmlj IG9yaWdpbmF0aW5nDQo+ID4+IG91dHNpZGUgb2YgdGhlIFJQTCBkb21haW4gdGhlcmUgbWF5IGJl IGEgbWFwcGluZyBvY2N1cnJpbmcgYXQgdGhlDQo+ID4+IGdhdGV3YXkgaW50byB0aGUgUlBMIGRv bWFpbiwgcG9zc2libHkgYmFzZWQgb24gYW4gZW5jb2Rpbmcgd2l0aGluIHRoZQ0KPiA+PiBmbG93 IGxhYmVsLiBUaGlzIGFzcGVjdCBvZiBSUEwgb3BlcmF0aW9uIGlzIHRvIGJlIGNsYXJpZmllZCBp biBhDQo+ID4+IGZ1dHVyZSB2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4gPj4NCj4g Pj4gVGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0IG1pZ2h0IGJlIGF3YXJlIG9mIHRoZSBSUEwgbmV0 d29yaywgb2YgdGhlDQo+ID4+IGNvbnN0cmFpbnRzIGltcG9zZWQgb24gT0ZzLCBhbmQgb2YgYXNz b2NpYXRlZCBJbnN0YW5jZSBJRHMuIEluIHRoYXQNCj4gPj4gY2FzZSwgdGhlIHNvdXJjZSBvZiB0 aGUgcGFja2V0IE1BWSB0YWcgdGhlIGZsb3cgbGFiZWwgd2l0aCB0aGUNCj4gPj4gUlBMSW5zdGFu Y2VJRCwgaW4gd2hpY2ggY2FzZSBpdCBpcyB1c2VkIGluIHRoYXQgZm9ybSB3aXRoaW4gdGhlIFJQ TA0KPiA+PiBuZXR3b3JrLg0KPiA+Pg0KPiA+PiBBIHJvdXRlciB0aGF0IGluamVjdHMgYSBkYXRh IHBhY2tldCBpbnRvIHRoZSBSUEwgbmV0d29yayBNVVNUIHRhZyB0aGUNCj4gPj4gcGFja2V0IGJ5 IGluc2VydGluZyBhIFJQTCBIb3AtYnktaG9wIG9wdGlvbiBhcyBzcGVjaWZpZWQgaW4NCj4gPj4g W0ktRC5odWktNm1hbi1ycGwtb3B0aW9uXS4gSWYgdGhlIFJQTEluc3RhbmNlSUQgaXMgbm90IHBy ZXNlbnQgaW4NCj4gPj4gZmxvdyBsYWJlbCBvZiB0aGUgZGF0YSBwYWNrZXQsIHRoZSBpbmdyZXNz IHJvdXRlciB0aGF0IGluamVjdHMgdGhlDQo+ID4+IHBhY2tldCBpbnRvIHRoZSBSUEwgbmV0d29y ayBNVVNUIGFkZCBhIFJQTEluc3RhbmNlSUQgZmllbGQgdG8gdGhlIFJQTA0KPiA+PiBIb3AtYnkt aG9wIG9wdGlvbi4NCj4gPj4NCj4gPj4gw6gNCj4gPj4gICAgICAgICAgICAgIFRoZSBSUExJbnN0 YW5jZUlEIGlzIGFzc29jaWF0ZWQgYnkgdGhlIHNvdXJjZSB3aXRoIHRoZQ0KPiA+PiBwYWNrZXQu IFRoaXMNCj4gPj4gICAgICAgICAgICAgICAgIFJQTEluc3RhbmNlSUQgTVVTVCBtYXRjaCB0aGUg UlBMIEluc3RhbmNlIG9udG8gd2hpY2gNCj4gPj4gdGhlIHBhY2tldCBpcw0KPiA+PiAgICAgICAg ICAgICAgICAgcGxhY2VkIGJ5IGFueSBub2RlLCBiZSBpdCBhIGhvc3Qgb3Igcm91dGVyLg0KPiA+ Pg0KPiA+PiAgICAgICAgICAgICAgICAgRm9yIGEgcGFja2V0IHRoYXQgaXMgb3JpZ2luYXRlZCBm cm9tIG91dHNpZGUgdGhlIFJQTA0KPiA+PiBuZXR3b3JrLCB0aGUNCj4gPj4gICAgICAgICAgICAg ICAgIHNvdXJjZSBvZiB0aGUgcGFja2V0IG1pZ2h0IGJlIGF3YXJlIG9mIHRoZSBSUEwNCj4gPj4g bmV0d29yaywgb2YgdGhlDQo+ID4+ICAgICAgICAgICAgICAgICBjb25zdHJhaW50cyBpbXBvc2Vk IG9uIE9GcywgYW5kIG9mIGFzc29jaWF0ZWQNCj4gPj4gUlBMSW5zdGFuY2VJRHMuIEluDQo+ID4+ ICAgICAgICAgICAgICAgICB0aGF0IGNhc2UsIHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCBNQVkg dGFnIHRoZSBmbG93DQo+ID4+IGxhYmVsIHdpdGggdGhlDQo+ID4+ICAgICAgICAgICAgICAgICBS UExJbnN0YW5jZUlELg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgQSBSUEwgcm91dGVyIHRo YXQgZm9yd2FyZHMgYSBwYWNrZXQgaW4gdGhlIFJQTA0KPiA+PiBuZXR3b3JrIE1VU1QgY2hlY2sg aWYNCj4gPj4gICAgICAgICAgICAgICAgIHRoZSBwYWNrZXQgaW5jbHVkZXMgdGhlIFJQTCBMb29w IERldGVjdGlvbiBUTFYgaW4gYQ0KPiA+PiBSUEwgT3B0aW9uIHdpdGhpbg0KPiA+PiAgICAgICAg ICAgICAgICAgdGhlIElQdjYgSG9wLWJ5LUhvcCBPcHRpb24gaGVhZGVyLiBJZiBvbmUgZG9lcyBu b3QNCj4gPj4gZXhpc3QsIHRoZSBSUEwNCj4gPj4gICAgICAgICAgICAgICAgIHJvdXRlciBNVVNU IGluc2VydCBhIFJQTCBMb29wIERldGVjdGlvbiB0eXBlIGFzDQo+ID4+IHNwZWNpZmllZCBpbg0K PiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgW0ktRC5odWktNm1hbi1ycGwtb3B0aW9u XS4gSWYgdGhlIHJvdXRlciBpcyBhbg0KPiA+PiBpbmdyZXNzIHJvdXRlciB0aGF0DQo+ID4+ICAg ICAgICAgICAgICAgICBpbmplY3RzIHRoZSBwYWNrZXQgaW50byB0aGUgUlBMIG5ldHdvcmssIHRo ZSByb3V0ZXINCj4gPj4gTVVTVCBzZXQgdGhlDQo+ID4+ICAgICAgICAgICAgICAgICBSUExJbnN0 YW5jZUlEIGZpZWxkIGluIHRoZSBSUEwgTG9vcCBEZXRlY3Rpb24gVExWLg0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiBKUD4gKyBhZGQ6DQo+ID4+DQo+ID4+IEEgcm91dGVyIHRoYXQgZm9yd2FyZHMg YSBwYWNrZXQgdG8gb3V0c2lkZSB0aGUgUlBMIGRvbWFpbiBNVVNUDQo+ID4+IHJlbW92ZSB0aGUg UlBMIE9wdGlvbiBhcyBzcGVjaWZpZWQgaW4gW0ktRC5pZXRmLTZtYW4tcnBsLW9wdGlvbl0uDQo+ ID4+DQo+ID4+IEFzIHVzdWFsLCBwbGVhc2Ugc3BlYWsgdXAgaWYgdGhlcmXCknMgYW4gaXNzdWUg d2l0aCB0aGUgcHJvcG9zZWQNCj4gPj4gcmVzb2x1dGlvbiENCj4gPj4NCj4gPj4gUGFzY2FsDQo+ ID4+DQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4gUm9sbEBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5n IGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== From jpv@cisco.com Wed Jul 28 01:05:22 2010 Return-Path: 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 A02DA28C106 for ; Wed, 28 Jul 2010 01:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 ibfticVXOz2H for ; Wed, 28 Jul 2010 01:05: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 1D5FD28C105 for ; Wed, 28 Jul 2010 01:05:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFiBT0xAZnwN/2dsb2JhbACfa3GkY5sPhTYEiG6COg X-IronPort-AV: E=Sophos;i="4.55,272,1278288000"; d="scan'208,217";a="140108588" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2010 08:05:43 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6S85gE3003725 for ; Wed, 28 Jul 2010 08:05:43 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 10:05:42 +0200 Received: from dhcp-60f4.meeting.ietf.org ([10.61.97.90]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 10:05:42 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-35--798052357 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Jul 2010 10:05:41 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Jul 2010 08:05:42.0142 (UTC) FILETIME=[AC6BF9E0:01CB2E2B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17534.005 X-TM-AS-Result: No--5.800000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Wed, 28 Jul 2010 08:05:22 -0000 --Apple-Mail-35--798052357 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear WG, draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. This starts a 2-week Working Group last call ending on August 11 at 9:00am ET. Please send your comments to the authors and the list. Thanks. JP. --Apple-Mail-35--798052357 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear WG,

draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call.

This starts a 2-week Working Group last call ending on August 11 at 9:00am ET.

Please send your comments to the authors and the list.

Thanks.

JP.
--Apple-Mail-35--798052357-- From mcr@sandelman.ca Wed Jul 28 03:07:43 2010 Return-Path: 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 AA06C3A6A56 for ; Wed, 28 Jul 2010 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 GZMELlZhGTUO for ; Wed, 28 Jul 2010 03:07:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 5EDEA3A69FB for ; Wed, 28 Jul 2010 03:07:40 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 45124346B2; Wed, 28 Jul 2010 06:08:02 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4F5EE98A31; Wed, 28 Jul 2010 06:08:01 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D026ACE8B@XMB-AMS-107.cisco.com> References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org><064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org><4C4F7466.80905@exegin.com> <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D026ACE8B@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 28 Jul 2010 06:08:01 -0400 Message-ID: <24552.1280311681@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 10:07:43 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> As you know, I do support the idea of using the flow label Pascal> in a number of circumstances. I'm in fact very much along Pascal> Michael's lines. Good. Pascal> But really, this has nothing to do with the main spec that Pascal> we need to focus on right now. RPL is completely agnostic to I agree, mostly: it goes in another specification, but our document may well block at rfc-editor step waiting for at least one such specification! It's about RPL-over-FOO, and it certainly affects some very low level structures in nodes that are expected to be routes. Pascal> If there's interest, and I hope there is, then we can start Pascal> a draft on a flow-label-based alternative and have WG Pascal> discussions around it in due time. I'll be glad to Pascal> participate. In the interest of progress and stability of Pascal> the main work, let us trust the chairs to guide us on when Pascal> this and other discussions can best happen. I think that it's somewhat more urgent. If there are layer-2 places where the RPLinstanceID/flow-label can be *copied*, then great. I'm not aware of any other than 801q or MPLS, and I think given that most of the stacks are custom, either involves adding equivalent amounts of code as just leaving it in L3 flow label. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From c.chauvenet@watteco.com Wed Jul 28 05:48:14 2010 Return-Path: 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 835C73A6840 for ; Wed, 28 Jul 2010 05:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 nt280vadxpCE for ; Wed, 28 Jul 2010 05:48:13 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 3BAFA3A67B2 for ; Wed, 28 Jul 2010 05:48:12 -0700 (PDT) Received: from [10.0.0.58] ([83.161.201.77]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id KTY56332; Wed, 28 Jul 2010 14:48:32 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Chauvenet_C=E9dric?= In-Reply-To: Date: Wed, 28 Jul 2010 14:47:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BF99FBE-5DA9-4631-8E94-F1EBD497D39F@watteco.com> References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Wed, 28 Jul 2010 12:48:14 -0000 Hi Yoav,=20 Thank you for your scenario. Furthermore, it is relevant to say that power consumption is also a key = point in PLC. Your solution seems to be tight to link quality in the network. As PLC behavior is very moving, it could happen that an event in the = network (Plug/Unplug an electrical device, appliances start-up etc...) = may change most of the link quality in the network. As a result, the gain control computed during association may become = irrelevant to the actual link quality. How would your scenario adapt to these changes ? Thanks, C=E9dric Le 28 juil. 2010 =E0 07:27, Yoav Ben-Yehezkel a =E9crit : > Indeed, in wireless networks SNR can be used as a good estimator. > Unlike wireless networks, in low speed PLC technologies, because the > operation is very close to the negative SNR bounds, there's only about = 3dB > difference between no reception and perfect reception. > This is the main motivation for this method. 3dB is not a good enough > margin. >=20 > Thanks, > Yoav >=20 >=20 > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Wednesday, July 28, 2010 1:48 AM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] question on gain control >=20 >=20 > On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel wrote: >=20 >> Hi, >>=20 >> I would like to probe the WG's opinion on the issue of transmission = at > different transmission gains to obtain more reliability on the link > quality. >>=20 >> For example, somehow indicating the transmission power level on > DIS/DIO/DAO (maybe by percent of or db less than maximum transmission > level) to make sure that metrics are calculated/parents are selected, = etc. > only based on transmissions received with low transmission gains. >>=20 >> We've used this to make o cur topologies more stable in proprietary > solutions. The motivation is to have sufficient level of margin for = noise > before messages at high gain will not be received properly (i.e. if > messages are received at 6dB less than the maximum transmission gain, > there's room for at least 6 dB more noise before the messages will not = be > received - 6 dB is a lot of margin, so topologies remain very stable = with > this kind of margin). >>=20 >> I believe that such an option used by the RPL would bring benefit, = and > maybe belong to one of the RPL drafts (i.e. metric, OF, other?). >>=20 >> Would this something the RPL WG would consider to add? >>=20 >> Your inputs would be greatly appreciated. >=20 > Why not just use a good link estimator? Any reasonable implementation > isn't going to assume receiving a DIS or DIO implies good = connectivity. > Another mechanism would simply be to only consider nodes whose DIOs = have > had an SNR above X to be candidate neighbors. Actually using variable > transmission power to infer link quality and stability is problematic: = it > can be a link has high SNR but low PRR (e.g., due to external > interference). >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Wed Jul 28 06:42:11 2010 Return-Path: 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 A43F53A68F6 for ; Wed, 28 Jul 2010 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 O1oTT94n9Vdd for ; Wed, 28 Jul 2010 06:42:10 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id F06FC3A697A for ; Wed, 28 Jul 2010 06:42:09 -0700 (PDT) Received: from source ([74.125.82.44]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTFAzxyt7pBoXpg8G+QqfIzA3b7BRKWUP@postini.com; Wed, 28 Jul 2010 06:42:33 PDT Received: by mail-ww0-f44.google.com with SMTP id 40so1953317wwj.13 for ; Wed, 28 Jul 2010 06:42:31 -0700 (PDT) Received: by 10.227.157.70 with SMTP id a6mr10631858wbx.163.1280324549509; Wed, 28 Jul 2010 06:42:29 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> <8BF99FBE-5DA9-4631-8E94-F1EBD497D39F@watteco.com> In-Reply-To: <8BF99FBE-5DA9-4631-8E94-F1EBD497D39F@watteco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuUzLSnMy+MnyYQ2S2kdh19uZPDQABW6HA Date: Wed, 28 Jul 2010 16:42:22 +0300 Message-ID: <4dee171432563db46dea686648b9be06@mail.gmail.com> To: =?ISO-8859-1?Q?Chauvenet_C=E9dric?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Wed, 28 Jul 2010 13:42:11 -0000 Hi Cedric, Thanks for the feedback. I completely agree that power consumption in PLC is also of great importance. As you've said, changes in the grid can cause the noise to be big enough to cause disconnections. My proposal was to add an option when trying to (re)connect to get more reliability on the link state when connecting, and after that use higher gain if necessary. The difference between the gain used to connect and the gain used later is the amount of margin a node has on the reliability of the link with its parent, to accommodate for the grid changes you mentioned. This is more adaptive than not using any margin on gain between connection and normal operation. Hope this shed some light on this issue. Thanks, Yoav -----Original Message----- From: Chauvenet C=E9dric [mailto:c.chauvenet@watteco.com] Sent: Wednesday, July 28, 2010 3:48 PM To: Yoav Ben-Yehezkel Cc: Philip Levis; roll@ietf.org Subject: Re: [Roll] question on gain control Hi Yoav, Thank you for your scenario. Furthermore, it is relevant to say that power consumption is also a key point in PLC. Your solution seems to be tight to link quality in the network. As PLC behavior is very moving, it could happen that an event in the network (Plug/Unplug an electrical device, appliances start-up etc...) may change most of the link quality in the network. As a result, the gain control computed during association may become irrelevant to the actual link quality. How would your scenario adapt to these changes ? Thanks, C=E9dric Le 28 juil. 2010 =E0 07:27, Yoav Ben-Yehezkel a =E9crit : > Indeed, in wireless networks SNR can be used as a good estimator. > Unlike wireless networks, in low speed PLC technologies, because the > operation is very close to the negative SNR bounds, there's only about 3dB > difference between no reception and perfect reception. > This is the main motivation for this method. 3dB is not a good enough > margin. > > Thanks, > Yoav > > > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Wednesday, July 28, 2010 1:48 AM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] question on gain control > > > On Jul 25, 2010, at 10:37 PM, Yoav Ben-Yehezkel wrote: > >> Hi, >> >> I would like to probe the WG's opinion on the issue of transmission at > different transmission gains to obtain more reliability on the link > quality. >> >> For example, somehow indicating the transmission power level on > DIS/DIO/DAO (maybe by percent of or db less than maximum transmission > level) to make sure that metrics are calculated/parents are selected, etc. > only based on transmissions received with low transmission gains. >> >> We've used this to make o cur topologies more stable in proprietary > solutions. The motivation is to have sufficient level of margin for noise > before messages at high gain will not be received properly (i.e. if > messages are received at 6dB less than the maximum transmission gain, > there's room for at least 6 dB more noise before the messages will not be > received - 6 dB is a lot of margin, so topologies remain very stable with > this kind of margin). >> >> I believe that such an option used by the RPL would bring benefit, and > maybe belong to one of the RPL drafts (i.e. metric, OF, other?). >> >> Would this something the RPL WG would consider to add? >> >> Your inputs would be greatly appreciated. > > Why not just use a good link estimator? Any reasonable implementation > isn't going to assume receiving a DIS or DIO implies good connectivity. > Another mechanism would simply be to only consider nodes whose DIOs have > had an SNR above X to be candidate neighbors. Actually using variable > transmission power to infer link quality and stability is problematic: it > can be a link has high SNR but low PRR (e.g., due to external > interference). > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Emmanuel.Monnerie@landisgyr.com Wed Jul 28 06:54:54 2010 Return-Path: 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 E44D33A6829 for ; Wed, 28 Jul 2010 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6] 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 vU-uGJwc+sBs for ; Wed, 28 Jul 2010 06:54:53 -0700 (PDT) Received: from mta1.cellnet.com (mta1.cellnet.com [66.173.18.47]) by core3.amsl.com (Postfix) with ESMTP id A7B183A6895 for ; Wed, 28 Jul 2010 06:54:53 -0700 (PDT) X-ASG-Debug-ID: 1280325315-521e00730000-BCmCR7 X-Barracuda-URL: http://10.3.2.11:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta1.cellnet.com (Spam Firewall) with ESMTP id 13B5DD5F87 for ; Wed, 28 Jul 2010 08:55:15 -0500 (CDT) Received: from livemail.cellnethunt.com (usatlsv15.am.bm.net [10.1.130.15]) by mta1.cellnet.com with ESMTP id jrVjNp0xKFrogqPc for ; Wed, 28 Jul 2010 08:55:15 -0500 (CDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jul 2010 09:55:15 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Wed, 28 Jul 2010 09:55:06 -0400 Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: questions about ETX (was: question on gain control) Date: Wed, 28 Jul 2010 09:55:05 -0400 Message-ID: <76DBCE2AA6605F42A49F1BD7454C841BEB0B69@usatlsv105.am.bm.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions about ETX (was: question on gain control) thread-index: Acst3cda4N2oajuWTv6iQLIAErL89gAd2dmw References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> From: "Monnerie, Emmanuel" To: X-OriginalArrivalTime: 28 Jul 2010 13:55:06.0665 (UTC) FILETIME=[7C405190:01CB2E5C] X-Barracuda-Connect: usatlsv15.am.bm.net[10.1.130.15] X-Barracuda-Start-Time: 1280325316 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Subject: [Roll] questions about ETX (was: question on gain control) 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: , X-List-Received-Date: Wed, 28 Jul 2010 13:54:55 -0000 That is correct. It is problematic to use SNR as a link quality indicator. Computing a SNR is not an easy matter, particularly when it has to be computed by a low cost and low power device. A SNR is the ratio of the received signal power of a good packet over the average noise power. When a link is bad, the device will not have many good packets to choose from to measure the signal power and therefore the statistics can be very inaccurately computed. I think that ETX or PRR are better metrics in general. But I have a similar question regarding the definition of the ETX metric (cf: draft-gnawali-roll-etxof-01). I think it is missing some parameters to be complete: Which packet transmission is used to compute this statistic? How long is the packet? My point is that the ETX value will depend on the length of the packet. The standard should either define a baseline packet length to compute this value or the definition of the ETX should be expanded to allow a normalization of this value, based on the length of the packets. Another question is: which ETX value should be used by default, when a device discovers a new link? Should it be Infinity, until the statistics are computed or should it be a more reasonable value (like 1 , 2 or 3)? Depending on which decision is made, the system behavior can change quite a bit. Any suggestion? -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Tuesday, July 27, 2010 6:48 PM To: Yoav Ben-Yehezkel Cc: roll@ietf.org Subject: Re: [Roll] question on gain control (...) > Actually using variable transmission power to infer link quality and stability is problematic: it can be a link has > high SNR but low PRR (e.g., due to external interference). >Phil Emmanuel Monnerie Senior Research Engineer Landis+Gyr Energy Management Solutions Office: +1 678 258 1695 Fax: +1 678 258 1316 Emmanuel.Monnerie@landisgyr.com www.landisgyr.com manage energy better From culler@cs.berkeley.edu Wed Jul 28 06:55:50 2010 Return-Path: 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 9B2DE3A687A for ; Wed, 28 Jul 2010 06:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 CtnIHMxafbRX for ; Wed, 28 Jul 2010 06:55:49 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 935D33A680A for ; Wed, 28 Jul 2010 06:55:49 -0700 (PDT) Received: from dhcp-86b4.meeting.ietf.org (dhcp-86b4.meeting.ietf.org [130.129.134.180]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6SDt2Sg021510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Jul 2010 06:56:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Tue, 27 Jul 2010 13:59:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <171741AB-4EAB-42D0-A13E-5DF7A3070F40@cs.berkeley.edu> References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Wed, 28 Jul 2010 13:55:50 -0000 The setting of the gain is of course a physical layer property. Many = chips provide many such parameters. Many link layers provide some = mechanisms to gain access to such properties. Selecting the channel or = SSID on your WiFi router is one such example. And you might even say it = was "up to the application" since it is accessed through a configuration = interface either by a human being or a management tool. But it is, of = course, not part of the network layer's interface to the link, and it is = not part of the routing protocol or the addressing structure. And it is = certainly not presented through the transport layer to the application. = Although, such things may be accessible to applications 'around the = side" through an IOCTL or other operating systems interface. All = networks face this issue. It is inherent in the separation of concerns = and technological decoupling that is inherent in a layered architecture. Yes the gain control affects the topology of the connectivity = relationship, and therefore what the routing protocol has to work with, = but that does not make it a routing protocol issue per se. The density = and placement of nodes also affects the available connectivity topology, = but the routing protocol is not going to manufacture some new nodes and = place them in convenient locations. Nor does it have the authority to = decide to ignore some nodes because it doesn't like the connections that = they introduce. Obviously, the question is jumbling together issues at very different = layers in the architecture. We might get all excited that this begs of = cross-layer visibility and optimization, but then again variants of this = appear in all sorts of other links. Whether you get 53 mbps, or 11 = mbps, or 3 mpbs, 1 mbps in modern 802.11 links depends on how far away = you are from the access point and what's in the way. Similarly, the = topology and available bandwidth of wired networks depends on what = switches and routers are used and how they are wired up. These aspects = of making the physical network organization match the target workload = are what capacity planning is all about. Why would the picture be any = different in LLNs? The routing protocol needs to find the best = available route within reasonable effort. It cannot prevent you from = assembling a network that fails to meet the demands of the workload. = Many factors may determine how any particular node sets its output gain = control, or whether a PA or an LNA are used. But unquestionably, they = are outside the purview of the layer 3 routing protocol. On Jul 26, 2010, at 9:17 PM, Yoav Ben-Yehezkel wrote: > It is up to the application which gains to use and how to use it with = DIS > messages. >=20 > We've used it in PLC networks in topologies with up to a few thousands = of > nodes, where each node on average has direct connectivity with about = 200 > nodes when using maximum gain and about 80% of the nodes using lower > transmission gain. >=20 > Our technology allows for 8 levels of gain, other technologies allows = for > some other values, Jennic's 802.15.4 modules allow for 4 levels of = gain > for example. This is completely application dependant. >=20 > Does this make sense? >=20 > Thanks, > Yoav >=20 >=20 > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Monday, July 26, 2010 11:32 PM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] question on gain control >=20 > On Sun, Jul 25, 2010 at 1:37 PM, Yoav Ben-Yehezkel > wrote: >> Hi, >>=20 >>=20 >>=20 >> I would like to probe the WG's opinion on the issue of transmission = at >> different transmission gains to obtain more reliability on the link > quality. >>=20 >>=20 >>=20 >> For example, somehow indicating the transmission power level on > DIS/DIO/DAO >> (maybe by percent of or db less than maximum transmission level) to = make >> sure that metrics are calculated/parents are selected, etc. only = based > on >> transmissions received with low transmission gains. >>=20 >>=20 >>=20 >> We've used this to make our topologies more stable in proprietary > solutions. >> The motivation is to have sufficient level of margin for noise before >> messages at high gain will not be received properly (i.e. if messages > are >> received at 6dB less than the maximum transmission gain, there's room > for at >> least 6 dB more noise before the messages will not be received - 6 dB = is > a >> lot of margin, so topologies remain very stable with this kind of > margin). >=20 > How low a gain would you consider for topology discovery if you were > to use this approach and the chip allows you to go to extremely low > values? How does this work on networks with different density? >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Wed Jul 28 08:21:29 2010 Return-Path: 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 ABCBF3A694A for ; Wed, 28 Jul 2010 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 UaqffuDM-FSR for ; Wed, 28 Jul 2010 08:21:27 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id D31F13A684F for ; Wed, 28 Jul 2010 08:21:26 -0700 (PDT) Received: from source ([74.125.82.181]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTFBLDGTK1zhykYpqhCIkBHUsdDDl8Cwv@postini.com; Wed, 28 Jul 2010 08:21:50 PDT Received: by mail-wy0-f181.google.com with SMTP id 36so5485693wyb.40 for ; Wed, 28 Jul 2010 08:21:48 -0700 (PDT) Received: by 10.227.128.82 with SMTP id j18mr10418271wbs.36.1280330507743; Wed, 28 Jul 2010 08:21:47 -0700 (PDT) From: Yoav Ben-Yehezkel References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> <171741AB-4EAB-42D0-A13E-5DF7A3070F40@cs.berkeley.edu> In-Reply-To: <171741AB-4EAB-42D0-A13E-5DF7A3070F40@cs.berkeley.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuXKWUOHxi1VAJSZWC7QegdFJT9gACas2A Date: Wed, 28 Jul 2010 18:21:39 +0300 Message-ID: To: David Culler Content-Type: multipart/alternative; boundary=0016e65a07881bf474048c742d74 Cc: roll@ietf.org Subject: Re: [Roll] question on gain control 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: , X-List-Received-Date: Wed, 28 Jul 2010 15:21:29 -0000 --0016e65a07881bf474048c742d74 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi David, Thanks for the long response. I hope I understood it well. I'm also not a fan of mixing between layers. You've convinced me that we shouldn't introduce gain control explicitly to the RPL mechanisms and I als= o agree that gain control is not a routing issue per se. It is an interface between L2 and L3 issue. However, from the point of view of L3 the issue was to allow for some optimization for "marginal" reliability when (re)connecting to a parent/DODAG. I described how to do it by using an L2 mechanism of gain control. The point I was trying to make for RPL was to have some way of requesting to connect with some margin for reliability. Gain control can be one means to do it in PLC networks, maybe SNR estimations can be the means in wireless. Maybe there're other ways to get this in other technologies also. However, I'm still requesting your assistance to address the issue of how t= o quantify some reliability margin possibly to an L3 metric/constraint or DIS filter that would make sense in L3, (I=92ll stop calling it gain control fr= om now J ). There's great potential for stabilizing the topology by reducing the amount of disconnections and reconnections with such a "marginal reliability" metric/filter/constraint for connection. It would be a short-coming of RPL relative to existing mesh-under methods in PLC if we don't introduce it IMHO. I'd appreciate any further thoughts on this. Best regards, Yoav -----Original Message----- From: David Culler [mailto:culler@cs.berkeley.edu] Sent: Tuesday, July 27, 2010 11:59 PM To: Yoav Ben-Yehezkel Cc: Omprakash Gnawali; roll@ietf.org Subject: Re: [Roll] question on gain control The setting of the gain is of course a physical layer property. Many chips provide many such parameters. Many link layers provide some mechanisms to gain access to such properties. Selecting the channel or SSID on your WiFi router is one such example. And you might even say it was "up to the application" since it is accessed through a configuration interface either by a human being or a management tool. But it is, of course, not part of the network layer's interface to the link, and it is not part of the routin= g protocol or the addressing structure. And it is certainly not presented through the transport layer to the application. Although, such things may be accessible to applications 'around the side" through an IOCTL or other operating systems interface. All networks face this issue. It is inherent in the separation of concerns and technological decoupling that is inherent in a layered architecture. Yes the gain control affects the topology of the connectivity relationship, and therefore what the routing protocol has to work with, but that does not make it a routing protocol issue per se. The density and placement of node= s also affects the available connectivity topology, but the routing protocol is not going to manufacture some new nodes and place them in convenient locations. Nor does it have the authority to decide to ignore some nodes because it doesn't like the connections that they introduce. Obviously, the question is jumbling together issues at very different layer= s in the architecture. We might get all excited that this begs of cross-laye= r visibility and optimization, but then again variants of this appear in all sorts of other links. Whether you get 53 mbps, or 11 mbps, or 3 mpbs, 1 mbps in modern 802.11 links depends on how far away you are from the access point and what's in the way. Similarly, the topology and available bandwidth of wired networks depends on what switches and routers are used and how they are wired up. These aspects of making the physical network organization match the target workload are what capacity planning is all about. Why would the picture be any different in LLNs? The routing protocol needs to find the best available route within reasonable effort. It cannot prevent you from assembling a network that fails to meet the demands of the workload. Many factors may determine how any particular nod= e sets its output gain control, or whether a PA or an LNA are used. But unquestionably, they are outside the purview of the layer 3 routing protocol. On Jul 26, 2010, at 9:17 PM, Yoav Ben-Yehezkel wrote: > It is up to the application which gains to use and how to use it with DIS > messages. > > We've used it in PLC networks in topologies with up to a few thousands of > nodes, where each node on average has direct connectivity with about 200 > nodes when using maximum gain and about 80% of the nodes using lower > transmission gain. > > Our technology allows for 8 levels of gain, other technologies allows for > some other values, Jennic's 802.15.4 modules allow for 4 levels of gain > for example. This is completely application dependant. > > Does this make sense? > > Thanks, > Yoav > > > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Monday, July 26, 2010 11:32 PM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] question on gain control > > On Sun, Jul 25, 2010 at 1:37 PM, Yoav Ben-Yehezkel > wrote: >> Hi, >> >> >> >> I would like to probe the WG's opinion on the issue of transmission at >> different transmission gains to obtain more reliability on the link > quality. >> >> >> >> For example, somehow indicating the transmission power level on > DIS/DIO/DAO >> (maybe by percent of or db less than maximum transmission level) to make >> sure that metrics are calculated/parents are selected, etc. only based > on >> transmissions received with low transmission gains. >> >> >> >> We've used this to make our topologies more stable in proprietary > solutions. >> The motivation is to have sufficient level of margin for noise before >> messages at high gain will not be received properly (i.e. if messages > are >> received at 6dB less than the maximum transmission gain, there's room > for at >> least 6 dB more noise before the messages will not be received - 6 dB is > a >> lot of margin, so topologies remain very stable with this kind of > margin). > > How low a gain would you consider for topology discovery if you were > to use this approach and the chip allows you to go to extremely low > values? How does this work on networks with different density? > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --0016e65a07881bf474048c742d74 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi David,

=A0

Thanks for the long response. I hope I understood= it well.

=A0

I'm also not a fan of mixing between layers. You've convinced me that we shouldn= 't introduce gain control explicitly to the RPL mechanisms and I also agree th= at gain control is not a routing issue per se. It is an interface between L2 and L3 issue.

=A0

However, from the point of view of L3 the issue was to allow for some optimization f= or "marginal" reliability when (re)connecting to a parent/DODAG. I described how to do it= by using an L2 mechanism of gain control. =A0The point I was trying to make fo= r RPL was to have some way of requesting to connect with some margin for reliabil= ity. Gain control can be one means to do it in PLC networks, maybe SNR estimatio= ns can be the means in wireless. Maybe there're other ways to get this in othe= r technologies also.

=A0

However, I'm still requesting your assistance to address the issue of how to qua= ntify some reliability margin possibly to an L3 metric/constraint or DIS filter that w= ould make sense in L3, (I=92ll stop calling it gain control from now J ). There's great potential for stabilizin= g the topology by reducing the amount of disconnections and reconnections with su= ch a "marginal reliability" metric/filter/constraint for connection. I= t would be a short-coming of RPL relative to existing mesh-under methods in P= LC if we don't introduce it IMHO.

=A0

I'd appreciate any further thoughts on this.<= /p>

=A0

Best regards,

Yoav

=A0

=A0

-----Original Message-----
From: David Culler [mailto:culler= @cs.berkeley.edu]
Sent: Tuesday, July 27, 2010 11:59 PM
To: Yoav Ben-Yehezkel
Cc: Omprakash Gnawali; roll@ietf.org Subject: Re: [Roll] question on gain control

=A0

The setting of the gain is of course a physical l= ayer property.=A0 Many chips provide many such parameters.=A0 Many link layers p= rovide some mechanisms to gain access to such properties.=A0 Selecting the channel= or SSID on your WiFi router is one such example.=A0 And you might even say it = was "up to the application" since it is accessed through a configurat= ion interface either by a human being or a management tool.=A0 But it is, of co= urse, not part of the network layer's interface to the link, and it is not pa= rt of the routing protocol or the addressing structure.=A0 And it is certainly no= t presented through the transport layer to the application.=A0 Although, such things may be accessible to applications 'around the side" through= an IOCTL or other operating systems interface.=A0 All networks face this issue= .=A0 It is inherent in the separation of concerns and technological decoupling that= is inherent in a layered architecture.

=A0

Yes the gain control affects the topology of the connectivity relationship, and therefore what the routing protocol has to w= ork with, but that does not make it a routing protocol issue per se.=A0 The den= sity and placement of nodes also affects the available connectivity topology, bu= t the routing protocol is not going to manufacture some new nodes and place t= hem in convenient locations.=A0 Nor does it have the authority to decide to ign= ore some nodes because it doesn't like the connections that they introduce.=

=A0

Obviously, the question is jumbling together issu= es at very different layers in the architecture.=A0 We might get all excited that= this begs of cross-layer visibility and optimization, but then again variants of this appear in all sorts of other links.=A0 Whether you get 53 mbps, or 11 = mbps, or 3 mpbs, 1 mbps in modern 802.11 links depends on how far away you are fr= om the access point and what's in the way.=A0 Similarly, the topology and = available bandwidth of wired networks depends on what switches and routers are used a= nd how they are wired up.=A0 These aspects of making the physical network organization match the target workload are what capacity planning is all about.=A0 Why would the picture be any different in LLNs?=A0 The routing pr= otocol needs to find the best available route within reasonable effort.=A0 It cann= ot prevent you from assembling a network that fails to meet the demands of the workload.=A0 Many factors may determine how any particular node sets its ou= tput gain control,=A0 or whether a PA or an LNA are used.=A0 But unquestionably,= they are outside the purview of the layer 3 routing protocol.

=A0

On Jul 26, 2010, at 9:17 PM, Yoav Ben-Yehezkel wr= ote:

=A0

> It is up to the application which gains to u= se and how to use it with DIS

> messages.

>

> We've used it in PLC networks in topolog= ies with up to a few thousands of

> nodes, where each node on average has direct connectivity with about 200

> nodes when using maximum gain and about 80% = of the nodes using lower

> transmission gain.

>

> Our technology allows for 8 levels of gain, = other technologies allows for

> some other values, Jennic's 802.15.4 mod= ules allow for 4 levels of gain

> for example. This is completely application dependant.

>

> Does this make sense?

>

> Thanks,

> Yoav

>

>

> -----Original Message-----

> From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu<= /a>]

> Sent: Monday, July 26, 2010 11:32 PM

> To: Yoav Ben-Yehezkel

> Cc: roll@ie= tf.org

> Subject: Re: [Roll] question on gain control=

>

> On Sun, Jul 25, 2010 at 1:37 PM, Yoav Ben-Ye= hezkel <yoav@yitran.com>

> wrote:

>> Hi,

>>

>>

>>

>> I would like to probe the WG's opini= on on the issue of transmission at

>> different transmission gains to obtain m= ore reliability on the link

> quality.

>>

>>

>>

>> For example, somehow indicating the tran= smission power level on

> DIS/DIO/DAO

>> (maybe by percent of or db less than max= imum transmission level) to make

>> sure that metrics are calculated/parents= are selected, etc. only based

> on

>> transmissions received with low transmis= sion gains.

>>

>>

>>

>> We've used this to make our topologi= es more stable in proprietary

> solutions.

>> The motivation is to have sufficient lev= el of margin for noise before

>> messages at high gain will not be receiv= ed properly (i.e. if messages

> are

>> received at 6dB less than the maximum transmission gain, there's room

> for at

>> least 6 dB more noise before the message= s will not be received - 6 dB is

> a

>> lot of margin, so topologies remain very= stable with this kind of

> margin).

>

> How low a gain would you consider for topolo= gy discovery if you were

> to use this approach and the chip allows you= to go to extremely low

> values? How does this work on networks with different density?

>

> - om_p

> ____________________________________________= ___

> Roll mailing list

> Roll@ietf.o= rg

> https://www.ietf.org/mailman/listinfo/roll

=A0

--0016e65a07881bf474048c742d74-- From dat@exegin.com Wed Jul 28 13:49:46 2010 Return-Path: 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 2CF6A3A6A55 for ; Wed, 28 Jul 2010 13:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, 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 S1irVmetuHiX for ; Wed, 28 Jul 2010 13:49:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 5EC2828C0D8 for ; Wed, 28 Jul 2010 13:49:44 -0700 (PDT) Received: by ewy22 with SMTP id 22so2144921ewy.31 for ; Wed, 28 Jul 2010 13:50:07 -0700 (PDT) Received: by 10.213.30.15 with SMTP id s15mr8697890ebc.48.1280350206933; Wed, 28 Jul 2010 13:50:06 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id a48sm9807eei.13.2010.07.28.13.50.04 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 13:50:05 -0700 (PDT) Message-ID: <4C5097F1.9050107@exegin.com> Date: Wed, 28 Jul 2010 13:49:53 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: JP Vasseur References: <055.24ccd27cbd1af8e9aee22895dacdb4a6@tools.ietf.org> <064.674f58452901dadf907dc72ef817dfb1@tools.ietf.org> <4C4F7466.80905@exegin.com> <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> In-Reply-To: <3546C078-9F76-40E6-8C4B-B90E884376AE@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option 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: , X-List-Received-Date: Wed, 28 Jul 2010 20:49:46 -0000 That seems a more appropriate place for it. Thanks. JP Vasseur wrote: > Thanks for your email. As discussed, it will go in the RPL option. > > On Jul 28, 2010, at 2:05 AM, Dario Tedeschi wrote: > >> >> If the flow label is used by a source to identify a RPL Instance how >> would the same source use the flow label for other flows not related >> to RPL. Put another way, if an application (or a transport like TCP) >> wanted to identify a new data flow, how would the ingress router know >> that the label was identifying the new flow and not the RPL Instance. >> >> Reading RFC 3697, it would appear that the flow label is used in >> identifying the end-to-end flow, not for identify a route. >> >> From Section 2 in RFC 3697: >> >> The Flow Label value set by the source MUST be delivered unchanged to >> the destination node(s). >> IPv6 nodes MUST NOT assume any mathematical or other properties of >> the Flow Label values assigned by source nodes. Router performance >> SHOULD NOT be dependent on the distribution of the Flow Label values. >> >> >> Regards >> Dario >> >> roll issue tracker wrote: >>> #64: RPL Instance ID in flow label or RPL option >>> -----------------------------+---------------------------------------------- >>> >>> Reporter: jpv@… | Owner: pthubert@… >>> Type: enhancement | Status: closed >>> Priority: major | Milestone: >>> Component: rpl | Version: >>> Severity: In WG Last Call | Resolution: fixed >>> Keywords: | >>> -----------------------------+---------------------------------------------- >>> >>> Changes (by jpv@…): >>> >>> * status: new => closed >>> * resolution: => fixed >>> >>> >>> Comment: >>> >>> Email from JP July 24 Following an email from Pascal. >>> >>> Great text, which I think address the ticket - minor comments below. >>> >>> On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote: >>> >>> Dear WG: >>> >>> Long discussions lead to specify only the location of the RPLinstanceID >>> inside the RPL network, leaving it to policies the way the ingress >>> router >>> figures it out. The RPLinstanceID will be placed in the RPL option >>> which >>> is probably the cleanest and most generic thing we can do. Other drafts >>> are allowed to come later and provide alternate forwarding rules >>> eventually placing the content of the RPL option validation somewhere >>> else, for instance in order to avoid IPinIP. A forwarding mode will >>> probably indicate what the network does. >>> >>> Proposed changes: >>> >>> RPL uses a hop-by-hop IPv6 header to detect possible loops within a >>> DODAG. >>> -> >>> RPL carries routing information in a RPL Option >>> contained in >>> an IPv6 >>> Hop-by-Hop Option as specified in [I-D.hui-6man-rpl- >>> option]. Such >>> routing information are used for example for loop >>> detection within a >>> DODAG as discussed in Section 11.2 and may be >>> extended in >>> future >>> documents for additional features. >>> >>> >>> For data packets, the RPLInstanceID may be indicated in the flow >>> label by the source of the packet. If it is not, then it is inferred >>> and added by the RPL network ingress router in the RPL Hop-by-hop >>> option ([I-D.hui-6man-rpl-option]) as further described in >>> Section 10.2 >>> >>> è >>> >>> Data packet that flow within the RP network expose the >>> RPLInstanceID >>> in the RPL option that is specified in >>> [I-D.hui-6man-rpl- >>> option], and >>> further described in Section 11.2. For data packets >>> coming >>> from >>> outside the RPL network, the RPLInstanceID is >>> determined >>> by the RPL >>> network ingress router and placed in the RPL option >>> that >>> is added to >>> the packet. >>> >>> >>> RPL loop detection uses information that is placed into the packet. >>> A future version of this specification will detail how this >>> information is carried with the packet (e.g. a hop-by-hop option >>> ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow >>> label). For the purpose of RPL operations, the information carried >>> with a packet is constructed follows: >>> >>> è >>> RPL loop detection uses information that contained >>> within the >>> data >>> packet using the RPL Option [I-D.hui-6man-rpl-option]) >>> in an >>> IPv6 >>> Hop-by-Hop Option header. The RPL Option is a generic >>> container for >>> a list of TLVs. This specification defines a new RPL >>> Option type, >>> called the RPL Loop Detection. The RPL Loop >>> Detection TLV >>> is placed >>> in the RPL Option with Option Type = 1 (to be >>> confirmed by >>> IANA), >>> Option Data Length = 4 octets, and the Value has the >>> following >>> format: >>> >>> >>> >>> The RPLInstanceID is associated by the source with the packet. This >>> RPLInstanceID MUST match the RPL Instance onto which the packet is >>> placed by any node, be it a host or router. For traffic originating >>> outside of the RPL domain there may be a mapping occurring at the >>> gateway into the RPL domain, possibly based on an encoding within the >>> flow label. This aspect of RPL operation is to be clarified in a >>> future version of this specification. >>> >>> The source of the packet might be aware of the RPL network, of the >>> constraints imposed on OFs, and of associated Instance IDs. In that >>> case, the source of the packet MAY tag the flow label with the >>> RPLInstanceID, in which case it is used in that form within the RPL >>> network. >>> >>> A router that injects a data packet into the RPL network MUST tag the >>> packet by inserting a RPL Hop-by-hop option as specified in >>> [I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in >>> flow label of the data packet, the ingress router that injects the >>> packet into the RPL network MUST add a RPLInstanceID field to the RPL >>> Hop-by-hop option. >>> >>> è >>> The RPLInstanceID is associated by the source with the >>> packet. This >>> RPLInstanceID MUST match the RPL Instance onto which >>> the >>> packet is >>> placed by any node, be it a host or router. >>> >>> For a packet that is originated from outside the RPL >>> network, the >>> source of the packet might be aware of the RPL >>> network, of >>> the >>> constraints imposed on OFs, and of associated >>> RPLInstanceIDs. In >>> that case, the source of the packet MAY tag the flow >>> label >>> with the >>> RPLInstanceID. >>> >>> A RPL router that forwards a packet in the RPL network >>> MUST check if >>> the packet includes the RPL Loop Detection TLV in a RPL >>> Option within >>> the IPv6 Hop-by-Hop Option header. If one does not >>> exist, >>> the RPL >>> router MUST insert a RPL Loop Detection type as >>> specified >>> in >>> >>> >>> [I-D.hui-6man-rpl-option]. If the router is an ingress >>> router that >>> injects the packet into the RPL network, the router >>> MUST >>> set the >>> RPLInstanceID field in the RPL Loop Detection TLV. >>> >>> >>> >>> JP> + add: >>> >>> A router that forwards a packet to outside the RPL domain MUST >>> remove the RPL Option as specified in [I-D.ietf-6man-rpl-option]. >>> >>> As usual, please speak up if there’s an issue with the proposed >>> resolution! >>> >>> Pascal >>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From yoav@yitran.com Wed Jul 28 23:58:14 2010 Return-Path: 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 456883A6896 for ; Wed, 28 Jul 2010 23:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Rap67YvU8MFk for ; Wed, 28 Jul 2010 23:58:13 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id DA5323A67E7 for ; Wed, 28 Jul 2010 23:58:11 -0700 (PDT) Received: from source ([74.125.82.44]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTFEmmf66OSsQ1XfrA5Pf7ADyl3A4Hz9A@postini.com; Wed, 28 Jul 2010 23:58:36 PDT Received: by wwj40 with SMTP id 40so16132wwj.1 for ; Wed, 28 Jul 2010 23:58:33 -0700 (PDT) Received: by 10.227.32.82 with SMTP id b18mr11748033wbd.149.1280386707633; Wed, 28 Jul 2010 23:58:27 -0700 (PDT) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuK7N9ZZRme4ylSbayCNz+ge0MmQAt9RFg Date: Thu, 29 Jul 2010 09:58:20 +0300 Message-ID: To: pal@cs.stanford.edu, T.Clausen@computer.org, jhui@archrock.com, gnawali@cs.stanford.edu, jgko@cs.jhu.edu Content-Type: multipart/alternative; boundary=002215b038a2e23971048c8142be Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 06:58:14 -0000 --002215b038a2e23971048c8142be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Authors/ROLL WG, Find below some minor comments/clarifications I have on the Trickle draft. Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is poten= tially not used solely by wireless =96 though it was developed on a wireless platf= orm I understand). It appears in the abstract, in the intro, at the last para of section 3., a= t section 6.7. =93Abstract The Trickle algorithm allows *wireless* nodes to exchange information in a highly robust,...=94 =931. Introduction The Trickle algorithm is designed for *wireless* networks.=94 =933. Trickle Algorithm Overview =85 Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. This is an important property in *wireless* networks, where the channel is a valuable shared resource.=94 =936.7. Tweaks and improvements to Trickle =85 However, in dynamic network environments such as *wireless*, the coordination needed to compute the=85 Last paragraph of section 3 is a little unclear to me. =93 A single, disconnected node must transmit at the communication rate.= =94 Can you clarify this sentence? What do you mean by =93must transmit at the communication rate=94? The communication rate is the output of the number o= f transmissions a disconnected node makes, not the other way around. =93 In a lossless, single-hop network of size n, the sum of transmissions over the network is the communication rate, so for each node it is 1/n.=94 I think =93the sum of transmissions=94 should be =93the sum of transmission rates=94, right? This property is true only if all nodes have the same arri= val rates. Is this always the case, or just the case when using trickle? You probably mean that this is a long term average, not always, right? Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. This is an important property in wireless networks, where the channel is a valuable shared resource. Additionally, reducing transmissions in dense networks conserves system energy.=94 I think the word Trickle is missing in the above to emphasize the fact that what you describe is true for the trickle mechanism, not in a network consisting of both trickle control data together with application data. I have some questions/clarifications for section 4.2: Generally, what I think required is a more precise description of the term =93interval=94. When does an interval start? When did the previous ended? After the previous I expires or when t is reached (and transmission or suppression of transmission is decided on)? It is not so clear in the text. If it is when I expires, then after the transmission a node must wait from the randomized time t till I expires and then re-randomize the next t, and that leads to the question of what happens with all the (in)consistencies it hears till the next interval starts? Should they be counted as well (in step 2 it says to count all consistencies and in step 1 it says to set c to 0, i.e. disregard counts from t till I expires)? Some clarification would be helpful. One comment on operational considerations (section 6): Do you see value in describing some typical =93events=94 that can be used t= o reset the timer? What are the guidelines/limitations for doing these resets= , what could be considered good events and what could be considered bad events? Best regards, Yoav --002215b038a2e23971048c8142be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Authors/ROLL WG,

=A0

Find below some minor comments/clarifications I have on the = Trickle draft.

=A0

Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is potentially not used solely by wireless =96 though it was developed on a wireless platform I understand).

=A0

It appears in the abstract, in the intro, at the last para o= f section 3., at section 6.7.

=93Abstract

=A0

=A0=A0 The Trickle algorithm allows wireless nodes to exchange information<= /span>

=A0=A0 in a highly robust,...=94

=A0

=A0

=931.=A0 Introduction
=A0
=A0=A0 The Trickle algorithm is designed for wireless networks.=94=

=A0

=933. Trickle Algorithm Overview
=
=A0=A0 =85 Sparser networks require more transmissions per node, but
<= pre>=A0=A0 utilization of the radio channel over space will not increase.= =A0 This 
=A0=A0 is an important property in wireless networks, where the=
 channel is a
=A0=A0 valuable shared resource.=94

=A0

=936.7.=A0 Tweaks and improvements=
 to Trickle
=A0=A0 =85 However, in dynamic network environ=
ments such as wireless,
=A0=A0 the coordination needed to =
compute the=85
=A0

=A0

Last paragraph of section 3 is a little unclear to me. 

=93=A0 A single, disconnected node must transmit at the communication =
rate.=94

Can you clarify this sentence? What do you mean by =93must transmit at the communication rate=94? The communication rate is the output of the number of transmissions a disconnected node makes, not the other way around.

=A0
=93=A0 In a lossless, single-hop network of size n, the =
sum of transmissions
=A0=A0 over the network is the communication=
 rate, so for each node it is
=A0=A0 1/n.=94

I think =93the sum of transmissions=94 should be =93the sum of transmission rates=94, right? This property is true only if all nodes have the same arrival rates. Is this always the case, or just the cas= e when using trickle? You probably mean that this is a long term average, not alwa= ys, right?

=A0
 =A0=A0Sparser networks require more transmissions per n=
ode, but
=A0=A0 utilization of the radio channel over space will =
not increase.=A0 This
=A0=A0 is an important property in wireless=
 networks, where the channel is a
=A0=A0 valuable shared resource.=A0 Additionally, reducing transmissio=
ns in
=A0=A0 dense networks conserves system energy.=94
I think the word Trickle is missing in the abov= e to emphasize the fact that what you describe is true for the trickle mech= anism, not in a network consisting of both trickle control data together wi= th application data. 
=A0
=A0

I have some questions/clarifications for section 4.2:= 

Generally, what I think required is a more precise descripti=
on of the term =93interval=94.
=
When does an interval start? When did the previous ended? After the previou=
s I expires or when t is reached (and transmission or suppression of transm=
ission is decided on)? It is not so clear in the text. If it is =A0when I e=
xpires, then after the transmission a node must wait from the randomized ti=
me t till I expires and then re-randomize the next t, and that leads to the=
 question of what happens with all the (in)consistencies it hears till the =
next interval starts? Should they be counted as well (in step 2 it says to =
count all consistencies and in step 1 it says to set c to 0, i.e. disregard=
 counts from t till I expires)? Some clarification would be helpful.=

=A0

One comment on operational considerations (section 6):

Do you see value in describing some typical =93events=94 that can be used to reset the timer? What are the guidelines/limitations fo= r doing these resets, what could be considered good events and what could be considered bad events?

=A0

Best regards,

Yoav

=A0

--002215b038a2e23971048c8142be-- From c.chauvenet@watteco.com Thu Jul 29 02:08:51 2010 Return-Path: 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 A81EF3A69D7 for ; Thu, 29 Jul 2010 02:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 k9hdWeE6pcLi for ; Thu, 29 Jul 2010 02:08:50 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id D86FF3A69EE for ; Thu, 29 Jul 2010 02:08:44 -0700 (PDT) Received: from dhcp-87d7.meeting.ietf.org ([130.129.135.215]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id LQM85805; Thu, 29 Jul 2010 11:09:05 +0200 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-2--707849295 From: =?iso-8859-1?Q?Chauvenet_C=E9dric?= In-Reply-To: Date: Thu, 29 Jul 2010 11:09:04 +0200 Message-Id: <3018F86A-6DAE-4187-9EB1-B565A1191846@watteco.com> References: To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) Cc: T.Clausen@computer.org, roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 09:08:51 -0000 --Apple-Mail-2--707849295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi all, I support first Yoav comment. As RPL is PHY agnostic, wireless references should be limited. The LLN term is more general end well suited here. Regards, C=E9dric Le 29 juil. 2010 =E0 08:58, Yoav Ben-Yehezkel a =E9crit : > Authors/ROLL WG, > =20 > Find below some minor comments/clarifications I have on the Trickle = draft. > =20 > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is = potentially not used solely by wireless =96 though it was developed on a = wireless platform I understand). > =20 > It appears in the abstract, in the intro, at the last para of section = 3., at section 6.7. > =93Abstract > =20 > The Trickle algorithm allows wireless nodes to exchange information > in a highly robust,...=94 > =20 > =20 > =931. Introduction > =20 > The Trickle algorithm is designed for wireless networks.=94 > =20 > =933. Trickle Algorithm Overview > =85 Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. = This > is an important property in wireless networks, where the channel is = a > valuable shared resource.=94 > =20 > =936.7. Tweaks and improvements to Trickle > =85 However, in dynamic network environments such as wireless, > the coordination needed to compute the=85 > =20 > =20 > Last paragraph of section 3 is a little unclear to me. > =93 A single, disconnected node must transmit at the communication = rate.=94 > Can you clarify this sentence? What do you mean by =93must transmit at = the communication rate=94? The communication rate is the output of the = number of transmissions a disconnected node makes, not the other way = around. > =20 > =93 In a lossless, single-hop network of size n, the sum of = transmissions > over the network is the communication rate, so for each node it is > 1/n.=94 > I think =93the sum of transmissions=94 should be =93the sum of = transmission rates=94, right? This property is true only if all nodes = have the same arrival rates. Is this always the case, or just the case = when using trickle? You probably mean that this is a long term average, = not always, right? > =20 > Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. = This > is an important property in wireless networks, where the channel is = a > valuable shared resource. Additionally, reducing transmissions in > dense networks conserves system energy.=94 > I think the word Trickle is missing in the above to emphasize the fact = that what you describe is true for the trickle mechanism, not in a = network consisting of both trickle control data together with = application data. > =20 > =20 > I have some questions/clarifications for section 4.2: > Generally, what I think required is a more precise description of the = term =93interval=94. > When does an interval start? When did the previous ended? After the = previous I expires or when t is reached (and transmission or suppression = of transmission is decided on)? It is not so clear in the text. If it is = when I expires, then after the transmission a node must wait from the = randomized time t till I expires and then re-randomize the next t, and = that leads to the question of what happens with all the = (in)consistencies it hears till the next interval starts? Should they be = counted as well (in step 2 it says to count all consistencies and in = step 1 it says to set c to 0, i.e. disregard counts from t till I = expires)? Some clarification would be helpful. > =20 > One comment on operational considerations (section 6): > Do you see value in describing some typical =93events=94 that can be = used to reset the timer? What are the guidelines/limitations for doing = these resets, what could be considered good events and what could be = considered bad events? > =20 > Best regards, > Yoav > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-2--707849295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi all,

I support first Yoav = comment.

As RPL is PHY agnostic, wireless = references should be limited.
The LLN term is more general end = well suited = here.

Regards,
C=E9dric

<= div>
Le 29 juil. 2010 =E0 08:58, Yoav Ben-Yehezkel a =E9crit = :

Authors/ROLL WG,

 

Find below some minor = comments/clarifications I have on the Trickle draft.

 

Suggest to replace the term = =93wireless=94 with =93LLN=94 (trickle is potentially not used solely by = wireless =96 though it was developed on a wireless platform I = understand).

 

It = appears in the abstract, in the intro, at the last para of section 3., = at section 6.7.
=93Abstract

 

   The Trickle algorithm = allows wireless nodes to exchange = information
   in a highly = robust,...=94

=931.  = Introduction

 
   The Trickle algorithm =
is designed for wireless networks.=94

 

=933. =
Trickle Algorithm Overview
   utilization of the radio channel over =
space will not increase.  This
   is an important =
property in wireless networks, where the channel is a
 
=936.7.  Tweaks and =
improvements to Trickle
   =85 However, in dynamic =
network environments such as wireless,
Last paragraph of =
section 3 is a little unclear to me.
=93  A single, =
disconnected node must transmit at the communication rate.=94
Can you clarify this sentence? = What do you mean by =93must transmit at the communication rate=94? The = communication rate is the output of the number of transmissions a = disconnected node makes, not the other way around.
=93  In a lossless, single-hop network of size n, =
the sum of transmissions
   over the network is the =
communication rate, so for each node it is
   =
1/n.=94
I think =93the sum of = transmissions=94 should be =93the sum of transmission rates=94, right? = This property is true only if all nodes have the same arrival rates. Is = this always the case, or just the case when using trickle? You probably = mean that this is a long term average, not always, = right?
 
   Sparser networks =
require more transmissions per node, but
   utilization =
of the radio channel over space will not increase.  This
   valuable shared resource.  =
Additionally, reducing transmissions in
   dense =
networks conserves system energy.=94
I think the =
word Trickle is missing in the above to emphasize the fact that what you =
describe is true for the trickle mechanism, not in a network consisting =
of both trickle control data together with application =
data.
 
 
I have some questions/clarifications for section = 4.2:
Generally, what I think required =
is a more precise description of the term =93interval=94.
When does an interval start? When did the previous = ended? After the previous I expires or when t is reached (and = transmission or suppression of transmission is decided on)? It is not so = clear in the text. If it is  when I expires, then after the = transmission a node must wait from the randomized time t till I expires = and then re-randomize the next t, and that leads to the question of what = happens with all the (in)consistencies it hears till the next interval = starts? Should they be counted as well (in step 2 it says to count all = consistencies and in step 1 it says to set c to 0, i.e. disregard counts = from t till I expires)? Some clarification would be = helpful.
 
One = comment on operational considerations (section 6):
Do you see value in describing = some typical =93events=94 that can be used to reset the timer? What are = the guidelines/limitations for doing these resets, what could be = considered good events and what could be considered bad = events?

Best = regards,

Yoav

=20 > =20 > Last paragraph of section 3 is a little unclear to me. > =93 A single, disconnected node must transmit at the communication = rate.=94 > Can you clarify this sentence? What do you mean by =93must transmit at = the communication rate=94? The communication rate is the output of the = number of transmissions a disconnected node makes, not the other way = around. Ah -- I see. This sentence is referring to the prior paragraph, which = reads: "As long as the network is connected and there is some minimum = communication rate for each node, the network will reach eventual = consistency." The point is that communication is either transmission or reception and = that the edge case of a solitary node, its communication will be all = transmissions. In networks of multiple nodes, a node's communication can = be some mix of receptions and transmissions. Would it make more sense if the text read "Trickle communication rate" = rather than "communication rate?" > =20 > =93 In a lossless, single-hop network of size n, the sum of = transmissions > over the network is the communication rate, so for each node it is > 1/n.=94 > I think =93the sum of transmissions=94 should be =93the sum of = transmission rates=94, right? This property is true only if all nodes = have the same arrival rates. Is this always the case, or just the case = when using trickle? You probably mean that this is a long term average, = not always, right? I don't understand -- the same arrival rates? It's a lossless, = single-hop network: when a node transmits, every other node hears the = transmission. So the communication (reception+transmission) rates across = the network are uniform. > =20 > Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. = This > is an important property in wireless networks, where the channel is = a > valuable shared resource. Additionally, reducing transmissions in > dense networks conserves system energy.=94 > I think the word Trickle is missing in the above to emphasize the fact = that what you describe is true for the trickle mechanism, not in a = network consisting of both trickle control data together with = application data. Which sentence do you think is unclear? Is it that application data does = not necessarily follow this property of scaling? I'd like to think there = is some context, and that it doesn't have to be that every sentence says = Trickle in it. > =20 > =20 > I have some questions/clarifications for section 4.2: > Generally, what I think required is a more precise description of the = term =93interval=94. > When does an interval start? When did the previous ended? After the = previous I expires or when t is reached (and transmission or suppression = of transmission is decided on)? It is not so clear in the text. If it is = when I expires, then after the transmission a node must wait from the = randomized time t till I expires and then re-randomize the next t, and = that leads to the question of what happens with all the = (in)consistencies it hears till the next interval starts? Should they be = counted as well (in step 2 it says to count all consistencies and in = step 1 it says to set c to 0, i.e. disregard counts from t till I = expires)? Some clarification would be helpful. =46rom -02: o I, the current interval size 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). I'm not sure how this can be more precise... would changing the text to 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). The interval ends at I. be helpful? > =20 > One comment on operational considerations (section 6): > Do you see value in describing some typical =93events=94 that can be = used to reset the timer? What are the guidelines/limitations for doing = these resets, what could be considered good events and what could be = considered bad events? >=20 I'm really a bit wary of doing this -- almost any recommendations we = could come up with would be wrong in some cases. E.g., the = recommendations for multicast are very different than protocol = acknowledgment timing. Perhaps the document can point to references of a = few examples of its use, from which a reader might benefit? Phil From joakime@sics.se Thu Jul 29 03:09:52 2010 Return-Path: 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 6A02F3A68E7 for ; Thu, 29 Jul 2010 03:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, HELO_EQ_SE=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 1bBefm-Eefci for ; Thu, 29 Jul 2010 03:09:51 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 836BC3A63C9 for ; Thu, 29 Jul 2010 03:09:51 -0700 (PDT) Received: from [192.168.1.144] (c-ef1ae455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.26.239]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id A2BA1400DA; Thu, 29 Jul 2010 12:10:14 +0200 (CEST) Message-ID: <4C515386.5040401@sics.se> Date: Thu, 29 Jul 2010 12:10:14 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: roll@ietf.org References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> In-Reply-To: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 10:09:52 -0000 Regarding mismatched Imax, From section: 6.3. Mismatched Imax: "If nodes do not agree on Imax, then this can cause long-term problems with transmission load. Nodes with small Imax values will transmit faster, suppressing those with larger Imax values. The nodes with larger Imax values, always suppressed, will never transmit. In the base case, when the network is consistent, this can cause long-term inequities in energy cost." This only mentions problems with energy costs. But is it not also a problem if these nodes that never transmits are also the only link to other nodes in the network? This might cause very slow propagation of new information to these weakly connected parts of the network. I think it is a good thing to warn a bit more for mismatched Imax. Best regards, -- Joakim Eriksson, SICS From yoav@yitran.com Thu Jul 29 03:47:33 2010 Return-Path: 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 617723A69C0 for ; Thu, 29 Jul 2010 03:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ihnrjpq60PyR for ; Thu, 29 Jul 2010 03:47:29 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id B8FB33A69BC for ; Thu, 29 Jul 2010 03:47:28 -0700 (PDT) Received: from source ([74.125.82.176]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTFFcV/s6Q39R0H6s3q3AfT5E174U+kXl@postini.com; Thu, 29 Jul 2010 03:47:53 PDT Received: by wyf23 with SMTP id 23so193159wyf.35 for ; Thu, 29 Jul 2010 03:47:51 -0700 (PDT) Received: by 10.227.157.70 with SMTP id a6mr12000966wbx.163.1280400470745; Thu, 29 Jul 2010 03:47:50 -0700 (PDT) From: Yoav Ben-Yehezkel References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> In-Reply-To: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsvA2lnfC3cmG3BTfmaHOmiU83RiQAAP9RQ Date: Thu, 29 Jul 2010 13:47:43 +0300 Message-ID: To: Philip Levis Content-Type: multipart/alternative; boundary=001636416ae13aa474048c847708 Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 10:47:33 -0000 --001636416ae13aa474048c847708 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Phil, I think now I understand better some of the points. With these understandings, I=92d like to bring up some more the topics for further discussion. I=92m OK with all your explanations excluding the ones that are= in the below list. ---- > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is pot= entially not used solely by wireless =96 though it was developed on a wireless platf= orm I understand). =85 Phil: "Correspondingly, I don't think LLN is the right term either. How about "lossy broadcast-based networks," with a few examples (e.g., wireless= , PLC)?" Yoav: I definitely support the examples. I'm not familiar with the term "lossy broadcast-based networks", is this a commonly used term? To me, something like "lossy and partially connected networks" would make more sense. But if people understand what that means, = I wouldn't object. ---- > Last paragraph of section 3 is a little unclear to me. =85 Phil: Would it make more sense if the text read "Trickle communication rate= " rather than "communication rate?" Yoav: It would make sense to explain some terminology. For example, communication rate, maybe also: (in)consistency, event, maybe also =93lossy broadcast-based networks=94 that you spoke of earlier. Specifically, to me = the term =93communication rate=94 was not self-explanatory and I would apprecia= te it if you described it somewhere. Yoav: Something like: =94communication rate =96 the communication rate of a= node is the sum of transmission and reception rates of this node.=94 Yoav: maybe also: =93Trickle communication rate =96 the trickle communicati= on rate equals the communication rate of trickle messages only.=94 With this understanding in mind, I still think that the sentence: =93 A single, disconnected node must transmit at the communication rate.= =94 Yoav: Is somewhat misleading, and mixes the outcome with the given scenario= . Yoav: Would you consider a re-write in the form of: Yoav: "In the case of a single, disconnected node, the communication rate i= s equal to the transmission rate." Yoav: Is this what you were trying to say? ---- > > =93 In a lossless, single-hop network of size n, the sum of transmission= s > over the network is the communication rate, so for each node it is > 1/n.=94 =85 Yoav: How does one sum up transmissions? It is not a numeric value. One can count them, or sum their rates. Yoav: I agree that the transmission rates will be uniformly distributed whe= n using the trickle and the same communication rates will be the sum of the transmission rates. Yoav: Trying to follow this logic, I would like to propose the following re-write here: Yoav: " In a lossless, single-hop network of size n, the sum of transmissio= n rates of trickle messages (summed over all nodes) equals the trickle communication rate of each node separately. The trickle mechanism balances the load in such a scenario, such that for each node, the transmission rate of trickle messages is 1/n times the trickle communication rate." Yoav: Is the above correct? Does it clarify my point better? ---- > I have some questions/clarifications for section 4.2: =85 Phil: I'm not sure how this can be more precise... would changing the text to Phil: 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). The interval ends at I. Phil: be helpful? Yoav: Yes! So is my understanding that between t and I, there's no meaning to counting consistencies correct? Would it promote this understanding (not so much implementation or correctness) if you change rule 2. to: Yoav: " 2. Whenever Trickle hears a transmission that is "consistent," it increments counter c." to: Yoav: " 2. Whenever Trickle hears a transmission that is "consistent," *unt= il t expires*, it increments counter c." ---- > One comment on operational considerations (section 6): =85 Phil: Perhaps the document can point to references of a few examples of its use, from which a reader might benefit? Yoav: that would be good enough for me. ---- Thanks for the productive response. Best Regards, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Thursday, July 29, 2010 12:50 PM To: Yoav Ben-Yehezkel Cc: T.Clausen@computer.org; jhui@archrock.com; gnawali@cs.stanford.edu; jgko@cs.jhu.edu; roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 Yoav, my comments are inline. On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote: > Authors/ROLL WG, > > Find below some minor comments/clarifications I have on the Trickle draft= . > > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is pot= entially not used solely by wireless =96 though it was developed on a wireless platf= orm I understand). > > It appears in the abstract, in the intro, at the last para of section 3., at section 6.7. > =93Abstract > > The Trickle algorithm allows wireless nodes to exchange information > in a highly robust,...=94 > > > =931. Introduction > > The Trickle algorithm is designed for wireless networks.=94 > > =933. Trickle Algorithm Overview > =85 Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. This > is an important property in wireless networks, where the channel is a > valuable shared resource.=94 > > =936.7. Tweaks and improvements to Trickle > =85 However, in dynamic network environments such as wireless, > the coordination needed to compute the=85 This is a good point. What this text is trying to get at is that Trickle is designed for, and well-suited to, lossy broadcast media. We've never really examined its use in low-loss switched networks (e.g., Ethernet). When the algorithm was designed, lossy broadcast media basically meant wireless, and not just low-power wireless. E.g., Trickle is well suited to 802.11. We didn't really consider PLC -- in the context of ROLL, however, it should definitely be considered. Correspondingly, I don't think LLN is the right term either. How about "lossy broadcast-based networks," with a few examples (e.g., wireless, PLC)= ? > > > Last paragraph of section 3 is a little unclear to me. > =93 A single, disconnected node must transmit at the communication rate.= =94 > Can you clarify this sentence? What do you mean by =93must transmit at th= e communication rate=94? The communication rate is the output of the number o= f transmissions a disconnected node makes, not the other way around. Ah -- I see. This sentence is referring to the prior paragraph, which reads= : "As long as the network is connected and there is some minimum communicatio= n rate for each node, the network will reach eventual consistency." The point is that communication is either transmission or reception and tha= t the edge case of a solitary node, its communication will be all transmissions. In networks of multiple nodes, a node's communication can be some mix of receptions and transmissions. Would it make more sense if the text read "Trickle communication rate" rather than "communication rate?" > > =93 In a lossless, single-hop network of size n, the sum of transmission= s > over the network is the communication rate, so for each node it is > 1/n.=94 > I think =93the sum of transmissions=94 should be =93the sum of transmissi= on rates=94, right? This property is true only if all nodes have the same arri= val rates. Is this always the case, or just the case when using trickle? You probably mean that this is a long term average, not always, right? I don't understand -- the same arrival rates? It's a lossless, single-hop network: when a node transmits, every other node hears the transmission. So the communication (reception+transmission) rates across the network are uniform. > > Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. This > is an important property in wireless networks, where the channel is a > valuable shared resource. Additionally, reducing transmissions in > dense networks conserves system energy.=94 > I think the word Trickle is missing in the above to emphasize the fact that what you describe is true for the trickle mechanism, not in a network consisting of both trickle control data together with application data. Which sentence do you think is unclear? Is it that application data does no= t necessarily follow this property of scaling? I'd like to think there is som= e context, and that it doesn't have to be that every sentence says Trickle in it. > > > I have some questions/clarifications for section 4.2: > Generally, what I think required is a more precise description of the ter= m =93interval=94. > When does an interval start? When did the previous ended? After the previous I expires or when t is reached (and transmission or suppression of transmission is decided on)? It is not so clear in the text. If it is when I expires, then after the transmission a node must wait from the randomized time t till I expires and then re-randomize the next t, and that leads to the question of what happens with all the (in)consistencies it hears till the next interval starts? Should they be counted as well (in step 2 it says to count all consistencies and in step 1 it says to set c to 0, i.e. disregard counts from t till I expires)? Some clarification would be helpful. >From -02: o I, the current interval size 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). I'm not sure how this can be more precise... would changing the text to 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). The interval ends at I. be helpful? > > One comment on operational considerations (section 6): > Do you see value in describing some typical =93events=94 that can be used= to reset the timer? What are the guidelines/limitations for doing these resets= , what could be considered good events and what could be considered bad events? > I'm really a bit wary of doing this -- almost any recommendations we could come up with would be wrong in some cases. E.g., the recommendations for multicast are very different than protocol acknowledgment timing. Perhaps the document can point to references of a few examples of its use, from which a reader might benefit? Phil --001636416ae13aa474048c847708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks Phil,

=A0

I think now I understand better some of the point= s. With these understandings, I=92d like to bring up some more the topics for further dis= cussion. I=92m OK with all your explanations excluding the ones that are in the below list.

=A0

----

> Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is potentially not used solely by wireless =96 though it was developed on a wireless platform I understand).

=85

Phil: "Correspondingly, I don't think LL= N is the right term either. How about "lossy broadcast-based networks," wi= th a few examples (e.g., wireless, PLC)?"

=A0

Yoav: I definitely support the examples.

I'm not familiar with the term "lossy br= oadcast-based networks", is this a commonly used term? To me, something like "l= ossy and partially connected networks" would make more sense. But if people understand what that means, I wouldn't object.

----

> Last paragraph of section 3 is a little uncl= ear to me.

=85

=A0

Phil: Would it make more sense if the text read "Trickle communication rate" rather than "communication rate?"

=A0

Yoav: It would make sense to explain some termino= logy. For example, communication rate, maybe also: (in)consistency, event, maybe = also =93lossy broadcast-based networks=94 that you spoke of earlier. Specificall= y, to me the term =93communication rate=94 was not self-explanatory and I would appreciate it if you described it somewhere.

=A0

Yoav: Something like: =94communication rate =96 the communication rate of a node is the sum of transmission and reception r= ates of this node.=94

Yoav: maybe also: =93Trickle communication rate = =96 the trickle communication rate equals the communication rate of trickle messages only.=94

=A0

With this understanding in mind, I still think th= at the sentence:

=A0=93=A0 A single, disconnected node must transmit at the communication rate.=94

=A0

Yoav: Is somewhat misleading, and mixes the outco= me with the given scenario.

=A0

Yoav: Would you consider a re-write in the form o= f:

Yoav: "In the case of a single, disconnected= node, the communication rate is equal to the transmission rate."

=A0

Yoav: Is this what you were trying to say?

----

>=A0

> =93=A0 In a lossless, single-hop network of size n, the sum of transmissions

>=A0=A0=A0 over the network is the communication rate, so for each node it is

>=A0=A0=A0 1/n.=94=A0=A0

=85

Yoav: How does one sum up transmissions? It is no= t a numeric value. One can count them, or sum their rates.

=A0

Yoav: I agree that the transmission rates will be= uniformly distributed when using the trickle and the same communication rates will be= the sum of the transmission rates.

=A0

Yoav: Trying to follow this logic, I would like t= o propose the following re-write here:

Yoav: " In a lossless, single-hop network of= size n, the sum of transmission rates of trickle messages (summed over all nodes) e= quals the trickle communication rate of each node separately. The trickle mechani= sm balances the load in such a scenario, such that for each node, the transmission rate= of trickle messages is 1/n times the trickle communication rate."

=A0

Yoav: Is the above correct? Does it clarify my po= int better?

----

> I have some questions/clarifications for sec= tion 4.2:

=85

Phil: I'm not sure how this can be more preci= se... would changing the text to

=A0

Phil:=A0=A0 1.=A0 When an interval begins, Trickle resets c to 0 and sets t to a

=A0=A0=A0=A0=A0=A0 random point in the interval, taken from the range [I/2, I). The

=A0=A0=A0=A0=A0=A0 interval ends at I.

=A0

Phil: be helpful?

=A0

Yoav: Yes! So is my understanding that between t = and I, there's no meaning to counting consistencies correct? Would it promote = this understanding (not so much implementation or correctness) if you change rule 2. to:

=A0

Yoav: " 2.=A0 Whenever Trickle hears a transmission that is "consistent," it

=A0=A0=A0=A0=A0=A0 increments counter c." to:

=A0

Yoav: " 2. Whenever Trickle hears a transmis= sion that is "consistent," until t expires, it

=A0=A0=A0=A0=A0=A0 increments counter c."

----

> One comment on operational considerations (s= ection 6):

=85

Phil: Perhaps the document can point to reference= s of a few examples of its use, from which a reader might benefit?

=A0

Yoav: that would be good enough for me.

----

=A0

Thanks for the productive response.

=A0

Best Regards,

Yoav

=A0

=A0

-----Original Message-----
From: Philip Levis [mailto:pal@cs.st= anford.edu]
Sent: Thursday, July 29, 2010 12:50 PM
To: Yoav Ben-Yehezkel
Cc: T.Clausen@computer.org; <= a href=3D"mailto:jhui@archrock.com">jhui@archrock.com; gnawali@cs.stanford.edu; jgko@cs.jhu.edu; roll@ietf.org
Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02

=A0

Yoav, my comments are inline.

On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wr= ote:

=A0

> Authors/ROLL WG,

>=A0

> Find below some minor comments/clarification= s I have on the Trickle draft.

>=A0

> Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is potentially not used solely by wireless =96 though it was developed on a wireless platform I understand).

>=A0

> It appears in the abstract, in the intro, at= the last para of section 3., at section 6.7.

> =93Abstract

>=A0

>=A0=A0=A0 The Trickle algorithm allows wireless nodes to exchange information

>=A0=A0=A0 in a highly robust,...=94

>=A0

>=A0

> =931.=A0 Introduction

>=A0

>=A0=A0=A0 The Trickle algorithm is designed for wireless networks.=94

>=A0

> =933. Trickle Algorithm Overview

>=A0=A0=A0 =85 Sparser networks require more transmissions per node, but

>=A0=A0=A0 utilization of the radio channel over space will not increase.=A0 This

>=A0=A0=A0 is an important property in wireless networks, where the channel is a

>=A0=A0=A0 valuable shared resource.=94

>=A0

> =936.7.=A0 Tweaks and improvements to Trickl= e

>=A0=A0=A0 =85 However, in dynamic network environments such as wireless,

>=A0=A0=A0 the coordination needed to compute the=85

=A0

This is a good point. What this text is trying to= get at is that Trickle is designed for, and well-suited to, lossy broadcast media. We've never really examined its use in low-loss switched networks (e.g.= , Ethernet). When the algorithm was designed, lossy broadcast media basically meant wireless, and not just low-power wireless. E.g., Trickle is well suit= ed to 802.11. We didn't really consider PLC -- in the context of ROLL, how= ever, it should definitely be considered.

=A0

Correspondingly, I don't think LLN is the rig= ht term either. How about "lossy broadcast-based networks," with a few examples (e.g., wireless, PLC)?

=A0

>=A0

>=A0

> Last paragraph of section 3 is a little uncl= ear to me.

> =93=A0 A single, disconnected node must transmit at the communication rate.=94

> Can you clarify this sentence? What do you m= ean by =93must transmit at the communication rate=94? The communication rate is the output of the number of transmissions a disconnected node makes, not= the other way around.

=A0

Ah -- I see. This sentence is referring to the pr= ior paragraph, which reads:

=A0

"As long as the network is connected and the= re is some minimum communication rate for each node, the network will reach event= ual consistency."

=A0

The point is that communication is either transmi= ssion or reception and that the edge case of a solitary node, its communication will= be all transmissions. In networks of multiple nodes, a node's communicatio= n can be some mix of receptions and transmissions.

=A0

Would it make more sense if the text read "T= rickle communication rate" rather than "communication rate?"

=A0

=A0

=A0

>=A0

> =93=A0 In a lossless, single-hop network of size n, the sum of transmissions

>=A0=A0=A0 over the network is the communication rate, so for each node it is

>=A0=A0=A0 1/n.=94

> I think =93the sum of transmissions=94 should be =93the sum of transmission rates=94, right? This property is true only if all nodes have the same arrival rates. Is this always the case= , or just the case when using trickle? You probably mean that this is a long ter= m average, not always, right?

=A0

I don't understand -- the same arrival rates?= It's a lossless, single-hop network: when a node transmits, every other node hears= the transmission. So the communication (reception+transmission) rates across th= e network are uniform.

=A0

=A0

>=A0

>=A0=A0=A0 Sparser networks require more transmissions per node, but

>=A0=A0=A0 utilization of the radio channel over space will not increase.=A0 This

>=A0=A0=A0 is an important property in wireless networks, where the channel is a

>=A0=A0=A0 valuable shared resource.=A0 Additionally, reducing transmissions in

>=A0=A0=A0 dense networks conserves system energy.=94

> I think the word Trickle is missing in the a= bove to emphasize the fact that what you describe is true for the trickle mechanism= , not in a network consisting of both trickle control data together with application data.

=A0

Which sentence do you think is unclear? Is it tha= t application data does not necessarily follow this property of scaling? I= 9;d like to think there is some context, and that it doesn't have to be that eve= ry sentence says Trickle in it.

=A0

=A0

>=A0

>=A0

> I have some questions/clarifications for sec= tion 4.2:

> Generally, what I think required is a more p= recise description of the term =93interval=94.

> When does an interval start? When did the pr= evious ended? After the previous I expires or when t is reached (and transmission = or suppression of transmission is decided on)? It is not so clear in the text.= If it is=A0 when I expires, then after the transmission a node must wait from the randomized time t till I expires and then re-randomize the next t, and = that leads to the question of what happens with all the (in)consistencies it hea= rs till the next interval starts? Should they be counted as well (in step 2 it says to count all consistencies and in step 1 it says to set c to 0, i.e. disregard counts from t till I expires)? Some clarification would be helpfu= l.

=A0

From -02:

=A0

=A0=A0 o I, the current interval size

=A0

=A0=A0 1.=A0 When an interval begins, Trickle resets c to 0 and sets t to a

=A0=A0=A0=A0=A0=A0 random point in the interval, taken from the range [I/2, I).

=A0

I'm not sure how this can be more precise... = would changing the text to

=A0

=A0=A0 1.=A0 When an interval begins, Trickle resets c to 0 and sets t to a

=A0=A0=A0=A0=A0=A0 random point in the interval, taken from the range [I/2, I). The

=A0=A0=A0=A0=A0=A0 interval ends at I.

=A0

be helpful?

=A0

>=A0

> One comment on operational considerations (s= ection 6):

> Do you see value in describing some typical =93events=94 that can be used to reset the timer? What are the guidelines/l= imitations for doing these resets, what could be considered good events and what could= be considered bad events?

>

=A0

I'm really a bit wary of doing this -- almost= any recommendations we could come up with would be wrong in some cases. E.g., t= he recommendations for multicast are very different than protocol acknowledgme= nt timing. Perhaps the document can point to references of a few examples of i= ts use, from which a reader might benefit?

=A0

Phil

=A0

=A0

--001636416ae13aa474048c847708-- From pal@cs.stanford.edu Thu Jul 29 05:37:22 2010 Return-Path: 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 CB1023A69F7 for ; Thu, 29 Jul 2010 05:37:22 -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 Jbf6ubhRJbRv for ; Thu, 29 Jul 2010 05:37:18 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7C74F28C206 for ; Thu, 29 Jul 2010 05:37:11 -0700 (PDT) Received: from dhcp-7556.meeting.ietf.org ([130.129.117.86]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OeSMN-0002y4-GQ; Thu, 29 Jul 2010 05:37:16 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: Date: Thu, 29 Jul 2010 14:37:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <823C0318-324C-41E6-9302-1EBC7AA44302@cs.stanford.edu> References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: d0ce9d9472212b49e09b1e688a60244d Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 12:37:23 -0000 On Jul 29, 2010, at 12:47 PM, Yoav Ben-Yehezkel wrote: > Thanks Phil, > =20 > I think now I understand better some of the points. With these = understandings, I=92d like to bring up some more the topics for further = discussion. I=92m OK with all your explanations excluding the ones that = are in the below list. > =20 > ---- > > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle = is potentially not used solely by wireless =96 though it was developed = on a wireless platform I understand). > =85 > Phil: "Correspondingly, I don't think LLN is the right term either. = How about "lossy broadcast-based networks," with a few examples (e.g., = wireless, PLC)?" > =20 > Yoav: I definitely support the examples. > I'm not familiar with the term "lossy broadcast-based networks", is = this a commonly used term? To me, something like "lossy and partially = connected networks" would make more sense. But if people understand what = that means, I wouldn't object. Hm. My intention wasn't that it be a term, with long-standing = implications; rather, it be a simple descriptive statement. The issue = isn't partial connection (one could infer that to be a graph that isn't = fully connected), rather packet loss. > ---- > > Last paragraph of section 3 is a little unclear to me. > =85 > =20 > Phil: Would it make more sense if the text read "Trickle communication = rate" rather than "communication rate?" > =20 > Yoav: It would make sense to explain some terminology. For example, = communication rate, maybe also: (in)consistency, event, maybe also = =93lossy broadcast-based networks=94 that you spoke of earlier. = Specifically, to me the term =93communication rate=94 was not = self-explanatory and I would appreciate it if you described it = somewhere. > =20 > Yoav: Something like: =94communication rate =96 the communication rate = of a node is the sum of transmission and reception rates of this node.=94 > Yoav: maybe also: =93Trickle communication rate =96 the trickle = communication rate equals the communication rate of trickle messages = only. Section 3 says something very close: "As long as every node communicates somehow - either receives or = transmits - the need for an update will be detected." > =94 > =20 > With this understanding in mind, I still think that the sentence: > =93 A single, disconnected node must transmit at the communication = rate.=94 > =20 > Yoav: Is somewhat misleading, and mixes the outcome with the given = scenario. > =20 > Yoav: Would you consider a re-write in the form of: > Yoav: "In the case of a single, disconnected node, the communication = rate is equal to the transmission rate." > =20 > Yoav: Is this what you were trying to say? Yes. I'd be happy to make that change. > ---- > >=20 > > =93 In a lossless, single-hop network of size n, the sum of = transmissions > > over the network is the communication rate, so for each node it = is > > 1/n.=94 =20 > =85 > Yoav: How does one sum up transmissions? It is not a numeric value. = One can count them, or sum their rates. Rate is a count over time. You sum the transmissions in an interval. > =20 > Yoav: I agree that the transmission rates will be uniformly = distributed when using the trickle and the same communication rates will = be the sum of the transmission rates. > =20 > Yoav: Trying to follow this logic, I would like to propose the = following re-write here: > Yoav: " In a lossless, single-hop network of size n, the sum of = transmission rates of trickle messages (summed over all nodes) equals = the trickle communication rate of each node separately. The trickle = mechanism balances the load in such a scenario, such that for each node, = the transmission rate of trickle messages is 1/n times the trickle = communication rate." > =20 > Yoav: Is the above correct? Does it clarify my point better? It's correct. I'd clean up the text a little: "In a lossless, single-hop network of size n, the communication rate at = each node equals the sum of the Trickle transmission rates across all = nodes. Trickle balances the load in such a scenario. Each node's Trickle = transmission rate is 1/nth of Trickle communication rate." Is that OK? > ---- > > I have some questions/clarifications for section 4.2: > =85 > Phil: I'm not sure how this can be more precise... would changing the = text to > =20 > Phil: 1. When an interval begins, Trickle resets c to 0 and sets t = to a > random point in the interval, taken from the range [I/2, I). = The > interval ends at I. > =20 > Phil: be helpful? > =20 > Yoav: Yes! So is my understanding that between t and I, there's no = meaning to counting consistencies correct? Would it promote this = understanding (not so much implementation or correctness) if you change = rule 2. to: > =20 > Yoav: " 2. Whenever Trickle hears a transmission that is = "consistent," it > increments counter c." to: > =20 > Yoav: " 2. Whenever Trickle hears a transmission that is "consistent," = until t expires, it > increments counter c." I personally think this overspecifies. It turns out that incrementing c = after t doesn't matter, but your text suggests you should add an if = statement to the implementation. This is added code which doesn't = accomplish anything -- exactly the kind of thing you want to avoid in = LLNs. :) > ---- > > One comment on operational considerations (section 6): > =85 > Phil: Perhaps the document can point to references of a few examples = of its use, from which a reader might benefit? > =20 > Yoav: that would be good enough for me. > ---- OK. > =20 > Thanks for the productive response. > =20 No problem. Thanks for the comments! Phil= From root@core3.amsl.com Thu Jul 29 07:00:02 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 203393A68B5; Thu, 29 Jul 2010 07:00: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: <20100729140002.203393A68B5@core3.amsl.com> Date: Thu, 29 Jul 2010 07:00:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-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: , X-List-Received-Date: Thu, 29 Jul 2010 14:00:02 -0000 --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 : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-03.txt Pages : 9 Date : 2010-07-29 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages to maximize connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-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-of0-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-29064939.I-D@ietf.org> --NextPart-- From yoav@yitran.com Thu Jul 29 07:29:22 2010 Return-Path: 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 3EA4328C168 for ; Thu, 29 Jul 2010 07:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Mxi-dVvycjee for ; Thu, 29 Jul 2010 07:29:17 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 25A9728C113 for ; Thu, 29 Jul 2010 07:29:16 -0700 (PDT) Received: from source ([209.85.215.172]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTFGQVJzamMSGCeEbLpKSQiHAI9o4jXUz@postini.com; Thu, 29 Jul 2010 07:29:41 PDT Received: by eyb7 with SMTP id 7so155347eyb.17 for ; Thu, 29 Jul 2010 07:29:39 -0700 (PDT) Received: by 10.227.156.212 with SMTP id y20mr177557wbw.142.1280413779022; Thu, 29 Jul 2010 07:29:39 -0700 (PDT) From: Yoav Ben-Yehezkel References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> <823C0318-324C-41E6-9302-1EBC7AA44302@cs.stanford.edu> In-Reply-To: <823C0318-324C-41E6-9302-1EBC7AA44302@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsvGskdZ0n1rjNhRdOuCTKLojbOxQADu9Lg Date: Thu, 29 Jul 2010 17:29:31 +0300 Message-ID: <65d491cd033ca86392983df2ec6c8911@mail.gmail.com> To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 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: , X-List-Received-Date: Thu, 29 Jul 2010 14:29:22 -0000 Phil, No more comments :) Thanks for accommodating most of my comments, I find the specifications clearer now. Regards, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Thursday, July 29, 2010 3:37 PM To: Yoav Ben-Yehezkel Cc: T.Clausen@computer.org; jhui@archrock.com; gnawali@cs.stanford.edu; jgko@cs.jhu.edu; roll@ietf.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 On Jul 29, 2010, at 12:47 PM, Yoav Ben-Yehezkel wrote: > Thanks Phil, > > I think now I understand better some of the points. With these understandings, I'd like to bring up some more the topics for further discussion. I'm OK with all your explanations excluding the ones that are in the below list. > > ---- > > Suggest to replace the term "wireless" with "LLN" (trickle is potentially not used solely by wireless - though it was developed on a wireless platform I understand). > . > Phil: "Correspondingly, I don't think LLN is the right term either. How about "lossy broadcast-based networks," with a few examples (e.g., wireless, PLC)?" > > Yoav: I definitely support the examples. > I'm not familiar with the term "lossy broadcast-based networks", is this a commonly used term? To me, something like "lossy and partially connected networks" would make more sense. But if people understand what that means, I wouldn't object. Hm. My intention wasn't that it be a term, with long-standing implications; rather, it be a simple descriptive statement. The issue isn't partial connection (one could infer that to be a graph that isn't fully connected), rather packet loss. > ---- > > Last paragraph of section 3 is a little unclear to me. > . > > Phil: Would it make more sense if the text read "Trickle communication rate" rather than "communication rate?" > > Yoav: It would make sense to explain some terminology. For example, communication rate, maybe also: (in)consistency, event, maybe also "lossy broadcast-based networks" that you spoke of earlier. Specifically, to me the term "communication rate" was not self-explanatory and I would appreciate it if you described it somewhere. > > Yoav: Something like: "communication rate - the communication rate of a node is the sum of transmission and reception rates of this node." > Yoav: maybe also: "Trickle communication rate - the trickle communication rate equals the communication rate of trickle messages only. Section 3 says something very close: "As long as every node communicates somehow - either receives or transmits - the need for an update will be detected." > " > > With this understanding in mind, I still think that the sentence: > " A single, disconnected node must transmit at the communication rate." > > Yoav: Is somewhat misleading, and mixes the outcome with the given scenario. > > Yoav: Would you consider a re-write in the form of: > Yoav: "In the case of a single, disconnected node, the communication rate is equal to the transmission rate." > > Yoav: Is this what you were trying to say? Yes. I'd be happy to make that change. > ---- > > > > " In a lossless, single-hop network of size n, the sum of transmissions > > over the network is the communication rate, so for each node it is > > 1/n." > . > Yoav: How does one sum up transmissions? It is not a numeric value. One can count them, or sum their rates. Rate is a count over time. You sum the transmissions in an interval. > > Yoav: I agree that the transmission rates will be uniformly distributed when using the trickle and the same communication rates will be the sum of the transmission rates. > > Yoav: Trying to follow this logic, I would like to propose the following re-write here: > Yoav: " In a lossless, single-hop network of size n, the sum of transmission rates of trickle messages (summed over all nodes) equals the trickle communication rate of each node separately. The trickle mechanism balances the load in such a scenario, such that for each node, the transmission rate of trickle messages is 1/n times the trickle communication rate." > > Yoav: Is the above correct? Does it clarify my point better? It's correct. I'd clean up the text a little: "In a lossless, single-hop network of size n, the communication rate at each node equals the sum of the Trickle transmission rates across all nodes. Trickle balances the load in such a scenario. Each node's Trickle transmission rate is 1/nth of Trickle communication rate." Is that OK? > ---- > > I have some questions/clarifications for section 4.2: > . > Phil: I'm not sure how this can be more precise... would changing the text to > > Phil: 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). The > interval ends at I. > > Phil: be helpful? > > Yoav: Yes! So is my understanding that between t and I, there's no meaning to counting consistencies correct? Would it promote this understanding (not so much implementation or correctness) if you change rule 2. to: > > Yoav: " 2. Whenever Trickle hears a transmission that is "consistent," it > increments counter c." to: > > Yoav: " 2. Whenever Trickle hears a transmission that is "consistent," until t expires, it > increments counter c." I personally think this overspecifies. It turns out that incrementing c after t doesn't matter, but your text suggests you should add an if statement to the implementation. This is added code which doesn't accomplish anything -- exactly the kind of thing you want to avoid in LLNs. :) > ---- > > One comment on operational considerations (section 6): > . > Phil: Perhaps the document can point to references of a few examples of its use, from which a reader might benefit? > > Yoav: that would be good enough for me. > ---- OK. > > Thanks for the productive response. > No problem. Thanks for the comments! Phil From alexandru.petrescu@gmail.com Thu Jul 29 08:14:48 2010 Return-Path: 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 233FD28C12B for ; Thu, 29 Jul 2010 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, 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 cimLQN74MsZP for ; Thu, 29 Jul 2010 08:14:43 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B446628C0FA for ; Thu, 29 Jul 2010 08:14:42 -0700 (PDT) Received: by bwz7 with SMTP id 7so303556bwz.31 for ; Thu, 29 Jul 2010 08:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=CGZcNe5rrjMZhxzOO7VjLiw4hUvQSdkKMSpJ2Vcmr94=; b=Uh6bFm6yJ/lo9VREpt8iHYm/fITmAiB5Pv06hKK57DHS8b8mKlGC/goqtbnUFyT8cY YBXrRAgWQlw3luc7Onp9Enp+IGgUL1gst1crPnO8g113Pk4CHDi53V0bRT88iE2aY+Qd xrfxb3xjlaLZTwSintNFZkLALTM/Ih1BAt2HQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=aimTrLRbefKCxJDN6jjMSi7OoD3k3yQevbrniwfwXmFXs7iuikw+hunmT+6fO1Hh/G UosiwLzCQyjtmvQgNi5q6R2iAAMYeyTFwJqJiWbxCwY1ZbtMLfdRhdoSUiYMhsy5Yt2u vAQpDIVGBZeWWx05pyPTYNcNFTFAD8Nq+J2b4= MIME-Version: 1.0 Received: by 10.204.6.68 with SMTP id 4mr189444bky.28.1280416505787; Thu, 29 Jul 2010 08:15:05 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Thu, 29 Jul 2010 08:15:05 -0700 (PDT) Date: Thu, 29 Jul 2010 17:15:05 +0200 Message-ID: From: Alexandru Petrescu To: rstruik@certicom.com Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: [Roll] Checksum field and MAC in RPL document 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: , X-List-Received-Date: Thu, 29 Jul 2010 15:14:48 -0000 Hello Rene, Following our desk discussion about RPL and security and signature and checksum - I believe we should specify in RPL doc that the Checksum field is set to 0 prior to computing the signature. I mean the Checksum field in this figure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is but one remark. I don't want it drawn in a series of other remarks... risking to be discarded because of the others, or solved with the others... Thanks for the nice chat, Alex From root@core3.amsl.com Thu Jul 29 09:45:04 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40FF628C17E; Thu, 29 Jul 2010 09:45:02 -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: <20100729164503.40FF628C17E@core3.amsl.com> Date: Thu, 29 Jul 2010 09:45:03 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-11.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: , X-List-Received-Date: Thu, 29 Jul 2010 16:45:04 -0000 --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 : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-11.txt Pages : 139 Date : 2010-07-29 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint- to-point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to- point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-11.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-rpl-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-29093656.I-D@ietf.org> --NextPart-- From trac@tools.ietf.org Thu Jul 29 12:32:09 2010 Return-Path: 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 425BC28C0E3 for ; Thu, 29 Jul 2010 12:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 W7s55wE4H6XG for ; Thu, 29 Jul 2010 12:32:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 767B33A68EA for ; Thu, 29 Jul 2010 12:32:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OeYqE-0005oB-6Y; Thu, 29 Jul 2010 12:32:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 29 Jul 2010 19:32:30 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/70#comment:2 Message-ID: <064.b79d23f8e92b4da023bc2756a6dd60f0@tools.ietf.org> References: <055.d823261b419b55d9dd0dde82abf7f82f@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <055.d823261b419b55d9dd0dde82abf7f82f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #70: List of detailed comments during RPL LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 19:32:09 -0000 #70: List of detailed comments during RPL LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: task | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Considering the number of comments, it is hard to provide all Diffs (one by one) and add them to the ticket #70. But all comments have been addressed in the rev-11. Thus ticket #70 can be closed. Thanks. JP. -- Ticket URL: roll From jpv@cisco.com Thu Jul 29 13:26:26 2010 Return-Path: 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 93E813A67E3 for ; Thu, 29 Jul 2010 13:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GbLC0jJassFK for ; Thu, 29 Jul 2010 13:26:25 -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 A75733A6359 for ; Thu, 29 Jul 2010 13:26:25 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD6BUUytJV2Z/2dsb2JhbACgE3GmEJsDhTgEiHmCPgwB X-IronPort-AV: E=Sophos;i="4.55,283,1278288000"; d="scan'208";a="140996661" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2010 20:26:49 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o6TKQnTn023418 for ; Thu, 29 Jul 2010 20:26:49 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jul 2010 15:26:49 -0500 Received: from [192.168.48.94] ([10.82.235.92]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 15:26:48 -0500 Message-Id: <7BEA52FB-7A50-4019-B182-1341B9EC4D3E@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 22:24:34 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Jul 2010 20:26:48.0840 (UTC) FILETIME=[5F0D6080:01CB2F5C] Subject: [Roll] Draft ROLL WG minutes 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: , X-List-Received-Date: Thu, 29 Jul 2010 20:26:26 -0000 Dear Working Group, Draft minutes have been posted: http://www.ietf.org/proceedings/78/minutes/roll.txt Thanks. JP. From jpv@cisco.com Thu Jul 29 13:26:45 2010 Return-Path: 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 C3C3E3A68A0 for ; Thu, 29 Jul 2010 13:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ildgFg9n2fdY for ; Thu, 29 Jul 2010 13:26:44 -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 AF1D33A6359 for ; Thu, 29 Jul 2010 13:26:44 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGqBUUytJV2a/2dsb2JhbACgE3GmCpsDhTgEiHmCPgwB X-IronPort-AV: E=Sophos;i="4.55,283,1278288000"; d="scan'208";a="140950424" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 29 Jul 2010 20:26:55 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o6TKQtSJ001925 for ; Thu, 29 Jul 2010 20:26:55 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 15:26:54 -0500 Received: from [192.168.48.94] ([10.82.235.92]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 15:26:53 -0500 Message-Id: <8801BED4-CED2-479E-9464-53C6A37E8825@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 22:26:47 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Jul 2010 20:26:54.0746 (UTC) FILETIME=[62928FA0:01CB2F5C] Subject: [Roll] Draft ROLL WG minutes 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: , X-List-Received-Date: Thu, 29 Jul 2010 20:26:45 -0000 Dear Working Group, Draft minutes have been posted: http://www.ietf.org/proceedings/78/minutes/roll.txt Thanks. JP. From alexandru.petrescu@gmail.com Thu Jul 29 15:18:50 2010 Return-Path: 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 E5DE63A67C3 for ; Thu, 29 Jul 2010 15:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 wmQHqKwKQLPV for ; Thu, 29 Jul 2010 15:18:50 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CD5633A67F4 for ; Thu, 29 Jul 2010 15:18:49 -0700 (PDT) Received: by bwz7 with SMTP id 7so568519bwz.31 for ; Thu, 29 Jul 2010 15:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=99G7SG4imFD76TgJJs6h2mOyw0027zP68w2y67hJVMc=; b=STUuDe7yh/SsFPPHrQtE4a2QSwQQpTc18MERqCNpb8CSILOLohzmssUs/N/FK9AsOf 0jh+52cmLtmWyVT5W76olmIFtErXzwoH/ExwSoD+JQAGxpoXcKQjxx1Xx8GoMn3JOE0l EmP6/0Sfd1kyjrYxEuswT4vK0osmBo7340beA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=coJ7AvjjMzM3zOyMD/VOQ5XmZlr4Phy5hI+7AJDVALi2p3CAVpYnTCMTnIORTvTQmU MOGVo568aUHruRZksnPTSW4B6dtJ0tqqsuwwXlAZNZmdbnRT3nNi6srECgafl0mj50Qu 35DC0MY+5t76kFiyRtm09qZ7VumL0l/2fJjMg= MIME-Version: 1.0 Received: by 10.204.6.68 with SMTP id 4mr556397bky.28.1280441953316; Thu, 29 Jul 2010 15:19:13 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Thu, 29 Jul 2010 15:19:13 -0700 (PDT) Date: Fri, 30 Jul 2010 00:19:13 +0200 Message-ID: From: Alexandru Petrescu To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] About the second session of today 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: , X-List-Received-Date: Thu, 29 Jul 2010 22:18:51 -0000 Just a note to say that I was feeling a little bit bad to sit there in Auditorium II and wait for the second session to start, and nothing started. Worse - I was not the only one waiting... Was this 2nd session cancellation announced somehow somewhere? (I checked agenda and jabber log, I can' seem to find an announcement, or I may have missed them..) Alex From jpv@cisco.com Thu Jul 29 16:08:40 2010 Return-Path: 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 5873B3A6965 for ; Thu, 29 Jul 2010 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gQWhFV3Gkr1G for ; Thu, 29 Jul 2010 16:08:39 -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 30FFA3A6955 for ; Thu, 29 Jul 2010 16:08:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOqmUUytJV2c/2dsb2JhbACgGXGmIpp+hTgEiHmCPgwB X-IronPort-AV: E=Sophos;i="4.55,283,1278288000"; d="scan'208";a="141002807" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 29 Jul 2010 23:09:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6TN92lt018744; Thu, 29 Jul 2010 23:09:02 GMT Received: from xfe-rcd-301.cisco.com ([72.163.63.12]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 18:09:02 -0500 Received: from [192.168.48.94] ([10.82.235.92]) by xfe-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 18:09:02 -0500 Message-Id: <2B6542F8-463E-48DF-8BB2-4BF2A1F3DDC3@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 01:08:36 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Jul 2010 23:09:02.0197 (UTC) FILETIME=[0895CA50:01CB2F73] Cc: roll@ietf.org Subject: Re: [Roll] About the second session of today 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: , X-List-Received-Date: Thu, 29 Jul 2010 23:08:40 -0000 sincere apologies if it was not clear that the ROLL meeting was over after the first 2h slot. I went through the full agenda (presented when we opened the meeting, item by item and then concluded by "meeting closed see you in Beijin". See you, and have all a safe trip back. JP and David. On Jul 30, 2010, at 12:19 AM, Alexandru Petrescu wrote: > Just a note to say that I was feeling a little bit bad to sit there in > Auditorium II and wait for the second session to start, and nothing > started. > > Worse - I was not the only one waiting... > > Was this 2nd session cancellation announced somehow somewhere? > > (I checked agenda and jabber log, I can' seem to find an announcement, > or I may have missed them..) > > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Jul 29 23:19:01 2010 Return-Path: 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 97DBF3A6A73 for ; Thu, 29 Jul 2010 23:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 RCsBS+eFF7AD for ; Thu, 29 Jul 2010 23:18:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AB8F43A6A77 for ; Thu, 29 Jul 2010 23:18:58 -0700 (PDT) Received: by bwz7 with SMTP id 7so696287bwz.31 for ; Thu, 29 Jul 2010 23:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Ifv4IAXTn9Ix/h++P2bvyzgIqH6luQyL4+z1SEenmzw=; b=T7IyEEYsiBODsh2PB8UMI9Xb7NTRPOpfTc8CmEJey9shxgYMYxJI+xgun3Rj3HDQmg 72dtZ/4Z1mtVVE3mPSS0VXugO4pDFvfflkAN5DMm7ySItCza5JFIF6Sl+XJP8CHU4lEb cY8MkfiHhjSFbv8RgD/X/MVPNHDAYbS+MwyeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uIlPUylkjzgQ4wqhxU+be5PGOj4RXonUNSm9fiPZeLb0MV3FjpOJZ1mHSih0EgeN+h 9NVKNDHm0SWE3daWC0EeAQ42mTE9dzkTBOJaznjUffHUgujkPSh3T15r5YhgrpXNpUEb s/oVXuMZK+QPGELHqt540WhAc0ktKx9paqhHg= MIME-Version: 1.0 Received: by 10.204.59.2 with SMTP id j2mr763155bkh.199.1280470761798; Thu, 29 Jul 2010 23:19:21 -0700 (PDT) Received: by 10.204.47.228 with HTTP; Thu, 29 Jul 2010 23:19:21 -0700 (PDT) Date: Fri, 30 Jul 2010 08:19:21 +0200 Message-ID: From: Alexandru Petrescu To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutes 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: , X-List-Received-Date: Fri, 30 Jul 2010 06:19:01 -0000 > 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) > [160] Quick update on the changes in -02. Currently in LC. > > JP> ID is a normative reference in RPL core spec (thus we have a > downref). Discussion on ID status JP> Will come back to the list to > consider status change (informational to standard track) Just a quick note to consider more ways to solve this problem (RPL spec 'downref'erencing a draft it fully relies on): -move draft-ietf-roll-trickle in the Informative References section. This implies making Trickle parameters less mandatory in RPL. -change the track of the base spec to Informational (this implies change to communication to SDO requiring this RP, I suppose). Also worth mentioning the use of BCP tag on the Trickle draft... Trickle being common practice in widespread use yet not really a protocol (timer management). These may have already been considered, Alex From pthubert@cisco.com Fri Jul 30 05:09:28 2010 Return-Path: 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 CC1AE3A6807 for ; Fri, 30 Jul 2010 05:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YNVK39fvatxl for ; Fri, 30 Jul 2010 05:09:27 -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 4ABCD3A67AE for ; Fri, 30 Jul 2010 05:09:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALtdUkxAZnwN/2dsb2JhbACgF3GkLpsIhTkEizg X-IronPort-AV: E=Sophos;i="4.55,287,1278288000"; d="scan'208";a="141220302" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2010 12:09:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6UC9jxN006233; Fri, 30 Jul 2010 12:09:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 14:09:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 14:09:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutesposted) thread-index: AcsvryzXzXFn8ymiTzKyoTyjFZdyXwAMIqUQ References: From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 30 Jul 2010 12:09:46.0858 (UTC) FILETIME=[1A2DCCA0:01CB2FE0] Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutesposted) 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: , X-List-Received-Date: Fri, 30 Jul 2010 12:09:28 -0000 Alex: We need to be very clear that the WG is chartered for Standard Track, not Informational. So RPL is and will stay on that track. Moving Trickle to standard track is a good move, highly deserved for a method that's well understood and proven, and I support it 100%. Safe trip back, Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Alexandru Petrescu > Sent: Friday, July 30, 2010 8:19 AM > To: roll@ietf.org > Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG > minutesposted) >=20 > > 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) > > [160] Quick update on the changes in -02. Currently in LC. > > > > JP> ID is a normative reference in RPL core spec (thus we have a > > downref). Discussion on ID status JP> Will come back to the list to > > consider status change (informational to standard track) >=20 > Just a quick note to consider more ways to solve this problem (RPL spec > 'downref'erencing a draft it fully relies on): >=20 > -move draft-ietf-roll-trickle in the Informative References section. > This implies making Trickle parameters less mandatory in RPL. > -change the track of the base spec to Informational (this implies change to > communication to SDO requiring this RP, I suppose). >=20 > Also worth mentioning the use of BCP tag on the Trickle draft... Trickle being > common practice in widespread use yet not really a protocol (timer > management). >=20 > These may have already been considered, >=20 > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Fri Jul 30 05:54:25 2010 Return-Path: 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 A59EF3A69B2 for ; Fri, 30 Jul 2010 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=0.644, 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 LAKAbxoqEebe for ; Fri, 30 Jul 2010 05:54:24 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 4705C3A69AA for ; Fri, 30 Jul 2010 05:54:24 -0700 (PDT) Received: by bwz7 with SMTP id 7so882748bwz.31 for ; Fri, 30 Jul 2010 05:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.83.167 with SMTP id f39mr1130901bkl.151.1280494488266; Fri, 30 Jul 2010 05:54:48 -0700 (PDT) Received: by 10.204.163.5 with HTTP; Fri, 30 Jul 2010 05:54:48 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> Date: Fri, 30 Jul 2010 14:54:48 +0200 Message-ID: From: Ulrich Herberg To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutesposted) 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: , X-List-Received-Date: Fri, 30 Jul 2010 12:54:25 -0000 Hi, On Fri, Jul 30, 2010 at 2:09 PM, Pascal Thubert (pthubert) wrote: > Alex: > > We need to be very clear that the WG is chartered for Standard Track, > not Informational. So RPL is and will stay on that track. > Moving Trickle to standard track is a good move, highly deserved for a > method that's well understood and proven, and I support it 100%. I fully agree with Pascal. Ulrich > > Safe trip back, > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Alexandru Petrescu >> Sent: Friday, July 30, 2010 8:19 AM >> To: roll@ietf.org >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >> minutesposted) >> >> > 5) The Trickle Algorithm - draft-levis-roll-trickle-02 =A0(Phil - 5mn) >> > [160] Quick update on the changes in -02. Currently in LC. >> > >> > JP> ID is a normative reference in RPL core spec (thus we have a >> > downref). Discussion on ID status JP> Will come back to the list to >> > consider status change (informational to standard track) >> >> Just a quick note to consider more ways to solve this problem (RPL > spec >> 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References section. >> =A0This implies making Trickle parameters less mandatory in RPL. >> -change the track of the base spec to Informational (this implies > change to >> communication to SDO requiring this RP, I suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... > Trickle being >> common practice in widespread use yet not really a protocol (timer >> management). >> >> These may have already been considered, >> >> Alex >> _______________________________________________ >> 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 jpv@cisco.com Fri Jul 30 13:54:07 2010 Return-Path: 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 28C1B3A688E for ; Fri, 30 Jul 2010 13:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HFn+Ct-CF9WH for ; Fri, 30 Jul 2010 13:54:06 -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 1B3173A6805 for ; Fri, 30 Jul 2010 13:54:06 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMfYUkxAZnwN/2dsb2JhbACgJnGmcZsLhTkEiHuCPQ X-IronPort-AV: E=Sophos;i="4.55,288,1278288000"; d="scan'208";a="141436878" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2010 20:54:30 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6UKsUoZ006285; Fri, 30 Jul 2010 20:54:30 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 22:54:30 +0200 Received: from [192.168.1.10] ([10.55.87.248]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 22:54:30 +0200 Message-Id: <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> From: JP Vasseur To: ROLL WG In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 22:54:30 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 30 Jul 2010 20:54:30.0060 (UTC) FILETIME=[67A12EC0:01CB3029] Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutesposted) 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: , X-List-Received-Date: Fri, 30 Jul 2010 20:54:07 -0000 On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: > Alex: > > We need to be very clear that the WG is chartered for Standard Track, > not Informational. So RPL is and will stay on that track. That's correct. > Moving Trickle to standard track is a good move, highly deserved for a > method that's well understood and proven, and I support it 100%. > As a WG LC, I do favor to have the trickle ID move to Std track too. JP. > Safe trip back, > > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of >> Alexandru Petrescu >> Sent: Friday, July 30, 2010 8:19 AM >> To: roll@ietf.org >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >> minutesposted) >> >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) >>> [160] Quick update on the changes in -02. Currently in LC. >>> >>> JP> ID is a normative reference in RPL core spec (thus we have a >>> downref). Discussion on ID status JP> Will come back to the list to >>> consider status change (informational to standard track) >> >> Just a quick note to consider more ways to solve this problem (RPL > spec >> 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References section. >> This implies making Trickle parameters less mandatory in RPL. >> -change the track of the base spec to Informational (this implies > change to >> communication to SDO requiring this RP, I suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... > Trickle being >> common practice in widespread use yet not really a protocol (timer >> management). >> >> These may have already been considered, >> >> Alex >> _______________________________________________ >> 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 Matteo.Paris@ember.com Fri Jul 30 18:53:21 2010 Return-Path: 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 AD3CB3A682A for ; Fri, 30 Jul 2010 18:53:21 -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 gsSvdEanteNg for ; Fri, 30 Jul 2010 18:53:20 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BC4693A67CC for ; Fri, 30 Jul 2010 18:53:20 -0700 (PDT) Received: from [192.168.81.33] ([192.168.90.71]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 21:53:45 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 30 Jul 2010 21:53:43 -0400 To: roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 31 Jul 2010 01:53:45.0432 (UTC) FILETIME=[35DD8580:01CB3053] Subject: [Roll] Non-storing mode comments 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: , X-List-Received-Date: Sat, 31 Jul 2010 01:53:21 -0000 Hi, There are a few places in the draft where I believe the text is applicable only for storing mode of operation, and does not make sense for non-storing mode. 1. Section 5: "A RPL Control Message has the scope of a link. The source address is a link local address." I don't think this is true for non-storing DAOs and DAO-ACKs, which are sent multiple hops and hence cannot have a link local source address. 2. Section 5.4.1: "The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used." The MUST makes sense for storing mode, where DAOs are sent to parents. But in non-storing mode it is not necessary, because the the IP destination of the DAO is the DODAG root, which can be the DODAGID since the DODAGID is required to be a routable IPv6 address for local instance ids. We should not require that the DODAGID also appear in the DAO in non-storing mode, since in many cases this will be redundant. 3. Section 11.2.2.4, Foward Path Recovery, makes sense for storing mode, where intermediate routers contain downward state. However it does not make sense for non-storing mode, where intermediate routers do not have downward state, and cannot make an alternate forwarding decision besides what is indicated in the source routing header of the packet. I think the text should point this out for clarity. Thanks, Matteo From culler@cs.berkeley.edu Fri Jul 30 21:13:52 2010 Return-Path: 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 354393A68C1 for ; Fri, 30 Jul 2010 21:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 NBAIlwiC91t3 for ; Fri, 30 Jul 2010 21:13:49 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C36DA3A68C0 for ; Fri, 30 Jul 2010 21:13:49 -0700 (PDT) Received: from [192.168.2.106] (64-142-4-199.dsl.static.sonic.net [64.142.4.199]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o6V4Dx4F001622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Jul 2010 21:14:13 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: Date: Fri, 30 Jul 2010 16:03:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutes 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: , X-List-Received-Date: Sat, 31 Jul 2010 04:13:52 -0000 Yes, this change to the references was considered and even discussed at = the WG meeting. =20 That part that was not discussed was anything about "less mandatory". = Mandatory is a binary property. Something either IS or IS NOT. Perhaps = you mean "optional".=20 There are two fundamental aspects of RPL that make it particularly = suited for LLNs. One is maintaining a small amount of diversity in = routing so that transient variations in links (the lossy part) can be = accommodated within the normal mode of operation. The second is = eliminating broadcast storms and ack implosion, which are particularly = problematic with low bandwidth links (the low power part). These two = techniques have been very widely used in protocols that have been shown = to work in practice and at scale. So at this stage, it is not = particularly attractive to start throwing out fundamental aspects of the = protocol design because is provides an alternative means of cleaning up = the reference section. =20 You raised this issue over and over at the microphone in the WG meeting = without stating what goal you were trying to achieve by the suggestion. = Are you saying that it is a problem for some reason to propose that the = trickle draft be upgraded? If so, please state what you think that = problem is. If the concern is that some people are not familiar with trickle, well = that is the reason for doing the I-D. While it is well covered in the = open literature (the CACM highlight article that Phil Levis cited is an = excellent reference) the aspects that you want captured in a I-D are = rather more specific. It is not a matter of the broader algorithmic = analyses, it is the specifics of the realization and the trade-offs = associated with different specific choices. =20 Perhaps you could explain what you see is to be gained by your = suggestion? On Jul 29, 2010, at 11:19 PM, Alexandru Petrescu wrote: >> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) >> [160] Quick update on the changes in -02. Currently in LC. >>=20 >> JP> ID is a normative reference in RPL core spec (thus we have a >> downref). Discussion on ID status JP> Will come back to the list to >> consider status change (informational to standard track) >=20 > Just a quick note to consider more ways to solve this problem (RPL = spec > 'downref'erencing a draft it fully relies on): >=20 > -move draft-ietf-roll-trickle in the Informative References section. > This implies making Trickle parameters less mandatory in RPL. > -change the track of the base spec to Informational (this implies > change to communication to SDO requiring this RP, I suppose). >=20 > Also worth mentioning the use of BCP tag on the Trickle draft... = Trickle > being common practice in widespread use yet not really a protocol = (timer > management). >=20 > These may have already been considered, >=20 > Alex > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sat Jul 31 01:50:23 2010 Return-Path: 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 8CB2F3A69B3 for ; Sat, 31 Jul 2010 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wPkAomdicpnC for ; Sat, 31 Jul 2010 01:50:22 -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 A572A3A6876 for ; Sat, 31 Jul 2010 01:50:22 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGuAU0yrRN+K/2dsb2JhbACgJnGjfJp+hTkEiz0 X-IronPort-AV: E=Sophos;i="4.55,291,1278288000"; d="scan'208";a="566562854" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2010 08:50:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6V8olht017076; Sat, 31 Jul 2010 08:50:47 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Jul 2010 10:50:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 31 Jul 2010 10:50:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02727B6E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Non-storing mode comments thread-index: AcswU2S7XEqHIxsjQoedqlZukygbfAANqX4Q References: From: "Pascal Thubert (pthubert)" To: "Matteo Paris" , X-OriginalArrivalTime: 31 Jul 2010 08:50:47.0398 (UTC) FILETIME=[781E8860:01CB308D] Subject: Re: [Roll] Non-storing mode comments 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: , X-List-Received-Date: Sat, 31 Jul 2010 08:50:23 -0000 Hi Matteo: =20 > 1. Section 5: "A RPL Control Message has the scope of a link. The source > address is a link local address." I don't think this is true for non-storing DAOs > and DAO-ACKs, which are sent multiple hops and hence cannot have a link local > source address. [Pascal] You are right. 6.4 is very clear that now, non-storing DAO fly straight to the root along Richard's proposal. So we need to add that the DAO/ack flow in non-storing is an exception to the general rule in section 5. >=20 > 2. Section 5.4.1: "The 'D' flag indicates that the DODAGID field is present. This > flag MUST be set when a local RPLInstanceID is used." > The MUST makes sense for storing mode, where DAOs are sent to parents. But > in non-storing mode it is not necessary, because the the IP destination of the > DAO is the DODAG root, which can be the DODAGID since the DODAGID is > required to be a routable IPv6 address for local instance ids. We should not > require that the DODAGID also appear in the DAO in non-storing mode, since in > many cases this will be redundant. [Pascal] I see what you're saying, but that's also somewhat of a violation and may have consequences if the method is extended. I'd rather have a compression algorithm that compresses the option together with a lot of other stuff, like the prefix of the parent in the transit option. Now that the spec has stabilized, it would be good that someone starts this work. >=20 > 3. Section 11.2.2.4, Foward Path Recovery, makes sense for storing mode, > where intermediate routers contain downward state. However it does not > make sense for non-storing mode, where intermediate routers do not have > downward state, and cannot make an alternate forwarding decision besides > what is indicated in the source routing header of the packet. I think the text > should point this out for clarity. [Pascal] In non-storing, the 'F' bit is never set. The mechanism is to fire an ICMP error back to the source. So clearly, that section does not apply; but I agree it does not hurt to remind it, as you say, for clarity. Pascal From jpv@cisco.com Sat Jul 31 03:04:28 2010 Return-Path: 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 DAE613A6859 for ; Sat, 31 Jul 2010 03:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 E2yEobr6vTj0 for ; Sat, 31 Jul 2010 03:04:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E12163A67F5 for ; Sat, 31 Jul 2010 03:04:27 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKSU0yrRN+J/2dsb2JhbACgJXGjX5p9hTkEiH+CPg X-IronPort-AV: E=Sophos;i="4.55,293,1278288000"; d="scan'208";a="348096485" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2010 10:04:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6VA4o98004751; Sat, 31 Jul 2010 10:04:52 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Jul 2010 12:04:50 +0200 Received: from [192.168.1.10] ([10.61.87.163]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Jul 2010 12:04:50 +0200 Message-Id: From: JP Vasseur To: Matteo Paris , "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02727B6E@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 31 Jul 2010 12:04:49 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D02727B6E@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 Jul 2010 10:04:50.0121 (UTC) FILETIME=[D0304390:01CB3097] Cc: ROLL WG Subject: Re: [Roll] Non-storing mode comments 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: , X-List-Received-Date: Sat, 31 Jul 2010 10:04:29 -0000 Just a quick reminder, since we passed WG LC. We'll make sure that these two clarifications get added at some point. Thanks. JP On Jul 31, 2010, at 10:50 AM, Pascal Thubert (pthubert) wrote: > Hi Matteo: > > >> 1. Section 5: "A RPL Control Message has the scope of a link. The > source >> address is a link local address." I don't think this is true for > non-storing DAOs >> and DAO-ACKs, which are sent multiple hops and hence cannot have a > link local >> source address. > > [Pascal] You are right. 6.4 is very clear that now, non-storing DAO > fly > straight to the root along Richard's proposal. > So we need to add that the DAO/ack flow in non-storing is an exception > to the general rule in section 5. > >> >> 2. Section 5.4.1: "The 'D' flag indicates that the DODAGID field is > present. This >> flag MUST be set when a local RPLInstanceID is used." >> The MUST makes sense for storing mode, where DAOs are sent to >> parents. > But >> in non-storing mode it is not necessary, because the the IP > destination of the >> DAO is the DODAG root, which can be the DODAGID since the DODAGID is >> required to be a routable IPv6 address for local instance ids. We > should not >> require that the DODAGID also appear in the DAO in non-storing mode, > since in >> many cases this will be redundant. > [Pascal] I see what you're saying, but that's also somewhat of a > violation and may have consequences if the method is extended. > I'd rather have a compression algorithm that compresses the option > together with a lot of other stuff, like the prefix of the parent in > the > transit option. > Now that the spec has stabilized, it would be good that someone starts > this work. > >> >> 3. Section 11.2.2.4, Foward Path Recovery, makes sense for storing > mode, >> where intermediate routers contain downward state. However it does > not >> make sense for non-storing mode, where intermediate routers do not > have >> downward state, and cannot make an alternate forwarding decision > besides >> what is indicated in the source routing header of the packet. I >> think > the text >> should point this out for clarity. > > > [Pascal] In non-storing, the 'F' bit is never set. The mechanism is to > fire an ICMP error back to the source. > So clearly, that section does not apply; but I agree it does not > hurt to > remind it, as you say, for clarity. > > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sat Jul 31 08:04:03 2010 Return-Path: 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 1CB793A698E for ; Sat, 31 Jul 2010 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.685, 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 QSXTaGqLcm9G for ; Sat, 31 Jul 2010 08:04:02 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D0DBB3A68E0 for ; Sat, 31 Jul 2010 08:04:00 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 40201940067; Sat, 31 Jul 2010 17:04:19 +0200 (CEST) Message-ID: <4C543B71.60007@gmail.com> Date: Sat, 31 Jul 2010 17:04:17 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: David Culler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100731-0, 31/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D 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: , X-List-Received-Date: Sat, 31 Jul 2010 15:04:03 -0000 Le 31/07/2010 01:03, David Culler a écrit : > Yes, this change to the references was considered and even discussed > at the WG meeting. > > That part that was not discussed was anything about "less mandatory". > Mandatory is a binary property. Something either IS or IS NOT. > Perhaps you mean "optional". I agree, I mean optional. > There are two fundamental aspects of RPL that make it particularly > suited for LLNs. One is maintaining a small amount of diversity in > routing so that transient variations in links (the lossy part) can be > accommodated within the normal mode of operation. The second is > eliminating broadcast storms and ack implosion, which are > particularly problematic with low bandwidth links (the low power > part). These two techniques have been very widely used in protocols > that have been shown to work in practice and at scale. So at this > stage, it is not particularly attractive to start throwing out > fundamental aspects of the protocol design because is provides an > alternative means of cleaning up the reference section. Well I mainly agree with the intent to keep these features. But often broadcast storms are avoided by the link-layer, not IP. The multicast concepts of e.g. Ethernet, of 802.15.4, and the exclusive use of multicast by IPv6 (no broadcast) are there precisely to avoid the broadcast problems. Ack implosion - I confess I do not know the problem. I think DAO ack messages are optional, probably less of a problem. But I do not the ack problem that you mention. > You raised this issue over and over at the microphone in the WG > meeting without stating what goal you were trying to achieve by the > suggestion. The goal is to identify whether Trickle is mandatory for implementation, or not. What would mean INFORMATIONAL, Std Track, BCP - with respect to Trickle being mandatory to implement RPL, or not. > Are you saying that it is a problem for some reason to propose that > the trickle draft be upgraded? If so, please state what you think > that problem is. I don't really see this as a blocking problem, let me explain. Is Trickle a protocol (in the sense of message diagrams, message formats)? If not, it sounds as practice to me, which may indeed good practice. Could thus be Best Current Practice. BCP1 which is RFC1818 describes "BCP" in a sense; BCPs are listed at: http://www.rfc-editor.org/bcp-index.html BCP71 "TCP over 2G" is such a BCP making me thing Trickle could be a similar BCP. In another context: ND, MLD and TCP RFCs there are state machines specified in the protocol documents; but that text is explicitly saying one is free to implement otherwise than these state machines. > If the concern is that some people are not familiar with trickle, > well that is the reason for doing the I-D. I personally am familiar to Trickle to mean "Trickle Charger" or the "Trickle Power Management" of SIRF chipsets. Wikipedia entries and publications exist. These Trickle concepts are very different than the Trickle I-D. E.g. it is hard to say "ZigBee devices use trickle for power management and Trickle for RPL communication protocol". > While it is well covered in the open literature (the CACM highlight > article that Phil Levis cited is an excellent reference) the aspects > that you want captured in a I-D are rather more specific. I think "Trickle" appears in the literature also to mean the power management thing, and is in widespread deployment too. Alex > It is not a matter of the broader algorithmic analyses, it is the > specifics of the realization and the trade-offs associated with > different specific choices. > > Perhaps you could explain what you see is to be gained by your > suggestion? I think putting Trickle as INFORMATIONAL would read more like one is free to set the RPL's Trickle parameters otherwise than with the Trickle I-D. I think putting it on BCP would also leave this freedom. I have read BCP 1 (RFC1818) about what "BCP" may mean. My suggestion is to make clear whether or not one _has_ to implement Trickle I-D when implementing RPL. Alex > > On Jul 29, 2010, at 11:19 PM, Alexandru Petrescu wrote: > >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - >>> 5mn) [160] Quick update on the changes in -02. Currently in LC. >>> >>> JP> ID is a normative reference in RPL core spec (thus we have >>> a downref). Discussion on ID status JP> Will come back to the >>> list to consider status change (informational to standard track) >> >> Just a quick note to consider more ways to solve this problem (RPL >> spec 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References >> section. This implies making Trickle parameters less mandatory in >> RPL. -change the track of the base spec to Informational (this >> implies change to communication to SDO requiring this RP, I >> suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... >> Trickle being common practice in widespread use yet not really a >> protocol (timer management). >> >> These may have already been considered, >> >> Alex _______________________________________________ Roll mailing >> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Sat Jul 31 08:05:11 2010 Return-Path: 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 41F583A699C for ; Sat, 31 Jul 2010 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.673, 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 bDj1bNwewe4S for ; Sat, 31 Jul 2010 08:05:10 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E19BF3A68E0 for ; Sat, 31 Jul 2010 08:05:08 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C5C55940154; Sat, 31 Jul 2010 17:05:28 +0200 (CEST) Message-ID: <4C543BB7.4010200@gmail.com> Date: Sat, 31 Jul 2010 17:05:27 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> In-Reply-To: <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100731-0, 31/07/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D 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: , X-List-Received-Date: Sat, 31 Jul 2010 15:05:11 -0000 Le 30/07/2010 22:54, JP Vasseur a écrit : > > On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: > >> Alex: >> >> We need to be very clear that the WG is chartered for Standard >> Track, not Informational. So RPL is and will stay on that track. > > That's correct. > >> Moving Trickle to standard track is a good move, highly deserved >> for a method that's well understood and proven, and I support it >> 100%. >> > > As a WG LC, I do favor to have the trickle ID move to Std track too. Would Trickle Stds Track mean it is mandatory in order to implement RPL? Alex > > JP. > >> Safe trip back, >> >> Pascal >> >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf >> Of >>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D (was: >>> Draft ROLL WG minutesposted) >>> >>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - >>>> 5mn) [160] Quick update on the changes in -02. Currently in >>>> LC. >>>> >>>> JP> ID is a normative reference in RPL core spec (thus we have >>>> a downref). Discussion on ID status JP> Will come back to the >>>> list to consider status change (informational to standard >>>> track) >>> >>> Just a quick note to consider more ways to solve this problem >>> (RPL >> spec >>> 'downref'erencing a draft it fully relies on): >>> >>> -move draft-ietf-roll-trickle in the Informative References >>> section. This implies making Trickle parameters less mandatory in >>> RPL. -change the track of the base spec to Informational (this >>> implies >> change to >>> communication to SDO requiring this RP, I suppose). >>> >>> Also worth mentioning the use of BCP tag on the Trickle draft... >> Trickle being >>> common practice in widespread use yet not really a protocol >>> (timer management). >>> >>> These may have already been considered, >>> >>> Alex _______________________________________________ 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 alexandru.petrescu@gmail.com Sat Jul 31 08:14:28 2010 Return-Path: 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 69AB23A68E0 for ; Sat, 31 Jul 2010 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=0.662, 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 td5J2IAXgPme for ; Sat, 31 Jul 2010 08:14:21 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 004223A69E2 for ; Sat, 31 Jul 2010 08:14:18 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D89B594001E; Sat, 31 Jul 2010 17:14:38 +0200 (CEST) Message-ID: <4C543DDD.9070706@gmail.com> Date: Sat, 31 Jul 2010 17:14:37 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Ulrich Herberg References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100731-0, 31/07/2010), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D 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: , X-List-Received-Date: Sat, 31 Jul 2010 15:14:28 -0000 Le 30/07/2010 14:54, Ulrich Herberg a écrit : > Hi, > > On Fri, Jul 30, 2010 at 2:09 PM, Pascal Thubert (pthubert) > wrote: >> Alex: >> >> We need to be very clear that the WG is chartered for Standard >> Track, not Informational. So RPL is and will stay on that track. >> Moving Trickle to standard track is a good move, highly deserved >> for a method that's well understood and proven, and I support it >> 100%. > > I fully agree with Pascal. Well yes, I agree too about the first part in Pascal's commen, because the "ROLL routing protocol specification as PS" is in the Charter - this makes impossible to switch RPL to INFORMATIONAL. Yet the Charter does not seem to say something about Trickle I-D... About the statement saying that Trickle is a method well understood and proven - it may be so about this Trickle I-D, probably in TinyOS (or other?); but the "trickle" term generally in LLNs means something different to me: power management, trickle power charge, trickle operation of GPS chipset, etc. It may be only me. Alex > > Ulrich > > >> >> Safe trip back, >> >> Pascal >> >>> -----Original Message----- From: roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] On Behalf >> Of >>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D (was: >>> Draft ROLL WG minutesposted) >>> >>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil >>>> - 5mn) [160] Quick update on the changes in -02. Currently in >>>> LC. >>>> >>>> JP> ID is a normative reference in RPL core spec (thus we >>>> have a downref). Discussion on ID status JP> Will come back to >>>> the list to consider status change (informational to standard >>>> track) >>> >>> Just a quick note to consider more ways to solve this problem >>> (RPL >> spec >>> 'downref'erencing a draft it fully relies on): >>> >>> -move draft-ietf-roll-trickle in the Informative References >>> section. This implies making Trickle parameters less mandatory >>> in RPL. -change the track of the base spec to Informational >>> (this implies >> change to >>> communication to SDO requiring this RP, I suppose). >>> >>> Also worth mentioning the use of BCP tag on the Trickle draft... >> Trickle being >>> common practice in widespread use yet not really a protocol >>> (timer management). >>> >>> These may have already been considered, >>> >>> Alex _______________________________________________ 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 jpv@cisco.com Sat Jul 31 13:40:09 2010 Return-Path: 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 371143A68DF for ; Sat, 31 Jul 2010 13:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.496 X-Spam-Level: X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 4JWWMpiNP1FY for ; Sat, 31 Jul 2010 13:40:07 -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 4208A3A65A5 for ; Sat, 31 Jul 2010 13:40:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP4mVExAZnwN/2dsb2JhbACgJ3Gjc5orhTkEiH+CPg X-IronPort-AV: E=Sophos;i="4.55,296,1278288000"; d="scan'208";a="141751970" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 31 Jul 2010 20:40:32 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6VKeWIo002708; Sat, 31 Jul 2010 20:40:32 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Jul 2010 22:40:32 +0200 Received: from [192.168.1.10] ([10.61.87.163]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 31 Jul 2010 22:40:31 +0200 Message-Id: <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C543BB7.4010200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 31 Jul 2010 22:40:31 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 31 Jul 2010 20:40:31.0848 (UTC) FILETIME=[9E6DEE80:01CB30F0] Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D 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: , X-List-Received-Date: Sat, 31 Jul 2010 20:40:09 -0000 On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: > Le 30/07/2010 22:54, JP Vasseur a =E9crit : >> >> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: >> >>> Alex: >>> >>> We need to be very clear that the WG is chartered for Standard >>> Track, not Informational. So RPL is and will stay on that track. >> >> That's correct. >> >>> Moving Trickle to standard track is a good move, highly deserved >>> for a method that's well understood and proven, and I support it >>> 100%. >>> >> >> As a WG LC, I do favor to have the trickle ID move to Std track too. > > Would Trickle Stds Track mean it is mandatory in order to implement =20= > RPL? > If you want Alex I can give you a call and explain the process next =20 week. In a nutshell, Trickle is a normative reference (answer to your =20 question is of course "yes") and RPL is std track according to our charter. Now we can either have =20= the trickle ID be an informative ref in which case we have what we call a downref or simply =20= move trickle to Std track. Feel free to to express your opinion about the trickle ID =20 (informational or std track) as part of WG LC. For the process in general, let me know if you need =20= more pointers to understand the process. Thanks. JP. > Alex > >> >> JP. >> >>> Safe trip back, >>> >>> Pascal >>> >>>> -----Original Message----- From: roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] On Behalf >>> Of >>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D (was: >>>> Draft ROLL WG minutesposted) >>>> >>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - >>>>> 5mn) [160] Quick update on the changes in -02. Currently in >>>>> LC. >>>>> >>>>> JP> ID is a normative reference in RPL core spec (thus we have >>>>> a downref). Discussion on ID status JP> Will come back to the >>>>> list to consider status change (informational to standard >>>>> track) >>>> >>>> Just a quick note to consider more ways to solve this problem >>>> (RPL >>> spec >>>> 'downref'erencing a draft it fully relies on): >>>> >>>> -move draft-ietf-roll-trickle in the Informative References >>>> section. This implies making Trickle parameters less mandatory in >>>> RPL. -change the track of the base spec to Informational (this >>>> implies >>> change to >>>> communication to SDO requiring this RP, I suppose). >>>> >>>> Also worth mentioning the use of BCP tag on the Trickle draft... >>> Trickle being >>>> common practice in widespread use yet not really a protocol >>>> (timer management). >>>> >>>> These may have already been considered, >>>> >>>> Alex _______________________________________________ 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 >> >> >