From angelo.castellani@gmail.com Thu Sep 1 01:02:21 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC0A21F8B3B for ; Thu, 1 Sep 2011 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRfWxtsnjjUv for ; Thu, 1 Sep 2011 01:02:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5960821F8B28 for ; Thu, 1 Sep 2011 01:02:20 -0700 (PDT) Received: by wwf5 with SMTP id 5so1069388wwf.13 for ; Thu, 01 Sep 2011 01:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ZDhuXSIF1SHtQf0RwOVtMVhwz9g3TvOqIw5wNzRjldU=; b=tnB52qmb9E7L/Ev01cNprDIi+v/lmXVdT743sFkNjDzkfQpeb9Kz+rABg6vY6+mZhl 8yrxSsGM0JikJSUmZt326hRUicIPXETSH0XE4bGM1p3GqB4apvOm+FN9EHICjPUqThUW oAId9bi8N/Ksewt5xhR3iNqfApIex7jdZuc4E= Received: by 10.216.184.147 with SMTP id s19mr1259499wem.36.1314864230093; Thu, 01 Sep 2011 01:03:50 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Thu, 1 Sep 2011 01:03:30 -0700 (PDT) In-Reply-To: <24100.1314827183@marajade.sandelman.ca> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> From: "Angelo P. Castellani" Date: Thu, 1 Sep 2011 10:03:30 +0200 X-Google-Sender-Auth: cErucZGv8D8wpXjAhODz5q4cB3Q Message-ID: To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:02:21 -0000 +1 On Wed, Aug 31, 2011 at 23:46, Michael Richardson wrote: > >>>>>> "Thomas" =3D=3D Thomas Heide Clausen writes= : > =A0 =A0Thomas> I'd much like a routing protocol, designed for low-power, > =A0 =A0Thomas> lossy networks and with low-MTU MACs as one of its > =A0 =A0Thomas> design-target to be able to run over these networks. If > =A0 =A0Thomas> _this_ early a need for an alternative, more compact, pack= et > =A0 =A0Thomas> format is identified, then by all means let's get RPL > =A0 =A0Thomas> updated to use that alternative, more compact, packet > =A0 =A0Thomas> format. I have absolutely no problems with that. > > +1 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Jorjeta.Jetcheva@itron.com Thu Sep 1 01:16:47 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9521F8A95 for ; Thu, 1 Sep 2011 01:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW-hOrcV1Dck for ; Thu, 1 Sep 2011 01:16:45 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0421F8A7D for ; Thu, 1 Sep 2011 01:16:44 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Thu, 1 Sep 2011 01:18:13 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" Date: Thu, 1 Sep 2011 01:18:08 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxoHgdouVr1zpYlRQ2FeCJZrDyWRQAYB80w Message-ID: <0368F388C03BB34BBBFA73209849D47A4CCBA5AF@ITR-EXMBXVS-2.itron.com> References: <4EA811E84AEC874FA69EE87C8C6BBEB5869A3495B3@FRPARSV10.mx.bm.net> 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 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:16:47 -0000 Hello Bora, It seems that you do not agree with any of the deployment advantages of mes= h mentioned on the list. What in your view are the scenarios where deployi= ng a mesh has an advantage over deploying cellular or wireline or any other= type of technology? Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 1:39 PM To: Salazar, Ruben; Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Ruben I think if you are in rural US (think Montana), I am not sure wireless mesh network is going to have any advantages for coverage when compared to cellular. Regardless, I would propose that the suggested wording below is used to replace the existing paragraph in this draft. In one type of AMI network, electric meters are interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility network through a network aggregation point (NAP). In a multi-hop mesh network, each electric meter mesh may have up toseveral thousand wireless endpoints, with densities varying based on the area and the terrain. Apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have one or two network neighbors. Paths in the mesh between a network device and the nearest aggregation point may be composed of several hops or even tens of hops. Do you have any objections? Thanks --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 10:59 AM, "Salazar, Ruben" wrote: >All, >The benefit of multi-hop networks is clear as it relates to geography >coverage: that is why star topologies have some hidden repeat-route-relay >features/mechanisms to extend coverage, which comes naturally with mesh >topologies. And this statement applies to both wireless and wired >networks. >Regards > >Ruben Salazar >Director Research and Technology >Landis+Gyr >Energy Management Solutions >Office: +1 678 258 3165 >Ruben.Salazar@landisgyr.com >www.landisgyr.com >manage energy better > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Jetcheva, Jorjeta >Sent: Wednesday, August 31, 2011 1:17 PM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hi Bora and all, > >There were some comments on the list related to adding text about the >applicability of multi-hop vs. single-hop deployments. This paragraph >attempted to distinguish between the two. Perhaps it is not necessary to >motivate the existence/use of multi-hop networks because they are already >the focus of the protocol development within this group. > >Does anyone else have any additional comments regarding including text >about the benefits of multi-hop networks as compared to single-hop >networks in the draft? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 9:13 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hi again, > >My point is that this statement adds no value to the document and in my >opinion subtracts value. >The alternate wording I suggested is technical and avoids "markitecture" >type statements. > >I meant powerline (as in Aclara TWACS or the newer technologies) which is >essentially a single hop technology. > >I believe the cost effectiveness of a particular technology highly depends >on the OPEX as well as the CAPEX, >and customer density. I don't think we should take that on in an IETF >document. > >Regards > > >-- >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" >wrote: > >>Hello Bora, >> >>The text in this paragraph doesn't actually use the word "substantial", >>and I think you meant "wireline", not "powerline". >> >>What would you consider to be a "substantiated" statement of the >>applicability/benefits of mesh networks relative to other deployment >>paradigms? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards >>CTO Office >>Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 8:40 AM >>To: Jetcheva, Jorjeta >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >>Hi Jorjeta >> >>Sorry, I had two comments in my original email. One was regarding >>gas/power meters and the second regarding the non-technical slant in the >>introduction. >>The modified paragraph that I proposed is related to the second point. >> >>To answer your question, I disagree with the unbsubstantiated statement >>that multi-hop wireless mesh networks have substantial cost benefits >>compared to either powerline or single-hop (e.g. cellular modems) >>networks. >>I am not saying this is completely wrong, I am saying that this statement >>does not belong in an IETF document since it has no relevance to ROLL >>or the applicability of ROLL to AMI networks. I think the paragraph I >>proposed is clear-cut and technically accurate without having a bias >>towards the use of wireless mesh networks. >> >>Regards >> >>Bora >> >>-----Original Message----- >>From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >>Sent: Wednesday, August 31, 2011 8:35 AM >>To: Akyol, Bora A >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hello Bora, >> >>The paragraph you cited does not reference anything related to water or >>gas meters which was the topic of your earlier comment and the discussion >>that followed. Is this perhaps not the right paragraph or is this the >>beginning of a new discussion? >> >>As far as the benefits of multi-hop networks over wireline or cellular >>backhaul, I think that lower cost and deployment complexity are pretty >>commonly cited. Do you disagree with this statement? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 8:09 AM >>To: Nicolas DEJEAN >>Cc: Jetcheva, Jorjeta; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >> >>Hi Nicolas >> >>Yes, we had a private email exchange off-list. >> >>I would like to suggest alternate wording for this paragraph as follows: >> >>ORIGINAL: >> >> Electric meters are often interconnected into multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). These >> kinds of networks increase coverage and reduce installation cost, >> time and complexity, as well as operational costs, as compared to >> single-hop wireless networks, relying on a wireline or cellular >> backhaul. Each electric meter mesh typically has on the order of >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >>have sparse node distributions and include nodes that only have one or >>two network neighbors. Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >> >> >>ALTERNATE WORDING: >> >> >>In one type of AMI network, electric meters are interconnected into >>multi-hop mesh >>networks, each of which is connected to a backhaul network leading to >>the utility network through a network aggregation point (NAP). >> >>>mesh> >> >>In a multi-hop mesh network, each electric meter mesh may have up to >>several thousand wireless endpoints, with densities varying based on >>the area and the terrain. Apartment buildings in urban centers may >>have hundreds of meters in close proximity, whereas rural areas may >>have sparse node distributions and include nodes that only have one or >>two >>network neighbors. >>Paths in the mesh between a network device >>and the nearest aggregation point may be composed of several hops or >>even tens of hops. >> >> >> >>What do you think? >> >>Thanks >> >> >>-- >>Bora Akyol, Pacific Northwest National Laboratory >>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >>On 8/31/11 4:23 AM, "Nicolas DEJEAN" >>wrote: >> >>>Hello Bora, >>> >>>Did Jorjeta answered your concerns about an AMI network considered as >>>a backhaul for Gas and Water? >>> >>>Thank you in advance, >>> >>>Nicolas. >>> >>>2011/8/30 Jetcheva, Jorjeta : >>>> Hello Bora, >>>> >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>> >>>> Actually AMI backhaul for gas and water meters is very much in scope >>>>as >>>>per the NIST Wireless Guidelines (PAP2) work and the related >>>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>>should be aware of this. >>>> >>>> Jorjeta >>>> >>>> Jorjeta Jetcheva, Ph.D. >>>> Principal Engineer, Architecture & Standards >>>> CTO Office >>>> Itron, Inc. >>>> >>>> >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>>Of >>>>Akyol, Bora A >>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>> To: Nicolas DEJEAN >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] I-D Action: >>>>draft-ietf-roll-applicability-ami-01.txt >>>> >>>> Hi Nicolas >>>> >>>> Thank you for your response. >>>> >>>> Please see my comments within >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>> >>>> >>>> >>>> >>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>> >>>> wrote: >>>> >>>>>Hello Bora, >>>>> >>>>>2011/7/29 Akyol, Bora A : >>>>>> I think the statement about AMI networks being used as an almost >>>>>>general >>>>>> purpose backhaul network for all other devices >>>>>> is overreaching. I know there are some utilities that are looking >>>>>>into >>>>>> this, but a lot more that have shied away from >>>>>> this vision. Secondly, there are a lot more AMI deployments not >>>>>>using >>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>> powerline carrier, etc. >>>>> >>>>>I agree that all utilities are not looking into it. >>>>>However this is one possible case that should be considered, isn't it? >>>>>Could you please precise what you are expecting to be in the draft? >>>> >>>> I think the draft should be focusing on the applicability of ROLL from >>>>a >>>> technical front >>>> without siting this one case as the only justification. >>>> >>>>> >>>>>> >>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>>also >>>>>> potentially >>>>>> remove Gas & Water meters from the scope of this document. >>>>>> >>>>> >>>>>On our point of view, Gas and Water metering are part of AMI. >>>> >>>> This is not the widely-held view at least within the US electric >>>>utility >>>> community. >>>> The gas and water meters have capabilities which are quite different >>>>from >>>> electric power meters. >>>> For example, while the electric meter has easy access to mains power, >>>>the >>>> gas/water meters don't. >>>> In most instances, the gas/water service may be provided by a >>>>completely >>>> different entity than the electric >>>> power utility. >>>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>>> >>>> Would the document lose technical integrity if the gas/water meter >>>>were >>>> either removed or included as an optional. >>>> >>>> Regards >>>> >>>> >>>> >>>>>Could you please elaborate? >>>>>According to you, why should Gas and Water be removed from the draft? >>>>> >>>>>Thank you in advance, >>>>> >>>>>Nicolas. >>>>> >>>>>> Regards >>>>>> >>>>>> -- >>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>> >>>>>> _______________________________________________ >>>>>> 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 angelo.castellani@gmail.com Thu Sep 1 01:25:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484AB21F8B6E for ; Thu, 1 Sep 2011 01:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzPiyptipYWq for ; Thu, 1 Sep 2011 01:25:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2D721F8B63 for ; Thu, 1 Sep 2011 01:25:42 -0700 (PDT) Received: by wyg8 with SMTP id 8so1306201wyg.31 for ; Thu, 01 Sep 2011 01:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=tB0rw7t5x86Aw6JBM6oTomiBFfWWT1/1NRYslpp2kvQ=; b=LlU9QJHczi5KANEAKyD5+Gnw/fNXSaSprrfyEm/hzYu+sS6hF3UG3MTarBdw4QawwV /Twg89IfpJWSNqcC7sFULCH2rDE9wIHA/dr4Isv9wHeXPOrXf5QJ7d1kfbjbbMoRy3OL U0/x5uI7MwcPmzgbxf2vP1uTdC/ARgdjFv7gQ= Received: by 10.216.20.5 with SMTP id o5mr1277275weo.51.1314865581415; Thu, 01 Sep 2011 01:26:21 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Thu, 1 Sep 2011 01:26:01 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D055AE27C@XMB-AMS-107.cisco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D055AE27C@XMB-AMS-107.cisco.com> From: "Angelo P. Castellani" Date: Thu, 1 Sep 2011 10:26:01 +0200 X-Google-Sender-Auth: 9i8yMSJFCy-PRGcAixLPBG5AL_U Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a newROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:25:43 -0000 On Wed, Aug 31, 2011 at 18:07, Pascal Thubert (pthubert) wrote: > Also, I think that if we change RPL to RPLv2, I will not mind changing the compression to compression v2 at the same time, because probably the 2 RPL versions would not interoperate well. I think that by introducing compression we are already working to a completely different version of RPL, in which the packet format is updated. Moreover I think that the term compression leads to some confusion, it is not a general compression but a more synthetic packet format of some "critical" packets and options. Given that supporting both a verbose and a synthetic packet format for interoperability, is a pain and adds even more overhead, why shouldn't we want to require the use of the synthetic packet format. Probably a good solution to this problem will be defining over which kind of L2 mediums the use of the synthetic packet formats. EXAMPLE: If the DIO message does not fit in a single frame MUST be using the "synthetic packet format" (MUST be "compressed"). Best, Angelo From angelo.castellani@gmail.com Thu Sep 1 01:30:52 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1FD21F8B5C for ; Thu, 1 Sep 2011 01:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqJHuNlFcIns for ; Thu, 1 Sep 2011 01:30:51 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0D221F84F6 for ; Thu, 1 Sep 2011 01:30:51 -0700 (PDT) Received: by wyg8 with SMTP id 8so1310710wyg.31 for ; Thu, 01 Sep 2011 01:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ogY2xaiS5s4os80Un5VxeiJ2dKeHph7TYbIyE6CfOE8=; b=lEk1dPDBYC/Gf4Wv8UuMlmLUzVz4wUSMoE9RLqHZCYBssjE2AnrUCQIpT2/qGczdLR T+RKM+YDHHsEpxg7bfSxwR3zlr2lX5+SfeHJA+cj5ffEftfGm5AOpnmVooLcctpKpJoV VGTKss0yZvHprYrrHMdSvVAMeNjX3cYSkl+Zg= Received: by 10.216.210.206 with SMTP id u56mr1336171weo.21.1314865943231; Thu, 01 Sep 2011 01:32:23 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Thu, 1 Sep 2011 01:32:03 -0700 (PDT) In-Reply-To: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> From: "Angelo P. Castellani" Date: Thu, 1 Sep 2011 10:32:03 +0200 X-Google-Sender-Auth: iKlhS-tVtgRwRMVcUKokKiWpvxs Message-ID: To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:30:52 -0000 I slightly changed my mind about this +1. Probably a good way to avoid this problem is to require the update of the RPL packet format only for those mediums where the use of a synthetic packet formats is a strong requirement (e.g. 802.15.4). As detailed in , the conditions can be characterized in a more general way, avoiding referencing single technologies in the standard: "If the L2 medium does not support frames longer than X, than only the synthetic packet format MUST be used." In this way we avoid manual configuration and supporting both formats in devices that target implementing this spec on very limited L2 medium. In other words, synthetic packet format should be a MUST for some lower layer technologies characterized by some parameters (without referencing specific technologies). Best, Angelo On Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani wrote: > +1 > > On Wed, Aug 31, 2011 at 23:46, Michael Richardson wrot= e: >> >>>>>>> "Thomas" =3D=3D Thomas Heide Clausen write= s: >> =A0 =A0Thomas> I'd much like a routing protocol, designed for low-power, >> =A0 =A0Thomas> lossy networks and with low-MTU MACs as one of its >> =A0 =A0Thomas> design-target to be able to run over these networks. If >> =A0 =A0Thomas> _this_ early a need for an alternative, more compact, pac= ket >> =A0 =A0Thomas> format is identified, then by all means let's get RPL >> =A0 =A0Thomas> updated to use that alternative, more compact, packet >> =A0 =A0Thomas> format. I have absolutely no problems with that. >> >> +1 >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > From mcr@sandelman.ca Thu Sep 1 06:42:54 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E521F95EB for ; Thu, 1 Sep 2011 06:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2VpcxHrd8qz for ; Thu, 1 Sep 2011 06:42:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44E21F95EA for ; Thu, 1 Sep 2011 06:42:52 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 19ACB3430B for ; Thu, 1 Sep 2011 09:43:43 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9ECB798B17 for ; Thu, 1 Sep 2011 09:44:54 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 01 Sep 2011 09:44:54 -0400 Message-ID: <7748.1314884694@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 13:42:54 -0000 >>>>> "Angelo" == Angelo P Castellani writes: Angelo> Probably a good way to avoid this problem is to require the Angelo> update of the RPL packet format only for those mediums where Angelo> the use of a synthetic packet formats is a strong Angelo> requirement (e.g. 802.15.4). No. You still massively increase the testing effort for no gain. -- ] 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 angelo.castellani@gmail.com Thu Sep 1 06:52:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F70A21F98EE for ; Thu, 1 Sep 2011 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnZpD0jK-lUc for ; Thu, 1 Sep 2011 06:52:37 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id C794121F98EC for ; Thu, 1 Sep 2011 06:52:36 -0700 (PDT) Received: by wwe5 with SMTP id 5so1216367wwe.1 for ; Thu, 01 Sep 2011 06:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Hc527x2HDNAR9FmYEZK82Ctu02ml5i5yxbJ337jMRdI=; b=SjJJoA5eou9aevqYg4Gb4SR0UfFH7inBWSJ+jSN3CcBca7jfJ159xiK4rIfDAkUxWL FabWdkra+Xs00WsEsZH1oeqUJdsZ3e1qd/7WmjG6O/Fus3g5t0nRWyjaSmHgSQjBE+m0 XWyO5He4u2nJNOmVbxH2nAh0BTzwkGTqihuY8= Received: by 10.216.20.5 with SMTP id o5mr257683weo.51.1314885249116; Thu, 01 Sep 2011 06:54:09 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Thu, 1 Sep 2011 06:53:48 -0700 (PDT) In-Reply-To: <7748.1314884694@marajade.sandelman.ca> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> From: "Angelo P. Castellani" Date: Thu, 1 Sep 2011 15:53:48 +0200 X-Google-Sender-Auth: G8ce-DBPBws5ADg5vAHPsvaPPDk Message-ID: To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 13:52:37 -0000 On Thu, Sep 1, 2011 at 15:44, Michael Richardson wrote: > No. You still massively increase the testing effort for no gain. As long as I can implement only the smaller format in energy-constrained networks and be interoperable, my gain is clear. Probably I would have preferred a more compact RPL message format everywhere, however now this seems to be not possible anymore. There was some messages in this thread saying that it was decided on the ML that RPL should not have only the synthetic packet format, so for this reason the best option for low-power (short-frames, low-bandwidth) networks is to have the synthetic format as a MUST on them. Angelo From pthubert@cisco.com Thu Sep 1 07:21:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7136D21F968C for ; Thu, 1 Sep 2011 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycRRjK5IzPQK for ; Thu, 1 Sep 2011 07:21:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BDDD221F962F for ; Thu, 1 Sep 2011 07:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2202; q=dns/txt; s=iport; t=1314886976; x=1316096576; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zFiuert+XPoyC6EtvIr5s3w0zIx6WhLfBlw5lB2P7sI=; b=mqxNne6EX30xy8LmdMEiK3TIEQHUbi8l1QApb8x5axJZvho1fqyQyqNw +UqVTJTAQf6H/zquW6/cBcjuWHaEDMTvbRS6pjwzUmcsREF86Qd13+OkN md+3LnTzJqzavOpTt6Ht6PM/KV+1loV7AU6bvHyJANAJorI/GTfwq/UoP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALOUX06Q/khR/2dsb2JhbABCqFV3gUABAQEBAwEBAQ8BHQoyAggDDAQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah1SZDAGfMYV7YASYPIt1 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="52861226" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Sep 2011 14:22:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p81EMt0M021905; Thu, 1 Sep 2011 14:22: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); Thu, 1 Sep 2011 16:22:55 +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, 1 Sep 2011 16:22:54 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D055AE57F@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxorqUa7mOgs/XkRi6GtPeCnXFWkgAAlQag References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu><4884.1314797912@marajade.sandelman.ca><8CA251EF-2842-453A-964A-E3F30713917A@cisco.com><2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org><24100.1314827183@marajade.sandelman.ca><7748.1314884694@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Angelo P. Castellani" , "Michael Richardson" X-OriginalArrivalTime: 01 Sep 2011 14:22:55.0321 (UTC) FILETIME=[A4150490:01CC68B2] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:21:37 -0000 Hello Angelo For the current features, RPL is now complete. We could have done smaller options but that's not the way the WG decided to go.=20 The idea was and is still that for a constrained environment, an additional compression could take place as an adaptation layer, not as a protocol replacement. This is what 6LoWPAN HC does for 802.15.4 based networks for instance. That approach is being extended for multiple other LLC/MACs, including Bluetooth and DECT.=20 And GHC http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-02 extends the approach for RPL and other protocols. For me the question is really whether GHC is the final answer or if we should recommend something more specific to RPL, for instance adding a little bit of dictionary into it. If GHC appears to be the right approach, then let it be known and let us find a WG to host it. If we prefer a more RPL-specific compression, then maybe we can host it. In any fashion, I'd think that the compression needs to improve not only the control, but also the data packets. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Angelo P. Castellani Sent: jeudi 1 septembre 2011 15:54 To: Michael Richardson Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document On Thu, Sep 1, 2011 at 15:44, Michael Richardson wrote: > No. You still massively increase the testing effort for no gain. As long as I can implement only the smaller format in energy-constrained networks and be interoperable, my gain is clear. Probably I would have preferred a more compact RPL message format everywhere, however now this seems to be not possible anymore. There was some messages in this thread saying that it was decided on the ML that RPL should not have only the synthetic packet format, so for this reason the best option for low-power (short-frames, low-bandwidth) networks is to have the synthetic format as a MUST on them. Angelo _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From yi.jiazi@gmail.com Thu Sep 1 07:26:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6261221F9945 for ; Thu, 1 Sep 2011 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDYuYjYShZxD for ; Thu, 1 Sep 2011 07:26:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 872E321F9944 for ; Thu, 1 Sep 2011 07:26:58 -0700 (PDT) Received: by wwf5 with SMTP id 5so1316519wwf.13 for ; Thu, 01 Sep 2011 07:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=bxXUcOL5Cqh/34QKs2bhO7F53XP26nXE3BpaG9Gk+bU=; b=sFJ7r1c0kb7X2+Txi+czmDSuKNhmlcsb44h8/UjtZtW17c06oBmIW9MCXdmNHCMWKX 363XvoEIngWFe4pOvKL3wnUFqlmynazdrHaX+2YTNrsH0zTgegvpMmHzerfre6Adf7R9 h9ftQJEZbq9YQclRlmIm+rjVnH04blmK6GxDQ= Received: by 10.216.220.139 with SMTP id o11mr253340wep.59.1314887310095; Thu, 01 Sep 2011 07:28:30 -0700 (PDT) Received: from jy-mac-pro.local (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id p18sm84288wbh.21.2011.09.01.07.28.27 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 07:28:28 -0700 (PDT) Message-ID: <4E5F968A.2000005@gmail.com> Date: Thu, 01 Sep 2011 16:28:26 +0200 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "Angelo P. Castellani" References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:26:59 -0000 On 9/1/11 3:53 PM, Angelo P. Castellani wrote: > for this reason the best option for low-power (short-frames, > low-bandwidth) networks is to have the synthetic format as a MUST on > them. if I understand well, this is what "ROLL" stands for. > Probably I would have preferred a more compact RPL message format > everywhere if it doesn't do any harm to the performance, and MUST be used for "low power, low-bandwidth" networks... +1 > Angelo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Jiazi YI From angelo.castellani@gmail.com Thu Sep 1 07:58:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8479721F9632 for ; Thu, 1 Sep 2011 07:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq-7VX5CUwyG for ; Thu, 1 Sep 2011 07:58:48 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA9CE21F9631 for ; Thu, 1 Sep 2011 07:58:47 -0700 (PDT) Received: by wyg8 with SMTP id 8so1630356wyg.31 for ; Thu, 01 Sep 2011 08:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=v2b9l8ksdvRogk6jPzgPx2prfOw2ClWjQ/yP3GmHwfE=; b=e9Xi70dehDDlGaP4zPx9psoXuRXEPwIpAxuhEzij3kHq+vQuzeNztMmTgjcId8sfT2 rnvak67wY47oN0RarVLbLqQ5OMUhOLjW5ilggjV/NnlGnuikbp+xkGcCFtEM8TOQjUy8 LvMAU1ot9UbYWqdj4aQ7h2tldRXN3VzmFGXG0= Received: by 10.216.20.5 with SMTP id o5mr325278weo.51.1314889220210; Thu, 01 Sep 2011 08:00:20 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Thu, 1 Sep 2011 07:59:59 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D055AE57F@XMB-AMS-107.cisco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D055AE57F@XMB-AMS-107.cisco.com> From: "Angelo P. Castellani" Date: Thu, 1 Sep 2011 16:59:59 +0200 X-Google-Sender-Auth: mBgD0S_uGlOfnUZraDhXxFCA8LA Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:58:48 -0000 Thanks Pascal for the interesting response. Some comments (and more questions) inline. On Thu, Sep 1, 2011 at 16:22, Pascal Thubert (pthubert) wrote: > For the current features, RPL is now complete. We could have done > smaller options but that's not the way the WG decided to go. OK, I understand that the WG did not decided to go for a "compact" format (everywhere). Some questions about the design of the current message format: 1) What are the benefits of having a protocol targeting LLNs with very big flexible base message format? 2) Wouldn't a more parsimonious packet format, more defaults, more in-line fields be a better tradeoff? > The idea was and is still that for a constrained environment, an > additional compression could take place as an adaptation layer, not as a > protocol replacement. > This is what 6LoWPAN HC does for 802.15.4 based networks for instance. > That approach is being extended for multiple other LLC/MACs, including > Bluetooth and DECT. I am not against compression work and I personally like that efforts, such as 6LoWPAN. However we should remember that 6LoWPAN is born as the "IPv6 over IEEE 802.15.4" whereas IPv6 targets the whole Internet and obviously requires an adaptation layer to adapt to the various lower-layer technologies. The work that 6LoWPAN WG has done is very useful, and much work will be shared (hopefully in a single document) even for different lower layers. However, in my understanding of ROLL, this WG is born targeting LLNs, where short-frames and low-bandwidth is the norm rather than the exception. > And GHC http://tools.ietf.org/html/draft-bormann-6lowpan-ghc-02 extends > the approach for RPL and other protocols. > > For me the question is really whether GHC is the final answer or if we > should recommend something more specific to RPL, for instance adding a > little bit of dictionary into it. > > If GHC appears to be the right approach, then let it be known and let us > find a WG to host it. If we prefer a more RPL-specific compression, then > maybe we can host it. > > In any fashion, I'd think that the compression needs to improve not only > the control, but also the data packets. In my understanding, GHC is a general purpose compression method, that should be applied to address the fact that we can't expect that every protocol will be redesigned or compressed to go on power-constrained networks. Native power-constrained protocols probably can natively get better results by considering the fact that are being designed for such networks. Best, Angelo From mcr@sandelman.ca Thu Sep 1 08:35:41 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1893D21F9631 for ; Thu, 1 Sep 2011 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZCSCJe5sQvw for ; Thu, 1 Sep 2011 08:35:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id AA44321F9609 for ; Thu, 1 Sep 2011 08:35:40 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 6A509342E2; Thu, 1 Sep 2011 11:36:30 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EE28B98B17; Thu, 1 Sep 2011 11:37:41 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23961.1314891459.1@marajade.sandelman.ca> Date: Thu, 01 Sep 2011 11:37:41 -0400 Message-ID: <23968.1314891461@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 15:35:41 -0000 >>>>> "Angelo" == Angelo P Castellani writes: Angelo> On Thu, Sep 1, 2011 at 15:44, Michael Richardson Angelo> wrote: >> No. You still massively increase the testing effort for no gain. Angelo> As long as I can implement only the smaller format in Angelo> energy-constrained networks and be interoperable, my gain is Angelo> clear. Agreed. And you are making my point: once you have smaller format, there is no reason why any energy constrained device would ever have the original format. Which is why, if this is useful, then we should have one format only. It doesn't hurt non-energy constrained, non-MTU-constrained devices to use fewer bytes. Angelo> There was some messages in this thread saying that it was Angelo> decided on the ML that RPL should not have only the Angelo> synthetic packet format, so for this reason the best option Angelo> for low-power (short-frames, low-bandwidth) networks is to Angelo> have the synthetic format as a MUST on them. I don't know that the ML concluded that. I thought that most people felt that we should have one format. -- ] 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 prvs=218c51b6a=bora@pnnl.gov Thu Sep 1 08:39:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C1121F99D4 for ; Thu, 1 Sep 2011 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd07kR94ruZ1 for ; Thu, 1 Sep 2011 08:39:01 -0700 (PDT) Received: from emailgw03.pnl.gov (emailgw03.pnl.gov [192.101.109.31]) by ietfa.amsl.com (Postfix) with ESMTP id 88CB721F99D5 for ; Thu, 1 Sep 2011 08:39:01 -0700 (PDT) Received: from emailhub01.pnl.gov ([130.20.251.61]) by emailgw03.pnl.gov with ESMTP/TLS/AES128-SHA; 01 Sep 2011 08:40:34 -0700 Received: from Email05.pnl.gov ([130.20.251.70]) by emailhub01.pnl.gov ([130.20.251.61]) with mapi; Thu, 1 Sep 2011 08:40:34 -0700 From: "Akyol, Bora A" To: "Jetcheva, Jorjeta" Date: Thu, 1 Sep 2011 08:40:31 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxovXy74J1Q7zV+Qn+Dwf3pn+mVgA== Message-ID: In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CCBA5AF@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 15:39:03 -0000 Hi Jorjeta If I understand correctly, this draft is about applicability of ROLL to AMI networks using wireless mesh. Whether wireless mesh has any advantages over any other AMI technology is not very relevant to the draft and in my mind detracts from the draft. Regarding your question on whether mesh has any advantages for AMI, I think the answer is "It depends." Happy to discuss that one over some beverages :-) -- Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 9/1/11 1:18 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >It seems that you do not agree with any of the deployment advantages of >mesh mentioned on the list. What in your view are the scenarios where >deploying a mesh has an advantage over deploying cellular or wireline or >any other type of technology? > >Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 1:39 PM >To: Salazar, Ruben; Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Ruben > >I think if you are in rural US (think Montana), I am not sure wireless >mesh network is going to have any advantages for coverage when compared to >cellular. >Regardless, I would propose that the suggested wording below is used to >replace the existing paragraph in this draft. > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). >In a multi-hop mesh network, each electric meter mesh may have up >toseveral thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > >Do you have any objections? > >Thanks > > > >-- >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 10:59 AM, "Salazar, Ruben" wrote: > >>All, >>The benefit of multi-hop networks is clear as it relates to geography >>coverage: that is why star topologies have some hidden repeat-route-relay >>features/mechanisms to extend coverage, which comes naturally with mesh >>topologies. And this statement applies to both wireless and wired >>networks. >>Regards >> >>Ruben Salazar >>Director Research and Technology >>Landis+Gyr >>Energy Management Solutions >>Office: +1 678 258 3165 >>Ruben.Salazar@landisgyr.com >>www.landisgyr.com >>manage energy better >> >> >>-----Original Message----- >>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Jetcheva, Jorjeta >>Sent: Wednesday, August 31, 2011 1:17 PM >>To: Akyol, Bora A >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hi Bora and all, >> >>There were some comments on the list related to adding text about the >>applicability of multi-hop vs. single-hop deployments. This paragraph >>attempted to distinguish between the two. Perhaps it is not necessary to >>motivate the existence/use of multi-hop networks because they are already >>the focus of the protocol development within this group. >> >>Does anyone else have any additional comments regarding including text >>about the benefits of multi-hop networks as compared to single-hop >>networks in the draft? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards >>CTO Office >>Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 9:13 AM >>To: Jetcheva, Jorjeta >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hi again, >> >>My point is that this statement adds no value to the document and in my >>opinion subtracts value. >>The alternate wording I suggested is technical and avoids "markitecture" >>type statements. >> >>I meant powerline (as in Aclara TWACS or the newer technologies) which is >>essentially a single hop technology. >> >>I believe the cost effectiveness of a particular technology highly >>depends >>on the OPEX as well as the CAPEX, >>and customer density. I don't think we should take that on in an IETF >>document. >> >>Regards >> >> >>-- >>Bora Akyol, Pacific Northwest National Laboratory >>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >>On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" >>wrote: >> >>>Hello Bora, >>> >>>The text in this paragraph doesn't actually use the word "substantial", >>>and I think you meant "wireline", not "powerline". >>> >>>What would you consider to be a "substantiated" statement of the >>>applicability/benefits of mesh networks relative to other deployment >>>paradigms? >>> >>>Thanks, Jorjeta >>> >>>Jorjeta Jetcheva, Ph.D. >>>Principal Engineer, Architecture & Standards >>>CTO Office >>>Itron, Inc. >>> >>> >>>-----Original Message----- >>>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>>Sent: Wednesday, August 31, 2011 8:40 AM >>>To: Jetcheva, Jorjeta >>>Cc: D?jean Nicolas; roll@ietf.org >>>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>> >>>Hi Jorjeta >>> >>>Sorry, I had two comments in my original email. One was regarding >>>gas/power meters and the second regarding the non-technical slant in the >>>introduction. >>>The modified paragraph that I proposed is related to the second point. >>> >>>To answer your question, I disagree with the unbsubstantiated statement >>>that multi-hop wireless mesh networks have substantial cost benefits >>>compared to either powerline or single-hop (e.g. cellular modems) >>>networks. >>>I am not saying this is completely wrong, I am saying that this >>>statement >>>does not belong in an IETF document since it has no relevance to ROLL >>>or the applicability of ROLL to AMI networks. I think the paragraph I >>>proposed is clear-cut and technically accurate without having a bias >>>towards the use of wireless mesh networks. >>> >>>Regards >>> >>>Bora >>> >>>-----Original Message----- >>>From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >>>Sent: Wednesday, August 31, 2011 8:35 AM >>>To: Akyol, Bora A >>>Cc: D?jean Nicolas; roll@ietf.org >>>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>>Hello Bora, >>> >>>The paragraph you cited does not reference anything related to water or >>>gas meters which was the topic of your earlier comment and the >>>discussion >>>that followed. Is this perhaps not the right paragraph or is this the >>>beginning of a new discussion? >>> >>>As far as the benefits of multi-hop networks over wireline or cellular >>>backhaul, I think that lower cost and deployment complexity are pretty >>>commonly cited. Do you disagree with this statement? >>> >>>Thanks, Jorjeta >>> >>>Jorjeta Jetcheva, Ph.D. >>>Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >>> >>> >>>-----Original Message----- >>>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>>Sent: Wednesday, August 31, 2011 8:09 AM >>>To: Nicolas DEJEAN >>>Cc: Jetcheva, Jorjeta; roll@ietf.org >>>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>> >>>Hi Nicolas >>> >>>Yes, we had a private email exchange off-list. >>> >>>I would like to suggest alternate wording for this paragraph as follows: >>> >>>ORIGINAL: >>> >>> Electric meters are often interconnected into multi-hop mesh >>> networks, each of which is connected to a backhaul network leading to >>> the utility network through a network aggregation point (NAP). These >>> kinds of networks increase coverage and reduce installation cost, >>> time and complexity, as well as operational costs, as compared to >>> single-hop wireless networks, relying on a wireline or cellular >>> backhaul. Each electric meter mesh typically has on the order of >>> several thousand wireless endpoints, with densities varying based on >>> the area and the terrain. Apartment buildings in urban centers may >>> have hundreds of meters in close proximity, whereas rural areas may >>>have sparse node distributions and include nodes that only have one or >>>two network neighbors. Paths in the mesh between a network device >>> and the nearest aggregation point may be composed of several hops or >>> even tens of hops. >>> >>> >>>ALTERNATE WORDING: >>> >>> >>>In one type of AMI network, electric meters are interconnected into >>>multi-hop mesh >>>networks, each of which is connected to a backhaul network leading to >>>the utility network through a network aggregation point (NAP). >>> >>>>>mesh> >>> >>>In a multi-hop mesh network, each electric meter mesh may have up to >>>several thousand wireless endpoints, with densities varying based on >>>the area and the terrain. Apartment buildings in urban centers may >>>have hundreds of meters in close proximity, whereas rural areas may >>>have sparse node distributions and include nodes that only have one or >>>two >>>network neighbors. >>>Paths in the mesh between a network device >>>and the nearest aggregation point may be composed of several hops or >>>even tens of hops. >>> >>> >>> >>>What do you think? >>> >>>Thanks >>> >>> >>>-- >>>Bora Akyol, Pacific Northwest National Laboratory >>>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>>On 8/31/11 4:23 AM, "Nicolas DEJEAN" >>> >>>wrote: >>> >>>>Hello Bora, >>>> >>>>Did Jorjeta answered your concerns about an AMI network considered as >>>>a backhaul for Gas and Water? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>2011/8/30 Jetcheva, Jorjeta : >>>>> Hello Bora, >>>>> >>>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>>> backhaul were considered out of scope. >>>>> >>>>> Actually AMI backhaul for gas and water meters is very much in scope >>>>>as >>>>>per the NIST Wireless Guidelines (PAP2) work and the related >>>>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>>>should be aware of this. >>>>> >>>>> Jorjeta >>>>> >>>>> Jorjeta Jetcheva, Ph.D. >>>>> Principal Engineer, Architecture & Standards >>>>> CTO Office >>>>> Itron, Inc. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>>>Of >>>>>Akyol, Bora A >>>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>>> To: Nicolas DEJEAN >>>>> Cc: roll@ietf.org >>>>> Subject: Re: [Roll] I-D Action: >>>>>draft-ietf-roll-applicability-ami-01.txt >>>>> >>>>> Hi Nicolas >>>>> >>>>> Thank you for your response. >>>>> >>>>> Please see my comments within >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> >>>>> >>>>> >>>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>>> >>>>> wrote: >>>>> >>>>>>Hello Bora, >>>>>> >>>>>>2011/7/29 Akyol, Bora A : >>>>>>> I think the statement about AMI networks being used as an almost >>>>>>>general >>>>>>> purpose backhaul network for all other devices >>>>>>> is overreaching. I know there are some utilities that are looking >>>>>>>into >>>>>>> this, but a lot more that have shied away from >>>>>>> this vision. Secondly, there are a lot more AMI deployments not >>>>>>>using >>>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>>> powerline carrier, etc. >>>>>> >>>>>>I agree that all utilities are not looking into it. >>>>>>However this is one possible case that should be considered, isn't >>>>>>it? >>>>>>Could you please precise what you are expecting to be in the draft? >>>>> >>>>> I think the draft should be focusing on the applicability of ROLL >>>>>from >>>>>a >>>>> technical front >>>>> without siting this one case as the only justification. >>>>> >>>>>> >>>>>>> >>>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>>>also >>>>>>> potentially >>>>>>> remove Gas & Water meters from the scope of this document. >>>>>>> >>>>>> >>>>>>On our point of view, Gas and Water metering are part of AMI. >>>>> >>>>> This is not the widely-held view at least within the US electric >>>>>utility >>>>> community. >>>>> The gas and water meters have capabilities which are quite different >>>>>from >>>>> electric power meters. >>>>> For example, while the electric meter has easy access to mains power, >>>>>the >>>>> gas/water meters don't. >>>>> In most instances, the gas/water service may be provided by a >>>>>completely >>>>> different entity than the electric >>>>> power utility. >>>>> >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>>> >>>>> Would the document lose technical integrity if the gas/water meter >>>>>were >>>>> either removed or included as an optional. >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>>>Could you please elaborate? >>>>>>According to you, why should Gas and Water be removed from the draft? >>>>>> >>>>>>Thank you in advance, >>>>>> >>>>>>Nicolas. >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> -- >>>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 pthubert@cisco.com Thu Sep 1 08:42:33 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7121F9807 for ; Thu, 1 Sep 2011 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeFsW8d9Ftcy for ; Thu, 1 Sep 2011 08:42:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0635821F9848 for ; Thu, 1 Sep 2011 08:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2085; q=dns/txt; s=iport; t=1314891846; x=1316101446; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EyUEVnZdgshSgbnE/pYGszTvbjD3Da1cbINSMl3YMKM=; b=IivJ2e4X4LBwqIQBCyhFsp/AHDOnS5aPQgt8Q/9WWyBT9deEHh2lF9k8 A4FsKAn5fhllwY0hzE3mrWSyjaKU+gfIQuMMv3nh/qFlc9nSMW0AQ/fTZ R6XXIBnLy5fJFhNYjStTmU9EvXo17QLfZGUfc4MtnmXoW5J+hrMv6rotR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG+nX06Q/khN/2dsb2JhbABCqEt3gUABAQEBAgESAR0KPwULAgEIIgYYBgFWAQEEGxqHUJo2AZ8phTJJYASYPIt1 X-IronPort-AV: E=Sophos;i="4.68,313,1312156800"; d="scan'208";a="113558749" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2011 15:44:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p81Fi2Ie025772; Thu, 1 Sep 2011 15:44:02 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); Thu, 1 Sep 2011 17:44:02 +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, 1 Sep 2011 17:44:01 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0565D17A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: Acxot+YqD9JcyBGdQhyeMoow2f1OrwAAGDxg References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D055AE57F@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Angelo P. Castellani" X-OriginalArrivalTime: 01 Sep 2011 15:44:02.0821 (UTC) FILETIME=[F9569350:01CC68BD] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 15:42:33 -0000 Hello Angelo: > Some questions about the design of the current message format: >1) What are the benefits of having a protocol targeting LLNs with very big flexible base message format? >2) Wouldn't a more parsimonious packet format, more defaults, more in-line fields be a better tradeoff? We have been quite a bit more parsimonious than classical IPv6. Examples: the length is expressed in bytes, the RH has a prefix factorization... Still, we have refrained to optimize for one specific type of LLN; as you know, LP 802.11 and recent variations of 802.15.4 support IPv6 min MTU. And we have kept reserved fields. They are set to 0 and easy to compress, and at the same time the protocol is open to future extensions. > However, in my understanding of ROLL, this WG is born targeting LLNs, where short-frames and low-bandwidth is the norm rather than the exception. Many sorts of them actually. In one extreme there can be a really optimized adaption layer for each type of LLN and for each given protocol in which case it probably makes sense to leave the work to the IPv6-over-foo WG. GHC is the other end of that spectrum, where we can get a reasonable benefit independent of the MAC and for all sorts of packets. > In my understanding, GHC is a general purpose compression method, that should be applied to address the fact that we can't expect that every protocol will be redesigned or compressed to go on power-constrained networks. > Native power-constrained protocols probably can natively get better results by considering the fact that are being designed for such networks. Yes, that's the discussion I had hoped we'd have with this thread, and the reason why I support this work. You'll note that GHC reuses the 6LoWPAN context and can probably compress efficiently the costly target and transit options, as well as the routing header. My own take is that it is a good start for us, and that we should study its applicability and then figure if/where more specific macros can/need-to be applied.=20 Cheers, Pascal From Jorjeta.Jetcheva@itron.com Thu Sep 1 09:09:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BD821F9652 for ; Thu, 1 Sep 2011 09:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2APBXAogUPh for ; Thu, 1 Sep 2011 09:09:45 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id A06D421F963C for ; Thu, 1 Sep 2011 09:09:43 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Thu, 1 Sep 2011 09:11:16 -0700 From: "Jetcheva, Jorjeta" To: "Akyol, Bora A" Date: Thu, 1 Sep 2011 09:11:13 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxovXy74J1Q7zV+Qn+Dwf3pn+mVgAAAzPFA Message-ID: <0368F388C03BB34BBBFA73209849D47A4CD189D4@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4CCBA5AF@ITR-EXMBXVS-2.itron.com> 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 Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 16:09:49 -0000 Hi Bora, This was actually an independent question -- I was curious about what you h= ad mind. As far as the applicability statement goes, I wanted to give people some ti= me for feedback as per my request yesterday. If there are no objections by= sometime tomorrow, we can remove the multi-hop advantages text. Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov] Sent: Thursday, September 01, 2011 8:41 AM To: Jetcheva, Jorjeta Cc: roll@ietf.org; Salazar, Ruben; D?jean Nicolas Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Jorjeta If I understand correctly, this draft is about applicability of ROLL to AMI networks using wireless mesh. Whether wireless mesh has any advantages over any other AMI technology is not very relevant to the draft and in my mind detracts from the draft. Regarding your question on whether mesh has any advantages for AMI, I think the answer is "It depends." Happy to discuss that one over some beverages :-) -- Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 9/1/11 1:18 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >It seems that you do not agree with any of the deployment advantages of >mesh mentioned on the list. What in your view are the scenarios where >deploying a mesh has an advantage over deploying cellular or wireline or >any other type of technology? > >Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 1:39 PM >To: Salazar, Ruben; Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Ruben > >I think if you are in rural US (think Montana), I am not sure wireless >mesh network is going to have any advantages for coverage when compared to >cellular. >Regardless, I would propose that the suggested wording below is used to >replace the existing paragraph in this draft. > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). >In a multi-hop mesh network, each electric meter mesh may have up >toseveral thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > >Do you have any objections? > >Thanks > > > >-- >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 10:59 AM, "Salazar, Ruben" wrote: > >>All, >>The benefit of multi-hop networks is clear as it relates to geography >>coverage: that is why star topologies have some hidden repeat-route-relay >>features/mechanisms to extend coverage, which comes naturally with mesh >>topologies. And this statement applies to both wireless and wired >>networks. >>Regards >> >>Ruben Salazar >>Director Research and Technology >>Landis+Gyr >>Energy Management Solutions >>Office: +1 678 258 3165 >>Ruben.Salazar@landisgyr.com >>www.landisgyr.com >>manage energy better >> >> >>-----Original Message----- >>From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>Jetcheva, Jorjeta >>Sent: Wednesday, August 31, 2011 1:17 PM >>To: Akyol, Bora A >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hi Bora and all, >> >>There were some comments on the list related to adding text about the >>applicability of multi-hop vs. single-hop deployments. This paragraph >>attempted to distinguish between the two. Perhaps it is not necessary to >>motivate the existence/use of multi-hop networks because they are already >>the focus of the protocol development within this group. >> >>Does anyone else have any additional comments regarding including text >>about the benefits of multi-hop networks as compared to single-hop >>networks in the draft? >> >>Thanks, Jorjeta >> >>Jorjeta Jetcheva, Ph.D. >>Principal Engineer, Architecture & Standards >>CTO Office >>Itron, Inc. >> >> >>-----Original Message----- >>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>Sent: Wednesday, August 31, 2011 9:13 AM >>To: Jetcheva, Jorjeta >>Cc: D?jean Nicolas; roll@ietf.org >>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >> >>Hi again, >> >>My point is that this statement adds no value to the document and in my >>opinion subtracts value. >>The alternate wording I suggested is technical and avoids "markitecture" >>type statements. >> >>I meant powerline (as in Aclara TWACS or the newer technologies) which is >>essentially a single hop technology. >> >>I believe the cost effectiveness of a particular technology highly >>depends >>on the OPEX as well as the CAPEX, >>and customer density. I don't think we should take that on in an IETF >>document. >> >>Regards >> >> >>-- >>Bora Akyol, Pacific Northwest National Laboratory >>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >> >> >> >> >>On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" >>wrote: >> >>>Hello Bora, >>> >>>The text in this paragraph doesn't actually use the word "substantial", >>>and I think you meant "wireline", not "powerline". >>> >>>What would you consider to be a "substantiated" statement of the >>>applicability/benefits of mesh networks relative to other deployment >>>paradigms? >>> >>>Thanks, Jorjeta >>> >>>Jorjeta Jetcheva, Ph.D. >>>Principal Engineer, Architecture & Standards >>>CTO Office >>>Itron, Inc. >>> >>> >>>-----Original Message----- >>>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>>Sent: Wednesday, August 31, 2011 8:40 AM >>>To: Jetcheva, Jorjeta >>>Cc: D?jean Nicolas; roll@ietf.org >>>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>> >>>Hi Jorjeta >>> >>>Sorry, I had two comments in my original email. One was regarding >>>gas/power meters and the second regarding the non-technical slant in the >>>introduction. >>>The modified paragraph that I proposed is related to the second point. >>> >>>To answer your question, I disagree with the unbsubstantiated statement >>>that multi-hop wireless mesh networks have substantial cost benefits >>>compared to either powerline or single-hop (e.g. cellular modems) >>>networks. >>>I am not saying this is completely wrong, I am saying that this >>>statement >>>does not belong in an IETF document since it has no relevance to ROLL >>>or the applicability of ROLL to AMI networks. I think the paragraph I >>>proposed is clear-cut and technically accurate without having a bias >>>towards the use of wireless mesh networks. >>> >>>Regards >>> >>>Bora >>> >>>-----Original Message----- >>>From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >>>Sent: Wednesday, August 31, 2011 8:35 AM >>>To: Akyol, Bora A >>>Cc: D?jean Nicolas; roll@ietf.org >>>Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>>Hello Bora, >>> >>>The paragraph you cited does not reference anything related to water or >>>gas meters which was the topic of your earlier comment and the >>>discussion >>>that followed. Is this perhaps not the right paragraph or is this the >>>beginning of a new discussion? >>> >>>As far as the benefits of multi-hop networks over wireline or cellular >>>backhaul, I think that lower cost and deployment complexity are pretty >>>commonly cited. Do you disagree with this statement? >>> >>>Thanks, Jorjeta >>> >>>Jorjeta Jetcheva, Ph.D. >>>Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >>> >>> >>>-----Original Message----- >>>From: Akyol, Bora A [mailto:bora@pnnl.gov] >>>Sent: Wednesday, August 31, 2011 8:09 AM >>>To: Nicolas DEJEAN >>>Cc: Jetcheva, Jorjeta; roll@ietf.org >>>Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>> >>> >>>Hi Nicolas >>> >>>Yes, we had a private email exchange off-list. >>> >>>I would like to suggest alternate wording for this paragraph as follows: >>> >>>ORIGINAL: >>> >>> Electric meters are often interconnected into multi-hop mesh >>> networks, each of which is connected to a backhaul network leading to >>> the utility network through a network aggregation point (NAP). These >>> kinds of networks increase coverage and reduce installation cost, >>> time and complexity, as well as operational costs, as compared to >>> single-hop wireless networks, relying on a wireline or cellular >>> backhaul. Each electric meter mesh typically has on the order of >>> several thousand wireless endpoints, with densities varying based on >>> the area and the terrain. Apartment buildings in urban centers may >>> have hundreds of meters in close proximity, whereas rural areas may >>>have sparse node distributions and include nodes that only have one or >>>two network neighbors. Paths in the mesh between a network device >>> and the nearest aggregation point may be composed of several hops or >>> even tens of hops. >>> >>> >>>ALTERNATE WORDING: >>> >>> >>>In one type of AMI network, electric meters are interconnected into >>>multi-hop mesh >>>networks, each of which is connected to a backhaul network leading to >>>the utility network through a network aggregation point (NAP). >>> >>>>>mesh> >>> >>>In a multi-hop mesh network, each electric meter mesh may have up to >>>several thousand wireless endpoints, with densities varying based on >>>the area and the terrain. Apartment buildings in urban centers may >>>have hundreds of meters in close proximity, whereas rural areas may >>>have sparse node distributions and include nodes that only have one or >>>two >>>network neighbors. >>>Paths in the mesh between a network device >>>and the nearest aggregation point may be composed of several hops or >>>even tens of hops. >>> >>> >>> >>>What do you think? >>> >>>Thanks >>> >>> >>>-- >>>Bora Akyol, Pacific Northwest National Laboratory >>>+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>>On 8/31/11 4:23 AM, "Nicolas DEJEAN" >>> >>>wrote: >>> >>>>Hello Bora, >>>> >>>>Did Jorjeta answered your concerns about an AMI network considered as >>>>a backhaul for Gas and Water? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>2011/8/30 Jetcheva, Jorjeta : >>>>> Hello Bora, >>>>> >>>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>>> backhaul were considered out of scope. >>>>> >>>>> Actually AMI backhaul for gas and water meters is very much in scope >>>>>as >>>>>per the NIST Wireless Guidelines (PAP2) work and the related >>>>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>>>should be aware of this. >>>>> >>>>> Jorjeta >>>>> >>>>> Jorjeta Jetcheva, Ph.D. >>>>> Principal Engineer, Architecture & Standards >>>>> CTO Office >>>>> Itron, Inc. >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>>>>Of >>>>>Akyol, Bora A >>>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>>> To: Nicolas DEJEAN >>>>> Cc: roll@ietf.org >>>>> Subject: Re: [Roll] I-D Action: >>>>>draft-ietf-roll-applicability-ami-01.txt >>>>> >>>>> Hi Nicolas >>>>> >>>>> Thank you for your response. >>>>> >>>>> Please see my comments within >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> >>>>> >>>>> >>>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>>> >>>>> wrote: >>>>> >>>>>>Hello Bora, >>>>>> >>>>>>2011/7/29 Akyol, Bora A : >>>>>>> I think the statement about AMI networks being used as an almost >>>>>>>general >>>>>>> purpose backhaul network for all other devices >>>>>>> is overreaching. I know there are some utilities that are looking >>>>>>>into >>>>>>> this, but a lot more that have shied away from >>>>>>> this vision. Secondly, there are a lot more AMI deployments not >>>>>>>using >>>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>>> powerline carrier, etc. >>>>>> >>>>>>I agree that all utilities are not looking into it. >>>>>>However this is one possible case that should be considered, isn't >>>>>>it? >>>>>>Could you please precise what you are expecting to be in the draft? >>>>> >>>>> I think the draft should be focusing on the applicability of ROLL >>>>>from >>>>>a >>>>> technical front >>>>> without siting this one case as the only justification. >>>>> >>>>>> >>>>>>> >>>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>>>also >>>>>>> potentially >>>>>>> remove Gas & Water meters from the scope of this document. >>>>>>> >>>>>> >>>>>>On our point of view, Gas and Water metering are part of AMI. >>>>> >>>>> This is not the widely-held view at least within the US electric >>>>>utility >>>>> community. >>>>> The gas and water meters have capabilities which are quite different >>>>>from >>>>> electric power meters. >>>>> For example, while the electric meter has easy access to mains power, >>>>>the >>>>> gas/water meters don't. >>>>> In most instances, the gas/water service may be provided by a >>>>>completely >>>>> different entity than the electric >>>>> power utility. >>>>> >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>>> >>>>> Would the document lose technical integrity if the gas/water meter >>>>>were >>>>> either removed or included as an optional. >>>>> >>>>> Regards >>>>> >>>>> >>>>> >>>>>>Could you please elaborate? >>>>>>According to you, why should Gas and Water be removed from the draft? >>>>>> >>>>>>Thank you in advance, >>>>>> >>>>>>Nicolas. >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> -- >>>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 c.chauvenet@watteco.com Fri Sep 2 03:20:56 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4121F8F46 for ; Fri, 2 Sep 2011 03:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWhHDKi+-PM0 for ; Fri, 2 Sep 2011 03:20:56 -0700 (PDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id D381621F8F47 for ; Fri, 2 Sep 2011 03:20:51 -0700 (PDT) Received: from mail195-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Sep 2011 10:22:26 +0000 Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2-R.bigfish.com (Postfix) with ESMTP id 2834D19046F; Fri, 2 Sep 2011 10:22:26 +0000 (UTC) X-SpamScore: -23 X-BigFish: VPS-23(z1725nzc89bh1432N98dKzz1202hzz8275ch1033IL8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB001.red002.local; RD:none; EFVD:NLI Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2 (MessageSwitch) id 1314958944747578_8515; Fri, 2 Sep 2011 10:22:24 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.247]) by mail195-tx2.bigfish.com (Postfix) with ESMTP id A72AD10046; Fri, 2 Sep 2011 10:22:24 +0000 (UTC) Received: from IE2RD2HUB001.red002.local (213.199.187.153) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 2 Sep 2011 10:22:24 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB001.red002.local ([10.33.16.61]) with mapi; Fri, 2 Sep 2011 03:22:09 -0700 From: C Chauvenet To: "Angelo P. Castellani" Date: Fri, 2 Sep 2011 03:22:07 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxpWivWODIkUV7NTS6Q5qXQkL8MYA== Message-ID: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 10:20:56 -0000 Hi,=20 Because RPL is a Route-Over routing protocol, it is applicable to many diff= erent L1/L2, including the well-known 802.14.5 and their last improvements/= updates, PLC and many others ... Thus, I think we should avoid to bind RPL to some specifics L1/L2, or we wo= uld need to update RPL for each new L1/L2 created that aim to use RPL. C=E9dric. Le 1 sept. 2011 =E0 10:32, Angelo P. Castellani a =E9crit : > I slightly changed my mind about this +1. >=20 > Probably a good way to avoid this problem is to require the update of > the RPL packet format only for those mediums where the use of a > synthetic packet formats is a strong requirement (e.g. 802.15.4). >=20 > As detailed in , the conditions can be characterized in a more general > way, avoiding referencing single technologies in the standard: > "If the L2 medium does not support frames longer than X, than only the > synthetic packet format MUST be used." >=20 > In this way we avoid manual configuration and supporting both formats > in devices that target implementing this spec on very limited L2 > medium. >=20 > In other words, synthetic packet format should be a MUST for some > lower layer technologies characterized by some parameters (without > referencing specific technologies). >=20 > Best, > Angelo >=20 > On Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani > wrote: >> +1 >>=20 >> On Wed, Aug 31, 2011 at 23:46, Michael Richardson wro= te: >>>=20 >>>>>>>> "Thomas" =3D=3D Thomas Heide Clausen writ= es: >>> Thomas> I'd much like a routing protocol, designed for low-power, >>> Thomas> lossy networks and with low-MTU MACs as one of its >>> Thomas> design-target to be able to run over these networks. If >>> Thomas> _this_ early a need for an alternative, more compact, packet >>> Thomas> format is identified, then by all means let's get RPL >>> Thomas> updated to use that alternative, more compact, packet >>> Thomas> format. I have absolutely no problems with that. >>>=20 >>> +1 >>>=20 >>> _______________________________________________ >>> 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 >=20 From c.chauvenet@watteco.com Fri Sep 2 04:47:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDED21F8D63 for ; Fri, 2 Sep 2011 04:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4RmwYtg49Ue for ; Fri, 2 Sep 2011 04:47:12 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7060721F8D61 for ; Fri, 2 Sep 2011 04:47:11 -0700 (PDT) Received: from mail148-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Sep 2011 11:48:47 +0000 Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1-R.bigfish.com (Postfix) with ESMTP id 4AA6D1990524; Fri, 2 Sep 2011 11:48:47 +0000 (UTC) X-SpamScore: -38 X-BigFish: VPS-38(z1725nz9371Kc89bh1418M1432N98dK14ffOzz1202hzz1033ILc704dh8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1 (MessageSwitch) id 1314964126589329_2322; Fri, 2 Sep 2011 11:48:46 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail148-ch1.bigfish.com (Postfix) with ESMTP id 7DF76CF005B; Fri, 2 Sep 2011 11:48:46 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 2 Sep 2011 11:48:45 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Fri, 2 Sep 2011 04:48:24 -0700 From: C Chauvenet To: Thomas Heide Clausen Date: Fri, 2 Sep 2011 04:48:22 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxpZjhdyxR1N1F7Q32G5e1f0Z7Z9g== Message-ID: <76BFB7B0-5A9C-43D8-995F-44A39A41CE82@watteco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> In-Reply-To: <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 11:47:13 -0000 Hi all,=20 First, I think that we all agree that every bit saved in LLNs is a good thi= ng. That's why I definitely support the effort in defining a compression mechan= ism for RPL. I was quite amazed by the storm messages created by this good initiative, b= ut it seems that some messages were not fully related to the discussion Obj= ect. It is sad because it may have discourage people to dig into this interestin= g discussion. That's said, I don't see any problem for trying to design some improvements= for RPL. I think this rule is the same for every protocols. As already mentioned in this discussion, it's all about *optional* improvem= ents. Designing new mechanism like compression doesn't mean that you HAVE to impl= ement them. So I don't see why nodes won't interoperate if they all rely on the same R= PL RFC. Note that having a RFC speeds up implementations, as the protocols gets sta= ble, and indeed push interoperability forward. So I think that RPL becoming a RFC is a good thing, without preventing impr= ovements, nor further modifications. A lot of good work as been done in the 6loWPAN WG about compression, and I = think we may find a good amount of good materials looking back to their wor= k. I think that some of the concerns raised in this discussion may found some = answers in 6loWPAN HC early discussions. Best, C=E9dric. Le 31 ao=FBt 2011 =E0 19:25, Thomas Heide Clausen a =E9crit : >=20 > On Aug 31, 2011, at 18:39 , JP Vasseur wrote: >=20 >> Dear Thomas, >>=20 >> On Aug 31, 2011, at 5:54 PM, Thomas Heide Clausen wrote: >>=20 >>> I think that this is somewhat going to the crux of what I was referring= to when I suggested updates/obsoletes RPL in case this (or, any) compressi= on scheme is introduced. >>>=20 >>> As I understood the original design scope of ROLL, as retained in the c= harter, 802.15.4 was one of the (but, not the only) target L2's. It may be = that a less verbose message format is required for 802.15.4 than that curre= ntly proposed in RPL - in fact, we've got some indications from our testing= that this is the case (even for stock RPL) to avoid fragmentation. >>>=20 >>> However then the working group should fix the problem in RPL by updatin= g that specification, >>=20 >> Once again, there is no fix to have.=20 >=20 > I would submit that if when running RPL on 802.15.4 I manage to get fragm= ented RPL control packets, then there's something that should be fixed in a= protocol from a working group, which has 802.15.4 among its design targets= . >=20 > Daniel Popa said in his email that: >=20 >> Hi Emmanuel, Thomas, >>=20 >> One case where we do not necessarily need compression is the use of the = new IEEE 802.15.4 amendments, specifically designed for smart grids. 802.15= .4g is a PHY Layer for Smart Utility Networks and 802.15.4e, a new MAC sub-= layer that among others functionalities provide support for a 4g PHY layer.= For information, 4g PHY amendment mandates the support of IPv6 MTU. =20 >>=20 >> Regards, >> Daniel >=20 > It seems that Daniel indicates that there may be exceptional MACs where c= ompression isn't needed. But, it also seems that in the majority of the cas= es, it is needed and thus should be default. >=20 > Do note that my main point is, that "simple is good".=20 >=20 > As Michael has said repeatedly, having two different, incompatible, packe= t formats is extra overhead in coding and testing and isn't without complic= ations for extensibility etc.=20 >=20 > As Ulrich and Michael have pointed out, there are issues when running two= different and incompatible flavors of RPL (as would be the case if there w= ere two different packet format) in the same network. If such is prohibited= , then the WG has effectively created 4 different, non-interoperable protoc= ols as previously enumerated. >=20 > I'd much like a routing protocol, designed for low-power, lossy networks = and with low-MTU MACs as one of its design-target to be able to run over th= ese networks. If _this_ early a need for an alternative, more compact, pack= et format is identified, then by all means let's get RPL updated to use tha= t alternative, more compact, packet format. I have absolutely no problems w= ith that. >=20 > I do, however, think that it should be avoided adding yet another compone= nt of functionality and complexity to an already complex protocol. And, it = should be avoided to adding another set of non-interoperable modes-of-opera= tion rendering deployments more complex. >=20 > Respectfully yours, >=20 > Thomas >=20 >> Mukul is proposing an optional compression mechanism, currently discusse= d by the WG, that's it. >=20 >> Thanks. >>=20 >> JP. >>=20 >>> rather than propose an alternative, incompatible message format as an o= ption which - as Michael has pointed out in this and previous messages - ne= cessitating writing/testing multiple different parsers, additional signalin= g to ensure that in a given deployment messages are sent in the "right" for= mat (or, do we disallow heterogenous deployments?) etc. >>>=20 >>> I'm concerned that the WG, so early after (well, before) that RPL is pu= blished as RFC feels the need to consider such "patches" to the protocol. >>>=20 >>> Respectfully yours,=20 >>>=20 >>> Thomas >>>=20 >>> On Aug 31, 2011, at 15:38 , Michael Richardson wrote: >>>=20 >>>>=20 >>>>>>>>> "Mukul" =3D=3D Mukul Goyal writes: >>>> Mukul> I understand your preference for GHC scheme. As for our >>>> Mukul> scheme, it seems to me that you would like our scheme much >>>> Mukul> better if there is a way for a node to solicit >>>> Mukul> compressed/uncompressed DIOs. Is my understanding correct?=20 >>>> Mukul> This could be done by a simple DIS flag. >>>>=20 >>>> No, I wouldn't like that. I'd like not to have to write and test two >>>> parsers for options, and I'd like the scheme not to fall apart when we >>>> introduce another option type. >>>>=20 >>>> I will evaluate GHC method, and write a draft this long weekend with m= y >>>> results. If anyone has sample RPL messages they want me to consider,= =20 >>>> I would appreciate a PCAP file, otherwise, I'll evaluate only my own. >>>> In particular, I need more examples of metric options. >>>>=20 >>>>=20 >>>> --=20 >>>> ] He who is tired of Weird Al is tired of life! | fir= ewalls [ >>>> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net a= rchitect[ >>>> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |devic= e driver[ >>>> Kyoto Plus: watch the video >>>> then sign the petition.=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From c.chauvenet@watteco.com Fri Sep 2 05:00:05 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C721F8E9A for ; Fri, 2 Sep 2011 05:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.656 X-Spam-Level: X-Spam-Status: No, score=-5.656 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RewVTV0xekmc for ; Fri, 2 Sep 2011 05:00:04 -0700 (PDT) Received: from TX2EHSOBE008.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6801721F8E93 for ; Fri, 2 Sep 2011 05:00:04 -0700 (PDT) Received: from mail5-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Fri, 2 Sep 2011 12:01:40 +0000 Received: from mail5-tx2 (localhost.localdomain [127.0.0.1]) by mail5-tx2-R.bigfish.com (Postfix) with ESMTP id E041E15384F2; Fri, 2 Sep 2011 12:01:39 +0000 (UTC) X-SpamScore: -56 X-BigFish: VPS-56(zzbb2dK9371Kc89bh542M1dbaL1418M1432Nc540K98dK4015Lzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB017.red002.local; RD:none; EFVD:NLI Received: from mail5-tx2 (localhost.localdomain [127.0.0.1]) by mail5-tx2 (MessageSwitch) id 1314964852978298_12286; Fri, 2 Sep 2011 12:00:52 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.249]) by mail5-tx2.bigfish.com (Postfix) with ESMTP id 3C94813D8185; Fri, 2 Sep 2011 11:59:40 +0000 (UTC) Received: from IE2RD2HUB017.red002.local (213.199.187.153) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 2 Sep 2011 11:59:39 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB017.red002.local ([10.43.198.95]) with mapi; Fri, 2 Sep 2011 04:59:08 -0700 From: C Chauvenet To: "Akyol, Bora A" Date: Fri, 2 Sep 2011 04:59:06 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: AcxpZ7giIr4RpPGVReWiaSJ4CAwzfw== Message-ID: <7AE229F5-4E68-421D-8E6F-C7AB64CCFB9A@watteco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: D?jean Nicolas , "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 12:00:05 -0000 Hi,=20 Just a comment on PLC inline. Le 31 ao=FBt 2011 =E0 18:13, Akyol, Bora A a =E9crit : > Hi again, >=20 > My point is that this statement adds no value to the document and in my > opinion subtracts value. > The alternate wording I suggested is technical and avoids "markitecture" > type statements. >=20 > I meant powerline (as in Aclara TWACS or the newer technologies) which is > essentially a single hop technology. I don't really agree with that. PLC (PowerLine Communication) cannot be generally considered as a single ho= p technology. It would be great if, like ethernet, everyone on the same wire could commun= icate with each other but reality tells us that it is not often the case. Of course, this may greatly depends on the technology you are considering, = but regarding those targeted for AMI purpose, I think it is a little bit op= timistic to state that most of PLC meter will be in the same neighborhood (= i.e one hop away). >=20 > I believe the cost effectiveness of a particular technology highly depend= s > on the OPEX as well as the CAPEX, > and customer density. I don't think we should take that on in an IETF > document. >=20 > Regards >=20 >=20 > -- > Bora Akyol, Pacific Northwest National Laboratory > +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >=20 >=20 Just a comment, C=E9dric. >=20 >=20 > On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrot= e: >=20 >> Hello Bora, >>=20 >> The text in this paragraph doesn't actually use the word "substantial", >> and I think you meant "wireline", not "powerline". >>=20 >> What would you consider to be a "substantiated" statement of the >> applicability/benefits of mesh networks relative to other deployment >> paradigms? >>=20 >> Thanks, Jorjeta >>=20 >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards >> CTO Office >> Itron, Inc. >>=20 >>=20 >> -----Original Message----- >> From: Akyol, Bora A [mailto:bora@pnnl.gov] >> Sent: Wednesday, August 31, 2011 8:40 AM >> To: Jetcheva, Jorjeta >> Cc: D?jean Nicolas; roll@ietf.org >> Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>=20 >>=20 >> Hi Jorjeta >>=20 >> Sorry, I had two comments in my original email. One was regarding >> gas/power meters and the second regarding the non-technical slant in the >> introduction. >> The modified paragraph that I proposed is related to the second point. >>=20 >> To answer your question, I disagree with the unbsubstantiated statement >> that multi-hop wireless mesh networks have substantial cost benefits >> compared to either powerline or single-hop (e.g. cellular modems) >> networks. >> I am not saying this is completely wrong, I am saying that this statemen= t >> does not belong in an IETF document since it has no relevance to ROLL >> or the applicability of ROLL to AMI networks. I think the paragraph I >> proposed is clear-cut and technically accurate without having a bias >> towards the use of wireless mesh networks. >>=20 >> Regards >>=20 >> Bora >>=20 >> -----Original Message----- >> From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >> Sent: Wednesday, August 31, 2011 8:35 AM >> To: Akyol, Bora A >> Cc: D?jean Nicolas; roll@ietf.org >> Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>=20 >> Hello Bora, >>=20 >> The paragraph you cited does not reference anything related to water or >> gas meters which was the topic of your earlier comment and the discussio= n >> that followed. Is this perhaps not the right paragraph or is this the >> beginning of a new discussion? >>=20 >> As far as the benefits of multi-hop networks over wireline or cellular >> backhaul, I think that lower cost and deployment complexity are pretty >> commonly cited. Do you disagree with this statement? >>=20 >> Thanks, Jorjeta >>=20 >> Jorjeta Jetcheva, Ph.D. >> Principal Engineer, Architecture & Standards CTO Office Itron, Inc. >>=20 >>=20 >> -----Original Message----- >> From: Akyol, Bora A [mailto:bora@pnnl.gov] >> Sent: Wednesday, August 31, 2011 8:09 AM >> To: Nicolas DEJEAN >> Cc: Jetcheva, Jorjeta; roll@ietf.org >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt >>=20 >>=20 >> Hi Nicolas >>=20 >> Yes, we had a private email exchange off-list. >>=20 >> I would like to suggest alternate wording for this paragraph as follows: >>=20 >> ORIGINAL: >>=20 >> Electric meters are often interconnected into multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). These >> kinds of networks increase coverage and reduce installation cost, >> time and complexity, as well as operational costs, as compared to >> single-hop wireless networks, relying on a wireline or cellular >> backhaul. Each electric meter mesh typically has on the order of >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >> have sparse node distributions and include nodes that only have one or >> two network neighbors. Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >>=20 >>=20 >> ALTERNATE WORDING: >>=20 >>=20 >> In one type of AMI network, electric meters are interconnected into >> multi-hop mesh >> networks, each of which is connected to a backhaul network leading to >> the utility network through a network aggregation point (NAP). >>=20 >> > mesh> >>=20 >> In a multi-hop mesh network, each electric meter mesh may have up to >> several thousand wireless endpoints, with densities varying based on >> the area and the terrain. Apartment buildings in urban centers may >> have hundreds of meters in close proximity, whereas rural areas may >> have sparse node distributions and include nodes that only have one or t= wo >> network neighbors. >> Paths in the mesh between a network device >> and the nearest aggregation point may be composed of several hops or >> even tens of hops. >>=20 >>=20 >>=20 >> What do you think? >>=20 >> Thanks >>=20 >>=20 >> -- >> Bora Akyol, Pacific Northwest National Laboratory >> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>=20 >>=20 >>=20 >>=20 >> On 8/31/11 4:23 AM, "Nicolas DEJEAN" >> wrote: >>=20 >>> Hello Bora, >>>=20 >>> Did Jorjeta answered your concerns about an AMI network considered as >>> a backhaul for Gas and Water? >>>=20 >>> Thank you in advance, >>>=20 >>> Nicolas. >>>=20 >>> 2011/8/30 Jetcheva, Jorjeta : >>>> Hello Bora, >>>>=20 >>>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>>> backhaul were considered out of scope. >>>>=20 >>>> Actually AMI backhaul for gas and water meters is very much in scope a= s >>>> per the NIST Wireless Guidelines (PAP2) work and the related >>>> SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>> should be aware of this. >>>>=20 >>>> Jorjeta >>>>=20 >>>> Jorjeta Jetcheva, Ph.D. >>>> Principal Engineer, Architecture & Standards >>>> CTO Office >>>> Itron, Inc. >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf O= f >>>> Akyol, Bora A >>>> Sent: Tuesday, August 30, 2011 10:37 AM >>>> To: Nicolas DEJEAN >>>> Cc: roll@ietf.org >>>> Subject: Re: [Roll] I-D Action: >>>> draft-ietf-roll-applicability-ami-01.txt >>>>=20 >>>> Hi Nicolas >>>>=20 >>>> Thank you for your response. >>>>=20 >>>> Please see my comments within >>>> -- >>>> Bora Akyol, Pacific Northwest National Laboratory >>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>>> >>>> wrote: >>>>=20 >>>>> Hello Bora, >>>>>=20 >>>>> 2011/7/29 Akyol, Bora A : >>>>>> I think the statement about AMI networks being used as an almost >>>>>> general >>>>>> purpose backhaul network for all other devices >>>>>> is overreaching. I know there are some utilities that are looking >>>>>> into >>>>>> this, but a lot more that have shied away from >>>>>> this vision. Secondly, there are a lot more AMI deployments not usin= g >>>>>> wireless mesh networks, e.g. using cellular modem, >>>>>> powerline carrier, etc. >>>>>=20 >>>>> I agree that all utilities are not looking into it. >>>>> However this is one possible case that should be considered, isn't it= ? >>>>> Could you please precise what you are expecting to be in the draft? >>>>=20 >>>> I think the draft should be focusing on the applicability of ROLL from >>>> a >>>> technical front >>>> without siting this one case as the only justification. >>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>> also >>>>>> potentially >>>>>> remove Gas & Water meters from the scope of this document. >>>>>>=20 >>>>>=20 >>>>> On our point of view, Gas and Water metering are part of AMI. >>>>=20 >>>> This is not the widely-held view at least within the US electric >>>> utility >>>> community. >>>> The gas and water meters have capabilities which are quite different >>>> from >>>> electric power meters. >>>> For example, while the electric meter has easy access to mains power, >>>> the >>>> gas/water meters don't. >>>> In most instances, the gas/water service may be provided by a >>>> completely >>>> different entity than the electric >>>> power utility. >>>>=20 >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>>>=20 >>>> Would the document lose technical integrity if the gas/water meter wer= e >>>> either removed or included as an optional. >>>>=20 >>>> Regards >>>>=20 >>>>=20 >>>>=20 >>>>> Could you please elaborate? >>>>> According to you, why should Gas and Water be removed from the draft? >>>>>=20 >>>>> Thank you in advance, >>>>>=20 >>>>> Nicolas. >>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>> -- >>>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Jorjeta.Jetcheva@itron.com Fri Sep 2 05:00:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70F221F8E9C for ; Fri, 2 Sep 2011 05:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aWEk+G-2C+9 for ; Fri, 2 Sep 2011 05:00:34 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB9921F8E93 for ; Fri, 2 Sep 2011 05:00:29 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Fri, 2 Sep 2011 05:02:04 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Fri, 2 Sep 2011 05:02:00 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Thread-Index: Acxn+N7nNlDzn16jT/a4Vz4B6K8W6wABlihAAFob3OA= Message-ID: <0368F388C03BB34BBBFA73209849D47A4CD69271@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4CC5A0AD@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4CCB9745@ITR-EXMBXVS-2.itron.com> 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: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 12:00:35 -0000 Hi all, There don't seem to be objections to removing the text about the benefits o= f multi-hop networks from the applicability draft, so we will remove it as = requested. Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jet= cheva, Jorjeta Sent: Wednesday, August 31, 2011 10:17 AM To: Akyol, Bora A Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi Bora and all, There were some comments on the list related to adding text about the appli= cability of multi-hop vs. single-hop deployments. This paragraph attempted= to distinguish between the two. Perhaps it is not necessary to motivate t= he existence/use of multi-hop networks because they are already the focus o= f the protocol development within this group. Does anyone else have any additional comments regarding including text abou= t the benefits of multi-hop networks as compared to single-hop networks in = the draft?=20 Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Principal Engineer, Architecture & Standards CTO Office Itron, Inc. -----Original Message----- From: Akyol, Bora A [mailto:bora@pnnl.gov]=20 Sent: Wednesday, August 31, 2011 9:13 AM To: Jetcheva, Jorjeta Cc: D?jean Nicolas; roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt Hi again, My point is that this statement adds no value to the document and in my opinion subtracts value. The alternate wording I suggested is technical and avoids "markitecture" type statements. I meant powerline (as in Aclara TWACS or the newer technologies) which is essentially a single hop technology. I believe the cost effectiveness of a particular technology highly depends on the OPEX as well as the CAPEX, and customer density. I don't think we should take that on in an IETF document. Regards --=20 Bora Akyol, Pacific Northwest National Laboratory +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov On 8/31/11 9:05 AM, "Jetcheva, Jorjeta" wrote: >Hello Bora, > >The text in this paragraph doesn't actually use the word "substantial", >and I think you meant "wireline", not "powerline". > >What would you consider to be a "substantiated" statement of the >applicability/benefits of mesh networks relative to other deployment >paradigms? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards >CTO Office >Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:40 AM >To: Jetcheva, Jorjeta >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Jorjeta > >Sorry, I had two comments in my original email. One was regarding >gas/power meters and the second regarding the non-technical slant in the >introduction. >The modified paragraph that I proposed is related to the second point. > >To answer your question, I disagree with the unbsubstantiated statement >that multi-hop wireless mesh networks have substantial cost benefits >compared to either powerline or single-hop (e.g. cellular modems) >networks.=20 >I am not saying this is completely wrong, I am saying that this statement >does not belong in an IETF document since it has no relevance to ROLL >or the applicability of ROLL to AMI networks. I think the paragraph I >proposed is clear-cut and technically accurate without having a bias >towards the use of wireless mesh networks. > >Regards > >Bora > >-----Original Message----- >From: Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] >Sent: Wednesday, August 31, 2011 8:35 AM >To: Akyol, Bora A >Cc: D?jean Nicolas; roll@ietf.org >Subject: RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > >Hello Bora, > >The paragraph you cited does not reference anything related to water or >gas meters which was the topic of your earlier comment and the discussion >that followed. Is this perhaps not the right paragraph or is this the >beginning of a new discussion? > >As far as the benefits of multi-hop networks over wireline or cellular >backhaul, I think that lower cost and deployment complexity are pretty >commonly cited. Do you disagree with this statement? > >Thanks, Jorjeta > >Jorjeta Jetcheva, Ph.D. >Principal Engineer, Architecture & Standards CTO Office Itron, Inc. > > >-----Original Message----- >From: Akyol, Bora A [mailto:bora@pnnl.gov] >Sent: Wednesday, August 31, 2011 8:09 AM >To: Nicolas DEJEAN >Cc: Jetcheva, Jorjeta; roll@ietf.org >Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-01.txt > > >Hi Nicolas > >Yes, we had a private email exchange off-list. > >I would like to suggest alternate wording for this paragraph as follows: > >ORIGINAL: > > Electric meters are often interconnected into multi-hop mesh > networks, each of which is connected to a backhaul network leading to > the utility network through a network aggregation point (NAP). These > kinds of networks increase coverage and reduce installation cost, > time and complexity, as well as operational costs, as compared to > single-hop wireless networks, relying on a wireline or cellular > backhaul. Each electric meter mesh typically has on the order of > several thousand wireless endpoints, with densities varying based on > the area and the terrain. Apartment buildings in urban centers may > have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or >two network neighbors. Paths in the mesh between a network device > and the nearest aggregation point may be composed of several hops or > even tens of hops. > > >ALTERNATE WORDING: > > >In one type of AMI network, electric meters are interconnected into >multi-hop mesh >networks, each of which is connected to a backhaul network leading to >the utility network through a network aggregation point (NAP). > >mesh> > >In a multi-hop mesh network, each electric meter mesh may have up to >several thousand wireless endpoints, with densities varying based on >the area and the terrain. Apartment buildings in urban centers may >have hundreds of meters in close proximity, whereas rural areas may >have sparse node distributions and include nodes that only have one or two >network neighbors. >Paths in the mesh between a network device >and the nearest aggregation point may be composed of several hops or >even tens of hops. > > > >What do you think? > >Thanks > > >--=20 >Bora Akyol, Pacific Northwest National Laboratory >+1 509 371 6682, bora@pnnl.gov, www.pnnl.gov > > > > >On 8/31/11 4:23 AM, "Nicolas DEJEAN" >wrote: > >>Hello Bora, >> >>Did Jorjeta answered your concerns about an AMI network considered as >>a backhaul for Gas and Water? >> >>Thank you in advance, >> >>Nicolas. >> >>2011/8/30 Jetcheva, Jorjeta : >>> Hello Bora, >>> >>>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>>> backhaul were considered out of scope. >>> >>> Actually AMI backhaul for gas and water meters is very much in scope as >>>per the NIST Wireless Guidelines (PAP2) work and the related >>>SG-Communications/SG-Net work. CSWG coordinates with the PAPs so they >>>should be aware of this. >>> >>> Jorjeta >>> >>> Jorjeta Jetcheva, Ph.D. >>> Principal Engineer, Architecture & Standards >>> CTO Office >>> Itron, Inc. >>> >>> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >>>Akyol, Bora A >>> Sent: Tuesday, August 30, 2011 10:37 AM >>> To: Nicolas DEJEAN >>> Cc: roll@ietf.org >>> Subject: Re: [Roll] I-D Action: >>>draft-ietf-roll-applicability-ami-01.txt >>> >>> Hi Nicolas >>> >>> Thank you for your response. >>> >>> Please see my comments within >>> -- >>> Bora Akyol, Pacific Northwest National Laboratory >>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>> >>> >>> >>> >>> On 8/30/11 1:25 AM, "Nicolas DEJEAN" >>> >>> wrote: >>> >>>>Hello Bora, >>>> >>>>2011/7/29 Akyol, Bora A : >>>>> I think the statement about AMI networks being used as an almost >>>>>general >>>>> purpose backhaul network for all other devices >>>>> is overreaching. I know there are some utilities that are looking >>>>>into >>>>> this, but a lot more that have shied away from >>>>> this vision. Secondly, there are a lot more AMI deployments not using >>>>> wireless mesh networks, e.g. using cellular modem, >>>>> powerline carrier, etc. >>>> >>>>I agree that all utilities are not looking into it. >>>>However this is one possible case that should be considered, isn't it? >>>>Could you please precise what you are expecting to be in the draft? >>> >>> I think the draft should be focusing on the applicability of ROLL from >>>a >>> technical front >>> without siting this one case as the only justification. >>> >>>> >>>>> >>>>> Is it possible to tone this "marketing" text Section 1.1. down and >>>>>also >>>>> potentially >>>>> remove Gas & Water meters from the scope of this document. >>>>> >>>> >>>>On our point of view, Gas and Water metering are part of AMI. >>> >>> This is not the widely-held view at least within the US electric >>>utility >>> community. >>> The gas and water meters have capabilities which are quite different >>>from >>> electric power meters. >>> For example, while the electric meter has easy access to mains power, >>>the >>> gas/water meters don't. >>> In most instances, the gas/water service may be provided by a >>>completely >>> different entity than the electric >>> power utility. >>> >>> At least within the US NIST SGIP CSWG, the gas/water meters and AMI >>> backhaul were considered out of scope. >>> >>> Would the document lose technical integrity if the gas/water meter were >>> either removed or included as an optional. >>> >>> Regards >>> >>> >>> >>>>Could you please elaborate? >>>>According to you, why should Gas and Water be removed from the draft? >>>> >>>>Thank you in advance, >>>> >>>>Nicolas. >>>> >>>>> Regards >>>>> >>>>> -- >>>>> Bora Akyol, Pacific Northwest National Laboratory >>>>> +1 509 371 6682, bora@pnnl.gov, www.pnnl.gov >>>>> >>>>> _______________________________________________ >>>>> 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 angelo.castellani@gmail.com Fri Sep 2 07:07:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7635721F8B35 for ; Fri, 2 Sep 2011 07:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xWDnAtMC392 for ; Fri, 2 Sep 2011 07:07:34 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5324021F8B06 for ; Fri, 2 Sep 2011 07:07:34 -0700 (PDT) Received: by wyg8 with SMTP id 8so2640105wyg.31 for ; Fri, 02 Sep 2011 07:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=CJQ6rjNxm0BJsmEc+8tqBP5ci0iA3TqlnLap7uTzpXA=; b=o3UGAngSKDBymbt0xE9R5YY+bDtmcLsgjamsgbZkWDyy8iUbn60IsrX+ToUiheUSHD mrbely7/gWmfnbdQ2r7wmB6lIo3zV74IeWoSzhGkKMA031nx5jowEs4O8Emv/vaJACE0 FclHJBQsaVg1rC++nKVAUl1cE/D71uzO2nIOA= Received: by 10.216.210.231 with SMTP id u81mr1450934weo.6.1314972549703; Fri, 02 Sep 2011 07:09:09 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Fri, 2 Sep 2011 07:08:49 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0565D17A@XMB-AMS-107.cisco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <7748.1314884694@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D055AE57F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0565D17A@XMB-AMS-107.cisco.com> From: "Angelo P. Castellani" Date: Fri, 2 Sep 2011 16:08:49 +0200 X-Google-Sender-Auth: iqtKB6kS5FBRdJFizEx2vt4P63I Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:07:35 -0000 > And we have kept reserved fields. They are set to 0 and easy to > compress, and at the same time the protocol is open to future > extensions. Do you believe that avoiding having defaults, bit-flagged header parsing and in-line fields is useful for some implementations? It's not that complex to be handled and typically is handled successfully in very constrained devices (see 6lowpan implementations). I still don't get why: a) having lots 0s in some implementations and the optional requirement for a separate generic compression layer. b) or in some implementation with strict power constraints, the requirement for a separate (!!) RPL adaptation layer could simplify, in general, RPL systems. > Still, we have refrained to optimize for one specific type of LLN; as > you know, LP 802.11 and recent variations of 802.15.4 support IPv6 min > MTU. > [...] > Many sorts of them actually. In one extreme there can be a really > optimized adaption layer for each type of LLN and for each given > protocol in which case it probably makes sense to leave the work to the > IPv6-over-foo WG. GHC is the other end of that spectrum, where we can > get a reasonable benefit independent of the MAC and for all sorts of > packets. I want to clarify better my point: I am NOT advocating to have an optimization for a specific LL. I will prefer having in RPL something like the following text: <> In this way we are not bounded to a specific link layer > Yes, that's the discussion I had hoped we'd have with this thread, and > the reason why I support this work. I support this work too, as long as we are not introducing the added complexity of handling both formats for interoperability. I would prefer that given a link layer technology having some high-level characteristics, only one message format is permitted. > You'll note that GHC reuses the > 6LoWPAN context and can probably compress efficiently the costly target > and transit options, as well as the routing header. Definitely, reusing context information (if possible) is a very good approach. > My own take is that it is a good start for us, and that we should study > its applicability and then figure if/where more specific macros > can/need-to be applied. Sure, let's discuss about this. Best, Angelo From angelo.castellani@gmail.com Fri Sep 2 07:30:42 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9889521F8B38 for ; Fri, 2 Sep 2011 07:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeaS13+DgtqM for ; Fri, 2 Sep 2011 07:30:42 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFE4421F8B21 for ; Fri, 2 Sep 2011 07:30:41 -0700 (PDT) Received: by wyg8 with SMTP id 8so2659444wyg.31 for ; Fri, 02 Sep 2011 07:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=amrAn+jgQIeyDkVJ3Tijw6L+NDry1zyJa4hO3Xzh9MA=; b=SzXJKDmfz7u7y25lLbao781h2CcPLpOVY4OC83749Q92ljIK+Y9DQzqRPdyNWmMTEG 92ThAv9e40Uwbo5aXZFbXo5rwOum29/ULwapB2pL8SqdvD2WXZI5qjQYq7wUP1/1D49x V7+rICIlaogrz5P89+bXys8qxDdHmQsUNayqY= Received: by 10.216.20.5 with SMTP id o5mr1096240weo.51.1314973937185; Fri, 02 Sep 2011 07:32:17 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Fri, 2 Sep 2011 07:31:56 -0700 (PDT) In-Reply-To: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> From: "Angelo P. Castellani" Date: Fri, 2 Sep 2011 16:31:56 +0200 X-Google-Sender-Auth: d1D5GxNYcJ7sdR68Why86pGmUPc Message-ID: To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:30:42 -0000 Hi, On Fri, Sep 2, 2011 at 12:22, C Chauvenet wrote: > Because RPL is a Route-Over routing protocol, it is applicable to many di= fferent L1/L2, including the well-known 802.14.5 and their last improvement= s/updates, PLC =A0and many others ... > > Thus, I think we should avoid to bind RPL to some specifics L1/L2, or we = would need to update RPL for each new L1/L2 created that aim to use RPL. Sure! As clarified in the previous message, I am NOT telling to bind RPL to a specific LL. I believe that given a specific LL, message format to be used on it should be a MUST and not an implementation decision. The format to be used on a specific link layer should be identified using some high-level characteristics of the link-layer itself (i.e. MAX_FRAME_SIZE): in this way we will not bind to any specific LL. The main advantage of this is that no confusion will exist about which message format to use on any link-layer, and any implementation will interoperate with each without requiring that nodes (at least some) support both formats. Best, Angelo From ietfroll@yahoo.com Fri Sep 2 23:36:47 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13321F8B71 for ; Fri, 2 Sep 2011 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-nDWIk0pcH8 for ; Fri, 2 Sep 2011 23:36:46 -0700 (PDT) Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 757E621F8B61 for ; Fri, 2 Sep 2011 23:36:46 -0700 (PDT) Received: from [98.139.91.66] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:38:21 -0000 Received: from [98.139.91.27] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:38:21 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:38:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 520415.31127.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 18509 invoked by uid 60001); 3 Sep 2011 06:38:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315031901; bh=AOrS/gAOgq7rq+0Bnl45I17wZyzjmJwqeSge6KDPot8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tU4qRKjE8rZNUL3Hi0v1wuypNqdiPkKi2Fn/UbVbv2o7D6UJNluS6u/3AY0bN6CS/8Hakov7mJqYYBobGczI97rG7Gf4ZU7OJZC+FBUwvlKtIhooYu3zZiQhjBuy101OI9LF4fwAQKbcqhJI+PxraWMjWi6hS5DYrJUMxZC9Z44= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RDTwWu/dS9ga0gcsRMo9f0nWFpBO5ZQ4ltP4N3dSHcFaubS5AORy20DZsn3VgznFHjWdxabXFAx0vR13z9zy15u+tp3hmkpI/LECc0jaaDadapOwQImezV/M9F7g+uReT8/a3F14f7rLZ8+kc+o0KCKHWOCisSLnGuQiZQAO1S0=; X-YMail-OSG: HpjqXKsVM1ncKAmE3KQGPd7pWpGCOcPRuPMpXUTrL2tOEe9 GAJczWxzSLUCzQkO48Q6qeXRwPbXTaTBJGGr8z9eD0Wzt.553OCt_i15ybkZ g9kgyruAHzT2sA2nl1cgeG6Ox8cSjy2yMx6oqlqvisUKa7PBPqmOtzMU3FAR uPgtjlmmOgdoE_7N5c_g8jrJB_6Yr6_AXL8MmvcKpTevHOoBXg3gOEtOSJl2 z_Y0ewrxY5cDpz6k1DgsraEXmymjwt4kWBRu73gclyTFPGNCAq3eKozgQbHx 8jKvLKrTpOWaacVQjugZrBihwh35YJAE.77FS9ni_vRT4xSKH.C53zE21XaG 7QMXC3ezOwYFuhht_RiV6bvZ82DC896EUZu1kTC.A Received: from [77.247.181.163] by web113920.mail.gq1.yahoo.com via HTTP; Fri, 02 Sep 2011 23:38:20 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <76BFB7B0-5A9C-43D8-995F-44A39A41CE82@watteco.com> Message-ID: <1315031900.16281.YahooMailNeo@web113920.mail.gq1.yahoo.com> Date: Fri, 2 Sep 2011 23:38:20 -0700 (PDT) From: Ietf Roll To: C Chauvenet , Thomas Heide Clausen In-Reply-To: <76BFB7B0-5A9C-43D8-995F-44A39A41CE82@watteco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-625931554-1315031900=:16281" Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ietf Roll List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 06:36:47 -0000 --0-625931554-1315031900=:16281 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0ACedric wrote:=0A=0AThat's said, I don't see any problem for trying to= design some improvements for RPL.=0AI think this rule is the same for ever= y protocols.=0A=0A[rav] Yes and RPL certainly needs improvements. :-)=A0 An= d compressing out a bunch of unused bits would be a good improvement.=0A=0A= As already mentioned in this discussion, it's all about *optional* improvem= ents.=0ADesigning new mechanism like compression doesn't mean that you HAVE= to implement them.=0ASo I don't=A0 see why nodes won't interoperate if the= y all rely on the same RPL RFC.=0A=0A[rav] Yes you are correct that nodes c= an interoperate if they all adhere to the same RFC (or in RPLs case - lots = of RFCs already - and more if you want to do P2P and more if you want to to= do non-storing mode, but I digress).=0A=A0=A0=A0=A0=A0=A0=A0=A0 We are tal= king about a change to the core specification that will cause interoperabil= ity problems from the outset.=A0 If I rely on the uncompressed spec RFC (oh= wait, it isn't an RFC yet) I can't speak to you if you rely on this new co= mpression=0A=A0=A0=A0=A0=A0=A0=A0=A0 scheme.=A0 If we decide to go forward = this this, then we have to have some way to negotiate between nodes to say = if you are or are not using compression (oops another I-D). OR everyone has= to implement both which goes against the notion=0A=A0 =A0 =A0 =A0=A0 that = we are designing constrained nodes.=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 If this c= ompression is a good idea, then let's make it part of the core spec, get ri= d of the extra wasted bits and try to make RPL useful on constrained nodes.= =A0 This draft, if it is adopted by the WG, should deprecate the RPL core s= pec and fix it.=0A=0Arav=0A --0-625931554-1315031900=:16281 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Cedric wrote:

That's said, I don't see any problem for trying t= o design some improvements for RPL.
I think this rule is the same for ev= ery protocols.

[rav] Yes and RPL certainly needs improvements. :-)&n= bsp; And compressing out a bunch of unused bits would be a good improvement= .

As already mentioned in this discussion, it's all about *optional*= improvements.
Designing new mechanism like compression doesn't mean tha= t you HAVE to implement them.
So I don't  see why nodes won't inter= operate if they all rely on the same RPL RFC.

[rav] Yes you are corr= ect that nodes can interoperate if they all adhere to the same RFC (or in RPLs case - lots of RFCs already - and more if you want to do P2P and more= if you want to to do non-storing mode, but I digress).
  &nbs= p;      We are talking about a change to the core = specification that will cause interoperability problems from the outset.&nb= sp; If I rely on the uncompressed spec RFC (oh wait, it isn't an RFC yet) I= can't speak to you if you rely on this new compression
  &nbs= p;      scheme.  If we decide to go forward t= his this, then we have to have some way to negotiate between nodes to say i= f you are or are not using compression (oops another I-D). OR everyone has = to implement both which goes against the notion
      &nb= sp;  that we are designing constrained nodes.

   = ;      If this compression is a good idea, then le= t's make it part of the core spec, get rid of the extra wasted bits and try to make RPL useful on constrained nodes.  This draft, if it i= s adopted by the WG, should deprecate the RPL core spec and fix it.

= rav
--0-625931554-1315031900=:16281-- From ietfroll@yahoo.com Fri Sep 2 23:40:37 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380EE21F8C21 for ; Fri, 2 Sep 2011 23:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA8liTQOVpJb for ; Fri, 2 Sep 2011 23:40:36 -0700 (PDT) Received: from nm12-vm0.bullet.mail.sp2.yahoo.com (nm12-vm0.bullet.mail.sp2.yahoo.com [98.139.91.242]) by ietfa.amsl.com (Postfix) with SMTP id 3FE2F21F8B8E for ; Fri, 2 Sep 2011 23:40:36 -0700 (PDT) Received: from [98.139.91.70] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:42:09 -0000 Received: from [98.139.91.7] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:42:09 -0000 Received: from [127.0.0.1] by omp1007.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 06:42:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 658309.26741.bm@omp1007.mail.sp2.yahoo.com Received: (qmail 17544 invoked by uid 60001); 3 Sep 2011 06:42:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315032129; bh=xYB2U1sL5D4MUdvDdD5Zqk55ihIfi2uyU8jhaFkDiCc=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VkvvsSCJZpqdt7VBU/Cr1z0kINZl6rYnpreuCfPd0Fx3U8tzNHYBWAMtNPFRklGRXcLotmFYwJmP1R5uHrdyam8eINFsroNFMey5yFA4+ZzRWcIF971+JOUzCT1KCdTTbIkx7+FiK69EiSPXgwCM/mSwBO+2qjbeXRnaGxzv0sA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=v6LNvjfqk6kR1Bma/H1U0JNY2grzKkVK4OmB7auWc6e9xYTpQjpCvOlMuyaz1J8dN5sdHcqGbMb9i9xM7b33Cqz99hT71yNlkep9xEX+C+jfDYcE3oM26UkmyAj2/hIv84hfF46UgLKgjCfa+X5WN8GZIU9iBG6ktIIO0vTybIo=; X-YMail-OSG: gbhe0T0VM1moIuoLs.XltsNx6..5Jh1pYh3aCIrEXc5BOHt md1UCMfWDPM7RwmAH1YuKK9BAVIt6in.A_BNiPSrPRqf1iKTemDxLYjehArE aBWTB1CahOss43FbUGVZa.H6p_v5NSj9UMlPCuXOVwChu5GaNCdvPTloddSG spIUlK8guYJI5HznibHxHLMqHhu7M69qWyj2iMr8H28yCT_xjTRnUFtx60Tz al7YvAQoIGUTgRPjA_imrhqmwX29tD20P3YE08ocdPnypZOrTbH3GakUFgG_ E5EK8IJ9A18Utki6Dwe20kOPbhN7xbcwNjAof089j9Z4QK13r_ZrBxsZlr1G ofxh.BiJluaH7c1h1nGN.nGsJbD8GzfPujvf02WBN Received: from [77.247.181.163] by web113913.mail.gq1.yahoo.com via HTTP; Fri, 02 Sep 2011 23:42:09 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> Message-ID: <1315032129.8272.YahooMailNeo@web113913.mail.gq1.yahoo.com> Date: Fri, 2 Sep 2011 23:42:09 -0700 (PDT) From: Ietf Roll To: C Chauvenet , "Angelo P. Castellani" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-646403744-1315032129=:8272" Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ietf Roll List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 06:40:37 -0000 --0-646403744-1315032129=:8272 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable No one is talking about (or should not be talking about binding rpl to any = specific l1/l2, but we are talking about compressing bits and that is usefu= l on ANY l1/l2 - 802.15.4, 802.15.4g, 802.11LP and PLC.=A0 Less bits sent m= eans less time on air, less contention, less power, less less less.=A0 So l= et's attempt to fix RPL now and get rid of the packet bloat.=0A=0Arav=0A=0A= =0A=0A________________________________=0AFrom: C Chauvenet =0ATo: Angelo P. Castellani =0ACc: roll WG = =0ASent: Friday, September 2, 2011 4:22 AM=0ASubject: Re: [R= oll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document= =0A=0AHi, =0A=0ABecause RPL is a Route-Over routing protocol, it is applica= ble to many different L1/L2, including the well-known 802.14.5 and their la= st improvements/updates, PLC=A0 and many others ...=0A=0AThus, I think we s= hould avoid to bind RPL to some specifics L1/L2, or we would need to update= RPL for each new L1/L2 created that aim to use RPL.=0A=0AC=E9dric.=0A=0ALe= 1 sept. 2011 =E0 10:32, Angelo P. Castellani a =E9crit :=0A=0A> I slightly= changed my mind about this +1.=0A> =0A> Probably a good way to avoid this = problem is to require the update of=0A> the RPL packet format only for thos= e mediums where the use of a=0A> synthetic packet formats is a strong requi= rement (e.g. 802.15.4).=0A> =0A> As detailed in , the conditions can be cha= racterized in a more general=0A> way, avoiding referencing single technolog= ies in the standard:=0A> "If the L2 medium does not support frames longer t= han X, than only the=0A> synthetic packet format MUST be used."=0A> =0A> In= this way we avoid manual configuration and supporting both formats=0A> in = devices that target implementing this spec on very limited L2=0A> medium.= =0A> =0A> In other words, synthetic packet format should be a MUST for some= =0A> lower layer technologies characterized by some parameters (without=0A>= referencing specific technologies).=0A> =0A> Best,=0A> Angelo=0A> =0A> On = Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani=0A> = wrote:=0A>> +1=0A>> =0A>> On Wed, Aug 31, 2011 at 23:46, Michael Richardso= n wrote:=0A>>> =0A>>>>>>>> "Thomas" =3D=3D Thomas Heide = Clausen writes:=0A>>>=A0 =A0 Thomas> I'd much like= a routing protocol, designed for low-power,=0A>>>=A0 =A0 Thomas> lossy net= works and with low-MTU MACs as one of its=0A>>>=A0 =A0 Thomas> design-targe= t to be able to run over these networks. If=0A>>>=A0 =A0 Thomas> _this_ ear= ly a need for an alternative, more compact, packet=0A>>>=A0 =A0 Thomas> for= mat is identified, then by all means let's get RPL=0A>>>=A0 =A0 Thomas> upd= ated to use that alternative, more compact, packet=0A>>>=A0 =A0 Thomas> for= mat. I have absolutely no problems with that.=0A>>> =0A>>> +1=0A>>> =0A>>> = _______________________________________________=0A>>> Roll mailing list=0A>= >> Roll@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/roll=0A>>> =0A= >> =0A> _______________________________________________=0A> Roll mailing li= st=0A> Roll@ietf.org=0A> https://www.ietf.org/mailman/listinfo/roll=0A> =0A= =0A=0A_______________________________________________=0ARoll mailing list= =0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll --0-646403744-1315032129=:8272 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
No one is = talking about (or should not be talking about binding rpl to any specific l= 1/l2, but we are talking about compressing bits and that is useful on ANY l= 1/l2 - 802.15.4, 802.15.4g, 802.11LP and PLC.  Less bits sent means le= ss time on air, less contention, less power, less less less.  So let's= attempt to fix RPL now and get rid of the packet bloat.
<= br>
rav

From: C Chauvenet <c.chauvenet@wattec= o.com>
To: Angelo P. Castellani <angelo@castellani.net>
Cc: roll WG <roll@ietf.org>
Sent: Friday, September 2, 2011 4:22 AM
Subject: Re: [Roll] Adoption= of draft-goyal-roll-rpl-compression as a new ROLL WG document
Hi,

Because RPL is a Route-Over routing protocol, it is applicabl= e to many different L1/L2, including the well-known 802.14.5 and their last= improvements/updates, PLC  and many others ...

Thus, I think w= e should avoid to bind RPL to some specifics L1/L2, or we would need to upd= ate RPL for each new L1/L2 created that aim to use RPL.

C=E9dric.
Le 1 sept. 2011 =E0 10:32, Angelo P. Castellani a =E9crit :

>= ; I slightly changed my mind about this +1.
>
> Probably a goo= d way to avoid this problem is to require the update of
> the RPL packet format only for those mediums where the use of a
> synthetic = packet formats is a strong requirement (e.g. 802.15.4).
>
> As= detailed in , the conditions can be characterized in a more general
>= ; way, avoiding referencing single technologies in the standard:
> "I= f the L2 medium does not support frames longer than X, than only the
>= ; synthetic packet format MUST be used."
>
> In this way we av= oid manual configuration and supporting both formats
> in devices tha= t target implementing this spec on very limited L2
> medium.
> =
> In other words, synthetic packet format should be a MUST for some<= br>> lower layer technologies characterized by some parameters (without<= br>> referencing specific technologies).
>
> Best,
> = Angelo
>
> On Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani<= br>> <angelo@castellani.net> wrote:=
>> +1
>>
>> On Wed, Aug 31, 2011 at 23:46, Mic= hael Richardson <mcr@sandelman.ca> wrote:
>>>
>&g= t;>>>>>> "Thomas" =3D=3D Thomas Heide Clausen <ietf@thomasclausen.org> writes:
>>>    Thoma= s> I'd much like a routing protocol, designed for low-power,
>>= >    Thomas> lossy networks and with low-MTU MACs as one of= its
>>>    Thomas> design-target to be able to ru= n over these networks. If
>>>    Thomas> _this_ ea= rly a need for an alternative, more compact, packet
>>>  &= nbsp; Thomas> format is identified, then by all means let's get RPL
>>>    Thomas> updated to use that alternativ= e, more compact, packet
>>>    Thomas> format. I h= ave absolutely no problems with that.
>>>
>>> +1>>>
>>> ___________________________________________= ____
>>> Roll mailing list
>>> Roll@ietf.org
>>= > https://www.ietf.org/mailman/listinfo/roll
>>>
>&= gt;
> _______________________________________________
> Roll m= ailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/ro= ll
>


_______________________________________________<= br>Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--0-646403744-1315032129=:8272-- From ietfroll@yahoo.com Sat Sep 3 00:52:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47F21F8B9D for ; Sat, 3 Sep 2011 00:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OK9B4JOItg0 for ; Sat, 3 Sep 2011 00:52:48 -0700 (PDT) Received: from nm1-vm0.bullet.mail.sp2.yahoo.com (nm1-vm0.bullet.mail.sp2.yahoo.com [98.139.91.202]) by ietfa.amsl.com (Postfix) with SMTP id 3A40D21F8C4A for ; Sat, 3 Sep 2011 00:52:48 -0700 (PDT) Received: from [98.139.91.64] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 07:54:26 -0000 Received: from [98.139.91.17] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 07:54:26 -0000 Received: from [127.0.0.1] by omp1017.mail.sp2.yahoo.com with NNFMP; 03 Sep 2011 07:54:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 444178.80170.bm@omp1017.mail.sp2.yahoo.com Received: (qmail 53794 invoked by uid 60001); 3 Sep 2011 07:54:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315036466; bh=5TfkUJFkOekqvYpDWEe+SzafQJDW30BGPOLTus1D9PA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iO3sWKYH5KKC2WHYGlRVx74Qdp1sy2dLoBOFv8EeJvmlNLISzwteFDbsixoBlJpRRM9sP2aL6Pc4F4ZWdlcvgLq3uSX+QNOVj9z5sQtOfnmneDedcwf/+5//PDAfCwZAAflytK0L6JV2ZsvbtHqB5YUFx3ZxPFqLe6+WVrhZ5hI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rciE5OXEWOWIDMZJ1ihmJ6GoPRWbLmOfQcTQd2zsGmxQUR81ikyCc4OJVgNp4VL5ETyWmvZYZvftuuhRNsF2x7r2PLGE7iC3nW2AdhnnXBihqfuSAWAGm9jQHPOzPiZjQ6GQ8uwUVTrrrmUPgKWjPAxRM0QC6n1VaB25uwtZ9Z4=; X-YMail-OSG: _htnNTgVM1lFRVHVv3yRBEfxsHAnCX96TzL7C6CEhu_P3wJ h7ZoBCjpb84o2K6fiOushnnSdGL9fCM3nwz2MWbZdk6KHZswAD.VKJYitF7R aIJ6alQHbyF2zyMImSCykygltEASX7eMwWgs.q7kyQ205hjmyNdEpTVZ2RDD vA4lKzgo2WfB.pWvz8oNpbySHMHk_ZZe5QMYhuVkh8FdjKqupHt9WxIl3lH0 FmPxImuKfmEjLx6C8tj5ZkL2TH1fmNu_c655sVZAEng1fkts.koqdrPgdBeZ c_AApLnwGsAQSpV1nTifBF5aj2hzKjTDX3D0taJBbeWGDuNhFqGiH5WFkfov q3wP6qQVsIK1KlIHejs6xOd9gGk.NZZi6QLVVoFHo Received: from [188.138.91.232] by web113917.mail.gq1.yahoo.com via HTTP; Sat, 03 Sep 2011 00:54:25 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> Message-ID: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT) From: Ietf Roll To: JP Vasseur , Thomas Heide Clausen In-Reply-To: <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1438364730-1315036465=:46782" Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ietf Roll List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 07:52:49 -0000 --0-1438364730-1315036465=:46782 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable JP Vasseur wrote:=0A=0A=0A=0A*if* you think that this not elegant enough (w= hich has to be demonstrated IMO), then you must be supportive=0Aof the P2P = IDs work that the WG has been working on ?=0A[rav] how about a demonstratio= n that RPL actually works as purported.=A0 Thomas has said that his group i= mplemented it and it was difficult, complex and fraught with inconsistencie= s in specification.=0A=A0=A0=A0=A0=A0=A0=A0=A0 I heard that zigbee is havin= g problems making it work and the only paper that I've seen on RPL says tha= t for constrained nodes they recommend no more than 30 nodes in a network.= =A0 Hardly the scale necessary for some of the =0A=A0=A0=A0=A0=A0=A0=A0=A0 = use cases been suggested (like AMI).=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 The P2P = is a hack to try to fix the fact the RPL is basically a collection tree and= as such downward routing is an distant after thought (certainly not elegan= t).=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 Without lots of memory, node must use non= -storing mode (oh and we are talking about constrained devices so lots of m= emory is then inconsistent) and then routing is up to the root and back dow= n.=A0 Not what anyone who=0A=A0=A0=A0=A0=A0=A0=A0=A0 understands routing wo= uld consider elegant P2P.=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 In the rush to get = RPL out of the working group we all were bamboozled by the chair into belie= ving the draft was actually complete and the IESG further compounded this e= rror.=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 If it were possible to fix things, RPL = should be an experimental draft until such time as there are working intero= perable implementations that are shown to provide the services that were re= quired in the various Use-case=0A=A0=A0=A0=A0=A0=A0=A0=A0 drafts - or even = just one of them.=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 And now we are rushing to g= enerate and publish a marketing document (called an applicability statement= ) without having any experience with the protocol.=0A=0A=A0=A0=A0=A0=A0=A0= =A0=A0 Are we rushing and putting so much pressure and bending the systems = so that this gets published before we find we've built a house of cards and= it comes crashing down.=0A=0A=A0=A0=A0=A0=A0=A0=A0=A0 This will be really = counter productive to the industry and the Internet (certainly not Thomas's= warnings).=A0 When everyone looks at this mistake and says, why didn't the= IETF do its job and exercise proper engineering, then the ROLL WG=0A=A0=A0= =A0=A0=A0=A0=A0=A0=A0 and the Chairs will be the ones that have hurt the in= dustry and the Internet.=0A=0ARav --0-1438364730-1315036465=:46782 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
JP Vasseur= wrote:

*if* you think that this not elegant enough (which has to be dem= onstrated IMO), then you must be supportive
of the P2P IDs work t= hat the WG has been working on ?

[rav] how about a demo= nstration that RPL actually works as purported.  Thomas has said that = his group implemented it and it was difficult, complex and fraught with inc= onsistencies in specification.
       = ;  I heard that zigbee is having problems making it work and the only = paper that I've seen on RPL says that for constrained nodes they recommend no more than 30 nodes in a network.  Hardly the scale necessary for s= ome of the
         use cases b= een suggested (like AMI).

       =   The P2P is a hack to try to fix the fact the RPL is basically a coll= ection tree and as such downward routing is an distant after thought (certa= inly not elegant).

         = Without lots of memory, node must use non-storing mode (oh and we are talki= ng about constrained devices so lots of memory is then inconsistent) and th= en routing is up to the root and back down.  Not what anyone who
&n= bsp;        understands routing would co= nsider elegant P2P.

        = In the rush to get RPL out of the working group we all were bamboozled by = the chair into believing the draft was actually complete and the IESG further compounded this error.

     &= nbsp;   If it were possible to fix things, RPL should be an exper= imental draft until such time as there are working interoperable implementa= tions that are shown to provide the services that were required in the vari= ous Use-case
         drafts - o= r even just one of them.

       &= nbsp; And now we are rushing to generate and publish a marketing document (= called an applicability statement) without having any experience with the p= rotocol.

         Are we rus= hing and putting so much pressure and bending the systems so that this gets= published before we find we've built a house of cards and it comes crashin= g down.

         This will b= e really counter productive to the industry and the Internet (certainly not Thomas's warnings).  When everyone looks at this mista= ke and says, why didn't the IETF do its job and exercise proper engineering= , then the ROLL WG
         = ; and the Chairs will be the ones that have hurt the industry and the Inter= net.

Rav

--0-1438364730-1315036465=:46782-- From c.chauvenet@watteco.com Sat Sep 3 07:40:05 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7948421F8B47 for ; Sat, 3 Sep 2011 07:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+IRi43HR9pH for ; Sat, 3 Sep 2011 07:40:04 -0700 (PDT) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D35921F8B3D for ; Sat, 3 Sep 2011 07:40:03 -0700 (PDT) Received: from mail95-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Sep 2011 14:41:41 +0000 Received: from mail95-va3 (localhost.localdomain [127.0.0.1]) by mail95-va3-R.bigfish.com (Postfix) with ESMTP id 93F0B137831C; Sat, 3 Sep 2011 14:41:41 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(z1725nz9371Kc89bhc85dh1432N98dKzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB015.red002.local; RD:none; EFVD:NLI Received: from mail95-va3 (localhost.localdomain [127.0.0.1]) by mail95-va3 (MessageSwitch) id 1315060892603516_32318; Sat, 3 Sep 2011 14:41:32 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.249]) by mail95-va3.bigfish.com (Postfix) with ESMTP id 65ED63C80FC; Sat, 3 Sep 2011 14:40:07 +0000 (UTC) Received: from IE2RD2HUB015.red002.local (213.199.187.153) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 3 Sep 2011 14:40:06 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB015.red002.local ([10.43.198.13]) with mapi; Sat, 3 Sep 2011 07:40:06 -0700 From: C Chauvenet To: Ietf Roll Date: Sat, 3 Sep 2011 07:40:05 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxqR18N1KZqoRVsT3672xWF6TOgQg== Message-ID: References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <24100.1314827183@marajade.sandelman.ca> <1315032129.8272.YahooMailNeo@web113913.mail.gq1.yahoo.com> In-Reply-To: <1315032129.8272.YahooMailNeo@web113913.mail.gq1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_CB53525100D849ECB2CD0B33CC8E3CA9wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 14:40:05 -0000 --_000_CB53525100D849ECB2CD0B33CC8E3CA9wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, yes I agree, that was the introduction of my mail about my feeling on the c= ompression. Happy that we agree on that. C=E9dric. Le 3 sept. 2011 =E0 08:42, Ietf Roll a =E9crit : No one is talking about (or should not be talking about binding rpl to any = specific l1/l2, but we are talking about compressing bits and that is usefu= l on ANY l1/l2 - 802.15.4, 802.15.4g, 802.11LP and PLC. Less bits sent mea= ns less time on air, less contention, less power, less less less. So let's= attempt to fix RPL now and get rid of the packet bloat. rav ________________________________ From: C Chauvenet > To: Angelo P. Castellani > Cc: roll WG > Sent: Friday, September 2, 2011 4:22 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new R= OLL WG document Hi, Because RPL is a Route-Over routing protocol, it is applicable to many diff= erent L1/L2, including the well-known 802.14.5 and their last improvements/= updates, PLC and many others ... Thus, I think we should avoid to bind RPL to some specifics L1/L2, or we wo= uld need to update RPL for each new L1/L2 created that aim to use RPL. C=E9dric. Le 1 sept. 2011 =E0 10:32, Angelo P. Castellani a =E9crit : > I slightly changed my mind about this +1. > > Probably a good way to avoid this problem is to require the update of > the RPL packet format only for those mediums where the use of a > synthetic packet formats is a strong requirement (e.g. 802.15.4). > > As detailed in , the conditions can be characterized in a more general > way, avoiding referencing single technologies in the standard: > "If the L2 medium does not support frames longer than X, than only the > synthetic packet format MUST be used." > > In this way we avoid manual configuration and supporting both formats > in devices that target implementing this spec on very limited L2 > medium. > > In other words, synthetic packet format should be a MUST for some > lower layer technologies characterized by some parameters (without > referencing specific technologies). > > Best, > Angelo > > On Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani > > wrote: >> +1 >> >> On Wed, Aug 31, 2011 at 23:46, Michael Richardson > wrote: >>> >>>>>>>> "Thomas" =3D=3D Thomas Heide Clausen > writes: >>> Thomas> I'd much like a routing protocol, designed for low-power, >>> Thomas> lossy networks and with low-MTU MACs as one of its >>> Thomas> design-target to be able to run over these networks. If >>> Thomas> _this_ early a need for an alternative, more compact, packet >>> Thomas> format is identified, then by all means let's get RPL >>> Thomas> updated to use that alternative, more compact, packet >>> Thomas> format. I have absolutely no problems with that. >>> >>> +1 >>> >>> _______________________________________________ >>> 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 --_000_CB53525100D849ECB2CD0B33CC8E3CA9wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 

yes I agree, that was the introduction of my mail about my feeling on th= e compression.

Happy that we agree on that.
<= div>
C=E9dric.

Le 3 sept. 2011 =E0 08= :42, Ietf Roll a =E9crit :

= No one is talking about (or should not be talking about binding rpl t= o any specific l1/l2, but we are talking about compressing bits and that is= useful on ANY l1/l2 - 802.15.4, 802.15.4g, 802.11LP and PLC.  Less bi= ts sent means less time on air, less contention, less power, less less less= .  So let's attempt to fix RPL now and get rid of the packet bloat.

rav
<= br>
From: C Chauvenet <c.chauvenet@watteco.com>To: Angelo P. Castellani <angelo@castellani.= net>
Cc: roll WG= <roll@ietf.org>
Sent: Friday, September 2, 2011 4:22 A= M
Subject: Re: [Roll] A= doption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Hi,

Because RPL is a Route-Over routing protocol, it is ap= plicable to many different L1/L2, including the well-known 802.14.5 and the= ir last improvements/updates, PLC  and many others ...

Thus, I = think we should avoid to bind RPL to some specifics L1/L2, or we would need= to update RPL for each new L1/L2 created that aim to use RPL.

C=E9d= ric.

Le 1 sept. 2011 =E0 10:32, Angelo P. Castellani a =E9crit :
=
> I slightly changed my mind about this +1.
>
> Probabl= y a good way to avoid this problem is to require the update of
> the = RPL packet format only for those mediums where the use of a
> synthetic = packet formats is a strong requirement (e.g. 802.15.4).
>
> As= detailed in , the conditions can be characterized in a more general
>= ; way, avoiding referencing single technologies in the standard:
> "I= f the L2 medium does not support frames longer than X, than only the
>= ; synthetic packet format MUST be used."
>
> In this way we av= oid manual configuration and supporting both formats
> in devices tha= t target implementing this spec on very limited L2
> medium.
> =
> In other words, synthetic packet format should be a MUST for some<= br>> lower layer technologies characterized by some parameters (without<= br>> referencing specific technologies).
>
> Best,
> = Angelo
>
> On Thu, Sep 1, 2011 at 10:03, Angelo P. Castellani<= br>> <angelo@castellani.net> wrote:
>> +1
&= gt;>
>> On Wed, Aug 31, 2011 at 23:46, Michael Richardson <= mcr= @sandelman.ca> wrote:
>>>
>>>>>>&g= t;> "Thomas" =3D=3D Thomas Heide Clausen <ietf@thomasclausen= .org> writes:
>>>    Thomas> I'd much like = a routing protocol, designed for low-power,
>>>    Th= omas> lossy networks and with low-MTU MACs as one of its
>>>=     Thomas> design-target to be able to run over these network= s. If
>>>    Thomas> _this_ early a need for an al= ternative, more compact, packet
>>>    Thomas> for= mat is identified, then by all means let's get RPL
>>>    Thomas> updated to use that alternativ= e, more compact, packet
>>>    Thomas> format. I h= ave absolutely no problems with that.
>>>
>>> +1>>>
>>> ___________________________________________= ____
>>> Roll mailing list
>>> Roll@ietf.org
>>= > https://www.ietf.org/mailman/listinfo/roll
>>>
>&= gt;
> _______________________________________________
> Roll m= ailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/ro= ll
>


_______________________________________________<= br>Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


= --_000_CB53525100D849ECB2CD0B33CC8E3CA9wattecocom_-- From prvs=2203449e0=mukul@uwm.edu Sat Sep 3 07:45:52 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A882921F8997 for ; Sat, 3 Sep 2011 07:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.92 X-Spam-Level: X-Spam-Status: No, score=-4.92 tagged_above=-999 required=5 tests=[AWL=1.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKoq3I9i+NE8 for ; Sat, 3 Sep 2011 07:45:52 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E54FF21F877F for ; Sat, 3 Sep 2011 07:45:51 -0700 (PDT) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 03 Sep 2011 09:47:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9548412E3B2; Sat, 3 Sep 2011 09:47:30 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asEzDr-SYqry; Sat, 3 Sep 2011 09:47:30 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4EB3512E3B1; Sat, 3 Sep 2011 09:47:30 -0500 (CDT) Date: Sat, 3 Sep 2011 09:47:30 -0500 (CDT) From: Mukul Goyal To: Ietf Roll Message-ID: <1128231318.183084.1315061250217.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <1315031900.16281.YahooMailNeo@web113920.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 14:45:53 -0000 I would like to respectfully submit that I find it very hard to accept the = argument that a protocol should not be extended because the devices that do= nt implement the extension can't talk to devices that do. The compression s= cheme we proposed seems like a good optimization to us for some of the appl= ications we are concerned with. Whether this is absolutely the best approac= h for all possible RPL applications, I dont know. As Pascal suggested, it i= s important to compress both data and control messages. May be GHC is a bet= ter approach. We will find out. There was a lot of opposition to adding more stuff to core RPL. The (valid)= argument was that any further additions would be introduced as supplementa= ry documents. Now that core RPL is (almost) done, objections in the name of= interoperability are being raised to deny useful extensions of the protoco= l and even to attack the core protocol itself. I find it to be a sorry stat= e of affairs. Thanks Mukul =20 ----- Original Message ----- From: "Ietf Roll" To: "C Chauvenet" , "Thomas Heide Clausen" Cc: "roll WG" Sent: Saturday, September 3, 2011 1:38:20 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new= =09ROLL WG document Cedric wrote:=20 That's said, I don't see any problem for trying to design some improvements= for RPL.=20 I think this rule is the same for every protocols.=20 [rav] Yes and RPL certainly needs improvements. :-)=C2=A0 And compressing o= ut a bunch of unused bits would be a good improvement.=20 As already mentioned in this discussion, it's all about *optional* improvem= ents.=20 Designing new mechanism like compression doesn't mean that you HAVE to impl= ement them.=20 So I don't=C2=A0 see why nodes won't interoperate if they all rely on the s= ame RPL RFC.=20 [rav] Yes you are correct that nodes can interoperate if they all adhere to= the same RFC (or in RPLs case - lots of RFCs already - and more if you wan= t to do P2P and more if you want to to do non-storing mode, but I digress).= =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We are talking about a cha= nge to the core specification that will cause interoperability problems fro= m the outset.=C2=A0 If I rely on the uncompressed spec RFC (oh wait, it isn= 't an RFC yet) I can't speak to you if you rely on this new compression=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scheme.=C2=A0 If we decide= to go forward this this, then we have to have some way to negotiate betwee= n nodes to say if you are or are not using compression (oops another I-D). = OR everyone has to implement both which goes against the notion=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 that we are designing constrained nodes.= =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If this compression is a g= ood idea, then let's make it part of the core spec, get rid of the extra wa= sted bits and try to make RPL useful on constrained nodes.=C2=A0 This draft= , if it is adopted by the WG, should deprecate the RPL core spec and fix it= .=20 rav=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Sat Sep 3 07:48:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E4D21F8B72 for ; Sat, 3 Sep 2011 07:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.398 X-Spam-Level: X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-2yvWG6kKLw for ; Sat, 3 Sep 2011 07:48:43 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id E670B21F8B71 for ; Sat, 3 Sep 2011 07:48:42 -0700 (PDT) Received: from mail184-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Sep 2011 14:50:20 +0000 Received: from mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1-R.bigfish.com (Postfix) with ESMTP id 3002E1CA0646; Sat, 3 Sep 2011 14:50:20 +0000 (UTC) X-SpamScore: -13 X-BigFish: VPS-13(z1725nzc89bh1803Mc85dh1dbaL98dK14ffOzz1202hzzz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB012.red002.local; RD:none; EFVD:NLI Received: from mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1 (MessageSwitch) id 1315061419702508_9846; Sat, 3 Sep 2011 14:50:19 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail184-ch1.bigfish.com (Postfix) with ESMTP id 9DB307A804B; Sat, 3 Sep 2011 14:50:19 +0000 (UTC) Received: from IE2RD2HUB012.red002.local (213.199.187.153) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 3 Sep 2011 14:50:19 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB012.red002.local ([10.33.16.251]) with mapi; Sat, 3 Sep 2011 07:50:18 -0700 From: C Chauvenet To: Ietf Roll Date: Sat, 3 Sep 2011 07:50:18 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxqSMvSQ20bA6JLQdqjCbcMVcHxMQ== Message-ID: <97A20B88-32F6-4EF8-A70B-0FFFBFEE29DA@watteco.com> References: <1483809161.144962.1314763722334.JavaMail.root@mail05.pantherlink.uwm.edu> <4884.1314797912@marajade.sandelman.ca> <8CA251EF-2842-453A-964A-E3F30713917A@cisco.com> <2507C27F-0589-488C-902F-52B55A0FCE49@thomasclausen.org> <76BFB7B0-5A9C-43D8-995F-44A39A41CE82@watteco.com> <1315031900.16281.YahooMailNeo@web113920.mail.gq1.yahoo.com> In-Reply-To: <1315031900.16281.YahooMailNeo@web113920.mail.gq1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_97A20B8832F64EF8A70B0FFFBFEE29DAwattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 14:48:43 -0000 --_000_97A20B8832F64EF8A70B0FFFBFEE29DAwattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The last part of my mail you didn't mentioned in your reply talked about th= e 6loWPAN work which has done some previous work on compression. I think the 6LoWPAN WG and people involved into it have answers to the poin= t you are exposing. I'm feeling that doing some compression in RPL is not so far from doing com= pression like 6LoWPAN. Your point seems to be related to the general compression mechanism, not es= pecially RPL. What do you think ? ps : What about saying "hi" and "regards" in mails, and assume your opinion= through a real name and affiliation ? respectfully, C=E9dric. Le 3 sept. 2011 =E0 08:38, Ietf Roll a =E9crit : Cedric wrote: That's said, I don't see any problem for trying to design some improvements= for RPL. I think this rule is the same for every protocols. [rav] Yes and RPL certainly needs improvements. :-) And compressing out a = bunch of unused bits would be a good improvement. As already mentioned in this discussion, it's all about *optional* improvem= ents. Designing new mechanism like compression doesn't mean that you HAVE to impl= ement them. So I don't see why nodes won't interoperate if they all rely on the same R= PL RFC. [rav] Yes you are correct that nodes can interoperate if they all adhere to= the same RFC (or in RPLs case - lots of RFCs already - and more if you wan= t to do P2P and more if you want to to do non-storing mode, but I digress). We are talking about a change to the core specification that will = cause interoperability problems from the outset. If I rely on the uncompre= ssed spec RFC (oh wait, it isn't an RFC yet) I can't speak to you if you re= ly on this new compression scheme. If we decide to go forward this this, then we have to hav= e some way to negotiate between nodes to say if you are or are not using co= mpression (oops another I-D). OR everyone has to implement both which goes = against the notion that we are designing constrained nodes. If this compression is a good idea, then let's make it part of the= core spec, get rid of the extra wasted bits and try to make RPL useful on = constrained nodes. This draft, if it is adopted by the WG, should deprecat= e the RPL core spec and fix it. rav --_000_97A20B8832F64EF8A70B0FFFBFEE29DAwattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 

The last part of my mail you didn't mentioned in your reply talked about= the 6loWPAN work which has done some previous work on compression.I think the 6LoWPAN WG and people involved into it have answers to the p= oint you are exposing.
I'm feeling that doing some compression in= RPL is not so far from doing compression like 6LoWPAN.
Your poin= t seems to be related to the general compression mechanism, not especially = RPL.

What do you think ?

ps= : What about saying "hi" and "regards" in mails, and assume your opinion t= hrough a real name and affiliation ?

respectfully,=  

C=E9dric.

Le 3 sept= . 2011 =E0 08:38, Ietf Roll a =E9crit :


Cedric wrote:

That's said, I don't= see any problem for trying to design some improvements for RPL.
I think= this rule is the same for every protocols.

[rav] Yes and RPL certai= nly needs improvements. :-)  And compressing out a bunch of unused bit= s would be a good improvement.

As already mentioned in this discussi= on, it's all about *optional* improvements.
Designing new mechanism like= compression doesn't mean that you HAVE to implement them.
So I don't&nb= sp; see why nodes won't interoperate if they all rely on the same RPL RFC.<= br>
[rav] Yes you are correct that nodes can interoperate if they all ad= here to the same RFC (or in RPLs case - lots of RFCs already - and more if you want to do P2P and more= if you want to to do non-storing mode, but I digress).
  &nbs= p;      We are talking about a change to the core = specification that will cause interoperability problems from the outset.&nb= sp; If I rely on the uncompressed spec RFC (oh wait, it isn't an RFC yet) I= can't speak to you if you rely on this new compression
  &nbs= p;      scheme.  If we decide to go forward t= his this, then we have to have some way to negotiate between nodes to say i= f you are or are not using compression (oops another I-D). OR everyone has = to implement both which goes against the notion
      &nb= sp;  that we are designing constrained nodes.

   = ;      If this compression is a good idea, then le= t's make it part of the core spec, get rid of the extra wasted bits and try to make RPL useful on constrained nodes.  This draft, if it i= s adopted by the WG, should deprecate the RPL core spec and fix it.

= rav

= --_000_97A20B8832F64EF8A70B0FFFBFEE29DAwattecocom_-- From c.chauvenet@watteco.com Sat Sep 3 08:04:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5AB21F8AFA for ; Sat, 3 Sep 2011 08:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhBu+ZIfWBLR for ; Sat, 3 Sep 2011 08:03:59 -0700 (PDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4A42721F8AF8 for ; Sat, 3 Sep 2011 08:03:59 -0700 (PDT) Received: from mail156-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Sat, 3 Sep 2011 15:05:37 +0000 Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2-R.bigfish.com (Postfix) with ESMTP id D8B98D082D3; Sat, 3 Sep 2011 15:05:37 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(z1725nzc89bh146fKc85dh98dKzz1202hzzz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB010.red002.local; RD:none; EFVD:NLI Received: from mail156-tx2 (localhost.localdomain [127.0.0.1]) by mail156-tx2 (MessageSwitch) id 1315062336833996_24348; Sat, 3 Sep 2011 15:05:36 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.250]) by mail156-tx2.bigfish.com (Postfix) with ESMTP id C4B5B398056; Sat, 3 Sep 2011 15:05:36 +0000 (UTC) Received: from IE2RD2HUB010.red002.local (213.199.187.153) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 3 Sep 2011 15:05:34 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB010.red002.local ([10.33.16.249]) with mapi; Sat, 3 Sep 2011 08:05:34 -0700 From: C Chauvenet To: Ietf Roll Date: Sat, 3 Sep 2011 08:05:34 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxqSu4h9A1olxstRpCHKpFX98vNCQ== Message-ID: References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> <4598998E-F7F6-4469-8977-BD49B5D7ECF7@cisco.com> <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> In-Reply-To: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_DAE1530E4D284EB69D2BCF946738CD04wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 15:04:00 -0000 --_000_DAE1530E4D284EB69D2BCF946738CD04wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Le 3 sept. 2011 =E0 09:54, Ietf Roll a =E9crit : JP Vasseur wrote: *if* you think that this not elegant enough (which has to be demonstrated I= MO), then you must be supportive of the P2P IDs work that the WG has been working on ? [rav] how about a demonstration that RPL actually works as purported. Thom= as has said that his group implemented it and it was difficult, complex and= fraught with inconsistencies in specification. I heard that zigbee is having problems making it work and the only= paper that I've seen on RPL says that for constrained nodes they recommend= no more than 30 nodes in a network. Hardly the scale necessary for some o= f the use cases been suggested (like AMI). You may use this fantastic website : http://scholar.google.fr/ to increase = your bibliography about RPL. There are a lot of paper on RPL, and more and more are coming through the l= ast conferences. Furthermore, if you were in IETF (but we cannot know...) you should have ta= lk to the main author of the paper you are referring to, to clarify your un= derstanding of that paper (He was in the first row during the ROLL session;= hard to miss ...). The P2P is a hack to try to fix the fact the RPL is basically a co= llection tree and as such downward routing is an distant after thought (cer= tainly not elegant). Without lots of memory, node must use non-storing mode (oh and we = are talking about constrained devices so lots of memory is then inconsisten= t) and then routing is up to the root and back down. Not what anyone who understands routing would consider elegant P2P. In the rush to get RPL out of the working group we all were bamboo= zled by the chair into believing the draft was actually complete and the IE= SG further compounded this error. If it were possible to fix things, RPL should be an experimental d= raft until such time as there are working interoperable implementations tha= t are shown to provide the services that were required in the various Use-c= ase drafts - or even just one of them. And now we are rushing to generate and publish a marketing documen= t (called an applicability statement) without having any experience with th= e protocol. Are we rushing and putting so much pressure and bending the system= s so that this gets published before we find we've built a house of cards a= nd it comes crashing down. This will be really counter productive to the industry and the Int= ernet (certainly not Thomas's warnings). When everyone looks at this mista= ke and says, why didn't the IETF do its job and exercise proper engineering= , then the ROLL WG and the Chairs will be the ones that have hurt the industry and t= he Internet. All this looks very much to your mail during IETF. I don't really see the value regarding the object of this discussion, focus= ed on the compression document. Anyway, you should definitely reduce your coffee consumption ;-) Rav Regards, C=E9dric. --_000_DAE1530E4D284EB69D2BCF946738CD04wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, 

Le 3 sept. 2011 =E0 09:54, Ietf Roll a =E9crit :

JP Vasseur wrote:

*if* you think that = this not elegant enough (which has to be demonstrated IMO), then you must b= e supportive
of the P2P IDs work that the WG has been working on = ?

[rav] how about a demonstration that RPL actually wor= ks as purported.  Thomas has said that his group implemented it and it= was difficult, complex and fraught with inconsistencies in specification.<= br>         I heard that zigbee is = having problems making it work and the only paper that I've seen on RPL say= s that for constrained nodes they recommend no more than 30 nodes in a network.  Hardly the scale necessary for s= ome of the
         use cases b= een suggested (like AMI).


You may use this fantastic website :&= nbsp;http://scholar.google.fr/&nb= sp;to increase your bibliography about RPL.
There are a lot of pa= per on RPL, and more and more are coming through the last conferences.

Furthermore, if you were in IETF (but we cannot know..= .) you should have talk to the main author of the paper you are referring t= o, to clarify your understanding of that paper (He was in the first row dur= ing the ROLL session; hard to miss ...).


         The P= 2P is a hack to try to fix the fact the RPL is basically a collection tree = and as such downward routing is an distant after thought (certainly not ele= gant).

         Without lots= of memory, node must use non-storing mode (oh and we are talking about con= strained devices so lots of memory is then inconsistent) and then routing i= s up to the root and back down.  Not what anyone who
  &n= bsp;      understands routing would consider elega= nt P2P.

         In the rush= to get RPL out of the working group we all were bamboozled by the chair in= to believing the draft was actually complete and the IESG further compounded this error.

     &= nbsp;   If it were possible to fix things, RPL should be an exper= imental draft until such time as there are working interoperable implementa= tions that are shown to provide the services that were required in the vari= ous Use-case
         drafts - o= r even just one of them.

       &= nbsp; And now we are rushing to generate and publish a marketing document (= called an applicability statement) without having any experience with the p= rotocol.

         Are we rus= hing and putting so much pressure and bending the systems so that this gets= published before we find we've built a house of cards and it comes crashin= g down.

         This will b= e really counter productive to the industry and the Internet (certainly not Thomas's warnings).  When everyone looks at this mista= ke and says, why didn't the IETF do its job and exercise proper engineering= , then the ROLL WG
         = ; and the Chairs will be the ones that have hurt the industry and the Inter= net.


All this looks very much to your mail during IETF.
I don't = really see the value regarding the object of this discussion, focused on th= e compression document.
Anyway, you should definitely reduce your= coffee consumption ;-)

Rav

<ATT00001..txt>=

Regards,

C=E9dr= ic.


= --_000_DAE1530E4D284EB69D2BCF946738CD04wattecocom_-- From prvs=2203449e0=mukul@uwm.edu Sat Sep 3 08:31:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4921F8B15 for ; Sat, 3 Sep 2011 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKkD1LfMKHmA for ; Sat, 3 Sep 2011 08:31:58 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 002D421F8B14 for ; Sat, 3 Sep 2011 08:31:57 -0700 (PDT) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 03 Sep 2011 10:33:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 82F062B3F2F; Sat, 3 Sep 2011 10:33:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu 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 t14Rq7oboMYE; Sat, 3 Sep 2011 10:33:03 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 08A552B3F21; Sat, 3 Sep 2011 10:33:03 -0500 (CDT) Date: Sat, 3 Sep 2011 10:33:35 -0500 (CDT) From: Mukul Goyal To: Ietf Roll Message-ID: <1230776290.183247.1315064014742.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 15:31:59 -0000 >[rav] how about a demonstration that RPL actually works as purported. Tho= mas has said that his group implemented it and it was difficult, complex an= d fraught with inconsistencies in specification.=20 An open-source RPL implementation on Contiki has existed for a while. I am = a cursory observer of the Contiki mailing list but it is clear to me that t= his RPL implementation is quite popular. INRIA (Matthias Phillip and Emmanu= el Baccelli) did an RPL-P2P implementation on top of this implementation. T= his implementatio is uptodate with RPL-P2P version 4. I have checked this c= ode (and also the core RPL implementation code) line by line and I dont see= how we can characterize the implementation difficult/complex or fraught wi= th inconsistencies. A second P2P-RPL implementation is in works at Sigma De= sign. I hear the zigbee-IP folks have been testing various RPL implementations ve= ry aggressively. I have not heard difficult/complex/inconsistent complaints= there too (although I have no direct participation in that effort but I he= ar about the ongings of zigbee-IP activities from people who do). So, I thi= nk this particular statement may not be accurate or fair. Perhaps some one = from zigbee-IP camp can update us on the situation in this regard. =20 I guess I object to rest of this email too. I guess people will realize it = for what it is - unfounded libel from a person too afraid to identify himse= lf/herself. Thanks Mukul ----- Original Message ----- From: "Ietf Roll" To: "JP Vasseur" , "Thomas Heide Clausen" Cc: "roll WG" Sent: Saturday, September 3, 2011 2:54:25 AM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new= =09ROLL WG document JP Vasseur wrote:=20 *if* you think that this not elegant enough (which has to be demonstrated I= MO), then you must be supportive=20 of the P2P IDs work that the WG has been working on ?=20 [rav] how about a demonstration that RPL actually works as purported.=C2=A0= Thomas has said that his group implemented it and it was difficult, comple= x and fraught with inconsistencies in specification.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I heard that zigbee is hav= ing problems making it work and the only paper that I've seen on RPL says t= hat for constrained nodes they recommend no more than 30 nodes in a network= .=C2=A0 Hardly the scale necessary for some of the=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 use cases been suggested (= like AMI).=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The P2P is a hack to try t= o fix the fact the RPL is basically a collection tree and as such downward = routing is an distant after thought (certainly not elegant).=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Without lots of memory, no= de must use non-storing mode (oh and we are talking about constrained devic= es so lots of memory is then inconsistent) and then routing is up to the ro= ot and back down.=C2=A0 Not what anyone who=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 understands routing would = consider elegant P2P.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the rush to get RPL out= of the working group we all were bamboozled by the chair into believing th= e draft was actually complete and the IESG further compounded this error.= =20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If it were possible to fix= things, RPL should be an experimental draft until such time as there are w= orking interoperable implementations that are shown to provide the services= that were required in the various Use-case=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 drafts - or even just one = of them.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And now we are rushing to = generate and publish a marketing document (called an applicability statemen= t) without having any experience with the protocol.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are we rushing and putting= so much pressure and bending the systems so that this gets published befor= e we find we've built a house of cards and it comes crashing down.=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will be really counte= r productive to the industry and the Internet (certainly not Thomas's warni= ngs).=C2=A0 When everyone looks at this mistake and says, why didn't the IE= TF do its job and exercise proper engineering, then the ROLL WG=20 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the Chairs will = be the ones that have hurt the industry and the Internet.=20 Rav=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Sat Sep 3 14:33:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91C621F8A4D for ; Sat, 3 Sep 2011 14:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahvir2Tszk4R for ; Sat, 3 Sep 2011 14:33:14 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9405121F8A1A for ; Sat, 3 Sep 2011 14:33:13 -0700 (PDT) Received: by pzk33 with SMTP id 33so12087946pzk.18 for ; Sat, 03 Sep 2011 14:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Petqy6GAibxTbWWHaVuToKHArTk2n5WqGPML9whY2uY=; b=OC6CRjidGSebi57b+Dk66kj15+jfvvLORXkcsrPogn9VXmx2+ZRe2x32ibcO2AItmF 6o9vtRMpEtRZWiKZsUbSgSpdQf1t0WcTuydzwExPX/2lBukCz77a2w59E6YjbzRdNCKE Zfm/vlmEX/5yHaAtrnzph1rDIG08mAXPC5DY8= Received: by 10.68.7.194 with SMTP id l2mr4622693pba.397.1315085693144; Sat, 03 Sep 2011 14:34:53 -0700 (PDT) Received: from sjc-vpn2-94.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id jl4sm8831064pbc.10.2011.09.03.14.34.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Sep 2011 14:34:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D053A3D61@XMB-AMS-107.cisco.com> Date: Sat, 3 Sep 2011 14:34:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C4F28D7-84C5-4745-9B48-8D278E189322@gmail.com> References: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D053A3D61@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org Subject: Re: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 03 Sep 2011 21:33:15 -0000 On Aug 10, 2011, at 1:03 AM 8/10/11, Pascal Thubert (pthubert) wrote: > Hi Ralph >=20 >> OF0, when it generates a rank_increase based on hop count, is > characterized >> as inappropriate for wireless meshes. I wonder if "wireless" is > really the right >> descriptive term here. More generally, a hop count metric is > inappropriate >> for subnets composed of links in which a route with a higher hop = count > might >> perform better than a router with a lower hop count. Such subnets = can > be >> either wireless or wired; for example, as I understand the = technology, > it's >> possible for an IEEE1901.2 network to exhibit connectivity and > transmission >> quality characteristics for which a route through more higher quality > hops >> might be better than a router through fewer lower quality hops. >=20 > [Pascal] You're correct. > OF0 does not know the type of link it can be applied to so it leaves = the > computation of the step_of_rank to the implementation that knows = better. I'm not sure I made my point clearly. I think the terms "wireless" and = "wired" are inaccurate in describing the two kinds of links; "equal = cost" and "variable cost" would be more accurate. 802.11 provides = wireless links but, in usual deployments, my understanding is that they = are essentially equal cost. At the same time, wired links - e.g. = IEEE1901.2 - can have variable cost. - Ralph >> I'm also confused about some of the use cases for RPL. Is there a = use > case in >> which RPL would be used in a non-LLN environment in place of other > routing >> protocols like RIP, OSPF and ISIS? >=20 > [Pascal] RPL is a DV routing protocol. It has the pros and cons of its > family. But yes, it could apply in many places. It is a matter of > network engineering to select the most adapted tool for a given > situation, knowing that: > -As opposed to the classical bunch, it does not compute the optimal = end > to end path for all nodes.=20 > -RPL does not try to fix any broken situation as soon as it occurs.=20 > -RPL requires looking inside the packets for datapath validation, and > RPL adds a (set of) L3 "VLANs" we call instances >=20 > If you look at it, a spanning tree is not much different, just a lot > simpler (just a tree, no TTL). > So in a situation where a (mesh_under) spanning tree is used today a > (route_over) RPL solution could actually provide a positive = replacement. > Benefits would be: > - no risk of meltdown (that's TTL for you) thus faster convergence. > - end to end IP (that's route_over vs. mesh_under) > - multipath ( that's coming from RPL's DAG) > - Goal (the root is picked at a sensible place) >=20 > Another example: If you have a number of access points at home, and = you > want to mesh them, then the link quality is asserted by the = association > process so hop count could work. You'll note that with hop count, a = cost > is traditionally associated to link speed and that would apply too = since > WIFI reduces the link speed to maintain the link quality. This is a = case > where RPL could easily replace a proprietary mesh technology, either > using (hop count, line speed), something a bit fancier, like ETX, or > something more proprietary if that can provide a market advantage. OF0 > will allow all those to interoperate and you'll get a DAG that reaches > the goal, if that's possible at all. >=20 > Cheers, >=20 > Pascal From mcr@sandelman.ca Sat Sep 3 19:00:15 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF72821F8801 for ; Sat, 3 Sep 2011 19:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.338 X-Spam-Level: **** X-Spam-Status: No, score=4.338 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FRT_ROLEX=3.878, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caubO7ngtsqO for ; Sat, 3 Sep 2011 19:00:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1702521F87FA for ; Sat, 3 Sep 2011 19:00:14 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.85.217.9]) by relay.sandelman.ca (Postfix) with ESMTPS id EF4F434309 for ; Sat, 3 Sep 2011 22:01:09 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A25D498C83 for ; Sat, 3 Sep 2011 21:57:05 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sat, 03 Sep 2011 21:57:05 -0400 Message-ID: <9081.1315101425@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] ghc-02 vs grrc-00 examples X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 02:00:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable In case you haven't read both=20 draft-goyal-roll-rpl-compression-00 and draft-bormann-6lowpan-ghc-02 here are the numbers listedn for ROLL examples: GRRC: DIO: started at 87 bytes; compressed to 48 bytes, compression factor 1.81 DIO: started at 89 bytes; compressed to 50 bytes, compression factor 1.78 GHC: DIO: started at 92 bytes; compressed to 53 bytes, compression factor 1.74 DAO: started at 50 bytes; compressed to 27 bytes, compression factor 1.85 ND: started at 48 bytes; compressed to 26 bytes, compression factor 1.85 The compression rates are almost identical, and this is without using GHC's "contexts", which as far as I can tell is not well enough documented to understand. What I do not know if how the two sample packets compare: are they even close to expressing the same thing. In particular the GRRC document does not list the *actual* packet contents, since GRRC is not sensitive to the actual field contents. As such I will be taking Bormann's packets, plus some from Contiki.=20 (Hmm. I only brought one econotag to the cottage) IF YOU HAVE PCAP TRACES OF ROLL PACKETS PLEASE SEND THEM, AS MY SAMPLES ARE TOO SIMPLE!!! =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATmLa8YCLcPvd0N1lAQKlJwf/dfLhfXnoL/R7aCNHFEOhXpGk2NkiKXLv NaYSxdAid4lgCa09h6goPBUBkN5Qg8dzX3Ng3ie8bMu6u9ip03eJxNGfSDSj0ftY UYRfOEUm+yl1jORV9tNxWHDHik8eMkodUE3gPXJIhP2oSf7KF+5VWxKeFk8BJzUh KapUDMrq4W4nCeAaN+O6YW/HmW8w9SHkM/cyZ62/G7e9PXEw03bru10foarGQD8w MgEdVbJkMiDFJGIB8iwISYFQmb9dm38e/+Exk3kE7CM9jnWkTC9JWcC+98IMQ5mO 0EqBNOCaxgVJLJxyjvvzlzr8DJQ/UOiW4AYYWc6kIBJBUJRrNBKbnw== =qxYY -----END PGP SIGNATURE----- --=-=-=-- From prvs=221503ad7=mukul@uwm.edu Sat Sep 3 19:42:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208AF21F886D for ; Sat, 3 Sep 2011 19:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, FRT_ROLEX=3.878, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OO8Bq0z-RLo for ; Sat, 3 Sep 2011 19:42:29 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5675D21F8841 for ; Sat, 3 Sep 2011 19:42:29 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 03 Sep 2011 21:44:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 6C2334E8986; Sat, 3 Sep 2011 21:44:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhQFJyXE23qS; Sat, 3 Sep 2011 21:44:08 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5655AE6A70; Sat, 3 Sep 2011 21:44:08 -0500 (CDT) Date: Sat, 3 Sep 2011 21:44:08 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <2078013874.185217.1315104248233.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <9081.1315101425@marajade.sandelman.ca> 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.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] ghc-02 vs grrc-00 examples X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 02:42:30 -0000 Hi Michael Since GHC performance depends on actual packet contents, you would need to use a variety of examples - some showing the best performance GHC is capable of and others where the performance is not so good. Then we have to come up with examples which we could consider as the common case and see how GHC performs for them. I am looking forward to your results eagerly. Regards Mukul ----- Original Message ----- From: "Michael Richardson" To: roll@ietf.org Sent: Saturday, September 3, 2011 8:57:05 PM Subject: [Roll] ghc-02 vs grrc-00 examples In case you haven't read both draft-goyal-roll-rpl-compression-00 and draft-bormann-6lowpan-ghc-02 here are the numbers listedn for ROLL examples: GRRC: DIO: started at 87 bytes; compressed to 48 bytes, compression factor 1.81 DIO: started at 89 bytes; compressed to 50 bytes, compression factor 1.78 GHC: DIO: started at 92 bytes; compressed to 53 bytes, compression factor 1.74 DAO: started at 50 bytes; compressed to 27 bytes, compression factor 1.85 ND: started at 48 bytes; compressed to 26 bytes, compression factor 1.85 The compression rates are almost identical, and this is without using GHC's "contexts", which as far as I can tell is not well enough documented to understand. What I do not know if how the two sample packets compare: are they even close to expressing the same thing. In particular the GRRC document does not list the *actual* packet contents, since GRRC is not sensitive to the actual field contents. As such I will be taking Bormann's packets, plus some from Contiki. (Hmm. I only brought one econotag to the cottage) IF YOU HAVE PCAP TRACES OF ROLL PACKETS PLEASE SEND THEM, AS MY SAMPLES ARE TOO SIMPLE!!! -- ] 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 d.sturek@att.net Sun Sep 4 06:19:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3966E21F876F for ; Sun, 4 Sep 2011 06:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE9s6PvFBU5f for ; Sun, 4 Sep 2011 06:18:57 -0700 (PDT) Received: from nm14.access.bullet.mail.sp2.yahoo.com (nm14.access.bullet.mail.sp2.yahoo.com [98.139.44.141]) by ietfa.amsl.com (Postfix) with SMTP id B38F321F8760 for ; Sun, 4 Sep 2011 06:18:57 -0700 (PDT) Received: from [98.139.44.104] by nm14.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2011 13:20:33 -0000 Received: from [98.139.44.65] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 04 Sep 2011 13:20:33 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 04 Sep 2011 13:20:33 -0000 X-Yahoo-Newman-Id: 453538.41110.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 42191 invoked from network); 4 Sep 2011 13:20:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1315142432; bh=JokksPfML2i3xUCk5s0zduwCJohlOMtJP5hULvWU5rE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=IkugMX0Ee6s0JbK1efR8weeFRnw4fxBsz/1ZwRT8iy8WflLLbWu57VquUkHFsN/zAoqlHb0eiec489hXoY527BBN7r6tVLn/zDCsEGs9IRem90yKR44c4QrG7lBqVXp5MnR/J0uEHlyZ9Bw5aAisUIiPcYfc2rsp3FKLWH8AR8Y= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mZL0aAMVM1n06xoXfEzT26Q6J4zvCmyi2m2kyIKY0gky9R9 5uA5yhLmk0Vfh8lwA.Lm1Cl6.QY9cnuDpKh_9UPCC71tj1_vtVJhwCrIhQzX lU7wHs3QK2RhpxTOKOvn7K86OthlMPxIAXbO5FgtSQ5jWW21Zjz0ek9jQzYr zO3qvQitwLrLMvJgLCHB6Zwd_HIyIK8PJpnMQnlKbHKVHHqtRG5xUNO4XKrj TuAUQEayh7dHzvHkoBHPTvuD3_RvTayEE_6zdib2xM_QyJ.CUt_af4munBQt StHzQ7qPjOztmEnRLM3Cn..P6vDQuJDt9x9YKRVSYi4NnsO0F74CpUZWWa2N OvdOJce1SExGjMBRl3EDtpKcBpdL5AIljGoMgslWnBtqVCOm0rXwITYfQaXE FJFdgib69iw_QEFncdxo- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.137.36 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 04 Sep 2011 06:20:31 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Sun, 04 Sep 2011 06:20:27 -0700 From: Don Sturek To: Ietf Roll , JP Vasseur , Thomas Heide Clausen Message-ID: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document In-Reply-To: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3397962031_1096695" Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 13:19:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3397962031_1096695 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Here are a few points to maybe consider: 1) ZigBee is not "having problems making it work" (referring to ROLL RPL. I chair the group in ZigBee testing "ZigBee IP" and we have had relatively good success using RPL for the use cases we are considering. 2) The Smart Energy 2.0 use cases are for only 30 devices in a single hom= e area network. We are testing 30 nodes with 3 hops 3) The upward routing feature in RPL is quite efficient. The downward routing feature either assumes storing mode (which we don't use) or non-storing mode with source routing (which does not offer pro-active or re-active route establishment). 4) I personally would not use ROLL RPL as it is for low latency applications like lighting control, home automation, etc. I fully support the ROLL RPL P2P draft for these applications. On additional, perhaps related topics: 5) I don't believe there will be only a single mesh routing protocol defined for all applications in IETF. I fully support the work going on in MANET and also think "mesh under" solutions will also be useful for some applications And finally: 6) All this said, I think ZigBee IP will successfully conclude testing using ROLL RPL=8A=8A=8A=8A Happy to sign my real name, Don Sturek From: Ietf Roll Reply-To: Ietf Roll Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT) To: JP Vasseur , Thomas Heide Clausen Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document JP Vasseur wrote: *if* you think that this not elegant enough (which has to be demonstrated IMO), then you must be supportive of the P2P IDs work that the WG has been working on ? [rav] how about a demonstration that RPL actually works as purported. Thomas has said that his group implemented it and it was difficult, complex and fraught with inconsistencies in specification. I heard that zigbee is having problems making it work and the only paper that I've seen on RPL says that for constrained nodes they recommend no more than 30 nodes in a network. Hardly the scale necessary for some of the=20 use cases been suggested (like AMI). The P2P is a hack to try to fix the fact the RPL is basically a collection tree and as such downward routing is an distant after thought (certainly not elegant). Without lots of memory, node must use non-storing mode (oh and we are talking about constrained devices so lots of memory is then inconsistent) and then routing is up to the root and back down. Not what anyone who understands routing would consider elegant P2P. In the rush to get RPL out of the working group we all were bamboozled by the chair into believing the draft was actually complete and the IESG further compounded this error. If it were possible to fix things, RPL should be an experimental draft until such time as there are working interoperable implementations that are shown to provide the services that were required in the various Use-case drafts - or even just one of them. And now we are rushing to generate and publish a marketing documen= t (called an applicability statement) without having any experience with the protocol. Are we rushing and putting so much pressure and bending the system= s so that this gets published before we find we've built a house of cards and it comes crashing down. This will be really counter productive to the industry and the Internet (certainly not Thomas's warnings). When everyone looks at this mistake and says, why didn't the IETF do its job and exercise proper engineering, then the ROLL WG and the Chairs will be the ones that have hurt the industry and the Internet. Rav _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --B_3397962031_1096695 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Here are a few points to may= be consider:
1)   ZigBee is not "having problems making it wo= rk" (referring to ROLL RPL.   I chair the group in ZigBee testing "ZigB= ee IP" and we have had relatively good success using RPL for the use cases w= e are considering.
2)   The Smart Energy 2.0 use cases are fo= r only 30 devices in a single home area network.   We are testing 30 no= des with 3 hops
3)   The upward routing feature in RPL is qui= te efficient.  The downward routing feature either assumes storing mode= (which we don't use) or non-storing mode with source routing (which does no= t offer pro-active or re-active route establishment).
4)   I = personally would not use ROLL RPL as it is for low latency applications like= lighting control, home automation, etc.   I fully support the ROLL RPL= P2P draft for these applications.

On additional, p= erhaps related topics:
5)  I don't believe there will be only= a single mesh routing protocol defined for all applications in IETF.  = I fully support the work going on in MANET and also think "mesh under" solut= ions will also be useful for some applications

And = finally:
6)  All this said, I think ZigBee IP will successful= ly conclude testing using ROLL RPL…………
Happy to sign my real name,

Don Sturek<= /div>




From: Ietf Roll <ietfroll@yahoo.com>
Reply-To: = Ietf Roll <ietfroll@yahoo.com= >
Date: Sat, 3 Sep 2011 00:= 54:25 -0700 (PDT)
To: JP Vasseur &= lt;jpv@cisco.com>, Thomas Heide Clause= n <ietf@thomasclausen.org>=
Cc: roll WG <roll@ietf.org>
Subjec= t: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLL WG document

JP Vasseur wrote:
<= div id=3D"yiv1740105533">

*if* you think that this not elegant en= ough (which has to be demonstrated IMO), then you must be supportive
of the P2P IDs work that the WG has been working on ?

[rav] how about a demonstration that RPL actually works as purported. = Thomas has said that his group implemented it and it was difficult, complex= and fraught with inconsistencies in specification.
   &nb= sp;     I heard that zigbee is having problems making it= work and the only paper that I've seen on RPL says that for constrained nod= es they recommend no more than 30 nodes in a network.  Hardly the scale necessary for s= ome of the
         use cases be= en suggested (like AMI).

       &n= bsp; The P2P is a hack to try to fix the fact the RPL is basically a collect= ion tree and as such downward routing is an distant after thought (certainly= not elegant).

         Witho= ut lots of memory, node must use non-storing mode (oh and we are talking abo= ut constrained devices so lots of memory is then inconsistent) and then rout= ing is up to the root and back down.  Not what anyone who
 &nbs= p;       understands routing would consider el= egant P2P.

         In the ru= sh to get RPL out of the working group we all were bamboozled by the chair i= nto believing the draft was actually complete and the IESG further compounded this error.

     &= nbsp;   If it were possible to fix things, RPL should be an experi= mental draft until such time as there are working interoperable implementati= ons that are shown to provide the services that were required in the various= Use-case
         drafts - or ev= en just one of them.

        = And now we are rushing to generate and publish a marketing document (called= an applicability statement) without having any experience with the protocol= .

         Are we rushing and= putting so much pressure and bending the systems so that this gets publishe= d before we find we've built a house of cards and it comes crashing down.
         This will be really co= unter productive to the industry and the Internet (certainly not Thomas's warnings).  When everyone looks at this mista= ke and says, why didn't the IETF do its job and exercise proper engineering,= then the ROLL WG
          = and the Chairs will be the ones that have hurt the industry and the Internet= .

Rav

______________= _________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/m= ailman/listinfo/roll --B_3397962031_1096695-- From mcr@sandelman.ca Sun Sep 4 09:09:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BFE21F855D for ; Sun, 4 Sep 2011 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.688 X-Spam-Level: * X-Spam-Status: No, score=1.688 tagged_above=-999 required=5 tests=[AWL=2.650, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3LOhGqCMsDZ for ; Sun, 4 Sep 2011 09:09:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F3AFB21F855A for ; Sun, 4 Sep 2011 09:09:22 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.85.219.206]) by relay.sandelman.ca (Postfix) with ESMTPS id 9AB81342F6 for ; Sun, 4 Sep 2011 12:10:17 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8FA8098C7A for ; Sat, 3 Sep 2011 22:36:15 -0400 (EDT) From: Michael Richardson To: roll WG In-Reply-To: <1128231318.183084.1315061250217.JavaMail.root@mail05.pantherlink.uwm.edu> References: <1128231318.183084.1315061250217.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sat, 03 Sep 2011 22:36:15 -0400 Message-ID: <16050.1315103775@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 16:09:27 -0000 >>>>> "Mukul" == Mukul Goyal writes: Mukul> There was a lot of opposition to adding more stuff to core Mukul> RPL. The (valid) argument was that any further additions Mukul> would be introduced as supplementary documents. Now that core Mukul> RPL is (almost) done, objections in the name of Mukul> interoperability are being raised to deny useful extensions Mukul> of the protocol and even to attack the core protocol Mukul> itself. I find it to be a sorry state of affairs. The issue Mukul is that GRRC is not an addition to RPL, it is a replacement. (I don't know who "IetfRoll@yahoo.com" is, it would be nice if you could use a real name, or at least use a useful pseudonym) -- ] 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 Sun Sep 4 09:12:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE9221F862F for ; Sun, 4 Sep 2011 09:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=1.821, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KER4HPXxxdNY for ; Sun, 4 Sep 2011 09:12:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B159D21F855D for ; Sun, 4 Sep 2011 09:12:13 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.85.219.206]) by relay.sandelman.ca (Postfix) with ESMTPS id E490D3432E; Sun, 4 Sep 2011 12:13:12 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6F6E098411; Sun, 4 Sep 2011 12:14:22 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <2078013874.185217.1315104248233.JavaMail.root@mail05.pantherlink.uwm.edu> References: <2078013874.185217.1315104248233.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 04 Sep 2011 12:14:22 -0400 Message-ID: <20670.1315152862@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] ghc-02 vs grrc-00 examples X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 16:12:14 -0000 >>>>> "Mukul" == Mukul Goyal writes: Mukul> Since GHC performance depends on actual packet contents, you Mukul> would need to use a variety of examples - some showing the Mukul> best performance GHC is capable of and others where the Mukul> performance is not so good. Then we have to come up with Mukul> examples which we could consider as the common case and see Mukul> how GHC performs for them. I am looking forward to your Mukul> results eagerly. GRRC also depends upon the contents of the packets. It depends upon the assumption that there are fields which are never used in practice. It would be very helpful if you could send pcap captures of rpl-19 format DIO messages which you have applied your re-encoding to. -- ] 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 prvs=221503ad7=mukul@uwm.edu Sun Sep 4 16:34:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5221F86C2 for ; Sun, 4 Sep 2011 16:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[AWL=1.497, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xox49pm0scfp for ; Sun, 4 Sep 2011 16:34:07 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8D21F86AB for ; Sun, 4 Sep 2011 16:34:07 -0700 (PDT) Received: from localhost (HELO mta01.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 04 Sep 2011 18:35:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0DA56E6A74; Sun, 4 Sep 2011 18:35:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3uI+hCIbX3D; Sun, 4 Sep 2011 18:35:49 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 8CEE0E6A70; Sun, 4 Sep 2011 18:35:49 -0500 (CDT) Date: Sun, 4 Sep 2011 18:35:49 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <16050.1315103775@marajade.sandelman.ca> 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.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Sep 2011 23:34:08 -0000 Michael It is not a replacement. It is an optional feature. This feature is to be used in deployments that consider it to be useful. Such deployments would probably have all devices implement this feature. Or such deployments would be OK with the fact that any devices that do not implement this feature would not be able to talk to the devices that do. Other deployments need not use this feature. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "roll WG" Sent: Saturday, September 3, 2011 9:36:15 PM Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document >>>>> "Mukul" == Mukul Goyal writes: Mukul> There was a lot of opposition to adding more stuff to core Mukul> RPL. The (valid) argument was that any further additions Mukul> would be introduced as supplementary documents. Now that core Mukul> RPL is (almost) done, objections in the name of Mukul> interoperability are being raised to deny useful extensions Mukul> of the protocol and even to attack the core protocol Mukul> itself. I find it to be a sorry state of affairs. The issue Mukul is that GRRC is not an addition to RPL, it is a replacement. (I don't know who "IetfRoll@yahoo.com" is, it would be nice if you could use a real name, or at least use a useful pseudonym) -- ] 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 mcr@sandelman.ca Sun Sep 4 19:10:22 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9609521F85F2 for ; Sun, 4 Sep 2011 19:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5ed8B5JHJpS for ; Sun, 4 Sep 2011 19:10:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E8A5F21F8760 for ; Sun, 4 Sep 2011 19:10:21 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.85.219.44]) by relay.sandelman.ca (Postfix) with ESMTPS id 52EA134319 for ; Sun, 4 Sep 2011 22:11:11 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 0290A98C7A for ; Sun, 4 Sep 2011 21:54:40 -0400 (EDT) From: Michael Richardson to: roll@ietf.org In-Reply-To: <9081.1315101425@marajade.sandelman.ca> References: <9081.1315101425@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Sep 2011 21:54:39 -0400 Message-ID: <9984.1315187679@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] ghc-02 vs grrc-00 examples X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 02:10:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I am attempting to construct an RPL message according to the criteria in GRRC section 5.1. Some comments on the GRRC. If we go this direction, we need to fix some of these things. - there is no reason for the Rouer Information Option to be 24 bytes. It can easily be 16 bytes in an uncompressed packet, as long as we are dealing with normal subnets, a /64 so we can elide 8 bytes of the prefix. This means that the size is not 87 bytes, but in fact 79 bytes. The compressed size is not 48 bytes, but 40.=20 - the 40 bytes best case has pretty much everything turned off, or perhaps taken from a "context". This is very significant to me, as it means that in fact everything is either provisioned, or must be defaults. This concerns me greatly, as it significantly limits the ability to tweak values. Yes, you can tweak a few values at a time, and I guess if they work, then one can update the context. - the Metric objects all have implicit length. We have only defined=20 types 0-5. types 6, and 7 are undefined. Should they be defined,=20 older implementations will not know how big they are, they should always be placed last, as processing could stop at the first object that is unknown. - I can't see how the DTSN can be taken from a context. It needs to be either transmitted, or be zero. In particular, as is pointed out in draft-dvir-roll-security-extensions, increasing the sequence number is the only response available to a bogus DIO message in the network.=20 - rpl-19 does no define a defaul value for MaxRankIncrease. What it says is that if 0, this mechanism is disable. GRRC will need to be more clear, perhaps defining a default when I1=3D0. - ditto for LifeTime Unit/Default Lifeime, rpl-19 does not define a default lifetime or lifetime unit as far as I can see. - (I am rather ignorant of metrics, suggestions welcome) So I have as my inputs. (for those using Lookout, pick a fixed width font) I'm interested in this email if you think my assumptions are wrong. ORIGINAL PACKET: 00000000: 9b01 7a5f=20 DIO base 8000 0007 0000 0000 0000 0000 ..z_........ ... 00000010: 0000 0000 0000 0000 0000 face=20=20=20=20=20=20=20=20=20=20=20=20 DODAG cfg option 040e 0014 ................ 00000020: 030a 0000 0100 0000 0000 0000=20 ROUTE INFO 0316 4000 ...............=20 00000030: 0001 5180 2001 4830 16ca 0001 0000 0000 ............ ... 00000040: 0000 0000=20 METRIC 020c=20 metric 1 0700 6002 0102=20 constraint 2 0402 6002 1000=20 summary: 00000000: 9b01 7a5f 8000 0007 0000 0000 0000 0000=20 00000010: 0000 0000 0000 0000 0000 face 040e 0014=20 00000020: 030a 0000 0100 0000 0000 0000 0316 4000 00000030: 0001 5180 2001 4830 16ca 0001 0000 0000 00000040: 0000 0000 020c 0700 6002 0102 0402 6002 00000050: 1000=20 DIO Base 4 bytes base object, 2 header, 2 bytes for DODAGID. must be: C=3D0 - no context. I=3D0 - use context? L=3D1 - implicit value 128. V=3D0 - implicit value 0. R=3D1 - 4-bit rank. G=3D0 - Ground value=3D0, MOP=3D0 (non-storing), Pref=3D= 0. T=3D0 - DTSN field (HOW CAN THIS BE OMITTED?) F=3D0 - no flags, no reserved. Ra=3D0x7 - Rank value. Compr=3D14 - 2 bytes DODAGID. DODAGID - 0xfa 0xce results in: 0x28 0x7e 0xfa 0xce DODAG cfg option, 2+1. F =3D 0 - flags, A and PCS fields are zero. T1=3D 0 - DIOIntervalDoublings - default value. (from rpl= -19) T2=3D 0 - DIORedundancyConstant- default value. (from rpl= -19) I1=3D 0 - MaxRankIncrease. default value I2=3D 0 - MinHopRankInc. default value O =3D 0 - RPL Object Function 0 used. R =3D 0 - no reserved field. L =3D 0 - Default Lifetime is elided. results in: 0x84 0x03 0x00 ROUTE INFO, 24 bytes. results in: 0x03 0x16 0x40 0x00 0x00 0x01 0x51 0x80 <- lifetime, 86400s value. 0x20 0x01 0x48 0x30 2001:4830:16ca:1::/64 0x16 0xca 0x00 0x01 0x00 0x00 0x00 0x00 <- should be omitted. 0x00 0x00 0x00 0x00 METRIC 8 bytes, 2+3+3. 0x82 0x06 header. object1: T=3D5 ETX Object C=3D0 metric P1/P2=3D00 highest precedence A=3D0x03 multiplicative data: 0xa3 0x01 0x02 object2: T=3D3 throughput (made up) C=3D1 constraint=20=20=20=20=20=20=20=20=20=20 O=3D1 optional P2/A=3D0 data: 0x60 0x10 0x00 (1 kib/s) RESULTING PACKET 00000000: 9b01 7a5f ICMP 00000004: 287e face DIO Base 00000008: 8403 00 DODAG cfg 0000000b: 0316 4000 0001 5180 2001 4830 16ca 0001 ROUTE INFO (2001:4830:16= ca:1::/64) 0000001b: 0000 0000 0000 0000 METRIC 00000023: 8206 a301 0260 1000 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATmQr34CLcPvd0N1lAQIeWQgAqdyjYr+TH6AhfTR3DxF3NBBpI9ctggBp m4UBHuv8JPjsCz2KOSpPVQGt9Wxklad92bwfpwpmpngfneskinf4O+XvHnaMzghr SPtcI5HKv6Fquh2VyAhdBXIykRqfEJpNqEB9twINFZa2H7YSoaI/JZKXy2alKUCq D9rXUq3Z4ibgUZaEOCUVnmUgZ3sY+XiEnWyY1uNRhYnOBYpizrDdOrxVTYtK0+tE CJL9HCPozgPRL5kKjFBFvMri9tNTNdI4EGbsdKEiBgF7BbAWPBpUfHsvoE2/neRR CzI1sRhjqeIKXApMgE4x1pP0K4I64KZHJ+Tkj6aqldmhnrISYdvmQg== =CIAP -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Sep 4 19:10:22 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14F921F876F for ; Sun, 4 Sep 2011 19:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z3fnVQfVrNJ for ; Sun, 4 Sep 2011 19:10:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E899C21F8751 for ; Sun, 4 Sep 2011 19:10:21 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [208.85.219.44]) by relay.sandelman.ca (Postfix) with ESMTPS id 9626134342 for ; Sun, 4 Sep 2011 22:11:11 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2E2FD98C7F for ; Sun, 4 Sep 2011 22:10:00 -0400 (EDT) From: Michael Richardson to: roll@ietf.org In-Reply-To: <9984.1315187679@marajade.sandelman.ca> References: <9081.1315101425@marajade.sandelman.ca> <9984.1315187679@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Sep 2011 22:10:00 -0400 Message-ID: <12115.1315188600@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] ghc-02 vs grrc-00 examples X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 02:10:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable The result of running a "reasonable" packet, consistent with Example 5.1 From=20GRRC, outlined in previous message, through a most-primitive,=20 single pass GHC compressor. You can see my code at: See: https://github.com/mcr/roll-ghc "make check" to run two packets through it. Packet #2 is in the previous email. This code gets 1.46 ratio, actually better than on Bormann's example packet, which was probably more pessimistic about packets contents. (he has a DAO example as well). RUNNING 01-bormann ...Input 92 Output 69 ratio=3D133%...SUCCEEDED. RUNNING 02-grrc ...Input 82 Output 56 ratio=3D146%...SUCCEEDED. My code does not make use of the GHC nibble mode (probably not relevant except for CoAP), nor of the the contexts, nor does it extract from the pseudo-header values, nor does it look for sequences to repeat longer than 2 bytes. (I know that in case 01- there is a sequence of 0xff, that is two bytes longer than necessary) I think it's important that we can get almost as good results with a VERY stupid application of -02 GHC. It's quite possible that an aware RPL encoder could encode directly to GHC, perhaps using the pseudo-header, and certainly using the HC contexts, which are already assumed to be present.=20=20 The GHC code may already be there and can be applied to CoAP. The other advantage for GHC is that it means that all nodes continue to have a full RPL decoder, so there is no issue of whether or not a product (or a SKU of one) will interoperate out of the box. =3D=3D=3D=3D input packet: 00000000 9b 01 7a 5f 80 00 00 07 00 00 00 00 00 00 00 00 |..z_..........= ..| 00000010 00 00 00 00 00 00 00 00 00 00 fa ce 04 0e 00 14 |..............= ..| 00000020 03 0d 00 00 01 00 00 00 00 00 00 00 03 16 40 00 |..............= @.| 00000030 00 01 51 80 20 01 48 30 16 ca 00 01 00 00 00 00 |..Q. .H0......= ..| 00000040 00 00 00 00 02 0c 07 00 60 02 01 02 04 02 60 02 |........`.....= `.| 00000050 10 00 |..| 00000052 output packet: 00000000 05 9b 01 7a 5f 80 80 01 07 90 08 fa ce 04 0e 00 |...z_.........= ..| 00000010 14 03 0d 80 01 01 85 03 03 16 40 80 0b 01 51 80 |..........@...= Q.| 00000020 20 01 48 30 16 ca 00 01 86 0d 02 0c 07 00 60 02 | .H0..........= `.| 00000030 01 02 04 02 60 02 10 90 |....`...| 00000038 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATmQvd4CLcPvd0N1lAQJ19Qf+NH0hXjQ69SuB13WmKWik8KL8tjz2A1Qm CN8MXaKkmWos3Ivqoa2R/eLYcSwgQ3FerlkS3DgoHtAseytYMltls9RDX4Jcmdiq b12v0jv/nsQm8B/n97tEkAJ/ep4vepNcwsuvbw1TLXFIO6n1kRX45RXpfe395DqH uGMrMbXPemracpMMxXEKNn7KLA2K1UquMb+DzGkBEXncKjzOSLtr+IVuIz8iav4P DmvxRHc+FkrwPG7MU2DqR2wqv51vRz30G8rkmKIkBpAfmitB/F/+YP/uFgWruAMe nGPmIDMKF+F1brMrOaD8ArhD4s0eYuXvuJBsxtxDJtMVHt1W5y2Ifg== =824E -----END PGP SIGNATURE----- --=-=-=-- From pthubert@cisco.com Mon Sep 5 02:12:34 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23AC21F8B05 for ; Mon, 5 Sep 2011 02:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.369 X-Spam-Level: X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHmep1Z4Xu2t for ; Mon, 5 Sep 2011 02:12:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B552F21F8B04 for ; Mon, 5 Sep 2011 02:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4893; q=dns/txt; s=iport; t=1315214056; x=1316423656; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=CEul5PsTAtpu+77h2CUH8eFHIO7NWNlm9IgxTazXzwg=; b=MnfkYdeZ+ycKoMfJZug8GxaDtpzD5O6oyE1PEJ5gFEVfESlPtLvSNdiR EVtDpmlxhhxU7pwKPEOVnGcGSsGPS2iFeywLF0lHSToCb8CUl//QJ7uRn 3QGrYA3dqEtlH+KnrR6svRfKiiNXOFsznRX9cYXBBnZ9cqZ5pDQOuInUR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0QABKSZE6Q/khN/2dsb2JhbABClACUUQZygT8HAQEBAQIBEgEdCjgHBQcEAgEIDgMEAQELBhcBBgEgJQkIAQEEEwgTB4dRmQUBnheGCmAEmEaEZIcT X-IronPort-AV: E=Sophos;i="4.68,332,1312156800"; d="scan'208";a="113941478" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Sep 2011 09:14:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p859EFBd031438; Mon, 5 Sep 2011 09:14: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); Mon, 5 Sep 2011 11:14:15 +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, 5 Sep 2011 11:14:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0565D61A@XMB-AMS-107.cisco.com> In-Reply-To: <7C4F28D7-84C5-4745-9B48-8D278E189322@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question/clarification about applicability of OF0 Thread-Index: AcxqgVKwUXFamXNuQoOLstAUF5rF8wBKUU9w References: <3D21B0E7-C9D1-4335-B849-87DF61B2D6CD@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D053A3D61@XMB-AMS-107.cisco.com> <7C4F28D7-84C5-4745-9B48-8D278E189322@gmail.com> From: "Pascal Thubert (pthubert)" To: "Ralph Droms" X-OriginalArrivalTime: 05 Sep 2011 09:14:15.0577 (UTC) FILETIME=[2F1B5890:01CC6BAC] Cc: roll@ietf.org Subject: Re: [Roll] Question/clarification about applicability of OF0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 09:12:35 -0000 Hi Ralph: I agree with your point.=20 We have in one hand the classical links where the cost is usually a direct and constant relation to the speed. And in the other, links with properties that vary over time.=20 Clearly, most classical wires fall in the first category, and most wireless fall in the other. Yet they are not an exact match.=20 In any case, the distinction between wired and wireless is mostly gone from the spec; it appears in a snippet that is only an illustration of a point: " The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. " I'll be happy to change that to " The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or high-speed wire over lower-speed wireless, within a same DAG. " What do you think? Pascal -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 Sent: samedi 3 septembre 2011 23:35 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] Question/clarification about applicability of OF0 On Aug 10, 2011, at 1:03 AM 8/10/11, Pascal Thubert (pthubert) wrote: > Hi Ralph >=20 >> OF0, when it generates a rank_increase based on hop count, is > characterized >> as inappropriate for wireless meshes. I wonder if "wireless" is > really the right >> descriptive term here. More generally, a hop count metric is > inappropriate >> for subnets composed of links in which a route with a higher hop=20 >> count > might >> perform better than a router with a lower hop count. Such subnets=20 >> can > be >> either wireless or wired; for example, as I understand the=20 >> technology, > it's >> possible for an IEEE1901.2 network to exhibit connectivity and > transmission >> quality characteristics for which a route through more higher quality > hops >> might be better than a router through fewer lower quality hops. >=20 > [Pascal] You're correct. > OF0 does not know the type of link it can be applied to so it leaves=20 > the computation of the step_of_rank to the implementation that knows better. I'm not sure I made my point clearly. I think the terms "wireless" and "wired" are inaccurate in describing the two kinds of links; "equal cost" and "variable cost" would be more accurate. 802.11 provides wireless links but, in usual deployments, my understanding is that they are essentially equal cost. At the same time, wired links - e.g. IEEE1901.2 - can have variable cost. - Ralph >> I'm also confused about some of the use cases for RPL. Is there a=20 >> use > case in >> which RPL would be used in a non-LLN environment in place of other > routing >> protocols like RIP, OSPF and ISIS? >=20 > [Pascal] RPL is a DV routing protocol. It has the pros and cons of its > family. But yes, it could apply in many places. It is a matter of=20 > network engineering to select the most adapted tool for a given=20 > situation, knowing that: > -As opposed to the classical bunch, it does not compute the optimal=20 > end to end path for all nodes. > -RPL does not try to fix any broken situation as soon as it occurs.=20 > -RPL requires looking inside the packets for datapath validation, and=20 > RPL adds a (set of) L3 "VLANs" we call instances >=20 > If you look at it, a spanning tree is not much different, just a lot=20 > simpler (just a tree, no TTL). > So in a situation where a (mesh_under) spanning tree is used today a > (route_over) RPL solution could actually provide a positive replacement. > Benefits would be: > - no risk of meltdown (that's TTL for you) thus faster convergence. > - end to end IP (that's route_over vs. mesh_under) > - multipath ( that's coming from RPL's DAG) > - Goal (the root is picked at a sensible place) >=20 > Another example: If you have a number of access points at home, and=20 > you want to mesh them, then the link quality is asserted by the=20 > association process so hop count could work. You'll note that with hop > count, a cost is traditionally associated to link speed and that would > apply too since WIFI reduces the link speed to maintain the link=20 > quality. This is a case where RPL could easily replace a proprietary=20 > mesh technology, either using (hop count, line speed), something a bit > fancier, like ETX, or something more proprietary if that can provide a > market advantage. OF0 will allow all those to interoperate and you'll=20 > get a DAG that reaches the goal, if that's possible at all. >=20 > Cheers, >=20 > Pascal From angelo.castellani@gmail.com Mon Sep 5 06:44:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB33B21F8A67 for ; Mon, 5 Sep 2011 06:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2-oKoBKnnwx for ; Mon, 5 Sep 2011 06:44:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 446A121F8B24 for ; Mon, 5 Sep 2011 06:44:37 -0700 (PDT) Received: by wyg8 with SMTP id 8so4419009wyg.31 for ; Mon, 05 Sep 2011 06:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=VLkO79ORrTdrtH+9DJ98bCYa5QINlvzeDiDri0jmbOM=; b=jbWTNg4Ifo5whmei0dE9rWV76FIzuOauALVSprAuj0Fj+SxulVQaxVNcQFEuE89o6G OSxn5r1dmzKZ/JoAqCXZEarY5elBo6/J++e9zYgnITnoCpafshYT31lDSyTQ1S+rdt+7 9/g8K4Vv9naSko/rzT26PYOxdgaWHayMBUErU= Received: by 10.216.166.20 with SMTP id f20mr11778wel.51.1315230373180; Mon, 05 Sep 2011 06:46:13 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Mon, 5 Sep 2011 06:45:52 -0700 (PDT) In-Reply-To: <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> References: <16050.1315103775@marajade.sandelman.ca> <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Angelo P. Castellani" Date: Mon, 5 Sep 2011 15:45:52 +0200 X-Google-Sender-Auth: RNngpD1ql1Tqd6EAytt6osTWGNQ Message-ID: To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 13:44:43 -0000 On Mon, Sep 5, 2011 at 01:35, Mukul Goyal wrote: > Such deployments would probably have all devices implement this feature. = Or such deployments would be OK with the fact that any devices that do not = implement this feature would not be able to talk to the devices that do. Ot= her deployments need not use this feature. The same thing happens when there are 2 protocol competing for providing a similar feature. Usually leading to a period of time, before a de facto standard will emerge, where either: a) different implementation using different protocols don't interoperate b) both protocols have to be implemented for interopeability The point that some people is arguing is: - do we really need two different RPL dialects to exist? - if yes, do we want this even if this could lead to a similar situation of when two completely different protocols exist offering a similar feature? Best, Angelo From pthubert@cisco.com Mon Sep 5 06:59:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC75C21F8B68 for ; Mon, 5 Sep 2011 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.379 X-Spam-Level: X-Spam-Status: No, score=-10.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBCZpUrNf9be for ; Mon, 5 Sep 2011 06:59:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C7D0021F8B36 for ; Mon, 5 Sep 2011 06:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=725; q=dns/txt; s=iport; t=1315231288; x=1316440888; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=j+60h6LvDrKGoBCm1w87FPNWhyx95pFP4id2Oo3ooX4=; b=ZR9PdUnkrjpWMGsHaMZnfotCxRESuknPdYNuFTpvxEvu5Tk4ZlDrJi9e ejm9OtWR5LahLKWgcImjwIErg8PC61CEFgtvaMkaT/xQq61Wrz8yPVus+ F0+WV7ZOg6XsXzil4lZQrqqLTbknKYAu+Bdb6zJZyz2K/vb/RLeZg7RYH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANXUZE6Q/khL/2dsb2JhbABDDqgKeIFGAQEBAQMSAR0KPxACAQgiBhgGAVYBAQQBGhqheQGeSoYKYASYRos9Og X-IronPort-AV: E=Sophos;i="4.68,333,1312156800"; d="scan'208";a="113996110" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 Sep 2011 14:01:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p85E1PEn009615; Mon, 5 Sep 2011 14:01: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); Mon, 5 Sep 2011 16:01: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Sep 2011 16:01:24 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0565D771@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: Acxr0joExRY32bp+TQurtKV2go/qTQAAORAA References: <16050.1315103775@marajade.sandelman.ca><465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Angelo P. Castellani" , "Mukul Goyal" X-OriginalArrivalTime: 05 Sep 2011 14:01:25.0830 (UTC) FILETIME=[4D234E60:01CC6BD4] Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 13:59:44 -0000 Hello Angelo > - do we really need two different RPL dialects to exist? I, for one, do not. I think that once decompression has occurred, we should get RPL packets as defined in the spec.=20 If more than one compression method exist over a same MAC in a same network, or if nodes use compression and others do not, then we are in a situation that is equivalent to different MACs over the same band, or different cryptos. DIOs have to be sent twice, etc. So people will have to be careful as to when and how they deploy new stuff. It is probably preferable to limit the number of gateways that have to repeat their multicast DIOs over multiple networks. But that's a deployment issue. Cheers, Pascal From angelo.castellani@gmail.com Mon Sep 5 07:05:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6946A21F8B7B for ; Mon, 5 Sep 2011 07:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw6iBEBy-T3T for ; Mon, 5 Sep 2011 07:05:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF54521F8B73 for ; Mon, 5 Sep 2011 07:05:48 -0700 (PDT) Received: by wyg8 with SMTP id 8so4436462wyg.31 for ; Mon, 05 Sep 2011 07:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=D5t/9ZtRTwLg8ja5WlyEhCL8QAyd7tfBBshM1h6aQcQ=; b=XDIoYIUyhP8w43mAhH9wwdFab0qCRSmpN3jAES3oBuZk2EhfYWyauD+HbKKiu3z2sT ist2spC3D9BXbFkYzMBY8plirMiBCmidmVSSb/z/1l2y250Nmt789hT79fFS+ha0A+mA Vos5VYWYPoQySKcjxdrBZi4oF5FMATWd9WfqY= Received: by 10.216.24.42 with SMTP id w42mr2455777wew.36.1315231652504; Mon, 05 Sep 2011 07:07:32 -0700 (PDT) MIME-Version: 1.0 Sender: angelo.castellani@gmail.com Received: by 10.216.11.211 with HTTP; Mon, 5 Sep 2011 07:07:11 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0565D771@XMB-AMS-107.cisco.com> References: <16050.1315103775@marajade.sandelman.ca> <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0565D771@XMB-AMS-107.cisco.com> From: "Angelo P. Castellani" Date: Mon, 5 Sep 2011 16:07:11 +0200 X-Google-Sender-Auth: rY_ycwqMA905r38AwNMWGaRr284 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:05:49 -0000 On Mon, Sep 5, 2011 at 16:01, Pascal Thubert (pthubert) wrote: > Hello Angelo > >> - do we really need two different RPL dialects to exist? > > I, for one, do not. I think that once decompression has occurred, we > should get RPL packets as defined in the spec. > > If more than one compression method exist over a same MAC in a same > network, or if nodes use compression and others do not, then we are in a > situation that is equivalent to different MACs over the same band, or > different cryptos. DIOs have to be sent twice, etc. > > So people will have to be careful as to when and how they deploy new > stuff. It is probably preferable to limit the number of gateways that > have to repeat their multicast DIOs over multiple networks. But that's a > deployment issue. Why shouldn't we avoid this complexity defining, using a set of guidelines (e.g. if MAX_FRAME_SIZE X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F8521F8B9F for ; Mon, 5 Sep 2011 07:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqJFJCqgU-i9 for ; Mon, 5 Sep 2011 07:45:38 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 807E421F8B8C for ; Mon, 5 Sep 2011 07:45:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id CC6DC4300C3; Mon, 5 Sep 2011 07:47:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.111] (AMontsouris-651-1-188-133.w82-123.abo.wanadoo.fr [82.123.187.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id E2DC443006C; Mon, 5 Sep 2011 07:47:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_8722672C-9851-4EEA-BC01-56923FA7401A" From: Thomas Heide Clausen In-Reply-To: <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> Date: Mon, 5 Sep 2011 16:47:19 +0200 Message-Id: References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:45:39 -0000 --Apple-Mail=_8722672C-9851-4EEA-BC01-56923FA7401A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear JP, I am not sure I completely understand the question=85=85is this the WG = chair polling the group for adaptation as WG document? If yes, when do you plan on making a decision (so as to give a target as = to before when an opinion should have been formed?) Thomas On Aug 31, 2011, at 14:55 , JP Vasseur wrote: > Any comment ? >=20 > Thanks. >=20 > JP. >=20 > Begin forwarded message: >=20 >> From: JP Vasseur >> Subject: [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt >> Date: August 26, 2011 9:17:42 AM GMT+02:00 >> To: roll WG >>=20 >> Dear all, >>=20 >> Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you >> please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns >> out that the WG wants to adopt this ID, I'll poll the WG to make it a = WG =85 Please comment. >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> 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 --Apple-Mail=_8722672C-9851-4EEA-BC01-56923FA7401A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = JP,

I am not sure I completely understand the = question=85=85is this the WG chair polling the group for adaptation as = WG document?

If yes, when do you plan on = making a decision (so as to give a target as to before when an opinion = should have been = formed?)

Thomas

On Aug = 31, 2011, at 14:55 , JP Vasseur wrote:

Any comment = ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject: = [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt
Date: August 26, 2011 = 9:17:42 AM GMT+02:00
To: roll WG <roll@ietf.org>

Dear all,

Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you
please = comment on this I-D as soon as possible ? We need a key management = protocol and if it turns
out that the WG wants to adopt this ID, I'll = poll the WG to make it a WG =85 Please = comment.

Thanks.

JP.
____________________________________= ___________
Roll mailing list
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=_8722672C-9851-4EEA-BC01-56923FA7401A-- From jpv@cisco.com Mon Sep 5 07:51:55 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1425D21F8AE6 for ; Mon, 5 Sep 2011 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.382 X-Spam-Level: X-Spam-Status: No, score=-109.382 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWPTZaQiEzNj for ; Mon, 5 Sep 2011 07:51:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A31E721F8AD9 for ; Mon, 5 Sep 2011 07:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=6096; q=dns/txt; s=iport; t=1315234418; x=1316444018; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=5h/tjUDDMU4bk/hmj6YqMRPFp86Z526CjD2qNCGOEw8=; b=hp8+yi0JPYmFWQqqRPDcX8JOjEVzyu+208MlDxyme9SZmMW8uNmSTYmP Y7YuEoyPqI/kNBFyu28Tp0PCpOXvSu9O5ES2A+w/AOMT3UkbRQ6dnI7Xe xa/mAlyEq7eWiHfVw1hNwokZFoIvLQ5IGOXsI5geqJEC822NJV4s9+fVS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC7iZE5Io8UQ/2dsb2JhbABDqBh4gUYBAQEBAgEBAQEPAVsLBQsLEQMBAgEuJygIBhMih1EEmXkBnlCGCmAEky6FDwmLdw X-IronPort-AV: E=Sophos;i="4.68,333,1312156800"; d="scan'208,217";a="53274479" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 05 Sep 2011 14:53:33 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p85ErX80030077; Mon, 5 Sep 2011 14:53:33 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, 5 Sep 2011 20:23:33 +0530 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 20:23:32 +0530 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6639C82-F0EC-4A84-BF2B-5DEA74239846" From: JP Vasseur In-Reply-To: Date: Mon, 5 Sep 2011 16:53:30 +0200 Message-Id: References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 05 Sep 2011 14:53:32.0807 (UTC) FILETIME=[94F62170:01CC6BDB] Cc: roll WG Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:51:55 -0000 --Apple-Mail=_A6639C82-F0EC-4A84-BF2B-5DEA74239846 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Thomas, On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote: > Dear JP, >=20 > I am not sure I completely understand the question=85=85is this the WG = chair polling the group for adaptation as WG document? >=20 > If yes, when do you plan on making a decision (so as to give a target = as to before when an opinion should have been formed?) >=20 I was polling the WG to get some comment since we did not get a chance = to discuss it during the WG meeting, that was not yet a poll for WG adoption. Any opinion to share of this document ? Thanks. JP. > Thomas >=20 > On Aug 31, 2011, at 14:55 , JP Vasseur wrote: >=20 >> Any comment ? >>=20 >> Thanks. >>=20 >> JP. >>=20 >> Begin forwarded message: >>=20 >>> From: JP Vasseur >>> Subject: [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt >>> Date: August 26, 2011 9:17:42 AM GMT+02:00 >>> To: roll WG >>>=20 >>> Dear all, >>>=20 >>> Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you >>> please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns >>> out that the WG wants to adopt this ID, I'll poll the WG to make it = a WG =85 Please comment. >>>=20 >>> Thanks. >>>=20 >>> JP. >>> _______________________________________________ >>> 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 >=20 --Apple-Mail=_A6639C82-F0EC-4A84-BF2B-5DEA74239846 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Thomas,

On Sep 5, 2011, at 4:47 PM, Thomas Heide = Clausen wrote:

Dear = JP,

I am not sure I completely understand the = question=85=85is this the WG chair polling the group for adaptation as = WG document?

If yes, when do you plan on = making a decision (so as to give a target as to before when an opinion = should have been = formed?)


= I was polling the WG to get some comment since we did not get a chance = to discuss it during the WG meeting,
that was not yet a poll = for WG adoption.

Any opinion to share of this = document = ?

Thanks.

JP.
=

Thomas

On Aug 31, = 2011, at 14:55 , JP Vasseur wrote:

Any comment = ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject: = [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt
Date: August 26, 2011 = 9:17:42 AM GMT+02:00
To: roll WG <roll@ietf.org>

Dear all,

Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you
please = comment on this I-D as soon as possible ? We need a key management = protocol and if it turns
out that the WG wants to adopt this ID, I'll = poll the WG to make it a WG =85 Please = comment.

Thanks.

JP.
____________________________________= ___________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____= __________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll


= --Apple-Mail=_A6639C82-F0EC-4A84-BF2B-5DEA74239846-- From ietf@thomasclausen.org Mon Sep 5 09:06:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9046821F8B7E for ; Mon, 5 Sep 2011 09:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woEcOVjGduzm for ; Mon, 5 Sep 2011 09:06:00 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4121F8B5E for ; Mon, 5 Sep 2011 09:05:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AE9E14300EC; Mon, 5 Sep 2011 09:07:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.111] (AMontsouris-651-1-188-133.w82-123.abo.wanadoo.fr [82.123.187.133]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id BE1D84300A2; Mon, 5 Sep 2011 09:07:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_F0EEC050-765A-4EAA-A367-5F6B6BC38D5A" From: Thomas Heide Clausen In-Reply-To: Date: Mon, 5 Sep 2011 18:07:41 +0200 Message-Id: References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1244.3) Cc: roll WG Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 16:06:00 -0000 --Apple-Mail=_F0EEC050-765A-4EAA-A367-5F6B6BC38D5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear JP, Thanks. I have read the specification a couple of times, but as I am not = a key-management-expert, I have not (yet) formed any real opinions on = the technical content. I am still working on that bit ;) However as you message was cryptic, I wanted to make sure that I did not = miss any last-review-before-wg-document deadline. I understand that = there's no immediate deadline so I would suggest that the WG gets to = consider that when a determination has been made on the other ongoing = issues currently being discussed=20 [Not to belittle this document; I, for one, like most LLN routers just = have limited bandwidth and processing power=85.trying to make sure that = they are being used appropriately] Respectfully yours, Thomas On Sep 5, 2011, at 16:53 , JP Vasseur wrote: > Hi Thomas, >=20 > On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP, >>=20 >> I am not sure I completely understand the question=85=85is this the = WG chair polling the group for adaptation as WG document? >>=20 >> If yes, when do you plan on making a decision (so as to give a target = as to before when an opinion should have been formed?) >>=20 >=20 > I was polling the WG to get some comment since we did not get a chance = to discuss it during the WG meeting, > that was not yet a poll for WG adoption. >=20 > Any opinion to share of this document ? >=20 > Thanks. >=20 > JP. >=20 >=20 >> Thomas >>=20 >> On Aug 31, 2011, at 14:55 , JP Vasseur wrote: >>=20 >>> Any comment ? >>>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: JP Vasseur >>>> Subject: [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt >>>> Date: August 26, 2011 9:17:42 AM GMT+02:00 >>>> To: roll WG >>>>=20 >>>> Dear all, >>>>=20 >>>> Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you >>>> please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns >>>> out that the WG wants to adopt this ID, I'll poll the WG to make it = a WG =85 Please comment. >>>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>> _______________________________________________ >>>> 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 >>=20 >=20 --Apple-Mail=_F0EEC050-765A-4EAA-A367-5F6B6BC38D5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = JP,

Thanks. I have read the specification a couple of = times, but as I am not a key-management-expert, I have not (yet) formed = any real opinions on the technical content. I am still working on that = bit ;)

However as you message was cryptic, I = wanted to make sure that I did not miss any = last-review-before-wg-document deadline. I understand that there's no = immediate deadline so I would suggest that the WG gets to consider =  that when a determination has been made on the other ongoing = issues currently being discussed 

[Not to = belittle this document; I, for one, like most LLN routers just have = limited bandwidth and processing power=85.trying to make sure that they = are being used appropriately]

Respectfully = yours,

Thomas


=

On Sep 5, 2011, at 16:53 , JP Vasseur wrote:

Hi Thomas,

On = Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote:

Dear JP,

I = am not sure I completely understand the question=85=85is this the WG = chair polling the group for adaptation as WG = document?

If yes, when do you plan on = making a decision (so as to give a target as to before when an opinion = should have been = formed?)


= I was polling the WG to get some comment since we did not get a chance = to discuss it during the WG meeting,
that was not yet a poll = for WG adoption.

Any opinion to share of this = document = ?

Thanks.

JP.
=

Thomas

On Aug 31, = 2011, at 14:55 , JP Vasseur wrote:

Any comment = ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject: = [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt
Date: August 26, 2011 = 9:17:42 AM GMT+02:00
To: roll WG <roll@ietf.org>

Dear all,

Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you
please = comment on this I-D as soon as possible ? We need a key management = protocol and if it turns
out that the WG wants to adopt this ID, I'll = poll the WG to make it a WG =85 Please = comment.

Thanks.

JP.
____________________________________= ___________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____= __________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



= --Apple-Mail=_F0EEC050-765A-4EAA-A367-5F6B6BC38D5A-- From jpv@cisco.com Mon Sep 5 09:34:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92DE21F8B3A for ; Mon, 5 Sep 2011 09:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.483 X-Spam-Level: X-Spam-Status: No, score=-109.483 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2Tvz4lXraLP for ; Mon, 5 Sep 2011 09:34:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 76BEA21F8556 for ; Mon, 5 Sep 2011 09:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=9254; q=dns/txt; s=iport; t=1315240574; x=1316450174; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=nk7x558ZHe8Nkb9bkiOGZ5CvOc+5Cv5K8yqAFO7QXLE=; b=Mwly1d68Hw7eHsb2agd+wxvfYJXQP8DZiQzUyQ/fvnsa4iKdJTkrUJSF qeKPtT/4FXwvt2krBU6n+8TtwshpIT5MYXMatBjbMQ/H8UXLHS9WQALO8 ZPV2cXX6GU7tl35gs6sykDqfmuI/xYg0L1N4bcaNoCE+3YxY/LDqA6qBb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADH5ZE5Io8UT/2dsb2JhbABDqBh4gUYBAQEBAgEBAQEPAVgDCwULCxEDAQIBLicoCAYTIodRBJoAAZ5fhgpgBJMuhQ8Ji3c X-IronPort-AV: E=Sophos;i="4.68,334,1312156800"; d="scan'208,217";a="114016360" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 05 Sep 2011 16:36:09 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p85Ga8To024312; Mon, 5 Sep 2011 16:36:08 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 22:06:08 +0530 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 22:06:07 +0530 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_BA2F591C-446F-4EF6-9DC8-6ACE394E9256" From: JP Vasseur In-Reply-To: Date: Mon, 5 Sep 2011 18:36:05 +0200 Message-Id: <5DAFCC5E-1D44-4DFB-B47A-8BBD708C2C2C@cisco.com> References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 05 Sep 2011 16:36:07.0782 (UTC) FILETIME=[E99CC860:01CC6BE9] Cc: roll WG Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 16:34:31 -0000 --Apple-Mail=_BA2F591C-446F-4EF6-9DC8-6ACE394E9256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Thomas for your feed-back. Still, I would encourage people to read and comment; the issue of key = management has been raised by several ADs and in the security framework, so we may want to make some progress = and address IESG's requests. On Sep 5, 2011, at 6:07 PM, Thomas Heide Clausen wrote: > Dear JP, >=20 > Thanks. I have read the specification a couple of times, but as I am = not a key-management-expert, I have not (yet) formed any real opinions = on the technical content. I am still working on that bit ;) >=20 > However as you message was cryptic, I wanted to make sure that I did = not miss any last-review-before-wg-document deadline. I understand that = there's no immediate deadline so I would suggest that the WG gets to = consider that when a determination has been made on the other ongoing = issues currently being discussed=20 >=20 > [Not to belittle this document; I, for one, like most LLN routers just = have limited bandwidth and processing power=85.trying to make sure that = they are being used appropriately] >=20 > Respectfully yours, >=20 > Thomas >=20 >=20 >=20 > On Sep 5, 2011, at 16:53 , JP Vasseur wrote: >=20 >> Hi Thomas, >>=20 >> On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP, >>>=20 >>> I am not sure I completely understand the question=85=85is this the = WG chair polling the group for adaptation as WG document? >>>=20 >>> If yes, when do you plan on making a decision (so as to give a = target as to before when an opinion should have been formed?) >>>=20 >>=20 >> I was polling the WG to get some comment since we did not get a = chance to discuss it during the WG meeting, >> that was not yet a poll for WG adoption. >>=20 >> Any opinion to share of this document ? >>=20 >> Thanks. >>=20 >> JP. >>=20 >>=20 >>> Thomas >>>=20 >>> On Aug 31, 2011, at 14:55 , JP Vasseur wrote: >>>=20 >>>> Any comment ? >>>>=20 >>>> Thanks. >>>>=20 >>>> JP. >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: JP Vasseur >>>>> Subject: [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt >>>>> Date: August 26, 2011 9:17:42 AM GMT+02:00 >>>>> To: roll WG >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you >>>>> please comment on this I-D as soon as possible ? We need a key = management protocol and if it turns >>>>> out that the WG wants to adopt this ID, I'll poll the WG to make = it a WG =85 Please comment. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP. >>>>> _______________________________________________ >>>>> 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 >>>=20 >>=20 >=20 --Apple-Mail=_BA2F591C-446F-4EF6-9DC8-6ACE394E9256 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = JP,

Thanks. I have read the specification a couple of = times, but as I am not a key-management-expert, I have not (yet) formed = any real opinions on the technical content. I am still working on that = bit ;)

However as you message was cryptic, I = wanted to make sure that I did not miss any = last-review-before-wg-document deadline. I understand that there's no = immediate deadline so I would suggest that the WG gets to consider =  that when a determination has been made on the other ongoing = issues currently being discussed 

[Not to = belittle this document; I, for one, like most LLN routers just have = limited bandwidth and processing power=85.trying to make sure that they = are being used appropriately]

Respectfully = yours,

Thomas


=

On Sep 5, 2011, at 16:53 , JP Vasseur wrote:

Hi Thomas,

On = Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote:

Dear JP,

I = am not sure I completely understand the question=85=85is this the WG = chair polling the group for adaptation as WG = document?

If yes, when do you plan on = making a decision (so as to give a target as to before when an opinion = should have been = formed?)


= I was polling the WG to get some comment since we did not get a chance = to discuss it during the WG meeting,
that was not yet a poll = for WG adoption.

Any opinion to share of this = document = ?

Thanks.

JP.
=

Thomas

On Aug 31, = 2011, at 14:55 , JP Vasseur wrote:

Any comment = ?

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Subject: = [Roll] PLEASE Comment on = draft-alexander-roll-mikey-lln-key-mgmt
Date: August 26, 2011 = 9:17:42 AM GMT+02:00
To: roll WG <roll@ietf.org>

Dear all,

Several of you expressed some interest in = draft-alexander-roll-mikey-lln-key-mgmt. That said, could you
please = comment on this I-D as soon as possible ? We need a key management = protocol and if it turns
out that the WG wants to adopt this ID, I'll = poll the WG to make it a WG =85 Please = comment.

Thanks.

JP.
____________________________________= ___________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

_____= __________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll




= --Apple-Mail=_BA2F591C-446F-4EF6-9DC8-6ACE394E9256-- From prvs=222cdb431=mukul@uwm.edu Mon Sep 5 10:22:30 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BF821F8B80 for ; Mon, 5 Sep 2011 10:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.185 X-Spam-Level: X-Spam-Status: No, score=-5.185 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5-2z9SaBNHh for ; Mon, 5 Sep 2011 10:22:29 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5AF21F8B68 for ; Mon, 5 Sep 2011 10:22:29 -0700 (PDT) Received: from localhost (HELO mta03.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 05 Sep 2011 12:24:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id F036F1FD00F for ; Mon, 5 Sep 2011 12:24:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+wbPbHlWcXd for ; Mon, 5 Sep 2011 12:24:13 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8AF1A1FD00E for ; Mon, 5 Sep 2011 12:24:13 -0500 (CDT) Date: Mon, 5 Sep 2011 12:24:13 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <522763072.189557.1315243453458.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <20110905170809.18414.91738.idtracker@ietfa.amsl.com> 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.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-goyal-roll-dis-modifications-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 17:22:30 -0000 Hi all This draft is the merge of draft-dejean-roll-selective-dis and draft-goyal-roll-defunct-dags. Both drafts proposed specification of a "No Inconsistency" flag in DIS that allows the routers to not reset their trickle timers even if the DIS is sent via multicast. The merged draft includes the other key specifications of the selective DIS draft: 1. A new Response Spreading option to spread the DIO responses in a desired time interval. 2. Allow the inclusion of a metric container in the DIS to specify the constraints that the responding routers must satisfy. The merged draft specifies another DIS flag to request either unicast or multicast DIOs. The specified flags and options are useful for at least the following two applications: 1) a leaf node joining a dag with desired characteristics at a desired position. 2) a node identifying defunct dags it belongs to. Comments are welcome. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: mukul@uwm.edu Cc: "nicolas dejean" , "jerald p martocci" , "emmanuel baccelli" , mukul@uwm.edu, "dominique barthel" Sent: Monday, September 5, 2011 12:08:09 PM Subject: New Version Notification for draft-goyal-roll-dis-modifications-00.txt A new version of I-D, draft-goyal-roll-dis-modifications-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-dis-modifications Revision: 00 Title: DIS Modifications Creation date: 2011-09-05 WG ID: Individual Submission Number of pages: 11 Abstract: This document specifies the DIS flags and options that allow an RPL node to control how neighbor RPL routers respond to its solicitiation for DIOs. The IETF Secretariat From mcr@sandelman.ca Mon Sep 5 11:38:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753CF21F8B4A for ; Mon, 5 Sep 2011 11:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y775Hk6HGztW for ; Mon, 5 Sep 2011 11:38:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E1CD321F8B37 for ; Mon, 5 Sep 2011 11:38:06 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 6155F34374; Mon, 5 Sep 2011 14:39:06 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 41D5898411; Sun, 4 Sep 2011 22:17:34 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> References: <465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Sep 2011 22:17:34 -0400 Message-ID: <13330.1315189054@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 18:38:07 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> It is not a replacement. It is an optional feature. This Mukul> feature is to be used in deployments that consider it to be It's not optional. It's required for deployments that need it. You just said that. It is sufficiently useful a thing that I, and many others, want to simply make it required, if we are going to use it at all. Anyone who wants to sell product into places that might need is going to have to implement it. As such, I can see no reason to implement the synthetic version. Rip that code out, stop testing it, be done with it. Assuming that is, that we aren't painting ourselves into a corner. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATmQxPoCLcPvd0N1lAQL0ZQf/SmXLRyq6rrdlSCEbrrHIH//14DXY2vOH OTfierpkjEb7zTO5IOFxLd6jfgPMvfhlZy0RVybe2PSssc+txSsLvlSQF73q4YCt RcgvIo+xAuFItNmc5HVYRUDhPHJDmlZCJg27+qZvTVPCLDpNZ0kR+d+FwZ0eHJ71 IzxBRfSZPqtbpjqSGTcktfIEjkQm5KsMzOiu3pyKGBIrlFmzFR2vnBoR+2/SXaP6 U9pRHXoumVFYsXif6A6ayoSV5f+SzS9b6oMPWY+2nMdIpVYRVduyhN5dx9lwHo4K myfD6l+9DZlNQ7bhnT9575p7wpNJhj+o5fAFqZSdx/SWwUluDo24Pw== =wqFY -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Mon Sep 5 13:41:00 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E505A21F8B3A for ; Mon, 5 Sep 2011 13:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jd0thyAOLBY for ; Mon, 5 Sep 2011 13:41:00 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3D21F8B32 for ; Mon, 5 Sep 2011 13:40:59 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 86D1C3434D; Mon, 5 Sep 2011 16:41:59 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 40D5C98C68; Mon, 5 Sep 2011 16:43:15 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0565D771@XMB-AMS-107.cisco.com> References: <16050.1315103775@marajade.sandelman.ca><465899107.187484.1315179349447.JavaMail.root@mail05.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0565D771@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 05 Sep 2011 16:43:15 -0400 Message-ID: <20091.1315255395@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 20:41:01 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> I, for one, do not. I think that once decompression has Pascal> occurred, we should get RPL packets as defined in the spec. Pascal> If more than one compression method exist over a same MAC in Pascal> a same network, or if nodes use compression and others do Pascal> not, then we are in a situation that is equivalent to Pascal> different MACs over the same band, or different Pascal> cryptos. DIOs have to be sent twice, etc. This is a signaling problem as well as an interop problem. GRRC assumes 6LowPAN HC, and if one assumes that, then one has solved the signaling problem. I'm not yet convinced that GRRC can be made completely transparent to the security parts of RPL, such that a packet can be "decompressed", passed to another link-layer which does not have HC (such as ethernet), and still retain all it's expressiveness. -- ] 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 ietfroll@yahoo.com Mon Sep 5 16:53:51 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 583DD1B60AE6 for ; Mon, 5 Sep 2011 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viq0+sjZToFb for ; Mon, 5 Sep 2011 16:53:50 -0700 (PDT) Received: from nm5-vm0.bullet.mail.sp2.yahoo.com (nm5-vm0.bullet.mail.sp2.yahoo.com [98.139.91.204]) by ietfc.amsl.com (Postfix) with SMTP id 984331B60AE5 for ; Mon, 5 Sep 2011 16:53:46 -0700 (PDT) Received: from [98.139.91.69] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 05 Sep 2011 23:22:40 -0000 Received: from [98.139.91.38] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 05 Sep 2011 23:22:40 -0000 Received: from [127.0.0.1] by omp1038.mail.sp2.yahoo.com with NNFMP; 05 Sep 2011 23:22:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 305056.21507.bm@omp1038.mail.sp2.yahoo.com Received: (qmail 86532 invoked by uid 60001); 5 Sep 2011 23:22:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315264959; bh=B9QY4EuCxQENXJ5aWB0yJxB4drh2AA7dS7eEgLqdSCI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GGsdr754inm4FinnralryJeZ/7KVb39/Eus2Cra1lCD4GkvGirGYLXl4HfPKnWMc2G0RtCRkoMM48+R/c3rW6wWN0h39prhhfC89DXAmIMvL2RXVUkTdRN176mE7ejNN1TAPCKBmPaLz5NtFUq1oYVRKzxOTPalhNSMZKNtHMqQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OEpmmVh3Xq/JhHGFZliSf3CU4UxnMKa+TNTnpZc1PFIYfMp47rMwJh6nU+cy0/hzvDyR0ILlUjyro8Rr5iQDwDDX4nEp6KlsXWhUXlF7dbGsOVGQ6aLYdv+q4ZxadjZVdrdQTPnAhA3A5lDh8AmBvMjwRYV4F0HhwGqP4MK9zPY=; X-YMail-OSG: mh1p8sAVM1nD7oqqjG364.HSATylWCF_g2PGnTEstcwoEl4 0UK3CSQvIO8b4sDwTYRK82bqF8Lf3B3JELkyiGiXjzMddc789Qo8kMBkrZBY l43tjYql9xlD6ReEp71w_xLnuNqoXlJXbDNZ352Xr7Q8hRvCrmWRukCl5p5V PDIxDiHyycLWr6MKNaiV3heLekovfj.jhyGull2gRyQ95ZaS0HMHU_dijBkY e5LVTNNzUn2lV3DMwMNCRpct2jlJLoVUjqIIHTeeFvN.ydOC8f415WOxdZwq sY48D61T5Wa4tJlgdV38ZDedHdp92Nds4SW.Je2bP55jmuqDTvIzgsD_8PmN YY18Aaphe9C7OXS69N9Iz4tuv6_wcmq6Ic3ceSg-- Received: from [178.63.246.164] by web113916.mail.gq1.yahoo.com via HTTP; Mon, 05 Sep 2011 16:22:39 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> Message-ID: <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> Date: Mon, 5 Sep 2011 16:22:39 -0700 (PDT) From: Ietf Roll To: Don Sturek In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1454086480-1315264959=:82194" Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ietf Roll 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 Sep 2011 23:53:51 -0000 --0-1454086480-1315264959=:82194 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is good news that Zigbee is making it work.=C2=A0 I guess that since y= our =0Arequirements are only 30 nodes then that matches the paper that says= RPL for constrained devices should be limited to 30 nodes.=0A=0AIt is also= good to be re-affirmed that downward routing is not =0Aparticularly good i= n RPL.=C2=A0 Others have already stated this and Zigbee =0Aseems to confirm= this.=0A=0A=0ARav=0A=0APS - Since many keep pointing at =0Ame, I am not pu= tting my full name and company in my email for I fear retribution.=C2=A0 I = do not want to lose my job for asking questions and =0Acriticizing parts of= the RPL design.=C2=A0 I do not want my company or my =0Asupervisor called = by people like a chair and have my job put at risk.=0A=0A=0A_______________= _________________=0AFrom: Don Sturek =0ATo: Ietf Roll ; JP Vasseur ; Thomas Heide Clausen =0ACc: roll WG =0ASent: Sunday, September 4= , 2011 7:20 AM=0ASubject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compr= ession as a new ROLL WG document=0A=0A=0AHere are a few points to maybe con= sider:=0A1) =C2=A0 ZigBee is not "having problems making it work" (referrin= g to ROLL RPL. =C2=A0 I chair the group in ZigBee testing "ZigBee IP" and w= e have had relatively good success using RPL for the use cases we are consi= dering.=0A2) =C2=A0 The Smart Energy 2.0 use cases are for only 30 devices = in a single home area network. =C2=A0 We are testing 30 nodes with 3 hops= =0A3) =C2=A0 The upward routing feature in RPL is quite efficient. =C2=A0Th= e downward routing feature either assumes storing mode (which we don't use)= or non-storing mode with source routing (which does not offer pro-active o= r re-active route establishment).=0A4) =C2=A0 I personally would not use RO= LL RPL as it is for low latency applications like lighting control, home au= tomation, etc. =C2=A0 I fully support the ROLL RPL P2P draft for these appl= ications.=0A=0AOn additional, perhaps related topics:=0A5) =C2=A0I don't be= lieve there will be only a single mesh routing protocol defined for all app= lications in IETF. =C2=A0I fully support the work going on in MANET and als= o think "mesh under" solutions will also be useful for some applications=0A= =0AAnd finally:=0A6) =C2=A0All this said, I think ZigBee IP will successful= ly conclude testing using ROLL RPL=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=0A= =0AHappy to sign my real name,=0A=0ADon Sturek=0A=0A=0A=0AFrom: Ietf Roll = =0AReply-To: Ietf Roll =0ADate: S= at, 3 Sep 2011 00:54:25 -0700 (PDT)=0ATo: JP Vasseur , Thom= as Heide Clausen =0ACc: roll WG =0A= Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new = ROLL WG document=0A=0A=0AJP Vasseur wrote:=0A=0A=0A=0A*if* you think that t= his not elegant enough (which has to be demonstrated IMO), then you must be= supportive=0Aof the P2P IDs work that the WG has been working on ?=0A[rav]= how about a demonstration that RPL actually works as purported.=C2=A0 Thom= as has said that his group implemented it and it was difficult, complex and= fraught with inconsistencies in specification.=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 I heard that zigbee is having problems making it w= ork and the only paper that I've seen on RPL says that for constrained node= s they recommend=0A no more than 30 nodes in a network.=C2=A0 Hardly the sc= ale necessary for some of the =0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 use cases been suggested (like AMI).=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The P2P is a hack to try to fix the fact the RPL i= s basically a collection tree and as such downward routing is an distant af= ter thought (certainly not elegant).=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Without lots of memory, node must use non-storing mode (oh = and we are talking about constrained devices so lots of memory is then inco= nsistent) and then routing is up to the root and back down.=C2=A0 Not what = anyone who=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 understands r= outing would consider elegant P2P.=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 In the rush to get RPL out of the working group we all were= bamboozled by the chair into believing the draft was actually complete and= the=0A IESG further compounded this error.=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 If it were possible to fix things, RPL should be a= n experimental draft until such time as there are working interoperable imp= lementations that are shown to provide the services that were required in t= he various Use-case=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draf= ts - or even just one of them.=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 And now we are rushing to generate and publish a marketing docume= nt (called an applicability statement) without having any experience with t= he protocol.=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are we r= ushing and putting so much pressure and bending the systems so that this ge= ts published before we find we've built a house of cards and it comes crash= ing down.=0A=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will b= e really counter productive to the industry and the Internet=0A (certainly = not Thomas's warnings).=C2=A0 When everyone looks at this mistake and says,= why didn't the IETF do its job and exercise proper engineering, then the R= OLL WG=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the Cha= irs will be the ones that have hurt the industry and the Internet.=0A=0ARav= =0A=0A_______________________________________________=0ARoll mailing list R= oll@ietf.org https://www.ietf.org/mailman/listinfo/roll --0-1454086480-1315264959=:82194 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This=0A is= good news that Zigbee is making it work.  I guess that since your =0A= requirements are only 30 nodes then that matches the paper that says RPL=0A= for constrained devices should be limited to 30 nodes.
=0A
=0A
=0A
It=0A is also good to be re-affi= rmed that downward routing is not =0Aparticularly good in RPL.  Others= have already stated this and Zigbee =0Aseems to confirm this.
=0A

=0A
=0A
Rav
=0A

=0A
=0A
PS -= Since many keep pointing at =0Ame, I am not putting my full name and compa= ny in my email for I fear=0A retribution.  I do not want to lose my jo= b for asking questions and =0Acriticizing parts of the RPL design.  I = do not want my company or my =0Asupervisor called by people like a chair an= d have my job put at risk.

From: Don Sturek <d.sturek@att.net>
To: Ietf Roll <ietfroll@yahoo.com>= ; JP Vasseur <jpv@cisco.com>; Thomas Heide Clausen <ietf@thomascla= usen.org>
Cc: roll W= G <roll@ietf.org>
Sent: Sunday, September 4, 2011 7:20 AM
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-comp= ression as a new ROLL WG document

Here are a few points to maybe consider:
1)   ZigBee is not "having problems making it wor= k" (referring to ROLL RPL.   I chair the group in ZigBee testing "ZigB= ee IP" and we have had relatively good success using RPL for the use cases = we are considering.
2)   The Smart Energy 2.0 use cases are = for only 30 devices in a single home area network.   We are testing 30= nodes with 3 hops
3)   The upward routing feature in RPL is= quite efficient.  The downward routing feature either assumes storing= mode (which we don't use) or non-storing mode with source routing (which d= oes not offer pro-active or re-active route establishment).
4) &n= bsp; I personally would not use ROLL RPL as it is for low latency applicati= ons like lighting control, home automation, etc.   I fully support the= ROLL RPL P2P draft for these applications.

On add= itional, perhaps related topics:
5)  I don't believe there will be only a single mesh routing protocol defined for all applicat= ions in IETF.  I fully support the work going on in MANET and also thi= nk "mesh under" solutions will also be useful for some applications

And finally:
6)  All this said, I think Zi= gBee IP will successfully conclude testing using ROLL RPL=E2=80=A6=E2=80=A6= =E2=80=A6=E2=80=A6

Happy to sign my real name,

Don Sturek



From: Ietf R= oll <ietfroll@yahoo.com>
Reply-To: Ietf Roll <ietfroll@yahoo.com>
Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
To: JP Vasseur <j= pv@cisco.com>, Thomas Heide Clausen <ietf@thomasclausen.org>
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] Ado= ption of draft-goyal-roll-rpl-compression as a new ROLL WG document
=
*if* you think that this not elegant enough (which has to be demon= strated IMO), then you must be supportive
of the P2P IDs work tha= t the WG has been working on ?

[rav] how about a demons= tration that RPL actually works as purported.  Thomas has said that hi= s group implemented it and it was difficult, complex and fraught with incon= sistencies in specification.
       &= nbsp; I heard that zigbee is having problems making it work and the only paper that I've seen on RPL says that for constrained nodes they recommend= =0A no more than 30 nodes in a network.  Hardly the scale necessary fo= r some of the
         use case= s been suggested (like AMI).

      &nb= sp;  The P2P is a hack to try to fix the fact the RPL is basically a c= ollection tree and as such downward routing is an distant after thought (ce= rtainly not elegant).

       &nbs= p; Without lots of memory, node must use non-storing mode (oh and we are ta= lking about constrained devices so lots of memory is then inconsistent) and= then routing is up to the root and back down.  Not what anyone who         understands routing would= consider elegant P2P.

       &nb= sp; In the rush to get RPL out of the working group we all were bamboozled = by the chair into believing the draft was actually complete and the=0A IESG= further compounded this error.

      =    If it were possible to fix things, RPL should be an experiment= al draft until such time as there are working interoperable implementations= that are shown to provide the services that were required in the various U= se-case
         drafts - or eve= n just one of them.

        = And now we are rushing to generate and publish a marketing document (calle= d an applicability statement) without having any experience with the protoc= ol.

         Are we rushing = and putting so much pressure and bending the systems so that this gets publ= ished before we find we've built a house of cards and it comes crashing dow= n.

         This will be rea= lly counter productive to the industry and the Internet=0A (certainly not T= homas's warnings).  When everyone looks at this mistake and says, why = didn't the IETF do its job and exercise proper engineering, then the ROLL W= G
          and the Chairs = will be the ones that have hurt the industry and the Internet.

Rav
___________________________= ____________________=0ARoll mailing list=0ARoll@i= etf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll= =0A =0A


--0-1454086480-1315264959=:82194-- From gnawali@cs.stanford.edu Mon Sep 5 20:39:44 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2182F21F8445 for ; Mon, 5 Sep 2011 20:39:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-2V1vmEO+b5 for ; Mon, 5 Sep 2011 20:39:43 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 699EC21F8444 for ; Mon, 5 Sep 2011 20:39:40 -0700 (PDT) Received: from mail-pz0-f45.google.com ([209.85.210.45]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1R0mXK-0004rs-Hw for roll@ietf.org; Mon, 05 Sep 2011 20:41:25 -0700 Received: by pzk33 with SMTP id 33so15725785pzk.18 for ; Mon, 05 Sep 2011 20:41:22 -0700 (PDT) Received: by 10.68.16.201 with SMTP id i9mr8556667pbd.279.1315280482187; Mon, 05 Sep 2011 20:41:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.20 with HTTP; Mon, 5 Sep 2011 20:41:02 -0700 (PDT) In-Reply-To: <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> From: Omprakash Gnawali Date: Mon, 5 Sep 2011 22:41:02 -0500 Message-ID: To: Ietf Roll Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: e77698abd1e6debe3c2002ca69acc434 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 03:39:44 -0000 Can someone post a link to the paper being referenced? Thanks. - om_p On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll wrote: > This is good news that Zigbee is making it work.=A0 I guess that since yo= ur > requirements are only 30 nodes then that matches the paper that says RPL = for > constrained devices should be limited to 30 nodes. > It is also good to be re-affirmed that downward routing is not particular= ly > good in RPL.=A0 Others have already stated this and Zigbee seems to confi= rm > this. > > Rav > PS - Since many keep pointing at me, I am not putting my full name and > company in my email for I fear retribution.=A0 I do not want to lose my j= ob > for asking questions and criticizing parts of the RPL design.=A0 I do not= want > my company or my supervisor called by people like a chair and have my job > put at risk. > ________________________________ > From: Don Sturek > To: Ietf Roll ; JP Vasseur ; Thomas He= ide > Clausen > Cc: roll WG > Sent: Sunday, September 4, 2011 7:20 AM > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > Here are a few points to maybe consider: > 1) =A0 ZigBee is not "having problems making it work" (referring to ROLL = RPL. > =A0 I chair the group in ZigBee testing "ZigBee IP" and we have had relat= ively > good success using RPL for the use cases we are considering. > 2) =A0 The Smart Energy 2.0 use cases are for only 30 devices in a single= home > area network. =A0 We are testing 30 nodes with 3 hops > 3) =A0 The upward routing feature in RPL is quite efficient. =A0The downw= ard > routing feature either assumes storing mode (which we don't use) or > non-storing mode with source routing (which does not offer pro-active or > re-active route establishment). > 4) =A0 I personally would not use ROLL RPL as it is for low latency > applications like lighting control, home automation, etc. =A0 I fully sup= port > the ROLL RPL P2P draft for these applications. > On additional, perhaps related topics: > 5) =A0I don't believe there will be only a single mesh routing protocol > defined for all applications in IETF. =A0I fully support the work going o= n in > MANET and also think "mesh under" solutions will also be useful for some > applications > And finally: > 6) =A0All this said, I think ZigBee IP will successfully conclude testing > using ROLL RPL=85=85=85=85 > Happy to sign my real name, > Don Sturek > > > > From: Ietf Roll > Reply-To: Ietf Roll > Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT) > To: JP Vasseur , Thomas Heide Clausen > > Cc: roll WG > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new > ROLL WG document > > JP Vasseur wrote: > > *if* you think that this not elegant enough (which has to be demonstrated > IMO), then you must be supportive > of the P2P IDs work that the WG has been working on ? > [rav] how about a demonstration that RPL actually works as purported. > Thomas has said that his group implemented it and it was difficult, compl= ex > and fraught with inconsistencies in specification. > =A0=A0=A0=A0=A0=A0=A0=A0 I heard that zigbee is having problems making it= work and the only > paper that I've seen on RPL says that for constrained nodes they recommen= d > no more than 30 nodes in a network.=A0 Hardly the scale necessary for som= e of > the > =A0=A0=A0=A0=A0=A0=A0=A0 use cases been suggested (like AMI). > > =A0=A0=A0=A0=A0=A0=A0=A0 The P2P is a hack to try to fix the fact the RPL= is basically a > collection tree and as such downward routing is an distant after thought > (certainly not elegant). > > =A0=A0=A0=A0=A0=A0=A0=A0 Without lots of memory, node must use non-storin= g mode (oh and we > are talking about constrained devices so lots of memory is then > inconsistent) and then routing is up to the root and back down.=A0 Not wh= at > anyone who > =A0=A0=A0=A0=A0=A0=A0=A0 understands routing would consider elegant P2P. > > =A0=A0=A0=A0=A0=A0=A0=A0 In the rush to get RPL out of the working group = we all were > bamboozled by the chair into believing the draft was actually complete an= d > the IESG further compounded this error. > > =A0=A0=A0=A0=A0=A0=A0=A0 If it were possible to fix things, RPL should be= an experimental > draft until such time as there are working interoperable implementations > that are shown to provide the services that were required in the various > Use-case > =A0=A0=A0=A0=A0=A0=A0=A0 drafts - or even just one of them. > > =A0=A0=A0=A0=A0=A0=A0=A0 And now we are rushing to generate and publish a= marketing document > (called an applicability statement) without having any experience with th= e > protocol. > > =A0=A0=A0=A0=A0=A0=A0=A0 Are we rushing and putting so much pressure and = bending the systems > so that this gets published before we find we've built a house of cards a= nd > it comes crashing down. > > =A0=A0=A0=A0=A0=A0=A0=A0 This will be really counter productive to the in= dustry and the > Internet (certainly not Thomas's warnings).=A0 When everyone looks at thi= s > mistake and says, why didn't the IETF do its job and exercise proper > engineering, then the ROLL WG > =A0=A0=A0=A0=A0=A0=A0=A0=A0 and the Chairs will be the ones that have hur= t the industry and > the Internet. > > Rav > > _______________________________________________ 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 ulrich@herberg.name Mon Sep 5 21:50:11 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626C721F848A for ; Mon, 5 Sep 2011 21:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoiT1Zlbwuzt for ; Mon, 5 Sep 2011 21:50:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A039021F8488 for ; Mon, 5 Sep 2011 21:50:09 -0700 (PDT) Received: by vxi29 with SMTP id 29so5249114vxi.31 for ; Mon, 05 Sep 2011 21:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vIZONbe1JSli2S5C3fKCvJcsq1dz9TmDZmxQGdNLgrA=; b=BQIv5v6rOJoS5ld626qmk1qRRiDk1tVLFkz85hKoKIoUfecVNZHI4ZKDOl5NNzCroD P4tHhas5Faqmz0BZQxt22ySEflsgW4/VAg4lgOBUGGrD9tbAqGtBqqq5O/C0Pg4/UOW6 EeYyooELfX1zNFhylyw7K+OKOb7Kiy0oASGzQ= MIME-Version: 1.0 Received: by 10.220.148.208 with SMTP id q16mr1252547vcv.141.1315284712544; Mon, 05 Sep 2011 21:51:52 -0700 (PDT) Received: by 10.220.51.130 with HTTP; Mon, 5 Sep 2011 21:51:52 -0700 (PDT) In-Reply-To: References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> Date: Mon, 5 Sep 2011 21:51:52 -0700 Message-ID: From: Ulrich Herberg To: Omprakash Gnawali Content-Type: multipart/alternative; boundary=f46d0438950f11d8cd04ac3e96dd Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 04:50:11 -0000 --f46d0438950f11d8cd04ac3e96dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Omprakash, I believe the paper he refers to is that: J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating th= e Performance of RPL and 6LoWPAN in TinyOS" http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf Omprakash, you are an author of that paper :-) The paper states: "In our experiments with downstream routing in storing mode, we noticed that the current TinyRPL/BLIP implementations on TelosB motes support up to =E2=88=BC30 target destinations. This argues that to su= pport routes to all nodes in the RPL network, the network=E2=80=99s size must be = limited to =E2=88=BC30 nodes." Regards Ulrich On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali wrote: > Can someone post a link to the paper being referenced? Thanks. > > - om_p > > On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll wrote: > > This is good news that Zigbee is making it work. I guess that since yo= ur > > requirements are only 30 nodes then that matches the paper that says RP= L > for > > constrained devices should be limited to 30 nodes. > > It is also good to be re-affirmed that downward routing is not > particularly > > good in RPL. Others have already stated this and Zigbee seems to confi= rm > > this. > > > > Rav > > PS - Since many keep pointing at me, I am not putting my full name and > > company in my email for I fear retribution. I do not want to lose my j= ob > > for asking questions and criticizing parts of the RPL design. I do not > want > > my company or my supervisor called by people like a chair and have my j= ob > > put at risk. > > ________________________________ > > From: Don Sturek > > To: Ietf Roll ; JP Vasseur ; Thomas > Heide > > Clausen > > Cc: roll WG > > Sent: Sunday, September 4, 2011 7:20 AM > > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a n= ew > > ROLL WG document > > > > Here are a few points to maybe consider: > > 1) ZigBee is not "having problems making it work" (referring to ROLL > RPL. > > I chair the group in ZigBee testing "ZigBee IP" and we have had > relatively > > good success using RPL for the use cases we are considering. > > 2) The Smart Energy 2.0 use cases are for only 30 devices in a single > home > > area network. We are testing 30 nodes with 3 hops > > 3) The upward routing feature in RPL is quite efficient. The downwar= d > > routing feature either assumes storing mode (which we don't use) or > > non-storing mode with source routing (which does not offer pro-active o= r > > re-active route establishment). > > 4) I personally would not use ROLL RPL as it is for low latency > > applications like lighting control, home automation, etc. I fully > support > > the ROLL RPL P2P draft for these applications. > > On additional, perhaps related topics: > > 5) I don't believe there will be only a single mesh routing protocol > > defined for all applications in IETF. I fully support the work going o= n > in > > MANET and also think "mesh under" solutions will also be useful for som= e > > applications > > And finally: > > 6) All this said, I think ZigBee IP will successfully conclude testing > > using ROLL RPL=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6 > > Happy to sign my real name, > > Don Sturek > > > > > > > > From: Ietf Roll > > Reply-To: Ietf Roll > > Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT) > > To: JP Vasseur , Thomas Heide Clausen > > > > Cc: roll WG > > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a n= ew > > ROLL WG document > > > > JP Vasseur wrote: > > > > *if* you think that this not elegant enough (which has to be demonstrat= ed > > IMO), then you must be supportive > > of the P2P IDs work that the WG has been working on ? > > [rav] how about a demonstration that RPL actually works as purported. > > Thomas has said that his group implemented it and it was difficult, > complex > > and fraught with inconsistencies in specification. > > I heard that zigbee is having problems making it work and the > only > > paper that I've seen on RPL says that for constrained nodes they > recommend > > no more than 30 nodes in a network. Hardly the scale necessary for som= e > of > > the > > use cases been suggested (like AMI). > > > > The P2P is a hack to try to fix the fact the RPL is basically = a > > collection tree and as such downward routing is an distant after though= t > > (certainly not elegant). > > > > Without lots of memory, node must use non-storing mode (oh and > we > > are talking about constrained devices so lots of memory is then > > inconsistent) and then routing is up to the root and back down. Not wh= at > > anyone who > > understands routing would consider elegant P2P. > > > > In the rush to get RPL out of the working group we all were > > bamboozled by the chair into believing the draft was actually complete > and > > the IESG further compounded this error. > > > > If it were possible to fix things, RPL should be an experiment= al > > draft until such time as there are working interoperable implementation= s > > that are shown to provide the services that were required in the variou= s > > Use-case > > drafts - or even just one of them. > > > > And now we are rushing to generate and publish a marketing > document > > (called an applicability statement) without having any experience with > the > > protocol. > > > > Are we rushing and putting so much pressure and bending the > systems > > so that this gets published before we find we've built a house of cards > and > > it comes crashing down. > > > > This will be really counter productive to the industry and the > > Internet (certainly not Thomas's warnings). When everyone looks at thi= s > > mistake and says, why didn't the IETF do its job and exercise proper > > engineering, then the ROLL WG > > and the Chairs will be the ones that have hurt the industry a= nd > > the Internet. > > > > Rav > > > > _______________________________________________ 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 > --f46d0438950f11d8cd04ac3e96dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Omprakash,

I believe the paper he refers to is that:
J. Ko, S. D= awson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating the Perf= ormance of RPL and 6LoWPAN in TinyOS"
http://hinrg.cs.= jhu.edu/joomla/images/stories/TinyRPL.pdf

Omprakash, you are an author of that paper :-)

The paper=20 states: "In our experiments with downstream routing in storing mode, w= e=20 noticed that the current TinyRPL/BLIP implementations on TelosB motes=20 support up to =E2=88=BC30 target destinations. This argues that to support= =20 routes to all nodes in the RPL network, the network=E2=80=99s size must be= =20 limited to =E2=88=BC30 nodes."

Regards
Ulrich

On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali <gnawali@cs.stanford.edu= > wrote:
Can someone post a link to the paper being = referenced? Thanks.

- om_p

On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <ietfroll@yahoo.com> wrote:
> This is good news that Zigbee is making it work.=C2=A0 I guess that si= nce your
> requirements are only 30 nodes then that matches the paper that says R= PL for
> constrained devices should be limited to 30 nodes.
> It is also good to be re-affirmed that downward routing is not particu= larly
> good in RPL.=C2=A0 Others have already stated this and Zigbee seems to= confirm
> this.
>
> Rav
> PS - Since many keep pointing at me, I am not putting my full name and=
> company in my email for I fear retribution.=C2=A0 I do not want to los= e my job
> for asking questions and criticizing parts of the RPL design.=C2=A0 I = do not want
> my company or my supervisor called by people like a chair and have my = job
> put at risk.
> ________________________________
> From: Don Sturek <d.sturek@att.= net>
> To: Ietf Roll <ietfroll@yahoo= .com>; JP Vasseur <jpv@cisco.com= >; Thomas Heide
> Clausen <ietf@thomasclaus= en.org>
> Cc: roll WG <roll@ietf.org>=
> Sent: Sunday, September 4, 2011 7:20 AM
> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new
> ROLL WG document
>
> Here are a few points to maybe consider:
> 1) =C2=A0 ZigBee is not "having problems making it work" (re= ferring to ROLL RPL.
> =C2=A0 I chair the group in ZigBee testing "ZigBee IP" and w= e have had relatively
> good success using RPL for the use cases we are considering.
> 2) =C2=A0 The Smart Energy 2.0 use cases are for only 30 devices in a = single home
> area network. =C2=A0 We are testing 30 nodes with 3 hops
> 3) =C2=A0 The upward routing feature in RPL is quite efficient. =C2=A0= The downward
> routing feature either assumes storing mode (which we don't use) o= r
> non-storing mode with source routing (which does not offer pro-active = or
> re-active route establishment).
> 4) =C2=A0 I personally would not use ROLL RPL as it is for low latency=
> applications like lighting control, home automation, etc. =C2=A0 I ful= ly support
> the ROLL RPL P2P draft for these applications.
> On additional, perhaps related topics:
> 5) =C2=A0I don't believe there will be only a single mesh routing = protocol
> defined for all applications in IETF. =C2=A0I fully support the work g= oing on in
> MANET and also think "mesh under" solutions will also be use= ful for some
> applications
> And finally:
> 6) =C2=A0All this said, I think ZigBee IP will successfully conclude t= esting
> using ROLL RPL=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6
> Happy to sign my real name,
> Don Sturek
>
>
>
> From: Ietf Roll <ietfroll@yah= oo.com>
> Reply-To: Ietf Roll <ietfroll= @yahoo.com>
> Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
> To: JP Vasseur <jpv@cisco.com&= gt;, Thomas Heide Clausen
> <ietf@thomasclausen.org>
> Cc: roll WG <roll@ietf.org>=
> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new
> ROLL WG document
>
> JP Vasseur wrote:
>
> *if* you think that this not elegant enough (which has to be demonstra= ted
> IMO), then you must be supportive
> of the P2P IDs work that the WG has been working on ?
> [rav] how about a demonstration that RPL actually works as purported.<= br> > Thomas has said that his group implemented it and it was difficult, co= mplex
> and fraught with inconsistencies in specification.
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I heard that zigbee i= s having problems making it work and the only
> paper that I've seen on RPL says that for constrained nodes they r= ecommend
> no more than 30 nodes in a network.=C2=A0 Hardly the scale necessary f= or some of
> the
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 use cases been sugges= ted (like AMI).
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The P2P is a hack to = try to fix the fact the RPL is basically a
> collection tree and as such downward routing is an distant after thoug= ht
> (certainly not elegant).
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Without lots of memor= y, node must use non-storing mode (oh and we
> are talking about constrained devices so lots of memory is then
> inconsistent) and then routing is up to the root and back down.=C2=A0 = Not what
> anyone who
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 understands routing w= ould consider elegant P2P.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the rush to get RP= L out of the working group we all were
> bamboozled by the chair into believing the draft was actually complete= and
> the IESG further compounded this error.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If it were possible t= o fix things, RPL should be an experimental
> draft until such time as there are working interoperable implementatio= ns
> that are shown to provide the services that were required in the vario= us
> Use-case
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 drafts - or even just= one of them.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And now we are rushin= g to generate and publish a marketing document
> (called an applicability statement) without having any experience with= the
> protocol.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Are we rushing and pu= tting so much pressure and bending the systems
> so that this gets published before we find we've built a house of = cards and
> it comes crashing down.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will be really c= ounter productive to the industry and the
> Internet (certainly not Thomas's warnings).=C2=A0 When everyone lo= oks at this
> mistake and says, why didn't the IETF do its job and exercise prop= er
> engineering, then the ROLL WG
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the Chairs = will be the ones that have hurt the industry and
> the Internet.
>
> Rav
>
> _______________________________________________ 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
>
>
_______________________________________________

--f46d0438950f11d8cd04ac3e96dd-- From c.chauvenet@watteco.com Tue Sep 6 00:42:17 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A621F84AC for ; Tue, 6 Sep 2011 00:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glo8GSc9I-mb for ; Tue, 6 Sep 2011 00:42:15 -0700 (PDT) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 730CB21F84D7 for ; Tue, 6 Sep 2011 00:42:14 -0700 (PDT) Received: from mail81-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Sep 2011 07:44:00 +0000 Received: from mail81-tx2 (localhost.localdomain [127.0.0.1]) by mail81-tx2-R.bigfish.com (Postfix) with ESMTP id 5A1A2100327; Tue, 6 Sep 2011 07:44:00 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(z1725nz9371Kc89bh1803M1432Nc857h98dK9a6kzz1202hzz8275ch1033IL5eeeM8275bh8275dhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB012.red002.local; RD:none; EFVD:NLI Received: from mail81-tx2 (localhost.localdomain [127.0.0.1]) by mail81-tx2 (MessageSwitch) id 1315294994771292_19889; Tue, 6 Sep 2011 07:43:14 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.240]) by mail81-tx2.bigfish.com (Postfix) with ESMTP id 31690AC00C4; Tue, 6 Sep 2011 07:40:52 +0000 (UTC) Received: from IE2RD2HUB012.red002.local (213.199.187.153) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 6 Sep 2011 07:40:51 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.55]) by IE2RD2HUB012.red002.local ([10.33.16.251]) with mapi; Tue, 6 Sep 2011 00:40:26 -0700 From: C Chauvenet To: Ulrich Herberg , Omprakash Gnawali Date: Tue, 6 Sep 2011 00:40:22 -0700 Thread-Topic: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document Thread-Index: AcxsUNqvNwjVW+tJTZu8SpVT/RrpoQAFjTfA Message-ID: References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C971CE5D201FDIE2RD2XVS211r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 07:42:17 -0000 --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE5D201FDIE2RD2XVS211r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rIHlvdSBmb3IgdGhlIGxpbmsuDQoNCkFzIG1lbnRpb25lZCBpbiB0aGUgc2Vu dGVuY2UsIHRoaXMgaXMgcmVsYXRlZCB0byB0aGUgVGlueVJQTC9CTElQIGltcGxlbWVudGF0aW9u IG9mIFJQTCBydW5pbmcgb24gVGVsb3NCIG5vZGVzLg0KVGVsb3NCIG9mZmVycyA0OEsgb2YgUk9N IGFuZCAxMEsgb2YgUkFNLg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIDMwIG5vZGVzIGxp bWl0YXRpb24gaXMgcmVsYXRlZCB0byB0aGUgVGVsb3NCIGFyY2hpdGVjdHVyZSAoUkFNIHNpemUg aW4gcGFydGljdWxhcikgYW5kIG5vdCBSUEwuDQpCZWNhdXNlIFRlbG9zQiBoYXMgYmVlbiBkZXNp Z25lZCBpbiAyMDA0LCB3ZSBjYW4gZXhwZWN0IHRoYXQgcGxhdGZvcm1zIHVzZWQgZm9yIFJQTCBk ZXBsb3ltZW50cyBvZiB0b2RheSBtYXkgaGF2ZSBxdWl0ZSBkaWZmZXJlbnQgY2hhcmFjdGVyaXN0 aWNzLg0KDQpBdXRob3IgbWF5IGNvbXBsZXRlIG15IHVuZGVyc3RhbmRpbmcuDQoNCkPDqWRyaWMu DQoNCkRlIDogcm9sbC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIFVscmljaCBIZXJiZXJnDQpFbnZvecOpIDogbWFyZGkgNiBzZXB0 ZW1icmUgMjAxMSAwNjo1Mg0Kw4AgOiBPbXByYWthc2ggR25hd2FsaQ0KQ2MgOiByb2xsIFdHDQpP YmpldCA6IFJlOiBbUm9sbF0gQWRvcHRpb24gb2YgZHJhZnQtZ295YWwtcm9sbC1ycGwtY29tcHJl c3Npb24gYXMgYSBuZXcgUk9MTCBXRyBkb2N1bWVudA0KDQpPbXByYWthc2gsDQoNCkkgYmVsaWV2 ZSB0aGUgcGFwZXIgaGUgcmVmZXJzIHRvIGlzIHRoYXQ6DQpKLiBLbywgUy4gRGF3c29uLUhhZ2dl cnR5LCBPLiBHbmF3YWxpLCBELiBDdWxsZXIsIEEuIFRlcnppcywgIkV2YWx1YXRpbmcgdGhlIFBl cmZvcm1hbmNlIG9mIFJQTCBhbmQgNkxvV1BBTiBpbiBUaW55T1MiDQpodHRwOi8vaGlucmcuY3Mu amh1LmVkdS9qb29tbGEvaW1hZ2VzL3N0b3JpZXMvVGlueVJQTC5wZGYNCg0KT21wcmFrYXNoLCB5 b3UgYXJlIGFuIGF1dGhvciBvZiB0aGF0IHBhcGVyIDotKQ0KDQpUaGUgcGFwZXIgc3RhdGVzOiAi SW4gb3VyIGV4cGVyaW1lbnRzIHdpdGggZG93bnN0cmVhbSByb3V0aW5nIGluIHN0b3JpbmcgbW9k ZSwgd2Ugbm90aWNlZCB0aGF0IHRoZSBjdXJyZW50IFRpbnlSUEwvQkxJUCBpbXBsZW1lbnRhdGlv bnMgb24gVGVsb3NCIG1vdGVzIHN1cHBvcnQgdXAgdG8g4oi8MzAgdGFyZ2V0IGRlc3RpbmF0aW9u cy4gVGhpcyBhcmd1ZXMgdGhhdCB0byBzdXBwb3J0IHJvdXRlcyB0byBhbGwgbm9kZXMgaW4gdGhl IFJQTCBuZXR3b3JrLCB0aGUgbmV0d29ya+KAmXMgc2l6ZSBtdXN0IGJlIGxpbWl0ZWQgdG8g4oi8 MzAgbm9kZXMuIg0KDQpSZWdhcmRzDQpVbHJpY2gNCk9uIE1vbiwgU2VwIDUsIDIwMTEgYXQgODo0 MSBQTSwgT21wcmFrYXNoIEduYXdhbGkgPGduYXdhbGlAY3Muc3RhbmZvcmQuZWR1PG1haWx0bzpn bmF3YWxpQGNzLnN0YW5mb3JkLmVkdT4+IHdyb3RlOg0KQ2FuIHNvbWVvbmUgcG9zdCBhIGxpbmsg dG8gdGhlIHBhcGVyIGJlaW5nIHJlZmVyZW5jZWQ/IFRoYW5rcy4NCg0KLSBvbV9wDQoNCk9uIE1v biwgU2VwIDUsIDIwMTEgYXQgNjoyMiBQTSwgSWV0ZiBSb2xsIDxpZXRmcm9sbEB5YWhvby5jb208 bWFpbHRvOmlldGZyb2xsQHlhaG9vLmNvbT4+IHdyb3RlOg0KPiBUaGlzIGlzIGdvb2QgbmV3cyB0 aGF0IFppZ2JlZSBpcyBtYWtpbmcgaXQgd29yay4gIEkgZ3Vlc3MgdGhhdCBzaW5jZSB5b3VyDQo+ IHJlcXVpcmVtZW50cyBhcmUgb25seSAzMCBub2RlcyB0aGVuIHRoYXQgbWF0Y2hlcyB0aGUgcGFw ZXIgdGhhdCBzYXlzIFJQTCBmb3INCj4gY29uc3RyYWluZWQgZGV2aWNlcyBzaG91bGQgYmUgbGlt aXRlZCB0byAzMCBub2Rlcy4NCj4gSXQgaXMgYWxzbyBnb29kIHRvIGJlIHJlLWFmZmlybWVkIHRo YXQgZG93bndhcmQgcm91dGluZyBpcyBub3QgcGFydGljdWxhcmx5DQo+IGdvb2QgaW4gUlBMLiAg T3RoZXJzIGhhdmUgYWxyZWFkeSBzdGF0ZWQgdGhpcyBhbmQgWmlnYmVlIHNlZW1zIHRvIGNvbmZp cm0NCj4gdGhpcy4NCj4NCj4gUmF2DQo+IFBTIC0gU2luY2UgbWFueSBrZWVwIHBvaW50aW5nIGF0 IG1lLCBJIGFtIG5vdCBwdXR0aW5nIG15IGZ1bGwgbmFtZSBhbmQNCj4gY29tcGFueSBpbiBteSBl bWFpbCBmb3IgSSBmZWFyIHJldHJpYnV0aW9uLiAgSSBkbyBub3Qgd2FudCB0byBsb3NlIG15IGpv Yg0KPiBmb3IgYXNraW5nIHF1ZXN0aW9ucyBhbmQgY3JpdGljaXppbmcgcGFydHMgb2YgdGhlIFJQ TCBkZXNpZ24uICBJIGRvIG5vdCB3YW50DQo+IG15IGNvbXBhbnkgb3IgbXkgc3VwZXJ2aXNvciBj YWxsZWQgYnkgcGVvcGxlIGxpa2UgYSBjaGFpciBhbmQgaGF2ZSBteSBqb2INCj4gcHV0IGF0IHJp c2suDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IERvbiBTdHVy ZWsgPGQuc3R1cmVrQGF0dC5uZXQ8bWFpbHRvOmQuc3R1cmVrQGF0dC5uZXQ+Pg0KPiBUbzogSWV0 ZiBSb2xsIDxpZXRmcm9sbEB5YWhvby5jb208bWFpbHRvOmlldGZyb2xsQHlhaG9vLmNvbT4+OyBK UCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPG1haWx0bzpqcHZAY2lzY28uY29tPj47IFRob21hcyBI ZWlkZQ0KPiBDbGF1c2VuIDxpZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0bzppZXRmQHRob21h c2NsYXVzZW4ub3JnPj4NCj4gQ2M6IHJvbGwgV0cgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxA aWV0Zi5vcmc+Pg0KPiBTZW50OiBTdW5kYXksIFNlcHRlbWJlciA0LCAyMDExIDc6MjAgQU0NCj4g U3ViamVjdDogUmU6IFtSb2xsXSBBZG9wdGlvbiBvZiBkcmFmdC1nb3lhbC1yb2xsLXJwbC1jb21w cmVzc2lvbiBhcyBhIG5ldw0KPiBST0xMIFdHIGRvY3VtZW50DQo+DQo+IEhlcmUgYXJlIGEgZmV3 IHBvaW50cyB0byBtYXliZSBjb25zaWRlcjoNCj4gMSkgICBaaWdCZWUgaXMgbm90ICJoYXZpbmcg cHJvYmxlbXMgbWFraW5nIGl0IHdvcmsiIChyZWZlcnJpbmcgdG8gUk9MTCBSUEwuDQo+ICAgSSBj aGFpciB0aGUgZ3JvdXAgaW4gWmlnQmVlIHRlc3RpbmcgIlppZ0JlZSBJUCIgYW5kIHdlIGhhdmUg aGFkIHJlbGF0aXZlbHkNCj4gZ29vZCBzdWNjZXNzIHVzaW5nIFJQTCBmb3IgdGhlIHVzZSBjYXNl cyB3ZSBhcmUgY29uc2lkZXJpbmcuDQo+IDIpICAgVGhlIFNtYXJ0IEVuZXJneSAyLjAgdXNlIGNh c2VzIGFyZSBmb3Igb25seSAzMCBkZXZpY2VzIGluIGEgc2luZ2xlIGhvbWUNCj4gYXJlYSBuZXR3 b3JrLiAgIFdlIGFyZSB0ZXN0aW5nIDMwIG5vZGVzIHdpdGggMyBob3BzDQo+IDMpICAgVGhlIHVw d2FyZCByb3V0aW5nIGZlYXR1cmUgaW4gUlBMIGlzIHF1aXRlIGVmZmljaWVudC4gIFRoZSBkb3du d2FyZA0KPiByb3V0aW5nIGZlYXR1cmUgZWl0aGVyIGFzc3VtZXMgc3RvcmluZyBtb2RlICh3aGlj aCB3ZSBkb24ndCB1c2UpIG9yDQo+IG5vbi1zdG9yaW5nIG1vZGUgd2l0aCBzb3VyY2Ugcm91dGlu ZyAod2hpY2ggZG9lcyBub3Qgb2ZmZXIgcHJvLWFjdGl2ZSBvcg0KPiByZS1hY3RpdmUgcm91dGUg ZXN0YWJsaXNobWVudCkuDQo+IDQpICAgSSBwZXJzb25hbGx5IHdvdWxkIG5vdCB1c2UgUk9MTCBS UEwgYXMgaXQgaXMgZm9yIGxvdyBsYXRlbmN5DQo+IGFwcGxpY2F0aW9ucyBsaWtlIGxpZ2h0aW5n IGNvbnRyb2wsIGhvbWUgYXV0b21hdGlvbiwgZXRjLiAgIEkgZnVsbHkgc3VwcG9ydA0KPiB0aGUg Uk9MTCBSUEwgUDJQIGRyYWZ0IGZvciB0aGVzZSBhcHBsaWNhdGlvbnMuDQo+IE9uIGFkZGl0aW9u YWwsIHBlcmhhcHMgcmVsYXRlZCB0b3BpY3M6DQo+IDUpICBJIGRvbid0IGJlbGlldmUgdGhlcmUg d2lsbCBiZSBvbmx5IGEgc2luZ2xlIG1lc2ggcm91dGluZyBwcm90b2NvbA0KPiBkZWZpbmVkIGZv ciBhbGwgYXBwbGljYXRpb25zIGluIElFVEYuICBJIGZ1bGx5IHN1cHBvcnQgdGhlIHdvcmsgZ29p bmcgb24gaW4NCj4gTUFORVQgYW5kIGFsc28gdGhpbmsgIm1lc2ggdW5kZXIiIHNvbHV0aW9ucyB3 aWxsIGFsc28gYmUgdXNlZnVsIGZvciBzb21lDQo+IGFwcGxpY2F0aW9ucw0KPiBBbmQgZmluYWxs eToNCj4gNikgIEFsbCB0aGlzIHNhaWQsIEkgdGhpbmsgWmlnQmVlIElQIHdpbGwgc3VjY2Vzc2Z1 bGx5IGNvbmNsdWRlIHRlc3RpbmcNCj4gdXNpbmcgUk9MTCBSUEzigKbigKbigKbigKYNCj4gSGFw cHkgdG8gc2lnbiBteSByZWFsIG5hbWUsDQo+IERvbiBTdHVyZWsNCj4NCj4NCj4NCj4gRnJvbTog SWV0ZiBSb2xsIDxpZXRmcm9sbEB5YWhvby5jb208bWFpbHRvOmlldGZyb2xsQHlhaG9vLmNvbT4+ DQo+IFJlcGx5LVRvOiBJZXRmIFJvbGwgPGlldGZyb2xsQHlhaG9vLmNvbTxtYWlsdG86aWV0ZnJv bGxAeWFob28uY29tPj4NCj4gRGF0ZTogU2F0LCAzIFNlcCAyMDExIDAwOjU0OjI1IC0wNzAwIChQ RFQpDQo+IFRvOiBKUCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPG1haWx0bzpqcHZAY2lzY28uY29t Pj4sIFRob21hcyBIZWlkZSBDbGF1c2VuDQo+IDxpZXRmQHRob21hc2NsYXVzZW4ub3JnPG1haWx0 bzppZXRmQHRob21hc2NsYXVzZW4ub3JnPj4NCj4gQ2M6IHJvbGwgV0cgPHJvbGxAaWV0Zi5vcmc8 bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW1JvbGxdIEFkb3B0aW9uIG9m IGRyYWZ0LWdveWFsLXJvbGwtcnBsLWNvbXByZXNzaW9uIGFzIGEgbmV3DQo+IFJPTEwgV0cgZG9j dW1lbnQNCj4NCj4gSlAgVmFzc2V1ciB3cm90ZToNCj4NCj4gKmlmKiB5b3UgdGhpbmsgdGhhdCB0 aGlzIG5vdCBlbGVnYW50IGVub3VnaCAod2hpY2ggaGFzIHRvIGJlIGRlbW9uc3RyYXRlZA0KPiBJ TU8pLCB0aGVuIHlvdSBtdXN0IGJlIHN1cHBvcnRpdmUNCj4gb2YgdGhlIFAyUCBJRHMgd29yayB0 aGF0IHRoZSBXRyBoYXMgYmVlbiB3b3JraW5nIG9uID8NCj4gW3Jhdl0gaG93IGFib3V0IGEgZGVt b25zdHJhdGlvbiB0aGF0IFJQTCBhY3R1YWxseSB3b3JrcyBhcyBwdXJwb3J0ZWQuDQo+IFRob21h cyBoYXMgc2FpZCB0aGF0IGhpcyBncm91cCBpbXBsZW1lbnRlZCBpdCBhbmQgaXQgd2FzIGRpZmZp Y3VsdCwgY29tcGxleA0KPiBhbmQgZnJhdWdodCB3aXRoIGluY29uc2lzdGVuY2llcyBpbiBzcGVj aWZpY2F0aW9uLg0KPiAgICAgICAgICBJIGhlYXJkIHRoYXQgemlnYmVlIGlzIGhhdmluZyBwcm9i bGVtcyBtYWtpbmcgaXQgd29yayBhbmQgdGhlIG9ubHkNCj4gcGFwZXIgdGhhdCBJJ3ZlIHNlZW4g b24gUlBMIHNheXMgdGhhdCBmb3IgY29uc3RyYWluZWQgbm9kZXMgdGhleSByZWNvbW1lbmQNCj4g bm8gbW9yZSB0aGFuIDMwIG5vZGVzIGluIGEgbmV0d29yay4gIEhhcmRseSB0aGUgc2NhbGUgbmVj ZXNzYXJ5IGZvciBzb21lIG9mDQo+IHRoZQ0KPiAgICAgICAgICB1c2UgY2FzZXMgYmVlbiBzdWdn ZXN0ZWQgKGxpa2UgQU1JKS4NCj4NCj4gICAgICAgICAgVGhlIFAyUCBpcyBhIGhhY2sgdG8gdHJ5 IHRvIGZpeCB0aGUgZmFjdCB0aGUgUlBMIGlzIGJhc2ljYWxseSBhDQo+IGNvbGxlY3Rpb24gdHJl ZSBhbmQgYXMgc3VjaCBkb3dud2FyZCByb3V0aW5nIGlzIGFuIGRpc3RhbnQgYWZ0ZXIgdGhvdWdo dA0KPiAoY2VydGFpbmx5IG5vdCBlbGVnYW50KS4NCj4NCj4gICAgICAgICAgV2l0aG91dCBsb3Rz IG9mIG1lbW9yeSwgbm9kZSBtdXN0IHVzZSBub24tc3RvcmluZyBtb2RlIChvaCBhbmQgd2UNCj4g YXJlIHRhbGtpbmcgYWJvdXQgY29uc3RyYWluZWQgZGV2aWNlcyBzbyBsb3RzIG9mIG1lbW9yeSBp cyB0aGVuDQo+IGluY29uc2lzdGVudCkgYW5kIHRoZW4gcm91dGluZyBpcyB1cCB0byB0aGUgcm9v dCBhbmQgYmFjayBkb3duLiAgTm90IHdoYXQNCj4gYW55b25lIHdobw0KPiAgICAgICAgICB1bmRl cnN0YW5kcyByb3V0aW5nIHdvdWxkIGNvbnNpZGVyIGVsZWdhbnQgUDJQLg0KPg0KPiAgICAgICAg ICBJbiB0aGUgcnVzaCB0byBnZXQgUlBMIG91dCBvZiB0aGUgd29ya2luZyBncm91cCB3ZSBhbGwg d2VyZQ0KPiBiYW1ib296bGVkIGJ5IHRoZSBjaGFpciBpbnRvIGJlbGlldmluZyB0aGUgZHJhZnQg d2FzIGFjdHVhbGx5IGNvbXBsZXRlIGFuZA0KPiB0aGUgSUVTRyBmdXJ0aGVyIGNvbXBvdW5kZWQg dGhpcyBlcnJvci4NCj4NCj4gICAgICAgICAgSWYgaXQgd2VyZSBwb3NzaWJsZSB0byBmaXggdGhp bmdzLCBSUEwgc2hvdWxkIGJlIGFuIGV4cGVyaW1lbnRhbA0KPiBkcmFmdCB1bnRpbCBzdWNoIHRp bWUgYXMgdGhlcmUgYXJlIHdvcmtpbmcgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMNCj4g dGhhdCBhcmUgc2hvd24gdG8gcHJvdmlkZSB0aGUgc2VydmljZXMgdGhhdCB3ZXJlIHJlcXVpcmVk IGluIHRoZSB2YXJpb3VzDQo+IFVzZS1jYXNlDQo+ICAgICAgICAgIGRyYWZ0cyAtIG9yIGV2ZW4g anVzdCBvbmUgb2YgdGhlbS4NCj4NCj4gICAgICAgICAgQW5kIG5vdyB3ZSBhcmUgcnVzaGluZyB0 byBnZW5lcmF0ZSBhbmQgcHVibGlzaCBhIG1hcmtldGluZyBkb2N1bWVudA0KPiAoY2FsbGVkIGFu IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50KSB3aXRob3V0IGhhdmluZyBhbnkgZXhwZXJpZW5jZSB3 aXRoIHRoZQ0KPiBwcm90b2NvbC4NCj4NCj4gICAgICAgICAgQXJlIHdlIHJ1c2hpbmcgYW5kIHB1 dHRpbmcgc28gbXVjaCBwcmVzc3VyZSBhbmQgYmVuZGluZyB0aGUgc3lzdGVtcw0KPiBzbyB0aGF0 IHRoaXMgZ2V0cyBwdWJsaXNoZWQgYmVmb3JlIHdlIGZpbmQgd2UndmUgYnVpbHQgYSBob3VzZSBv ZiBjYXJkcyBhbmQNCj4gaXQgY29tZXMgY3Jhc2hpbmcgZG93bi4NCj4NCj4gICAgICAgICAgVGhp cyB3aWxsIGJlIHJlYWxseSBjb3VudGVyIHByb2R1Y3RpdmUgdG8gdGhlIGluZHVzdHJ5IGFuZCB0 aGUNCj4gSW50ZXJuZXQgKGNlcnRhaW5seSBub3QgVGhvbWFzJ3Mgd2FybmluZ3MpLiAgV2hlbiBl dmVyeW9uZSBsb29rcyBhdCB0aGlzDQo+IG1pc3Rha2UgYW5kIHNheXMsIHdoeSBkaWRuJ3QgdGhl IElFVEYgZG8gaXRzIGpvYiBhbmQgZXhlcmNpc2UgcHJvcGVyDQo+IGVuZ2luZWVyaW5nLCB0aGVu IHRoZSBST0xMIFdHDQo+ICAgICAgICAgICBhbmQgdGhlIENoYWlycyB3aWxsIGJlIHRoZSBvbmVz IHRoYXQgaGF2ZSBodXJ0IHRoZSBpbmR1c3RyeSBhbmQNCj4gdGhlIEludGVybmV0Lg0KPg0KPiBS YXYNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g Um9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGlu ZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KPg0KPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xs QGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsDQoNCg== --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE5D201FDIE2RD2XVS211r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hl YWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhpLCA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSBmb3IgdGhlIGxpbmsuPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5BcyBtZW50aW9uZWQgaW4gdGhlIHNlbnRlbmNlLCB0aGlzIGlzIHJlbGF0ZWQgdG8gdGhlIFRp bnlSUEwvQkxJUCBpbXBsZW1lbnRhdGlvbiBvZiBSUEwgcnVuaW5nIG9uIFRlbG9zQiBub2Rlcy4g PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlRlbG9zQiBvZmZlcnMgNDhLIG9mIFJPTSBhbmQgMTBLIG9mIFJBTS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIDMwIG5vZGVzIGxpbWl0YXRpb24gaXMgcmVsYXRlZCB0 byB0aGUgVGVsb3NCIGFyY2hpdGVjdHVyZSAoUkFNIHNpemUgaW4gcGFydGljdWxhcikgYW5kIG5v dCBSUEwuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkJlY2F1c2UgVGVsb3NCIGhhcyBiZWVuIGRlc2lnbmVkIGluIDIwMDQsIHdl IGNhbiBleHBlY3QgdGhhdCBwbGF0Zm9ybXMgdXNlZCBmb3IgUlBMIGRlcGxveW1lbnRzIG9mIHRv ZGF5IG1heSBoYXZlIHF1aXRlIGRpZmZlcmVudCBjaGFyYWN0ZXJpc3RpY3MuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5BdXRob3IgbWF5IGNvbXBsZXRlIG15IHVuZGVyc3RhbmRpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5Dw6lkcmljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiByb2xs LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIDxiPkRlIGxh IHBhcnQgZGU8L2I+IFVscmljaCBIZXJiZXJnPGJyPjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJk aSA2IHNlcHRlbWJyZSAyMDExIDA2OjUyPGJyPjxiPsOAJm5ic3A7OjwvYj4gT21wcmFrYXNoIEdu YXdhbGk8YnI+PGI+Q2MmbmJzcDs6PC9iPiByb2xsIFdHPGJyPjxiPk9iamV0Jm5ic3A7OjwvYj4g UmU6IFtSb2xsXSBBZG9wdGlvbiBvZiBkcmFmdC1nb3lhbC1yb2xsLXJwbC1jb21wcmVzc2lvbiBh cyBhIG5ldyBST0xMIFdHIGRvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz5PbXByYWthc2gsPGJyPjxicj5JIGJlbGlldmUgdGhlIHBhcGVy IGhlIHJlZmVycyB0byBpcyB0aGF0OiA8YnI+Si4gS28sIFMuIERhd3Nvbi1IYWdnZXJ0eSwgTy4g R25hd2FsaSwgRC4gQ3VsbGVyLCBBLiBUZXJ6aXMsICZxdW90O0V2YWx1YXRpbmcgdGhlIFBlcmZv cm1hbmNlIG9mIFJQTCBhbmQgNkxvV1BBTiBpbiBUaW55T1MmcXVvdDs8YnI+PGEgaHJlZj0iaHR0 cDovL2hpbnJnLmNzLmpodS5lZHUvam9vbWxhL2ltYWdlcy9zdG9yaWVzL1RpbnlSUEwucGRmIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2hpbnJnLmNzLmpodS5lZHUvam9vbWxhL2ltYWdlcy9zdG9y aWVzL1RpbnlSUEwucGRmPC9hPjxicj48YnI+T21wcmFrYXNoLCB5b3UgYXJlIGFuIGF1dGhvciBv ZiB0aGF0IHBhcGVyIDotKTxicj48YnI+VGhlIHBhcGVyIHN0YXRlczogJnF1b3Q7SW4gb3VyIGV4 cGVyaW1lbnRzIHdpdGggZG93bnN0cmVhbSByb3V0aW5nIGluIHN0b3JpbmcgbW9kZSwgd2Ugbm90 aWNlZCB0aGF0IHRoZSBjdXJyZW50IFRpbnlSUEwvQkxJUCBpbXBsZW1lbnRhdGlvbnMgb24gVGVs b3NCIG1vdGVzIHN1cHBvcnQgdXAgdG8gPHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiLCJzZXJpZiInPuKIvDwvc3Bhbj4zMCB0YXJnZXQgZGVzdGluYXRpb25zLiBUaGlzIGFy Z3VlcyB0aGF0IHRvIHN1cHBvcnQgcm91dGVzIHRvIGFsbCBub2RlcyBpbiB0aGUgUlBMIG5ldHdv cmssIHRoZSBuZXR3b3Jr4oCZcyBzaXplIG11c3QgYmUgbGltaXRlZCB0byA8c3BhbiBzdHlsZT0n Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCIsInNlcmlmIic+4oi8PC9zcGFuPjMwIG5vZGVzLiZx dW90Ozxicj48YnI+UmVnYXJkczxicj48c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4OCc+VWxyaWNo PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgU2Vw IDUsIDIwMTEgYXQgODo0MSBQTSwgT21wcmFrYXNoIEduYXdhbGkgJmx0OzxhIGhyZWY9Im1haWx0 bzpnbmF3YWxpQGNzLnN0YW5mb3JkLmVkdSI+Z25hd2FsaUBjcy5zdGFuZm9yZC5lZHU8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+Q2FuIHNvbWVvbmUgcG9z dCBhIGxpbmsgdG8gdGhlIHBhcGVyIGJlaW5nIHJlZmVyZW5jZWQ/IFRoYW5rcy48YnI+PGJyPi0g b21fcDxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPk9uIE1v biwgU2VwIDUsIDIwMTEgYXQgNjoyMiBQTSwgSWV0ZiBSb2xsICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZnJvbGxAeWFob28uY29tIj5pZXRmcm9sbEB5YWhvby5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ Jmd0OyBUaGlzIGlzIGdvb2QgbmV3cyB0aGF0IFppZ2JlZSBpcyBtYWtpbmcgaXQgd29yay4mbmJz cDsgSSBndWVzcyB0aGF0IHNpbmNlIHlvdXI8YnI+Jmd0OyByZXF1aXJlbWVudHMgYXJlIG9ubHkg MzAgbm9kZXMgdGhlbiB0aGF0IG1hdGNoZXMgdGhlIHBhcGVyIHRoYXQgc2F5cyBSUEwgZm9yPGJy PiZndDsgY29uc3RyYWluZWQgZGV2aWNlcyBzaG91bGQgYmUgbGltaXRlZCB0byAzMCBub2Rlcy48 YnI+Jmd0OyBJdCBpcyBhbHNvIGdvb2QgdG8gYmUgcmUtYWZmaXJtZWQgdGhhdCBkb3dud2FyZCBy b3V0aW5nIGlzIG5vdCBwYXJ0aWN1bGFybHk8YnI+Jmd0OyBnb29kIGluIFJQTC4mbmJzcDsgT3Ro ZXJzIGhhdmUgYWxyZWFkeSBzdGF0ZWQgdGhpcyBhbmQgWmlnYmVlIHNlZW1zIHRvIGNvbmZpcm08 YnI+Jmd0OyB0aGlzLjxicj4mZ3Q7PGJyPiZndDsgUmF2PGJyPiZndDsgUFMgLSBTaW5jZSBtYW55 IGtlZXAgcG9pbnRpbmcgYXQgbWUsIEkgYW0gbm90IHB1dHRpbmcgbXkgZnVsbCBuYW1lIGFuZDxi cj4mZ3Q7IGNvbXBhbnkgaW4gbXkgZW1haWwgZm9yIEkgZmVhciByZXRyaWJ1dGlvbi4mbmJzcDsg SSBkbyBub3Qgd2FudCB0byBsb3NlIG15IGpvYjxicj4mZ3Q7IGZvciBhc2tpbmcgcXVlc3Rpb25z IGFuZCBjcml0aWNpemluZyBwYXJ0cyBvZiB0aGUgUlBMIGRlc2lnbi4mbmJzcDsgSSBkbyBub3Qg d2FudDxicj4mZ3Q7IG15IGNvbXBhbnkgb3IgbXkgc3VwZXJ2aXNvciBjYWxsZWQgYnkgcGVvcGxl IGxpa2UgYSBjaGFpciBhbmQgaGF2ZSBteSBqb2I8YnI+Jmd0OyBwdXQgYXQgcmlzay48YnI+Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IEZyb206IERvbiBTdHVy ZWsgJmx0OzxhIGhyZWY9Im1haWx0bzpkLnN0dXJla0BhdHQubmV0Ij5kLnN0dXJla0BhdHQubmV0 PC9hPiZndDs8YnI+Jmd0OyBUbzogSWV0ZiBSb2xsICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZnJv bGxAeWFob28uY29tIj5pZXRmcm9sbEB5YWhvby5jb208L2E+Jmd0OzsgSlAgVmFzc2V1ciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5jb20iPmpwdkBjaXNjby5jb208L2E+Jmd0OzsgVGhv bWFzIEhlaWRlPGJyPiZndDsgQ2xhdXNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFz Y2xhdXNlbi5vcmciPmlldGZAdGhvbWFzY2xhdXNlbi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7IENjOiBy b2xsIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwv YT4mZ3Q7PGJyPiZndDsgU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgNCwgMjAxMSA3OjIwIEFNPGJy PiZndDsgU3ViamVjdDogUmU6IFtSb2xsXSBBZG9wdGlvbiBvZiBkcmFmdC1nb3lhbC1yb2xsLXJw bC1jb21wcmVzc2lvbiBhcyBhIG5ldzxicj4mZ3Q7IFJPTEwgV0cgZG9jdW1lbnQ8YnI+Jmd0Ozxi cj4mZ3Q7IEhlcmUgYXJlIGEgZmV3IHBvaW50cyB0byBtYXliZSBjb25zaWRlcjo8YnI+Jmd0OyAx KSAmbmJzcDsgWmlnQmVlIGlzIG5vdCAmcXVvdDtoYXZpbmcgcHJvYmxlbXMgbWFraW5nIGl0IHdv cmsmcXVvdDsgKHJlZmVycmluZyB0byBST0xMIFJQTC48YnI+Jmd0OyAmbmJzcDsgSSBjaGFpciB0 aGUgZ3JvdXAgaW4gWmlnQmVlIHRlc3RpbmcgJnF1b3Q7WmlnQmVlIElQJnF1b3Q7IGFuZCB3ZSBo YXZlIGhhZCByZWxhdGl2ZWx5PGJyPiZndDsgZ29vZCBzdWNjZXNzIHVzaW5nIFJQTCBmb3IgdGhl IHVzZSBjYXNlcyB3ZSBhcmUgY29uc2lkZXJpbmcuPGJyPiZndDsgMikgJm5ic3A7IFRoZSBTbWFy dCBFbmVyZ3kgMi4wIHVzZSBjYXNlcyBhcmUgZm9yIG9ubHkgMzAgZGV2aWNlcyBpbiBhIHNpbmds ZSBob21lPGJyPiZndDsgYXJlYSBuZXR3b3JrLiAmbmJzcDsgV2UgYXJlIHRlc3RpbmcgMzAgbm9k ZXMgd2l0aCAzIGhvcHM8YnI+Jmd0OyAzKSAmbmJzcDsgVGhlIHVwd2FyZCByb3V0aW5nIGZlYXR1 cmUgaW4gUlBMIGlzIHF1aXRlIGVmZmljaWVudC4gJm5ic3A7VGhlIGRvd253YXJkPGJyPiZndDsg cm91dGluZyBmZWF0dXJlIGVpdGhlciBhc3N1bWVzIHN0b3JpbmcgbW9kZSAod2hpY2ggd2UgZG9u J3QgdXNlKSBvcjxicj4mZ3Q7IG5vbi1zdG9yaW5nIG1vZGUgd2l0aCBzb3VyY2Ugcm91dGluZyAo d2hpY2ggZG9lcyBub3Qgb2ZmZXIgcHJvLWFjdGl2ZSBvcjxicj4mZ3Q7IHJlLWFjdGl2ZSByb3V0 ZSBlc3RhYmxpc2htZW50KS48YnI+Jmd0OyA0KSAmbmJzcDsgSSBwZXJzb25hbGx5IHdvdWxkIG5v dCB1c2UgUk9MTCBSUEwgYXMgaXQgaXMgZm9yIGxvdyBsYXRlbmN5PGJyPiZndDsgYXBwbGljYXRp b25zIGxpa2UgbGlnaHRpbmcgY29udHJvbCwgaG9tZSBhdXRvbWF0aW9uLCBldGMuICZuYnNwOyBJ IGZ1bGx5IHN1cHBvcnQ8YnI+Jmd0OyB0aGUgUk9MTCBSUEwgUDJQIGRyYWZ0IGZvciB0aGVzZSBh cHBsaWNhdGlvbnMuPGJyPiZndDsgT24gYWRkaXRpb25hbCwgcGVyaGFwcyByZWxhdGVkIHRvcGlj czo8YnI+Jmd0OyA1KSAmbmJzcDtJIGRvbid0IGJlbGlldmUgdGhlcmUgd2lsbCBiZSBvbmx5IGEg c2luZ2xlIG1lc2ggcm91dGluZyBwcm90b2NvbDxicj4mZ3Q7IGRlZmluZWQgZm9yIGFsbCBhcHBs aWNhdGlvbnMgaW4gSUVURi4gJm5ic3A7SSBmdWxseSBzdXBwb3J0IHRoZSB3b3JrIGdvaW5nIG9u IGluPGJyPiZndDsgTUFORVQgYW5kIGFsc28gdGhpbmsgJnF1b3Q7bWVzaCB1bmRlciZxdW90OyBz b2x1dGlvbnMgd2lsbCBhbHNvIGJlIHVzZWZ1bCBmb3Igc29tZTxicj4mZ3Q7IGFwcGxpY2F0aW9u czxicj4mZ3Q7IEFuZCBmaW5hbGx5Ojxicj4mZ3Q7IDYpICZuYnNwO0FsbCB0aGlzIHNhaWQsIEkg dGhpbmsgWmlnQmVlIElQIHdpbGwgc3VjY2Vzc2Z1bGx5IGNvbmNsdWRlIHRlc3Rpbmc8YnI+Jmd0 OyB1c2luZyBST0xMIFJQTOKApuKApuKApuKApjxicj4mZ3Q7IEhhcHB5IHRvIHNpZ24gbXkgcmVh bCBuYW1lLDxicj4mZ3Q7IERvbiBTdHVyZWs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0 OyBGcm9tOiBJZXRmIFJvbGwgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmcm9sbEB5YWhvby5jb20i PmlldGZyb2xsQHlhaG9vLmNvbTwvYT4mZ3Q7PGJyPiZndDsgUmVwbHktVG86IElldGYgUm9sbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZyb2xsQHlhaG9vLmNvbSI+aWV0ZnJvbGxAeWFob28uY29t PC9hPiZndDs8YnI+Jmd0OyBEYXRlOiBTYXQsIDMgU2VwIDIwMTEgMDA6NTQ6MjUgLTA3MDAgKFBE VCk8YnI+Jmd0OyBUbzogSlAgVmFzc2V1ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5j b20iPmpwdkBjaXNjby5jb208L2E+Jmd0OywgVGhvbWFzIEhlaWRlIENsYXVzZW48YnI+Jmd0OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdGhvbWFzY2xhdXNlbi5vcmciPmlldGZAdGhvbWFzY2xh dXNlbi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7IENjOiByb2xsIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPiZndDsgU3ViamVjdDogUmU6 IFtSb2xsXSBBZG9wdGlvbiBvZiBkcmFmdC1nb3lhbC1yb2xsLXJwbC1jb21wcmVzc2lvbiBhcyBh IG5ldzxicj4mZ3Q7IFJPTEwgV0cgZG9jdW1lbnQ8YnI+Jmd0Ozxicj4mZ3Q7IEpQIFZhc3NldXIg d3JvdGU6PGJyPiZndDs8YnI+Jmd0OyAqaWYqIHlvdSB0aGluayB0aGF0IHRoaXMgbm90IGVsZWdh bnQgZW5vdWdoICh3aGljaCBoYXMgdG8gYmUgZGVtb25zdHJhdGVkPGJyPiZndDsgSU1PKSwgdGhl biB5b3UgbXVzdCBiZSBzdXBwb3J0aXZlPGJyPiZndDsgb2YgdGhlIFAyUCBJRHMgd29yayB0aGF0 IHRoZSBXRyBoYXMgYmVlbiB3b3JraW5nIG9uID88YnI+Jmd0OyBbcmF2XSBob3cgYWJvdXQgYSBk ZW1vbnN0cmF0aW9uIHRoYXQgUlBMIGFjdHVhbGx5IHdvcmtzIGFzIHB1cnBvcnRlZC48YnI+Jmd0 OyBUaG9tYXMgaGFzIHNhaWQgdGhhdCBoaXMgZ3JvdXAgaW1wbGVtZW50ZWQgaXQgYW5kIGl0IHdh cyBkaWZmaWN1bHQsIGNvbXBsZXg8YnI+Jmd0OyBhbmQgZnJhdWdodCB3aXRoIGluY29uc2lzdGVu Y2llcyBpbiBzcGVjaWZpY2F0aW9uLjxicj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGhlYXJkIHRoYXQgemlnYmVlIGlzIGhhdmluZyBwcm9i bGVtcyBtYWtpbmcgaXQgd29yayBhbmQgdGhlIG9ubHk8YnI+Jmd0OyBwYXBlciB0aGF0IEkndmUg c2VlbiBvbiBSUEwgc2F5cyB0aGF0IGZvciBjb25zdHJhaW5lZCBub2RlcyB0aGV5IHJlY29tbWVu ZDxicj4mZ3Q7IG5vIG1vcmUgdGhhbiAzMCBub2RlcyBpbiBhIG5ldHdvcmsuJm5ic3A7IEhhcmRs eSB0aGUgc2NhbGUgbmVjZXNzYXJ5IGZvciBzb21lIG9mPGJyPiZndDsgdGhlPGJyPiZndDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZSBjYXNlcyBi ZWVuIHN1Z2dlc3RlZCAobGlrZSBBTUkpLjxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBQMlAgaXMgYSBoYWNrIHRvIHRy eSB0byBmaXggdGhlIGZhY3QgdGhlIFJQTCBpcyBiYXNpY2FsbHkgYTxicj4mZ3Q7IGNvbGxlY3Rp b24gdHJlZSBhbmQgYXMgc3VjaCBkb3dud2FyZCByb3V0aW5nIGlzIGFuIGRpc3RhbnQgYWZ0ZXIg dGhvdWdodDxicj4mZ3Q7IChjZXJ0YWlubHkgbm90IGVsZWdhbnQpLjxicj4mZ3Q7PGJyPiZndDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdpdGhvdXQg bG90cyBvZiBtZW1vcnksIG5vZGUgbXVzdCB1c2Ugbm9uLXN0b3JpbmcgbW9kZSAob2ggYW5kIHdl PGJyPiZndDsgYXJlIHRhbGtpbmcgYWJvdXQgY29uc3RyYWluZWQgZGV2aWNlcyBzbyBsb3RzIG9m IG1lbW9yeSBpcyB0aGVuPGJyPiZndDsgaW5jb25zaXN0ZW50KSBhbmQgdGhlbiByb3V0aW5nIGlz IHVwIHRvIHRoZSByb290IGFuZCBiYWNrIGRvd24uJm5ic3A7IE5vdCB3aGF0PGJyPiZndDsgYW55 b25lIHdobzxicj4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB1bmRlcnN0YW5kcyByb3V0aW5nIHdvdWxkIGNvbnNpZGVyIGVsZWdhbnQgUDJQLjxi cj4mZ3Q7PGJyPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEluIHRoZSBydXNoIHRvIGdldCBSUEwgb3V0IG9mIHRoZSB3b3JraW5nIGdyb3VwIHdl IGFsbCB3ZXJlPGJyPiZndDsgYmFtYm9vemxlZCBieSB0aGUgY2hhaXIgaW50byBiZWxpZXZpbmcg dGhlIGRyYWZ0IHdhcyBhY3R1YWxseSBjb21wbGV0ZSBhbmQ8YnI+Jmd0OyB0aGUgSUVTRyBmdXJ0 aGVyIGNvbXBvdW5kZWQgdGhpcyBlcnJvci48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBpdCB3ZXJlIHBvc3NpYmxlIHRv IGZpeCB0aGluZ3MsIFJQTCBzaG91bGQgYmUgYW4gZXhwZXJpbWVudGFsPGJyPiZndDsgZHJhZnQg dW50aWwgc3VjaCB0aW1lIGFzIHRoZXJlIGFyZSB3b3JraW5nIGludGVyb3BlcmFibGUgaW1wbGVt ZW50YXRpb25zPGJyPiZndDsgdGhhdCBhcmUgc2hvd24gdG8gcHJvdmlkZSB0aGUgc2VydmljZXMg dGhhdCB3ZXJlIHJlcXVpcmVkIGluIHRoZSB2YXJpb3VzPGJyPiZndDsgVXNlLWNhc2U8YnI+Jmd0 OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnRz IC0gb3IgZXZlbiBqdXN0IG9uZSBvZiB0aGVtLjxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZCBub3cgd2UgYXJlIHJ1c2hp bmcgdG8gZ2VuZXJhdGUgYW5kIHB1Ymxpc2ggYSBtYXJrZXRpbmcgZG9jdW1lbnQ8YnI+Jmd0OyAo Y2FsbGVkIGFuIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50KSB3aXRob3V0IGhhdmluZyBhbnkgZXhw ZXJpZW5jZSB3aXRoIHRoZTxicj4mZ3Q7IHByb3RvY29sLjxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFyZSB3ZSBydXNoaW5n IGFuZCBwdXR0aW5nIHNvIG11Y2ggcHJlc3N1cmUgYW5kIGJlbmRpbmcgdGhlIHN5c3RlbXM8YnI+ Jmd0OyBzbyB0aGF0IHRoaXMgZ2V0cyBwdWJsaXNoZWQgYmVmb3JlIHdlIGZpbmQgd2UndmUgYnVp bHQgYSBob3VzZSBvZiBjYXJkcyBhbmQ8YnI+Jmd0OyBpdCBjb21lcyBjcmFzaGluZyBkb3duLjxi cj4mZ3Q7PGJyPiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFRoaXMgd2lsbCBiZSByZWFsbHkgY291bnRlciBwcm9kdWN0aXZlIHRvIHRoZSBpbmR1 c3RyeSBhbmQgdGhlPGJyPiZndDsgSW50ZXJuZXQgKGNlcnRhaW5seSBub3QgVGhvbWFzJ3Mgd2Fy bmluZ3MpLiZuYnNwOyBXaGVuIGV2ZXJ5b25lIGxvb2tzIGF0IHRoaXM8YnI+Jmd0OyBtaXN0YWtl IGFuZCBzYXlzLCB3aHkgZGlkbid0IHRoZSBJRVRGIGRvIGl0cyBqb2IgYW5kIGV4ZXJjaXNlIHBy b3Blcjxicj4mZ3Q7IGVuZ2luZWVyaW5nLCB0aGVuIHRoZSBST0xMIFdHPGJyPiZndDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCB0aGUg Q2hhaXJzIHdpbGwgYmUgdGhlIG9uZXMgdGhhdCBoYXZlIGh1cnQgdGhlIGluZHVzdHJ5IGFuZDxi cj4mZ3Q7IHRoZSBJbnRlcm5ldC48YnI+Jmd0Ozxicj4mZ3Q7IFJhdjxicj4mZ3Q7PGJyPiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gUm9sbCBtYWls aW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRm Lm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y b2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsPC9hPjxicj4mZ3Q7PGJyPiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgUm9s bCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9s bEBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3JvbGwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PGJyPiZndDs8YnI+Jmd0OzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Um9sbCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciPlJvbGxA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE5D201FDIE2RD2XVS211r_-- From yoshihiro.ohba@toshiba.co.jp Wed Sep 7 22:16:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132CF21F8B2A for ; Wed, 7 Sep 2011 22:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROBnE8hT1M4X for ; Wed, 7 Sep 2011 22:16:03 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3478D21F8B18 for ; Wed, 7 Sep 2011 22:16:02 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p885HqtP021549 for ; Thu, 8 Sep 2011 14:17:52 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p885Hqpc017628 for roll@ietf.org; Thu, 8 Sep 2011 14:17:52 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA17627; Thu, 8 Sep 2011 14:17:52 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p885Hq18029941 for ; Thu, 8 Sep 2011 14:17:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p885Hp60008174; Thu, 8 Sep 2011 14:17:51 +0900 (JST) Received: from [133.196.16.130] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LR6001UBUPR3C80@mail.po.toshiba.co.jp> for roll@ietf.org; Thu, 08 Sep 2011 14:17:51 +0900 (JST) Date: Thu, 08 Sep 2011 14:17:35 +0900 From: Yoshihiro Ohba In-reply-to: <5DAFCC5E-1D44-4DFB-B47A-8BBD708C2C2C@cisco.com> To: roll@ietf.org Message-id: <4E684FEF.8090102@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> <5DAFCC5E-1D44-4DFB-B47A-8BBD708C2C2C@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 05:16:04 -0000 Hello, I think a cross-layer key management approach is important for resource-constrained devices. On the other hand, there are similar approaches proposed in other IETF WG: http://tools.ietf.org/id/draft-arkko-core-security-arch-00.txt http://tools.ietf.org/id/draft-garcia-core-security-02.txt http://tools.ietf.org/id/draft-sarikaya-core-sbootstrapping-02.txt http://tools.ietf.org/id/draft-ohba-core-eap-based-bootstrapping-00.txt (and I am a co-author of the last two ones.) MIKEY-based cross-layer key management (such as described in draft-alexander) can be an alternative, and similar solutions can be defined using other key management protocols such as PANA, TLS, IKEv2, GDOI and maybe HIP. I am not trying to compare them here, but I just want to point out that there are multiple approaches in this area. Regards, Yoshihiro Ohba (2011/09/06 1:36), JP Vasseur wrote: > Thanks Thomas for your feed-back. > > Still, I would encourage people to read and comment; the issue of key > management has been raised by several > ADs and in the security framework, so we may want to make some > progress and address IESG's requests. > > On Sep 5, 2011, at 6:07 PM, Thomas Heide Clausen wrote: > >> Dear JP, >> >> Thanks. I have read the specification a couple of times, but as I am >> not a key-management-expert, I have not (yet) formed any real >> opinions on the technical content. I am still working on that bit ;) >> >> However as you message was cryptic, I wanted to make sure that I did >> not miss any last-review-before-wg-document deadline. I understand >> that there's no immediate deadline so I would suggest that the WG >> gets to consider that when a determination has been made on the >> other ongoing issues currently being discussed >> >> [Not to belittle this document; I, for one, like most LLN routers >> just have limited bandwidth and processing power$B!D(B.trying to make >> sure that they are being used appropriately] >> >> Respectfully yours, >> >> Thomas >> >> >> >> On Sep 5, 2011, at 16:53 , JP Vasseur wrote: >> >>> Hi Thomas, >>> >>> On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote: >>> >>>> Dear JP, >>>> >>>> I am not sure I completely understand the question$B!D!D(Bis this the WG >>>> chair polling the group for adaptation as WG document? >>>> >>>> If yes, when do you plan on making a decision (so as to give a >>>> target as to before when an opinion should have been formed?) >>>> >>> >>> I was polling the WG to get some comment since we did not get a >>> chance to discuss it during the WG meeting, >>> that was not yet a poll for WG adoption. >>> >>> Any opinion to share of this document ? >>> >>> Thanks. >>> >>> JP. >>> >>> >>>> Thomas >>>> >>>> On Aug 31, 2011, at 14:55 , JP Vasseur wrote: >>>> >>>>> Any comment ? >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> *From: *JP Vasseur > >>>>>> *Subject: **[Roll] PLEASE Comment on >>>>>> draft-alexander-roll-mikey-lln-key-mgmt* >>>>>> *Date: *August 26, 2011 9:17:42 AM GMT+02:00 >>>>>> *To: *roll WG > >>>>>> >>>>>> Dear all, >>>>>> >>>>>> Several of you expressed some interest in >>>>>> draft-alexander-roll-mikey-lln-key-mgmt. That said, could you >>>>>> please comment on this I-D as soon as possible ? We need a key >>>>>> management protocol and if it turns >>>>>> out that the WG wants to adopt this ID, I'll poll the WG to make >>>>>> it a WG $B!D(B Please comment. >>>>>> >>>>>> 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 From internet-drafts@ietf.org Wed Sep 7 22:50:42 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF5821F8C79; Wed, 7 Sep 2011 22:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSXdISYcno7a; Wed, 7 Sep 2011 22:50:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175AD21F8C63; Wed, 7 Sep 2011 22:50:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110908055042.2221.89401.idtracker@ietfa.amsl.com> Date: Wed, 07 Sep 2011 22:50:42 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-20.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 05:50:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-20.txt Pages : 14 Date : 2011-09-07 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt From robert.cragie@gmail.com Thu Sep 8 05:10:35 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65C21F8B73 for ; Thu, 8 Sep 2011 05:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti195mowt+NK for ; Thu, 8 Sep 2011 05:10:34 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3121F8B6D for ; Thu, 8 Sep 2011 05:10:33 -0700 (PDT) Received: by vxi29 with SMTP id 29so684091vxi.31 for ; Thu, 08 Sep 2011 05:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EqBpiJ59XmjveyJWYdif7/y44zjQD+WJSxTfl68igcM=; b=GSc3K43aeUFRw+aOhm5Z+opzUkKFMqKD5KeXH32hB2icoaauOTvTS24hxm5nXvDglK 36WHoFPK31wXk29AlBFbiVJQmfRG4FmiE6pKhJupDOsgPF9ynJ+uSRqh85bOgHC9dPWg Jas8EJuOqjj5NKg1dasS1D6RyB1P4ArnNt3YM= MIME-Version: 1.0 Received: by 10.220.9.132 with SMTP id l4mr158937vcl.185.1315483945789; Thu, 08 Sep 2011 05:12:25 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.187.202 with HTTP; Thu, 8 Sep 2011 05:12:25 -0700 (PDT) In-Reply-To: <4E684FEF.8090102@toshiba.co.jp> References: <79860D3D-A86D-474B-BA0B-D4ADDC6977D9@cisco.com> <683511D7-32EE-49F1-AA67-C8599C8775BA@cisco.com> <5DAFCC5E-1D44-4DFB-B47A-8BBD708C2C2C@cisco.com> <4E684FEF.8090102@toshiba.co.jp> Date: Thu, 8 Sep 2011 13:12:25 +0100 X-Google-Sender-Auth: RiFZdYglDDQB9L3YQw8_nsuW-tk Message-ID: From: Robert Cragie To: Yoshihiro Ohba Content-Type: multipart/alternative; boundary=0003255734da4be81704ac6cf9ec Cc: roll@ietf.org Subject: Re: [Roll] PLEASE Comment on draft-alexander-roll-mikey-lln-key-mgmt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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, 08 Sep 2011 12:10:35 -0000 --0003255734da4be81704ac6cf9ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1. I can see the merit in attempting to propose a generic key management protocol but the very fact that different mechanisms exist suggests that it is probably an unattainable target due to the distinct properties of the underlying system the key management is being applied to. Also, I question whether roll *needs* a key management protocol. It needs a key management proposal, which should probably focus on abstract key management operations relevant to roll networks rather than mandating (a) specific key management protocol(s). Or is the desire to be more specific t= o provide better interoperability? Robert 2011/9/8 Yoshihiro Ohba > Hello, > > I think a cross-layer key management approach is important for > resource-constrained devices. On the other hand, there are similar > approaches proposed in other IETF WG: > > http://tools.ietf.org/id/draft-arkko-core-security-arch-00.txt > http://tools.ietf.org/id/draft-garcia-core-security-02.txt > http://tools.ietf.org/id/draft-sarikaya-core-sbootstrapping-02.txt > http://tools.ietf.org/id/draft-ohba-core-eap-based-bootstrapping-00.txt > > (and I am a co-author of the last two ones.) > > MIKEY-based cross-layer key management (such as described in > draft-alexander) can be an alternative, and similar solutions can be > defined using other key management protocols such as PANA, TLS, > IKEv2, GDOI and maybe HIP. > > I am not trying to compare them here, but I just want to point out > that there are multiple approaches in this area. > > Regards, > Yoshihiro Ohba > > (2011/09/06 1:36), JP Vasseur wrote: > > Thanks Thomas for your feed-back. > > > > Still, I would encourage people to read and comment; the issue of key > > management has been raised by several > > ADs and in the security framework, so we may want to make some > > progress and address IESG's requests. > > > > On Sep 5, 2011, at 6:07 PM, Thomas Heide Clausen wrote: > > > >> Dear JP, > >> > >> Thanks. I have read the specification a couple of times, but as I am > >> not a key-management-expert, I have not (yet) formed any real > >> opinions on the technical content. I am still working on that bit ;) > >> > >> However as you message was cryptic, I wanted to make sure that I did > >> not miss any last-review-before-wg-document deadline. I understand > >> that there's no immediate deadline so I would suggest that the WG > >> gets to consider that when a determination has been made on the > >> other ongoing issues currently being discussed > >> > >> [Not to belittle this document; I, for one, like most LLN routers > >> just have limited bandwidth and processing power=85.trying to make > >> sure that they are being used appropriately] > >> > >> Respectfully yours, > >> > >> Thomas > >> > >> > >> > >> On Sep 5, 2011, at 16:53 , JP Vasseur wrote: > >> > >>> Hi Thomas, > >>> > >>> On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote: > >>> > >>>> Dear JP, > >>>> > >>>> I am not sure I completely understand the question=85=85is this the = WG > >>>> chair polling the group for adaptation as WG document? > >>>> > >>>> If yes, when do you plan on making a decision (so as to give a > >>>> target as to before when an opinion should have been formed?) > >>>> > >>> > >>> I was polling the WG to get some comment since we did not get a > >>> chance to discuss it during the WG meeting, > >>> that was not yet a poll for WG adoption. > >>> > >>> Any opinion to share of this document ? > >>> > >>> Thanks. > >>> > >>> JP. > >>> > >>> > >>>> Thomas > >>>> > >>>> On Aug 31, 2011, at 14:55 , JP Vasseur wrote: > >>>> > >>>>> Any comment ? > >>>>> > >>>>> Thanks. > >>>>> > >>>>> JP. > >>>>> > >>>>> Begin forwarded message: > >>>>> > >>>>>> *From: *JP Vasseur > > >>>>>> *Subject: **[Roll] PLEASE Comment on > >>>>>> draft-alexander-roll-mikey-lln-key-mgmt* > >>>>>> *Date: *August 26, 2011 9:17:42 AM GMT+02:00 > >>>>>> *To: *roll WG > > >>>>>> > >>>>>> Dear all, > >>>>>> > >>>>>> Several of you expressed some interest in > >>>>>> draft-alexander-roll-mikey-lln-key-mgmt. That said, could you > >>>>>> please comment on this I-D as soon as possible ? We need a key > >>>>>> management protocol and if it turns > >>>>>> out that the WG wants to adopt this ID, I'll poll the WG to make > >>>>>> it a WG =85 Please comment. > >>>>>> > >>>>>> 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 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0003255734da4be81704ac6cf9ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1.

I can see the merit in attempting to prop= ose a generic key management protocol but the very fact that different mech= anisms exist suggests that it is probably an unattainable target due to the= distinct properties of the underlying system the key management is being a= pplied to.

Also, I question whether roll *needs* a key management proto= col. It needs a key management proposal, which should probably focus on abs= tract key management operations relevant to roll networks rather than manda= ting (a) specific key management protocol(s). Or is the desire to be more s= pecific to provide better interoperability?

Robert

20= 11/9/8 Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
Hello,

I think a cross-layer key management approach is important for
resource-constrained devices. =A0On the other hand, there are similar
approaches proposed in other IETF WG:

http://tools.ietf.org/id/draft-arkko-core-security-arch-0= 0.txt
http://tools.ietf.org/id/draft-garcia-core-security-02.txt
http://tools.ietf.org/id/draft-sarikaya-core-sbootstr= apping-02.txt
http://tools.ietf.org/id/draft-ohba-core-eap-bas= ed-bootstrapping-00.txt

(and I am a co-author of the last two ones.)

MIKEY-based cross-layer key management (such as described in
draft-alexander) can be an alternative, and similar solutions can be
defined using other key management protocols such as PANA, TLS,
IKEv2, GDOI and maybe HIP.

I am not trying to compare them here, but I just want to point out
that there are multiple approaches in this area.

Regards,
Yoshihiro Ohba

(2011/09/06 1:36), JP Vasseur wrote:
> Thanks Thomas for your feed-back.
>
> Still, I would encourage people to read and comment; the issue of key<= br> > management has been raised by several
> ADs and in the security framework, so we may want to make some
> progress and address IESG's requests.
>
> On Sep 5, 2011, at 6:07 PM, Thomas Heide Clausen wrote:
>
>> Dear JP,
>>
>> Thanks. I have read the specification a couple of times, but as I = am
>> not a key-management-expert, I have not (yet) formed any real
>> opinions on the technical content. I am still working on that bit = ;)
>>
>> However as you message was cryptic, I wanted to make sure that I d= id
>> not miss any last-review-before-wg-document deadline. I understand=
>> that there's no immediate deadline so I would suggest that the= WG
>> gets to consider that when a determination has been made on the >> other ongoing issues currently being discussed
>>
>> [Not to belittle this document; I, for one, like most LLN routers<= br> >> just have limited bandwidth and processing power=85.trying to make=
>> sure that they are being used appropriately]
>>
>> Respectfully yours,
>>
>> Thomas
>>
>>
>>
>> On Sep 5, 2011, at 16:53 , JP Vasseur wrote:
>>
>>> Hi Thomas,
>>>
>>> On Sep 5, 2011, at 4:47 PM, Thomas Heide Clausen wrote:
>>>
>>>> Dear JP,
>>>>
>>>> I am not sure I completely understand the question=85=85is= this the WG
>>>> chair polling the group for adaptation as WG document?
>>>>
>>>> If yes, when do you plan on making a decision (so as to gi= ve a
>>>> target as to before when an opinion should have been forme= d?)
>>>>
>>>
>>> I was polling the WG to get some comment since we did not get = a
>>> chance to discuss it during the WG meeting,
>>> that was not yet a poll for WG adoption.
>>>
>>> Any opinion to share of this document ?
>>>
>>> Thanks.
>>>
>>> JP.
>>>
>>>
>>>> Thomas
>>>>
>>>> On Aug 31, 2011, at 14:55 , JP Vasseur wrote:
>>>>
>>>>> Any comment ?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> JP.
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>>> *From: *JP Vasseur <jpv@cisco.com <mailto:jpv@cisco.com>>
>>>>>> *Subject: **[Roll] PLEASE Commen= t on
>>>>>> draft-alexander-roll-mikey-lln-key-mgmt*
>>>>>> *Date: *August 26, 2011 9:17:42 AM GMT+02:00
>>>>>> *To: *roll WG <roll@ietf.org <mailto:roll@i= etf.org>>
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> Several of you expressed some interest in
>>>>>> draft-alexander-roll-mikey-lln-key-mgmt. That said= , could you
>>>>>> please comment on this I-D as soon as possible ? W= e need a key
>>>>>> management protocol and if it turns
>>>>>> out that the WG wants to adopt this ID, I'll p= oll the WG to make
>>>>>> it a WG =85 Please comment.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> JP.
>>>>>> _______________________________________________ >>>>>> Roll mailing list
>>>>>> Roll@ietf.o= rg <mailto:Roll@ietf.org>
>>>>>> https://www.ietf.org/mailman/listi= nfo/roll
>>>>>
>>>>> _______________________________________________
>>>>> 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/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--0003255734da4be81704ac6cf9ec-- From jpv@cisco.com Thu Sep 8 13:58:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD46D21F8B29 for ; Thu, 8 Sep 2011 13:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLwmNbhlgehF for ; Thu, 8 Sep 2011 13:58:58 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8621F8713 for ; Thu, 8 Sep 2011 13:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5626; q=dns/txt; s=iport; t=1315515651; x=1316725251; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=uZWjxVGBXDUqotBh2DhTyb3SjReJqfKBbDjOvSklWRU=; b=SHkpDcDqPCRgczapKJco4h7yw4z/+xJzVySj9plZEvF1ok4FuaLJj7FN YS69CBmwabyYIO3ahTpMVNP5QpPYyko1ONJo2NkRJfbB/ciFh3hY1q22B bbPm3TRt2tVXNdymR+muatqMaV7A57zj+4MGddKAr2hJrI17W03Wgas/O Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC0saU6rRDoG/2dsb2JhbABCqAJ4gUYBAQEBAgEBAQEPARpBCwULC0YnMAYTCRmHUwSZcwGeNoYNYASTM4USCYt9 X-IronPort-AV: E=Sophos;i="4.68,352,1312156800"; d="scan'208,217";a="1020487" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Sep 2011 21:00:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p88L0ndt025516 for ; Thu, 8 Sep 2011 21:00:49 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 14:00:49 -0700 Received: from [10.60.114.231] ([10.60.114.231]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 14:00:48 -0700 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_66A70299-8330-411E-9050-13B21C63904E" From: JP Vasseur In-Reply-To: <20110908055042.2221.89401.idtracker@ietfa.amsl.com> Date: Thu, 8 Sep 2011 23:00:47 +0200 Message-Id: <99BD88E3-D20B-4E51-8D56-E6EC6D77D82C@cisco.com> References: <20110908055042.2221.89401.idtracker@ietfa.amsl.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 08 Sep 2011 21:00:48.0701 (UTC) FILETIME=[629DF6D0:01CC6E6A] Cc: roll WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-of0-20.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 20:58:58 -0000 --Apple-Mail=_66A70299-8330-411E-9050-13B21C63904E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Pascal, May I ask you to provide a summary of the latest changes for the WG = since there were several new revisions lately; since this is a WG it is = important to keep the WG up to date. Many Thanks. JP. On Sep 8, 2011, at 7:50 AM, = wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Routing Over Low power and = Lossy networks Working Group of the IETF. >=20 > Title : RPL Objective Function Zero > Author(s) : Pascal Thubert > Filename : draft-ietf-roll-of0-20.txt > Pages : 14 > Date : 2011-09-07 >=20 > The Routing Protocol for Low Power and Lossy Networks (RPL) > specification defines a generic Distance Vector protocol that is > adapted to a variety of networks types by the application of = specific > Objective Functions (OFs). An OF states the outcome of the process > used by a RPL node to select and optimize routes within a RPL > Instance based on the information objects available; an OF is not = an > algorithm. >=20 > This document specifies a basic Objective Function that relies only > on the objects that are defined in RPL and does not use any = protocol > extension >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail=_66A70299-8330-411E-9050-13B21C63904E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Pascal,

May I ask you to provide a summary of the latest changes for the WG since
there were several new revisions lately; since this is a WG it is important to
keep the WG up to date.

Many Thanks.

JP.

On Sep 8, 2011, at 7:50 AM, <internet-drafts@ietf.org> <internet-drafts@ietf.org> wrote:

[Roll] I-D Action: draft-ietf-roll-of0-20.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

        Title           : RPL Objective Function Zero
        Author(s)       : Pascal Thubert
        Filename        : draft-ietf-roll-of0-20.txt
        Pages           : 14
        Date            : 2011-09-07

   The Routing Protocol for Low Power and Lossy Networks (RPL)
   specification defines a generic Distance Vector protocol that is
   adapted to a variety of networks types by the application of specific
   Objective Functions (OFs).  An OF states the outcome of the process
   used by a RPL node to select and optimize routes within a RPL
   Instance based on the information objects available; an OF is not an
   algorithm.

   This document specifies a basic Objective Function that relies only
   on the objects that are defined in RPL and does not use any protocol
   extension



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


--Apple-Mail=_66A70299-8330-411E-9050-13B21C63904E-- From gnawali@cs.stanford.edu Fri Sep 9 21:05:28 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489EB21F888A for ; Fri, 9 Sep 2011 21:05: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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4oHJz8QDtd2 for ; Fri, 9 Sep 2011 21:05:27 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id B8FF021F8565 for ; Fri, 9 Sep 2011 21:05:27 -0700 (PDT) Received: from mail-yx0-f172.google.com ([209.85.213.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1R2Eqg-0006HO-Ef for roll@ietf.org; Fri, 09 Sep 2011 21:07:22 -0700 Received: by yxt33 with SMTP id 33so770367yxt.31 for ; Fri, 09 Sep 2011 21:07:21 -0700 (PDT) Received: by 10.68.39.230 with SMTP id s6mr436358pbk.11.1315627641069; Fri, 09 Sep 2011 21:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.155.16 with HTTP; Fri, 9 Sep 2011 21:07:01 -0700 (PDT) In-Reply-To: References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> From: Omprakash Gnawali Date: Fri, 9 Sep 2011 23:07:01 -0500 Message-ID: To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Sep 2011 04:05:28 -0000 On Tue, Sep 6, 2011 at 2:40 AM, C Chauvenet wrote: > Hi, > > > > Thank you for the link. > > > > As mentioned in the sentence, this is related to the TinyRPL/BLIP > implementation of RPL runing on TelosB nodes. > > TelosB offers 48K of ROM and 10K of RAM. > > As far as I understand, the 30 nodes limitation is related to the TelosB > architecture (RAM size in particular) and not RPL. > > Because TelosB has been designed in 2004, we can expect that platforms used > for RPL deployments of today may have quite different characteristics. > > > > Author may complete my understanding. Thank you for sharing the paper and also your commentary. We should be concerned about the state requirement of the storing mode. However, we should not extrapolate these results too far beyond the constraints we worked with in our experiments. - om_p From sdhags@gmail.com Sat Sep 10 08:30:48 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1327821F8715 for ; Sat, 10 Sep 2011 08:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9cy5nyoF2Bl for ; Sat, 10 Sep 2011 08:30:46 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BF21F86A4 for ; Sat, 10 Sep 2011 08:30:46 -0700 (PDT) Received: by gwb17 with SMTP id 17so3177369gwb.15 for ; Sat, 10 Sep 2011 08:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5svynuEUuHNKL/ox46kKgo4Sb4xHxWYWB5j5d9kcb/0=; b=FoZATkehjrZMdTle0mYZRoABxMkdD+ng9Yq+gTL3IIckCHdfd15pjHzMAzTpJpOwFf GftrVnxbwdTvyf7aC0rCO+sD76ISlurWJTc3ph1r9rygP8hJ1CoZvQ7JBLLR9hqvShq4 E1SYS56netbz6yJuV18ielxXg6udNhGZTAJ6A= Received: by 10.150.169.11 with SMTP id r11mr827552ybe.315.1315668759129; Sat, 10 Sep 2011 08:32:39 -0700 (PDT) MIME-Version: 1.0 Sender: sdhags@gmail.com Received: by 10.150.206.9 with HTTP; Sat, 10 Sep 2011 08:32:19 -0700 (PDT) In-Reply-To: References: <1315036465.46782.YahooMailNeo@web113917.mail.gq1.yahoo.com> <1315264959.82194.YahooMailNeo@web113916.mail.gq1.yahoo.com> From: Stephen Dawson-Haggerty Date: Sat, 10 Sep 2011 15:32:19 +0000 X-Google-Sender-Auth: cBfytYekcHd8OcG3pMq1TDoQ_kQ Message-ID: To: C Chauvenet Content-Type: multipart/alternative; boundary=000e0cd58cde07b1fd04ac980178 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Sep 2011 15:30:48 -0000 --000e0cd58cde07b1fd04ac980178 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I implemented most of the parts that are limited to 30, and I believe it could certainly be improved even with telosb-style memory. RPL table size is only one limiting factor at the moment, there are also packet buffers which could be either shrunk or differently managed. Furthermore, at the cost of a little more code space we could easily compress the routing table -- right now we store full destination addresses and next hops but these often share a common prefix, usually /112 if short addresses are in use. Steve On Tue, Sep 6, 2011 at 12:40 AM, C Chauvenet wrote= : > Hi, **** > > ** ** > > Thank you for the link.**** > > ** ** > > As mentioned in the sentence, this is related to the TinyRPL/BLIP > implementation of RPL runing on TelosB nodes. **** > > TelosB offers 48K of ROM and 10K of RAM.**** > > As far as I understand, the 30 nodes limitation is related to the TelosB > architecture (RAM size in particular) and not RPL.**** > > Because TelosB has been designed in 2004, we can expect that platforms us= ed > for RPL deployments of today may have quite different characteristics.***= * > > ** ** > > Author may complete my understanding.**** > > ** ** > > C=C3=A9dric.**** > > ** ** > > *De :* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *De la part d= e > * Ulrich Herberg > *Envoy=C3=A9 :* mardi 6 septembre 2011 06:52 > *=C3=80 :* Omprakash Gnawali > *Cc :* roll WG > *Objet :* Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a ne= w > ROLL WG document**** > > ** ** > > Omprakash, > > I believe the paper he refers to is that: > J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating > the Performance of RPL and 6LoWPAN in TinyOS" > http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf > > Omprakash, you are an author of that paper :-) > > The paper states: "In our experiments with downstream routing in storing > mode, we noticed that the current TinyRPL/BLIP implementations on TelosB > motes support up to =E2=88=BC30 target destinations. This argues that to = support > routes to all nodes in the RPL network, the network=E2=80=99s size must b= e limited > to =E2=88=BC30 nodes." > > Regards > Ulrich**** > > On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali > wrote:**** > > Can someone post a link to the paper being referenced? Thanks. > > - om_p**** > > > On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll wrote: > > This is good news that Zigbee is making it work. I guess that since yo= ur > > requirements are only 30 nodes then that matches the paper that says RP= L > for > > constrained devices should be limited to 30 nodes. > > It is also good to be re-affirmed that downward routing is not > particularly > > good in RPL. Others have already stated this and Zigbee seems to confi= rm > > this. > > > > Rav > > PS - Since many keep pointing at me, I am not putting my full name and > > company in my email for I fear retribution. I do not want to lose my j= ob > > for asking questions and criticizing parts of the RPL design. I do not > want > > my company or my supervisor called by people like a chair and have my j= ob > > put at risk. > > ________________________________ > > From: Don Sturek > > To: Ietf Roll ; JP Vasseur ; Thomas > Heide > > Clausen > > Cc: roll WG > > Sent: Sunday, September 4, 2011 7:20 AM > > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a n= ew > > ROLL WG document > > > > Here are a few points to maybe consider: > > 1) ZigBee is not "having problems making it work" (referring to ROLL > RPL. > > I chair the group in ZigBee testing "ZigBee IP" and we have had > relatively > > good success using RPL for the use cases we are considering. > > 2) The Smart Energy 2.0 use cases are for only 30 devices in a single > home > > area network. We are testing 30 nodes with 3 hops > > 3) The upward routing feature in RPL is quite efficient. The downwar= d > > routing feature either assumes storing mode (which we don't use) or > > non-storing mode with source routing (which does not offer pro-active o= r > > re-active route establishment). > > 4) I personally would not use ROLL RPL as it is for low latency > > applications like lighting control, home automation, etc. I fully > support > > the ROLL RPL P2P draft for these applications. > > On additional, perhaps related topics: > > 5) I don't believe there will be only a single mesh routing protocol > > defined for all applications in IETF. I fully support the work going o= n > in > > MANET and also think "mesh under" solutions will also be useful for som= e > > applications > > And finally: > > 6) All this said, I think ZigBee IP will successfully conclude testing > > using ROLL RPL=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6 > > Happy to sign my real name, > > Don Sturek > > > > > > > > From: Ietf Roll > > Reply-To: Ietf Roll > > Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT) > > To: JP Vasseur , Thomas Heide Clausen > > > > Cc: roll WG > > Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a n= ew > > ROLL WG document > > > > JP Vasseur wrote: > > > > *if* you think that this not elegant enough (which has to be demonstrat= ed > > IMO), then you must be supportive > > of the P2P IDs work that the WG has been working on ? > > [rav] how about a demonstration that RPL actually works as purported. > > Thomas has said that his group implemented it and it was difficult, > complex > > and fraught with inconsistencies in specification. > > I heard that zigbee is having problems making it work and the > only > > paper that I've seen on RPL says that for constrained nodes they > recommend > > no more than 30 nodes in a network. Hardly the scale necessary for som= e > of > > the > > use cases been suggested (like AMI). > > > > The P2P is a hack to try to fix the fact the RPL is basically = a > > collection tree and as such downward routing is an distant after though= t > > (certainly not elegant). > > > > Without lots of memory, node must use non-storing mode (oh and > we > > are talking about constrained devices so lots of memory is then > > inconsistent) and then routing is up to the root and back down. Not wh= at > > anyone who > > understands routing would consider elegant P2P. > > > > In the rush to get RPL out of the working group we all were > > bamboozled by the chair into believing the draft was actually complete > and > > the IESG further compounded this error. > > > > If it were possible to fix things, RPL should be an experiment= al > > draft until such time as there are working interoperable implementation= s > > that are shown to provide the services that were required in the variou= s > > Use-case > > drafts - or even just one of them. > > > > And now we are rushing to generate and publish a marketing > document > > (called an applicability statement) without having any experience with > the > > protocol. > > > > Are we rushing and putting so much pressure and bending the > systems > > so that this gets published before we find we've built a house of cards > and > > it comes crashing down. > > > > This will be really counter productive to the industry and the > > Internet (certainly not Thomas's warnings). When everyone looks at thi= s > > mistake and says, why didn't the IETF do its job and exercise proper > > engineering, then the ROLL WG > > and the Chairs will be the ones that have hurt the industry a= nd > > the Internet. > > > > Rav > > > > _______________________________________________ Roll mailing list > > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > >**** > > > _______________________________________________**** > > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > >**** > > _______________________________________________**** > > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll**** > > ** ** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --=20 stephen dawson-haggerty http://cs.berkeley.edu/~stevedh uc berkeley wireless and embedded systems lab berkeley, ca 94720 --000e0cd58cde07b1fd04ac980178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I implemented most of the parts that are limited to 30, and I believe it co= uld certainly be improved even with telosb-style memory. =C2=A0RPL table si= ze is only one limiting factor at the moment, there are also packet buffers= which could be either shrunk or differently managed. =C2=A0Furthermore, at= the cost of a little more code space we could easily compress the routing = table -- right now we store full destination addresses and next hops but th= ese often share a common prefix, usually /112 if short addresses are in use= .

Steve

On Tue, Sep 6= , 2011 at 12:40 AM, C Chauvenet <c.chauvenet@watteco.com> wrote:

Hi,

= =C2=A0

Thank= you for the link.

=C2=A0

As mentioned in the sentence= , this is related to the TinyRPL/BLIP implementation of RPL runing on Telos= B nodes.

TelosB offers 48K of ROM and 10K of RAM.

As fa= r as I understand, the 30 nodes limitation is related to the TelosB archite= cture (RAM size in particular) and not RPL.

Because TelosB has been desi= gned in 2004, we can expect that platforms used for RPL deployments of toda= y may have quite different characteristics.

=C2=A0<= /p>

Au= thor may complete my understanding.

=C2=A0<= /p>

C=C3= =A9dric.

=C2=A0

De=C2=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Ul= rich Herberg
Envoy=C3=A9=C2=A0: mardi 6 septembre 2011 06:52
=C3=80=C2=A0:<= /b> Omprakash Gnawali
Cc=C2=A0: roll WG
Objet=C2=A0: Re= : [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG docu= ment

=C2=A0

Omprakash,

I believe = the paper he refers to is that:
J. Ko, S. Dawson-Haggerty, O. Gnawali, = D. Culler, A. Terzis, "Evaluating the Performance of RPL and 6LoWPAN i= n TinyOS"
http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf<= br>
Omprakash, you are an author of that paper :-)

The paper stat= es: "In our experiments with downstream routing in storing mode, we no= ticed that the current TinyRPL/BLIP implementations on TelosB motes support= up to =E2=88=BC30 target destinations. This argues that to support rout= es to all nodes in the RPL network, the network=E2=80=99s size must be limi= ted to =E2=88=BC30 nodes."

Regards
Ulrich

On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnaw= ali <gnawal= i@cs.stanford.edu> wrote:

Can someone post a link to the paper being reference= d? Thanks.

- om_p

=
On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <ietfroll@yahoo.com> wrote:
> This is good news that Zigbee is making it work.=C2=A0 I guess that si= nce your
> requirements are only 30 nodes then that matches the paper= that says RPL for
> constrained devices should be limited to 30 node= s.
> It is also good to be re-affirmed that downward routing is not particu= larly
> good in RPL.=C2=A0 Others have already stated this and Zigbee= seems to confirm
> this.
>
> Rav
> PS - Since many= keep pointing at me, I am not putting my full name and
> company in my email for I fear retribution.=C2=A0 I do not want to los= e my job
> for asking questions and criticizing parts of the RPL desi= gn.=C2=A0 I do not want
> my company or my supervisor called by peopl= e like a chair and have my job
> put at risk.
> ________________________________
> From: Do= n Sturek <d.sturek= @att.net>
> To: Ietf Roll <ietfroll@yahoo.com>; JP Vasseur <jpv@cisco.com>; Thomas H= eide
> Clausen <ietf@thomasclausen.org>
> Cc: roll WG <roll@ietf.org>
> Sent: Sunday= , September 4, 2011 7:20 AM
> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a = new
> ROLL WG document
>
> Here are a few points to maybe= consider:
> 1) =C2=A0 ZigBee is not "having problems making it = work" (referring to ROLL RPL.
> =C2=A0 I chair the group in ZigBee testing "ZigBee IP" and w= e have had relatively
> good success using RPL for the use cases we a= re considering.
> 2) =C2=A0 The Smart Energy 2.0 use cases are for on= ly 30 devices in a single home
> area network. =C2=A0 We are testing 30 nodes with 3 hops
> 3) = =C2=A0 The upward routing feature in RPL is quite efficient. =C2=A0The down= ward
> routing feature either assumes storing mode (which we don'= t use) or
> non-storing mode with source routing (which does not offer pro-active = or
> re-active route establishment).
> 4) =C2=A0 I personally w= ould not use ROLL RPL as it is for low latency
> applications like li= ghting control, home automation, etc. =C2=A0 I fully support
> the ROLL RPL P2P draft for these applications.
> On additional, = perhaps related topics:
> 5) =C2=A0I don't believe there will be = only a single mesh routing protocol
> defined for all applications in= IETF. =C2=A0I fully support the work going on in
> MANET and also think "mesh under" solutions will also be use= ful for some
> applications
> And finally:
> 6) =C2=A0All= this said, I think ZigBee IP will successfully conclude testing
> us= ing ROLL RPL=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6
> Happy to sign my real name,
> Don Sturek
>
>
>=
> From: Ietf Roll <ietfroll@yahoo.com>
> Reply-To: Ietf Roll <ietfroll@yahoo.com&= gt;
> Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
> To: JP Vasseur <= jpv@cisco.com>, T= homas Heide Clausen
> <ietf@thomasclausen.org>
> Cc: roll WG <rol= l@ietf.org>
> Subject: Re: [Roll] Adoption of draft-goyal-roll= -rpl-compression as a new
> ROLL WG document
>
> JP Vasse= ur wrote:
>
> *if* you think that this not elegant enough (which has to be d= emonstrated
> IMO), then you must be supportive
> of the P2P ID= s work that the WG has been working on ?
> [rav] how about a demonstr= ation that RPL actually works as purported.
> Thomas has said that his group implemented it and it was difficult, co= mplex
> and fraught with inconsistencies in specification.
> = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I heard that zigbee is hav= ing problems making it work and the only
> paper that I've seen on RPL says that for constrained nodes they r= ecommend
> no more than 30 nodes in a network.=C2=A0 Hardly the scale= necessary for some of
> the
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 use cases been suggested (like AMI).
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The P2P is a = hack to try to fix the fact the RPL is basically a
> collection tree = and as such downward routing is an distant after thought
> (certainly= not elegant).
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Without lots of memory, node must use non-storing mode (oh and we > are talking about constrained devices so lots of memory is then
>= ; inconsistent) and then routing is up to the root and back down.=C2=A0 Not= what
> anyone who
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 understands routing would consider elegant P2P.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the rush t= o get RPL out of the working group we all were
> bamboozled by the ch= air into believing the draft was actually complete and
> the IESG fur= ther compounded this error.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If it were possible t= o fix things, RPL should be an experimental
> draft until such time a= s there are working interoperable implementations
> that are shown to= provide the services that were required in the various
> Use-case
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draf= ts - or even just one of them.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 And now we are rushing to generate and publish a mark= eting document
> (called an applicability statement) without having a= ny experience with the
> protocol.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Are we rushing and putting so much pressure and bending the systems<= br>> so that this gets published before we find we've built a house = of cards and
> it comes crashing down.
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will be = really counter productive to the industry and the
> Internet (certain= ly not Thomas's warnings).=C2=A0 When everyone looks at this
> mi= stake and says, why didn't the IETF do its job and exercise proper
> engineering, then the ROLL WG
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 and the Chairs will be the ones that have hurt the= industry and
> the Internet.
>
> Rav
>
> ___= ____________________________________________ Roll mailing list
> Roll@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/roll
>
>

> _________________________________________= ______

______________________________________= _________

=C2=A0


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll




--
stephen = dawson-haggerty
http://cs.berkeley.edu/~stevedh
uc berkeley wireless and embed= ded systems lab
berkeley, ca 94720
--000e0cd58cde07b1fd04ac980178-- From pal@cs.stanford.edu Sat Sep 10 14:15:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3621F8906 for ; Sat, 10 Sep 2011 14:15:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH9sQpxa3kUt for ; Sat, 10 Sep 2011 14:15:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0321F88A0 for ; Sat, 10 Sep 2011 14:15:21 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R2UvO-0000gG-Uz; Sat, 10 Sep 2011 14:17:19 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> Date: Sat, 10 Sep 2011 14:17:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <902899BD-1A87-4BB5-99FE-748B4860254D@cs.stanford.edu> References: <36101A99-F6FC-4E94-A7D2-DD7EAB6CEBA3@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Sep 2011 21:15:27 -0000 On Aug 30, 2011, at 2:10 AM, Thomas Heide Clausen wrote: > All, >=20 > Let me reiterate what I said at the Quebec meeting at the microphone: = I find it incomprehensible if - before the ink is dry on the RPL RFC and = before an RFC number has even been assigned to the specification - the = working group finds it necessary to invent a "compression mechanism" for = RPL.=20 >=20 > After all, RPL was supposed to have been designed for networks with = (among other characteristics) a small MTU. >=20 > If this document is necessary, then the logical conclusion would have = to be that the initial design of (at least) the packet format of RPL was = insufficient, and that therefore this document should either or both of = "Updates/Obsoletes" RPL? >=20 > If this document is not intended to either or both of = "Updates/Obsoletes" RPL, then I do not see any justification for the = document being adopted. >=20 > Respectfully Yours, >=20 > Thomas Thomas, Apologies for the tardy response: I just returned from an (unheard of = for Americans!) two week vacation with no email contact. I fear that you might be misrepresenting the situation: RPL does not = have an RFC number not because of uncertainty on its content, but rather = for procedural reasons. Specifically, it references several other = documents that are in the queue and its number can't be assigned until = those dependencies are resolved. That being said, you comment is totally valid: if compression is a big = deal, why isn't it in the core spec? There was a lot of tension in = writing the RPL document on completeness versus simplicity, with many = people taking different positions. Some thought it should be split into = three: the core spec, storing mode, and non-storing mode. Others thought = up and down should be separate. Others still thought it should include = more, such as the Trickle algorithm. After a lot of back-and-forth, I = had though that we as a working group reached consensus that the one = submitted to the IESG was a reasonable compromise between all of the = different proposed approaches. That being said, I can assure you that if = we'd added another X pages on compression, someone would have suggested = we remove it and put it in a separate document. Compression places a tradeoff between computational cost and code = size/complexity versus packet size. Because it's a tradeoff, it seems = like a mistake to mandate it; correspondingly, it's an optional = approach, which practice, use and deployment will evaluate and validate = or discard. So necessitating it in the core spec seems like a mistake to = me. What do you think? BTW, apologies I couldn't make Quebec, it would have been nice to catch = up. Phil From pal@cs.stanford.edu Sat Sep 10 14:22:55 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD521F84EC for ; Sat, 10 Sep 2011 14:22:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6sHZnCs-6tP for ; Sat, 10 Sep 2011 14:22:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6535E21F84E1 for ; Sat, 10 Sep 2011 14:22:55 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R2V2k-0000pD-5P; Sat, 10 Sep 2011 14:24:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> Date: Sat, 10 Sep 2011 14:24:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <178F3A34-5018-44B4-B348-69DC37964F51@cs.stanford.edu> References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Cc: roll WG Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Sep 2011 21:22:56 -0000 On Aug 31, 2011, at 10:08 AM, Thomas Heide Clausen wrote: >=20 > On Aug 31, 2011, at 19:05 , JP Vasseur wrote: >=20 >>=20 >> On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On Aug 31, 2011, at 18:41 , JP Vasseur wrote: >>>=20 >>> > >>> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote: >>> > >>> >> I would actually argue that RPL and P2P-RPL are two entirely = different protocols (albeit sharing some commonalities in the overall = message structure). >>> >> >>> >> There are ways of making multiple routing protocols co-exist on = the same routers (and in the same network). However I am not sure that = it is such a good idea to do so in a LLN. >>> >> >>> >> I've always found it odd that P2P traffic was not supported in = RPL -- and really, dog-leg routing through a DODAG root and using source = routing isn't (efficiently) supporting P2P. >>> > >>> > Thomas, >>> > >>> > I cannot let you say this =85 you perfectly know that the core = specification of RPL supports P2P traffic. >>>=20 >>> Ah, but you must, JP, you must. >>>=20 >>> Note that I said in the above that RPL supports P2P traffic by way = of dog-leg routing through the DODAG root, then source routing -- that's = the _only_ way P2P is supported, guaranteed to work across all the = different RPL-flavors (storing/non-storing with/without RPL-P2P, =85) = that the WG is exploring. >>>=20 >> Well the sentence was, to say the least, strangely worded =85 As you = know, you go via the root only if you deploy non-storing. >>=20 >=20 > Well, given the state requirements for storing-mode in networks larger = than a few handful of routers, non-storing mode seems to be the only = realistic choice for the lions share of deployments that I am aware of.=20= >=20 > Thus, dog-leg-source-routing is pretty much the only viable option - = and you must admit that it's not a particularly elegant or efficient = option at that? Thomas, In the mesh space, I'm less concerned with "elegant," which is based on = taste and mental conception, than "works," which means it's practical = and actually solves problems. You know as well as I do how wireless mesh = research (and even proposed standards!) is a graveyard of elegant = solutions which don't work. =20 Up-down routing may not be very efficient in the data plane, it's true: = but it has significant benefits in terms of the size and cost of = maintaining routing tables, in terms of RAM, state management = complexity, and control traffic. There are plenty of deployments today = which use it because it's simple and practical. =46rom the perspective = of an elegant idea for the academy, it's not very appealing; but I trust = the engineers I've spoken with on how attractive it is as a practical = solution. It's clear that if P2P traffic between nodes distant from = roots is the dominant traffic pattern, one might want something more = efficient (hence the P2P work); but many networks are simpler data = collection networks with smaller amounts of P2P traffic, and ignoring = their needs seems mistaken to me. Phil= From adam@sics.se Sat Sep 10 14:23:14 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDEF21F8A62 for ; Sat, 10 Sep 2011 14:23:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNc9BGfrPgHS for ; Sat, 10 Sep 2011 14:23:13 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by ietfa.amsl.com (Postfix) with ESMTP id C3A7E21F84E1 for ; Sat, 10 Sep 2011 14:23:13 -0700 (PDT) Received: from [192.168.1.71] (c-d2f3e155.771-1-64736c10.cust.bredbandsbolaget.se [85.225.243.210]) (Authenticated sender: adam@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 009CF3FFFF for ; Sat, 10 Sep 2011 23:25:07 +0200 (CEST) Message-ID: <4E6BD5A7.6090701@sics.se> Date: Sat, 10 Sep 2011 23:24:55 +0200 From: Adam Dunkels User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] FYI: Contiki 2.5 with RPL released X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 10 Sep 2011 21:23:15 -0000 Hi all, FYI: Contiki 2.5 was just released: http://www.contiki-os.org/ ContikiRPL, the Contiki RPL implementation, is now the default IPv6 Contiki routing protocol. Contiki with IPv6/RPL routing runs nicely on a number of platforms and over both always-on 802.15.4 and duty cycled low-power 802.15.4 (ContikiMAC). Here is a quick tutorial for setting up a RPL network in the Contiki simulator: http://www.sics.se/contiki/wiki/index.php/Setting_up_a_Low-Power_IPv6/RPL_Network (Note that the Instant Contiki development environment that is mentioned in the tutorial is still not updated to the latest 2.5 version.) Best regards, /adam -- Adam Dunkels | +46 70 7731614 | http://www.sics.se/~adam/ Book: Interconnecting Smart Objects with IP - http://TheNextInternet.org From pthubert@cisco.com Mon Sep 12 02:24:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1621F8AE1 for ; Mon, 12 Sep 2011 02:24:51 -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.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTlQGMlhynyS for ; Mon, 12 Sep 2011 02:24:51 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA1721F8AD3 for ; Mon, 12 Sep 2011 02:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2891; q=dns/txt; s=iport; t=1315819605; x=1317029205; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=C4rhBtDM65K5gXwrr6RNuO/RBKhXQJTnMKo4npFzHB0=; b=Ndi8b/PsyNkVANzXBGdz5MRRPnJX3gBUY1dtp+YyRbkEKyr9Ib4dhHNW xP7gFZMZaWoa7lkqCL9ylKjt8focCOKm7lLu4vrIA6eZMuzjX3wwBD56p 4KOe5qb6B6wQv6X5gLeG4rAykaQgrAXqcgTICpqF+6oN8ozzAbiS+kgvh o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGAJjPbU6Q/khN/2dsb2JhbABBmTaOT3iBUgEBAQEDAQEBDwEdCjQXBgEZBAEBCwYXAQcmHwkJAQQTCAERCIdZlhKBJgGdEoYOYASYW4Rphxc X-IronPort-AV: E=Sophos;i="4.68,367,1312156800"; d="scan'208";a="54175971" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Sep 2011 09:26:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8C9QhRb022181 for ; Mon, 12 Sep 2011 09:26:44 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, 12 Sep 2011 11:26: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: Mon, 12 Sep 2011 11:26:43 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D057112BD@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: News about draft-ietf-roll-of0-20.txt Thread-Index: AcxxLhRigbQ/4GS5S/q05HLPmAu18A== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 12 Sep 2011 09:26:44.0370 (UTC) FILETIME=[16505720:01CC712E] Subject: [Roll] News about draft-ietf-roll-of0-20.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 09:24:52 -0000 Dear WG: The IESG record for OF0 can be accessed at : https://datatracker.ietf.org/doc/draft-ietf-roll-of0/ballot/ You'll find that OF0-20 now has enough positions to pass and no open DISCUSS. Draft -20 is an attempt to resolve Ralph's comment that you'll find in the link above. I have no feedback yet that this specific goal is achieved. Version 15 is the one that went into IESG review. The major changes that happened since are: - clarify that only a single OF instance is currently supported in RPL and that multiple OFs is for further study. - clarify that an OF is not an algorithm but the specification of an outcome - clarify that the validation of a link or a router includes (admin) policies as well as (measured) quality - clarify the role of the rank_factor - clarify that some SHOULDs (e.g. use dodag config option) can be superseded by further guidance. The overall diff can be viewed by going to http://tools.ietf.org/rfcdiff and using file 1 URL of draft-ietf-roll-of0-15.txt and file URL 2 of draft-ietf-roll-of0-20.txt Many thanks to all those in the WG who helped on this work, and most specific kudos for his thorough care to our A-D Adrian. : ) Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: jeudi 8 septembre 2011 07:51 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-of0-20.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function Zero Author(s) : Pascal Thubert Filename : draft-ietf-roll-of0-20.txt Pages : 14 Date : 2011-09-07 The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Tue Sep 13 14:52:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA4511E811E for ; Tue, 13 Sep 2011 14:52:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF5Oe+ryvKds for ; Tue, 13 Sep 2011 14:52:06 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5A84711E8117 for ; Tue, 13 Sep 2011 14:51:57 -0700 (PDT) Received: from mail-yw0-f44.google.com ([209.85.213.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1R3avb-0003ls-Gu for roll@ietf.org; Tue, 13 Sep 2011 14:54:03 -0700 Received: by ywa6 with SMTP id 6so972920ywa.31 for ; Tue, 13 Sep 2011 14:54:02 -0700 (PDT) Received: by 10.68.64.101 with SMTP id n5mr40629pbs.279.1315950842060; Tue, 13 Sep 2011 14:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.77.1 with HTTP; Tue, 13 Sep 2011 14:53:41 -0700 (PDT) In-Reply-To: <20110913214738.30744.1691.idtracker@ietfa.amsl.com> References: <20110913214738.30744.1691.idtracker@ietfa.amsl.com> From: Omprakash Gnawali Date: Tue, 13 Sep 2011 16:53:41 -0500 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 21:52:07 -0000 Dear WG, I just added a quick note on storing mode, hoping to capture the implementation experiences. Please take a look. Thank you. - om_p ---------- Forwarded message ---------- From: Date: Tue, Sep 13, 2011 at 4:47 PM Subject: New Version Notification for draft-gnawali-roll-rpl-recommendations-02.txt To: gnawali@cs.stanford.edu Cc: gnawali@cs.stanford.edu, pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-rpl-recommendations-02.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL Creation date: =A0 2011-09-13 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 6 Abstract: =A0 RPL is a flexible routing protocol applicable to a wide range of Low =A0 Power and Lossy Networks. =A0To enable this wide applicability, RPL =A0 provides many configuration options and gives implementers choices on =A0 how to implement various components of RPL. =A0Drawing on our =A0 experiences, we distill the design choices and configuration =A0 parameters that lead to efficient RPL implementations and operations. The IETF Secretariat From ulrich@herberg.name Tue Sep 13 15:25:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4FA21F8C80 for ; Tue, 13 Sep 2011 15:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puhZ7s+fh5DL for ; Tue, 13 Sep 2011 15:25:00 -0700 (PDT) Received: from mail-vw0-f42.google.com (mail-vw0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id B932721F8C72 for ; Tue, 13 Sep 2011 15:24:59 -0700 (PDT) Received: by vwl1 with SMTP id 1so1585683vwl.15 for ; Tue, 13 Sep 2011 15:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d8ml69O1WLfUNmZf0xzFjNRwxeC27VR21myCgGHfYcM=; b=oQiS6uyyFjQzqiesGTjy0aKlXJeKg+vmLIAQ7aAVb+2n2J43qmibvup96TvwvVTWit LH6HnDl/CbfFkNihgIMvO8Ghbc5OWBuYy7KopTmuC7Uf/DxaA49Y9lUlQKsP5OU93hNS sCQOwD3zNFCJKcmv0vXyZdASmRHxU4a2tdwUU= MIME-Version: 1.0 Received: by 10.52.76.196 with SMTP id m4mr2780136vdw.237.1315952826605; Tue, 13 Sep 2011 15:27:06 -0700 (PDT) Received: by 10.220.84.211 with HTTP; Tue, 13 Sep 2011 15:27:06 -0700 (PDT) In-Reply-To: References: <20110913214738.30744.1691.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 15:27:06 -0700 Message-ID: From: Ulrich Herberg To: Omprakash Gnawali Content-Type: multipart/alternative; boundary=bcaec5015d07c55ede04acda24e7 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 22:25:04 -0000 --bcaec5015d07c55ede04acda24e7 Content-Type: text/plain; charset=ISO-8859-1 Omprakash, thanks for the update of the draft. For easier discussion, I have included the paragraph you have added in the draft: "A naive implementation of storing mode will have large state overhead, especially in large networks. However, it is possible for storing mode to use RAM efficiently by state aggregation, compression, and other techniques. Current open source implementations are known to limit the routing table size to 30 (TinyOS on TelosB which has 10KB of RAM) and 100 (Contiki on MSP430F5438-based platform which has 16K of RAM)." I think it is useful for implementers to have such a paragraph which describes the trade-offs and considerations to make before deploying an RPL network in either of the modes of operation. I agree that compression and other mechanisms can reduce the state to some degree. When using compression, I would assume that a constant factor can be gained (with possible loss of scope of addresses). But the tables will still grow with O(n) with n being the nodes in the network. Maybe we could add that to the sentence? Concerning aggregation, I am not convinced that this always may work efficiently, in particular when the network is dynamic (some nodes may be added later, others may be replaced etc). In that case, the address space could be non-continuous, which would require some additional protocol to handle the assigned addresses intelligently, or the aggregation would be much less effective. Regards Ulrich On Tue, Sep 13, 2011 at 2:53 PM, Omprakash Gnawali wrote: > Dear WG, > > I just added a quick note on storing mode, hoping to capture the > implementation experiences. Please take a look. Thank you. > > - om_p > > ---------- Forwarded message ---------- > From: > Date: Tue, Sep 13, 2011 at 4:47 PM > Subject: New Version Notification for > draft-gnawali-roll-rpl-recommendations-02.txt > To: gnawali@cs.stanford.edu > Cc: gnawali@cs.stanford.edu, pal@cs.stanford.edu > > > A new version of I-D, draft-gnawali-roll-rpl-recommendations-02.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. > > Filename: draft-gnawali-roll-rpl-recommendations > Revision: 02 > Title: Recommendations for Efficient Implementation of RPL > Creation date: 2011-09-13 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > RPL is a flexible routing protocol applicable to a wide range of Low > Power and Lossy Networks. To enable this wide applicability, RPL > provides many configuration options and gives implementers choices on > how to implement various components of RPL. Drawing on our > experiences, we distill the design choices and configuration > parameters that lead to efficient RPL implementations and operations. > > > > > The IETF Secretariat > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --bcaec5015d07c55ede04acda24e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Omprakash,

thanks for the update of the draft. For easier discussion, I have included = the paragraph you have added in the draft:

"A naive implementation of storing mode will have large state=A0=A0=A0=
overhead, especially in large networks. However, it is possible for=A0=A0= =A0
storing mode to use RAM efficiently by state aggregation,=A0=A0=A0
compression, and other techniques. Current open source=A0=A0=A0
implementations are known to limit the routing table size to 30=A0=A0=A0 (TinyOS on TelosB which has 10KB of RAM) and 100 (Contiki on=A0=A0=A0
MSP430F5438-based platform which has 16K of RAM)."

I think it is useful for implementers to have such a paragraph which descri= bes the trade-offs and considerations to make before deploying an RPL netwo= rk in either of the modes of operation.

I agree that compression and other mechanisms can reduce the state to=20 some degree. When using compression, I would assume that a constant=20 factor can be gained (with possible loss of scope of addresses). But the tables will still grow with O(n) with n being the nodes in the network. Maybe we could add that to the sentence?
Concerning aggregation, I am not convinced that this always may work effici= ently, in particular when the network is dynamic (some nodes may be added later,=20 others may be replaced etc). In that case, the address space could be=20 non-continuous, which would require some additional protocol to handle=20 the assigned addresses intelligently, or the aggregation would be much=20 less effective.


Regards
Ulrich


On Tue, Sep 13, 2011 at 2:53 PM, Ompraka= sh Gnawali <gnawali@cs.stanford.edu> wrote:
Dear WG,

I just added a quick note on storing mode, hoping to capture the
implementation experiences. Please take a look. Thank you.

- om_p

---------- Forwarded message ----------
From: =A0<internet-drafts@ie= tf.org>
Date: Tue, Sep 13, 2011 at 4:47 PM
Subject: New Version Notification for
draft-gnawali-roll-rpl-recommendations-02.txt
To: gnawali@cs.stanford.edu<= br> Cc: gnawali@cs.stanford.edu,= pal@cs.stanford.edu


A new version of I-D, draft-gnawali-roll-rpl-recommendations-02.txt
has been successfully submitted by Omprakash Gnawali and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL
Creation date: =A0 2011-09-13
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6

Abstract:
=A0 RPL is a flexible routing protocol applicable to a wide range of Low =A0 Power and Lossy Networks. =A0To enable this wide applicability, RPL
=A0 provides many configuration options and gives implementers choices on =A0 how to implement various components of RPL. =A0Drawing on our
=A0 experiences, we distill the design choices and configuration
=A0 parameters that lead to efficient RPL implementations and operations.



The IETF Secretariat
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--bcaec5015d07c55ede04acda24e7-- From internet-drafts@ietf.org Wed Sep 14 11:27:10 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0444D21F8CB1; Wed, 14 Sep 2011 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hvi64mxD+AJz; Wed, 14 Sep 2011 11:27:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B34221F8CB4; Wed, 14 Sep 2011 11:27:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914182709.21489.27768.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 11:27:09 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 18:27:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Applicability Statement for the Routing Protocol for Low= Power and Lossy Networks (RPL) in AMI Networks Author(s) : Daniel Popa Jorjeta Jetcheva Nicolas Dejean Ruben Salazar Jonathan W. Hui Filename : draft-ietf-roll-applicability-ami-02.txt Pages : 17 Date : 2011-09-14 This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-02.txt From Jorjeta.Jetcheva@itron.com Wed Sep 14 11:30:03 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919321F8CE9 for ; Wed, 14 Sep 2011 11:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 663q3dSsuhfj for ; Wed, 14 Sep 2011 11:30:02 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id E227C21F8CCD for ; Wed, 14 Sep 2011 11:30:00 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Wed, 14 Sep 2011 11:32:09 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Wed, 14 Sep 2011 11:32:03 -0700 Thread-Topic: I-D Action: draft-ietf-roll-applicability-ami-02.txt Thread-Index: AcxzDJk5kdLOCFsGSVS62gQnhzXpqw== Message-ID: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ACnd AQHC Ac4J Afuf B+sr CE6A Cgw+ Cioa DvQw ERmH EVg/ Fea6 GdTP IrSY I2uc JqKZ; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {5EF2D58C-462E-41A9-9ACB-EDED62BAAE36}; agBvAHIAagBlAHQAYQAuAGoAZQB0AGMAaABlAHYAYQBAAGkAdAByAG8AbgAuAGMAbwBtAA==; Wed, 14 Sep 2011 18:32:03 GMT; SQAtAEQAIABBAGMAdABpAG8AbgA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAHIAbwBsAGwALQBhAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AC0AYQBtAGkALQAwADIALgB0AHgAdAA= x-cr-puzzleid: {5EF2D58C-462E-41A9-9ACB-EDED62BAAE36} acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 18:30:03 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 02). We've made a few improvements to th= e draft based on feedback from the group received so far. Thank you all wh= o sent us questions, comments and suggestions! Below is a brief summary of the changes: - Expanded discussion of Trickle parameter setting considerations - Updates related to battery operated meters and routing infrastructure - Expanded discussion related to network topology characteristics - Updates related to traffic characteristics - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments - Clarification and readability improvements We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta [cid:image001.jpg@01CC720F.4C690A50] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC720F.4C690A50] [cid:im= age003.jpg@01CC720F.4C690A50] [cid:im= age004.jpg@01CC720F.4C690A50] [cid:image005.jpg@01CC720F.4C690A50] --_000_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello everyone,

 

Just wanted to draw your attention to the new itera= tion of the RPL AMI Applicability Internet-Draft (version 02).  We’ve ma= de a few improvements to the draft based on feedback from the group received so far.  Thank you all who sent us questions, comments and suggestions!

 

Below is a brief summary of the changes:=

 

- Expanded discussion of Trickle parameter setting considerations

- Updates related to battery operated meters and ro= uting infrastructure

- Expanded discussion related to network topology characteristics

- Updates related to traffic characteristics <= /o:p>

- Removed text discussing the benefits of multi-hop deployments vs. single-hop deployments

- Clarification and readability improvements <= /o:p>

 

We look forward to your feedback as we work on improvi= ng the draft further!

 

Thanks, Jorjeta

 

 

3D"http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg"

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jp= &n= bsp;  &n= bsp; 3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.j= &n= bsp; 

 

 

--_000_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Wed, 14 Sep 2011 11:32:06 GMT"; modification-date="Wed, 14 Sep 2011 11:32:06 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Wed, 14 Sep 2011 11:32:07 GMT"; modification-date="Wed, 14 Sep 2011 11:32:07 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Wed, 14 Sep 2011 11:32:07 GMT"; modification-date="Wed, 14 Sep 2011 11:32:07 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Wed, 14 Sep 2011 11:32:07 GMT"; modification-date="Wed, 14 Sep 2011 11:32:07 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Wed, 14 Sep 2011 11:32:08 GMT"; modification-date="Wed, 14 Sep 2011 11:32:08 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4D1DBA49ITREXMBXVS2itro_-- From jpv@cisco.com Wed Sep 14 11:44:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBF621F8B61 for ; Wed, 14 Sep 2011 11:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqi1fXkKfEQ2 for ; Wed, 14 Sep 2011 11:44:49 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3021F8B24 for ; Wed, 14 Sep 2011 11:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=10863; q=dns/txt; s=iport; t=1316026019; x=1317235619; h=from:mime-version:subject:date:references:cc:to: message-id; bh=9v4Oby+9dIT4JFWbZGLFuWcA/UQ9fygI/Y67aQipGJw=; b=EZQiNE6GZGiGh/Nks5UFdIdTVaKp/qWXWInUFsVQEhWc7ftbiL+x6e/R TU8r3FmKzRRh6IdSvB+AE3GNCr2Knv5tAJJE+QKUiyQ89gJfVc2Jg+m2C ceismx8tM9wHmlJ1cpX1lcr8Fvfqaqq+3l+uAh3J/HtSxGxW/b7FOWR4s 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM/1cE6rRDoG/2dsb2JhbABCp0h4gVMBAQQBAQEBDwFbCwUHBBwDAQEBKAcnHwkIBhMJEQiHVQSWKAGeUYYOYASTP4UbCYRqhzM X-IronPort-AV: E=Sophos;i="4.68,382,1312156800"; d="scan'208,217";a="2140855" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 14 Sep 2011 18:46:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8EIkw7T001607; Wed, 14 Sep 2011 18:46:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 11:46:58 -0700 Received: from [172.30.0.138] ([10.21.65.172]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 11:46:57 -0700 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C3A6FCA-A7D5-47D3-AE37-131C56EDFA2A" Date: Wed, 14 Sep 2011 14:46:56 -0400 References: <6A2A459175DABE4BB11DE2026AA50A5D057112BD@XMB-AMS-107.cisco.com> To: roll WG Message-Id: <6B888E8B-60B8-4499-920C-1B08CA8DBE8E@cisco.com> X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 14 Sep 2011 18:46:58.0064 (UTC) FILETIME=[AE768100:01CC730E] Cc: David Culler Subject: [Roll] * opportunity to comments * Fwd: News about draft-ietf-roll-of0-20.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 18:44:50 -0000 --Apple-Mail=_5C3A6FCA-A7D5-47D3-AE37-131C56EDFA2A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear WG, I think that we had plenty of discussions on the mailing list about this = document, with lots of fruitful comments. Thanks Pascal for summarizing changes when posting = new revisions. For the record, we had a WG Last Call on version -07 and IETF Last call = on version -14. Since we had several revisions to address IESG DISCUSS, I would like to = open a 1-week=20 window opportunity for comments (on changes between revision -14 and = -20), which will=20 end on Sept 21th at noon ET. Thanks. JP. Begin forwarded message: > From: "Pascal Thubert (pthubert)" > Subject: [Roll] News about draft-ietf-roll-of0-20.txt > Date: September 12, 2011 5:26:43 AM EDT > To: >=20 > Dear WG: >=20 > The IESG record for OF0 can be accessed at : > https://datatracker.ietf.org/doc/draft-ietf-roll-of0/ballot/ >=20 > You'll find that OF0-20 now has enough positions to pass and no open > DISCUSS. >=20 > Draft -20 is an attempt to resolve Ralph's comment that you'll find in > the link above. I have no feedback yet that this specific goal is > achieved. >=20 > Version 15 is the one that went into IESG review. The major changes = that > happened since are: >=20 > - clarify that only a single OF instance is currently supported in RPL > and that multiple OFs is for further study. > - clarify that an OF is not an algorithm but the specification of an > outcome > - clarify that the validation of a link or a router includes (admin) > policies as well as (measured) quality > - clarify the role of the rank_factor > - clarify that some SHOULDs (e.g. use dodag config option) can be > superseded by further guidance. >=20 > The overall diff can be viewed by going to = http://tools.ietf.org/rfcdiff > and using file 1 URL of draft-ietf-roll-of0-15.txt and file URL 2 of > draft-ietf-roll-of0-20.txt >=20 > Many thanks to all those in the WG who helped on this work, and most > specific kudos for his thorough care to our A-D Adrian. >=20 > : ) >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > internet-drafts@ietf.org > Sent: jeudi 8 septembre 2011 07:51 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-of0-20.txt >=20 > 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. >=20 > Title : RPL Objective Function Zero > Author(s) : Pascal Thubert > Filename : draft-ietf-roll-of0-20.txt > Pages : 14 > Date : 2011-09-07 >=20 > The Routing Protocol for Low Power and Lossy Networks (RPL) > specification defines a generic Distance Vector protocol that is > adapted to a variety of networks types by the application of = specific > Objective Functions (OFs). An OF states the outcome of the process > used by a RPL node to select and optimize routes within a RPL > Instance based on the information objects available; an OF is not an > algorithm. >=20 > This document specifies a basic Objective Function that relies only > on the objects that are defined in RPL and does not use any protocol > extension >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt > _______________________________________________ > 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=_5C3A6FCA-A7D5-47D3-AE37-131C56EDFA2A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = WG,

I think that we had plenty of discussions on the = mailing list about this document, with lots
of fruitful = comments. Thanks Pascal for summarizing changes when posting new = revisions.
For the record, we had a WG Last Call on version = -07 and IETF Last call on version -14.
Since we had several = revisions to address IESG DISCUSS, I would like to open a = 1-week 
window opportunity for comments (on changes = between revision -14 and -20), which will 
end on = Sept 21th at noon = ET.

Thanks.

JP.
=

Begin forwarded message:

From: "Pascal Thubert = (pthubert)" <pthubert@cisco.com>
Subject: = [Roll] News about = draft-ietf-roll-of0-20.txt
Date: September 12, 2011 5:26:43 AM = EDT

Dear WG:

The IESG record for OF0 can be accessed at :
http= s://datatracker.ietf.org/doc/draft-ietf-roll-of0/ballot/

You'll= find that OF0-20 now has enough positions to pass and no = open
DISCUSS.

Draft -20 is an attempt to resolve Ralph's = comment that you'll find in
the link above. I have no feedback yet = that this specific goal is
achieved.

Version 15 is the one = that went into IESG review. The major changes that
happened since = are:

- clarify that only a single OF instance is currently = supported in RPL
and that multiple OFs is for further study.
- = clarify that an OF is not an algorithm but the specification of = an
outcome
- clarify that the validation of a link or a router = includes (admin)
policies as well as (measured) quality
- clarify = the role of the rank_factor
- clarify that some SHOULDs (e.g. use = dodag config option) can be
superseded by further = guidance.

The overall diff can be viewed by going to = http://tools.ietf.org/rfcdiff
and using file 1 URL of = draft-ietf-roll-of0-15.txt and file URL 2 = of
draft-ietf-roll-of0-20.txt

Many thanks to all those in the = WG who helped on this work, and most
specific kudos for his thorough = care to our A-D Adrian.

: = )

Pascal


-----Original Message-----
From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of
internet-drafts@ietf.org
Sent: jeudi 8 septembre 2011 = 07:51
To: i-d-announce@ietf.org
Cc: roll@ietf.org
Subject: = [Roll] I-D Action: draft-ietf-roll-of0-20.txt

A New = Internet-Draft is available from the on-line = Internet-Drafts
directories. This draft is a work item of the Routing = Over Low power and
Lossy networks Working Group of the = IETF.

= Title =           : RPL = Objective Function Zero
Author(s) =       : Pascal Thubert
Filename =        : = draft-ietf-roll-of0-20.txt
Pages =           : = 14
= Date =            : = 2011-09-07

  The Routing Protocol for Low Power and = Lossy Networks (RPL)
  specification defines a generic = Distance Vector protocol that is
  adapted to a variety of = networks types by the application of specific
  Objective = Functions (OFs).  An OF states the outcome of the process
=   used by a RPL node to select and optimize routes within a = RPL
  Instance based on the information objects available; = an OF is not an
  algorithm.

  This = document specifies a basic Objective Function that relies only
=   on the objects that are defined in RPL and does not use any = protocol
  extension



A URL for this = Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt
<= br>Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-of0-20.txt
__= _____________________________________________
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=_5C3A6FCA-A7D5-47D3-AE37-131C56EDFA2A-- From internet-drafts@ietf.org Wed Sep 14 13:58:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20F921F8C21; Wed, 14 Sep 2011 13:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASDuHoIiTSRL; Wed, 14 Sep 2011 13:58:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E995E21F8B68; Wed, 14 Sep 2011 13:58:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914205826.8406.42286.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 13:58:26 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-terminology-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 20:58:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : JP Vasseur Filename : draft-ietf-roll-terminology-06.txt Pages : 8 Date : 2011-09-14 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.txt From jpv@cisco.com Wed Sep 14 14:01:17 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DF021F8CC3 for ; Wed, 14 Sep 2011 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PM1QfSQM5Ps for ; Wed, 14 Sep 2011 14:01:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2121F8CC2 for ; Wed, 14 Sep 2011 14:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7440; q=dns/txt; s=iport; t=1316034203; x=1317243803; h=from:subject:date:references:to:message-id:mime-version; bh=tGZYq2RemksbjFicLqu9j9eIljJA7nY8Yew+wpl5DjI=; b=bL4KM6LU33qnDh/vKTaO8qVryzoe5m3R5xplHg7DN6LjpfaMpvg73A78 SOtT7XiORXLr8wklLSe3WuSj3CW/iSPrDolyespgU23cCwDV1YXqju1tB YTub31n8OSszgln3Qb/7U8XrHgbvW1Sy2iGjuSSVDw7rXNi3HOT6b+7zT w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPUVcU6rRDoG/2dsb2JhbABCp0h4gVMBAQQBAQEBDwFbEAscAwECLycfBwIIBhMJEgeHVQSVRAGeUoYOYASTP4UbCYRqhzM X-IronPort-AV: E=Sophos;i="4.68,382,1312156800"; d="scan'208,217";a="2163233" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Sep 2011 21:03:23 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8EL3NWA004515 for ; Wed, 14 Sep 2011 21:03:23 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 14:03:23 -0700 Received: from [172.30.0.138] ([10.21.119.54]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 14:03:23 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_FAADB51F-CEAE-408E-A5A0-894836EE3093" Date: Wed, 14 Sep 2011 17:03:22 -0400 References: <20110914205826.8406.42286.idtracker@ietfa.amsl.com> To: roll WG Message-Id: <7D425BC1-D039-4665-84E5-17B6B4481012@cisco.com> Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 14 Sep 2011 21:03:23.0068 (UTC) FILETIME=[BD1AFFC0:01CC7321] Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-terminology-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 21:01:17 -0000 --Apple-Mail=_FAADB51F-CEAE-408E-A5A0-894836EE3093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just a simple refresh. Thanks. JP. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-roll-terminology-06.txt > Date: September 14, 2011 4:58:26 PM EDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Reply-To: internet-drafts@ietf.org >=20 > 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. >=20 > Title : Terminology in Low power And Lossy Networks > Author(s) : JP Vasseur > Filename : draft-ietf-roll-terminology-06.txt > Pages : 8 > Date : 2011-09-14 >=20 > The documents defines a terminology for discussing routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). A LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, = building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_FAADB51F-CEAE-408E-A5A0-894836EE3093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = a simple = refresh.

Thanks.

JP.


Begin forwarded message:

Subject: I-D Action: = draft-ietf-roll-terminology-06.txt
Date: September 14, 2011 = 4:58:26 PM EDT
Reply-To: = internet-drafts@ietf.org
<= /span>

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 =           : = Terminology in Low power And Lossy Networks
Author(s) =       : JP Vasseur
Filename =        : = draft-ietf-roll-terminology-06.txt
Pages =           : 8
Date =            : = 2011-09-14

  The documents defines a terminology for = discussing routing
  requirements and solutions for = networks referred to as Low power and
  Lossy Networks = (LLN).  A LLN is typically composed of many embedded
=   devices with limited power, memory, and processing = resources
  interconnected by a variety of links. =  There is a wide scope of
  application areas for = LLNs, including industrial monitoring, building
=   automation (e.g.  Heating, Ventilating, Air = Conditioning, lighting,
  access control, fire), connected = home, healthcare, environmental
  monitoring, urban sensor = networks, energy management, assets
  tracking, = refrigeration.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.t= xt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

This Internet-Draft can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-terminology-06.t= xt
_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= = --Apple-Mail=_FAADB51F-CEAE-408E-A5A0-894836EE3093-- From c.chauvenet@watteco.com Thu Sep 15 01:58:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAD621F8782 for ; Thu, 15 Sep 2011 01:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNvCvVuU79WD for ; Thu, 15 Sep 2011 01:58:07 -0700 (PDT) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9321F8781 for ; Thu, 15 Sep 2011 01:58:06 -0700 (PDT) Received: from mail59-tx2-R.bigfish.com (10.9.14.245) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Thu, 15 Sep 2011 09:00:17 +0000 Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2-R.bigfish.com (Postfix) with ESMTP id 9E4F613F0280; Thu, 15 Sep 2011 09:00:17 +0000 (UTC) X-SpamScore: -18 X-BigFish: VPS-18(zzc89bh1431Jc85eh14e3M14ffO4015Lzz1202hzzc704dh8275bhz2dh2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB024.red002.local; RD:none; EFVD:NLI Received: from mail59-tx2 (localhost.localdomain [127.0.0.1]) by mail59-tx2 (MessageSwitch) id 1316077216929539_20976; Thu, 15 Sep 2011 09:00:16 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.240]) by mail59-tx2.bigfish.com (Postfix) with ESMTP id D7CD817E0050; Thu, 15 Sep 2011 09:00:16 +0000 (UTC) Received: from IE2RD2HUB024.red002.local (213.199.187.153) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 15 Sep 2011 09:00:16 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB024.red002.local ([10.43.198.102]) with mapi; Thu, 15 Sep 2011 02:00:06 -0700 From: C Chauvenet To: "Jetcheva, Jorjeta" Date: Thu, 15 Sep 2011 02:00:04 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Thread-Index: AcxzhdyXpUsFdX3EREujihRyqGyWQQ== Message-ID: References: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_B1614F84C135496ABA06E4B9EED96AE0wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:58:08 -0000 --_000_B1614F84C135496ABA06E4B9EED96AE0wattecocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jorjeta, Thank you for the update, I think the doc brings additional valuable conten= t in this new revision. I have 2 comments about this new version of the draft : In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly = asymmetric, and mostly narrowed to MP2P traffic. I agree that most of the traffic in AMI will be sent by meters to the LBR. = Though, as stated a little bit above in the doc, most of meters will be pol= led, resulting in P2MP traffic (unicast or multicast packets). So, my under= standing is that if every meters is polled before sending its data, the tra= ffic becomes symmetrical, because you have a 1:1 ratio between downward (LB= R polling) and upward (Meter reporting) traffic. Could you please help me to understand your statement ? I think the traffic pattern may impact significantly the Storing Vs Non-Sto= ring design choice. In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) = may be suitable for energy constrained node much as water or gas meters. I am not sure about the efficiency of Hop Count regarding energy consumptio= n. As we are working in lossy networks, there is a great chance that the sh= ortest path may not be the more reliable. So the shortest path may induce m= any MAC level retries (thus inducing a faster energy drop of the node, and = a higher congestion of the channel), and decrease significantly the reliabi= lity. This could result in a path that cannot meet the requirements of AMI = (regarding reliability especially). I guess you mentioned Hop count, becaus= e you get an minimum number of forwarder, thus reducing the number of devic= es involved in the path, and minimizing the impact of a packet in the globa= l energy depletion of the global networks. I think this is very true in not= -so-lossy networks, but I was wondering about lossy networks. In my opinion, LQL may be more adapted. Maybe your were thinking about mixi= ng Hop Count and LQL? About energy, note that a specific metric has been designed in the rpl-metr= ic-draft. It may be worth to mention it. Best, C=E9dric. Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 02). We=92ve made a few improvements to = the draft based on feedback from the group received so far. Thank you all = who sent us questions, comments and suggestions! Below is a brief summary of the changes: - Expanded discussion of Trickle parameter setting considerations - Updates related to battery operated meters and routing infrastructure - Expanded discussion related to network topology characteristics - Updates related to traffic characteristics - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments - Clarification and readability improvements We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future --_000_B1614F84C135496ABA06E4B9EED96AE0wattecocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jorjeta, 

Thank you for the update, I think the= doc brings additional valuable content in this new revision.

<= /div>
I have 2 comments about this new version of the draft : 

In 2.2.1 : It is mentioned that the traffic in AMI ne= tworks will be highly asymmetric, and mostly narrowed to MP2P traffic. = ;
I agree that most of the traffic in AMI will be sent by meters = to the LBR. Though, as stated a little bit above in the doc, most of meters= will be polled, resulting in P2MP traffic (unicast or multicast packets). = So, my understanding is that if every meters is polled before sending its d= ata, the traffic becomes symmetrical, because you have a 1:1 ratio between = downward (LBR polling) and upward (Meter reporting) traffic.
Coul= d you please help me to understand your statement ?
I think the t= raffic pattern may impact significantly the Storing Vs Non-Storing design c= hoice.


In 4.1.4 : It is mentioned t= hat Hop Count (HC) or Link Quality Level (LQL) may be suitable for energy c= onstrained node much as water or gas meters.
I am not sure about = the efficiency of Hop Count regarding energy consumption. As we are working= in lossy networks, there is a great chance that the shortest path may not = be the more reliable. So the shortest path may induce many MAC level retrie= s (thus inducing a faster energy drop of the node, and a higher congestion = of the channel), and decrease significantly the reliability. This could res= ult in a path that cannot meet the requirements of AMI (regarding reliabili= ty especially). I guess you mentioned Hop count, because you get an minimum= number of forwarder, thus reducing the number of devices involved in the p= ath, and minimizing the impact of a packet in the global energy depletion o= f the global networks. I think this is very true in not-so-lossy networks, = but I was wondering about lossy networks.
In my opinion, LQL may = be more adapted. Maybe your were thinking about mixing Hop Count and LQL?
About energy, note that a specific metric has been designed in the= rpl-metric-draft. It may be worth to mention it.

= Best,

C=E9dric.


Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit :
Hello everyone,
 
Just wanted to draw= your attention to the new iteration of the RPL AMI Applicability Internet-= Draft (version 02).  We=92ve made a few improvements to the draft base= d on feedback from the group received so far.  Thank you all who sent = us questions, comments and suggestions!
 
Below is a brief summa= ry of the changes:
 
- Expanded discussion of Trickle parameter = setting considerations
- Updates related to battery operated meters and = routing infrastructure
- Expanded discussion related to network topology= characteristics
- Updates related to traffic characteristics=
- Remov= ed text discussing the benefits of multi-hop deployments vs. single-hop dep= loyments
- Clarification and readability improvements
 
We look forward to your feedback as we work on improving the draft furt= her!
 
Thanks, Jorjeta
 =
 
<= td valign=3D"bottom" style=3D"padding-top: 0in; padding-right: 0in; padding= -bottom: 0in; padding-left: 0in; ">
<image002.jpg>   <= a href=3D"http://www.facebook.com/ItronInc" style=3D"color: blue; text-deco= ration: underline; "><image003.j= pg>   <image004.jpg>   <image005.jpg>
Jorjeta Jetcheva= , Ph.D.
Strategic Industry Standards and Architecture<= o:p>
Office of the CTO
Mobile: +1.408.688.1428
K= nowledge to Shape Your Future
 
 
<ATT00001..txt>
=
= --_000_B1614F84C135496ABA06E4B9EED96AE0wattecocom_-- From nicolas.dejean.ietf@googlemail.com Fri Sep 16 01:06:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D74121F8BCD for ; Fri, 16 Sep 2011 01:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGKBgrJbusl4 for ; Fri, 16 Sep 2011 01:06:06 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBF121F8BB5 for ; Fri, 16 Sep 2011 01:06:06 -0700 (PDT) Received: by wwn22 with SMTP id 22so261430wwn.1 for ; Fri, 16 Sep 2011 01:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BwVn/jD/paGoH7CxPouQAgMJx821OK39pKkPFmFPrFM=; b=vok5rXLLInN6FBzK1E+Q/gV22LDSdPNPxoCRq4jQb53p2MXrDbnDFbKtafvFK9REmb ELRja4MXwcknKu7oZduytLX34V2kuQ4P2PRU8IdOBBnO25kgcteSSwFpenSuDNZFRDx1 CCcw0dlg30MpGYNBULIkISPyoAORpaCWo4Sjg= MIME-Version: 1.0 Received: by 10.227.59.13 with SMTP id j13mr813570wbh.100.1316160499556; Fri, 16 Sep 2011 01:08:19 -0700 (PDT) Received: by 10.180.97.71 with HTTP; Fri, 16 Sep 2011 01:08:19 -0700 (PDT) In-Reply-To: References: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> Date: Fri, 16 Sep 2011 10:08:19 +0200 Message-ID: From: Nicolas DEJEAN To: C Chauvenet Content-Type: multipart/alternative; boundary=20cf30025c140b225604ad0a7f9f Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:06:08 -0000 --20cf30025c140b225604ad0a7f9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello C=E9dric, I will answer to your second comment. I completely agree with you and this is excatly what is meant by "Hop Count and Link Quality Level". Moreover, the comment about an objective able to deal with more than one metric in section 4.1.5 follows the same idea. However, I agree that this is not clear enough in the draft and it will be updated in the next release. Something like a "combination of Hop Count and Link Quality Level" should appear. I also agree about the energy metric. The next release will also be updated accordingly. Cheers, Nicolas. 2011/9/15 C Chauvenet > Hi Jorjeta, > > Thank you for the update, I think the doc brings additional valuable > content in this new revision. > > I have 2 comments about this new version of the draft : > > In 2.2.1 : It is mentioned that the traffic in AMI networks will be highl= y > asymmetric, and mostly narrowed to MP2P traffic. > I agree that most of the traffic in AMI will be sent by meters to the LBR= . > Though, as stated a little bit above in the doc, most of meters will be > polled, resulting in P2MP traffic (unicast or multicast packets). So, my > understanding is that if every meters is polled before sending its data, = the > traffic becomes symmetrical, because you have a 1:1 ratio between downwar= d > (LBR polling) and upward (Meter reporting) traffic. > Could you please help me to understand your statement ? > I think the traffic pattern may impact significantly the Storing Vs > Non-Storing design choice. > > > In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL= ) > may be suitable for energy constrained node much as water or gas meters. > I am not sure about the efficiency of Hop Count regarding energy > consumption. As we are working in lossy networks, there is a great chance > that the shortest path may not be the more reliable. So the shortest path > may induce many MAC level retries (thus inducing a faster energy drop of = the > node, and a higher congestion of the channel), and decrease significantly > the reliability. This could result in a path that cannot meet the > requirements of AMI (regarding reliability especially). I guess you > mentioned Hop count, because you get an minimum number of forwarder, thus > reducing the number of devices involved in the path, and minimizing the > impact of a packet in the global energy depletion of the global networks.= I > think this is very true in not-so-lossy networks, but I was wondering abo= ut > lossy networks. > In my opinion, LQL may be more adapted. Maybe your were thinking about > mixing Hop Count and LQL? > About energy, note that a specific metric has been designed in the > rpl-metric-draft. It may be worth to mention it. > > Best, > > C=E9dric. > > > Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit : > > Hello everyone,**** > ** ** > Just wanted to draw your attention to the new iteration of the RPL AMI > Applicability Internet-Draft (version 02). We=92ve made a few improvemen= ts to > the draft based on feedback from the group received so far. Thank you al= l > who sent us questions, comments and suggestions!**** > ** ** > Below is a brief summary of the changes:**** > ** ** > - Expanded discussion of Trickle parameter setting considerations**** > - Updates related to battery operated meters and routing infrastructure**= * > * > - Expanded discussion related to network topology characteristics**** > - Updates related to traffic characteristics**** > - Removed text discussing the benefits of multi-hop deployments vs. > single-hop deployments**** > - Clarification and readability improvements**** > ** ** > We look forward to your feedback as we work on improving the draft furthe= r! > **** > ** ** > Thanks, Jorjeta**** > ** ** > ** ** > **** > *Jorjeta Jetcheva, Ph.D.*** > Strategic Industry Standards and Architecture**** > Office of the CTO > Mobile: +1.408.688.1428 > Knowledge to Shape Your Future**** > > > **** > ** ** > ** ** > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --20cf30025c140b225604ad0a7f9f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello C=E9dric,
=A0
I will answer to your second comment.
=A0
I completely agree with you and this is excatly what is meant by "= ;Hop Count and Link Quality Level".
Moreover, the comment about an objective able to deal with more than o= ne metric in section 4.1.5 follows the same idea.
However, I agree that this is not clear enough in the draft and it wil= l be updated in the next release.
Something like a "combination of Hop Count and Link Quality Level= " should appear.
=A0
I also agree about the energy metric.
The next release will also be updated accordingly.
=A0
Cheers,

Nicolas.
2011/9/15 C Chauvenet <c.chauvenet@watteco.com>
Hi Jorjeta,=A0=20

Thank you for the update, I think the doc brings additional valuable c= ontent in this new revision.

I have 2 comments about this new version of the draft :=A0

In 2.2.1 : It is mentioned that the traffic in AMI networks will be hi= ghly asymmetric, and mostly narrowed to MP2P traffic.=A0
I agree that most of the traffic in AMI will be sent by meters to the = LBR. Though, as stated a little bit above in the doc, most of meters will b= e polled, resulting in P2MP traffic (unicast or multicast packets). So, my = understanding is that if every meters is polled before sending its data, th= e traffic becomes symmetrical, because you have a 1:1 ratio between downwar= d (LBR polling) and upward (Meter reporting) traffic.
Could you please help me to understand your statement ?
I think the traffic pattern may impact significantly the Storing Vs No= n-Storing design choice.


In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (= LQL) may be suitable for energy constrained node much as water or gas meter= s.
I am not sure about the efficiency of Hop Count regarding energy consu= mption. As we are working in lossy networks, there is a great chance that t= he shortest path may not be the more reliable. So the shortest path may ind= uce many MAC level retries (thus inducing a faster energy drop of the node,= and a higher congestion of the channel), and decrease significantly the re= liability. This could result in a path that cannot meet the requirements of= AMI (regarding reliability especially). I guess you mentioned Hop count, b= ecause you get an minimum number of forwarder, thus reducing the number of = devices involved in the path, and minimizing the impact of a packet in the = global energy depletion of the global networks. I think this is very true i= n not-so-lossy networks, but I was wondering about lossy networks.
In my opinion, LQL may be more adapted. Maybe your were thinking about= mixing Hop Count and LQL?
About energy, note that a specific metric has been designed in the rpl= -metric-draft. It may be worth to mention it.

Best,

C=E9dric.


Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit :

We look forward to your feedback as we work on improving the dra= ft further!
=A0
Thanks, Jorjeta
=A0
=A0
=
Jorjeta Jetcheva, Ph.D.
Strategic Industry Standards and Architecture=
Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future
<image002.jpg>=A0=A0=A0<image003.jpg>=A0=A0=A0<image004.jpg>=A0=A0=A0<= a style=3D"COLOR: blue; TEXT-DECORATION: underline" href=3D"http://www.yout= ube.com/itronsmartmedia" target=3D"_blank"><image005.jpg>
=A0
=A0
<ATT00001..txt><= /div>


__________________= _____________________________
Roll mailing list
Roll@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/roll


--20cf30025c140b225604ad0a7f9f-- From trakadasp@yahoo.gr Fri Sep 16 08:51:51 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1921F854E for ; Fri, 16 Sep 2011 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef1Kve5JqIOd for ; Fri, 16 Sep 2011 08:51:49 -0700 (PDT) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by ietfa.amsl.com (Postfix) with SMTP id ED57521F851F for ; Fri, 16 Sep 2011 08:51:48 -0700 (PDT) Received: from [77.238.189.54] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 16 Sep 2011 15:54:00 -0000 Received: from [212.82.108.112] by tm7.bullet.mail.ird.yahoo.com with NNFMP; 16 Sep 2011 15:54:00 -0000 Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 16 Sep 2011 15:54:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 847421.24957.bm@omp1021.mail.ird.yahoo.com Received: (qmail 6719 invoked by uid 60001); 16 Sep 2011 15:54:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1316188440; bh=TTK7gFIEG1LW8slofK1SKTZO5rBytWsYRv5msS6cJ1E=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=qDFQ7vpBw5XLHfmusvNmE4GdbiELEfUfZybtiyp3O66yMLMl57jduHJDW0iSv4PcMpyQAkWIRPz66At1+wpt28TaZwRYh3LFnf3ICRKZZ1yQDF7PoQdEx75ULoicnY6JtORUMJMxmrOpdH59MLK+HeLH77sDxM5GisDWFI9o9ss= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=G7eaTX4klj3aIbg9OfV7sXOdIXOr4c2kFIRqGCdCDY4HJBJWa1EvFMMsslXYmlWIsxD4N0sM7Rd7cHMsA4giBpUulWxQXErrMCxq4v2o1UiAm0uXjj0xfm/C7B7XU1pdLdhAGiQ4/c9UrNwG3wTstPj52KgupsywVjGaVrQkcrA=; X-YMail-OSG: nr4wag4VM1kNwemEKGNyY1q2uHrfMArqSUnEODg9OUaw7.D DZGaKCN73QllzyVFpiUr5w9cb.yHG07PGDZRnUCzipth965H97p5CoO9NRMO GCOMrnpeqj9JPEzQ3ROpun.d1hbjjwsyao7SMjiUS_iiTlRlyaCVSKyhbgHq dOqc4KwRw27riPWqrHVI26oYxDa93D4D8UwT4GlU5p.29G2Al1uxYjbwl6pl blj..3FareUhHu51k1_gX5n1ED8n9PofS.mznoSQaRQM9Vvi5mxzybJWBi_f ZHbLiq46WGhKw6TscCTuWVKjlQGItnAuD73SPqY5rhjaN2ny1TjxJSHR4dSP q8jNkuDV9SHTaaigqqJyPHzwM41bk0PMDP26vN4KRYpP56.KLozWNuCVE02t 2iGUsycAByFEQT5zigw9hzBj0q1caZn_QpsNKHfjUtXSL1A01DO8gtN.YKYu bodA25Nq59lrQkEnoqEbS5J64iZORBAvnFKGrxnVqn1otUIcJZnbdQcu3GGD RQ9NpjCkCTvzR6OhItTA61g1P4PABQ61gcIRtaizKwZW7myfpO3v61m4WbKU ma8WK5vOOzFNWRQW0R6sdlXEMaA2S_7D.E7BSTHBku7aanwT0BNguLdQQnhc hJMrsYcO0at7WXO771OX_z2Ml1Uv9FBZm7hd2pVUj9ZvypvNC4ATp5YJRvOM 7iOoXAGTe3.aHJRhf1WtY6kw- Received: from [87.248.120.202] by web29607.mail.ird.yahoo.com via HTTP; Fri, 16 Sep 2011 16:54:00 BST X-Mailer: YahooMailWebService/0.8.114.317681 Message-ID: <1316188440.5357.yext-apple-iphone@web29607.mail.ird.yahoo.com> Date: Fri, 16 Sep 2011 16:54:00 +0100 (BST) From: Panos Trakadas To: Nicolas DEJEAN MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1212461981-1030300891-1316188440=:5357" Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas 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 Sep 2011 15:51:51 -0000 ---1212461981-1030300891-1316188440=:5357 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Nicolas,=0AFollowing your discussion with Cedric regarding routing me= trics composition for ami network deployment scenarios, i would like to rem= ind you that in draft-zahariadis-roll-metrics-composition-01 we present a d= esign framework for metric composition, including both theoretical and prac= tical aspects, followed by several examples.=0AI think that you will find i= nteresting information in this draft.=0AFurthermore, we have already starte= d examining composition rules for several metrics used in RPL routing proto= col (including HC, ETX, LQL, remaining energy) validated in an RPL simulati= on platform. =0AThe simulation platform provides multiple instances and OFs= support.=0AFinishing debugging, we plan to distribute a beta version of th= e simulator code.=0A=0A=0ABest Regards,=0APanos=0A=0A=0AOn 16 Sep 2011, at = 11:08, Nicolas DEJEAN wrote:=0A=0AHell= o C=C3=A9dric,=0A =0AI will answer to your second comment.=0A =0AI complete= ly agree with you and this is excatly what is meant by "Hop Count and Link = Quality Level".=0AMoreover, the comment about an objective able to deal wit= h more than one metric in section 4.1.5 follows the same idea.=0AHowever, I= agree that this is not clear enough in the draft and it will be updated in= the next release.=0ASomething like a "combination of Hop Count and Link Qu= ality Level" should appear.=0A =0AI also agree about the energy metric.=0AT= he next release will also be updated accordingly.=0A =0ACheers,=0A=0ANicola= s.=0A2011/9/15 C Chauvenet =0AHi Jorjeta, =0A=0ATh= ank you for the update, I think the doc brings additional valuable content = in this new revision.=0A=0AI have 2 comments about this new version of the = draft : =0A=0AIn 2.2.1 : It is mentioned that the traffic in AMI networks w= ill be highly asymmetric, and mostly narrowed to MP2P traffic. =0AI agree t= hat most of the traffic in AMI will be sent by meters to the LBR. Though, a= s stated a little bit above in the doc, most of meters will be polled, resu= lting in P2MP traffic (unicast or multicast packets). So, my understanding = is that if every meters is polled before sending its data, the traffic beco= mes symmetrical, because you have a 1:1 ratio between downward (LBR polling= ) and upward (Meter reporting) traffic.=0ACould you please help me to under= stand your statement ?=0AI think the traffic pattern may impact significant= ly the Storing Vs Non-Storing design choice.=0A=0A=0AIn 4.1.4 : It is menti= oned that Hop Count (HC) or Link Quality Level (LQL) may be suitable for en= ergy constrained node much as water or gas meters.=0AI am not sure about th= e efficiency of Hop Count regarding energy consumption. As we are working i= n lossy networks, there is a great chance that the shortest path may not be= the more reliable. So the shortest path may induce many MAC level retries = (thus inducing a faster energy drop of the node, and a higher congestion of= the channel), and decrease significantly the reliability. This could resul= t in a path that cannot meet the requirements of AMI (regarding reliability= especially). I guess you mentioned Hop count, because you get an minimum n= umber of forwarder, thus reducing the number of devices involved in the pat= h, and minimizing the impact of a packet in the global energy depletion of = the global networks. I think this is very true in not-so-lossy networks, bu= t I was wondering about lossy networks.=0AIn my opinion, LQL may be more ad= apted. Maybe your were thinking about mixing Hop Count and LQL?=0AAbout ene= rgy, note that a specific metric has been designed in the rpl-metric-draft.= It may be worth to mention it.=0A=0ABest,=0A=0AC=C3=A9dric.=0A=0A=0ALe 14 = sept. 2011 =C3=A0 20:32, Jetcheva, Jorjeta a =C3=A9crit :=0A=0AHello everyo= ne,=0A =0AJust wanted to draw your attention to the new iteration of the RP= L AMI Applicability Internet-Draft (version 02). We=E2=80=99ve made a few = improvements to the draft based on feedback from the group received so far.= Thank you all who sent us questions, comments and suggestions!=0A =0ABelo= w is a brief summary of the changes:=0A =0A- Expanded discussion of Trickle= parameter setting considerations=0A- Updates related to battery operated m= eters and routing infrastructure=0A- Expanded discussion related to network= topology characteristics=0A- Updates related to traffic characteristics=0A= - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments=0A- Clarification and readability improvements=0A =0AWe loo= k forward to your feedback as we work on improving the draft further!=0A = =0AThanks, Jorjeta=0A =0A =0A=0AJorjeta Jetcheva, Ph.D.=0AStr= ategic Industry Standards and Architecture=0AOffice of the CTO=0AMobile: +1= .408.688.1428=0AKnowledge to Shape Your Future=0A =0A =0A =0A=0A=0A=0A_= ______________________________________________=0ARoll mailing list=0ARoll@i= etf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A=0A=0A______________= _________________________________=0ARoll mailing list=0ARoll@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/roll=0A=0A ---1212461981-1030300891-1316188440=:5357 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Nicolas,
Followin= g your discussion with Cedric regarding routing metrics composition for ami= network deployment scenarios, i would like to remind you that in draft-z= ahariadis-roll-metrics-composition-01 we present a design framework for met= ric composition, including both theoretical and practical aspects, followed= by several examples.
I think that you will find interest= ing information in this draft.
Furthermore, we have alread= y started examining composition rules for several metrics used in RPL routin= g protocol (including HC, ETX, LQL, remaining energy) validated in an RPL s= imulation platform. 
The simulation platform provides multip= le instances and OFs support.
Finishing debugging, we plan to dis= tribute a beta version of the simulator code.


=
Best Regards,
Panos


On 16 Sep 20= 11, at 11:08, Nicolas DEJEAN <nicolas.d= ejean.ietf@googlemail.com> wrote:

Hello C=C3=A9dric,
=0A
 
= =0A
I will answer to your second comment.
=0A
 
=0A<= div>I completely agree with you and this is excatly what is meant by "Hop C= ount and Link Quality Level".
=0A
Moreover, the comment about an o= bjective able to deal with more than one metric in section 4.1.5 follows th= e same idea.
=0A
However, I agree that this is not clear enough in= the draft and it will be updated in the next release.
=0A
Somethi= ng like a "combination of Hop Count and Link Quality Level" should appear.<= /div>=0A
 
=0A
I also agree about the energy metric.=0A
The next release will also be updated accordingly.
=0A
&n= bsp;
=0A
Cheers,
=0A

Nicolas.
=0A
2011/9/15 C Chauvenet <c.chauvenet@watteco.com= >
=0A
=0A
Hi Jorjeta,  =0A

=0A
Than= k you for the update, I think the doc brings additional valuable content in= this new revision.
=0A

=0A
I have 2 comments about th= is new version of the draft : 
=0A

=0A
In 2.2.1= : It is mentioned that the traffic in AMI networks will be highly asymmetr= ic, and mostly narrowed to MP2P traffic. 
=0A
I agree that mo= st of the traffic in AMI will be sent by meters to the LBR. Though, as stat= ed a little bit above in the doc, most of meters will be polled, resulting = in P2MP traffic (unicast or multicast packets). So, my understanding is tha= t if every meters is polled before sending its data, the traffic becomes sy= mmetrical, because you have a 1:1 ratio between downward (LBR polling) and = upward (Meter reporting) traffic.
=0A=0A
Could you please help me = to understand your statement ?
=0A
I think the traffic pattern may= impact significantly the Storing Vs Non-Storing design choice.
=0A
=0A

=0A
In 4.1.4 : It is mentioned that Hop C= ount (HC) or Link Quality Level (LQL) may be suitable for energy constraine= d node much as water or gas meters.
=0A
I am not sure about the ef= ficiency of Hop Count regarding energy consumption. As we are working in lo= ssy networks, there is a great chance that the shortest path may not be the= more reliable. So the shortest path may induce many MAC level retries (thu= s inducing a faster energy drop of the node, and a higher congestion of the= channel), and decrease significantly the reliability. This could result in= a path that cannot meet the requirements of AMI (regarding reliability esp= ecially). I guess you mentioned Hop count, because you get an minimum numbe= r of forwarder, thus reducing the number of devices involved in the path, a= nd minimizing the impact of a packet in the global energy depletion of the = global networks. I think this is very true in not-so-lossy networks, but I = was wondering about lossy networks.
=0A=0A
In my opinion, LQL may = be more adapted. Maybe your were thinking about mixing Hop Count and LQL?=0A
About energy, note that a specific metric has been designed in = the rpl-metric-draft. It may be worth to mention it.
=0A

=0A
Best,
=0A

=0A
C=C3=A9dric.
=0A
=0A

=0A
=0A
=0A
Le 14 sept. 2011 =C3=A0 20= :32, Jetcheva, Jorjeta a =C3=A9crit :

=0A
=0A
= =0A
=0A
=0A
Hello everyone,
=0A<= u> 
=0A
Just wanted to draw your attention to the new= iteration of the RPL AMI Applicability Internet-Draft (version 02).  = We=E2=80=99ve made a few improvements to the draft based on feedback from t= he group received so far.  Thank you all who sent us questions, commen= ts and suggestions!
=0A=0A
 
= =0A
Below is a brief summary of the changes:
=0A
 
=0A
- Expanded discussion of Trickle parameter settin= g considerations
=0A
- Updates related to battery opera= ted meters and routing infrastructure
=0A
- Expanded di= scussion related to network topology characteristics
=0A=
- Re= moved text discussing the benefits of multi-hop deployments vs. single-hop = deployments
=0A
- Clarification and readability improve= ments
=0A
 
=0A
We lo= ok forward to your feedback as we work on improving the draft further!
=0A
 
=0A
Thanks= , Jorjeta
=0A
 
=0A 
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A
=0A=0A
=0A
Jorjeta Jetcheva, Ph.D.<= b>=
=0A
=0A
Strategic Industry Standards and Architectu= re
=0A=0A
Office of the CTO
Mob= ile: +1.408.688.1428
=0AKnowledge to Shape Your Future
=0A=
<image002.jpg>   <ima= ge003.jpg>   <image004.jpg>   <image005.jpg><= span style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman', serif">
=0A
=0A
&nb= sp;
=0A
 
<ATT= 00001..txt>

=
_______________________________________________
=0ARoll mailing list=
<= a href=3D"mailto:Roll@ietf.org">Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=0A
_______________________________________________
Ro= ll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
---1212461981-1030300891-1316188440=:5357-- From Jorjeta.Jetcheva@itron.com Fri Sep 16 09:08:27 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1521F8CA4 for ; Fri, 16 Sep 2011 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tceQMcRbDCed for ; Fri, 16 Sep 2011 09:08:24 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id C598D21F8CA1 for ; Fri, 16 Sep 2011 09:08:23 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Fri, 16 Sep 2011 09:10:38 -0700 From: "Jetcheva, Jorjeta" To: C Chauvenet Date: Fri, 16 Sep 2011 09:10:37 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Thread-Index: AcxzhdyXpUsFdX3EREujihRyqGyWQQBA8snw Message-ID: <0368F388C03BB34BBBFA73209849D47A4D2A5DA9@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 16:08:27 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello C=E9dric, Thank you for your comments. Since Nicolas already addressed your second q= uestion, let me try to address the first one. Most of the traffic tends to= be towards the LBR in terms of bytes (reports are typically much bigger th= an queries), but also in terms of number of packets, e.g., some reports hav= e to be split into multiple packets due to packet size limitations, periodi= c reports can be sent without requiring each of them to be triggered by a q= uery, and there are unsolicited events like alarms and outage notifications= generated by the meters as well. Does this answer your question? Clearly there is room for clarification in the text, so we will update it a= ccordingly. Thanks again! Jorjeta [cid:image001.jpg@01CC744F.CBF10330] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC744F.CBF10330] [cid:im= age003.jpg@01CC744F.CBF10330] [cid:im= age004.jpg@01CC744F.CBF10330] [cid:image005.jpg@01CC744F.CBF10330] From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Thursday, September 15, 2011 2:00 AM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Hi Jorjeta, Thank you for the update, I think the doc brings additional valuable conten= t in this new revision. I have 2 comments about this new version of the draft : In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly = asymmetric, and mostly narrowed to MP2P traffic. I agree that most of the traffic in AMI will be sent by meters to the LBR. = Though, as stated a little bit above in the doc, most of meters will be pol= led, resulting in P2MP traffic (unicast or multicast packets). So, my under= standing is that if every meters is polled before sending its data, the tra= ffic becomes symmetrical, because you have a 1:1 ratio between downward (LB= R polling) and upward (Meter reporting) traffic. Could you please help me to understand your statement ? I think the traffic pattern may impact significantly the Storing Vs Non-Sto= ring design choice. In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) = may be suitable for energy constrained node much as water or gas meters. I am not sure about the efficiency of Hop Count regarding energy consumptio= n. As we are working in lossy networks, there is a great chance that the sh= ortest path may not be the more reliable. So the shortest path may induce m= any MAC level retries (thus inducing a faster energy drop of the node, and = a higher congestion of the channel), and decrease significantly the reliabi= lity. This could result in a path that cannot meet the requirements of AMI = (regarding reliability especially). I guess you mentioned Hop count, becaus= e you get an minimum number of forwarder, thus reducing the number of devic= es involved in the path, and minimizing the impact of a packet in the globa= l energy depletion of the global networks. I think this is very true in not= -so-lossy networks, but I was wondering about lossy networks. In my opinion, LQL may be more adapted. Maybe your were thinking about mixi= ng Hop Count and LQL? About energy, note that a specific metric has been designed in the rpl-metr= ic-draft. It may be worth to mention it. Best, C=E9dric. Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 02). We've made a few improvements to th= e draft based on feedback from the group received so far. Thank you all wh= o sent us questions, comments and suggestions! Below is a brief summary of the changes: - Expanded discussion of Trickle parameter setting considerations - Updates related to battery operated meters and routing infrastructure - Expanded discussion related to network topology characteristics - Updates related to traffic characteristics - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments - Clarification and readability improvements We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future --_000_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hel= lo C=E9dric,

 

Tha= nk you for your comments. =A0Since Nicolas already addressed your second question,= let me try to address the first one.=A0 Most of the traffic tends to be towards= the LBR in terms of bytes (reports are typically much bigger than queries), but also in terms of number of packets, e.g., some reports have to be split int= o multiple packets due to packet size limitations, periodic reports can be se= nt without requiring each of them to be triggered by a query, and there are unsolicited events like alarms and outage notifications generated by the me= ters as well. =A0=A0Does this answer your question?

 

Cle= arly there is room for clarification in the text, so we will update it according= ly.=A0 Thanks again!

 

Jor= jeta

 

 

3D"http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg"

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jp=   3D"http://marketing.itron.com/campaign/social_media_icon_facebook29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_youtube29.jp=

 

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Thursday, September 15, 2011 2:00 AM
To: Jetcheva, Jorjeta
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02= .txt

 

Hi Jorjeta, 

 

Thank you for the update, I think the doc brings addit= ional valuable content in this new revision.

 

I have 2 comments about this new version of the draft : 

 

In 2.2.1 : It is mentioned that the traffic in AMI net= works will be highly asymmetric, and mostly narrowed to MP2P traffic. <= /o:p>

I agree that most of the traffic in AMI will be sent b= y meters to the LBR. Though, as stated a little bit above in the doc, most of meters will be polled, resulting in P2MP traffic (unicast or multicast packets). So, my understanding is that if every meters is polled before sen= ding its data, the traffic becomes symmetrical, because you have a 1:1 ratio bet= ween downward (LBR polling) and upward (Meter reporting) traffic.

Could you please help me to understand your statement = ?

I think the traffic pattern may impact significantly t= he Storing Vs Non-Storing design choice.

 

 

In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) may be suitable for energy constrained node much as wat= er or gas meters.

I am not sure about the efficiency of Hop Count regard= ing energy consumption. As we are working in lossy networks, there is a great chance that the shortest path may not be the more reliable. So the shortest path may induce many MAC level retries (thus inducing a faster energy drop = of the node, and a higher congestion of the channel), and decrease significant= ly the reliability. This could result in a path that cannot meet the requireme= nts of AMI (regarding reliability especially). I guess you mentioned Hop count, because you get an minimum number of forwarder, thus reducing the number of devices involved in the path, and minimizing the impact of a packet in the global energy depletion of the global networks. I think this is very true i= n not-so-lossy networks, but I was wondering about lossy networks.=

In my opinion, LQL may be more adapted. Maybe your wer= e thinking about mixing Hop Count and LQL?

About energy, note that a specific metric has been des= igned in the rpl-metric-draft. It may be worth to mention it.

 

Best,

 

C=E9dric.

 

 

Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9cri= t :



= Hello everyone,

=  

= Just wanted to draw your attention to the new iteration of the RPL AMI Applicabi= lity Internet-Draft (version 02).  We’ve made a few improvements to t= he draft based on feedback from the group received so far.  Thank you all= who sent us questions, comments and suggestions!

=  

= Below is a brief summary of the changes:

=  

= - Expanded discussion of Trickle parameter setting considerations<= /span>

= - Updates related to battery operated meters and routing infrastructure<= /o:p>

= - Expanded discussion related to network topology characteristics<= /span>

= - Updates related to traffic characteristics

= - Removed text discussing the benefits of multi-hop deployments vs. single-ho= p deployments

= - Clarification and readability improvements

=  

We look forward to your feedback as we work on improving the draft further!

 

Thanks, Jorjeta

 

 

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture=

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

 

 

<ATT00001..txt>

 

--_000_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Fri, 16 Sep 2011 09:10:35 GMT"; modification-date="Fri, 16 Sep 2011 09:10:35 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Fri, 16 Sep 2011 09:10:36 GMT"; modification-date="Fri, 16 Sep 2011 09:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Fri, 16 Sep 2011 09:10:36 GMT"; modification-date="Fri, 16 Sep 2011 09:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Fri, 16 Sep 2011 09:10:36 GMT"; modification-date="Fri, 16 Sep 2011 09:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Fri, 16 Sep 2011 09:10:36 GMT"; modification-date="Fri, 16 Sep 2011 09:10:36 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4D2A5DA9ITREXMBXVS2itro_-- From c.chauvenet@watteco.com Fri Sep 16 09:37:41 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACFB21F8C31 for ; Fri, 16 Sep 2011 09:37:41 -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=[AWL=-1.400, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBurTSaWgrws for ; Fri, 16 Sep 2011 09:37:38 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id E31EA21F8C28 for ; Fri, 16 Sep 2011 09:37:37 -0700 (PDT) Received: from mail168-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Fri, 16 Sep 2011 16:39:52 +0000 Received: from mail168-ch1 (localhost.localdomain [127.0.0.1]) by mail168-ch1-R.bigfish.com (Postfix) with ESMTP id 89B30F3840B; Fri, 16 Sep 2011 16:39:52 +0000 (UTC) X-SpamScore: -45 X-BigFish: VPS-45(zz9371Kc89bh1431Jc85dh14e3M14ffO111aL4015Lzz1202hzz1033ILc704dh8275bh8275dhz2dh54h49h2a8h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB006.red002.local; RD:none; EFVD:NLI Received: from mail168-ch1 (localhost.localdomain [127.0.0.1]) by mail168-ch1 (MessageSwitch) id 1316191162759217_22600; Fri, 16 Sep 2011 16:39:22 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail168-ch1.bigfish.com (Postfix) with ESMTP id 4673013E0266; Fri, 16 Sep 2011 16:39:07 +0000 (UTC) Received: from IE2RD2HUB006.red002.local (213.199.187.153) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 16 Sep 2011 16:39:01 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB006.red002.local ([10.33.16.154]) with mapi; Fri, 16 Sep 2011 09:39:00 -0700 From: C Chauvenet To: "Jetcheva, Jorjeta" Date: Fri, 16 Sep 2011 09:39:01 -0700 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Thread-Index: AcxzhdyXpUsFdX3EREujihRyqGyWQQBA8snwAAFM9eA= Message-ID: References: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4D2A5DA9@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4D2A5DA9@ITR-EXMBXVS-2.itron.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/related; boundary="_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 16:37:41 -0000 --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_" --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thank your for the clarification. It fully adress my question. C=E9dric. De : Jetcheva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com] Envoy=E9 : vendredi 16 septembre 2011 18:11 =C0 : C Chauvenet Cc : roll@ietf.org Objet : RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Hello C=E9dric, Thank you for your comments. Since Nicolas already addressed your second q= uestion, let me try to address the first one. Most of the traffic tends to= be towards the LBR in terms of bytes (reports are typically much bigger th= an queries), but also in terms of number of packets, e.g., some reports hav= e to be split into multiple packets due to packet size limitations, periodi= c reports can be sent without requiring each of them to be triggered by a q= uery, and there are unsolicited events like alarms and outage notifications= generated by the meters as well. Does this answer your question? Clearly there is room for clarification in the text, so we will update it a= ccordingly. Thanks again! Jorjeta [cid:image001.jpg@01CC749F.E6861230] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC749F.E6861230] [cid:im= age003.jpg@01CC749F.E6861230] [cid:im= age004.jpg@01CC749F.E6861230] [cid:image005.jpg@01CC749F.E6861230] From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Thursday, September 15, 2011 2:00 AM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Hi Jorjeta, Thank you for the update, I think the doc brings additional valuable conten= t in this new revision. I have 2 comments about this new version of the draft : In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly = asymmetric, and mostly narrowed to MP2P traffic. I agree that most of the traffic in AMI will be sent by meters to the LBR. = Though, as stated a little bit above in the doc, most of meters will be pol= led, resulting in P2MP traffic (unicast or multicast packets). So, my under= standing is that if every meters is polled before sending its data, the tra= ffic becomes symmetrical, because you have a 1:1 ratio between downward (LB= R polling) and upward (Meter reporting) traffic. Could you please help me to understand your statement ? I think the traffic pattern may impact significantly the Storing Vs Non-Sto= ring design choice. In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) = may be suitable for energy constrained node much as water or gas meters. I am not sure about the efficiency of Hop Count regarding energy consumptio= n. As we are working in lossy networks, there is a great chance that the sh= ortest path may not be the more reliable. So the shortest path may induce m= any MAC level retries (thus inducing a faster energy drop of the node, and = a higher congestion of the channel), and decrease significantly the reliabi= lity. This could result in a path that cannot meet the requirements of AMI = (regarding reliability especially). I guess you mentioned Hop count, becaus= e you get an minimum number of forwarder, thus reducing the number of devic= es involved in the path, and minimizing the impact of a packet in the globa= l energy depletion of the global networks. I think this is very true in not= -so-lossy networks, but I was wondering about lossy networks. In my opinion, LQL may be more adapted. Maybe your were thinking about mixi= ng Hop Count and LQL? About energy, note that a specific metric has been designed in the rpl-metr= ic-draft. It may be worth to mention it. Best, C=E9dric. Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 02). We've made a few improvements to th= e draft based on feedback from the group received so far. Thank you all wh= o sent us questions, comments and suggestions! Below is a brief summary of the changes: - Expanded discussion of Trickle parameter setting considerations - Updates related to battery operated meters and routing infrastructure - Expanded discussion related to network topology characteristics - Updates related to traffic characteristics - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments - Clarification and readability improvements We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thank your for the clarification. =

It fully adress my question.

 

C=E9dric.

=  

De :<= /b> Jetc= heva, Jorjeta [mailto:Jorjeta.Jetcheva@itron.com]
Envoy=E9 : vendredi 16 septembre 2011 18:11
=C0 : C Chauvenet
C= c : roll@ietf.org
Objet : RE: [Roll] I-D Action: dr= aft-ietf-roll-applicability-ami-02.txt

 

Hello C=E9dric,=

 

Thank you for yo= ur comments.  Since Nicolas already addressed your second question, le= t me try to address the first one.  Most of the traffic tends to be to= wards the LBR in terms of bytes (reports are typically much bigger than que= ries), but also in terms of number of packets, e.g., some reports have to b= e split into multiple packets due to packet size limitations, periodic repo= rts can be sent without requiring each of them to be triggered by a query, = and there are unsolicited events like alarms and outage notifications gener= ated by the meters as well.   Does this answer your question?

 

Clearly t= here is room for clarification in the text, so we will update it accordingl= y.  Thanks again!

 

Jorjeta

 

 

<= tr>

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowl= edge to Shape Your Future

=3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg"    =   =3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg"<= /span>   3D"http://marketing.itron.com/campaign==

 

=  

From= : C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent:= Thursday, September 15, 2011 2:00 AM
To: Jetcheva, JorjetaCc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-= ietf-roll-applicability-ami-02.txt

 

Hi Jorjeta, 

 

<= p class=3DMsoNormal>Thank you for the update, I think th= e doc brings additional valuable content in this new revision.

 

I have 2 comments= about this new version of the draft : 

 

In 2.2.1 : It is mentioned th= at the traffic in AMI networks will be highly asymmetric, and mostly narrow= ed to MP2P traffic. 

I agree that most of the traffic in AMI will be sent= by meters to the LBR. Though, as stated a little bit above in the doc, mos= t of meters will be polled, resulting in P2MP traffic (unicast or multicast= packets). So, my understanding is that if every meters is polled before se= nding its data, the traffic becomes symmetrical, because you have a 1:1 rat= io between downward (LBR polling) and upward (Meter reporting) traffic.

Could = you please help me to understand your statement ?

I think the traffic pattern = may impact significantly the Storing Vs Non-Storing design choice.

 =

&n= bsp;

In = 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) may= be suitable for energy constrained node much as water or gas meters.<= /o:p>

I am not= sure about the efficiency of Hop Count regarding energy consumption. As we= are working in lossy networks, there is a great chance that the shortest p= ath may not be the more reliable. So the shortest path may induce many MAC = level retries (thus inducing a faster energy drop of the node, and a higher= congestion of the channel), and decrease significantly the reliability. Th= is could result in a path that cannot meet the requirements of AMI (regardi= ng reliability especially). I guess you mentioned Hop count, because you ge= t an minimum number of forwarder, thus reducing the number of devices invol= ved in the path, and minimizing the impact of a packet in the global energy= depletion of the global networks. I think this is very true in not-so-loss= y networks, but I was wondering about lossy networks.

=

In my opinion, LQL may b= e more adapted. Maybe your were thinking about mixing Hop Count and LQL?

About= energy, note that a specific metric has been designed in the rpl-metric-dr= aft. It may be worth to mention it.

 

Best,

=

 

<= div>

C=E9dric.

=

 =

 

Le 14 = sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit :

=  

Hello everyone,

 

Just wanted to draw your attention to the new iteration of th= e RPL AMI Applicability Internet-Draft (version 02).  We’ve made= a few improvements to the draft based on feedback from the group received = so far.  Thank you all who sent us questions, comments and suggestions= !

 

=

Below is a brief summary of the changes:=

 

<= p class=3DMsoNormal>- Expanded discussion of Trickle parameter setting consideratio= ns

- Updates related to batter= y operated meters and routing infrastructure

- Expanded discussion related to network topology characteri= stics

- Updates related to tra= ffic characteristics

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:Consolas'>- Removed= text discussing the benefits of multi-hop deployments vs. single-hop deplo= yments

- Clarification and rea= dability improvements

=  

We look forward t= o your feedback as we work on improving the draft further!

 

Thanks, Jorjeta

 

 

<= td valign=3Dbottom style=3D'padding:0cm 0cm 0cm 0cm'>

Strategic Industry Standards and Architecture

<= /div>

Office of the CTO
Mobile: +1.408.688.1= 428
Knowledge to Shape Your Future

=
=

<= b>Jorjeta Jetcheva, Ph.D.

&nb= sp;

 <= /o:p>

<ATT00001..txt>

 

= --_000_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_-- --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Fri, 16 Sep 2011 09:38:58 GMT"; modification-date="Fri, 16 Sep 2011 09:38:58 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Fri, 16 Sep 2011 09:38:58 GMT"; modification-date="Fri, 16 Sep 2011 09:38:58 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Fri, 16 Sep 2011 09:38:58 GMT"; modification-date="Fri, 16 Sep 2011 09:38:58 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Fri, 16 Sep 2011 09:38:59 GMT"; modification-date="Fri, 16 Sep 2011 09:38:59 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Fri, 16 Sep 2011 09:38:59 GMT"; modification-date="Fri, 16 Sep 2011 09:38:59 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_BDF612E3788C4C4791A1A49AC3CB7C971CE710126DIE2RD2XVS211r_-- From Ruben.Salazar@landisgyr.com Fri Sep 16 14:13:53 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971121F8CB1 for ; Fri, 16 Sep 2011 14:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vnA2swu64Xe for ; Fri, 16 Sep 2011 14:13:49 -0700 (PDT) Received: from AM1EHSOBE005.bigfish.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A521F8C7E for ; Fri, 16 Sep 2011 14:13:48 -0700 (PDT) Received: from mail40-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.22; Fri, 16 Sep 2011 21:16:03 +0000 Received: from mail40-am1 (localhost.localdomain [127.0.0.1]) by mail40-am1-R.bigfish.com (Postfix) with ESMTP id 5EEA1E68467; Fri, 16 Sep 2011 21:16:03 +0000 (UTC) X-SpamScore: -45 X-BigFish: PS-45(zz9371Kc89bh1431Jc85dh14e3M14ffO111aL4015Lzz1202hzz1033ILc704dh8275bh8275dhz2dh54h49h668h839h8aah61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:80.12.107.22; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:av-smtp1.lng.gmessaging.net; RD:av-smtp1.lng.gmessaging.net; EFVD:NLI Received: from mail40-am1 (localhost.localdomain [127.0.0.1]) by mail40-am1 (MessageSwitch) id 1316207730119667_1306; Fri, 16 Sep 2011 21:15:30 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.251]) by mail40-am1.bigfish.com (Postfix) with ESMTP id 1B93F10081C2; Fri, 16 Sep 2011 21:14:47 +0000 (UTC) Received: from av-smtp1.lng.gmessaging.net (80.12.107.22) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server id 14.1.225.22; Fri, 16 Sep 2011 21:14:46 +0000 Received: from av-smtp1.lng.gmessaging.net (localhost.localdomain [127.0.0.1]) by localhost.lng.gmessaging.net (Postfix) with SMTP id 3AE0883C087; Fri, 16 Sep 2011 23:14:35 +0200 (CEST) Received: from secure1.landisgyr.com (unknown [10.33.192.35]) by av-smtp1.lng.gmessaging.net (Postfix) with ESMTP id 0D2B483C06D; Fri, 16 Sep 2011 23:14:35 +0200 (CEST) Received: from FRPARSV10.mx.bm.net ([10.33.192.40]) by frparsv03.mx.bm.net ([10.33.192.35]) with mapi; Fri, 16 Sep 2011 23:14:45 +0200 From: "Salazar, Ruben" To: "Jetcheva, Jorjeta" , C Chauvenet Date: Fri, 16 Sep 2011 23:14:43 +0200 Thread-Topic: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Thread-Index: AcxzhdyXpUsFdX3EREujihRyqGyWQQBA8snwAArC1VA= Message-ID: <4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDF@FRPARSV10.mx.bm.net> References: <0368F388C03BB34BBBFA73209849D47A4D1DBA49@ITR-EXMBXVS-2.itron.com> <0368F388C03BB34BBBFA73209849D47A4D2A5DA9@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4D2A5DA9@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: a70a6184-0c20-4798-8bda-10a8eb498786 Content-Type: multipart/related; boundary="_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 21:13:53 -0000 --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: multipart/alternative; boundary="_000_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_" --_000_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would like to add to Jorjetta's note: The section that Cedric identifies = 2.2.1 refers only to the Smart Meter Data application of the AMI network: f= or that application somewhere around 90% of the traffic generated comes fro= m scheduled activities in each meter, reporting of metering data and status= data, that can be originated in the meter without need for polling, thus c= reating the asymmetric aspect of this application. There will be symmetric = activities, polling, but they represent a reduced percentage of the traffic= . There may be, though, implementations where the reporting of metering data = and status data is also handled using polling schemes. Regards Ruben Salazar Director Research and Technology Landis+Gyr Energy Management Solutions Office: +1 678 258 3165 Ruben.Salazar@landisgyr.com www.landisgyr.com manage energy better From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jet= cheva, Jorjeta Sent: Friday, September 16, 2011 12:11 PM To: C Chauvenet Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Hello C=E9dric, Thank you for your comments. Since Nicolas already addressed your second q= uestion, let me try to address the first one. Most of the traffic tends to= be towards the LBR in terms of bytes (reports are typically much bigger th= an queries), but also in terms of number of packets, e.g., some reports hav= e to be split into multiple packets due to packet size limitations, periodi= c reports can be sent without requiring each of them to be triggered by a q= uery, and there are unsolicited events like alarms and outage notifications= generated by the meters as well. Does this answer your question? Clearly there is room for clarification in the text, so we will update it a= ccordingly. Thanks again! Jorjeta [cid:image001.jpg@01CC7494.201CC540] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC7494.201CC540] [cid:im= age003.jpg@01CC7494.201CC540] [cid:im= age004.jpg@01CC7494.201CC540] [cid:image005.jpg@01CC7494.201CC540] From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Thursday, September 15, 2011 2:00 AM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt Hi Jorjeta, Thank you for the update, I think the doc brings additional valuable conten= t in this new revision. I have 2 comments about this new version of the draft : In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly = asymmetric, and mostly narrowed to MP2P traffic. I agree that most of the traffic in AMI will be sent by meters to the LBR. = Though, as stated a little bit above in the doc, most of meters will be pol= led, resulting in P2MP traffic (unicast or multicast packets). So, my under= standing is that if every meters is polled before sending its data, the tra= ffic becomes symmetrical, because you have a 1:1 ratio between downward (LB= R polling) and upward (Meter reporting) traffic. Could you please help me to understand your statement ? I think the traffic pattern may impact significantly the Storing Vs Non-Sto= ring design choice. In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) = may be suitable for energy constrained node much as water or gas meters. I am not sure about the efficiency of Hop Count regarding energy consumptio= n. As we are working in lossy networks, there is a great chance that the sh= ortest path may not be the more reliable. So the shortest path may induce m= any MAC level retries (thus inducing a faster energy drop of the node, and = a higher congestion of the channel), and decrease significantly the reliabi= lity. This could result in a path that cannot meet the requirements of AMI = (regarding reliability especially). I guess you mentioned Hop count, becaus= e you get an minimum number of forwarder, thus reducing the number of devic= es involved in the path, and minimizing the impact of a packet in the globa= l energy depletion of the global networks. I think this is very true in not= -so-lossy networks, but I was wondering about lossy networks. In my opinion, LQL may be more adapted. Maybe your were thinking about mixi= ng Hop Count and LQL? About energy, note that a specific metric has been designed in the rpl-metr= ic-draft. It may be worth to mention it. Best, C=E9dric. Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 02). We've made a few improvements to th= e draft based on feedback from the group received so far. Thank you all wh= o sent us questions, comments and suggestions! Below is a brief summary of the changes: - Expanded discussion of Trickle parameter setting considerations - Updates related to battery operated meters and routing infrastructure - Expanded discussion related to network topology characteristics - Updates related to traffic characteristics - Removed text discussing the benefits of multi-hop deployments vs. single-= hop deployments - Clarification and readability improvements We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future --_000_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

I would like to add to Jorjetta’s note: The section th= at Cedric identifies 2.2.1 refers only to the Smart Meter Data application of the AMI network: for that application somewhere around 90% of the traffic generated comes from scheduled activities in each meter, reporting of metering data a= nd status data, that can be originated in the meter without need for polling, = thus creating the asymmetric aspect of this application. There will be symmetric= activities, polling, but they represent a reduced percentage of the traffic.=

There may be, though, implementations where the reporting of metering data and status data is also handled using polling schemes.

Regards

 

= Ruben Salazar
Director Research and Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165        
Ruben.Salazar@landisgyr.com=
www.landisgyr.com
manage energy better

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Je= tcheva, Jorjeta
Sent: Friday, September 16, 2011 12:11 PM
To: C Chauvenet
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02= .txt

 

Hel= lo C=E9dric,

 

Tha= nk you for your comments.  Since Nicolas already addressed your second questi= on, let me try to address the first one.  Most of the traffic tends to be towards the LBR in terms of bytes (reports are typically much bigger than queries), but also in terms of number of packets, e.g., some reports have t= o be split into multiple packets due to packet size limitations, periodic report= s can be sent without requiring each of them to be triggered by a query, and there are unsolicited events like alarms and outage notifications generated= by the meters as well.   Does this answer your question?<= /span>

 

Cle= arly there is room for clarification in the text, so we will update it accordingly.  Thanks again!

 

Jor= jeta

 

 

3D"http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg"

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jp=   3D"http://marketing.itron.com/campaign/social_media_icon_facebook29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_youtube29.jp=

 

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Thursday, September 15, 2011 2:00 AM
To: Jetcheva, Jorjeta
Cc: roll@ietf.org
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02= .txt

 

Hi Jorjeta, 

 

Thank you for the update, I think the doc brings addit= ional valuable content in this new revision.

 

I have 2 comments about this new version of the draft : 

 

In 2.2.1 : It is mentioned that the traffic in AMI net= works will be highly asymmetric, and mostly narrowed to MP2P traffic. <= /o:p>

I agree that most of the traffic in AMI will be sent b= y meters to the LBR. Though, as stated a little bit above in the doc, most of meters will be polled, resulting in P2MP traffic (unicast or multicast packets). So, my understanding is that if every meters is polled before sen= ding its data, the traffic becomes symmetrical, because you have a 1:1 ratio bet= ween downward (LBR polling) and upward (Meter reporting) traffic.

Could you please help me to understand your statement = ?

I think the traffic pattern may impact significantly t= he Storing Vs Non-Storing design choice.

 

 

In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) may be suitable for energy constrained node much as wat= er or gas meters.

I am not sure about the efficiency of Hop Count regard= ing energy consumption. As we are working in lossy networks, there is a great chance that the shortest path may not be the more reliable. So the shortest path may induce many MAC level retries (thus inducing a faster energy drop = of the node, and a higher congestion of the channel), and decrease significant= ly the reliability. This could result in a path that cannot meet the requireme= nts of AMI (regarding reliability especially). I guess you mentioned Hop count, because you get an minimum number of forwarder, thus reducing the number of devices involved in the path, and minimizing the impact of a packet in the global energy depletion of the global networks. I think this is very true i= n not-so-lossy networks, but I was wondering about lossy networks.=

In my opinion, LQL may be more adapted. Maybe your wer= e thinking about mixing Hop Count and LQL?

About energy, note that a specific metric has been des= igned in the rpl-metric-draft. It may be worth to mention it.

 

Best,

 

C=E9dric.

 

 

Le 14 sept. 2011 =E0 20:32, Jetcheva, Jorjeta a =E9cri= t :

 

= Hello everyone,

=  

= Just wanted to draw your attention to the new iteration of the RPL AMI Applicabi= lity Internet-Draft (version 02).  We’ve made a few improvements to t= he draft based on feedback from the group received so far.  Thank you all who s= ent us questions, comments and suggestions!

=  

= Below is a brief summary of the changes:

=  

= - Expanded discussion of Trickle parameter setting considerations<= /span>

= - Updates related to battery operated meters and routing infrastructure<= /o:p>

= - Expanded discussion related to network topology characteristics<= /span>

= - Updates related to traffic characteristics

= - Removed text discussing the benefits of multi-hop deployments vs. single-ho= p deployments

= - Clarification and readability improvements

=  

We look forward to your feedback as we work on improving the draft further!

 

Thanks, Jorjeta

 

 

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture=

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

 

 

<ATT00001..txt>

 

--_000_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_-- --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Fri, 16 Sep 2011 23:14:43 GMT"; modification-date="Fri, 16 Sep 2011 23:14:43 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Fri, 16 Sep 2011 23:14:44 GMT"; modification-date="Fri, 16 Sep 2011 23:14:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Fri, 16 Sep 2011 23:14:44 GMT"; modification-date="Fri, 16 Sep 2011 23:14:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Fri, 16 Sep 2011 23:14:44 GMT"; modification-date="Fri, 16 Sep 2011 23:14:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Fri, 16 Sep 2011 23:14:44 GMT"; modification-date="Fri, 16 Sep 2011 23:14:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_4EA811E84AEC874FA69EE87C8C6BBEB5869A6C0BDFFRPARSV10mxbm_-- From gnawali@cs.stanford.edu Sat Sep 17 22:40:25 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D97B21F8546 for ; Sat, 17 Sep 2011 22:40:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld43pUSJCfCe for ; Sat, 17 Sep 2011 22:40:25 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1A49421F8541 for ; Sat, 17 Sep 2011 22:40:25 -0700 (PDT) Received: from mail-pz0-f45.google.com ([209.85.210.45]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1R5A9K-0002R9-En for roll@ietf.org; Sat, 17 Sep 2011 22:42:42 -0700 Received: by pzk33 with SMTP id 33so11634179pzk.4 for ; Sat, 17 Sep 2011 22:42:42 -0700 (PDT) Received: by 10.68.54.101 with SMTP id i5mr2069921pbp.242.1316324562077; Sat, 17 Sep 2011 22:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.77.1 with HTTP; Sat, 17 Sep 2011 22:42:22 -0700 (PDT) In-Reply-To: References: <20110913214738.30744.1691.idtracker@ietfa.amsl.com> From: Omprakash Gnawali Date: Sun, 18 Sep 2011 00:42:22 -0500 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 05:40:25 -0000 On Tue, Sep 13, 2011 at 5:27 PM, Ulrich Herberg wrote: > Omprakash, > > thanks for the update of the draft. For easier discussion, I have included > the paragraph you have added in the draft: > > "A naive implementation of storing mode will have large state > overhead, especially in large networks. However, it is possible for > storing mode to use RAM efficiently by state aggregation, > compression, and other techniques. Current open source > implementations are known to limit the routing table size to 30 > (TinyOS on TelosB which has 10KB of RAM) and 100 (Contiki on > MSP430F5438-based platform which has 16K of RAM)." > > I think it is useful for implementers to have such a paragraph which > describes the trade-offs and considerations to make before deploying an RPL > network in either of the modes of operation. > > I agree that compression and other mechanisms can reduce the state to some > degree. When using compression, I would assume that a constant factor can be > gained (with possible loss of scope of addresses). But the tables will still > grow with O(n) with n being the nodes in the network. Maybe we could add > that to the sentence? > Concerning aggregation, I am not convinced that this always may work > efficiently, in particular when the network is dynamic (some nodes may be > added later, others may be replaced etc). In that case, the address space > could be non-continuous, which would require some additional protocol to > handle the assigned addresses intelligently, or the aggregation would be > much less effective. I think everyone agrees that storing mode may not be the right solution always. Regarding quantifying scaling assuming certain type of aggregation, this might not be the best document. I can count how big an entry is in some open source implementations as Cedric suggests in another email. What would be very helpful is people sharing their experiences running storing and non storing modes. I am happy to update the document so others can benefit from such experiences. - om_p From jpv@cisco.com Thu Sep 22 20:35:59 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19B211E808E for ; Thu, 22 Sep 2011 20:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptsm2uxJA+6a for ; Thu, 22 Sep 2011 20:35:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6794A1F0C3B for ; Thu, 22 Sep 2011 20:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=8226; q=dns/txt; s=iport; t=1316749112; x=1317958712; h=from:subject:date:message-id:cc:to:mime-version; bh=BUAur3lnuzmB3+/i/jhXg2258xyw7eITsCS1yEiq288=; b=Y9bNO42fTBr+wy8ElcP378ZUcUqDhPVd2DNiapf6KQe4CpQlKWuTokeX Nrvh5qsM7oJ0Bu4dbjapbMcd8UIJN47nnywwfif2rxc5SnxLczoJlFwW9 T9jq1+Ee1t+dIErBEqdvSye7gAaCkYW0nkU4+vBWI4yy9YqoomlI/+qyM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAX+e06Q/khN/2dsb2JhbABCgk2lPHiBbAFmgT4cGYdcll4BniuGHWAEh2+LYYUfCYwU X-IronPort-AV: E=Sophos;i="4.68,427,1312156800"; d="scan'208,217";a="116825122" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 23 Sep 2011 03:38:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8N3cU33023845; Fri, 23 Sep 2011 03:38:30 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 Sep 2011 05:38:30 +0200 Received: from [192.168.0.33] ([10.55.82.192]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Sep 2011 05:38:29 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary="Apple-Mail=_276AC879-9BDE-4013-8658-8E251EC0DBF4" Date: Fri, 23 Sep 2011 11:38:24 +0800 Message-Id: <7EF79512-039B-4F3C-8D55-25D19A1AEC74@cisco.com> To: roll WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-OriginalArrivalTime: 23 Sep 2011 03:38:30.0102 (UTC) FILETIME=[42E74F60:01CC79A2] Cc: David Culler Subject: [Roll] =?windows-1252?q?ROLL_WG_Meeting_Schedule=2C_request_for_s?= =?windows-1252?q?lots=2C_=85?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 03:36:00 -0000 --Apple-Mail=_276AC879-9BDE-4013-8658-8E251EC0DBF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Important dates: 2011-08-15 (Week of): IETF Online Registration opens. 2011-08-15 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool. 2011-09-26 (Monday): Cutoff date for requests to schedule Working Group = meetings at 17:00 PT (00:00 UTC). To request a Working Group session, = use the IETF Meeting Session Request Tool. 2011- 10-03 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (00:00 UTC). To request a BOF, please see = instructions on Requesting a BOF. 2011-10-06 (Thursday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (00:00 UTC). 2011-10-13 (Thursday): Preliminary agenda published for comment. 2011-10-17 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (00:00 UTC). 2011-10-17 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (00:00 UTC). 2011-10-21 (Friday): Final agenda to be published. 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission = Tool. 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT = (00:00 UTC), upload using IETF ID Submission Tool. 2011-11-02 (Wednesday): Draft Working Group agendas due by 17:00 PT = (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-11-04 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (00:00 UTC). 2011-11-07 (Monday): Revised Working Group agendas due by 17:00 PT = (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2011-11-07 (Monday): Registration cancellation cut-off at 17:00 PT = (00:00 UTC). 2011-11-11 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local meeting time. 2011-11-13 - 2011-11-18: 82nd IETF Meeting in Taipei, Taiwan. 2011-12-16 (Friday): Proceedings submission cutoff date by 17:00 PT = (00:00 UTC), upload using IETF Meeting Materials Management Tool. 2012-01-05 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (00:00 UTC), upload using IETF Meeting Materials Management = Tool. Please send us your request (should you need a slot) before Oct 31 at = noon ET.=20 ps: for information I won't be able to attend but David will be there to = chair the WG meeting. Thanks. JP.= --Apple-Mail=_276AC879-9BDE-4013-8658-8E251EC0DBF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

Important dates:

Please send = us your request (should you need a slot) before Oct 31 at noon = ET. 

ps: for information I won't be able = to attend but David will be there to chair the WG = meeting.

Thanks.

JP. = --Apple-Mail=_276AC879-9BDE-4013-8658-8E251EC0DBF4-- From iesg-secretary@ietf.org Tue Sep 27 07:34:07 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE82C21F8C00; Tue, 27 Sep 2011 07:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss9QwTsJyAEx; Tue, 27 Sep 2011 07:34:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7257721F8D94; Tue, 27 Sep 2011 07:34:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110927143406.453.79440.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2011 07:34:06 -0700 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Protocol Action: 'RPL Objective Function Zero' to Proposed Standard (draft-ietf-roll-of0-20.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 14:34:07 -0000 The IESG has approved the following document: - 'RPL Objective Function Zero' (draft-ietf-roll-of0-20.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-of0/ Technical Summary The Routing Protocol for Low Power and Lossy Networks (RPL) was designed as a generic core protocol that is agnostic to metrics and that is adapted to a given problem using Objective Functions (OF). This separation of Objective Functions from the core protocol specification allows RPL to adapt to meet the different optimization criteria required by the wide range of use cases. RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol. Each instance is associated with a specialized Objective Function. A DODAG is periodically reconstructed in a new Version to enable a global reoptimization of the graph. An Objective Function selects the DODAG Version that a device joins within an instance, and a number of neighbor routers within that DODAG Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by RPL to avoid loops and verify forward progression towards a destination. This document defines Objective Function 0 (OF0) which operates on parameters that are obtained from provisionning, from the RPL DODAG Configuration option, and from the RPL DIO base container. OF0 is designed as a default OF that will allow interoperation between implementations in a wide spectrum of use cases. Working Group Summary No discontent. There has been some confusion about the WG process because of the large number of revisions since the first WG last call. Here is the timeline: > 01/05 New revision -05 > 02/22 WG last call on -05 > 03/13 On-list discussions of changes > 03/13 New revision -06 > 03/13 New revision -07 > 03/14 WG last call on -07 > 03/16,, On-list discussions > 03/30 New revision -08 > 04/05 New revision -09 > 04/11 Comment on list > 04/11 New revision -10 > 04/21 Comment on list > 05/05 Notice to list about changes > 05/05 New revision -11 > 05/08 WG chair review posted to list > 05/10 Comment on list > 05/17 Notice to list about changes > 05/17 New revision -12 > 05/18.. On-list discussion > 05/24 Publication request > 06/01 AD review posted to list > 06/11 AD review :: Revised I-D needed > 06/17 New revision -13 > 06/20 New revision -14 > 06/20 IETF Last Call > 07/04 IETF Last Call ends > 07/08 New revision -15 > 07/16 Ballot issued > 08/09 IESG Discusses > 08/09.. On-list discussions > 08/11 IESG telechat Thus: all changes as a result of comments made on the list. Plenty of explanation to the list about what was changing and why. A further poll of the WG will be carried out after changes to address IESG Discusses Document Quality The OF0 has been extensively discussed and reviewed by key contributors of the Working Group. There are believed to be two implementations. Personnel JP Vasseur (jvasseur@cisco.com) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD. RFC Editor Note Section 4.2.1 OLD 2. An implementation SHOULD validate a router prior to selecting it as preferred as discussed in Section 3. The validation involves layer 2 connectivity to the router, layer 3 connectivity offered by the router, and may involve other factors such as policies. In most cases, a router that does not succeed the validation process cannot be further considered for selection as preferred parent. In any case a router that succeeded that validation process SHOULD be preferred. NEW 2. Prior to selecting a router as the preferred parent, an implementation SHOULD validate the connectivity and suitability of the router as discussed in Section 3. This validation involves checking the layer 2 connectivity to the router, the layer 3 connectivity offered by the router, and may involve examination of other factors such as locally or globally configured policies. In most cases, a router that does not succeed the validation process cannot be further considered for selection as preferred parent. In any case a router that succeeded that validation process SHOULD be preferred over one that does not succeed. END From adrian@olddog.co.uk Tue Sep 27 07:56:31 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9D21F8E10 for ; Tue, 27 Sep 2011 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsgC7lCBsjGq for ; Tue, 27 Sep 2011 07:56:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 258FD21F8DB3 for ; Tue, 27 Sep 2011 07:56:20 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8REx5hd016234; Tue, 27 Sep 2011 15:59:05 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8REx4ig016224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Sep 2011 15:59:05 +0100 From: "Adrian Farrel" To: Date: Tue, 27 Sep 2011 15:59:03 +0100 Message-ID: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acx9JebOqQuxacSeSJKxbycTLE63zA== Content-Language: en-gb Cc: roll@ietf.org Subject: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk 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 Sep 2011 14:56:31 -0000 Hi, Here is my AD review of your draft. I was hoping to get away with a few typos we could punt to a later stage, but I think there are a couple of issues we need to iron out with a quick new revision. I have put the I-D into "revised I-D needed" state and will issue the IETF Last Call when I see a new revision. Thanks, Adrian --- In progressing the OG0 draft we learnt that there was no clear understanding of what an objective function is. I think your draft does a good job at explaining, but in an attempt to learn from the past, can you please have a look at the text that got added to the OF0 document to see whether anything can be added here. --- Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not MROFH? --- During the review process for OF0 we ended up adding the following paragraph. Would you consider adding something similar to make this point crystal clear? The RPL specification [I-D.ietf-roll-rpl] requires the use of a common OF by all nodes in a network. The possible use of multiple OFs with a single network is for further study. --- Section 2... This document introduces two terms: There are three terms! --- Section 5.1 Can you add a statement on default values? Can you also have a look at Section 7 of the OF0 draft. This gives a more substantive approach to describing manageability. --- 7. IANA Considerations You need to point the IANA at the specific registry. This would be the "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. This specification requires an allocated OCP. A value of 1 is requested. s/requested/suggested/ --- 8. Security Considerations Security considerations to be developed in accordance to the output of the WG. I don't think we will get this past the Security directorate :-) How about... This specification makes simple extensions to RPL and so is vulnerable to and benefits from the security issues and mechanisms described in [I-D.ietf-roll-rpl] and [I-D.ietf-roll-security-framework]. This document does not introduce new flows or new messages, thus requires no specific mitigation for new threats. MRHOF depends on information exchanged in a number RPL protocol elements. If those elements were compromised, then an implementation of MRHOF might generate the wrong path for a packet, resulting in it being misrouted. Therefore, deployments are RECOMMENDED to use RPL security mechanisms if there is a risk that routing information might be modified or spoofed. From internet-drafts@ietf.org Tue Sep 27 12:08:08 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1757A21F8F2C; Tue, 27 Sep 2011 12:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKeyg59U44aw; Tue, 27 Sep 2011 12:08:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE1021F8F34; Tue, 27 Sep 2011 12:08:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110927190800.18790.39366.idtracker@ietfa.amsl.com> Date: Tue, 27 Sep 2011 12:08:00 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 19:08:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Applicability Statement for the Routing Protocol for Low= Power and Lossy Networks (RPL) in AMI Networks Author(s) : Daniel Popa Jorjeta Jetcheva Nicolas Dejean Ruben Salazar Jonathan W. Hui Filename : draft-ietf-roll-applicability-ami-03.txt Pages : 17 Date : 2011-09-27 This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-applicability-ami-03.txt From Jorjeta.Jetcheva@itron.com Tue Sep 27 12:19:56 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0672321F8F80 for ; Tue, 27 Sep 2011 12:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.548 X-Spam-Level: X-Spam-Status: No, score=-0.548 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJIaNNX1+ZPw for ; Tue, 27 Sep 2011 12:19:55 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34D21F8F89 for ; Tue, 27 Sep 2011 12:19:54 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 27 Sep 2011 12:22:38 -0700 From: "Jetcheva, Jorjeta" To: "roll@ietf.org" Date: Tue, 27 Sep 2011 12:22:33 -0700 Thread-Topic: changes in draft-ietf-roll-applicability-ami-03.txt Thread-Index: Acx9Ss7hRJCwW4vkTj27zHG64Ecm7w== Message-ID: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AYW0 BFaq CHcF CSkS E0rP E+7O FVnC GD1P GQjN InPA JD5p JEhT JILF JK1s JYbL KC2r; 1; cgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {B2EE9D6F-9E17-4384-AEAE-7C713119D8EF}; agBvAHIAagBlAHQAYQAuAGoAZQB0AGMAaABlAHYAYQBAAGkAdAByAG8AbgAuAGMAbwBtAA==; Tue, 27 Sep 2011 19:22:33 GMT; YwBoAGEAbgBnAGUAcwAgAGkAbgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQByAG8AbABsAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtAGEAbQBpAC0AMAAzAC4AdAB4AHQA x-cr-puzzleid: {B2EE9D6F-9E17-4384-AEAE-7C713119D8EF} acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 19:19:56 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 03). C=E9dric, thank you for the feedback= ! Below is a brief summary of the changes: =B7 Added more details to the Traffic Characteristics Section =B7 Clarified the text related to routing metrics for energy-constr= ained devices We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta [cid:image001.jpg@01CC7D10.1FF79610] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC7D10.1FF79610] [cid:im= age003.jpg@01CC7D10.1FF79610] [cid:im= age004.jpg@01CC7D10.1FF79610] [cid:image005.jpg@01CC7D10.1FF79610] --_000_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hello everyone,

=  

= Just wanted to draw your attention to the new iteration of the RPL AMI Applicabi= lity Internet-Draft (version 03). C=E9dric, thank you for the feedback!

=  

= Below is a brief summary of the changes:

=  

=B7      =    Added more details to the Traffic Characteristics Section

=B7      =    Clarified the text related to routing metrics for energy-constrained devices

=  

We look forward to your feedback as we work on improvi= ng the draft further!

 

Thanks, Jorjeta

 

 

3D"http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg"

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jp= &n= bsp;  &n= bsp; 3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.j= &n= bsp; 

 

 

--_000_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Tue, 27 Sep 2011 12:22:37 GMT"; modification-date="Tue, 27 Sep 2011 12:22:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Tue, 27 Sep 2011 12:22:37 GMT"; modification-date="Tue, 27 Sep 2011 12:22:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Tue, 27 Sep 2011 12:22:37 GMT"; modification-date="Tue, 27 Sep 2011 12:22:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Tue, 27 Sep 2011 12:22:37 GMT"; modification-date="Tue, 27 Sep 2011 12:22:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Tue, 27 Sep 2011 12:22:37 GMT"; modification-date="Tue, 27 Sep 2011 12:22:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4D628684ITREXMBXVS2itro_-- From c.chauvenet@watteco.com Wed Sep 28 02:31:05 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90821F8D25 for ; Wed, 28 Sep 2011 02:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdU9xK22ImIr for ; Wed, 28 Sep 2011 02:31:04 -0700 (PDT) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7265A21F8D27 for ; Wed, 28 Sep 2011 02:31:04 -0700 (PDT) Received: from mail108-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 28 Sep 2011 09:33:51 +0000 Received: from mail108-va3 (localhost.localdomain [127.0.0.1]) by mail108-va3-R.bigfish.com (Postfix) with ESMTP id A75692680AE; Wed, 28 Sep 2011 09:33:51 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zzc89bh1431Jc85dh14ffO4015Lzz1202hzz1033ILc704dh8275bh8275dhz2dh2a8h668h839h8aah) X-Forefront-Antispam-Report: CIP:213.199.187.153; KIP:(null); UIP:(null); IPVD:NLI; SRV:BULK; H:IE2RD2HUB009.red002.local; RD:none; EFVD:NLI X-FB-SS: 0,0, Received: from mail108-va3 (localhost.localdomain [127.0.0.1]) by mail108-va3 (MessageSwitch) id 1317202430860768_24084; Wed, 28 Sep 2011 09:33:50 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.239]) by mail108-va3.bigfish.com (Postfix) with ESMTP id CCDEDA0004B; Wed, 28 Sep 2011 09:33:50 +0000 (UTC) Received: from IE2RD2HUB009.red002.local (213.199.187.153) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 28 Sep 2011 09:33:50 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB009.red002.local ([10.33.16.248]) with mapi; Wed, 28 Sep 2011 02:32:41 -0700 From: C Chauvenet To: "Jetcheva, Jorjeta" Date: Wed, 28 Sep 2011 02:32:39 -0700 Thread-Topic: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt Thread-Index: Acx9wZE6Yl8Jp9HxSx+6X9w1G+Rp8A== Message-ID: <6BD57B3E-238A-4245-911C-5A5FEF8CEAD1@watteco.com> References: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> In-Reply-To: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_6BD57B3E238A4245911C5A5FEF8CEAD1wattecocom_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 09:31:05 -0000 --_000_6BD57B3E238A4245911C5A5FEF8CEAD1wattecocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jorjeta, Thank you for the update. I'm happy with your changes. Slight remaining remark : I section 4.1.4, the "companion RFCs" may be explicitly mentioned as the me= trics-related ROLL document : http://tools.ietf.org/html/draft-ietf-roll-ro= uting-metrics-19. (Currently in RFC Queue) and added in the Informative Ref= erences Section. But you may think of other docs, and so mentioning only this document may n= arrow the scope of documents that may be applicable for metrics design. Best, C=E9dric. Le 27 sept. 2011 =E0 21:22, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 03). C=E9dric, thank you for the feedback= ! Below is a brief summary of the changes: * Added more details to the Traffic Characteristics Section * Clarified the text related to routing metrics for energy-constrai= ned devices We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_6BD57B3E238A4245911C5A5FEF8CEAD1wattecocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jorjeta, 

Thank you for the update.
<= br>
I'm happy with your changes.

Slight = remaining remark : 

I section 4.1.4, the "com= panion RFCs" may be explicitly mentioned as the metrics-related ROLL docume= nt : http://tools.ietf.org/html/draft-ietf-roll-routing-metrics-19.= (Currently in RFC Queue) and added in the Informative References Sect= ion. 
But you may think of other docs, and so mentioning&nbs= p;only this document may narrow the scope of documents that may be app= licable for metrics design.

Best,

C=E9dric.

Le 27 sept. 2011 =E0 21:22, Jetc= heva, Jorjeta a =E9crit :

Hello everyone,
 
Just wanted to draw your attention to the new iteration of t= he RPL AMI Applicability Internet-Draft (version 03). C=E9dric, thank you for the feedback!
 
Below is a brief summary of the c= hanges:
&= nbsp;
=B7         Added more details to the Traffic Characteristic= s Section
=B7         Clarified the text related to routing = metrics for energy-constrained devices
 
We look forward to your = feedback as we work on improving the draft further!
 =
Thanks, Jorjeta
 
 =
= Jorjeta Jetcheva, Ph.D.
Strategic Industry Standards and= Architecture
Office of the CTO
Mobile: +1.408= .688.1428
Knowledge to Shape Your Future
<= /td>
 
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">=  
_______________________________________________
= Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

= --_000_6BD57B3E238A4245911C5A5FEF8CEAD1wattecocom_-- From mischa.dohler@cttc.es Thu Sep 29 01:20:49 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E321F8CCD for ; Thu, 29 Sep 2011 01:20:49 -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_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flFsiHXFd3Lf for ; Thu, 29 Sep 2011 01:20:45 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id BAF0221F8C7A for ; Thu, 29 Sep 2011 01:20:43 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8T8NEbS001598 for ; Thu, 29 Sep 2011 10:23:24 +0200 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) by castor (Postfix) with ESMTP id 933472FC27B for ; Thu, 29 Sep 2011 10:23:14 +0200 (CEST) Message-ID: <4E842ADD.6080102@cttc.es> Date: Thu, 29 Sep 2011 10:22:53 +0200 From: Mischa Dohler Organization: CTTC User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Thu, 29 Sep 2011 10:23:14 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Roll] FW: New I-D on composite routing metrics X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 08:20:50 -0000 Hi Panos and Theodore, I have gone through your updated draft http://tools.ietf.org/html/draft-zahariadis-roll-metrics-composition-01. It reads much better now and seems to have addressed the worries issued by Cedric and Pascal before. I personally fully second your findings on the need for composite routing metrics, facilitating in a sense some QoS framework over LLNs. I also like that you corroborate this by some theoretical framework on routing algebra (something coming a little too short in this WG so far). I would welcome however that you stated more clearly in the introduction that prior ROLL documents, notably - "draft-ietf-roll-minrank-hysteresis-of", - "draft-ietf-roll-routing-metrics" and - "draft-ietf-rollof0" define objective functions composed of one metric, but that the recently issued -"draft-ietf-roll-applicability-ami-03" clearly states the need for using more than one to get practical deployments viably going. It would be great if you could attend an upcoming IETF meeting to make a case for your draft which I am sure the entire WG would greatly profit from. Thanks and kind regards, Mischa. ______________________________ Dr Mischa Dohler Head of [IQe], CTTC, Barcelona www.cttc.es/home/mdohler CTO Worldsensing, Barcelona www.worldsensing.com ______________________________ [Roll] ÎÏÎÏ: Re: FW: New I-D on composite routing metrics To: C Chauvenet Subject: [Roll] ÎÏÎÏ: Re: FW: New I-D on composite routing metrics From: Panos Trakadas Date: Sun, 7 Aug 2011 10:58:21 +0100 (BST) Cc: roll at ietf.org Delivered-to: roll at ietfa.amsl.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1312711102; bh=IrSOTHkbfzZvXGay1yO2e0qV/eZmu7SUJjND8edHlQM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=2ceNeHNqjp/btN3PxxL9hJB4ur6UAxjs2o29plOP1kBVQ0UHPfg87kLGZixT0CrUAe1i9UIRbxGOnWTCkQd0Y4vcMNKApMXf+mQ8nNljjb+3KNf9XVnnmISFZMigc9kx8cU+tyihPbHJAG6+rewyKSQum9ELEbHWlPhtxwNH5uI= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=iCTLwhCfA2uxW3g4CNUZ0qwyTTXtLlpEjymO1cCMBJ5+Iup3yd0U00rB49rVOjjpmAriZaEV51GHdhiMy8HbwcO4I/4uTl6kBr/4BOlfA7XMxPEFomo7XkVdFzNWaL/Kp/xL2KdbvtV3NbtfpXjNaX/F/HHL4tf4r3dBaQpI+yQ=; List-archive: List-help: List-id: Routing Over Low power and Lossy networks List-post: List-subscribe: , List-unsubscribe: , Hi Cedric, We will take into consideration your comments in the newer version of our draft. Furthermore, we are developing RPL for JSim simulation platform (hopefully it will be ready by mid August). We could benefit from this simulator towards many directions such as evaluation of several QoS composite metrics, experimentation with multiple application-specific instances, as well as accurate estimation on hysteresis threshold. Best regards, Theodore and Panos. From: C Chauvenet ; To: Panos Trakadas ; Cc: zahariad at teihal.gr ; roll at ietf.org ; Subject: Re: [Roll] FW: New I-D on composite routing metrics Sent: Sat, Aug 6, 2011 2:29:35 PM Hi, See inline. Le 5 aoÃt 2011 Ã 01:58, Panos Trakadas a Ãcrit : > Dear Cedric, > > We believe that the definition of "order relation" is correct: the order relation is used by the OF to compare link/node weights along the path (equivalently, metric values) and select parent node. > > > [C.C] I Agree with your definition. > > As an example, consider the case where the ETX is aggregated along the traversed path. If node A receives DIO messages from nodes B and C (potential parents) with ETX values of 2.5 and 3.2, respectively, then the order relation will help selecting node B (advertising the minimum value of ETX) as the parent of node A. > In this concept, your comment is right; the order relation of LQL must be minimum (and not maximum). Please consider it as a typo. > > [C.C] OK > > > Regarding link-color comment: Apart from being used as a 10-bit flag field (e.g. for indicating the encrypted links, as described in rpl-metrics draft), link color may be used to indicate the number of nodes along the path transmitting at a specific radio channel; in this way interference can be reduced by selecting transmission in the "least occupied" channel. In this case, the order relation must be "minimum" and the domain is integer. > > [C.C] I think that the confusion is greatly due to the very wide range that the link color metric may cover. You example of the usage of this metric is interesting, but many others usage may be possible, and so an global order relation seems difficult to find for this metric. > > In general, we will re-format Table 1, following the metric description in rpl-metrics draft. Also, we will replace words "minimum"/"maximum" in the "order relation" column by "less-than" and "greater-than" in accordance to the order relation definition. > > [C.C] I agree that it would increase the readability. > > Before submitting this draft, there was a discussion on whether we should include examples and formulas in this initial version of the document; it seems that our decision was wrong... We will be happy to include examples and formulas to improve readability of this draft. > > [C.C] Nice. I think this would provide precious guidelines for readers, and speed up some RPL design. > > Finally, we think that "hysteresis" can provably improve RPL performance, and thus it will be included in this draft. To be honest, there is a "hidden" phrase: "...and if the first component values are equal *or differ less than a predefined threshold*..." (section 4.1, first sentence) indicating our effort to include hysteresis in this draft. We will give more emphasis on that point. > > [C.C] I noticed that reference, but it should be worth to explicitly speak about it. I also agree that the Hysteresis mechanism defined in the MRHOF draft greatly improve the stability of the topology and should be highly recommended. BTW, some guidelines about how to determine the good threshold value would be interesting. > > Thanks for your valuable comments, > Panos. > > CÃdric. > > > --- ÎÏÎÏ ÎÎÏ., 03/08/11, Î/Î C Chauvenet ÎÎÏÎÏÎ: > > > ÎÏÏ: C Chauvenet > ÎÎÎÎ: Re: [Roll] FW: New I-D on composite routing metrics > ÎÏÎÏ: "zahariad at teihal.gr" > ÎÎÎÎ.: "TRAKADAS PANOS" , "roll at ietf.org" > ÎÎÎÏÎÎÎÎÎÎ: ÎÎÏÎÏÏÎ, 3 ÎÏÎÎÏÏÏÎÏ 2011, 18:46 > > Hi Theodore, > > I found your draft interesting and it gave me some useful guidelines for metric's design. > > I've several comments on this : > > I fail to understand well the "Order Relation" you use in Table 1. > The definition of "metric order relation" given on page 4 doesn't really helped me. > Could you help me understand the Order Relation column in the table? > > In this table in particular (Figure 1): > > - Could you precise your view of the Link-Color metric (Why is it in the integer domain, why the order relation in "minimum" ?). > > - As far as I understand the Order Relation, it seems that the LQL order relation should not be "maximum" but rather "minimum" (same relation as ETX, excluding the 0 value). > > > More generally, I would be happy to see in the document some formulas examples for metric computation, or maybe some guidelines. > > Some example of metrics composition would also be great (You mention one in your draft with is ETX + RE (remainging Energy). Do you have some idea about other set of metric that would be interesting to bind ? > > I finally think that it should be worth to add some content about the mechanisms that aim to deal with metric's dynamics (Multi Threshold, EWMA, Low pass Filters, ...). Some of them are mentioned at the end of the rpl metric draft. > > Best, > > CÃdric. > > Le 2 aoÃt 2011 Ã 02:55, Theodore Zahariadis a Ãcrit : > > > Dear all, > > My colleague Dr. Panos Trakadas and myself are working on an EC-funded > > research project, called VITRO (Virtualized Distributed platform of Smart > > objects - http://www.vitro-fp7.eu/), which has adopted RPL as the primary > > routing protocol and we are currently performing some simulations and tests. > > > > By monitoring roll, we have noticed that three (sorry if we have missed any) > > I-D are discussed in the ROLL WG (draft-ietf-roll-minrank-hysteresis-of, > > draft-ietf-roll-of0, draft-gnawali-roll-etxof), defining RPL Objective > > Functions related to a single routing metric (either hop-count or ETX). > > > > In VITRO, each sensor may be part of many virtual networks (even from > > different administrative domains) and must be able to concurrently support > > multiple user requests even with contradicting QoS characteristics. It is > > obvious that in such cases, a composite routing metric is of great > > importance. > > > > In draft-zahariadis-roll-metrics-composition-00 > > (http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-composition/) > > , we aim at specifying the guidelines for designing efficient composite > > routing metrics to be applied at RPL routing protocol. > > > > We would be happy to receive your comments > > > > Best Regards, > > Theodore Zahariadis > > > > > > ------------------------------------ > > Ass. Prof. Theodore Zahariadis, PhD > > Technological Educational Institute of Chalkida > > Psachna, Chalkida, Greece > > Tel: +30 22280 99550 , +30 6932495045 > > Skype: theodore.zahariadis > > > > > > _______________________________________________ > > Roll mailing list > > Roll at ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll at ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jorjeta.Jetcheva@itron.com Thu Sep 29 18:48:13 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A856521F8C66 for ; Thu, 29 Sep 2011 18:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CihQEJPOxk5w for ; Thu, 29 Sep 2011 18:48:12 -0700 (PDT) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD821F8C53 for ; Thu, 29 Sep 2011 18:48:07 -0700 (PDT) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Thu, 29 Sep 2011 18:50:49 -0700 From: "Jetcheva, Jorjeta" To: C Chauvenet Date: Thu, 29 Sep 2011 18:50:48 -0700 Thread-Topic: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt Thread-Index: Acx9wZE6Yl8Jp9HxSx+6X9w1G+Rp8ABUXHAA Message-ID: <0368F388C03BB34BBBFA73209849D47A4D74BA61@ITR-EXMBXVS-2.itron.com> References: <0368F388C03BB34BBBFA73209849D47A4D628684@ITR-EXMBXVS-2.itron.com> <6BD57B3E-238A-4245-911C-5A5FEF8CEAD1@watteco.com> In-Reply-To: <6BD57B3E-238A-4245-911C-5A5FEF8CEAD1@watteco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Sep 2011 01:48:13 -0000 --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: multipart/alternative; boundary="_000_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_" --_000_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello C=E9dric, That's a good point. Thanks! Jorjeta [cid:image001.jpg@01CC7ED8.B12AF540] Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future [cid:image002.jpg@01CC7ED8.B12AF540] [cid:im= age003.jpg@01CC7ED8.B12AF540] [cid:im= age004.jpg@01CC7ED8.B12AF540] [cid:image005.jpg@01CC7ED8.B12AF540] From: C Chauvenet [mailto:c.chauvenet@watteco.com] Sent: Wednesday, September 28, 2011 2:33 AM To: Jetcheva, Jorjeta Cc: roll@ietf.org Subject: Re: [Roll] changes in draft-ietf-roll-applicability-ami-03.txt Hi Jorjeta, Thank you for the update. I'm happy with your changes. Slight remaining remark : I section 4.1.4, the "companion RFCs" may be explicitly mentioned as the me= trics-related ROLL document : http://tools.ietf.org/html/draft-ietf-roll-ro= uting-metrics-19. (Currently in RFC Queue) and added in the Informative Ref= erences Section. But you may think of other docs, and so mentioning only this document may n= arrow the scope of documents that may be applicable for metrics design. Best, C=E9dric. Le 27 sept. 2011 =E0 21:22, Jetcheva, Jorjeta a =E9crit : Hello everyone, Just wanted to draw your attention to the new iteration of the RPL AMI Appl= icability Internet-Draft (version 03). C=E9dric, thank you for the feedback= ! Below is a brief summary of the changes: * Added more details to the Traffic Characteristics Section * Clarified the text related to routing metrics for energy-constrai= ned devices We look forward to your feedback as we work on improving the draft further! Thanks, Jorjeta Jorjeta Jetcheva, Ph.D. Strategic Industry Standards and Architecture Office of the CTO Mobile: +1.408.688.1428 Knowledge to Shape Your Future _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hel= lo C=E9dric,

 

Tha= t’s a good point. Thanks!

 

Jor= jeta

 

3D"http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg"

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

3D"http://marketing.itron.com/campaign/social_media_icon_twitter29.jp=   3D"http://marketing.itron.com/campaign/social_media_icon_facebook29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_linkedin29.j=   3D"http://marketing.itron.com/campaign/social_media_icon_youtube29.jp=

 

 

From: C Chauvenet [mailto:c.chauvenet@watteco.com]
Sent: Wednesday, September 28, 2011 2:33 AM
To: Jetcheva, Jorjeta
Cc: roll@ietf.org
Subject: Re: [Roll] changes in draft-ietf-roll-applicability-ami-03.= txt

 

Hi Jorjeta, 

 

Thank you for the update.

 

I'm happy with your changes.

 

Slight remaining remark : 

 

I section 4.1.4, the "companion RFCs" may be explicitly mentioned as the metrics-related ROLL document : http= ://tools.ietf.org/html/draft-ietf-roll-routing-metrics-19. (Currently in RFC Queue) and added in the Informative References Section. 

But you may think of other docs, and so mentioning only this document may narrow the scope of documents t= hat may be applicable for metrics design.

 

Best,

 

C=E9dric.

 

Le 27 sept. 2011 =E0 21:22, Jetcheva, Jorjeta a =E9cri= t :



Hello everyone,=

 

Just wanted to draw your attention to the new iteration of the RPL AMI Applicabi= lity Internet-Draft (version 03). C=E9dric, thank you for the feedback!

 

Below is a brief summary of the changes:

 

=B7  &= nbsp;      Added more details to the Traffic Characteristics Section

=B7  &= nbsp;      Clarified the text related to routing metrics for energy-constrained devices

 

We look forward to your feedback as we work on improving the draft further!

 

Thanks, Jorjeta

 

 

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture=

Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

 

 

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

 

--_000_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_-- --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=20786; creation-date="Thu, 29 Sep 2011 18:50:48 GMT"; modification-date="Thu, 29 Sep 2011 18:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4RLERXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAA agEoAAMAAAABAAIAAAExAAIAAAAeAAAAcgEyAAIAAAAUAAAAkIdpAAQAAAABAAAApAAAANAACvyA AAAnEAAK/IAAACcQQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2gAMjAxMTowOTowOSAwOToz ODo1OQAAA6ABAAMAAAABAAEAAKACAAQAAAABAAAASKADAAQAAAABAAAAUQAAAAAAAAAGAQMAAwAA AAEABgAAARoABQAAAAEAAAEeARsABQAAAAEAAAEmASgAAwAAAAEAAgAAAgEABAAAAAEAAAEuAgIA BAAAAAEAABGOAAAAAAAAAEgAAAABAAAASAAAAAH/2P/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5v AhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAA AAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAA FHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALE AAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gA AAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJp Z2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElF QzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAA AAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZ WiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAA AAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29s b3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVu Y2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNl IFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABX H+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAA AAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8 AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0B EwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZ AeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC 6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7 BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF 5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfS B+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEK Jwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzA DNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MP zw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMj E0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW +hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsU GzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qf vx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSr JNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIq NSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+ MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2 cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0i PWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdE ikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwq THJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJU j1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0n XXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1m kmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XAr cIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6 pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VH hauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q 1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJ nPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSp N6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYB tnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+ 0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M 8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23/ ///tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8V GBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4O DhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA UQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSWQ90pJJJJSkkkklKSSSSU pJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa3LzLq2vbLambgDr/ADln 0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5dNdmNkWFmJXEQ2pzqS/aN rff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14jQ/iwQ+J4JTlCX6v24iU5 S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6qaiS47QXOt9zWNbWtbpX 1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5uewDGTHLG5A8Gv4uZ1fD6R gU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t2ol/1J6tj4d2U91R9AOc a2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8+kkki3H/085eh9I/yR9T vtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxcfD+g+h9Msf0r6mjJe4mz 0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kpBzFEen5Y8I16/vNWXwoS GQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7GraZjjpWbmdV6l1Amm6R VU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJOb4WMmSUo5Pbx5IiE8cYR +WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8vybKWUvc7kvsAbd/0fUXn CSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TOSXnaSyHun0RJedpJKfRE l52kkp9ESXnaSSn0RJedpJKf/9n/7RmsUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQQ6AAAAAACNAAAAEAAAAAEAAAAAAAtwcmludE91dHB1dAAAAAQAAAAAUHN0 U2Jvb2wBAAAAAEludGVlbnVtAAAAAEludGUAAAAAQ2xybQAAAA9wcmludFNpeHRlZW5CaXRib29s AAAAAAtwcmludGVyTmFtZVRFWFQAAAAMAEkATQBBAEcARQBSAFUATgBOAEUAUgAAADhCSU0EOwAA AAABsgAAABAAAAABAAAAAAAScHJpbnRPdXRwdXRPcHRpb25zAAAAEgAAAABDcHRuYm9vbAAAAAAA Q2xicmJvb2wAAAAAAFJnc01ib29sAAAAAABDcm5DYm9vbAAAAAAAQ250Q2Jvb2wAAAAAAExibHNi b29sAAAAAABOZ3R2Ym9vbAAAAAAARW1sRGJvb2wAAAAAAEludHJib29sAAAAAABCY2tnT2JqYwAA AAEAAAAAAABSR0JDAAAAAwAAAABSZCAgZG91YkBv4AAAAAAAAAAAAEdybiBkb3ViQG/gAAAAAAAA AAAAQmwgIGRvdWJAb+AAAAAAAAAAAABCcmRUVW50RiNSbHQAAAAAAAAAAAAAAABCbGQgVW50RiNS bHQAAAAAAAAAAAAAAABSc2x0VW50RiNQeGxAUgAAAAAAAAAAAAp2ZWN0b3JEYXRhYm9vbAEAAAAA UGdQc2VudW0AAAAAUGdQcwAAAABQZ1BDAAAAAExlZnRVbnRGI1JsdAAAAAAAAAAAAAAAAFRvcCBV bnRGI1JsdAAAAAAAAAAAAAAAAFNjbCBVbnRGI1ByY0BZAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAAB AAEASAAAAAEAAThCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAEAAAAeDhCSU0E GQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTScQAAAAAAAKAAEAAAAAAAAAAThC SU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQChmZoABgAAAAAAAQAyAAAAAQBaAAAA BgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAAcAAA//////////////////////// /////wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////// ////A+gAAAAA/////////////////////////////wPoAAA4QklNBAgAAAAAABAAAAABAAACQAAA AkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADSQAAAAYAAAAAAAAAAAAAAFEAAABIAAAA CgBVAG4AdABpAHQAbABlAGQALQAxAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAABI AAAAUQAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAA AAIAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVm dGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAUQAAAABSZ2h0bG9uZwAAAEgAAAAGc2xpY2VzVmxMcwAA AAFPYmpjAAAAAQAAAAAABXNsaWNlAAAAEgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxv bmcAAAAAAAAABm9yaWdpbmVudW0AAAAMRVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAA VHlwZWVudW0AAAAKRVNsaWNlVHlwZQAAAABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0 MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAAFEAAAAA UmdodGxvbmcAAABIAAAAA3VybFRFWFQAAAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRF WFQAAAABAAAAAAAGYWx0VGFnVEVYVAAAAAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNl bGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdk ZWZhdWx0AAAACXZlcnRBbGlnbmVudW0AAAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAAL YmdDb2xvclR5cGVlbnVtAAAAEUVTbGljZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0 bG9uZwAAAAAAAAAKbGVmdE91dHNldGxvbmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAA C3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJTQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQUAAAAAAAE AAAABDhCSU0EDAAAAAARqgAAAAEAAABIAAAAUQAAANgAAERYAAARjgAYAAH/2P/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////tAAxBZG9iZV9DTQAB/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkI DAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwM/8AAEQgAUQBIAwEiAAIRAQMRAf/dAAQABf/EAT8AAAEFAQEBAQEBAAAAAAAAAAMA AQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMB AAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKj dDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cR AAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M0 8SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW 5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8AzkkklkPdKSSSSUpJJJJSkkkklKSSSSU//9DOSSSW Q90pJJJJSkkkklKSSSSUpJJJJT//0c5JJJZD3SkkkklKSSSSUpJJJJSkkkklP//Szkkl2H1A6dVa 3LzLq2vbLambgDr/ADln0v8ArSyscDOQiNLez5rmI8vhllkOLhr07cXEeF49Jd/0roWH1DMzep5d NdmNkWFmJXEQ2pzqS/aNrff6bVjZX1RzMzq+dVhGimqhzYaS4NAeN9bNK3e/0/dZ/XUh5eYAI14j Q/iwQ+J4JTlCX6v24iU5S+WMjwxlD/AnPgeZVnpmKMvOqodqxxl/9UDc5aOb9Uuq4Yqa7ZbdfYa6 qaiS47QXOt9zWNbWtbpX1T6pgWm2wVvusrdsaHHa0jaf0tm36Tvofo/UUOTFm4JcECZVp5y2X5ue wDGTHLG5A8Gv4uZ1fD6RgU7WVk5Dx7G7naD992qwluY31d611jLyy8squx3hlwuLgNxn2V+m232t 2ol/1J6tj4d2U91R9AOca2lxc5rPpOZ7P3Ruahh5fLGHq4pncyKMfM4MVY8mcSyGruXFrP5eH+q8 +kkki3H/085eh9I/yR9TvtJ9thqffPi6z+Y/6PorzxJZeLJ7ZJqyRQ8Hsec5X7zGEDLhjGYnIVxc fD+g+h9Msf0r6mjJe4mz0XWtJMwbP6O0f51SX1cc7A+rNnUcgl9tgsyXl5JJgbKwXH3e5lTF54kp BzFEen5Y8I16/vNWXwoSGQHJrly+9M8H6H+a+d7P6ndYszepXnqOQbMgs/Vg8wBuM3Mpb9Fu7bV7 GraZjjpWbmdV6l1Amm6RVU4kNY2dzWtZLt9jPoM9P/0YvMk7nOcZcST4nVKHMERAMeIg2JX/ANJO b4WMmSUo5Pbx5IiE8cYR+WP+bl/k30vAzGV9Hy+sluz7QbckNPO1o9KgH+vXTWhdcyL8H6puGQ8v ybKWUvc7kvsAbd/0fUXnCSJ5o8NcP6PDv1O8lg+ERGQT9ywMgycPB+hD+bxcXH+ipJJJV3Vf/9TO SXnaSyHun0RJedpJKfREl52kkp9ESXnaSSn0RJedpJKf/9k4QklNBCEAAAAAAFUAAAABAQAAAA8A QQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAgAFAAaABvAHQAbwBz AGgAbwBwACAAQwBTADUAAAABADhCSU0EBgAAAAAABwAIAQEAAQEA/+ENmmh0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC8APD94cGFja2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6 TlRjemtjOWQiPz4gPHg6eG1wbWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0i QWRvYmUgWE1QIENvcmUgNS4wLWMwNjAgNjEuMTM0Nzc3LCAyMDEwLzAyLzEyLTE3OjMyOjAwICAg ICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjIt cmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4bWxuczp4bXA9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25z LmFkb2JlLmNvbS9waG90b3Nob3AvMS4wLyIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvIiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21t LyIgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJj ZUV2ZW50IyIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQaG90b3Nob3AgQ1M1IE1hY2ludG9zaCIg eG1wOkNyZWF0ZURhdGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNZXRhZGF0YURh dGU9IjIwMTEtMDktMDlUMDk6Mzg6NTktMDc6MDAiIHhtcDpNb2RpZnlEYXRlPSIyMDExLTA5LTA5 VDA5OjM4OjU5LTA3OjAwIiBwaG90b3Nob3A6Q29sb3JNb2RlPSIzIiBwaG90b3Nob3A6SUNDUHJv ZmlsZT0ic1JHQiBJRUM2MTk2Ni0yLjEiIGRjOmZvcm1hdD0iaW1hZ2UvanBlZyIgeG1wTU06SW5z dGFuY2VJRD0ieG1wLmlpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1wTU06 RG9jdW1lbnRJRD0ieG1wLmRpZDozOEVDOTBGRDFBMjI2ODExOEQ0REE0Qzk2QkZDRjc0MyIgeG1w TU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZC RkNGNzQzIj4gPHBob3Rvc2hvcDpEb2N1bWVudEFuY2VzdG9ycz4gPHJkZjpCYWc+IDxyZGY6bGk+ eG1wLmRpZDo1QkM3ODJFQzExMjA2ODExODA4M0M2NDI4QkQ3NkVDNzwvcmRmOmxpPiA8L3JkZjpC YWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8eG1wTU06SGlzdG9yeT4gPHJkZjpT ZXE+IDxyZGY6bGkgc3RFdnQ6YWN0aW9uPSJjcmVhdGVkIiBzdEV2dDppbnN0YW5jZUlEPSJ4bXAu aWlkOjM4RUM5MEZEMUEyMjY4MTE4RDREQTRDOTZCRkNGNzQzIiBzdEV2dDp3aGVuPSIyMDExLTA5 LTA5VDA5OjM4OjU5LTA3OjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9iZSBQaG90b3Nob3Ag Q1M1IE1hY2ludG9zaCIvPiA8L3JkZjpTZXE+IDwveG1wTU06SGlzdG9yeT4gPC9yZGY6RGVzY3Jp cHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFja2V0IGVuZD0idyI/Pv/iDFhJQ0NfUFJP RklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFjc3BNU0ZUAAAAAElF QyBzUkdCAAAAAAAAAAAAAAABAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHw AAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQA AAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1l YXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAI DHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBDb21wYW55AABkZXNj AAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAA 81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAA AAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklFQyA2MTk2Ni0yLjEg RGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNj AAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAA AAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQTCwADXJ4AAAABWFla IAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAACjwAAAAJzaWcg AAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcAOwBAAEUASgBPAFQA WQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDGAMsA0ADVANsA4ADl AOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoB oQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJdAmcCcQJ6AoQCjgKY AqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oDlgOiA64DugPHA9MD 4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVn BXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG4wb1BwcHGQcrBz0H TwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5 CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kM EgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5JDmQOfw6bDrYO0g7u DwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYS RRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUSFTQVVhV4FZsVvRXg FgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0a BBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5q HpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7IiciVSKCIq8i3SMKIzgj ZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6J6sn3CgNKD8ocSii KNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwtQS12Last4S4WLkwu gi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNGM38zuDPxNCs0ZTSe NNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07 azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDnQSlBakGsQe5CMEJy QrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBK N0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIx UnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa 9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1YklinGLwY0Njl2Pr ZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09rp2v/bFdsr20IbWBt uW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWFdeF2Pnabdvh3Vnez eBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCC koL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyoswi5aL/IxjjMqNMY2Y jf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZ kJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWp phqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuy wrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1 wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXO Ns62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK 3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr ++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3 /Af8mP0p/br+S/7c/23////uACFBZG9iZQBkQAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgICAgICAgICAgIDAwMD AwMDAwMDAQEBAQEBAQEBAQECAgECAgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwP/wgARCABRAEgDAREAAhEBAxEB/8QArgABAAICAwEAAAAAAAAAAAAAAAgJ BAoBAgcGAQEAAQMFAQAAAAAAAAAAAAAACAIGBwEEBQkKAxAAAgICAgIDAQEAAAAAAAAABgcFCAME EAkBAiAwUBESEQABBQEAAgIBAwUBAAAAAAADAQIEBQYHEggRFAAQIRUgMFATFiMSAAICAgEDAwIE AwkAAAAAAAECAwQRBRIhEwYAMQdBFBAgIjIwUFHwYXGBkUIzFQj/2gAMAwEBAhEDEQAAAIYdaHr8 AAAAAAAAAAAAAAAAAAAAAAAAAAAAA90sTHk7MDR5qflpMkDZJkj1Iy0uzCFaGNJeRqtvLthFgRjg rz8jfq7y4Gn3D88RuRzH6Csqv4dNKodWdnuzXJsPuNNfPOPurSphX6FQABmV7fDo3AAAAAA//9oA CAECAAEFAP22YUZg4GT5k3WJL8oMe1tvGLg0QSTEmpJibLplTFML4bdUmYwYleIuUw6O+lC2OiOB L+BSfGs+YQTq6yZR1Zp4v2J0jw6HgQmoKYxawgbSG7Aqj5e+TJl8/Z//2gAIAQMAAQUA/bapbmCA BJnDoZk1z2cNOYhNpzWQO1IBh95gNdIxf3fSzC93DeFMs2GMLXIKvQUNdhyPKjrh4/6sJfNuxug9 r8Wt09NrXAvoiYpbKWQJvd7r1kge7LveuouPMy7fy19XV1PT7P/aAAgBAQABBQD9utSx1HA77epy pNehHnoLr2NFkfVujKhsi4Gb1HOB3W3c3UzahK46q9UNoK8Fi467bm3cbB10n20Xaj4qV49KWdPV ap2YqF05ddcnJ126zOni3pC9bIQwHiqA6kS34obqDdxgGqF6oPluyMhJ5fs//9oACAECAgY/AP53 5Bv6rqL0UQWIkA4llZY0PE9G4s/MggghTkYz6Ni7uUj8XqsO/IK0AMje4gjPD9zDq7DPbQ5OGZAf x3+6vVI5YwyQJzUMAQO5J+4EZwYvXk/le41tabVWrDJUjwRxjgd4S5UBVHPtqVwTkZJxn15TU0bU K9OrLHhS0oRVlUvGgxCx5iMK0g9gXGGbOfWvilEE9+1ZaKKGFmZ2Cgs0uWRFWMAAksQVDAuF648c 8e1+z11eq9vv2i0kuUiiQgKCsLI8jNJ+hOQUsoYuFVmW54roKtejX1LLC6zswLSNyLNyjjkEjsV5 u/QNzVlJBGNntrE9QissjGNWcu6R5LMmYwOqgsqkhiMdAx4/idqcLaapJZz/AFkmz2P9QYV/tj0u 0nnY2hSeZSxJw02ft1GfYYaIYHTJJHv6ueTbGR5Lkyz23MjFmbivCMFieR5JEnHr/u6e/rat5NuD LtGixWEjAAB3zMkK9FUtxiPBRkqvQYU+vJPL/J/MGahYyIonJWOOPkGVVTk3ORBhE7agkFiQWkIH kPnDwdv7t7FwK3vwRe1AD/e8cMZwOnJzj39TrsbDSbaanHA7P+5pJgFmz/gpkIH0Ax+cNI5ZsYyS T0/z/i//2gAIAQMCBj8A/nfknkdR1XYQwhYSQDiaV1ijbichuDOHKkEEKcjGfRs395HF4lUcd+QV a4MjdCK8Z7f7mHV2Ge2hycMyBvx+MPj7x3d2qdox2NjZ7ErxMUJFarkxspIylvIPTIGOoPr4e+Ev AvLdvQ820urjs7uyXVjLZ2VevsErLK7yySfbm1KsvNU4twROQU4+GN78kReTbTf7mnZDyrDTkmll pTLDanbnehH2z2mlhqOP1utd+5FEVAPlFym2w13jGl1MV27fvRxQwQtM8ccdQCOaaWS0zOyhI0dZ HidIWlyhZdJrJ9tU8dp7Wr35ZIIxNaSTvJyp1lnLvHCgaeVrJrYIjQKZXjR/i8UK+y2PjO9oPYon XRQSMYY+1ymsizYpskkzykEFTJ3Y5kkSNk4+vEPCNZrd2r7iWrClmWGukMFi3wWOGfFp3HCR1imk RXjR+RDPGpk/FPC0LTaaPeVNQVHUpVoFf+yx/XhIt6X6D6E4Bb1L4brddCumPkNbXzLGiqWi14Ub SR+IAeTMNxuTDJUIrE8c+tF8QeKVIKmioza7RwR1Y0jhh70vftukSARoYp7k/cIUf8P6sgD14XD8 PeBJS8NivFts9WNmd2ggKa+e9IOUkixCW6O/MxVJJsMwaRc/EfwT8OfA0cXkuq4PcuwIktm3aMTR STSWBFH9vWnYtYnNmVkVliQOkdZS/wAWf+coNj92dHDq9E8kWe3355Tc2Tp9eEFq9ZQuwDduBeQA UAa6XxTVw1fBqG+t7KvHCMRxVNe8ktDj75DSpUVjn9Rct9fzmKpWjijJJIRQoJPucAAZP1Pv/F// 2gAIAQEBBj8A/wA3gcFZiMaktLUszQMAUoHPoaSDKurSOskLmFi/eiwFjtIxzXteZPFUd8fja+mx 02w6fpopm5ipLs9SYdTFXzAXU24f5NzfpQyorY4X+P25DVanyMZlZ+vfu0bbJ0GmrxTMzzDKt0FL AuYwJgAk1eyUQbKLJAI6AmUfi5iefi5yL+yp8+zntd2Lm3NdjynqfQbPLevuSFAlRBVOU5RptLzO w1MynhQaesrf+oFkIRYX1ynUoVKUvg4jfL2lyXDZPBOe43l+nyRYFPLvt5XUNTS7+jkX+PzkRa/n l4ddVByMWHPugqix45rQX+mRJa9XNwFZZjxW333Uui3GAwXOOdWtxeaO9jUNfZWVnt3ntKGhqKrH x4kIJXnlyAljAljJKHHRCIw+w0MDnmk3On5tsRZekrNHZvoMhYV3/Pz/AKu81cjPx4Vda304wq6G OqZbf7GvOVXtjiMUfsEa8n4fE7/kuxr8x0IHU7rSVkMN9Ypbuj5/IFyWX3USZVUNfUscxWFbG+lK ikAQ7C+adL6xf3vKDj5nA2F9NylRfaabf6DMYps2RZXufU+RhQTJY1tcWZAiyCR5UiP4I5gzvaD9 S9TKgq3UTeSbftwpD3IMc/XdIHIdyrzXy+R/crZediKqK5yqnkifKoz8jdRvLuyNqB8V1PTqGVZ2 MyWKJc9LLLfyGsrvsFeSurUDeUQkEJUY0ryEYiefx+a/2Z6LY2uj1+trOpew+jsddZz7W8vv4Ood m8VXzbixOaymCuc/ha5YrXFd8JOTwVFcv51OV7N9hkarp9hkxg4pC2NpFiQYEfR6AU3pee55Vv8A q1VXLtn01A9a+ANhTRoHy1jmAIrfZP2+9n/cKdPwfQ/5CFhcDpJ8yoymKyLLqNdVdLV5kttaLpdX nY7BVVayohjOURZJXDKee9ovYT3hl0i5tOs2nYPY2FU2yMbYuz+cpWYblNdPXycJZt/j+d1B0CJ7 g/asX+Cqr3OdeR+i6Cyv+t7Dj2K5RqLS/J52d1tenQa6m6Mh1Vo1YSNUT7kgho3/AM2R2s+ERPlP 6mnsp0ywOwTAMNNkmllaEfyowtId5HtExXL8NRfhPn9v7v8A/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=1675; creation-date="Thu, 29 Sep 2011 18:50:48 GMT"; modification-date="Thu, 29 Sep 2011 18:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAI0AAAIDAQAAAAAAAAAAAAAA AAMJBQYICgEAAQQDAQAAAAAAAAAAAAAABwECBQgABAYDEAABBAIABAUDBQAAAAAAAAAFAgMEBgEH ERITCAAiFBUWITIzQpVW1gkRAAIBAwIFAgMFCQAAAAAAAAECAxESBAUGACExIhNBB1FSFWEyIxQI cUKSU5PTJFTU/9oADAMBAAIRAxEAPwDu3a2HCltpkjghcgPe88Ek3PqEKMSi5/HOhMl7SNI5gyPr lpxxhvDyODiOZtSFqlfpMy9srokg6rbKSD8CUjZaj1AJoeRoQRxAjX4JBfBDLJAfuuGgUMPmUSTI 9p9CVAYdwqpBJPnWP4yY/etff3fxn0pv5qfwT/2eF+uD/Xl/qYv/AE8Dd2HCiNqkkQhceOY884k5 PqE2MNi4/JOmsCLSSI4gx/pl1xthzDKOLi+VtK1pT6TKe2N0aQ9FtlUk/AF41Wp9ASKnkKkgcIdf gjF88MscA+85eBgo+ZhHM72j1IU2juNFBIUF3p7f2DQOx2923VNuJ0W9wKhquKBtYPETJgI0ct1D BmHxDk2NLYiz3QJGSy0/yKXHU5haOC0pzg9+2Wg6TrnuNhaZrUK5OmSy5BeNq2vZDNIoahBIvVSR 0NKHkTxWX3B3Vqmge3ORqmiS+HU4oMUI/wAt8sEbEc+tjMAeo6ilOMY6B/2F13T9Ma6qu/Y3cNf9 yAAbwy+3YJr6kEx1nIsmCmRhRsk5sKuOEJS64uE3JfVBjrelNuLUnOVZUolbq/T5ruZuLLy9qjTc fbskoaCJ55FZFKLcpXwvaPJfaLjRSAPhxwe1/wBQmgw7exIt0y5cm4liInZIAUZg72kHyCv4dlxI FWr+0tAoPcTT97aNTtmi5NoqtsqlxdgxbOKwDPwnxGDgIqOMC0yZrMaZDKDHmldGRIYcSnC23XEK wrIP1za2obV3DJoOreMZ+PJHd42vQhgkisrUFQyMpFQCK0IB5cGDTN4adufbn1rSnZsDIgmtuUq3 bejBlJNCGVgaEg05EjjIO9K4Y3B2xGtc17KJB87QqDMEQVqSjJMgB+K2yMJZW6420iUWUK9OzlWc Y6rifHZ+32qYO3N8YWtaibcGOeRXb0RZUkhLnr2pfc32A8B73AwtR3HsDM0TSe/VJMWFok5d7RGK YRjoLpLCi86XMOFqac7itRaio8LW23+0qo3e0VSWTht2pdH0y5ZiMCSRkkGYtzY2OPH2JFgEuy3I vVW7IQ7Gaaxjp8nL4sluv243ruLWX1zau4Z8bS8lUYRefMEaMFCkwnHLRmNqBqALRix51rxWXZ3v ZsDbWiR7f3noOPJrWIXRpGxcJpXBdmHmGSgmEi1tNxbtC0pSnDU9f7XrV70S1Z6fVXaDWSVFuiQ1 OdEhgiQMYVBsMBcWKNralV9qA4+PW7HXD4x3mXEuJ+7Pir27NA1PQN0ZOl61OMvVIpUMkwd5PIXV HBLyfiFrWAYP3KQVPTi1e1t3aTujaMOs6DEcfSJ8ebxRWJEEVPIlFSMeMLVCVKdpUhh14r+JE6LD Fs1kS6crCQohVcJGbCiq2B2uODYzgBmyhY9YuQxg9EDKYalOxSDjMhxHVw2xleWURGP5jEDkFFmq agAsK150NVNCakVFR0qevDNQaBJgunpNLhWLYzOInstFgdLJQHC0DFXIYi6i1tFnWQ2h5fV1IP1+ RHH37YdR916fLjpep+Q6w935enw5Or+jhy+Xh424Bl+MflGyfy/p4lyvH9tviazr1t9evDZZcy// AC4cfz0FfPNh+Wnpd58fy9Ol3pSnLiEnyDUpJhm6iXgYBQMmqykgthi2o41V2xDzhhmpBUVimgXy cuvJdaguOEG4cfnS6lt7CEsr1Mn8wEYwkNlX9HDKb6/vliz8m5tUXHoSOo98RlfKt1RJIsTxm9o3 SU+KzuEKKkUdTHURkOEWoYBgAp//2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=1586; creation-date="Thu, 29 Sep 2011 18:50:48 GMT"; modification-date="Thu, 29 Sep 2011 18:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIgAAAIDAAAAAAAAAAAAAAAA AAkKBQYIAQACAwEAAAAAAAAAAAAAAAAGBwMECAUQAAAHAAEDAwMFAQAAAAAAAAECAwQFBgcIERIJ ACETMVEUYXEiJBUWEQACAQMCBQIEAwkBAAAAAAABAgMREgQhBQAxEwYHQVFxIjJSYUIUgZGxctJz 09QVFv/aAAwDAQACEQMRAD8AYitXnMyeMsEmyrFDgpuuouThCTE3oV0hZWWi+v8ATlXcLW8LvkbD lk0gBwi3NJrOU26if5BEFxUQTcOF4d3rJxUnllskZQSoRDSvpVpkJpyJtArWhIoSGT96YMUpjVQV HrcwP7hGwFfjX3odOK2fzv0FIhlFcypaaZA6mOpq+oEIUPuYxuLgFKH7+rY8K7sTQTkn+3H/ALHE J74whqUWn8z/AOLidp3nUx6cno1pP0utxlbO7TJPTVd0e4WCUho0fd3KNoawYbRYyWCMREXCzYJR B0o2TUFuRdcE0FK2d4a3zExnnSQtIqkhSirWnpVZnIryBtIrSpAqRLj964E0oQgBSdSGY0/YY1B+ Fa+1Tpwn6lZe1FABUAOjdD2E/ToHwkEPr+nrVMEFYUNPyj+Hx4T0mQVdh7E8H88IvGOp6XdNl2fb svl5yOy2o0WQzGKutOkwrFgcXdO3yTu0wSE7GoxNrcM4mrJJtDoi5SIV+Cnt3pGFHeZO5MjDxcTZ tly0RsiWUTmKUXp0yiiNyjFoxc7FgbSSlPRhwfdkbbHlTTZufEzLEiFAyG03XEstRRqBRSlef4jj AvkP5WQvI+55rZIHivP8T2cBRbVFp1mwwSNcdXVvJTDR+1sSTBCnU8B/zEm5kFQ7HPxqLCT5A6D3 GnY/bZ7f2vMxzukW6F3BLo/UEZCMChPUk51qNRUDl7cHft2G45cLpiNiAKRay2l6kGtLV5Up6/Hg YcpUb8m7MmlAomRMyiVEzDa6QmIkcw0e4AexSyFUJ1Bb6GAB+/pq4GLM+FE/TY1Qfb/Vwv8AcN3w 4s2SO/UN9r+wP2cN3eHnm1vOxY5oeZapVM8rkHxVynFaTk7mpKuFpWwR0ZSr5C/PeXBdAtTJw/BD PI0xjtUYlIx11xKXt7QRyb5m7IwO293xdxx2yTPu+VkySiRoyoJkiYiIKgKiszD5yx0XXnV1ePe6 pd9wZ8VhF08CGFVKq6kiyQfNedTSMfSBrX3HC6nLTmByg5/W7NL3tef5jW5ahUC0V+NQzSUYxkc4 j5puezSC8m3suqXV65eIOo8pEhQVSKCQdBIY38vWhth8f4HYe1Z2HtP6uSGVrmMzRMQVBQUsWMUo STUHXhX5Xex7m3HGkzekrqCAI0lA1F2t13qB7fjxrPV6/wCPB5eZ1zVNc2evVZV6qNXhnfHVC5PG VZAwhXif9LBco6ISUiTQ4ImjTPYlnLFjRQK+KLoFTDX7Ym8rLsmOr422uemPmfIdGOmtV/SyUatb rXK3Vt0pxHv8fj5t0kLy5SyXcliLafl1WZARSltVDW0u14JX4tYHAmsTyYDGNXtc4grC0ILga48f Z6qnZNixmpBGGiSN+TNyCTUVQM9FQpjNPjEhAAT94imnfOcndT5Gyf8ApYcSNhJP0ehMZATdjXX1 gitANlKXVq3Kmp74yTt5Ytx/4Mk7rZF1epGyUFs9ttZXqfrry9OddBkYxXvHaztdUcWbXdqsdRS/ BGyRDbjmhS3z6rCmmWeKexznKW+kiYssKKxpMzKLeyoxoLlYADoUjg5u7JvK77TlBcbbI3tbWPJe Qg68l/Sx1NfpqwW6l3y14AO3I/Hq7hCYpctm0oHiK6U11aZwPlrdRS1tbdeP/9k= --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image004.jpg" Content-Description: image004.jpg Content-Disposition: inline; filename="image004.jpg"; size=1696; creation-date="Thu, 29 Sep 2011 18:50:48 GMT"; modification-date="Thu, 29 Sep 2011 18:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIoAAAIDAQAAAAAAAAAAAAAA AAUGCAkKBwEAAwEBAAAAAAAAAAAAAAAABAYHBQgQAAEEAgEDAwEIAwAAAAAAAAMCBAUGAQcIERIW FBUJACFRoRMjJDRWltcZEQACAQMDAgQDBgcAAAAAAAABAgMRBAUSEwYhBwAxIhRBUUJSI5PUFRdh cdHSJKQW/9oADAMBAAIRAxEAPwDYRLfIbpFhIPGsfE2ywRwTESwsLCb07ERU6zRntRLw7W5bYq1i JDO1JVls5MwAN2HGDgyRuQRV1Sz7PcuvLZLikaFhUqUuWZT9ljFbyJqH1AOSp9LUYECRX/ezhVhd vas7voNNQktVVh5alEtzG+k/SxQBh6lqpBI//oxp3+pXX/LuO3++Pon9luXfOH8O8/KeA/344P8A OX8ax/OeCEV8hmkX8g0ayEVa69HFMNEhYJCb07LxcE0WrCFy0w0pu2LTYhw7Rak5dOQsDjZhzk58 jbjKUYt52f5dZ2z3FI5CoqFVLlWY/ZUyW8aaj9ILgsfStWIBMsO9nCb+7S0V3TWaajJasqj7TCK5 kfSPqYIQo9TUUFhnd4kS8ZZN5aVrktqF9vtjKokGmNUx0nU411YSxmtbBNAdoNebHVKi5HWWkIR7 6Z/INxHSDCUd5khGvsPny3Fpwa8u7XIriZI0iPuSspCBpo0K/cRyyjcLhdUaMRXrRSxHFHbqO1vO 4FlbXuLOYjkkmHtQ0IMhSGVw3+RJFC20qF9MkighelWCg9JY8eeR25LFs2zaU4z2ePo0ZunaVABV 03/TfWhzlMt8tCTtGMeT2Wx9SKrSbIrX1TbBov7MDauTgSMq8xeecN41jrHH8nzUUmVbG205l2Lv 79JoleOb025oZFYNpakvxkRWJA037cc15Tk8hkuK4GWLDrlLqAQ+4sxsPDKySQnVcrURspXUtYvI RuyaWMatntbvrGXtlD2RVpulXCGinw5WvTwgCdiA/jHXp3TZ0zcO4yVipAPfgLtm4cND4SvCCK7V Yw6Y6+xWexQyuGuI7nGyK2l0rSq+YIYBlZTSquqsOlR1HhFyeJy/HcwcTm7aS1ykTLqR6VAY9GVl LK6sK0dGZT1oeh8OvxXy+JDnrxtYd3XLRpe3vT7sK477AHjOcdc9P5/4/Sl3mQjs9kpPnHaj/dtv 6eKV2aWJO8+MiU+pZLo0/nYXP93iwrfuy9laM+Pzl3dtW3OwUCzZ+Rvki3VZK24SxlxRE5yTtQnz drI5Es7BDteUDWUChF6dUJXjuzjMt4phMNybuxx/G5y2iu7L/j8eduQakLJj4ipK1o1Opoaj406e KlyvNZjjPaXkOSwV1NZ3p5lkRuxnS4V8jKGAahK16AlaH4AiviPXzFzEgS1cUZ2YKo8zZuLU+SYf EEgJpCRbYiZZyQ2BoEjKhuZExMIxjCR5MrpjHdnqy9hYY4sHyS2txS3hy1EFahVKSKKefwUCvxoP Onhc79arrkHGbi6NbqfDksxFCzBkc1p/Ek0+FTTz8Uw2DIWu0zA43p3lOAS2GuiydfWqq7TLWiwg ys20nB1FFxdgnWFYWgEmePkCN3eBkPkTZBFtx3bBtkzxiI8qTEKmkbgmctDXV0JMiKmkv1QOtVqq 1YgMYVygYIcslHGmzjXPTSbZUWWm2OgVWZw4joJTGxVqM1FUlQDnnG6/GpfyuH5G+E+/u/IfJ7JP +F+X+5K9x9/94qvj3l3vPd6j1X7/ANX1/M/V6/WxbGx93H7JcF+o7Q29thvbOn06NC7mzppp0+jT Snp8LtxX2knvDyb9O3TubgTZ3dXq3NZ297XXVq+81V1da+G+GzLurpUg8mU8jYOlKi5NeJK0LkrV aB0kTBRbA21nB3NFOYncv4hCgNDpkBsGhyDOoTnI0NyYWba7GBvDxJMI139YhcKu5XoZjEjdQerB l1sAQCtSwaOMDFHkdoOTtyBYtDbZuVDejQdQhV2WtVqEIYRqxDENQKf/2Q== --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=1656; creation-date="Thu, 29 Sep 2011 18:50:48 GMT"; modification-date="Thu, 29 Sep 2011 18:50:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAHQAYAwERAAIRAQMRAf/EAIwAAQEAAwAAAAAAAAAAAAAA AAkIAwUKAQABBAMBAAAAAAAAAAAAAAAEAAMGBwEFCAkQAAEEAgEDBQADAQAAAAAAAAUDBAYHAQII ExQVABESFglCIyYXEQACAQIDBQQIBAcAAAAAAAABAgMRBAASBSETFAYHMUEiMlFhgZEzFRYIwUJi 0nGhsYLCIyT/2gAMAwEAAhEDEQA/AO5YldcXF6AnTto5bjJYeHRiFlSUirqOtZqcM4WyDGRVvKZw DKl3x7DVXZgho3wu+TTyqhoolnXfZ0xEeYgH2/gKYYE+byKxH9u317SDT2YzRu4BEyBsJPEAr2Vx or3Xi5DG5bUpwGS7F44HvewLC7IdMHnZv2ayCvTU26ayW+m3ttrtjC3X6h7m/bhGanare9f3Y2ri x0R6W7wxFZGIFNsdUkXcPYS9aCWeMf2kiCASYlSmo9t74ysqm3Vwgn7qKfFLTffXO5J7CCf4H8QB hcQo2sCF9NVNPcxNPZs7ezBE/pAFfSv81btJxlA1vPqlpYJe1RrRUa4LSkdaVNjRUyhu8VYsW7sg oXerMVR+MNk919mzxXTTGc7eip02Mw7QSf54BtpAGQHYCAPZTA+2BPOUXGuaXfTdNSTlQKh9H1bH BkJj0Shs5dQVlRwCu+CpeNzuNtw0QfAH04k9ryyzPILD11zj9TL9JwjlJFPOBjVWKiuweju2bf64 NVkkCsctSfT622e6mGv4R2nN7O4UfeLIIzMvIj8l5e7JvLDEmQMpXhrLkHeIuukSAaRjQ5scxb1y zFosUnLZFTUfojj2zj2zkmEZgrbfN/lgK5YKWQUpl9P6RXAg8d7+sGxDfJ+V3ZZXJA/rU/FKxeS8 QC1TyfsmgwQnanQMTd5gjIRBNVRzYYdaSZBJN5hLKrHDP5bJud1t9teTtH5o1vXL7VrzW7rUXMFp cXSJBeTW0Y3LfCCReEKwYANSoy1IYknHvlzr0a6cdPOR+neidN9A5Ktm1bmTStCubnVOW9O1u6l+ YiUG/kuL0b1pYWgd2jzhZTLlVoUjVTWA/i3ymZRC0gBP9CL31s5GexyMUqWb3PfbaINDzHE7MSyO yUU1k7nfdzMwIHVFkV31xgWq3U3U13yvjX1JF5b5sFrcxy69fnUTIiQNxFyEBGdnRwJDXOoAVuxC CSDXFT3HW77fn17Rb2y6TcpLyatjcT6pCdH0M3LK/CxW9xbSNaqF4WaVnmgU1uVdVVlEdcRxyJe8 zOHlvREGc5m2Lb5QrD5BIiTQjY04koRNYG4kEYkUTl0Tl8iPNng57kTndksvqmu5HOE1tU2iuPjp FdXv+eOSNaswdYubpyVejSyvH4ZMjxyRyOwKt3EipU5gFbFz8m6J9sP3JdJOY7q06caDoMMIa3WW LT7C3ugJrdJ7e6tby0t4JI5Y89JEVmSOaMxs08ZJaLlsytrKuRyHFvSyTtda8WLd3s0mbUq6JydX iGsGiCtkNZWClKUzYoHx8f3DIPF40RUNPFk8rsEW2yizdIC2SPjtS+nJJOF4W43u8jjzcNUb0bZD XbTatHPcB2Y2Ak1k8m8nHq1DpK331Np3ywJNqLL86DT8CQ1tAtY2bflFuFECqcszPRWKJmnP7Ud2 b8kGMdx9OT6/aSXgH5D4+ElPa4AYHRP7F/1vtvK9Lsv9L1up/D4+rCdeo9WzPH5O5LWvlNMv+yu8 81KeOte7HLFpJ9o+WLdRQZeL/NLzTk+LFm3tYd3wVdzmzf8APky/mxI905ud1f0FQ55anwam0MN7 lydcb0BKpKlFkTkpVspr4KotIbGF7kISPQwgUXkBFMozLKZXdIuemk3Uh+vJc/PLT6xkPd8GOGtN 54wcktBJvK7wtVwe4jF58hyWo6Sa6ft9hsjp3EpvRdTauPEYYhamNr+BnFitvujAtupiaAZUZGJc f//Z --_008_0368F388C03BB34BBBFA73209849D47A4D74BA61ITREXMBXVS2itro_--
  • 2011-08-15 (Week of): IETF Online = Registration opens.
  • = IETF Meeting Session Request Tool.
  • 2011-09-26 = (Monday): Cutoff date for requests to schedule Working = Group meetings at 17:00 PT (00:00 UTC). To request a Working Group = session, use the = IETF Meeting Session Request Tool.
  • 2011- 10-03 = (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (00:00 UTC). To request a BOF, please see = instructions on Requesting a = BOF.
  • 2011-10-13 = (Thursday): Preliminary agenda published for = comment.
  • 2011-10-17 = (Monday): Working Group Chair approval for initial = document (Version -00) submissions appreciated by 17:00 PT (00:00 = UTC).
  • 2011-10-24 = (Monday): Internet Draft Cut-off for initial document = (-00) submission by 17:00 PT (00:00 UTC), upload using IETF ID Submission = Tool.
  • 2011-10-31 = (Monday): Internet Draft final submission cut-off by 17:00 = PT (00:00 UTC), upload using IETF ID Submission = Tool.
  • IETF = Meeting Materials Management Tool.
  • 2011-11-04 = (Friday): Early Bird registration and payment cut-off at = 17:00 PT (00:00 UTC).
  • IETF = Meeting Materials Management Tool.
  • 2011-11-07 = (Monday): Registration cancellation cut-off at 17:00 PT = (00:00 UTC).
  • 2011-11-13 - 2011-11-18: 82nd IETF = Meeting in Taipei, Taiwan.
  • 2011-12-16 = (Friday): Proceedings submission cutoff date by 17:00 PT = (00:00 UTC), upload using IETF = Meeting Materials Management Tool.
  • 2012-01-05 (Wednesday): Proceedings = submission corrections cutoff date by 17:00 PT (00:00 UTC), upload = using IETF = Meeting Materials Management = Tool.